Azure IaaS’te Savunma Katmanları: Güvenlik Nasıl Oturuyor?
Bir katman düşerse, diğerinin ayakta kalması
Açık konuşayım, Bulutta güvenlik konuşurken çoğu ekip hâlâ tek bir kapıya bakıyor. Firewall var mı? MFA açık mı? Log geliyor mu? Bunlar tabiî önemli,. Işin aslı şu: modern saldırılar tek yerden girmiyor; kimlikten giriyor, paket yönetiminden giriyor, yanlış yetkiden giriyor, bazen de doğrudan kontrol düzlemini yokluyor. Azure IaaS tarafında hoşuma giden şey tam burada başlıyor; güvenliği tek bir ürün gibi değil, bir sistem gibi kuruyor.
📋 İçindekiler
Şöyle söyleyeyim, Ben bunu sahada defalarca gördüm (kendi tecrübem). 2024’ün sonlarına doğru Ankara’da bir üretim firmasında yaptığımız değerlendirmede ekip “VM’ler güvenli mi?” diye sordu. Cevap tek satır değildi. Host güveni ayrıydı, ağ ayrımı ayrıydı, disk şifreleme ayrıydı, izleme ayrıydı… Hepsi birlikte çalışınca anlam kazanıyordu. Tek başına güzel görünen kontrol, pratikte bazen ince buz üstünde yürümek gibi kalıyor.
Azure’un yaklaşımı bana hep şu benzetmeyi hatırlatıyor: Evde sadece ön kapıyı kilitlemek yetmez; pencereyi de düşünürsün, alarmı da düşünürsün, anahtarı kimde tuttuğunu da düşünürsün (yanlış duymadınız). Savunma derinliği dediğimiz şey bu kadar gündelik aslında. Kağıt üstünde süper dürüyor, pratikte işe disiplin istiyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Secure by design: Güvenliği sonradan eklememek
Secure by design kısmı biraz sıkıcı görünebilir ama bence en can alıcı yer burası. Çünkü bazı ekipler sistemi kuruyor, sonra “güvenliği nereye koyacağız?” diye düşünüyor. İş işten geçmiş oluyor. Neyse, azure IaaS tarafında güvenlik mimarinin içine gömülü geliyor; yanı host doğrulaması, sanallaştırma izolasyonu. Platform davranışı baştan buna göre tasarlanıyor.
İtiraf edeyim, Ben 2019’da İstanbul’daki bir finans müşterisinde benzer bir yapıyı kendi lab ortamımda test etmiştim. O zamanlar özellikle host-level trust kavramını anlatmak zor olmuştu; çünkü ekipler bunu çoğu zaman görünmez sayıyor. Oysa görünmeyen katmanlar bazen en çok fark yaratan yer oluyor. Bir sunucu açılıyor ama önce platform onun gerçekten beklenen yazılım ve donanım durumunda olduğunu doğruluyor, sonra iş yükünü koşturuyor. Sız hiç denediniz mi? Kulağa basit geliyor ama ciddi mesele.
Bu yaklaşımın güzel tarafı şu: sız daha VM ayağa kalkmadan önce temelin sağlam olup olmadığını biliyorsunuz. Eksik tarafı da var tabiî; her şeyi (söylemesi ayıp) otomatik ve sihirli sanarsanız yanılırsınız. İşte, secure by design size iyi bir zemin verir, ama yanlış yapılandırılmış kimlik veya gereksiz açık port yine can yakar.
Durun, bir saniye.
Host güveni neden önemli?
Şöyle ki, Açık konuşayım, birçok kurum host seviyesini hiç görmüyor bile. Görmedikleri şeylere bütçe ayırmak zor oluyor ya hani… Ama saldırganın hedefi çoğu zaman tam orası oluyor: hypervisor katmanı, boot zinciri veya çalışma zamanı bütünlüğü. E peki, sonuç ne öldü? Azure burada platform seviyesinde sağlam kontroller koyarak işinizi bayağı kolaylaştırıyor.
Geçen yıl İzmir’de bir lojistik firmasının migrasyonunda bunu net hissettik. Ekip başlangıçta “bize ağ güvenliği yeter” diyordu; sonra log korelasyonunu ve host sinyallerini görünce fikir değişti. Ben de içimden “işte budur” dedim (buna dikkat edin)
Secure by default: Ayar yapmadan koruma
Şimdi gelelim en sevdiğim kısımlardan birine: secure by default. Yanı sız ekstra çaba harcamadan makul korumaların zaten açık gelmesi. Bu özellikle büyük kurumsal yapılarda altın değerinde. İlginç, değil mi? Her servis için manuel sertleştirme yapmak hem zaman alıyor hem de insan hatasına çok açık. Bu konuyla ilgili Kubernetes v1.36: CCM Route Sync Metriği Neyi Ele Veriyor? yazımıza da göz atmanızı tavsiye ederim.
İşin garibi, Küçük startup ile enterprise arasında burada fark bayağı belirginleşiyor. Küçük ekiplerde hız önemli olduğu için “default olarak güvenli” model direkt hayat kurtarıyor; tek kişi üç işi aynı anda yaparken yanlışlıkla internete açık VM bırakabiliyor. Herkes yoğun oluyor. Enterprise tarafta işe mesele hızdan çok tutarlılık oluyor; yüzlerce subscription içinde aynı standardı sürdürmek zorundasınız. azure ile ilgili önceki yazımız yazımızda bu konuya da değinmiştik.
Bunu fiyat açısından da düşünmek lazım. Türkiye’de TL bazında bakınca bazı ekipler ek güvenlik ürünlerine mesafeli dürüyor; haklılar da bazen bütçe dar oluyor. Böyle durumda önce default korumaları doğru kullanmak gerekiyor. Her sorun için pahalı üçüncü parti araç almak yerine Azure’un varsayılanlarını düzgün açıp yapılandırmak çoğu senaryoda daha mantıklı çıkıyor. Daha fazla bilgi için Prompt Injection’ı Durdurmak: Agent Framework’te FIDES yazımıza bakabilirsiniz. Bu konuyla ilgili MSVC Build Tools Preview Mayıs 2026: Derleyicide Sessiz Ama Kritik Güncellemeler yazımıza da göz atmanızı tavsiye ederim.
| Katman | Neyi korur? | Sahada etkisi |
|---|---|---|
| Ağ | Lateral movement ve maruziyet | Açık port karmaşasını azaltır |
| Depolama | Veri gizliliği ve bütünlük | Dışarı sızsa bile veri okunamaz hâle gelir |
| Konürgü (Compute) | İzolasyon ve çalışma zamanı | Kötü komşu etkisini sınırlayabilir |
| Operasyon | Tespit ve müdahale | Sorun büyümeden sinyal verir |
Ağ, şifreleme ve hesaplamada varsayılan koruma
Bi saniye — Ağ tarafında secure defaults deyince akla hemen NSG geliyor ama olay bundan biraz geniş. Segmentasyon var, trafik akışı var, yönetim uçları var… İdare eder görünen bir network tasarımıyla gerçek hayatta uzun süre rahat etmiyorsunuz. Çünkü içerideki hareket dışarıdan daha sessiz olur; saldırgan içeride dolaşmaya başladı mı gürültü azalır.
Yanı, Azure Functions’ta Retry Fırtınasını Durdurmak: Backoff ve Circuit Breaker
Yanı, Bütün bunların üstüne şifreleme geldiğinde tablo netleşiyor: veri diskte korunuyor olsa bile anahtar yönetimi zayıfsa iş bitmiş sayılmaz. Bu konuda ilk bir düşüneyim… denediğimde Key Vault erişiminde hataya düşmüştüm; yanlış rol ataması yüzünden disk şifre çözme süreci tıkanıyordu. Tahmin eder mısınız? Çözümü basitti ama vakit kaybettirdi: yetki modelini gözden geçirmek ve minimum izinle ilerlemek gerekiyordu (ki bu çoğu kişinin gözünden kaçıyor)
Şöyle söyleyeyim, Bazen güzel özellik ama henüz ham hissi veren noktalar da çıkıyor ortaya mesela işletme süreçleri yeterince olgun değilse insanlar teknolojiye değil kendi alışkanlıklarına dönüyorlar o yüzden sadece servisi açmak yetmiyor operasyonu da eğitmek gerekiyor neyse uzatmayayım bu kısım tam olarak öyle (ben de ilk duyduğumda şaşırmıştım)
MFA ile bitmiyor işin hikâyesi
Kimi kurumlar “kimlik güçlü öldü mu tamamdır” diye düşünüyor fakat bu fazla iyimser kalabiliyor Kimlik merkezî yaklaşım elbette şart ancak ağ katmanı ile birleşmeyince savunma delikli kalıyor Ben AZ-305’e hazırlanırken hep bunu tekrar ettim çünkü mimarı soruların çoğu tek çözüm istemez beraber çalışan parçaları isterdi İşte tam bu yüzden defense in depth bana sınav konusu olmaktan çok saha refleksi gibi geliyor.
Tek bir kontrol seni kurtarmayacak diye korkmana gerek yok; asıl mesele kontrol setlerinin birbirini tamamlamasıdır.
Süreklilik olmadan güvenlik olmaz
İzleme kısmını atlayan her ekip geç kalmaya mahkûm kalıyor biraz sert öldü ama doğru Monitöring demek sadece alarmlar yanıyor mu demek değil sinyal korelasyonu yapmak demek örneğin oturum açma denemesi artmış mı ağ trafiği değişmiş mi VM agent susmuş mu bunların hepsi birlikte okunmalı Yoksa log yığınına bakıp kafanız karışır sadece. PowerShell Paketlerini Güvenli Yönetmek: PSResourceGet’te Yeni Dönem yazımızda bu konuya da değinmiştik.
Coplilot cloud agent ile kırık pipeline işi çözen ekiplerde de aynı dersi gördüm aslında otomasyon varsa gözünüz sürekli açık olmak zorunda değil. Otomasyonun ürettiği sinyali anlamazsanız sorun yine kaçıyor Bir keresinde Dubai’de çalışan bir müşteride ufacık görünen yönetici hesabı anomalisi bize ileride oluşacak daha büyük hareketin erken uyarısını vermişti Sonradan baktık ki olayın kökü yetki devriymiş Yanı hani küçük sinyal büyük resmî taşıyor bazen.
Durun, bir saniye.
- Anormal girişleri toplayın. — bunu es geçmeyin
- Ağ davranışını eşleştirin.
- Etkilenen VM’leri önceliklendirin.
- Müdahale planını önceden yazın.
Küçük ekip mi büyük organizasyon mu?
Küçük ekipseniz basit başlayın merkezî log toplama birkaç can alıcı alarm net rol dağılımı Büyük enterprise yapıda işe olay daha serttir çünkü uyumluluk regülasyon denetim zinciri devreye girer orada SIEM entegrasyonu SOAR akışları. RBAC tasarımı iyice önem kazanır Az önce küçük başlayın dedim ama şimdi geri dönüp düzelteyim tamamen küçük kalın demiyorum ölçek büyüyorsa gözünüz de büyümeli yanı anlayacağınız işler doğal olarak genişliyor…
Bende bıraktığı genel izlenim ne?
Bence Azure’un bu yaklaşımı doğru yönde atılmış sağlam bir adım Ama eksik olan şeylerin farkında olmak lazım Mesela bazı kurumlar teknik katmanı hızlı toparlıyor fakat yönetişim kısmını unutuyor Güzel makineler kuruluyor ardından sahiplik belirsizleşiyor Bu hayal kırıklığı yaratan klasik tabloyu ben epey gördüm Logosoft tarafında yaptığımız projelerde teknik başarı kadar operasyonel sahiplenme de can alıcı çıktı aksi hâlde güzel kurgu raflarda tozlanıyor resmen.
Sahada işe yarayan ilk üç adım
# Basit kontrol listesi
1) Public endpoint var mı?
2) Yönetici rolleri gereksiz geniş mi?
3) Disk şifreleme aktif mi?
4) Log Analytics'e veri akıyor mu?
5) Kritik alarmlar test edildi mi?
E tabi bütçe kısıtlıysa pahalı savunma paketlerinden önce mevcut Azure özelliklerini düzgün kurmayı deneyin Microsoft Defender for Cloud temel seviyede bile ciddi fark yaratabiliyor Ama her şeyi onun sırtına yüklemek de hata olur Bulut güvenliği tek ürüne emanet edilmez Ben böyle düşünüyorum Hatta biraz sert söyleyeceğim en pahalı araç bile kötü mimariyi düzeltmez yalnızca hatayı daha görünür yapar…
Sıkça Sorulan Sorular
Azure IaaS’te defense in depth ne demek?
Aslında — hayır dur, daha doğrusu birkaç bağımsız güvenlik katmanının birlikte çalışması demek. Mesela ağ bozulsa bile kimlik kontrolü devrede kalıyor, ya da bir katman hata verse bile diğeri riski sınırlamaya devam ediyor. Kısacası tek duvara yaslanmıyorsunuz — bence bu yaklaşımın en güzel tarafı da bu zaten.
Neden secure by default önemli?
Şöyle düşünün: herkesin her servisi manuel olarak sertleştirmeye vakti olmuyor (ben de ilk duyduğumda şaşırmıştım). Varsayılan olarak güvenli gelen bir yapı insan hatasını ciddi ölçüde azaltıyor. Bilhassa de büyük ortamlarda tutarlılığı da bir hayli artırıyor — tecrübeme göre bu farkı en çok ekip büyüdüğünde hissediyorsunuz.
Küçük şirketler bu modeli nasıl uygulamalı?
Önce erişimi daraltın, sonra log toplamayı bir düzene sokun, ardından kritik kaynaklara segmentasyon uygulayın. Hani çok araç almaya gerek yok açıkçası. İlk aşamada sadece düzeni kurmak bile yeterli oluyor.
Sadece MFA açmak yeter mi?
Hayır, yetmiyor. MFA iyi bir başlangıç tabiî ama yanı network segmentation, encryption, monitöring. Least privilege ile desteklenmezse boşluk kalıyor. Güvenlik zincir gibi işliyor — zayıf halka bütün resmî etkiliyor (inanın bana)
Kaynaklar ve İleri Okuma
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
3 comments