Yetkiyi Vermek Kolay, Geri Almak Neden Zor?

Yetkiyi Vermek Kolay, Geri Almak Neden Zor?

Yetkilendirme, bilgi güvenliğinde en sık yapılan ama en zor yönetilen konulardan biri. Firewall erişimleri, sunucu admin yetkileri, sistem ve uygulama erişimleri… Hepsi işin yürümesi için gerekli. Ama aynı zamanda en büyük risk kaynaklarından biri. Sorun genelde şurada başlıyor: Yetki neden verildi, nasıl verildi ve ne zaman geri alınacak? Bu sorular net değilse, yetki zamanla kontrolden çıkıyor.

Yetki Neden Verilir?

Önce temel noktayı netleştirelim. Yetki, keyfi ya da “olur mu” üzerinden verilmez. Temel sebepler genelde şunlardır:

• Operasyonel bir işi gerçekleştirmek için
• Arıza / incident müdahalesi için
• Proje veya geçici bir görev için
• Sistem kurulumu, bakım veya konfigürasyon ihtiyacı için

Firewall, sunucu ve IAM tarafında bu ihtiyaçlar farklı şekillerde ortaya çıkar. Şimdi bunları kendi konusu altında ele alalım.

Firewall Yetkileri Neden ve Nasıl Verilir?

Firewall yetkileri genellikle:

• Kural ekleme / değiştirme
• Geçici port açma
• Kaynak–hedef erişimi tanımlama için verilir.

Riskli nokta:
Firewall yetkileri geniştir ve tek bir yanlış kural, tüm ağı etkileyebilir.

Bu yüzden:

• Her firewall yetkisi role dayalı olmalıdır
• “Tam yetki” yerine, mümkünse kısıtlı yetki verilmelidir
• Açılan her kuralın:
  • Sahibi
  • Gerekçesi
  • Başlangıç ve bitiş tarihi net olmalıdır

Firewall erişimi “kişiye” değil, mümkün olduğunca rol ve görev bazlı tanımlanmalıdır.

Sunucu Admin Yetkileri Neden Verilir?

Sunucu admin yetkileri genellikle:

• Sistem kurulumu
• Konfigürasyon değişikliği
• Log inceleme
• Performans veya hata analizi için talep edilir.

En kritik hata:
Admin yetkisinin sürekli ve kalıcı verilmesi.

Doğru yaklaşım:

• Kalıcı admin yerine geçici / süreli admin
• Gerekirse just-in-time (JIT) yetkilendirme
• İş bitince otomatik düşen erişimler

Admin yetkisi, “rahat çalışmak için” değil, zorunluysa verilmelidir.

Kimlik ve Erişim Yetkileri (IAM) Nasıl Ele Alınmalı?

IAM tarafında risk genelde şuradan gelir:

• Birden fazla sistem
• Birbirini görmeyen yetkiler
• Rol değişikliklerinde güncellenmeyen erişimler

İyi bir IAM yaklaşımı şunları içermelidir:

• Rol bazlı erişim tanımları (RBAC)
• Minimum ayrıcalık prensibi
• Merkezi kullanıcı ve rol yönetimi
• Periyodik erişim gözden geçirmeleri

Bir kullanıcı bir rolden çıktığında, sistemler bazında tek tek yetki kapatılmamalı; rol düşürülmelidir.

Yetki Talebi Nasıl Alınmalı?

Yetki taleplerinin e-posta veya sözlü şekilde alınması, en büyük problemlerden biridir.
Çünkü:

• İzlenemez
• Ölçülemez
• Unutulur

Sağlıklı yöntemler: Sistem Üzerinden Talep

• ITSM / IAM sistemi
• Form bazlı, kayıtlı talepler
• Onay mekanizması olan süreçler

Talep sırasında mutlaka şu bilgiler alınmalıdır:

• Yetki gerekçesi
• Kapsam (hangi sistem, hangi erişim)
• Süre (başlangıç – bitiş)
• Onaylayan kişi

Otomasyon Kullanmalı mıyız?

Evet, mümkün olan her yerde.

Otomasyon:

• Yetkinin süresi dolunca otomatik kapanmasını sağlar
• İnsan hatasını azaltır
• “Unutulmuş yetki” riskini düşürür

Özellikle:

• Geçici admin yetkileri
• Proje bazlı erişimler
• Incident müdahale yetkileri

için otomasyon büyük fark yaratır.

Ama otomasyon tek başına yeterli değildir. Otomasyon, doğru kurgulanmış süreçlerle anlam kazanır.

Yetki Geri Alma Neden Hâlâ Zor?

Yetki alımında otomasyon yapılmamış sistemler bulunması durumunda; geçici olarak verilen yetkilerin zamanında geri alınmaması, bu yetkilerle yürütülen süreçlerin ve uygulamaların kalıcı yetki varmış gibi yapılandırılması, otomasyon öncesinde veya geçiş sürecinde tanımlanmış yetkilerin düzenli olarak gözden geçirilmemesi başlıca sorun alanlarını oluşturmaktadır.

Bu kapsamda özellikle;

• Geçici görev, izin, vekâlet veya proje bazlı verilen yetkilerin bitiş tarihi tanımlanmadan kullanıcı üzerinde kalmaya devam etmesi,
• “İş aksamasın” gerekçesiyle manuel verilen erişimlerin sonradan unutulması veya takip edilmemesi,
• Yetki talep ve onay süreçlerinin e-posta, telefon veya sözlü onay gibi izlenebilirliği düşük yöntemlerle yürütülmesi,
• Uygulama veya süreç sahiplerinin, otomasyon öncesinde tanımlanmış yetkiler üzerinde sahiplik ve sorumluluk hissetmemesi,
• Rol bazlı yetkilendirme yerine kullanıcı bazlı istisnai yetkilerin yaygınlaşması,
• Görev değişikliği, organizasyon değişikliği veya işten ayrılma durumlarında yetki geri alımının sistematik şekilde tetiklenmemesi,

yetkilerin gereğinden uzun süre açık kalmasına ve kalıcı erişim algısı oluşmasına neden olmaktadır.

Bu durumun doğal sonucu olarak;

• Kullanıcılar görevleri sona ermesine rağmen kritik sistemlere erişmeye devam edebilmekte,
• “Yetki zaten var” yaklaşımıyla süreçler yeniden tasarlanmakta,
• Yetki fazlalıkları zaman içinde normalleşmekte ve görünmez hale gelmekte,
• Yetki–rol–görev uyumsuzlukları artmakta,
• Denetim ve incelemelerde yetki birikimi (access accumulation) ve ayrım prensibi (SoD) ihlalleri ortaya çıkmaktadır.

Özellikle otomasyon bulunmayan ortamlarda, yetki geri alımı kontrolü yapılmadığında, bu riskler uzun süre fark edilmeden ilerleyebilmekte ve ancak iç/dış denetimler, özdeğerlemeler veya olay sonrası incelemelerde tespit edilebilmektedir.

Bu nedenle, yetki alım süreçleri otomasyona bağlanana kadar dahi;

• Geçici yetkiler için süre ve kapsam tanımı yapılması,
• Periyodik yetki gözden geçirme (access review) kontrollerinin işletilmesi,
• Süreç ve uygulama sahiplerinin yetki sorumluluğunun açıkça tanımlanması,
• Manuel verilen yetkilerin merkezi bir envanterde izlenmesi

kritik öneme sahiptir.

Sonuç: Yetki Yönetimi Bir Yaşam Döngüsüdür

Yetki yönetimi:

• Talep ile başlar
• Onay ile devam eder
• Süre ile sınırlandırılır
• Geri alma ile tamamlanır

Bu döngü eksikse, verilen her yetki potansiyel bir riske dönüşür. Belki de en doğru soru şudur:

“Bu yetkiyi kime verelim?” değil, “Bu yetkiyi ne zaman ve nasıl geri alacağız?”