AI Ajanına Güvenlik Ürünü Yetkisi: En Az Yetki Tasarımı

Öne çıkanlar

Her ürün için ayrı, adı ajan olduğunu belli eden servis hesabı açın.
Yetkiyi okuma, öneri ve onaylı yazma olarak üç katmanda tasarlayın.
Yazma yetkisini kapsam (cihaz, policy package, grup) ve süre ile sınırlayın.
Ajanın kimlik bilgileri PAM veya kasa çözümünde tutulmalı, düzenli döndürülmelidir.

En az yetki ilkesi yeni değildir: bir kimlik, görevini yapmak için gereken en dar yetkiye sahip olmalıdır. AI ajanlarında bu ilke daha da önem kazanır, çünkü ajan yüksek hızla ve çok sayıda işlem yapabilir; ayrıca girdileri (alarm metinleri, e-postalar, ticket açıklamaları) dışarıdan etkilenebilir. Bu rehber, bir güvenlik ürününe bağlanacak ajan için yetki tasarımını adım adım ele alır.

Neden admin hesabı vermemelisiniz?

Pilot aşamasında en sık görülen kısayol, ajanı mevcut bir admin hesabıyla bağlamaktır. Bu yaklaşım üç sorun yaratır: denetim izinde ajanın işlemleri insan işlemlerinden ayrılamaz; ajanın yanlış yorumladığı bir talep ürünün tamamını etkileyebilir; ve hesabın kimlik bilgileri sızarsa saldırgan doğrudan tam yetki kazanır. Ajanın bir prompt injection girişimiyle yönlendirilmesi ihtimali de düşünüldüğünde, yetki sınırı ajanın kendi davranışından bağımsız bir güvenlik katmanı olmalıdır.

Üç katmanlı yetki modeli

Katman 1: Okuma

Konfigürasyon, log, alarm ve envanter verilerini okuma. Çoğu ürün salt okunur rol sunar (örneğin firewall yönetim konsollarında read-only admin profilleri, SIEM'lerde arama yapabilen ama içerik değiştiremeyen roller). İlk aşamada ajan yalnızca bu katmanda çalışmalıdır.

Katman 2: Öneri ve taslak

Ajan değişikliği ürüne yazmaz; bunun yerine ITSM'de bir change request, bir pull request veya onay kuyruğunda bir taslak oluşturur. Bu katmanda ajanın ürüne yazma yetkisi yoktur, yalnızca iş akışı aracına yazma yetkisi vardır. Birçok kurum için kalıcı çalışma modeli budur.

Katman 3: Onaylı yazma

Onay verildikten sonra değişikliğin ajan tarafından uygulanması. Burada yetki, yalnızca onaylanmış değişikliğin kapsamına ve sınırlı bir süreye bağlanmalıdır. İdeal olarak uygulama, onay kaydının kimliğini taşıyan ve başka işlem yapamayan bir mekanizmayla yapılır.

Adım adım tasarım

Görev envanteri çıkarın: ajanın yapacağı her işi ürün, nesne ve işlem (oku/oluştur/değiştir/sil) düzeyinde listeleyin.
Her görevi ürünün rol modelindeki en dar izinle eşleştirin. Ürün yeterince ince rol sunmuyorsa bunu not edin ve telafi edici kontrol (örneğin ara katman API) planlayın.
Servis hesaplarını oluşturun: ürün başına bir hesap, açıklayıcı adlandırma (örneğin svc-ai-agent-siem-ro), etkileşimli oturum açma kapalı.
Kapsamı daraltın: firewall'da belirli cihaz grupları veya policy package'lar, EDR'de belirli cihaz grupları, kimlik sisteminde belirli OU'lar.
Ağ kısıtı ekleyin: API erişimine yalnızca ajan altyapısının kaynak IP'lerinden izin verin.
Kimlik bilgilerini kasaya alın: API anahtarları ve parolalar PAM veya secret manager'da tutulsun, döndürme periyodu belirlensin.
Loglamayı doğrulayın: ajanın her API çağrısı hem üründe hem merkezi log sisteminde görünmeli.
Yetki gözden geçirmesini takvime bağlayın: kullanılmayan izinleri düzenli aralıklarla kaldırın.

Ürün bazında örnekler

Firewall

Okuma için kural tabanı, obje ve hit count verisine erişim yeterlidir. Yazma gerekiyorsa adayı (candidate) konfigürasyona yazma ile commit/install işlemini ayırmayı değerlendirin; commit veya install yetkisini insanda bırakmak yaygın ve güvenli bir modeldir.

SIEM

Arama ve alarm okuma ilk katmandır. Korelasyon kuralı değiştirme yetkisi yerine, kural değişikliği önerisini bir içerik deposuna (ör. Git) yazdırıp normal inceleme sürecinden geçirmek hem izlenebilirlik hem geri alma açısından avantajlıdır.

EDR/XDR

Telemetri okuma ve vaka notu yazma düşük risklidir. İzolasyon, süreç sonlandırma ve özellikle istisna (exclusion) ekleme yüksek risklidir ve onay gerektirmelidir. İstisna yetkisi, saldırganların da hedeflediği bir alan olduğu için ayrıca korunmalıdır.

Kimlik ve PAM

Ajanın kimlik sisteminde grup üyeliği değiştirmesi veya oturum sonlandırması güçlü işlemlerdir. Bu işlemler için just-in-time yetki yükseltme, yani yalnızca onaylı işlem süresince geçerli rol ataması tercih edilebilir.

Sık yapılan hatalar

Pilot için verilen geniş yetkinin üretime aynen taşınması.
Tek bir servis hesabının birden fazla ürün ve ortamda kullanılması.
API anahtarlarının yapılandırma dosyalarında veya ortam değişkenlerinde düz metin olarak bırakılması.
Ajanın kendi yetkisini değiştirebilecek bir role sahip olması.
Yetki tasarımının belgelenmemesi, dolayısıyla denetimde açıklanamaması.

Sık sorulan sorular

Ürün yeterince ince rol sunmuyorsa ne yapmalı?

Ajan ile ürün arasına yalnızca izin verilen API çağrılarını geçiren bir ara katman koymak veya ajanı öneri katmanında tutup yazmayı insana bırakmak iki yaygın seçenektir.

Just-in-time yetki her ürün için mümkün mü?

Her üründe yerleşik değildir. PAM çözümleri veya kimlik sağlayıcının zaman sınırlı rol ataması özellikleriyle benzer bir sonuç elde edilebilir.

Ajanın servis hesabı MFA kullanabilir mi?

Servis hesapları genellikle etkileşimli MFA kullanmaz; bunun yerine kısa ömürlü token, sertifika tabanlı kimlik doğrulama ve kaynak IP kısıtı gibi kontroller uygulanır.

İlgili çözümler

İlgili rehberler

confidenya

Bu adımları kendi ortamınızda planlayalım

Hiçbir değişiklik insan onayı olmadan canlıya alınmaz. Güvenlik ürünlerinizin yönetimini AI ajanlarına kademeli ve denetlenebilir şekilde devretmek için ekibimizle görüşün.

Ekibimizle görüşün

Bu içerik genel bilgilendirme amaçlıdır. Kurumunuza özel kararlar için uzman değerlendirmesi önerilir.

AI ajanına güvenlik ürünü yetkisi verirken en az yetki tasarımı