Çoğu kurumda yetki incelemesi bir fotoğraf çekme işidir. Veri dışarı alınır, bir hafta incelenir, rapor yazılır, dosyalanır. Fotoğraf çekildiği gün doğrudur.
Bir ay sonra kısmen geçersizdir. Roller değişmiş, yeni kullanıcılar açılmış, birine iki haftalığına verilen yetki hâlâ duruyordur. Rapor yanlış değildi; sadece artık o sistemi anlatmıyor.
Buradaki yanlış alışkanlık raporu üretmek değil, raporu bir sonuç sanmak. Yetki riski bir durum değil, bir değişim hikâyesidir; tek karede okunmaz.
Senkronizasyonu gruplara bölmek
AccessGuard, SAP kullanıcı, rol, rol-yetki, kullanıcı-rol ve profil verisini yerel tablolara senkronize eder. Bu iş tek parça değil: kullanıcılar, roller, atamalar, profiller, statik katalog ve risk taraması ayrı ayrı çalıştırılabilir.
Pratikte işe yarayan ayrım şu: katalog verisi seyrek, kullanıcı ve atama verisi sık yenilenir. Senkronizasyon işleri görev altyapısı üzerinden zamanlanır; ilerleme ve durum kaydı tutulur.
Buradaki tek gerçek risk, bir senkronizasyonun sessizce başarısız olması ve incelemenin eski veriyle yapılmasıdır. Bu yüzden bir bulguya bakarken altındaki verinin tarihine de bakın.
Kullanıcı deltası ile rol değişikliği aynı yoldan gelmez
Tam senkronizasyonun yanında, kullanıcı değişiklikleri için USRSTAMP damgasına bakan bir delta yolu var. Rol tarafındaki değişiklikler ise AGR_TIMEB üzerinden ayrı bir olay ve yoklama akışında ele alınır.
Bunu bilmek beklentiyi doğru kurar: tek bir genel delta mekanizması bütün değişiklik türlerini kapsamıyor. Rol değişikliklerinin ne sıklıkla görünür olacağına siz karar veriyorsunuz, bu bir zamanlama kararı.
İki tarama arasındaki fark neyi söyler?
Bir taramadan çıkan dört yüz bulgu yönetilemez. Aynı kümenin bir önceki taramaya göre farkı yönetilebilir: hangi bulgular yeni, hangileri düzeltilmiş, hangileri devam ediyor, hangileri kabul edilmiş durumda.
Bu ayrım iki soruyu birden cevaplar. Geçen dönem yapılan düzeltmeler tuttu mu? Ve yeni çıkanlar bir rol değişikliğiyle mi ilişkili?
Yönetim masasında konuşulabilir olan da budur. “Dört yüz bulgumuz var” bir cümle değil, bir yığındır. “Bu çeyrekte şu kadar bulgu kapandı, şu kadarı yeni açıldı ve yenilerin çoğu aynı rol değişikliğinden geliyor” bir cümledir.
Değişiklik günlüğünü bulgu listesinin yanına koymak
Eklenen, güncellenen ve silinen kayıtlar için değişiklik günlüğü tutulur. “Bu yetki ne zaman geldi?” sorusu böylece aranabilir bir soruya dönüşür ve sebep arama süresi kısalır.
Organizasyonel tarafta ise kullanıcının BUKRS, WERKS, EKORG ve VKORG gibi yetki değerleri HR ve organizasyon ana verisiyle karşılaştırılabilir; fazla, jokerli veya çözümlenemeyen erişimler burada görünür hâle gelir. Yıllar içinde büyümüş rollerde en çok işe yarayan kontrol bu.
Beklentiyi de doğru kuralım: AccessGuard SAP GRC’nin yerine geçmez ve rol atamalarını kendisi değiştirmez. Yaptığı iş senkronizasyon, kural değerlendirmesi ve bulgu yönetimidir. Düzeltmeyi kimin, ne zaman, hangi gerekçeyle yapacağı hâlâ sizin süreç sorunuz.
Somut bir başlangıç önerelim: son iki yetki incelemenizin tarihine bakın ve arada kaç rolün değiştiğini bugün kimsenin bilmediğini kabul edin. Bir sistem seçelim, iki hafta arayla iki tarama alalım ve farkı birlikte okuyalım. Tartışmayı değiştiren şey ilk tarama değil, ikincisi olacak.