Bulut LLM Güvenliği: Azure OpenAI, Bedrock ve Vertex AI Ayarları

Bulut LLM güvenliğinde hangi ayarlar sizin sorumluluğunuzda?

Paylaşılan sorumluluk modelinde sağlayıcı, platformun ve modelin güvenliğinden sorumludur. Hizmetin internetten erişilebilir olup olmadığı, hangi kimliğin hangi modeli çağırabildiği ve kayıtların nerede tutulduğu ise sizin kararınızdır. "Hizmet güvenli, o halde kullanımımız da güvenli" varsayımı yapılandırma hatalarının en yaygın kaynağıdır.

Aşağıdaki tablo, üç büyük platformda aynı kontrolün karşılığını gösterir.

Sorumluluk dağılımını yazılı hale getirin: ayarı kim yapıyor, kayıtları kim izliyor, olay anında sağlayıcıyla kim konuşuyor? Veri saklama ve eğitim kullanımı gibi sözleşme tarafındaki konular için LLM sağlayıcısı veri saklama kontrolü yazısına bakın.

Özel uç nokta neden ilk karardır?

Genel uç nokta kullanıldığında korumanın tek katmanı kimlik bilgisidir. Anahtar sızarsa dünyanın her yerinden çağrı yapılabilir. Özel uç noktada saldırganın önce ağınıza girmesi gerekir. Bu, ikinci bir katman ekler.

Azure'da Foundry kaynağının ağ ayarlarında genel ağ erişimini kapatıp özel uç nokta eklersiniz. Varsayılan ağ kuralı reddetmeye çekildiğinde, başka bir kural izin vermedikçe tüm erişim engellenir. Sanal ağdaki istemciler aynı adresi kullanır, DNS onları özel bağlantıya yönlendirir.

Bedrock'ta arayüz VPC uç noktası, VPC'nizden Bedrock'a özel bir yol açar. Çıkarım çağrıları bedrock-runtime uç noktasından geçer. AWS belgelerine göre uç noktanın varsayılan politikası Bedrock'a tam erişim verir. Bu yüzden hangi kimliklerin hangi işlemleri yapabileceğini sınırlayan özel bir uç nokta politikası yazın.

Google Cloud tarafında VPC Service Controls, belirlediğiniz kaynakların çevresinde bir hizmet çevresi oluşturur ve veri sızdırma riskini azaltır. Platform çevreye eklendiğinde, izin listesinde olmayan kaynaklardan genel internet erişimi engellenir.

Test ve geliştirme ortamlarına aynı disiplini uygulayın. Geliştirme hesabında genel erişime açık bırakılan hizmet sık görülen bir hatadır.

Anahtar yerine kimlik nasıl kullanılır?

Kimlik tabanlı erişimde uygulama, bulut sağlayıcının kimlik sistemiyle doğrulanır ve kısa ömürlü yetki alır. Kodda, dosyada ya da günlükte unutulacak kalıcı bir sır kalmaz.

Azure'da yerel kimlik doğrulamayı, yani anahtarla erişimi disableLocalAuth özelliğiyle ya da "Azure AI Services resources should have key access disabled" adlı Azure Policy tanımıyla kapatırsınız. Microsoft belgesi önemli bir ayrıntıyı belirtir: bu değişiklik anında etkili olmaz. Ağ geçidi önbelleği yenilenene kadar eski anahtarlar birkaç dakika, bazen birkaç saat kabul edilebilir. Değişiklikten sonra eski anahtarla istek gönderip HTTP 401 aldığınızı doğrulamadan işi kapatmayın.

Bedrock'ta temel yöntem IAM rolleridir. API anahtarı gerekiyorsa AWS üretim için en çok 12 saat geçerli kısa süreli anahtarları önerir. Uzun süreli anahtarlar ayrı bir IAM kullanıcısına bağlanır ve keşif amaçlıdır. Google Cloud'da uygulama, en az yetkili bir hizmet hesabıyla çalışır.

Uygulama adımları:

1. Her uygulama ve ortam için ayrı bir kimlik oluşturun.
2. Kimliğe yalnız gereken model çağrısı iznini verin, yönetim izinlerini vermeyin.
3. Statik anahtarı kapatın. Kapatamıyorsanız kasada tutun ve rotasyon planlayın.
4. İnsan kullanıcıların yönetim erişimini çok faktörlü doğrulamaya bağlayın.
5. Kullanılmayan izinleri düzenli olarak kaldırın.

Bir anahtar yine de sızarsa izlenecek adımlar LLM API anahtarı sızdı yazısında anlatılır.

Hangi kayıtlar açılmalı, hangileri maskelenmeli?

Kayıt tutma, olay anında "ne oldu" sorusunu yanıtlamak için gereklidir. Ancak varsayılan durum her platformda aynı değildir. AWS belgelerine göre Bedrock'ta model çağrı kaydı varsayılan olarak kapalıdır. Açıldığında istek ve yanıt gövdeleri, çağıran kimliğin ARN'si ve token sayıları CloudWatch Logs ya da S3'e yazılır. 100 KB'ı aşan gövdeler ayrı nesne olarak S3'te saklanır. Google Cloud'da BigQuery dışındaki hizmetler için Data Access denetim kayıtları varsayılan olarak kapalıdır ve açıkça etkinleştirilmeleri gerekir.

İçerik kaydı çift yönlü bir risktir. Olay incelemesi için çok değerlidir, ama kişisel veri, ticari sır ve kimlik bilgisi taşır. Kayıt deposu bu nedenle saldırganın hedefi olur. İçeriği saklayacaksanız:

• Kişisel veriyi modele ve kayda gitmeden önce maskeleyin.
• Kayıt deposuna okuma erişimini birkaç role sınırlayın.
• Saklama süresini kısa tutun ve otomatik silme kuralı tanımlayın.
• Silme ve değiştirme işlemlerini ayrıca izleyin.

TCKN, IBAN ve kart numarası gibi alanların maskelenmesi için KVKK uyumlu PII maskeleme yazısına bakabilirsiniz. Meta veri kaydı ise her zaman açık olmalıdır: çağıran kimlik, zaman, model, token sayısı, hata ve ret nedeni.

Bölge seçimi veri akışını nasıl etkiler?

Bölge, verinin nerede saklandığını ve istemin nerede işlendiğini belirler. Bu iki şey aynı olmayabilir.

Azure'da saklanan veri, dağıtım türünden bağımsız olarak kaynağın bulunduğu coğrafyada kalır. İşleme ise dağıtım türüne bağlıdır. Global dağıtımlarda istemler herhangi bir Azure bölgesinde işlenebilir. Data Zone dağıtımlar işlemeyi Microsoft'un tanımladığı veri bölgesiyle, örneğin AB ile sınırlar.

Bedrock'ta coğrafi çıkarım profilleri istekleri aynı coğrafyadaki bölgelere yönlendirir. Küresel profiller ise her ticari bölgeye gidebilir. AWS belgesi, saklanan verinin kaynak bölgede kaldığını, ancak istem ve çıktıların bölgeler arası çıkarım sırasında kaynak bölge dışına çıkabileceğini belirtir. Profil adındaki önek tek başına güvenilir bir gösterge sayılmaz. Veri yerleşimi gerekiyorsa her kaynak bölgede profilin hedef listesini sorgulayın.

Kişisel veri işleyen uygulamalarda bu kararı KVKK'nın yurt dışına aktarım hükümleriyle birlikte, hukuk biriminizle verin. Herkese açık içerik işleyen bir asistanla müşteri verisi işleyen bir asistan aynı bölge kararını gerektirmez.

Şifreleme ve müşteri yönetimli anahtar ne zaman gerekir?

Aktarım şifrelemesi istemci ile hizmet arasındaki trafiği korur ve her üç platformda da standarttır. Bekleme şifrelemesi saklanan veriyi korur. Varsayılan olarak sağlayıcı yönetimli anahtar kullanılır. Müşteri yönetimli anahtar, anahtarı devre dışı bırakarak saklanan veriye erişimi kesme imkânı verir, ama anahtar yönetimi yükünü de getirir.

Müşteri yönetimli anahtar şu durumlarda değerlendirilmelidir: düzenleyici beklenti varsa, ince ayar verisi ya da yüklenen belgeler hassassa, sözleşme anahtarın kurumda kalmasını istiyorsa. Şifreleme, verinin modele açık metin olarak gittiği gerçeğini değiştirmez. Bu yüzden veri azaltma ayrı bir kontroldür: gereksiz alanları modele göndermeyin.

Dağıtım öncesi kontrol listesi neleri içerir?

Cevaplardan biri "hayır" ise gerekçeli bir risk kabulü olmadan yayına çıkmayın.

• Genel ağ erişimi kapalı ve erişim yalnız özel uç noktadan mı?
• Bedrock uç nokta politikası varsayılan tam erişimden daraltıldı mı?
• Her uygulama ve ortam kendi kimliğiyle ve en az yetkiyle mi çalışıyor?
• Azure'da anahtarla erişim kapatıldı ve eski anahtarın 401 döndüğü doğrulandı mı?
• Çağrı kaydı ve denetim kayıtları bilinçli olarak açıldı mı?
• İçerik kaydı maskeli, erişimi sınırlı ve süreli mi?
• Dağıtım türü ya da çıkarım profili veri yerleşimi kararıyla uyumlu mu?
• Kota ve maliyet uyarıları tanımlı mı?

Yapılandırma zamanla kayar. Altyapıyı kod olarak yönetin ve sapmaları otomatik tarayın. Birden fazla bulut ve sağlayıcı kullanan kurumlarda kimlik, kota ve kayıt politikasını tek noktada toplamak için LLM gateway yaklaşımı değerlendirilebilir.

Sık Sorulan Sorular

Bulut LLM hizmetinde ilk yapılması gereken güvenlik ayarı nedir?

İlk iki ayar, genel ağ erişimini kapatıp hizmete özel uç nokta üzerinden ulaşmak ve kimlik doğrulamayı statik anahtardan kimlik tabanlı yönteme taşımaktır. Azure'da bu, özel uç nokta ile disableLocalAuth ayarına karşılık gelir. Bedrock'ta arayüz VPC uç noktası ve IAM rolleri, Google Cloud'da VPC Service Controls çevresi ve hizmet hesapları kullanılır.

API anahtarı yerine neden kimlik tabanlı erişim tercih edilir?

Statik anahtarlar kopyalanır, koda ya da günlüğe sızar ve rotasyonu ertelenir. Kimlik tabanlı erişimde uygulama kısa ömürlü, role bağlı yetkiyle çalışır ve kayıtlarda çağıranın kimliği görünür. AWS de Bedrock API anahtarı gerekiyorsa üretimde en çok 12 saat geçerli kısa süreli anahtarları, uzun süreli anahtarları ise yalnız keşif amaçlı kullanmayı önerir.

Bölge seçimi neden güvenlik ve uyum meselesidir?

Bölge ve dağıtım türü, istem ve yanıtların hangi coğrafyada işlendiğini belirler. Azure'da Global dağıtımlar herhangi bir Azure bölgesinde işlenebilir, Data Zone dağıtımlar belirli bir veri bölgesiyle sınırlı kalır. Bedrock'un küresel çıkarım profilleri de istekleri her ticari bölgeye yönlendirebilir. Kişisel veri işleyen uygulamada bu seçimi hukuk birimiyle birlikte yapın.

LLM hizmetinde hangi kayıtlar tutulmalı?

Çağıran kimlik, zaman, model, token sayısı, hata ve ret nedeni gibi meta veriler her zaman tutulmalıdır. İçerik kaydı ayrıca değerlendirilir. Bedrock model çağrı kaydı açıldığında istek ve yanıt gövdeleri de kayda girer, bu yüzden kayıt deposu kişisel veri deposu gibi korunmalı, erişimi sınırlanmalı ve saklama süresi kısa tutulmalıdır.

Kaynaklar

• Microsoft Learn: Disable local authentication in Foundry Tools
• Microsoft Learn: Understanding deployment types in Microsoft Foundry Models
• AWS: Monitor model invocation using CloudWatch Logs and Amazon S3
• AWS: Use interface VPC endpoints (AWS PrivateLink) with Amazon Bedrock
• AWS: Geographic cross-Region inference
• Google Cloud: Cloud Audit Logs overview

İlgili Yazılar

• LLM Sağlayıcı Veri Saklama Politikaları Karşılaştırması
• KVKK Uyumlu PII Maskeleme LLM Trafiğinde Veri Koruma
• LLM API Anahtarı Sızdı: İlk İki Saatte Yapılacaklar
• LLM Gateway Nedir? LLM Firewall ve Runtime Protection ile Farkı