“İki hafta yeter, sonra kapatırız.” Bu cümle hiçbir kurumda kötü niyetle kurulmaz. Danışman ekibi gelmiştir, entegrasyon testi başlamıştır, bir pano toplantıda paylaşılmıştır. Üçü de makul.
Tek tek bakıldığında bu erişimlerin hiçbiri sorun değil. Sorun toplamları. Üç yıl sonra kimsenin açıklayamadığı kullanıcı listesi, bu makul kararların üst üste binmesinden oluşur.
Asimetri şurada: açmak bir kişinin birkaç dakikasını alır, kapatmak ise hatırlamayı, sahiplenmeyi ve bir kontrol adımını gerektirir. Zamanla açılan tarafın kazanması bu yüzden kaçınılmaz görünür.
Bedeli de gecikmeli çıkıyor: bir denetimde, bir devir teslimde ya da kullanıcı listesi ilk kez baştan sona okunduğunda. O gün soru artık “bu erişim gerekli mi?” değil, “bunu kim, ne zaman, neden açtı?” oluyor — ve cevabı arayan ekip genellikle o kararı veren ekip değil.
Üç kanalın kapanma davranışı farklı
- BI paylaşım bağlantısı. Geçerlilik süresi verilebilir ve gerektiğinde iptal edilebilir. Ancak bağlantı, paylaşan kullanıcının satır yetkilerini devralmaz; kapsamı yayımdan önce test etmek gerekir.
- API servis erişimi. Kullanıcı ataması, izin verilen IP listesi ve istek limitleriyle sınırlandırılabilir. Fakat servis kullanıcısının süresi kendiliğinden dolmaz; kapatmak açan ekibin işidir.
- SAP rolü. AccessGuard rol ve yetki verisini senkronize eder, tanımlı kurallarla karşılaştırır ve bulgu üretir. Erişimi kendisi kaldırmaz; rolün geri alınması kurumun yetki sürecinde yürür.
Bu fark planlamayı değiştirir. Süre verilebilen tek kanal için takvim yeterli; diğer ikisi için bir sorumlu adı gerekir.
Erişimi açarken yazılacak dört bilgi
- Kim için açıldı.
- Hangi veri kapsamı verildi.
- Hangi tarihe kadar gerekli.
- Kapatmaktan kim sorumlu.
Dördüncüsü en çok atlanan satır ve sonraki temizliği mümkün kılan tek satır. Sorumlusu olmayan bir erişim, süresi yazılmış olsa bile kapanmıyor.
Bu dört satırın nerede durduğu önemli değil: bir talep kaydı, bir tablo ya da proje dosyası fark etmez. Önemli olan biçimi değil, altı ay sonra aranabilir olması.
Kapsamı daraltmak geri almayı küçültür
İş ortağına tüm görünüm klasörünü açmak yerine ihtiyaç duyduğu tek görünümü vermek, proje bittiğinde geri alınacak şeyi küçültür. Aynısı servis tarafında da geçerli: bir servise gereğinden fazla alan açmak, kapatma kararını da zorlaştırır.
Dar kapsamın ikinci faydası daha az konuşuluyor. Erişimin ne işe yaradığını altı ay sonra hatırlamak, kapsam dar tutulduğunda çok daha kolay.
Proje kapanışına eklenecek üç madde
- Paylaşım bağlantılarını iptal edin.
- Servis kullanıcısını devre dışı bırakın.
- Rol durumunu bir sonraki AccessGuard taramasında yeniden inceleyin.
Üçüncüsü genellikle sürpriz üretir. Kaldırıldığını düşündüğünüz bir yetkinin hâlâ durduğunu orada görürsünüz — ve bu, kimsenin ihmali olmadan da oluşabilir; rol ataması başka bir talep üzerinden geri gelmiş olabilir.
Süre koymak kurumun hesap kapatma sürecinin yerine geçmez. Ama erişimin ne zaman ve neden açıldığını kaydetmek, altı ay sonra “bu kullanıcı neden var?” sorusuna cevap verebilmenin en ucuz yolu.
Şöyle bir egzersiz önerelim: geçen yıl kapanmış bir projeyi seçin ve o proje için açılan erişimlerin bugün hangi durumda olduğunu birlikte çıkaralım. Tek bir proje, çoğu zaman sürecin tamamı hakkında yeterince şey söylüyor.