- Uygulama geliştirilir.
- Sunucular kurulur.
- Ağ bağlantıları açılır.
- Kullanıcılar tanımlanır.
- Sistem üretime alınır.
- Hangi kullanıcı hangi kaynağa erişebilir?
- Bir kullanıcı hesabı ele geçirilirse saldırgan nereye kadar ilerleyebilir?
- Bir sunucu ele geçirilirse diğer sistemlere geçiş mümkün müdür?
- Uygulama gerçekten ihtiyaç duymadığı sistemlerle konuşabiliyor mu?
- Bir servis hesabının gereğinden fazla yetkisi var mı?
- İç ağda olmak neden güvenilir kabul ediliyor?
- Yönetici hesabı günlük işlerde de kullanılıyor mu?
- Bir saldırgan sisteme girdiğinde onun hareketlerini görebiliyor muyuz?
1. Güvenli sistem tasarlamak ne demektir?
Güvenli sistem tasarlamak: “Her yere güvenlik ürünü koymak” demek değildir. Daha temel bir yaklaşım gerektirir. Örneğin bir sistem daha tasarım aşamasında şu özelliklere sahip olabilir:
- Yalnızca ihtiyaç duyduğu ağ bağlantıları açık,
- Kullanıcı ve servisler minimum yetkiyle çalışıyor,
- Yönetici hesapları normal kullanıcı hesaplarından ayrılmış,
- Kritik sistemler birbirlerinden mantıksal olarak ayrıştırılmış,
- Dışarıya açılan servisler sınırlandırılmış,
- Hassas veriye erişim açıkça tanımlanmış,
- Kimlik doğrulama yalnızca parolaya dayanmıyor,
- Erişim kararlarında kullanıcı kadar cihaz ve bağlam da dikkate alınıyor,
- Güvenlik olayları izlenebilir şekilde kaydediliyor,
- Bir sistem ele geçirilse bile saldırganın bütün kuruma yayılması zorlaştırılıyor.
2. Saldırı yüzeyi nedir?
Bir sistemin saldırı yüzeyi, saldırganın sisteme girebileceği, veri gönderebileceği, işlem yaptırabileceği veya sistemden veri çıkarabileceği noktaların bütünüdür.
OWASP, saldırı yüzeyini uygulamaya veri veya komut giriş-çıkışı sağlayan yollar, bu yolları koruyan kod ve mekanizmalar, değerli veriler ile bunları koruyan bileşenler açısından ele almaktadır.
Saldırı yüzeyi analizinin amacı hangi bölümlerin güvenlik açısından incelenmesi gerektiğini, yüksek riskli alanların nerede bulunduğunu ve sistem değiştikçe saldırı yüzeyinin nasıl değiştiğini anlamaktır. Bir web uygulamasında saldırı yüzeyi örneğin şunlardan oluşabilir:
- İnternet üzerinden erişilebilen web sayfaları,
- API uç noktaları,
- VPN bağlantıları,
- Uzak yönetim servisleri,
- Yönetim panelleri,
- Dosya yükleme alanları,
- Kimlik doğrulama ekranları,
- Mobil uygulamalar,
- Üçüncü taraf entegrasyonları,
- Bulut servisleri,
- E-posta geçitleri,
- Servis hesapları,
- Kullanıcı cihazları.
- Bir kullanıcının erişebildiği paylaşımlar,
- Servis hesapları,
- Yönetim portları,
- Yanlış yetkilendirilmiş veri tabanları,
- Ortak parolalar,
- Aşırı yetkili hesaplar
3. Güvenli tasarımın ilk ilkelerinden biri: İhtiyacın olmayan şeyi açma
Saldırı yüzeyini azaltmanın en etkili yöntemlerinden biri basittir: İhtiyaç duyulmayan hizmeti, portu, hesabı, API'yi veya erişim yolunu oluşturmamak.
Bir sistemde saldırganın kullanabileceği yüz ayrı giriş noktası yerine yirmi giriş noktası varsa savunulması gereken alan da küçülür. Bu nedenle sistem tasarlanırken şu sorular sorulmalıdır:
- Bu servis neden açık?
- Bu port gerçekten gerekiyor mu?
- Bu API'yi kim kullanıyor?
- Bu yönetim panelinin internete açık olması gerekiyor mu?
- Bu eski kullanıcı hesabı neden hâlâ aktif?
- Bu uygulamanın internet erişimine gerçekten ihtiyacı var mı?
- Bu sistem neden diğer bütün sunucularla iletişim kurabiliyor?
4. Güvenliğin merkezinde ağdan önce kimlik vardır
Uzun yıllar kurumsal güvenlik modellerinin önemli bölümü şu varsayıma dayanıyordu: Dış ağ tehlikelidir. ve İç ağ daha güvenlidir. Bu nedenle kurumun dış sınırına güçlü bir firewall konulur ve içerideki sistemlere daha geniş güven verilebilirdi. Ancak günümüz ortamlarında:
- Uzaktan çalışan personel,
- Bulut sistemleri,
- Mobil cihazlar,
- SaaS hizmetleri,
- Üçüncü taraf erişimleri,
- Hibrit altyapılar
bu sınırı giderek belirsizleştirmiştir. Daha önemlisi, saldırgan bir kullanıcı hesabını veya kurumsal cihazı ele geçirdiyse teknik olarak içeride bulunabilir. Bu durumda: “İç ağdan geliyor, o halde güvenilir.” varsayımı tehlikeli hale gelir.
5. Zero Trust “kimseye güvenme” demek değildir
- Kim?
- Hangi cihazdan?
- Hangi kaynağa?
- Hangi yetkiyle?
- Hangi koşullarda?
sorularıyla değerlendirilir. Örneğin bir çalışan normal şartlarda muhasebe uygulamasına erişebiliyor olabilir. Fakat:
- Bilinmeyen cihazdan,
- Olağan dışı coğrafi noktadan,
- Riskli bir oturumdan,
- Normal dışı zamanda
6. Zero Trust bir ürün değildir
Piyasada: “Zero Trust çözümü” olarak sunulan birçok teknoloji bulunabilir. Ancak Zero Trust tek başına satın alınabilecek bir cihaz veya yazılım değildir.
NIST bunu bir mimari yaklaşım ve güvenlik paradigması olarak ele almaktadır. Uygulamada aşağıdaki teknolojiler Zero Trust mimarisine katkıda bulunabilir:
- IAM,
- MFA,
- PAM,
- EDR,
- MDM,
- ZTNA,
- Mikro segmentasyon,
- Kimlik tabanlı erişim,
- Cihaz duruş değerlendirmesi,
- Merkezi politika motorları,
- SIEM ve davranış analitiği.
7. Kimlik doğrulama ile yetkilendirme aynı şey değildir
Bu ayrım temel olmasına rağmen çok önemlidir. Authentication - Kimlik doğrulama “Sen kimsin?” sorusudur. Parola, MFA, sertifika veya başka mekanizmalar kullanılabilir. Authorization - Yetkilendirme “Kim olduğunu doğruladık; peki ne yapmana izin var?” sorusudur.
Bir kullanıcının kimliğinin doğrulanmış olması bütün verilere ulaşabileceği anlamına gelmez. Örneğin: Bir personelin kurumsal kullanıcı olduğu doğrulanabilir. Ancak bu personel:
- İnsan kaynakları kayıtlarını okuyabilir mi?
- Maaş bilgilerini değiştirebilir mi?
- Sunucuda yönetici olabilir mi?
- Logları silebilir mi?
8. En az ayrıcalık: Kullanıcıya “lazım olabilir” diye yetki verilmemelidir
Güvenli sistem tasarımının temel ilkelerinden biri: Least Privilege - en Az Ayrıcalık ilkesidir.
NIST bunu kullanıcıların veya kullanıcı adına çalışan süreçlerin, görevlerini gerçekleştirmek için gerekli olan asgari yetkilere sahip olması olarak tanımlar. Basit örnek:
Bir çalışanın yalnızca bir dosyayı okuması gerekiyorsa: okuma yetkisi yeterlidir. Aynı kullanıcıya: değiştirme + silme + yetki verme haklarının verilmesi gereksizdir. Aynı prensip yalnızca insanlara uygulanmaz. Uygulamalar ve servis hesapları için de geçerlidir.
Örneğin bir uygulamanın veri tabanından yalnızca belirli tabloları okuması gerekiyorsa tüm veri tabanında yönetici yetkisi verilmemelidir.
9. Aşırı yetki neden bu kadar tehlikelidir?
Bir saldırgan bir kullanıcı hesabını ele geçirdiğinde saldırganın ilk yetkisi genellikle hesabın sahip olduğu yetkidir. Dolayısıyla: Kullanıcının yetkisi = başlangıçta saldırganın yetkisi haline gelebilir. Eğer normal kullanıcı:
- Kritik paylaşımlara erişebiliyor,
- Başka sunuculara oturum açabiliyor,
- Yazılım yükleyebiliyor,
- Sistem ayarlarını değiştirebiliyorsa
tek bir hesap ele geçirilmesi çok daha büyük zarara dönüşebilir. En az ayrıcalık, bu nedenle saldırının gerçekleşmesini her zaman engellemez. Ama saldırganın etki alanını küçültür.
10. Yönetici hesabı günlük hesap olmamalıdır
Özellikle ayrıcalıklı hesaplar güvenlik mimarisinin kritik parçalarıdır. Örneğin bir sistem yöneticisinin: muhammedyusuf@abc.local isimli normal hesabıyla e-posta okuması ve web'e erişmesi;
- Aynı hesabın aynı zamanda: Domain Administrator yetkisine sahip olması ciddi risk oluşturur.
- Daha güvenli tasarımda: Normal kullanıcı hesabı ile
- Ayrıcalıklı yönetim hesabı ayrılabilir.
Böylece günlük kullanıcı oturumu ele geçirilse bile saldırgan doğrudan yönetim ayrıcalığı elde etmeyebilir.
NIST SP 800-53 Rev. 5'in Least Privilege kontrolleri, ayrıcalıklı hesapların sınırlandırılması, ayrıcalıkların düzenli gözden geçirilmesi ve ayrıcalıklı fonksiyonların kullanımının kaydedilmesi gibi uygulamaları içerir.
11. Ağ segmentasyonu neden hâlâ önemlidir?
Zero Trust ağın artık önemsiz olduğu anlamına gelmez. Tam tersine ağ ayrıştırması saldırganın hareket kabiliyetini azaltmak için hâlâ güçlü bir kontroldür.
Örneğin tek ve düz bir ağ düşünelim: Kullanıcı bilgisayarı → Dosya sunucusu → Veri tabanı → Yedekleme sunucusu → Domain Controller birbirine geniş şekilde erişebiliyor.
Bir kullanıcının bilgisayarı ele geçirildiğinde saldırgan ağ içerisindeki diğer sistemleri keşfetmeye ve bunlara erişmeye çalışabilir. Bu hareket: lateral movement — yatay hareket olarak adlandırılır. Daha kontrollü mimaride ağ:
- Kullanıcı bölgesi,
- Uygulama bölgesi,
- Veri tabanı bölgesi,
- Yönetim bölgesi,
- Güvenlik araçları bölgesi,
- Yedekleme bölgesi
12. “İçerideki her şey birbirini görebilir” yaklaşımı neden risklidir?
Hayali bir kurumda 1.000 bilgisayar olduğunu düşünelim. Bütün kullanıcı bilgisayarları birbirleriyle ve sunucularla sınırsız konuşabiliyor. Bir kullanıcı bilgisayarına kötü amaçlı yazılım bulaştığında saldırgan artık önemli bir keşif alanına sahip olabilir.
Ancak mimari: Kullanıcı bilgisayarı yalnızca ihtiyaç duyduğu uygulama servislerine erişebilir şeklinde tasarlanmışsa saldırganın hareket alanı küçülür.
13. Servis hesapları neden unutulmamalıdır?
Kurumsal sistemlerde yalnızca insan kimlikleri bulunmaz. Aynı zamanda:
- Uygulama hesapları,
- API kimlikleri,
- Makine kimlikleri,
- Servis hesapları,
- Sertifikalar,
- Erişim anahtarları,
- Token'lar
vardır. Modern altyapılarda bunların sayısı insan hesaplarından bile fazla olabilir. Zero Trust yaklaşımında bu nedenle yalnızca: “Kullanıcı kim?” değil, “Servis kim?” sorusu da önem kazanır.
NIST SP 800-207A, özellikle bulut ve mikroservis ortamlarında ağ konumundan kimlik temelli politikalara geçişi; kullanıcı kimliğinin yanında uygulama ve servis kimliklerinin de erişim kararlarına dahil edilmesini, ele almaktadır.
14. Bir sistemi güvenli yapan şey yalnızca erişimi engellemek değildir
Erişim kontrolleri güçlü olabilir. Ama saldırgan bir şekilde içeri girdiğinde onu göremiyorsak başka bir problem vardır. Bu nedenle güvenli sistem tasarımı görünürlük de gerektirir. Örneğin şunlar kaydedilebilmelidir:
- Kullanıcı oturumları,
- Başarısız girişler,
- Yetki değişiklikleri,
- Ayrıcalıklı işlemler,
- Uygulama hataları,
- Yönetim işlemleri,
- Veri erişimi,
- Güvenlik politikası değişiklikleri.
15. Defense in Depth: Tek kontrolün başarısına güvenmemek
Parola
↓
MFA
↓
Cihaz güvenlik kontrolü
↓
Erişim politikası
↓
En az ayrıcalık
↓
Ağ segmentasyonu
↓
EDR
↓
Loglama / SIEM
↓
Veri erişim kontrolü
Bir kontrol başarısız olduğunda, diğerleri saldırganı durdurabilir veya en azından etkisini azaltabilir.
CISA'nın Secure by Design yaklaşımı da güvenlik mekanizmalarının ürünün tasarımına baştan yerleştirilmesini ve birden fazla savunma katmanının kullanılmasını önermektedir.
16. Secure by Design ne demektir?
Secure by Design yaklaşımının temel düşüncesi şudur: Güvenlik, ürün veya sistem tamamlandıktan sonra, müşterinin üzerine bırakılacak ek bir sorumluluk olmamalıdır.
CISA ve uluslararası ortaklarının Secure by Design yaklaşımı, teknoloji üreticilerinin müşteri güvenliği sonuçlarının sorumluluğunu daha fazla üstlenmesini; tehditlerin tasarım sırasında dikkate alınmasını ve güvenli varsayılanların kullanılmasını savunmaktadır.
Örneğin bir ürün: varsayılan parola ile geliyorsa kullanıcıdan bunu değiştirmesini beklemek yerine, hiç varsayılan parola kullanmamak daha güçlü bir tasarımdır.
Benzer şekilde: Güvenlik özelliğini müşterinin ayrıca satın alması veya elle etkinleştirmesi gerekiyorsa güvenlik büyük ölçüde kullanıcı davranışına bırakılmış olur.
17. Hayali bir kurum üzerinde güvenli mimari
Şimdi önceki yazılarda kullandığımız Kurum X örneğine dönelim. Vatandaşların başvuru yaptığı internet portalımız olsun. Basitleştirilmiş yapı:
İnternet
↓
WAF / Reverse Proxy
↓
Web/Uygulama Katmanı
↓
Veri Tabanı
- Portal ayrıca: Kimlik Doğrulama Sistemi ile iletişim kuruyor.
- Kurum personeli yönetim işlemlerini farklı bir: Yönetim Ağı üzerinden gerçekleştiriyor.
- Loglar: Merkezi SIEM/Log Platformuna aktarılıyor.
- Yedekleme sistemi ise: ayrı güvenlik alanında tutuluyor.
- Örneğin internet kullanıcısının, veri tabanına doğrudan erişmesi gerekmez.
- Web katmanının, Domain Controller üzerinde yönetici olması gerekmez.
- Veri tabanının, doğrudan internete çıkması gerekmeyebilir.
- Normal kullanıcı cihazlarının, yedekleme sunucusuna erişmesine gerek yoktur.
- Sistem yöneticisinin, internetten doğrudan kritik sunucuya yönetici oturumu açması gerekmeyebilir.
18. Bir kullanıcı hesabı ele geçirilirse ne olmalı?
İyi güvenlik mimarisini test etmenin güçlü yollarından biri şu sorudur: “Bir kullanıcı hesabının ele geçirildiğini varsayalım. Sonra ne olur?” Zayıf mimaride:
Kullanıcı hesabı ele geçirildi
↓
İç ağa erişim
↓
Sunucular keşfedildi
↓
Yetki yükseltildi
↓
Domain Admin elde edildi
↓
Yedek sistemlere erişildi
↓
Kurum genelinde ransomware
- MFA ilk erişimi zorlaştırabilir.
- Cihaz kontrolü bilinmeyen cihazı engelleyebilir.
- Least Privilege hesabın erişimini sınırlar.
- Segmentasyon diğer sistemlere geçişi zorlaştırır.
- PAM ayrıcalıklı hesaplara erişimi sınırlar.
- EDR şüpheli davranışı tespit edebilir.
- SIEM farklı olayları birleştirerek alarm üretebilir.
- İzole yedek son aşamada kurtarma imkânı sağlayabilir.
19. Zero Trust olgunluğu bir gecede oluşmaz
Bir kurumun mevcut altyapısını bir gecede tamamen Zero Trust mimarisine dönüştürmesi çoğu zaman gerçekçi değildir. CISA'nın Zero Trust Maturity Model Version 2.0 çalışması dönüşümü beş temel sütun üzerinden ele alır:
- Identity
- Devices
- Networks
- Applications & Workloads
- Data
ve bunlara ek olarak görünürlük/analitik ile otomasyon/orkestrasyon gibi yatay yetenekleri değerlendirir. Bu yaklaşım bize önemli bir ders verir:
20. Güvenli Sistem Tasarım Modeli
Bir sistem tasarlanırken aşağıdaki değerlendirme zinciri kullanılabilir.
- Neyi koruyoruz?
- Veri mi?
- Uygulama mı?
- Kritik hizmet mi?
- Veri nereden geliyor?
- Nereye gidiyor?
- Hangi sistemlerden geçiyor?
- Sisteme hangi yollarla girilebilir?
- Sistemden hangi yollarla veri çıkarılabilir?
4 — Gereksiz yolları kaldır
- Portlar,
- Hesaplar,
- API'ler,
- Servisler,
- Ağ bağlantıları
- Makineler,
- Servisler,
- Uygulamalar
- Kim?
- Hangi cihaz?
- Hangi kaynak?
- Hangi yetki?
- Hangi koşul?
Bu yapıyı: Güvenli Sistem Tasarım Zinciri olarak ifade edebiliriz.
21. Güvenli tasarımda sorulması gereken 15 soru
Bir sistem değerlendirmesinde şu sorular güçlü bir başlangıç sağlayabilir:
- Bu sistem hangi kritik hizmeti destekliyor?
- Hangi hassas verileri işliyor?
- İnternete açık hangi bileşenleri var?
- Kullanılmayan servis veya portlar var mı?
- İnsan ve makine kimlikleri nelerdir?
- MFA nerelerde uygulanıyor?
- Hangi hesaplar ayrıcalıklı?
- Yetkiler gerçekten gerekli mi?
- Yönetici hesapları günlük hesaplardan ayrılmış mı?
- Sistem hangi diğer sistemlerle iletişim kurabiliyor?
- Bu bağlantıların tamamı gerekli mi?
- Bir bileşen ele geçirilirse saldırgan nereye ilerleyebilir?
- Kritik erişimler loglanıyor mu?
- Loglar saldırgan tarafından değiştirilebilir mi?
- Ana sistem kaybedilirse güvenilir ortamdan nasıl toparlanacağız?
22. Sık yapılan güvenlik mimarisi hataları
Sonuç: Güvenli sistem, saldırganın hiç giremeyeceği sistem değildir
Mutlak güvenlik diye bir durum yoktur. Bu nedenle güçlü bir güvenlik mimarisinin hedefi: “Saldırgan hiçbir zaman içeri giremez.” varsayımına dayanamaz.
Bu düşünce bize birkaç temel ilke verir:
- Gereksiz saldırı yüzeyini azalt.
- Kimliği ağ konumundan daha önemli hale getir.
- Yetkiyi minimumda tut.
- Tek bir güvenlik kontrolüne güvenme.
- Bir sistemin ele geçirilmesinin diğerlerini otomatik olarak düşürmesine izin verme.
- Güvenliği en baştan tasarla.
Zero Trust'ın özü de burada ortaya çıkar. Zero Trust: bir ürün, bir firewall, bir VPN alternatifi veya yalnızca MFA değildir.
Zero Trust: Güveni varsaymak yerine her erişim talebini kaynak, kimlik, cihaz, yetki ve bağlam temelinde değerlendiren bir mimari düşüncedir.