AI ajan güvenliği: etki alanını ve kimlik bilgilerini sınırlayın

AI ajanları güçlü otomasyon araçlarıdır — sınırsız güç hataları felaketleştirir. Ajanınız ele geçirilirse veya kontrolden çıkarsa neleri etkileyebilir? Bu makale etki alanı (blast-radius) yaklaşımını, somut kimlik bilgisi kapsamlandırma desenlerini ve bir ajanın asla kalıcı olarak tutmaması gereken gizli verilerin kısa, açık bir listesini anlatır.

AI ajanları için 'blast radius' ne anlama gelir

Blast radius basit bir risk metriğidir: tek bir ele geçirilmiş bileşen ne kadar zarar verebilir? API çağrıları yapan, uzaktan eylemler gerçekleştiren veya kullanıcı adına sistemlere erişen AI ajanlar için blast radius üç şeye karşılık gelir: (1) ajanın hangi kimlik bilgilerine veya tokenlara sahip olduğu, (2) bu kimlik bilgilerinin hangi kaynaklara erişmesine izin verdiği ve (3) kimlik bilgilerinin ne kadar süre geçerli kaldığı. Bu üçünden herhangi birini azaltırsanız blast radius küçülür.

Pratik düşünün. Dar kapsamlı, geçici bir oturum tokenı kullanıp bir günlük dosyası alan bir ajanın blast radius'u, üretim veritabanınız için uzun ömürlü bir yönetici API anahtarına sahip olan ajandan çok daha küçüktür. Benzer şekilde, sorun giderme için uzak masaüstü oturumları başlatabilen bir ajan, yalnızca sistem metriklerini okuyan bir ajandan daha risklidir.

Kimlik bilgisi kapsamlandırma: işe yarayan somut kontroller

Kimlik bilgilerini kapsamlandırmak bir onay kutusu değil — bir tasarım disiplindir. Bu somut kontrolleri alternatif olarak değil, birlikte kullanın.

• Rol bazlı en az ayrıcalık: minimal eylemlerle roller verin (yalnızca okuma vs okuma-yazma vs yürütme). Ajan eylemlerini ayrı rollere eşleyin ve tek bir her şeyi kapsayan rolden kaçının.
• Kısa ömürlü oturum tokenları: yüksek riskli işlemler için saniye-ile-dakika arası TTL'leri tercih edin. Örneğin, aktif oturumlar için 30s–15m; düşük riskli okuma işlemleri için 1–4 saat.
• İhtiyaca göre yükseltme (just-in-time): ajanın daha yüksek haklara ihtiyacı olduğunda yükseltilmiş tokenları mint etmek için onay veya talep üzerine çalışan bir broker gerektirin. İşlem tamamlanır tamamlanmaz iptal edin.
• Donanım destekli veya bulut KMS: ana kök sırları ajan sürecinin dışında tutun. Ephemeral kimlik bilgileri oluşturan bir secrets broker kullanın.
• Kapsamlı servis hesapları: insan görünümlü API anahtarlarından kaçının. Döndürebileceğiniz veya bağımsız iptal edebileceğiniz her ajan, her görev için ayrı servis hesapları oluşturun.

Kısa ömürlü tokenlar tek başına en etkili kontroldür. Bunlar tek bir ele geçirmeyi dar bir blast penceresine dönüştürür. Saniyeden kısa TTL'leri kullanamıyorsanız bile, tespit sonrası erişimi bir dakika içinde kesebilecek otomatik rotasyon ve iptal araçlarını uygulayın.

Vault desenleri: ajanlar sırları nasıl almalı

Sırları asla ajan çalışma zamanına ya da imajına gömmeyin. Broker tabanlı bir model kullanın:

• Talep üzerine alma: ajan, düşük ayrıcalıklı bir bootstrap kimliği (makine kimliği) ile bir vault'a kimlik doğrular, belirli bir secret kapsamını talep eder ve vault görev için kısa ömürlü bir kimlik bilgisi döner.
• Kalıcı gizli önbellek yok: dönen sırları diske yazmayın. Yalnızca bellekte tutun ve kullanım sonrası hemen silin.
• Brokeri denetleyin: vault, her mint operasyonu için ayrıntılı bir denetim kaydı (kim istedi, neden, TTL, amaç) üretmelidir.

Örnek: bir ajan uzak-destek oturumu başlatmalı. Destek aracına 5 dakika geçerli bir oturum tokenı talep eder, kullanır ve sonra vault tokenı süresinden önce geçersiz kılar. Ajan ele geçirildiğinde token süresi dolmuşsa, token işe yaramaz.

Ajanın asla bulundurmaması gerekenler — açıkça yasaklanan öğeler

Yasaklı sırlar konusunda açık olun. Belirsizlik istisnalara yol açar ve bunlar kalıcı hale gelir. En azından ajanın asla tutmaması gerekenleri yasaklayın:

• Kök veya operatör anahtarları (kök veritabanı kimlik bilgileri, bulut sağlayıcı kök anahtarları, uzun ömürlü servis hesabı anahtarları).
• TLS sunucu sertifikaları veya kod imzalama anahtarları için özel anahtar materyali — bunlar HSM'lerde veya ayrı imzalama servislerinde saklanmalıdır.
• Diğer vault verilerini şifreleyen göç ettirilmemiş vault anahtarları veya anahtar-şifreleme anahtarları.
• Kullanıcı parola veritabanları veya parola hashleri — ajanlar asla gizli verilerin toplu ihracat kanalı olmamalıdır.
• Prod, staging, yedeklemeler arasında yanal harekete izin veren kapsamsız yönetici API tokenları.

Yasaklı listeyi tehdit modelinizin ve kod inceleme kontrol listenizin parçası yapın. Bir geliştirici diske kimlik bilgisi kaydeden bir kolaylık önerdiğinde, kod inceleyicisi listeyi gösterip değişikliği reddedebilmelidir.

Operasyonel kontroller: onaylar, denetim ve hızlı iptal

Politikalar ve tasarım gerekli ama yeterli değildir. Operasyonel kontroller tasarımları savunulabilir sistemlere dönüştürür.

• Onay kapıları: hassas işlemler için insan onayları gerektirin. Politika tabanlı onaylar kullanın (ör. işlem prod hedefliyorsa 2 mühendisin onayı gereksin). Desenler ve akış diyagramları için AI otomasyonu için onay kapıları'na bakın.
• Kapsamlı denetim kayıtları: ajan kimliğini, kullanıcı bağlamını, tam API çağrılarını veya uzak-oturum hedeflerini, mint edilen tokenları (gizli değeri olmadan) ve işlem sonucunu kaydedin. Olay incelemesi için logları en az 90 gün saklayın.
• Telemetri ve davranışsal alarmlar: alışılmadık ajan davranışını izleyin (alışılmadık uç noktalar, ani hacim sıçramaları veya mesai dışı çağrılar).
• Hızlı iptal yolları: otomatik kesme anahtarları için pipeline oluşturun — ajanın tüm aktif tokenlarını geçersiz kılan tek bir iptal API'si ve örnekteki örneği izole etmek için bir oyun kitabı (playbook) hazırlayın.

Denetim ayrıntıları için AI agent denetim log gereksinimleri'ne bakın. Loglar hem insan tarafından okunabilir hem de makine tarafından aranabilir olmalı, böylece "ajanı X yapması için kim yönlendirdi" sorusunu birkaç dakika içinde yanıtlayabilirsiniz.

Örnek kapsam politikası (gösterim amaçlı)

{
  "Version": "2024-01-01",
  "Statement": [
    {"Effect": "Allow", "Action": ["metrics:Read"], "Resource": ["arn:svc:metrics:env:app/*"]},
    {"Effect": "Deny",  "Action": ["db:Admin", "kms:Decrypt"], "Resource": ["*"]}
  ]
}

Yukarıdaki snippet gösterim amaçlıdır: salt okunur metrik erişim haklarını herhangi bir admin veya KMS deşifre yetkisinden ayırın. Pratikte kimlik sağlayıcınızın yerel politika dilini kullanın ve token mint anında görev başına bir politika üretin.

Dağıtım tercihleri: yönetilen relay vs kendi kendine barındırma ve Tenvo'nun yaklaşımı

Ajana nerede çalıştırdığınız ve trafiğin nasıl relay edildiği önemlidir. Yönetilen hizmetler operasyonel yükü azaltır ancak güven modeline üçüncü taraf bir operatör ekler. Kendi kendine barındırma yalnızca yazılı bir gereksiniminiz (veri ikametgahı, uyumluluk veya izole ağ) olduğunda doğrudur. Çoğu ekip için on-call, yamalama, sertifika yenileme ve anahtar saklama maliyetlerini hesaba kattığınızda yönetilen relay daha ucuzdur.

Tenvo, varsayılan öneri olarak çok bölgeli bir yönetilen relay sunar. Önemsemeniz gereken özellikler: macOS/Windows/Linux için yerel istemciler, genel betada bir tarayıcı istemcisi, failover ile çok bölgeli yönetilen relay ve Free $0 / Lite $2.99/mo / Pro $7.99/mo fiyat katmanları. Yönetilen relay yüksek erişilebilirlik ve sertifika yönetimini sadeleştirir ama unutmayın: trafik relaya düştüğünde TLS relay'de sonlanır, dolayısıyla relay operatörü oturum verilerine erişebilir. Bu herhangi bir relay tabanlı ürün için geçerlidir ve tehdit değerlendirmenizin bir parçası olmalıdır.

Eğer bir uyumluluk kuralı üçüncü taraf altyapısını yasaklıyorsa, bu gereksinimi belgeleyin ve sonra kendi kendinize barındırın: relay'i en az iki bölgede çalıştırın, sertifika yenilemeyi otomatikleştirin ve bir iptal yolu oluşturun. Kendi kendine barındırma takaslarıyla ilgili rehberlik için Self-Hosted Remote Desktop: Why, How, and What Breaks'e bakın.

Uzaktan kontrol araçlarıyla entegrasyon ve güvenli oturum politikaları

Bir ajan uzak masaüstleriyle etkileşim kurduğunda veya bakım betikleri çalıştırdığında oturum aracılığı (session mediation) ve açık onaylar kullanın. Uzak masaüstü oturumları için: tek bir makine ve tek bir operatöre scope edilmiş geçici bağlantı tokenları verin, ayrıcalıklı kimlik bilgilerini ajanın üzerinden geçirmekten kaçının ve izin verildiği yerde oturum başlangıç/bitişini ve tuş vuruşu özetlerini kaydedin.

İş akışınız Tenvo veya benzeri araçları içeriyorsa, zaman sınırlı oturumlar oluşturmak için ürünün session-token API'larını kullanın ve hassasiyet eşiğinin üzerindeki oturumlar için isimli bir onaylayıcı gerekli kılın. Uzak oturumların ajan tarafından kontrolü hakkında yazımız için AI agent remote desktop: policies, approvals, audit'a bakın.

Olay müdahalesi: bir ajan ele geçirmesini nasıl sınırlarsınız

İzole etme playbook'ları basit ve prova edilmiş olmalıdır. Temel adımlar:

• Ajan kimliğiyle ilişkili tüm tokenları ve broker tarafından yeni oluşturulmuş kimlik bilgilerini global iptal API'si ile iptal edin.
• Host'u izole edin (ağ ACL'leri) ve adli analiz için belleğin anlık görüntüsünü alın.
• Ajanın delege erişimi olan aşağı akış sırlarını döndürün/rotasyon yapın; yüksek etkili anahtarlardan başlayın (DB admin, bulut admin).
• Ajanın aktif TTL'si sırasında yanal hareket için denetim loglarını arayın. Tokenlar kısa ömürlü olduğundan, inceleme kapsamınız daha dar olmalıdır.

Playbook'u üç ayda bir uygulamalı olarak prova edin. İlk gerçek olay eksiklikleri ortaya çıkarır; tatbikatlar bu eksikleri bir başkası ortaya çıkarmadan kapatır.

Etkili AI ajan güvenliği savunmacı tasarım, operasyonel olgunluk ve altyapı hakkında dürüst güven kararlarının birleşimidir. Sırları kısa, kapsamlı, broker aracılı ve denetlenebilir kılın; kök anahtarları ajan belleğinden yasaklayın; yüksek riskli eylemler için onaylar zorunlu tutun; ve relay operatörünü tehdit modelinize eklemeden yönetilen altyapıyı seçmeyin.

Agent-dostu uzak oturumları ve token iş akışlarını test etmeye hazır mısınız? Tenvo'yu indirin ve Free $0, Lite $2.99/mo veya Pro $7.99/mo planlarıyla yönetilen relay'i deneyin: Tenvo'yu İndir.