En az ayrıcalık

Bir hesap ele geçtiğinde ilk soru şudur: bu hesap neler yapabiliyordu? Yanıt her şey ise olay felakete döner. Yanıt tek klasörü okumaksa olay küçük kalır.

Hasarın boyunu çoğu zaman saldırganın becerisi değil, ele geçen hesabın yetkisi belirler. Aynı oltalama e-postası bir stajyerin hesabını açtığında ekip bir parolayı sıfırlar. Bir etki alanı yöneticisinin hesabını açtığında ise bütün ağı yeniden kurar. Aradaki fark saldırganın yeteneği değil, hesaba yıllar içinde verilmiş yetkidir.

En az ayrıcalık (least privilege) bu gözlemi kurala bağlar. NIST tanımına göre sistem, kullanıcıların ve onlar adına çalışan süreçlerin yetkisini verilen işi bitirecek en düşük düzeyde tutar.

Kural insana, servis hesabına, kapsayıcıya ve API anahtarına aynı biçimde uygulanır. Fazla yetki, gelecekteki saldırganın hazır kazancıdır. Bir yetkiyi verirken sorarsın: bu hesap işini bu yetki olmadan yapabilir mi? Yanıt evetse yetki fazladır ve kaldırılır.

İlkeyi bir benzetmeyle tut: en az ayrıcalık, olası hasarın yarıçapını küçültür. Güvenlikçiler buna patlama yarıçapı der. Her şeye yetkili tek bir hesap, tek bir hatayla tüm kurumu düşürür; dar yetkili yüz hesap ise en kötü ihtimalde yalnız kendi küçük alanını kaybeder.

Bir sistemi tasarlarken yetkiyi bu gözle dağıtırsın: bir hesap ele geçerse en fazla ne kaybederim? Yanıt ne kadar küçükse tasarım o kadar sağlamdır.

İlk uygulama aracı rol tabanlı erişimdir (RBAC). Yetkiyi kişiye değil role bağlarsın. Destek rolü siparişi görür ama kart numarasını göremez.

Yeni gelen kişiye rolü verirsin, yetkileri tek tek dağıtmazsın. Kişi departman değiştirdiğinde eski rol düşer, yenisi gelir. RBAC'ın sınırı rol patlamasıdır.

Her küçük istisna için yeni bir rol açarsan yüzlerce rol birikir ve kimse hangisinin ne yaptığını bilmez. İşareti şudur: rol sayısı kişi sayısına yaklaşıyorsa model bozulmuştur. Çözüm, ortak yetkileri birkaç net rolde toplamak ve kalan ince istisnaları ayrı bir kurala bırakmaktır. Rolleri yılda bir sadeleştirir, kullanılmayanı kapatırsın.

Kurallar role sığmayınca nitelik tabanlı erişim (ABAC) devreye girer. ABAC kararı kullanıcının, kaynağın ve bağlamın niteliklerine göre verir: kişinin departmanı, günün saati, isteğin geldiği ağ, verinin gizlilik etiketi. 'Finans ekibi, yalnız mesai saatinde, yalnız kurum ağından ödeme kaydını açar' gibi bir kural RBAC ile zor kurulur, ABAC ile doğal yazılır.

NIST'in SP 800-162 belgesi ABAC'ı bu nitelik temelli model diye tanımlar. İki yaklaşım birlikte kullanılır: kaba hat RBAC, ince ayar ABAC.

# Fazla yetki: uygulama root ile çalışıyor, veritabanına da root bağlanıyor
USER root
DB_URL=mysql://root:...@db:3306/shop

# Dar yetki: ayrı sistem kullanıcısı ve yalnız okuyan veritabanı hesabı
USER app
DB_URL=mysql://shop_ro:...@db:3306/shop   # yalnız SELECT

GRANT SELECT ON shop.orders TO 'shop_ro'@'%';

Koddaki ilk blokta iki hata üst üste biner. Uygulama işletim sisteminde root olarak koşar ve veritabanına da tam yetkili root hesabıyla bağlanır. Uygulamada tek bir SQL enjeksiyonu açığı çıkarsa saldırgan tablo siler, yeni kullanıcı açar.

İkinci blokta uygulama ayrı bir sistem kullanıcısıyla çalışır, veritabanına yalnız SELECT yetkili shop_ro hesabıyla bağlanır. Son satır bu hesaba yalnız shop.orders tablosunda okuma verir. Aynı açık çıksa bile saldırgan yalnız okur, veriyi silemez ve yetki yükseltemez.

Servis hesapları ayrı bir başlıktır. Uygulamalar kurulum kolay olsun diye çoğu yerde root ile çalışır. Dockerfile'da USER satırı yoksa ve temel imaj da kullanıcı değiştirmiyorsa süreç kapsayıcının içinde root olarak koşar. İki yol daraltır: imaja USER satırı eklemek ya da daemon'ı root olmayan kullanıcıyla çalıştıran rootless modu kurmak.

Docker belgeleri açık konuşur: rootless mod, daemon'ı ve kapsayıcıları root olmayan kullanıcıyla çalıştırıp olası açıkların etkisini azaltır. Kapsayıcı yalıtımı tam değildir. Kapsayıcılar ana makinenin çekirdeğini paylaşır ve kaçış zincirleri çoğu zaman içerideki root ayrıcalığına yaslanır.

Aynı ilke API anahtarlarına da işler. Bir anahtar çoğu zaman bir insandan daha geniş yetki taşır ve koda, loga ya da yapılandırma dosyasına sızması kolaydır. Anahtarı yalnız ihtiyacı olan servise ver, kapsamını tek işe daralt ve düzenli olarak döndür.

Mümkünse kalıcı anahtar yerine kısa ömürlü belirteç kullan. Kod deposuna yanlışlıkla gönderilen anahtarı yakalamak için depoda gizli bilgi taramasını aç. Bir anahtarın nerede durduğunu bilmiyorsan onu güvende de tutamazsın.

Yönetim işi de sürekli yüksek yetki gerektirmez. Linux'ta sudo, yetkiyi tek komut için yükseltir ve komutu kimin çalıştırdığını sistem kaydına yazar. Kalıcı root kabuğu ise iki zarar verir: kimin ne yaptığı bulanıklaşır ve yanlış yazılan tek komut tüm sistemi etkiler.

Servisleri çoğu dağıtımda systemctl yönetir, eski sistemlerde service komutu aynı işi görür. sudoers dosyasında bir kullanıcıya yalnız tek servisi yeniden başlatma yetkisi de tanımlayabilirsin; o zaman kişi root kabuğu açamaz, yalnız o komutu çalıştırır.

sudo'nun ikinci faydası hesap verebilirliktir. Her sudo komutu auth.log'a kimin, hangi dizinde, hangi kimlikle, hangi komutu çalıştırdığını yazar. Olaydan sonra bu kayıt kimin ne yaptığını açığa çıkarır.

Paylaşılan root kabuğunda ise birkaç kişi aynı anda root olur ve hangi komutu kimin yazdığı kaybolur. Bu yüzden kişisel hesaptan sudo ile yükselmek, ortak root hesabına girmekten hem daha güvenli hem de daha izlenebilirdir. Aşağıdaki örnekte tek komutluk bir izin, izinli komutların listesi ve reddedilen bir deneme yan yana durur.

# /etc/sudoers.d/nginx (visudo -f ile düzenlenir)
deploy ALL=(root) /usr/bin/systemctl reload nginx

# deploy kullanıcısı izinlerini sorar
$ sudo -l
[sudo] password for deploy:
Matching Defaults entries for deploy on web-01:
    env_reset, mail_badpass, use_pty

User deploy may run the following commands on web-01:
    (root) /usr/bin/systemctl reload nginx

# İzin dışı bir komut denenir
$ sudo cat /etc/shadow
Sorry, user deploy is not allowed to execute '/usr/bin/cat /etc/shadow' as root on web-01.

# Reddedilen deneme kayda düşer
auth.log: sudo: deploy : command not allowed ; TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow

Örneği satır satır oku. İlk satır kuralın kendisidir: deploy kullanıcısı her makinede, root kimliğiyle yalnız tek bir komutu çalıştırabilir. Dosyayı visudo ile düzenlersin, çünkü visudo söz dizimini kaydetmeden önce denetler; bozuk bir sudoers dosyası sudo'yu herkes için kilitler. sudo -l kullanıcının izinli komutlarını listeler, bu yüzden yetki gözden geçirmesinde de işe yarar.

İzin dışı komut reddedilir ve deneme auth.log'a 'command not allowed' diye düşer. Bu satır tespit için çok değerlidir: dar yetkili bir hesabın birden /etc/shadow okumaya çalışması bir uyarı kuralına bağlanır. Bir tuzağa da dikkat et.

İzin verdiğin program kabuk açabiliyorsa, örneğin less ya da vi, tek komut izni aslında tam root demektir. sudoers belgesi bu riski açıkça yazar.

Dar yetkinin en büyük faydası yanal harekette görünür. MITRE ATT&CK yanal hareketi (lateral movement), saldırganın ortamda sistemden sisteme geçmesi diye tanımlar. Bu geçişin yakıtı fazla yetkili hesaplardır.

Her hesap dar tutulursa saldırgan her adımda yeni bir kimlik bilgisi aramak zorunda kalır. Her arayış yeni gürültü üretir ve savunma tarafına yakalama şansı verir. ATT&CK, geçerli hesapların kötüye kullanımını T1078 numarasıyla ayrı bir teknik diye listeler.

Dar yetki yalnız saldırganı yavaşlatmaz, onu görünür de kılar. Kısıtlı bir hesabın birden yeni bir sunucuya bağlanması, yeni bir yetki istemesi ya da alışmadığı bir komutu çalıştırması bir uyarı satırıdır. Yetkiler geniş olduğunda bu hareketlerin çoğu normal görünür ve alarm üretmez. Bu yüzden en az ayrıcalık aynı zamanda bir tespit aracıdır: olağan dışı yetki kullanımı, dar bir ortamda hemen sırıtır.

Windows ağlarında yanal hareketin klasik yakıtı ortak yerel yönetici parolasıdır. Yüzlerce makine aynı parolayı paylaşırsa bir makineden çalınan parola ya da parola özeti hepsini açar.

Microsoft'un Windows LAPS özelliği bu açığı kapatır: her cihazın yerel yönetici parolasını düzenli olarak döndürür, güvenli saklar ve yalnız yetkili yöneticiye verir. Böylece bir makineden sızan parola öbür makinelere yaramaz. Windows LAPS, 11 Nisan 2023 güncellemesini almış Windows 10, Windows 11, Windows Server 2019 ve 2022 ile daha yeni sürümlerde yerleşik gelir, ayrı kurulum istemez.

Unutulan hesaplar da aynı riski taşır. ATT&CK, saldırganların işten ayrılmış kişilere ait pasif hesapları kullandığını ayrıca anar; sahibi artık bakmadığı için bu hesaptaki tuhaf hareketi kimse fark etmez. İşten ayrılan kişinin hesabını aynı gün kapat.

En sağlamı, insan kaynakları kaydındaki ayrılışın hesabı kendiliğinden kapatmasıdır. Paylaşılan yönetici hesabından da kaç, çünkü kimin ne yaptığı kaybolur. Son doksan günde hiç kullanılmayan yetkiyi kaldırmak en ucuz kazançtır.

Bulutta ilke aynı biçimde işler. Kimlik bir rol üstlenir, role bağlı politika da hangi kaynakta hangi eylemin serbest olduğunu yazar.

En sık hata, eylem ve kaynak alanına yıldız işareti (*) koyan geniş politikadır; böyle bir politika sızınca saldırgan her kaynakta her eylemi yapar. Süre de bir yetki boyutudur: kalıcı erişim anahtarı sızınca süresiz kapı açar, kısa ömürlü belirteç birkaç saat sonra geçersiz olur. Politikayı yazarken hem eylemi hem kaynağı tek tek belirtir, geniş yıldızdan kaçarsın.

Bulutta en tehlikeli satırlardan biri, bir rolün başka rolleri üstlenmesine geniş izin veren yetkidir. Böyle bir rol sızarsa saldırgan rolden role atlayıp yönetici yetkisine ulaşır; buna yetki yükseltme (privilege escalation) denir.

Rol üstlenme yetkisini yalnız gerçekten gerekli yerde ver ve hangi rolün hangi rolü üstlenebileceğini tek tek yaz. Denetim kaydını da aç: hangi kimliğin hangi rolü ne zaman üstlendiği orada durur. Bir rolü daraltırken önce son aylardaki gerçek kullanımına bak; büyük bulut sağlayıcıları kullanılmayan izinleri raporlayan araçlar sunar.