Sorun, verilen yetkinin kendisi
Apple'ın macOS Tam Disk Erişimi'ni (FDA) sıkılaştırması, gerçek bir başarısızlık moduna karşı makul bir yanıttır: bir agent framework'ü, bir terminal sarmalayıcısı veya bir arka plan yardımcısı, dar kapsamlı istek belirtmesi daha zor olduğu için mümkün olan en geniş okuma yetkisini talep eder. Sonuç, kullanıcının okuyabildiği her dosya üzerinde tek bir boolean'dır. Tek bir proje dizinine ihtiyaç duyan bir agent, tek bir yapılandırma dosyasına ihtiyaç duyan bir agent ile aynı yetkiyi alır. İzni vermek ucuzdur, ancak üzerinde akıl yürütmek pahalıdır.
Bütün mesele bu asimetridir. Bir yetki vermek tek bir diyalog penceresine mal olur. Üzerinde akıl yürütmek ise ona bağlı her iş akışının denetlenmesine mal olur, çünkü geri alma kapsamlı değildir: FDA'yı geri almak, aynı boolean'ı paylaşan ilgisiz iş akışlarını da geçersiz kılar. Operatörler de yetkiyi olduğu gibi bırakıp ortam altyapısı gibi muamele ederek yanıt verir; ki sıkılaştırmanın önlemeyi amaçladığı durum tam olarak budur.
Daha derin sorun, izin modelinin her okumada döngüde bir insan olmadan hareket eden agent'lardan önce tasarlanmış olmasıdır. Bir kişi bir dosyayı açtığında, provenance kişinin kendisidir. Bir agent bir görev adına bir dosyayı okuduğunda, provenance görevdir ve platformun bunu kaydedecek bir yeri yoktur. FDA size bir şeyin keychain'inizi okuduğunu söyleyebilir. Hangi görevin, hangi agent'ın okuduğunu ya da bu okumanın meşru olup olmadığını söyleyemez.
Kapsamlandırma ilkeli olarak veri sınıfları
Kalıcı çözüm, dosya sistemi genelinde bir yetkiyi agent yetkilendirmesinin birimi olarak görmeyi bırakmaktır. Bunun yerine okuma haklarını veri sınıfı başına kapsamlandırın. Bir veri sınıfı, aynı okuma politikasını paylaşan yol kümesidir, örneğin:
- credentials: keychain'ler,
.envdosyaları, SSH materyali, bulut sağlayıcı yapılandırması, tarayıcı kimlik bilgisi depoları - source trees: sürüm kontrolündeki çalışma kopyaları, monorepo checkout'ları, vendored bağımlılıklar
- personal communications: posta depoları, mesaj veritabanları, takvim ve kişi depoları
- build artefacts: derlenmiş çıktı, önbellekler, container katmanları, paket yöneticisi depoları
- system configuration:
/etc, launch agent'lar, ağ profilleri
Agent'lar bir yol değil, bir sınıf talep eder. Platform, yolları yetki verilirken sınıflara çözer ve okuma anında yeniden çözer. Bir build agent'ı source-trees ve build-artefacts talep eder; bir deployment agent'ı tek bir sağlayıcıyla kapsamlandırılmış credentials ve build-artefacts talep eder; bir özetleme agent'ı tek bir hesap için personal-communications talep eder. Talep, ~/Projects'in olmadığı bir biçimde bir insan gözden geçiren için okunabilirdir, çünkü konumu değil amacı belirtir.
Kritik özellik, sınıf üyeliğinin agent tarafından beyan edilmesi değil, platform tarafından hesaplanmasıdır. Eğer bir agent "bu yol bir build artefact'ıdır" diye iddia edebilseydi, bir sırrı dist/ içine yeniden adlandırmak taksonomiyi boşa çıkarırdı. Çözümleme; yol kalıplarını, dosya meta verisini, içerik sinyallerini ve soy hattını birleştirmelidir: bir kimlik bilgisi tutan süreç tarafından yazılan bir dosya, kopyalandıktan sonra bile kimlik bilgisine komşu sınıflandırmayı miras almalıdır. Yeniden adlandırılmış bir sır korunur, çünkü sınıfı şu anda bulunduğu yerden değil, nasıl var olduğundan türetilir.
Her okumada provenance
Kapsamlandırma tek başına, ne olduğuna dair bir kayıt olmadan yetersizdir. Her okuma olayı en az üç alan taşımalıdır:
{
"agent_identity": "build-runner@ci-7",
"task_id": "task-4f9c2a1e",
"resolved_class": "source-trees",
"path": "/Users/dev/work/api/src/main.rs",
"decision": "allow",
"policy_version": "2024-11-03"
}
Görev tanımlayıcısı, çoğu sistemin atladığı alandır ve denetim kayıtlarını yorumlanabilir kılan da odur. O olmadan, ~/.aws/credentials okumasını gösteren bir log satırı, meşru bir deployment adımından ve bir sızdırma yolundan ayırt edilemez. O olduğunda, bir operatör önemli bir soruyu sorabilir: hangi görevler kimlik bilgilerini okudu ve bunlardan herhangi biri aynı pencerede kişisel iletişimleri de okudu mu? Bu soru yalnızca görev tanımlayıcısı her okumada mevcutsa ve agent'ın giriş noktasından her tool call ve alt sürece yayılıyorsa yanıtlanabilir.
Çözümleme kararını loglamak, yolu loglamak kadar önemlidir. Politikanın artık credentials olarak sınıflandıracağı bir yol için resolved_class: source-trees diyen bir kayıt, bir sapma sinyalidir. Karar olmadan, politika değişiklikleri bir şey bozulana kadar görünmez olur. Karar olduğunda, sapma bir sorgu olarak tespit edilebilir: çözümlenen sınıfın mevcut sınıflandırıcıyla uyuşmadığı okumaları bulun.
Somut bir çözümleme mekanizması
Uygulanabilir bir implementasyonun üç aşaması vardır.
Sınıflandırma. Bir arka plan sınıflandırıcısı, yol kalıplarından ve soy hattı kayıtlarından sınıflara bir eşleme tutar. Dosya oluşturma, yeniden adlandırma ve içerik değişikliğinde
sürümünü kaydeder.
Çözümleme. Her okumada, agent runtime'ı talep edilen sınıfı sınıflandırıcının güncel görünümüne karşı çözer. Yolun hesaplanan sınıfı agent'ın verilmiş kümesinde değilse, okuma yapılandırılmış bir gerekçeyle reddedilir: hesaplanan sınıf, politika sürümü ve gereken yetki.
Provenance yayımı. Runtime, yukarıdaki alanları içeren bir okuma olayını yalnızca eklenebilir bir sink'e yayar. Sink; görev, agent ve sınıfa göre sorgulanabilir ve sapma tespiti için zemin oluşturur.
İki ayrıntı, bunun pratikte işleyip işlemeyeceğini belirler. Birincisi, çözümleme okuma yolunda durabilecek kadar hızlı olmalıdır; inode ve politika sürümüyle anahtarlanmış bir önbellek genellikle yeterlidir ve sınıflandırma değişikliğinde geçersiz kılınır. İkincisi, ret eyleme dönüştürülebilir olmalıdır. computed_class: credentials, required_grant: credentials:aws-prod diyen bir ret, operatöre tam olarak neyi değiştirmesi gerektiğini söyler. permission denied diyen bir ret ise ona FDA vermeyi öğretir.
Bunun maliyeti
Dürüst ödünleşimler üç tanedir.
Gecikme ve bakım. Sınıf çözümlemesi okuma yoluna bir lookup ekler ve taksonomi bakım gerektirir. Alana özgü sınıflar, ekipler depolarını yeniden düzenledikçe sapar. Bakımı yapılmayan bir taksonomi, yanlış retlerin kaynağı haline gelir ve yanlış retler güveni geniş yetkilerden daha hızlı aşındırır.
Meşru retler. Agent'lar zaman zaman okumaları gereken okumalardan mahrum bırakılacaktır. Sınıflandırıcının kimlik bilgisine komşu olarak işaretlediği üretilmiş bir dosyayı okuyan bir build adımı başarısız olacaktır. Tasarım, bu redi sessiz olmaktan çıkarıp eyleme dönüştürülebilir kılmalıdır: hesaplanan sınıfı, politika sürümünü ve görevi açacak en dar yetkiyi ortaya koymalıdır. Sessiz ret, kaba yetkilerle aynı etrafından dolanma davranışını üretir.
Satıcı direnci. Platform satıcıları, alana özgü ve varsayılan olarak tanımlanması zor olduğu için sınıf taksonomilerini sunmaya direnecektir. Genel amaçlı bir işletim sistemi, bir ekibin fixtures/ dizininin sentetik veri, bir diğerininkinin üretim anlık görüntüleri içerdiğini bilemez. Gerçekçi yol, platform tanımlı küçük bir temel sınıf kümesi artı bir genişletme mekanizmasıdır; değerin çoğunun ve bakım yükünün çoğunun genişletmede yaşadığı bilinciyle.
Bunların hiçbiri bedava değildir ve hiçbiri eksiksiz bir yanıt değildir. Ancak yetkilendirmenin biriminde bir değişikliktir. FDA, bir agent'ın her şeyi okuyup okuyamayacağını sorar. Sınıf kapsamlı bir model ise bu agent'ın bu görevde hangi tür verileri okuyabileceğini sorar ve yanıtı kaydeder. Operatörlerin gerçekten yanıtlaması gereken soru ikincisidir ve mevcut modelin ifade edemediği de odur.