Sınırlamanın Birbirine Karıştırdığı İki Soru
Sınırlama dar ve mekanik bir soruyu yanıtlar: bu süreç neye dokunabilir? Yetkilendirme farklı bir soruyu yanıtlar: bu eylem devredilen yetki alanı içinde miydi? Bunlar aynı soru değildir ve bir işletim sistemi zorlayıcısı ikinciyi yanıtlayacak donanıma sahip değildir.
Windows Execution Containers gibi ana makine düzeyinde bir ilkel yapı ya da üzerine inşa edildiği daha eski Job Object ve AppContainer mekanizmaları, syscall'lar, handle'lar, token'lar ve SID'ler üzerinde çalışır. Bir dosya handle'ı, bir registry anahtarı, bir ağ soketi, bir bellek tahsisi talep eden bir süreç görür. Niyeti, görev kapsamını, kullanıcı onayını ya da bir agent'ın atanmış çalışma alanı içindeki bir belgeyi meşru biçimde düzenlemesi ile aynı agent'ın bir prompt injection yönlendirmesiyle o belgeyi sızdırması arasındaki farkı görmez. Çekirdeğin "bu eylem yetki alanı içindeydi" diye bir temsili yoktur. Yalnızca "bu handle verildi ya da reddedildi" temsili vardır.
Bu ayrım önemlidir çünkü teslim baskısı altındaki ekipler bunu sıklıkla birbirine karıştırır. Bir sandbox yapılandırılır, sandbox bir dizin dışındaki yazmaları engeller ve ekip yönetişimin halledildiği sonucuna varır. Aslında inşa edilen şey bir izolasyon sınırıdır. Yetkilendirmenin denetim izi — kimin neyi, hangi görev altında, hangi veri sınıflarıyla onayladığı — artık sandbox yapılandırmasında ya da daha kötüsü hiç kimsenin katmanında değil, hiçbir yerde yaşamaktadır. Bir olay incelemesi, bir agent'ın okumaması gereken bir müşteri kaydını neden okuduğunu sorduğunda, yanıt sınırlama günlüğünde değildir. Sınırlama günlüğü yalnızca bir okumanın başarılı olduğunu gösterir.
Sınırın Gerçekte Nerede Durduğu
İki katmanın güçlü yönleri zıttır. Çekirdek düzeyindeki ilkel yapılar izolasyonda güçlü, anlambilimde zayıftır. Bir container, bir sürecin C:\\Windows\\System32 dizinine yazmasını, ham bir soket açmasını ya da token'ını miras alan bir alt süreç doğurmasını güvenilir biçimde engelleyebilir. Size sürecin bu şeyleri yapması gerekip gerekmediğini söyleyemez. Politika motorları bunun tersidir: anlambilimde güçlü, zorlamada zayıf. Bir politika motoru "bu agent, invoice-reconcile-4417 görevi için finans veri sınıfına kapsanmış, on beş dakika içinde sona erecek bir yetkiye sahip" ifadesini değerlendirip bir satıcı defteri okumasının kapsam içinde olduğuna karar verebilir. Tek başına bir syscall'ı durduramaz. Politika motoru atlanırsa ya da olay sonrasında danışılırsa, yazma çoktan gerçekleşmiştir.
Bu nedenle aralarındaki arayüz, önem taşıyan tasarım yüzeyidir. Statik bir izin listesi — sandbox'ın izin verdiği sabit bir yol ve ana makine kümesi — yanlış biçimdir, çünkü görev kavramı, sona erme süresi ve aynı agent'ın farklı işler için farklı haklara sahip olması gerektiğini ifade etme yolu yoktur. Doğru biçim, imzalı bir yetenek grant'ıdır: politika katmanı tarafından verilen, zorlama katmanına sunulan ve kullanım noktasında doğrulanan yapılandırılmış bir token. Bir grant en azından bir görev tanımlayıcısı, bir kapsam (hangi veri sınıfları, hangi yollar, hangi ağ hedefleri), bir sona erme süresi ve bir terminal durumu taşır. Zorlama katmanı imzayı ve kapsamı kontrol eder; yetki alanını yeniden yorumlamaz.
Bu, işletim sistemlerinin onlarca yıldır kullandığı yetenek modeline yakındır ve agent iş yüklerine uygulanmıştır. Politika katmanı yeteneklerin vericisi olur; işletim sistemi katmanı referans monitörü olur. Hiçbiri tek başına yeterli değildir.
Katmanlı Sınırlama için Tasarım Kuralları
Her grant görev kapsamı, veri sınıfları ve bir terminal durumu taşır. "Bu agent D:\\data okuyabilir" diyen bir grant, grant değildir; kalıcı bir açıklıktır. "invoice-reconcile-4417 görevi, finance-vendor-ledger veri sınıfını 14:32 UTC'ye kadar okuyabilir, sonrasında yetenek iptal edilir ve süreç sonlandırılır" diyen bir grant denetlenebilirdir. Terminal durumu kapsam kadar önemlidir: görevini bitiren bir agent canlı bir yeteneği elinde tutmamalıdır, çünkü elinde eski bir grant bulunan ele geçirilmiş ya da
İşletim sistemi katmanında varsayılan olarak reddet; politika katmanında istisna yoluyla yetkilendir. Container, dosya sistemi, ağ ya da cihaz erişimi olmadan başlamalı ve yetenekleri yalnızca grant arayüzü üzerinden almalıdır. Politika katmanı da bir reddetme duruşundan başlamalı ve grant'ları yalnızca bir görev tanımı, bir veri sınıflandırma etiketi ve bir kullanıcı ya da servis onay kaydı hizalandığında vermelidir. Bu, sandbox'ın izin verici ve politika katmanının bir günlükleme sonradan düşüncesi olduğu yaygın kalıbı tersine çevirir.
Grant'ı ve zorlama kararını ayrı ayrı günlükle. Bunlar iki farklı sahibi olan iki farklı olaydır. Grant günlüğü, politika katmanının W onay kaydının yetkisiyle X görevi, Y kapsamı, Z sona erme süresi için bir yetenek verdiğini kaydeder. Zorlama günlüğü, işletim sistemi katmanının bu yetenek altında belirli bir handle isteğine izin verdiğini ya da reddettiğini kaydeder. Bir olay meydana geldiğinde, grant günlüğü "bu yetkilendirilmiş miydi?" sorusunu, zorlama günlüğü ise "sınır tuttu mu?" sorusunu yanıtlar. Bunları tek bir akışta birleştirmek, bir başarısızlığı politika katmanına ya da zorlama katmanına atfetme yeteneğini kaybettirir ki bu, bir inceleme sırasında tam olarak ihtiyaç duyduğunuz atıftır.
Dürüst Ödünleşim
Katmanlı sınırlama gecikme ve karmaşıklık maliyeti getirir. Her yetenek kontrolü politika katmanına bir gidiş-dönüş ya da imzalı bir token'a karşı bir doğrulamadır ve her görev, verme, yenileme ve iptal içeren bir grant yaşam döngüsüne ihtiyaç duyar. Bunu atlayıp tek bir izin verici sandbox'a güvenen ekipler daha hızlı teslim eder ve bir süre işliyor gibi görünür. Başarısızlık modu dramatik bir ihlal değildir; kimsenin sayamadığı kalıcı izinlerin yavaş yavaş birikmesi ve ardından sınırlama günlüğünün eksiksiz, yetkilendirme kaydının boş olduğu bir olaydır.
Rahatsız edici kısım şudur: işletim sistemi zorlayıcısı yetkilendirmeye asla karar veremeyecektir, çünkü yetkilendirme insan niyeti ve örgütsel yetki alanı hakkında bir ifadedir ve çekirdeğin ikisine de erişimi yoktur. Yapabileceği en iyi şey, başka bir yerde verilen bir kararı sadakatle ve hızlı biçimde uygulamaktır. İki katman arasındaki arayüzü tasarlamak — grant biçimi, doğrulama noktası, iptal yolu, ayrı günlükler — asıl mühendislik işidir. Sandbox'ı yönetişim kontrolü olarak ele almak, denetim izini politika katmanından çıkarıp kimsenin incelemediği bir yapılandırma dosyasına taşıyan kısa yoldur.
Yararlı bir test: sisteminizin bugün izin verdiği herhangi bir agent eylemini seçin ve iki soru sorun. Hangi katman bunun izin verildiğine karar verdi ve hangi katman bunu mümkün kıldı? Eğer aynı katman her ikisini de yanıtlıyorsa, sınır katmanlı değildir ve bir sonraki olay incelemesi, yetkilendirmeyi taşımak için hiç tasarlanmamış zorlama günlüklerinden yeniden inşa etmek zorunda kalacaktır.