En Az Yetki İlkesi: Minimal Erişim Sistemleri Nasıl Korur

Eşim ve ben dışında, evimizin anahtarına sahip dört kişi daha var: en yakın arkadaşlarımız ve kayınvalidemle kayınpederim. Her birinin, biz tatildeyken bitkileri sulamak ya da partiler için fazladan sandalye almak gibi işler için birer anahtar seti var. Komşularımdan hiçbirine anahtar vermedim, çünkü onları o kadar iyi tanımıyorum ve ben yokken eve girmeleri için bir gerekçe görmüyorum. Saksının altına kimsenin kullanması için bir anahtar bırakmıyorum ve tabii ki kapıyı açık bırakıp gitmiyorum. Bu, felaketi davet etmek olurdu, değil mi?

Siber güvenlikte de aynı kavram geçerlidir: İnsanlara ve sistemlere işlerini yapmak için gerçekten ihtiyaç duydukları erişimi verin, fazlasını değil. Buna En Az Yetki İlkesi, kısaca PoLP denir. Varsayılan yönetici hakları yok, “ne olur ne olmaz” süper kullanıcı ayrıcalıkları yok ve kesinlikle unutulmuş test hesaplarında ortalıkta dolaşan sınırsız erişim kartları yok. İnsanların erişimi ne kadar genişse, bir şeyler ters gittiğinde kaybedecek şey de o kadar fazladır!

Bu yazıda, PoLP’nin perde arkasında nasıl çalıştığını ve neden riski azaltmanın en etkili yollarından biri olduğunu ele alacağız. Yazıyı takip etmek için siber güvenlik geçmişine ihtiyacınız yok. Hatta amaç, kavramı, bir teknoloji projesinde çalışan herkesin uygulayıp uygulamasını biraz daha güvenli hâle getirebileceği kadar anlaşılır kılmaktır!

En Az Yetki İlkesi Nedir?

En Az Yetki İlkesi (PoLP) bazen Asgari Ayrıcalık İlkesi (PoMP) veya En Az Otorite (PoLA) olarak da adlandırılır. Tam da göründüğü gibidir: İnsanlara veya sistemlere işleri için ihtiyaç duydukları en az düzeyde erişim verin. İhtiyaç duyabilecekleri en fazla erişimi değil, kurulumu en kolay olanı değil, sadece gerçekten ihtiyaç duydukları kadarını ve fazlasını değil.

Önemli olan, bunun yalnızca insanlar için geçerli olmamasıdır. PoLP herkes ve her şey içindir: kullanıcılar, servisler, uygulamalar, sanal makineler, API’ler ve hatta arka plan süreçleri. Eğer oturum açabiliyor veya bir kaynağa erişebiliyorsa, potansiyel bir risk olarak ele alınmalı ve yalnızca gerekli olanı yapmasına izin verilmelidir.

Bu ilkeyi takip etmek sizi kasıtlı davranmaya zorlar: Kim, neye gerçekten ihtiyaç duyuyor? Ne kadar süreyle? Ve bu anahtarlar yanlış ellere geçerse ne olur?

En Az Yetki İlkesi Nasıl Çalışır?

Tamam, PoLP’nin erişimi asgari düzeyde sınırlandırmakla ilgili olduğunu gördük. Ancak uygulamada bu, sadece sık sık “hayır” demek anlamına gelmez. Erişimi kasıtlı, geçici ve güvenlik bariyerleriyle veren sistemler ve süreçler tasarlamak anlamına gelir. Bunu yapmak için birkaç strateji vardır:

Rol tabanlı erişim

Bireysel kullanıcılara ad hoc izinler vermek yerine, her biri önceden tanımlanmış erişim kurallarına sahip “geliştirici”, “analist” veya “finans” gibi roller atarsınız. Daha derli topludur, yönetimi kolaydır ve zamanla biriken istisna karmaşasını önler.

Süre sınırlı veya Anında (JIT) erişim

Bazen insanlar gerçekten yükseltilmiş izinlere ihtiyaç duyar, ancak yalnızca belirli bir görev veya zaman penceresi için. JIT erişimiyle kullanıcılar, genellikle net bir sona erme süresiyle, geçici ayrıcalık yükseltmesi talep edebilir.

Ayrıcalık parantezleme

JIT’in daha teknik bir türü: bir betik veya kullanıcı tek bir işlem için kısa süreliğine yükseltilmiş haklar alır, ardından hemen normale döner. Bu, DevOps iş akışlarında oldukça yaygındır.

Sıfır Güven gibi modern erişim modelleri

PoLP, Sıfır Güven Ağ Erişimi (ZTNA) içinde de büyük rol oynar. Sıfır Güven modelinde hiçbir kullanıcı veya cihaza varsayılan olarak güvenilmez: Herkes, her seferinde kim olduğunu kanıtlamalı ve erişmek istediğini gerekçelendirmelidir. En az yetki ilkesi, en başından itibaren bu modelin içindedir.

Buradaki temel çıkarımlardan biri, PoLP’nin sadece kim olduğunuzla ilgili değil, aynı zamanda şu anda neye ihtiyacınız olduğu ile de ilgili olduğudur.

En Az Yetki İlkesinin Önemi

Sistemler, kullanıcılar ve süreçler yalnızca gerçekten ihtiyaç duyduklarına eriştiğinde, kazara hataların riski azalır. Bu yazının başından beri bunu yeterince tekrarladım. Peki pratikte risk nasıl azalır?

Saldırı yüzeyini küçültmek

Ne kadar çok erişim verirseniz, bir saldırganın zarar verme fırsatı da o kadar artar. Ele geçirilmiş bir hesap yalnızca tek bir veritabanına erişebiliyorsa, hasar orada durur. Her şeye erişebiliyorsa? Kolay gelsin.

Kötü amaçlı yazılım yayılımını sınırlamak

Kötü amaçlı yazılımlar genellikle bir sistemden diğerine atlayarak yatayda yayılır. En az yetki, bu yolları duvarlarla kapatır. Sisteminizin bir bölümü ele geçirilse bile PoLP, bulaşmanın kontrol altına alınmasına yardımcı olabilir.

Ayrıcalık yükseltmeyi önlemek

Saldırganlar, düşük düzeyli hesapları yönetici hesaplarına dönüştürmeyi sever. PoLP uygulandığında, ayrıcalıklar zaten dar kapsamlı olduğundan yükseltme numaralarına daha az alan kalır.

İç tehditlere karşı koruma

Her risk dışarıdan gelmez. Bazen çalışanlar hata yapar veya maalesef kasıtlı hareket eder. PoLP, her iki durumda da etki alanını sınırlar.

Daha hızlı olay sınırlaması sağlar

Bir şeyler ters gittiğinde, kimin neye eriştiğini tam olarak bilmek kontrol altına almayı çok daha kolay hâle getirir. Yangın yayılırken izin tombalası oynamazsınız.

Uyumluluğu destekler

GDPR, HIPAA ve PCI DSS gibi düzenlemeler güçlü erişim kontrolleri gerektirir. PoLP, yalnızca doğru kişilerin hassas verilere eriştiğinden emin olarak bu gereklilikleri karşılamaya yardımcı olur.

Operasyonel netliği artırır

Herkes işini yapacak kadar erişime sahip olduğunda, denetlemek daha kolay, mantık yürütmek daha kolaydır ve “ayrıcalık şişmesi”ne çok daha az meyillidir (kimsenin ne zaman verildiğini hatırlamadığı, muhtemelen artık gerekmeyen ama yine de açık kalan o kalıcı izinler).

Bu tür uygulamalar etrafında daha sağlam bir temel oluşturmak istiyorsanız, Introduction to Data Security kursumuz, PoLP, şifreleme ve güvenli sistem tasarımı gibi temel ilkeleri daha derinlemesine ele alır.

En Az Yetki İlkesinin Uygulamadaki Örneği

Tamam, teori yeter. PoLP’nin pratik bir örneğine bakalım.

Orta ölçekli bir teknoloji şirketindeyiz ve son dakika bir olay geliyor: Canlıda bir hata müşteri panosunu bozuyor. Üç kişi göreve çağrılıyor: Corey, Luca ve Sam. Her birinin rolü çok farklı ve kritik olarak erişim düzeyleri de çok farklı.

Corey - Frontend Geliştirici

Corey, panonun arayüzünü yazdı, bu yüzden araştırma için dâhil ediliyor. Sahip olduğu yetkiler:

• Frontend kod deposuna ve web uygulamasının CI/CD hattına erişim.
• Salt okunur erişim: son dağıtımdan kalma günlüklere.
• Canlı veritabanlarına veya bulut altyapısına doğrudan erişim yok.

Corey, müşteri adlarının nasıl oluşturulduğuna dair son değişikliğin, API’den gelen beklenmedik null değerler nedeniyle başarısız olabileceğini tespit eder. Bunu daha fazla inceleme için işaretler, ancak canlı ortama SSH ile bağlanamaz (ve bağlanmamalıdır) ya da veritabanını kurcalayamaz. Erişimi tam olarak rolüne göre kapsamlanmıştır: arayüz kodu, günlükler ve tehlikeli hiçbir şey yok.

Luca - Site Güvenilirliği Mühendisi

Luca, altyapıdan sorumludur. Corey uyarıyı kaldırınca Luca, sorunu daha derinden izlemek için devreye girer. Sahip olduğu yetkiler:

• Kubernetes panosuna ve küme günlüklerine erişim.
• Servisleri yeniden başlatma, dağıtımları geri alma ve sistemleri geçici olarak ölçeklendirme yetkisi.
• Anında erişim (JIT): yalnızca dahili bir erişim onay aracı üzerinden verilen, canlı veritabanlarından okuma izni.

Luca, erişimini kullanarak API servis günlüklerini kontrol eder ve yakın tarihli bir taşınmanın küçük bir veri tutarsızlığına yol açtığını fark eder. Bunu doğrulamak için süre sınırlı veritabanı erişimi ister, onaylanır, etkilenen satırları okur ve ardından yükseltilmiş erişimi 30 dakika sonra otomatik olarak sona erer.

Luca gibi veritabanları, hatlar veya bulut altyapısıyla çalışıyorsanız, veri sistemlerinin nasıl kurulduğunu anlamak en baştan güvenli erişim tasarlamanıza yardımcı olur. Understanding Data Engineering kursumuz iyi bir başlangıçtır.

Sam - Finans Lideri

Bu arada, Sam’den, müşteri başarı ekibini hangi kullanıcıların etkilendiği ve bunun abonelikleri ile SLA’ları üzerinde ne etkisi olduğu konusunda bilgilendirmesi istenmiştir. Sahip olduğu yetkiler:

• Canlı veritabanının salt okunur bir analitik replikasıyla çalışan bir panoya erişim.
• Rapor dışa aktarma izni; ancak özel sorgular çalıştırma veya hassas dahili günlükleri görme izni yok.
• Canlı sunuculara, koda veya geliştirici araçlarına erişim yok.

Sam, olay raporunda işaretlenen müşteri kimliklerini kontrol eder ve dahili panoyu kullanarak, yalnızca faturalama kademesi ve kullanım verilerine göre filtreleyip bir rapor çıkarır. İşini yapmak için daha fazlasına ihtiyaç duymaz ve denese bile erişmemesi gereken bir şeye erişemez.

Bu örnekte herkes ihtiyaç duyduğunu alır ve fazlasını değil. Corey yanlışlıkla bir veritabanı tablosunu silemez. Luca’nın yükseltilmiş izinleri zamanla sınırlı ve izlenir durumdadır. Sam, canlı altyapıyı hiç görmeden paydaşlara yanıt verebilir.

En Az Yetki İlkesini Nasıl Uygularsınız?

Şunu söyleyerek başlayayım: PoLP’yi uygulamak için her şeyi bir gecede sil baştan yapmanız gerekmez. Küçük değişiklikler bile büyük fark yaratabilir, bu yüzden küçük başlamak sorun değildir!

Adım 1: Bir ayrıcalık denetimi yapın

Erişimi sıkılaştırmadan önce, kimin neye sahip olduğunu bilmeniz gerekir. Şunları gözden geçirmeniz gerekecek:

• Kullanıcı hesapları (çalışanlar, yükleniciler, servis hesapları)
• Uygulamalar ve entegrasyonlar
• Arka plan süreçleri veya betikler
• Bulut rolleri, veritabanı kullanıcıları, SSH anahtarları; aklınıza gelebilecek her şey.

Paylaşılan kimlik bilgileri, varsayılan hesaplarda kök erişimi veya 2018’den beri dokunulmamış roller gibi kırmızı bayraklara dikkat edin.

Adım 2: Asgari ayrıcalıklarla başlayın

Yeni hesaplar oluştururken (insan ya da makine fark etmez), varsayılan olarak en düşük erişim düzeyini verin. Gerekirse kullanıcıların veya servislerin daha fazlasını talep etmesine izin verin. Bir şeyler ters gittikten sonra aşırı yetkilendirilmiş hesapları temizlemektense, izinleri sonradan eklemek daha kolay (ve daha güvenlidir).

İlk birkaç hafta biraz can sıkıcı olabilir; çok fazla istek alırsınız, ancak herkes rolleri gereği çoğu görevi bir-iki kez tamamladıktan sonra işler dengelenir.

Adım 3: Ayrıcalıkların ayrımını uygulayın

Yönetici ve kullanıcı rollerini ayrı tutun. Birinin ikisine de ihtiyacı varsa (örneğin bir DevOps mühendisi), günlük işler için bir, belirli eylemler için yükseltilmiş haklara sahip başka bir hesap veya oturum kullanın. Bu, kazara (veya kötü niyetli) kötüye kullanım riskini sınırlar.

Adım 4: Anında (JIT) ayrıcalıklar uygulayın

Daha önce tartıştığımız gibi geçici erişim yükseltmesine izin veren araçlar kullanın. Bu şunlara benzeyebilir:

• Süresi dolan veritabanı kimlik bilgileri
• 30 dakika sonra otomatik iptal olan bulut rolleri
• Belirli görevlere bağlı onay iş akışları

Adım 5: Faaliyetleri izleyin ve günlüğe alın

Günlükleme sadece hata ayıklama için değildir. Şunları takip edin:

• Kim neye erişiyor
• Ayrıcalık yükseltmeleri ne zaman gerçekleşiyor
• Rollerde veya izin gruplarında yapılan değişiklikler

Bu veriler, denetimlerde, olay müdahalesinde veya sadece sistemlerinizin günlük kullanımını anlamada altın değerindedir.

Adım 6: Düzenli olarak gözden geçirin ve ayarlayın

En iyi kurulumlar bile zamanla sapar. İş rolleri değişir, ekipler evrilir, eski araçlar kullanım dışı kalır. Kullanılmayan hesapları temizlemek, izinleri ayarlamak ve sorun hâline gelmeden önce ayrıcalık şişmesini tespit etmek için yinelenen incelemeler planlayın (üç ayda bir iyi bir başlangıçtır).

Zorluklar ve Sınırlamalar

Teoride PoLP kulağa kolay gelir: Gerekenden fazla erişim vermeyin. Uygulamada mı? Biraz daha karmaşıktır, özellikle birçok eski sistemin, değişen ekiplerin ve bitmeyen isteklerin olduğu büyük, hızlı hareket eden ortamlarda.

Büyük organizasyonlarda karmaşıklık

Büyük şirketlerde kimsenin kimin neye eriştiğine dair tam bir resmi yoktur. Ekipler örtüşür, sorumluluklar bulanıklaşır ve mevcut izinleri çözmeye çalışmak Jenga oynamaya benzeyebilir. Ekip 1 için gerekmemesi gereken izinleri kaldırırsınız ve bir şekilde bu, Scott’ın işini yapmasını engeller. Meğer Scott, geçen yıl takım değiştirmeden önceki rolü bu olduğu için, tatildeyken Ekip 2’den Matt’in yerine bakıyormuş. PoLP’yi uygulamak genellikle bölümler arası koordinasyon gerektirir; bu da zaman (ve hatırı sayılır diplomasi) ister.

Üretkenlikte yavaşlama riski

Erişimi aşırı agresif şekilde kısıtladığınızda darboğazlara yol açabilir. İnsanlar onayları beklerken tıkanır veya o tek eksik izin verilmeden işlerini yapamaz. Bu, herkesin her işten biraz yaptığı küçük şirketlerde özellikle geçerlidir. Bir startupta, üç hafta boyunca her izin gerektiğinde 2 saat bekledikten (ve haftada en az 5 farklı izne ihtiyaç duyduktan) sonra, yönetici rolü istemiştim. Verildi ve ihtiyacım olandan çok daha fazla erişimim oldu ama en azından işimi yapabildim.

Tüm bunların söylemek istediği, PoLP’yi bürokrasi gibi hissettirmek yapabileceğiniz en kötü şeydir. Akıcı yükseltme iş akışları ve iyi iletişimle birlikte yürütülmesi gerekir.

Genel olarak güvenlik ve üretkenliği dengelemek zordur; özellikle eski sistemlerle ya da genişleyen ekiplerle uğraşırken. how to maintain data security başlıklı blog yazımız, her şeyi yavaşlatmadan pratikte nasıl güvenli kalınacağını inceler.

Her şeyi isteyen eski uygulamalar

Bazı eski sistemler ayrıntılı izinler düşünülerek inşa edilmemiştir. Geniş erişim beklerler ve sıkı kontroller altında çalıştırıldıklarında bozulabilir (veya kullanılamaz hâle gelebilir). Bu durumlarda, uygulamayı yalıtılmış bir alan (sandbox) içinde izole etmeniz, yakından izlemeniz ve daha uzun vadeli çözümleri planlamanız gerekebilir.

Ayrıcalık şişmesi sinsi, izleme emek ister

Zamanla kullanıcılar erişim biriktirir. Birisi “sadece geçici olarak” bir gruba eklenir ve sonra kimse onu çıkarmaz. Bu yavaş, sessiz birikime ayrıcalık şişmesi denir ve düzenli denetimlerin önemli olmasının en büyük nedenlerinden biridir. Altı ay önce mantıklı olan, bugün tamamen gereksiz olabilir. Ayrıca izinleri kusursuz şekilde kısıtlarsanız bile, kimin neyi, ne zaman ve neden kullandığını takip etmeniz gerekir. Sağlam günlükleme ve izleme olmadan PoLP’yi uygulamak zorlaşır ve denetçilere ya da olay müdahalesinde kanıtlamak güçleşir.

Açık konuşalım, PoLP zahmetsiz değildir; yönetmesi de pek ilgi çekici sayılmaz. Yine de yapmaya değer olduğunu kabul etmeliyiz. Ön kapımızı kilitlemek gibi, küçük bir sürtünme karşılığında büyük bir güvenlik sağlar.

Benzer İlkeler ve İlgili Kavramlar

Sıfır Güven mimarileri

Sıfır Güven, eski güvenlik modelini tersine çevirir. Ağın içindeki her şeyin güvenli olduğu varsayımı yerine, her kullanıcıyı, cihazı ve uygulamayı varsayılan olarak güvensiz kabul eder (isterlerse “içeride” olsunlar!).

Sıfır Güven kurulumunda en az yetki sadece iyi bir uygulama değil, zorunludur. Her erişim isteği gerçek zamanlı değerlendirilir ve kullanıcılara veya servislere, genellikle sınırlı bir süre ve belirli bir görev için, gerekli olan asgari erişim verilir.

Bu şu yollarla uygulanır:

• Kullanıcının kim olduğuna, hangi cihazı kullandığına, nerede bulunduğuna ve ne yapmaya çalıştığına dayanan dinamik, ince taneli erişim kontrolleri. Aşağıda bununla ilgili daha fazlası var.
• Sadece oturum açışta değil, sürekli olarak riski değerlendiren ilke motorları.
• Ayrıntılı günlükleme ve otomatik iptalle birleştirilmiş anında erişim.

Sıfır güven mimarisi. Kaynak: Gartner

Ayrıcalık parantezleme

Ayrıcalık parantezlemeden daha önce bahsettik. Bu, ayrıcalıklı bir eylemin gerçekleşmesi gereken tam an için izinleri yükseltme, ardından hemen normale dönme uygulamasıdır.

Genellikle tam yönetici erişimini açık bırakmanın çok riskli olacağı güvenli ortamlarda kullanılır. Örneğin:

• Bir betik düşük ayrıcalıklı bir kullanıcı altında çalışır ancak yalnızca o komut için sudo kullanarak bir sistem servisinin yeniden başlatılmasını gerçekleştirir.
• Bir dağıtım süreci, altyapıyı değiştirmek için geçici olarak ayrıcalıklı bir rol üstlenir, ardından tamamlandıktan sonra erişimi otomatik olarak iptal eder.

Bu, özellikle DevOps ve otomasyonda güçlüdür. Arka plan süreçlerinin 7/24 root olarak çalışması patlamaya hazır bir bombadır.

Güvenilir Hesaplama Tabanını (TCB) en aza indirme

Güvenilir Hesaplama Tabanınız, sisteminizin güvenliğini uygulamak için dayandığı her şeyi kapsar. İşletim sistemi çekirdeği, hipervizörler, kriptografik kütüphaneler ve erişim kontrol mantığı gibi unsurları içerebilir. TCB’niz ne kadar küçükse, denetlemesi ve güvenmesi o kadar kolaydır.

PoLP buna etki eder çünkü aşırı ayrıcalıklı yazılımlar TCB’nizi genişletir. Örneğin bir günlükleme daemoni, keyfî sistem dosyalarına yazabiliyorsa, TCB’nin bir parçası hâline gelir (muhtemelen olmaması gerekirken). Ayrıcalıkları azaltmak, herhangi bir bileşenin sistemi baltalama riskini azaltır.

Güvenli işletim sistemi tasarımı, sanallaştırma, gömülü sistemler veya yüksek güvenlikli bulut ortamlarıyla ilgileniyorsanız TCB en aza indirmeyle karşılaşabilirsiniz.

Öznitelik Tabanlı Erişim Kontrolü (ABAC)

Geleneksel erişim kontrolünün “yönetici” veya “destek” gibi statik rollere dayandığı yerde, ABAC kararları özniteliklere, yani kullanıcı, kaynak veya istekle ilgili bağlamsal verilere dayanarak verir.

Örneğin:

• “Kullanıcı İK departmanındaysa ve şirket cihazı kullanıyorsa ve mesai saatleri içindeyse erişime izin ver.”
• “İstek kurumsal VPN dışından geliyorsa hassas verilere erişimi engelle.”

ABAC, değişen koşullara uyum sağlayan, gerçek zamanlı ve ince ayarlı erişim kararlarına olanak verdiği için Sıfır Güven ortamlarının kilit bir parçasıdır. PoLP’nin yerini almaz; asgari temel izinlerin üzerine bağlamsal izinler katmanlayarak onu güçlendirir.

Önemli Noktalar

Tamam, bayağı bilgiydi! Umarım PoLP’yi artık biraz daha iyi anlıyorsunuzdur. Unutmayın:

• Erişim her zaman kasıtlı olmalıdır. Kullanıcılar, sistemler ve uygulamalar yalnızca işlerini yapmak için gerçekten ihtiyaç duydukları izinlere sahip olmalıdır; fazlası, kalıcısı ve “ne olur ne olmaz”ı olmamalıdır.
• PoLP sadece insanlar için değildir. Servis hesapları, betikler, API’ler, IoT cihazları, konteynerler… birbirleriyle konuşabilen her şey için geçerlidir.
• Ayrıcalık şişmesi gerçektir. Düzenli incelemeler olmadan insanlar artık ihtiyaç duymadıkları izinleri biriktirir. Periyodik denetimler ve iyi kapsamlanmış roller işleri düzenli tutmaya yardımcı olur.
• Anında ve geçici erişimler dostunuzdur. Ayrıcalıkları anlık olarak yükseltin, sonra geri alın. Bir sistemin yüksek ayrıcalık durumunda geçirdiği süre ne kadar azsa o kadar iyi.

Kısa vadede öyle görünebilir ama PoLP hayatınızı zorlaştırmakla ilgili değildir. Kaçınılmaz olarak meydana geldiğinde, hataları ve ihlalleri daha az maliyetli hâle getirmekle ilgilidir!