Doğrudan cevap
Bu kimlik türleri farklı aktörleri, yaşam döngülerini ve riskleri temsil eder. İnsan hesabı bir kişiye; servis hesabı insan dışı iş yüküne; service principal bir uygulama örneğine; managed identity bulut tarafından yönetilen iş yükü kimliğine; AI ajan kimliği ise amacı, sponsoru, araçları ve eylemleri ayrıca izlenmesi gereken ajana bağlanır.
Sade dille
Bir iş yerinde personel kartı, otomatik kapı sistemi kartı ve teslimat robotunun kimliği aynı kart olmamalıdır. Kimin ne yaptığını anlamak ve doğru yetkiyi vermek için her aktör ayrı tanınmalıdır.
Neden önemli?
Otomasyonu insan hesabıyla çalıştırmak sorumluluğu gizler, fazla yetki taşır ve kişi ayrıldığında sistemi bozar. Ajanı yalnız model adıyla tanımlamak da hangi somut ajan örneğinin ne yaptığını göstermez.
Karıştırma
- Kimlik, kimlik doğrulayıcı ve izin aynı şey değildir.
- Uygulama nesnesi ile service principal aynı nesne değildir.
- Managed identity, yönetilen bir kimlik türüdür; onu kullanan kaynakla ilişkisi ayrıca izlenir.
- AI ajanı, temel modelin kendisi değildir.
Ne yapmalısın?
- Her iş yükü ve yüksek etkili ajan için ayrı kimlik kullanın.
- İnsan hesabıyla arka plan otomasyonu çalıştırmaktan kaçının.
- Her kimliğe amaç, sahip veya sponsor, ortam ve yaşam döngüsü bağlayın.
- Uzun ömürlü statik sırlar yerine uygun olduğunda kısa ömürlü veya yönetilen kimlikleri tercih edin.
- Araç, model, runtime ve ajan kimliklerini ayrı kaydedin.
- En az yetki ve düzenli erişim incelemesi uygulayın.
Nasıl denetlersin?
- Kimliğin sınıfı doğru mu?
- İnsan dışı iş yükü insan hesabı kullanıyor mu?
- Sahip veya sponsor güncel mi?
- Statik anahtar gereksiz yere kullanılıyor mu?
- Ajanın model, araç ve runtime ilişkileri izlenebiliyor mu?
- Kimlik kapanınca bağlı izin ve sırlar da kapanıyor mu?
Sınır
Ürün terimleri sağlayıcıya göre değişir. NOMOS sınıfları ortak denetim dili önerir; Microsoft, Google veya AWS'nin bütün kimlik modellerini tek biçime indirgemez.
Tek cümlede hatırla
İnsan, uygulama, iş yükü ve ajan aynı kimliği paylaşırsa kimin ne yaptığı bulanıklaşır.
Bu kaydın kaynakları
- S24NIST SP 800-63-4, *Digital Identity Guidelines*Standart
- S25NIST SP 800-63B-4, *Authentication and Authenticator Management*Standart
- S29Microsoft Learn, *Application and Service Principal Objects in Microsoft Entra ID*Sağlayıcı
- S30Microsoft Learn, *Managed Identities for Azure Resources*Sağlayıcı
- S31Google Cloud, *Identities for Workloads*Sağlayıcı
- S32AWS IAM, *Temporary Credentials with AWS Resources*Sağlayıcı