Erişim yetkileri nasıl gözden geçirilir: kapsamdan kanıta
Erişim gözden geçirmesi, yetkilerin zamanla birikmesini önleyen düzenli bir kontroldür. Kapsam riske göre belirlenir, döküm iş diliyle hazırlanır, onay yetkiyi bilen kişiden alınır ve reddedilen yetki kaldırılarak kanıtlanır.
Bir bakışta
- Yetki zamanla birikir. Rol değişimi ve geçici erişimler gözden geçirilmezse gereksiz yetki kalıcı olur.
- Kapsamı riske göre kurun. Ayrıcalıklı yetkiler ve hassas sistemler en sık ve ayrıntılı kontrol edilir.
- Döküm anlaşılır olmalı. Teknik grup adları yerine yetkiyi iş diliyle açıklayın, sahibini belirtin.
- Onay, yetkiyi bilenden alınır. Yönetici görev ihtiyacını, uygulama sahibi hassas yetkiyi doğrular.
- Kaldırılmayan red anlamsızdır. Reddedilen yetkinin silindiğini doğrulayın ve kanıt tutun.
Erişim gözden geçirmesi nedir ve neden gerekir?
Kullanıcı erişim gözden geçirmesi (access review), kimin hangi sisteme ve veriye erişimi olduğunu düzenli aralıklarla listeleyip bu erişimin hâlâ gerekli olup olmadığını sahibine onaylatma sürecidir. Yetki tanımlama anında doğru olabilir; ancak zamanla kişi rol değiştirir, projeden ayrılır, geçici bir erişim kalıcı hale gelir. Hiçbir şey sorulmazsa yetkiler birikir ve çalışanın bugünkü görevinin çok ötesinde bir erişim kümesi oluşur.
Bu birikim hem güvenlik hem uyum riskidir. Ele geçirilen bir hesabın etkisi, hesabın sahip olduğu yetkiyle orantılıdır; gereksiz yetki saldırı yüzeyini büyütür. Ayrıca görevler ayrılığı (aynı kişinin hem talep edip hem onaylaması gibi) ihlalleri yetki birikmesiyle ortaya çıkabilir. İç denetim ve düzenleyici uyum gereklilikleri de yetkilerin düzenli onaylanmasını bekler.
Gözden geçirme, erişim yönetiminin kontrol adımıdır. Erişimi veren süreç (talep, onay, atama) ile erişimi geri alan süreç (rol değişimi, ayrılma) iyi çalışıyorsa gözden geçirme sapmaları yakalar; çalışmıyorsa her dönem büyük bir temizlik işine dönüşür.
Gözden geçirme tek seferlik temizlik değil, tekrar eden bir kontrol
Erişim gözden geçirme döngüsü
- Kapsamı belirleHangi sistem, uygulama ve veri kümelerinin gözden geçirileceği yazılır.
- Yetki dökümünü çıkarKim, hangi hesapla, hangi yetkiye sahip, listelenir.
- Sahiplere onaylatHer yetki, iş sahibi ya da yöneticisi tarafından onaylanır ya da reddedilir.
- Kaldırmaları uygulaReddedilen yetkiler kaldırılır ve kanıt tutulur.
- Sonuçlardan öğrenTekrarlayan sapmaların süreç nedeni belirlenir.
Kapsamı ve sıklığı riske göre belirleyin
Her sistemi aynı sıklık ve ayrıntıyla gözden geçirmek, ekibi yorar ve sonucu gevşetir. Kapsam belirlemede iki eksen birlikte düşünülür: yetkinin türü ve erişilen verinin hassasiyeti. Yüksek hassasiyetli sistemlerde (finans, müşteri verisi, üretim kontrol) ayrıcalıklı yetkiler en sık ve en ayrıntılı kontrole girer. Aynı sistemde standart kullanıcı yetkileri de düzenli ama daha seyrek gözden geçirilir.
Düşük hassasiyetli sistemlerde ayrıcalıklı hesaplar yine hedefli kontrol ister: yönetici hesabı, hassas olmayan bir sistemde bile yanal hareket için kullanılabilir. Düşük hassasiyetli veride standart yetkiler ise seyrek ve toplu onayla yönetilebilir.
Kapsam tablosunu önce kritik sistemlerle başlatıp zamanla genişletin. İlk dönemde hepsini birden kapsamaya çalışmak, kalitesiz onaylara ve yarım kalmış kapanışlara yol açar.
Ayrıcalık ve hassasiyet, gözden geçirmenin sıklığını belirler
Kapsam ve sıklık için dört kutu
Yetki dökümünü hazırlamak
Gözden geçirmenin kalitesi, dökümün kalitesine bağlıdır. İyi bir döküm; kullanıcının adı, birimi, yöneticisi, hesap türü (kişisel, servis, paylaşılan, yönetici), verilen yetki, ne zaman ve neden verildiği ve son kullanım zamanı gibi bilgileri içerir. Yalnızca teknik grup adları (ör. "GRP_FIN_RW") yazan bir liste, onaylayan kişi için anlamsızdır; yetkiyi iş diliyle açıklamak gerekir.
Kimlik yönetimi sistemi varsa döküm oradan alınır; yoksa her uygulama için ayrı bir dışa aktarım gerekir. Bu aşamada genellikle ikinci bir sorun ortaya çıkar: bazı uygulamalar merkezi kimlik sistemine bağlı değildir ve yetkileri yerel olarak yönetilir. Bu uygulamalar gözden geçirmenin kör noktasıdır ve ayrı bir listeyle izlenmelidir.
Servis hesapları ve paylaşılan hesaplar ayrıca ele alınmalıdır. Bunların sahibi olmadığında kimse onay vermez ve yıllarca kalırlar. Her hesaba bir sorumlu atamak, gözden geçirmenin ön koşuludur.
Onay süreci: kim neyi onaylar?
Onayı verecek kişi, yetkiye gerçekten hakim olandır. Yöneticisi çalışanın görevlerini bilir; ancak uygulamaya özgü yetkilerin anlamını uygulama sahibi bilir. Bu nedenle iki kademeli yapı sık kullanılır: yöneticisi çalışanın görevi için gerekli olup olmadığını onaylar, uygulama sahibi ise ayrıcalıklı ve hassas yetkileri ayrıca doğrular.
Onaylayıcıların yükünü azaltmak için talepler gruplanır, önceki dönemde onaylanıp değişmeyenler öne çıkarılır ve yalnızca değişiklik ya da riskli olanlar ayrıntılı gösterilir. Aksi halde onaylayıcı yüzlerce satırı gözünü kapatıp "onayla"ya basar; buna "lastik damga" onayı denir ve kontrolü anlamsızlaştırır.
Reddedilen yetkiler için bir süre ve sorumlu atanır. Kaldırma uygulanmadan kapatılan bir gözden geçirme, denetimde en sık yakalanan eksikliklerden biridir. Kanıt olarak onay kaydı, kaldırma talebi ve kapanış doğrulaması saklanmalıdır.
Rol değişimi, ayrılma ve kullanılmayan yetkiler
Periyodik gözden geçirme, olay tabanlı kontrollerin yerine geçmez. Çalışan başka bir birime geçtiğinde eski rolün yetkileri sonraki gözden geçirmeyi beklemeden kaldırılmalıdır; ayrılan çalışanın hesapları ise ayrılış günü kapatılmalıdır. İnsan kaynakları kayıtları ile kimlik sistemi arasında otomatik bir bağ kurmak, bu iki olayı güvenilir hale getirir.
Kullanılmayan yetkiler gözden geçirmede güçlü bir sinyaldir. Uzun süredir giriş yapılmamış hesaplar ya da yetkisi olup hiç kullanılmayan uygulamalar, onaylayıcıya "gerçekten gerekli mi?" sorusunu sorma fırsatı verir. Kullanım bilgisi dökümde yer aldığında onay kararı sezgiden veriye taşınır.
Geçici erişimler ayrı bir kategoridir. Proje ya da bakım için verilen erişimin bitiş tarihi tanımlanmalı ve süre dolunca otomatik kaldırılmalıdır. Bitiş tarihi olmayan her geçici erişim, bir sonraki gözden geçirmede kalıcı yetkiye dönüşmüş olarak karşınıza çıkar.
Sık yapılan hatalar
İlk hata, gözden geçirmeyi yalnızca denetimden önce yapılan bir temizlik olarak görmektir. Düzenli ve takvimli olmayan bir gözden geçirme, yetki birikimini yakalayamaz.
İkinci hata, onayı verenin yetkiyi anlamamasıdır. Teknik adlarla gelen listeler onaylayıcıyı çaresiz bırakır. Yetkiyi iş diliyle tanımlayın ve kullanım bilgisini gösterin.
Üçüncü hata, ayrılan ve rol değiştiren çalışanları gözden geçirmeye bırakmaktır. Bu iki olay için gözden geçirme beklenmeden anlık yetki geri alma süreci işlemelidir; periyodik gözden geçirme bunun yerine geçmez, yedeğidir.
Son hata, ayrıcalıklı hesapları ve servis hesaplarını kapsam dışı tutmaktır. Saldırganların en çok hedeflediği hesaplar bunlardır.
Bu beceriyi Mindset programlarında nerede çalışırsınız?
Siber Güvenlik Bootcamp Programı'nın Kimlik ve Erişim Yönetimi konusu, yetkilendirme modellerini ve erişim kontrolünün yaşam döngüsünü ele alır. BT güvenliği ile iç denetim ekiplerindeki katılımcılar, bu temeli gözden geçirme sürecinin tasarımı ve kanıt yönetimine taşıyabilir.
İlgili Mindset programı
Siber Güvenlik Bootcamp Programı
Sık sorulan sorular
Erişim gözden geçirmesi ne sıklıkla yapılmalı?
Sabit bir sıklık yoktur; risk belirler. Yüksek hassasiyetli sistemlerde ve ayrıcalıklı yetkilerde daha sık, düşük hassasiyetli sistemlerde daha seyrek yapılır. Kurumun politikası ve uyum gereklilikleri alt sınırı belirler. Rol değişimi ve ayrılma gibi olaylarda ise beklemeden yetki geri alınmalıdır.
Gözden geçirmeyi kim yapar?
Yetkiyi bilen iş sahibi ya da yönetici onaylar; BT ve güvenlik ekibi dökümü hazırlar, süreci yönetir ve kaldırmaları uygular. İç denetim sürecin işleyişini bağımsız olarak kontrol eder. Onay veren, yaptığı onayın sonucundan sorumlu olduğunu bilmelidir; aksi halde onay şekle dönüşür.
Servis hesapları nasıl gözden geçirilir?
Her servis hesabına bir sorumlu atayın ve hesabın amacını, kullanıldığı sistemi, yetkisini ve son kullanımını döküme ekleyin. Kullanılmayan hesaplar kapatılır, yetkisi geniş olanlar daraltılır. Sahibi belirsiz hesaplar gözden geçirmenin en çok atlanan kısmıdır.
Gözden geçirme sonucunda neler kanıt olarak saklanmalı?
Gözden geçirmenin kapsamı ve tarihi, kullanılan döküm, onay ve ret kayıtları, kaldırma talepleri ve uygulandığının doğrulaması, istisnalar ve gerekçeleri saklanmalıdır. Denetçi, yalnızca onayın alındığını değil, reddedilen yetkinin fiilen kaldırıldığını da görmek ister.
Küçük bir kurumda erişim gözden geçirmesi nasıl yapılır?
Kapsamı kritik sistemlerle sınırlayın: e-posta, dosya paylaşımı, finans ve yönetim panelleri. Döküm basit bir tabloyla çıkarılabilir; yönetici ve sistem sahibi onaylar. Takvime bağlamak, ayrılanların hesaplarını hızla kapatmak ve ortak hesaplardan kaçınmak, büyük sistemlere gerek kalmadan temel riski azaltır.