Kurumsal yapılarda ayrıcalıklı erişim (admin) çoğu zaman “gerektiğinde lazım” diye birikir. Sonra gün gelir:
- Bir hesap sızar, blast radius büyür
- Bir kişi ayrılır, erişimler kalır
- Incident sırasında herkes aynı “shared admin” ile girer, audit çöker
Operasyonel liderlikte bu konuyu “IAM ekibinin işi” diye bırakmak, aslında operasyonel risk üretir. Çünkü en kritik hatalar, en kritik anlarda bu erişimlerle yapılır.
Bu yazıda, access review’ü bir “yılda bir compliance toplantısı” olmaktan çıkarıp; sürdürülebilir bir ritme bağlayan pratik bir modeli anlatıyorum.
Hedef: “Kimde admin var?” değil “Admin erişimi nasıl veriyoruz?”
Olgun sistemlerde soru şuna dönüşür:
- Admin erişimi ne kadar süreli?
- Hangi koşullarda veriliyor (MFA, cihaz, ağ, ticket)?
- Erişim verildiğinde ne logluyoruz?
- Süre bitince otomatik geri alınıyor mu?
Bu dönüşüm, güvenlik kadar operasyonel sakinliği de artırır.
Üç erişim sınıfı: Kalıcı, JIT, Break-glass
1) Kalıcı erişim (en az tercih edilen)
Sadece platform sahiplerinde, sınırlı ve gerekçeli.
2) Just-in-Time (varsayılan hedef)
Ticket/incident ile tetiklenen, süreli ve loglu erişim.
3) Break-glass (acil durum)
En riskli ama en gerekli akış. Bu yüzden en disiplinli olması gerekir:
- Ayrı kimlik (normal hesapla aynı değil)
- Ayrı MFA (tercihen donanım anahtarı)
- Sıkı süre limiti
- Olay sonrası zorunlu review
Ritm: Haftalık küçük, aylık orta, çeyreklik büyük
Benim sahada işe yaradığını gördüğüm ritim:
- Haftalık (15 dk): yeni açılan admin erişimler, kapanmayan JIT’ler, exception’lar
- Aylık (45–60 dk): role/grup düzeni, orphan hesaplar, servis sahipliği değişimleri
- Çeyreklik (90 dk): politika güncelleme, MFA/cihaz uyumu, audit sonuçları, tatbikat
Burada amaç “mükemmel rapor” değil; sürekli hijyen.
Operasyonel runbook: Erişim geri alma (revocation) senaryosu
Incident’ta en değerli reflekslerden biri: erişimi geri almayı “son çare” değil, kontrollü bir araç olarak kullanmak.
Revocation runbook’unda en az şunlar olmalı:
- Kullanıcı hesabını kilitleme / token revoke
- SSH keys / API keys rotate
- Break-glass anahtar yenileme (gerekiyorsa)
- Etkilenen sistemlerde “son 24 saat admin aksiyonları” log taraması
Bu runbook, security ekibinin yanında ops ekibinin de elinde olmalı.
Metrikler: Ekipleri boğmadan, sinyali tut
Takip ettiğim pratik metrikler:
- Kalıcı admin sayısı (trend)
- JIT erişimlerin ortalama süresi
- Expire olup kapanmayan erişim sayısı
- Break-glass kullanım sayısı ve post-review tamamlanma oranı
Metriklerin amacı “puanlamak” değil; riskin nereye biriktiğini görmek.
Son söz
Ayrıcalıklı erişim, sadece güvenliğin değil; operasyonel liderliğin de omurgasıdır. Access review’ü ritme bağladığınızda; incident’ta daha sakin kalırsınız, audit daha temiz olur ve en önemlisi risk “kimsenin fark etmediği” bir yerlerde birikmez.