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
-
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
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
💡 Bilgi: Denemek istiyorsanız ilk iş şunu yapın: hayatı subscription’larda erişimleri daraltın, temel logları açın ve dışa açık yüzeyi haritalayın.# 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
Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.Aşkın KILIÇYazar20+ 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.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
İlginizi Çekebilir
Gökhan İ.
Azure’da “bir şeyler kurdum, güvendeyim” diye düşünürken bu yazıyı okuyunca fark ettim ki kimlik katmanını ayarlamışım ama disk şifreleme konusunda hiç kafa yormamışım. Özellikle izleme kısmını biraz daha detaylı ele alsanız güzel olur, hangi alertları kritik kabul etmek gerekiyor mesela?
Emre Ç.
Özellikle disk şifreleme katmanını çoğu zaman atlıyoruz, “zaten ağ güvenliği var” diyip geçiyoruz. Ama bir katman devre dışı kalınca diğerlerinin ne kadar kritik olduğu anlaşılıyor. Secure by design yaklaşımını sonradan yamaya çalışmak gerçekten pahalıya patlıyor.
Alp Y.
Disk şifreleme ve ağ segmentasyonunu ayrı katmanlar olarak ele almanız çok yerinde olmuş, çoğu zaman bunlar tek bir güvenlik politikasının altına gömülüp geçiliyor. Biz de geçen yıl bir migration sürecinde NSG kurallarını sonradan düzeltmek zorunda kalmıştık, baştan planlamak gerçekten fark yaratıyor. Bu arada şu yazınız da güzeldi: Prompt Injection’ı Durdurmak: Agent Framework’te FIDES — https://www.askinkilic.com.tr/prompt-injectioni-durdurmak-agent-frameworkte-fides/
Yorumlar kapalı.
3 comments