Erişim Kontrolü, Kimlik ve Sır Yönetimi

Kazanimlar:

• Kimlik doğrulama ile yetkilendirmeyi ayırıp RBAC/ABAC ile en az yetki uygulayabilme
• Modeli kullanıcı bağlamında çalıştırarak karışık vekil riskini önleyebilme
• API anahtarlarını sır yönetim sistemiyle saklayıp rotasyona bağlayabilme

Bir AI sistemine yapılan saldırıların önemli bir kısmı modeli "kandırmakla" değil, çalınmış bir API anahtarıyla ya da fazla yetkili bir hesapla başlar. Güvenliğin bu katmanı klasik bilgi güvenliğinden gelir ama AI bağlamında yeni riskler ekler: model başkasının adına araç çağırır, bir servis hesabı tüm verilere erişir, bir anahtar GitHub'a sızar. Bu ünitede kimlik doğrulama, yetkilendirme (RBAC/ABAC), en az yetki ve sır (secret) yönetimi ile AI sistemine erişimi nasıl daraltacağınızı öğreneceğiz.

Kimlik Doğrulama ve Yetkilendirme Farkı

İki terim sık karıştırılır:

• Kimlik doğrulama (authentication): "Sen kimsin?" — kullanıcının/servisin gerçekten iddia ettiği kişi olduğunu kanıtlamak (parola, token, sertifika, MFA).
• Yetkilendirme (authorization): "Ne yapabilirsin?" — kimliği doğrulanmış tarafın hangi kaynağa/eyleme erişebileceğini belirlemek.

AI sistemlerinde kritik incelik şudur: model bir kullanıcı adına iş yaparken, o kullanıcının yetkisiyle mi yoksa geniş bir servis hesabıyla mı çalışıyor? İkincisi tehlikelidir — çünkü injection'la kandırılan model, servis hesabının tüm yetkisine erişir.

Dikkat: "Karışık vekil (confused deputy)" sorunu: düşük yetkili bir kullanıcı, yüksek yetkili bir modele iş yaptırarak dolaylı olarak erişemeyeceği verilere ulaşır. Model her zaman kullanıcının yetki bağlamında çalışmalıdır, kendi geniş yetkisiyle değil.

RBAC ve ABAC

• RBAC (Role-Based Access Control): Erişim, kullanıcının rolüne bağlıdır. "Destek uzmanı" rolü müşteri notlarını okuyabilir ama silemez. Basit ve yaygın.
• ABAC (Attribute-Based Access Control): Erişim, özniteliklere bağlıdır: kullanıcının departmanı, verinin gizlilik etiketi, günün saati, isteğin geldiği ağ. Daha ince ayarlı ama daha karmaşık.

Çoğu kurum RBAC ile başlar, hassas verilerde ABAC ile derinleştirir. AI için pratik kural: model, çağırdığı her aracı ve eriştiği her veriyi, isteği yapan kullanıcının rol/özniteliklerine göre filtrelemeli.

Adım Adım: En Az Yetki Uygulamak

1. Envanter çıkarın. Model hangi araçları çağırıyor, hangi verilere erişiyor? Hepsini listeleyin.
2. Her erişimi gerekçelendirin. "Bu asistanın gerçekten silme yetkisine ihtiyacı var mı?" Yoksa kaldırın.
3. Salt-okunur varsayılan. Model varsayılan olarak okuyabilsin; yazma/silme ayrı, dar kapsamlı token gerektirsin.
4. Kullanıcı bağlamını taşıyın. Aracı, servis hesabıyla değil kullanıcının yetkisiyle çağırın.
5. Kısa ömürlü kimlik bilgisi. Uzun ömürlü anahtar yerine kısa süreli, otomatik yenilenen token kullanın.

Sır (Secret) Yönetimi

Sır, API anahtarı, parola, token veya sertifika gibi gizli kalması gereken kimlik bilgisidir. AI projelerinde en yaygın kaza, model sağlayıcısının API anahtarının koda gömülüp sürüm kontrolüne (Git) sızmasıdır.

Doğru uygulama:

• Anahtarları koda asla gömmeyin; ortam değişkeni veya bir sır yönetim sistemi (secret manager — anahtarları şifreli saklayan ve erişimi denetleyen servis) kullanın.
• Rotasyon: Anahtarları düzenli aralıklarla (örneğin 90 günde bir) yenileyin; sızıntı şüphesinde anında iptal edin.
• Kapsam daraltma: Her anahtar yalnızca gereken servise ve gereken yetkiye sahip olsun.
• Denetim: Anahtarın kim, ne zaman, nereden kullandığını loglayın.

Dört Kopyalanabilir Şablon

Erişim gözden geçirme kontrol promptu:

Aşağıdaki araç listesindeki her araç için değerlendir:- Bu asistanın görevini yapmak için bu araç GEREKLİ mi? (evet/hayır)- Salt-okunur mu, yoksa yazma/silme mi yapıyor?- Bu araç kullanıcının yetkisiyle mi, servis hesabıyla mı çağrılıyor?Gereksiz veya aşırı yetkili olanları "KALDIR/DARALT" olarak işaretle.<araclar>{{ arac_listesi }}</araclar>

Sır sızıntısı tarama promptu:

Aşağıdaki kod parçasında sabit kodlanmış (hardcoded) sır olabilecekher şeyi bul: API anahtarı, parola, token, bağlantı dizesi, özelanahtar. Her biri için satır ve tür ver. Değeri yanıtına KOPYALAMA;maskele (ilk 4 karakter + ***).<kod>{{ kaynak }}</kod>

En az yetki karar kuralı:

Yeni bir araç/erişim talebi geldiğinde sor:1. Bu erişim olmadan görev yapılabilir mi? -> Evet ise: REDDET2. Salt-okunur yeterli mi? -> Evet ise: yazma yetkisi VERME3. Kapsam tek bir kaynağa daraltılabilir mi? -> Evet ise: daratVarsayılan cevap "hayır"dır; erişim gerekçeyle kazanılır.

Rotasyon takvimi hatırlatıcısı:

Her sır için kaydet: sahip, oluşturma tarihi, son kullanım, kapsam.90 günü geçen veya 30 gündür kullanılmayan her anahtarı "ROTASYON/İPTAL ADAYI" olarak raporla.

Zayıf Prompt / Güçlü Prompt

Zayıf yaklaşım

Güçlü yaklaşım

Model tüm veriye tek servis hesabıyla erişir

Model, isteği yapan kullanıcının yetkisiyle erişir

API anahtarı koda gömülü, hiç değişmez

Anahtar sır yöneticisinde, 90 günde rotasyon

Asistana geniş "her şeyi yap" yetkisi

Salt-okunur varsayılan, dar kapsamlı yazma

Erişimler hiç gözden geçirilmez

Düzenli erişim incelemesi ve iptal

Üç Mini Vaka

Vaka 1 — Karışık vekil verisi sızdırdı. Bir şirket içi asistan, tüm çalışan kayıtlarına erişebilen bir servis hesabıyla çalışıyordu. Stajyer bir kullanıcı, "yönetici maaş tablosunu özetle" diyerek normalde göremeyeceği verilere ulaştı; çünkü model, kullanıcının değil kendi geniş yetkisinin bağlamında sorguladı. Kullanıcı bağlamı taşınacak şekilde düzeltilince stajyer yalnızca kendi görebileceği kayıtları çekebildi.

Vaka 2 — Sızan anahtar 2 haftada 190.000 TL fatura. Bir geliştirici, model API anahtarını bir yardımcı script'e gömüp herkese açık bir depoya pushladı. Bir bot anahtarı 40 dakikada buldu ve iki hafta boyunca kullandı; fatura 190.000 TL'ye ulaştı. Anahtar sır yöneticisine taşınıp rotasyona bağlanınca ve depo taraması eklenince olay tekrarlamadı.

Vaka 3 — Salt-okunur varsayılan kesintiyi önledi. Bir DevOps asistanı, prompt injection ile "üretim veritabanını sıfırla" komutu aldı. Ancak asistana yalnızca salt-okunur token verilmişti; yazma/silme ayrı bir onaylı akıştaydı. Komut yetki hatasıyla reddedildi ve olay bir alarm olarak loglandı; hiçbir veri kaybı olmadı.

İpucu: Yeni bir erişim talebinde varsayılan cevabınız "hayır" olsun. Erişim, gerekçeyle kazanılan bir şeydir; herkese geniş verip sonra kısmak neredeyse hiç yapılmaz ve risk birikir.

Sık yapılan hatalar

• Modeli geniş bir servis hesabıyla çalıştırıp kullanıcı bağlamını kaybetmek (karışık vekil).
• API anahtarını koda gömmek ve sürüm kontrolüne sızdırmak.
• Anahtarları hiç rotasyona sokmamak ("çalışıyor, dokunma").
• Asistana varsayılan olarak yazma/silme yetkisi vermek.
• Erişimleri bir kez verip bir daha gözden geçirmemek.
• Kimlik doğrulama ile yetkilendirmeyi karıştırıp "giriş yaptı, her şeye erişebilir" varsaymak.

Özetle

• Kimlik doğrulama "kimsin", yetkilendirme "ne yapabilirsin" sorusudur; AI'da ikisi de kullanıcı bağlamında işlemeli.
• Model, kendi geniş yetkisiyle değil isteği yapan kullanıcının yetkisiyle çalışmalı (karışık vekil riskini önler).
• RBAC ile başlayın, hassas veride ABAC ile derinleştirin; en az yetkiyi varsayılan yapın.
• Sırları koda gömmeyin; sır yöneticisinde saklayın, kapsamı daraltın ve düzenli rotasyona sokun.
• Salt-okunur varsayılan ve dar kapsamlı yazma, injection'ın etkisini büyük ölçüde sınırlar.

Uygulama görevi

AI asistanınızın eriştiği tüm araç ve verileri listeleyin. Her biri için üç soruyu yanıtlayın: (1) Gerçekten gerekli mi? (2) Salt-okunur yeterli mi? (3) Kullanıcı bağlamında mı çalışıyor? Ardından tüm sabit kodlanmış sırları arayın (yukarıdaki tarama promptuyla) ve bulduğunuz her anahtar için bir rotasyon planı yazın. En az bir gereksiz yetkiyi kaldırın.

Kontrol listesi

• [ ] Model, isteği yapan kullanıcının yetki bağlamında çalışıyor.
• [ ] Araç ve veri erişimleri en az yetki ilkesiyle daraltıldı.
• [ ] Yazma/silme salt-okunurdan ayrı, onaylı ve dar kapsamlı.
• [ ] Hiçbir sır koda gömülü değil; sır yöneticisinde tutuluyor.
• [ ] Anahtarlar için rotasyon takvimi ve iptal prosedürü var.
• [ ] Erişimler düzenli olarak gözden geçiriliyor.