Önce sonucu tanımlamak
Erişim kontrolü iş sorusuyla başlar: kim, hangi kayda, hangi koşulda, ne yapabilir? Rol isimleri listesi yeterli değildir. Eylemleri, sahiplik sınırlarını ve istisna yetkisini belirleyin. Kaydı okumak, değiştirmek, dışa aktarmak ve erişim vermek farklı güçlerdir.
Uygun yaklaşımı seçmek
Küçük iç uygulamaya basit rol modeli uyabilir. Kayıt sahipliği, şirket üyeliği veya akış durumu ek kontrol gerektirebilir. Birkaç özellik kuralı daha açık anlatıyorsa her birleşime yeni rol oluşturmayın. OWASP varsayılan reddi ve her istekte yetki kontrolünü önerir; düğmeyi saklamak uygulanan güvenlik sınırı değildir.
Somut kaydı karşılaştırmak
Örnek partner portalında hesap sorumlusu kendi şirketinin siparişlerini okur, finans kullanıcısı fatura indirir. Doğrudan indirme ve arama dâhil her eylemi başka şirketin kayıt kimliğiyle deneyin. Sonra tarayıcısı açık kullanıcının şirket üyeliğini kaldırın. Sonraki korumalı istek, önceden yüklenen ekranı değil yeni kararı uygulamalı.
Kanıtı kullanılabilir tutmak
Sorun incelemek kolay olsun diye desteğe kalıcı sınırsız erişim vermeyin. İstisna gerekiyorsa neden, süre ve kayıt tanımlayın. Toplu aktarım, arka plan işleri ve entegrasyon kimliklerini de ekranlar kadar inceleyin. Yetki tablosu ancak çalıştırılan kontrole ve olumsuz teste dönüşürse işe yarar.
Matrisi eylem ve sınırdan kurun
Her anlamlı eyleme satır, role sütun açıp kayıt sınırını yazın. Yalnız atandığı kuruluşun siparişini okuma şartı sonradan hatırlanacak not değil yetkinin parçasıdır. Arama, indirme, aktarım, arka plan işi ve başkasına yetki verme de kapsansın. Düzenlemeyi koruyup dışa aktarımı unutmak aynı kayıtları açabilir.
Yetkinin yaşam döngüsünü izleyin: davet, kuruluş doğrulama, rol değiştirme ve kaldırma. İkinci kişi gerektiren değişimleri ve acil erişimin bitişini belirleyin. Günlük operasyonu yürütme yetkisiyle uygulamanın yönetici yetkilerini birbirinden ayırın. Satın alma onaylayanın kimlik ayarı veya başka şirket kaydına erişmesi kendiliğinden gerekmez. Entegrasyon kimliklerini görevleriyle sınırlandırıp sahip ve iptal yolu verin.
Matrisi olumlu ve olumsuz örneğe dönüştürün: izinli kayıt, aynı rolde başka kuruluş, kaldırılmış üyelik ve ekranı atlayan doğrudan istek. Seçimle yürütme arasında yetki değişebileceğinden toplu ve kuyruk işlerinde tekrarlayın. Kişisel veri içeren istek gövdesini bütünüyle kopyalamadan, hassas işlemi kimin yetkilendirdiği anlaşılabilsin. Operatöre bu kanıtla reddi inceletin. Ret sınırı korurken meşru kullanıcıya düzeltme yolu vermeli, başkasının kaydını açıklamamalı.
Yetki kabul örnekleri
| Durum | Beklenen sınır |
|---|---|
| Aynı rol, farklı kuruluş | Rol benzerliği diğer kuruluşun kayıt, arama ve eklerine erişim vermez. |
| Açık oturumda üyelik kaldırılır | Sonraki işlem eski kontrolden değil güncel yetkiden karar verir. |
| Kendi yetkisini artırma girişimi | Onay kuralı uygulanır; sessiz güç vermeden girişim izlenebilir kalır. |
| Erişim değişince kuyruktaki aktarım çalışır | Eski seçim var diye dağıtmaz; kararlaştırılmış yetki politikasını uygular. |
Sorumluya sorulacaklar
Erişimi kim verir, kaldırır? Biri kendi yetki artışını onaylayabilir mi? Aynı rolde bile hangi kayıtlar ayrı kalmalı? Rol-eylem-kayıt matrisi ve reddedilen iş örnekleri getirin. İzin verilmeyenler, verilenler kadar konuşulmaya değer.