Dizin yetkisi bir erişim ayarı değil, bir mimari karardır

Tez#

Kurumsal geri getirmeli sistemlerde yetki sorusu genellikle geç soruluyor. Önce dizin kuruluyor, arama çalışıyor, cevaplar iyi görünüyor; sonra bir gözden geçirmede "bu kullanıcı bu belgeyi görmemeli" sorunu ortaya çıkıyor. Bu noktada en hızlı çözüm cevabın altındaki kaynak listesini filtrelemek gibi görünüyor.

Bu çözüm yetki sağlamıyor. Model, filtrelenen belgeyi okumuş ve cevabını ondan beslemiş durumda; kaynak listesinden çıkarılan şey belgenin içeriği değil, ona yapılan atıf. Kullanıcı görmemesi gereken bilgiyi görmüş oluyor, üstelik nereden geldiğini bilmeden — yani doğrulama imkânı da olmadan. İkinci sorun tutarlılık: yetkisiz kaynaklar ayıklandığında cevabın bir bölümü dayanaksız kalıyor ve sistem, kendi gösterdiği kaynaklarla desteklenmeyen iddialar üretiyor. Bu, güven açısından sızıntıdan bağımsız ikinci bir hasar.

Bağlam: yetkinin uygulanabileceği dört nokta#

Yetki akışın dört farklı yerinde uygulanabiliyor ve dördü aynı korumayı sağlamıyor. Tablo, her noktanın neyi koruduğunu ve neyi kaçırdığını ayırıyor.

Birinci satırdaki tuzak pratikte sık yaşanıyor. Yetki etiketleri dizinleme anında gömüldüğünde, bir kullanıcının yetkisi değiştiğinde ya da bir belgenin gizlilik sınıfı güncellendiğinde dizin geride kalıyor. Bu yüzden etiketler dizinde tutulsa bile yetki çözümlemesi sorgu anında yapılmalı: dizin "bu belge şu gruplara ait" bilgisini taşır, "bu kullanıcı şu gruplarda" bilgisi sorgu anında okunur.

Kanıt: sorgu içi yetkinin gerektirdikleri#

Yetkiyi sorgunun içine taşımak bir anahtar açıp kapatmak değil; belirli bir veri modeli ve belirli kararlar gerektiriyor.

• Parça düzeyinde etiket: yetki belge düzeyinde değil parça düzeyinde tutulmalı. Bir belgenin bazı bölümleri daha kısıtlı olabiliyor.
• Grup üyeliğinin sorgu anında çözülmesi: dizinde kullanıcı kimliği değil grup etiketi durmalı; üyelik değişimi dizini geçersizleştirmesin.
• Boş sonuç davranışı: kullanıcının yetkili kümesinde hiç sonuç yoksa sistem ne diyor? "Bilgi yok" ile "erişiminiz yok" farkı kendi başına bilgi sızdırabiliyor.
• Yetki değişiminin gecikmesi: bir yetki kaldırıldığında dizin ne kadar sürede yansıtıyor? Bu gecikme yazılı olarak bilinmeli.
• Önbellek ayrımı: geri getirme sonuçları önbelleğe alınıyorsa önbellek anahtarı yetki kümesini içermeli; yoksa bir kullanıcının sonucu başkasına dönebilir.
• Denetim kaydı: hangi kullanıcı hangi parçaya erişti? Bu kayıt olmadan bir sızıntı incelemesi yapılamıyor.

Beşinci madde en sessiz ve en ciddi hata kaynağı. Geri getirme sonuçlarını önbelleğe almak makul bir optimizasyon ama önbellek anahtarı yalnızca sorgu metnini içeriyorsa, aynı soruyu soran iki farklı yetkili kullanıcı aynı sonucu alıyor — yani düşük yetkili kullanıcı, yüksek yetkili kullanıcının sonucunu görebiliyor. Bu hata testlerde görünmüyor çünkü tek kullanıcıyla yapılan testlerde ortaya çıkmıyor.

Mekanizma: gömme uzayı yetki bilmez#

Sorunun kökü, vektör aramanın doğasında. Gömme uzayında yakınlık anlamsal benzerliğe göre belirleniyor ve bu uzay yetki hakkında hiçbir şey bilmiyor. Bir kısıtlı belge, sorguya en yakın komşu olabiliyor.

Bu yüzden yetki, benzerlik aramasının bir parçası olarak değil bir ön kısıt olarak uygulanmalı: arama yalnızca yetkili altkümede yapılmalı. Uygulamada bu, vektör veritabanının meta veri filtrelemesini arama sırasında desteklemesini gerektiriyor — sonuçları getirip sonra filtrelemek değil. İkisi arasındaki fark yalnızca güvenlik değil kalite: en yakın yüz komşuyu getirip yetkiye göre eleyince elinizde beş parça kalabiliyor ve cevap beş parçayla üretiliyor. Oysa yetkili altkümede yapılan bir arama, o altkümenin en iyi yüz parçasını getiriyor. Aynı yetki kuralı, iki tümüyle farklı cevap kalitesi üretiyor ve bu fark, kısıtlı kullanıcılarda sistemin işe yaramaz görünmesinin en sık nedeni.

Karşı görüş#

Üç itiraz yerinde. Birincisi: sorgu içi yetki filtrelemesi arama performansını düşürüyor ve bazı vektör depoları bunu verimli yapamıyor. İkincisi: kurumsal yetki modelleri karmaşık ve dizine taşınamıyor; miras alınan izinler, istisnalar, zaman kısıtları var. Üçüncüsü: çoğu iç kullanımda herkes her şeyi görebiliyor ve bu karmaşıklık gereksiz.

Yetkiyi sonradan filtreliyorduk. Bir iç denetimde soruldu: model kısıtlı belgeyi okudu mu? Okumuştu. Kaynak listesinde görünmüyordu ama cevabın içindeydi. O gün mimariyi değiştirdik.

Birinci itiraz gerçek bir kısıt ve depo seçimini belirliyor: sorgu anında meta veri filtrelemesi yapamayan bir depo, kurumsal yetki gerektiren bir kullanım için uygun değil — bu bir yapılandırma değil seçim kriteri. İkinci itiraz da doğru ve çözümü yetki modelini dizine taşımak değil, sorgu anında çözülen bir grup kümesine indirgemek: karmaşık kurallar kimlik tarafında değerlendirilip sonuç olarak bir etiket listesi üretiyor, dizin yalnızca o listeyi biliyor. Üçüncü itiraz en tehlikeli olanı çünkü bugünün durumunu kalıcı sayıyor: herkesin her şeyi gördüğü bir iç kullanımda bile ilk hassas kaynak eklendiğinde mimari değişikliği gerekiyor ve o noktada dizin yeniden kurulmak zorunda kalıyor.

Sınırlar ve belirsizlik#

Bu analiz belirli bir vektör deposu ya da yetki modeli önermiyor.

• Performans etkisi depoya bağlı: sorgu içi filtrelemenin gecikme maliyeti uygulamadan uygulamaya değişiyor.
• Parça düzeyi etiketleme maliyeti ölçülmedi: belge içi gizlilik sınıfı çıkarımı her belge türü için otomatikleştirilemiyor.
• Boş sonuç davranışının doğru biçimi bağlama bağlı: bazı durumlarda erişim olmadığını söylemek gerekiyor, bazılarında bu bilgi bile sızıntı.
• Yetki gecikmesi için kabul edilebilir eşik kurumsal bir karar; teknik bir tablodan çıkmıyor.

Sonuç#

Geri getirmeli sistemlerde yetki, bir erişim ayarı gibi sonradan takılamıyor. Cevap üretildikten sonra yapılan filtreleme içeriği değil atfı kaldırıyor; kullanıcı görmemesi gereken bilgiyi kaynağını bilmeden görüyor ve cevap kendi gösterdiği kaynaklarla desteklenmez hâle geliyor.

Doğru yer geri getirme sorgusunun kendisi: arama yalnızca kullanıcının yetkili altkümesinde yapılmalı. Bu, hem sızıntıyı kapatıyor hem cevap kalitesini yükseltiyor — çünkü elenen sonuçlarla değil, yetkili kümenin en iyi sonuçlarıyla üretim yapılıyor. Kararın mimari olmasının nedeni de bu: vektör deposu seçimi, dizin şeması ve önbellek anahtarı buna göre belirleniyor ve üçü de sonradan değiştirilmesi pahalı kararlar.

Ne yapmalı?#

1. 1Yetkiyi sorgu filtresine taşıyın

   Arama yetkili altkümede yapılmalı. Getirip sonra elemek hem sızdırıyor hem kaliteyi düşürüyor.

2. 2Dizine grup etiketi yazın, kullanıcı değil

   Üyelik sorgu anında çözülsün; yetki değişimi dizini geçersizleştirmesin.

3. 3Etiketi parça düzeyinde tutun

   Bir belgenin bazı bölümleri daha kısıtlı olabiliyor; belge düzeyi etiket bunu kaçırıyor.

4. 4Önbellek anahtarına yetki kümesini ekleyin

   Yoksa bir kullanıcının sonucu başkasına dönüyor ve bu hata tek kullanıcılı testlerde görünmüyor.

5. 5Boş sonuç davranışını tanımlayın

   "Bilgi yok" ile "erişiminiz yok" farkı kendi başına bilgi sızdırabiliyor.

6. 6Parça düzeyinde denetim kaydı tutun

   Hangi kullanıcı hangi parçaya erişti bilgisi olmadan sızıntı incelemesi yapılamıyor.