Bulut sağlayıcısı altyapıyı koruyor. Verinin, erişimin ve yapılandırmanın güvenliği ise size ait — ve ihlallerin çoğu tam olarak bu tarafta oluyor.
Done Dynamics bulut bilişim güvenliği denetimi ve sıkılaştırma çalışması yapıyor: mevcut bulut hesabının çıkarılması, yanlış yapılandırmaların tespiti, kimlik ve yetkilendirme yapısının sadeleştirilmesi, gizli bilgi yönetimi, kayıt ve izleme kurgusu, yedek doğrulaması ve KVKK açısından veri konumunun netleştirilmesi. Çalışma tek bir sağlayıcıya bağlı değil; AWS, Cloudflare, Hetzner, Google Cloud ve benzeri platformlarda aynı kontrol seti uygulanıyor.
Sayfanın çıkış noktası paylaşılan sorumluluk modeli. Bulut sağlayıcısı veri merkezini, donanımı ve sanallaştırma katmanını koruyor — bu tarafta gerçekten iyi bir iş yapılıyor. Ancak hesabınızda hangi kaynağın internete baktığı, kimin neye erişebildiği, verinin şifreli olup olmadığı ve anahtarların nerede durduğu tamamen sizde kalıyor. Sahada en sık karşılaştığımız yanlış anlama da burada: "bulutta duruyor, o zaman güvenlidir" cümlesi, devredilmemiş bir sorumluluğu devredilmiş sayıyor.
Denetim salt okunur yetkiyle yürütülür, üretime dokunulmaz ve çıktısı kritiklik seviyesine göre sıralanmış bir bulgu listesidir. Çalışma siber güvenlik denetimi kapsamının bir parçası olarak ya da tek başına yürütülebilir; barındırma tarafındaki kurulumla birlikte planlandığında ise barındırma hizmetiyle aynı belgede toplanır.
Bulut güvenliğiyle ilgili her tartışma bu çizgiden başlamalı: sınır nerede, hangi tarafta kim var.
Veri merkezinin fiziksel güvenliği, sunucu donanımı, sanallaştırma katmanı ve altyapı ağı bulut sağlayıcısının sorumluluğundadır. Bu tarafta gerçekten iyi bir iş yapılıyor: hiçbir orta ölçekli kurumun kendi başına kuramayacağı bir koruma seviyesi kira bedeline dahil geliyor. Sorun bu tarafta çıkmıyor.
Hesapların kimlere açık olduğu, hangi kaynağın internete baktığı, verinin şifreli tutulup tutulmadığı, anahtarların nerede durduğu ve kimin neyi silebildiği tamamen müşteride kalır. Sağlayıcı bu ayarları sizin adınıza güvenli hale getirmez; yalnızca güvenli hale getirebileceğiniz aracı verir.
Kiralık sunucuda işletim sistemi yamaları sizde; yönetilen veritabanında yamalar sağlayıcıda ama erişim politikası sizde; hazır bir yazılım hizmetinde yapılandırma ve kullanıcı yönetimi yine sizde. Aynı kurumda üç farklı hizmet türü kullanılıyorsa üç farklı sorumluluk sınırı vardır ve bunların yazılı olması gerekir.
Sahada en sık duyduğumuz cümle şu: "Bulutta duruyor, o zaman güvenlidir." Bu cümle sorumluluğun devredilmiş olduğunu varsayar, oysa yalnızca altyapı katmanı devredilmiştir. Veri sızıntılarının büyük çoğunluğu sağlayıcının altyapısı kırıldığı için değil, müşterinin yapılandırması gevşek bırakıldığı için oluyor.
Bulut tarafındaki olayların büyük çoğunluğu karmaşık bir saldırıdan değil, açık bırakılmış bir ayardan doğuyor. Aşağıdakiler devraldığımız hesaplarda en sık bulduğumuz altı kalıp.
Bir kova, yedek dosyalarını paylaşmak için bir öğleden sonra herkese açık hale getirilir ve kapatılmayı unutulur. İçinde müşteri kayıtları, veritabanı dökümü ya da fatura arşivi olabilir. Bu kovalar internet üzerinden sürekli taranıyor; bulunmaları saatler değil dakikalar sürüyor.
Geliştirme sırasında dışarıdan bağlanmak için açılan veritabanı portu üretimde de açık kalır. Tarayıcı botları bilinen portları sürekli deniyor; zayıf ya da varsayılan parola bulunduğunda giriş, sızıntı ve fidye aynı gün içinde gerçekleşebiliyor.
Kurulum sırasında hızlıca ayağa kaldırılan yönetim arayüzleri, izleme panelleri ve kuyruk yönetim ekranları çoğu zaman kurulum parolasıyla kalır. Bu paneller genellikle sunucunun tamamına erişim verir ve arama motorlarıyla bulunabilir haldedir.
Bir sorunu hızlı çözmek için güvenlik grubuna eklenen "her yerden her port" kuralı, sorun çözüldükten sonra silinmez. Bu kural tek başına bulut ağ segmentasyonunun tamamını işlevsiz bırakır; arkasındaki tüm sunucular doğrudan internete bakar hale gelir.
Bir proje için açılan test ortamı proje bittikten sonra kapatılmaz. Üretim verisinin bir kopyasıyla, güncellenmeyen yazılımla ve gevşek erişim kurallarıyla aylarca ayakta durur. Saldırgan için üretime giden en kolay yol çoğu zaman burasıdır.
Disk anlık görüntüleri ve makine imajları paylaşılabilir olarak işaretlenebiliyor. Paylaşıma açık bir imajın içinde gömülü anahtarlar, yapılandırma dosyaları ve veritabanı içeriği bulunur. Bu, kimse fark etmeden yıllarca sürebilen sessiz bir sızıntıdır.
Bu altı kalıbın ortak yanı, hiçbirinin kötü niyetten doğmaması. Hepsi bir işi hızlı bitirmek için verilmiş geçici bir karar ve hiçbiri geri alınmamış. Denetimin ilk işi bu geçici kararları bulup listelemek.
Bulutta güvenlik duvarının yerini büyük ölçüde kimlik yapısı aldı. Bir hesabın ele geçirilmesi, klasik ağda bir sunucunun ele geçirilmesinden çok daha ağır bir sonuç doğurabiliyor — çünkü o kimlikle oluşturulabilecek, silinebilecek ve okunabilecek her şey erişilebilir hale geliyor.
Sekiz maddenin ortak paydası tek bir soru: bu kimlik bugün ele geçirilse, saldırgan neye ulaşırdı?
Bir bulut hesabına giren saldırganların önemli bölümü kapıyı kırmıyor; anahtarı yerde bulup kullanıyor.
API anahtarları, veritabanı parolaları ve bulut erişim anahtarları en sık kod deposu üzerinden sızıyor. Anahtarı bir sonraki işlemede silmek yetmez — geçmiş kayıtlarda durmaya devam eder. Depo bir kez herkese açıldıysa anahtarın iptal edilmesi tek doğru cevaptır.
Ortam değişkeni, anahtarı koddan ayırdığı için bir adım ileridir; ancak süreç listesinde, kayıt dosyalarında ve hata izlerinde görünebilir. Kritik anahtarlar için gizli bilgi kasası kullanılır: erişim yetkilendirilir, her okuma kaydedilir, değer merkezi olarak değiştirilebilir.
Herkese açık kod depoları sürekli taranıyor. Sahada gördüğümüz tablo, sızan bir bulut anahtarının fark edilmesinden çok önce kullanılmaya başlandığıdır — genellikle kaynak açma amacıyla. Bu yüzden anahtar sızıntısı bir sonraki toplantının değil, o saatin konusudur.
Bir anahtarın sızdığından şüphelenildiğinde ne yapılacağı önceden yazılır: hangi anahtar nerede kullanılıyor, iptal edildiğinde hangi servis durur, yenisi nasıl dağıtılır. Bu prosedür yazılı değilse iptal kararı gecikir, gecikme de zararı büyütür.
Bulutta ağ, kablo değil yapılandırmadır. Bu da yanlış bir satırın tüm segmentasyonu ortadan kaldırabilmesi anlamına geliyor — ve aynı kolaylıkla geri getirilebilmesi.
Bulut güvenlik grupları da tıpkı klasik güvenlik duvarı kuralları gibi zamanla şişer. Her kuralın gerekçesi, sahibi ve tarihi yazılır; kaynak adres aralığı mümkün olan en dar haliyle tutulur. "Her yerden" ifadesi yalnızca gerçekten herkese açık olması gereken servisler için kullanılır.
Veritabanları, iç servisler ve iş kuyrukları internete bakan alt ağda durmaz. Bu bileşenler özel alt ağa taşınır; dışarıya erişimleri gerekiyorsa denetimli bir ağ geçidi üzerinden verilir. Böylece yanlış bir güvenlik grubu kuralı bile onları doğrudan internete açamaz.
Sunucu kabuk erişimi, veritabanı istemcisi ve yönetim panelleri internete açık bırakılmaz. Bunlar VPN ya da kimlik doğrulamalı bir erişim katmanı arkasına alınır. Bu tek değişiklik, tarama botlarının ürettiği gürültüyü ve bununla gelen riski büyük ölçüde ortadan kaldırır.
Çoğu kurulumda giriş trafiği denetlenir, çıkış serbest bırakılır. Oysa veri sızıntısı ve zararlı yazılımın komuta sunucusuyla konuşması çıkış yönünde gerçekleşir. Sunucuların dışarıya hangi adreslere ve hangi portlara ulaşabileceği sınırlandırılır.
Nesne depolama, gizli bilgi kasası ve yönetilen veritabanı gibi servislere internet üzerinden değil, sağlayıcının iç ağı üzerinden bağlanmak mümkündür. Bu hem trafiğin dışarı çıkmasını engeller hem de erişimi ağ düzeyinde kısıtlanabilir hale getirir.
Şifreleme bulutta neredeyse ücretsiz bir önlem — birkaç ayar ve bir tasarım kararı. Buna rağmen devraldığımız kurulumlarda en sık eksik bulduğumuz katmanlardan biri, özellikle yedek tarafında.
Bulut denetim günlüğü geriye dönük açılamaz. Kapalıysa, bir olay yaşandığında o döneme ait hiçbir kanıt üretilemez. Bu yüzden kayıt kurgusu, olay olmadan önce yapılan az sayıdaki geri dönüşsüz karardan biri.
Bulut sağlayıcısının verinizi kaybetmemesi ile sizin verinizi geri getirebilmeniz iki farklı şey. İkincisi için ayrı bir kurgu gerekiyor.
Sağlayıcının altyapısı dayanıklıdır — diskiniz bozulmaz, sunucunuz kaybolmaz. Ama bu yedek almak değildir. Yanlışlıkla silinen bir tablo, hatalı bir dağıtım ya da fidye yazılımıyla şifrelenen bir disk için ayrıca alınmış bir yedeğe ihtiyaç vardır ve o yedeği açmak sizin işinizdir.
Bir sunucu ya da veritabanı silindiğinde çoğu sağlayıcıda geri dönüş penceresi yoktur. Silme koruması, kritik kaynaklarda etiketle işaretleme ve silme yetkisinin dar bir gruba verilmesi bu riski azaltır. Silme işlemleri ayrıca kayıt altına alınır.
Yedek, korunmak istenen olayla aynı yerde durmamalıdır. Aynı hesapta duran bir yedek, hesabın ele geçirilmesi senaryosunda korumaz. Farklı bir bölgeye ve mümkünse yalnızca yazma yetkisi olan farklı bir hesaba kopya alınır.
Denenmemiş yedek yedek değildir. Belirli aralıklarla gerçek bir geri dönüş yapılır; ne kadar sürdüğü ölçülür ve yazılır. Kurumun tolere edebileceği kesinti süresi ile ölçülen süre örtüşmüyorsa yedekleme kurgusu değiştirilir.
Bulut hesabı açılırken seçilen bölge, çoğu zaman kimsenin üzerinde durmadığı bir açılır listedir. Oysa o liste kişisel verinin hangi ülkede işleneceğini belirler ve KVKK açısından yurt dışına aktarım o anda başlar.
Bu bölümün çıktısı hukuki görüş değil teknik tespittir: verinin fiilen nerede durduğu, hangi kopyaların nereye çıktığı ve bunların belgelenip belgelenmediği.
Bulutta güvenlik olayının ilk görünür belirtisi çoğu zaman bir uyarı değil, beklenmedik bir fatura oluyor. Bu yüzden maliyet kontrolleri güvenlik kontrolü sayılır.
Denetim beş adımda yürür. Her adımın çıktısı yazılıdır ve bir sonraki adımın girdisi olur.
Hangi hesaplar, hangi bölgeler ve hangi hizmetler denetlenecek yazılır. Denetim için salt okunur yetki tanımlanır; işlem yapabilen bir yetki istenmez. Yetkinin nasıl verileceği ve denetim sonunda nasıl geri alınacağı baştan konuşulur.
Hesaptaki tüm kaynaklar çıkarılır: makineler, depolama, veritabanları, kimlikler, ağ kuralları ve anahtarlar. Yaygın yanlış yapılandırma kalıpları otomatik kontrollerle taranır. Bu adımın çıktısı ham bulgu listesidir.
Otomatik tarama yanlış pozitif üretir. Her bulgu elle doğrulanır; gerçekten erişilebilir mi, hangi veriye ulaşılıyor, iş akışında bir gerekçesi var mı sorularına cevap aranır. Doğrulanmamış bulgu rapora girmez.
Bulgular kritiklik seviyesine göre sıralanır. Her bulgu için etkinin ne olduğu, nasıl doğrulandığı ve düzeltme adımının ne olduğu yazılır. Rapor teknik ekip için ayrıntılı, yönetim için bir sayfalık özet halinde iki katmanlı verilir.
Düzeltmeler öncelik sırasına göre planlanır; isteyen kurum kendi ekibiyle uygular, isteyen bize devreder. Düzeltme tamamlandıktan sonra aynı kontroller yeniden koşturulur ve kapanan bulgular ayrı bir belgede işaretlenir.
Denetim sabit bedelli bir projedir; kapsamını hesap sayısı, bölge sayısı ve kullanılan hizmet çeşitliliği belirler. Kapsam görüşmesi ücretsizdir ve sonunda tek sayfalık bir teklif çıkar — neyin dahil olduğu kadar neyin olmadığı da aynı sayfada yazılıdır. Düzeltme işleri ayrı kalem yazılır ve zorunlu değildir; raporu alıp kendi ekibiyle uygulamak isteyen kuruma ek bir bedel çıkmaz. Dönemsel yeniden denetim ve sürekli izleme isteyen kurumlar için aylık hizmet modeli tanımlıyoruz: yeni açılan kaynakların kontrolü, kimlik envanterinin güncel tutulması, bütçe uyarılarının takibi ve üç ya da altı aylık yeniden tarama bu kapsamda yürür. Bulut sağlayıcısına ödenen kullanım bedelleri her durumda müşteri adına, üzerine pay konmadan geçilir. Denetim çıktısı — rapor, envanter tabloları ve kontrol listesi — kurumda kalır; bunları kendimizde tutan bir çalışma modelimiz yok.
Ağırlıklı olarak AWS, Cloudflare, Hetzner ve Google Cloud tarafında çalışıyoruz; Azure ve DigitalOcean gibi platformlarda da denetim yapıyoruz. Kavramlar sağlayıcıdan bağımsız olarak aynı: kimlik ve yetkilendirme, ağ sınırları, depolama erişimi, şifreleme, kayıt ve yedek. Değişen şey isimler ve arayüz. Birden fazla sağlayıcı kullanan kurumlarda denetim tek raporda birleştirilir, çünkü asıl risk çoğu zaman iki platformun birleştiği yerde — örneğin bir platformda duran anahtarın diğerine erişim vermesinde — ortaya çıkıyor.
Denetim zaten mevcut kurulum üzerinde yapılır; sıfırdan kurulum gerekmez ve çoğu durumda önerilmez de. Yıllar içinde büyümüş bir bulut hesabı, üzerinde çalışan işi taşıdığı için değerlidir. Yaptığımız iş onu yıkmak değil, hangi ayarın neden öyle olduğunu çıkarmak ve riskli olanları sıraya koymak. Sıfırdan kurulum önerisi yalnızca hesap yapısı temelden sorunluysa — örneğin üretim ve test aynı hesapta iç içe geçmişse — gündeme gelir ve bu durumda da geçiş kademeli planlanır.
Tek hesaplı, sınırlı sayıda kaynağı olan bir kurulumda envanter ve tarama birkaç gün, elle doğrulama ve raporlama bir hafta kadar sürüyor. Çok hesaplı, birden fazla bölgede çalışan kurulumlarda süre iki-üç haftaya çıkabiliyor. Süreyi belirleyen ana değişken kaynak sayısı değil, kimlik ve yetki yapısının karmaşıklığı: yüz sunucuyu incelemek, birbirine geçmiş kırk rolü çözmekten daha kısa sürüyor. Kapsam netleştikten sonra süre yazılı olarak veriliyor.
Hayır. Denetim salt okunur yetkiyle yapılır; yapılandırma değiştirilmez, kaynak açılmaz, veri indirilmez. Yük testi ya da saldırı denemesi bu kapsamın dışındadır ve ancak ayrıca talep edilirse, yazılı izinle ve planlı bir pencerede yapılır. Okuma işlemleri sağlayıcının API sınırlarını zorlamayacak hızda yürütülür. Düzeltme aşamasına geçildiğinde ise her değişiklik ayrı ayrı planlanır, geri alma adımı önceden yazılır ve üretimi etkileyebilecek olanlar bakım penceresine alınır.
Bulut kullanmak tek başına bir uyumsuzluk sebebi değil. KVKK verinin nerede durduğunu değil, nasıl korunduğunu ve aktarımın nasıl belgelendiğini soruyor. Uygulamada üç şeye bakıyoruz: verinin fiziksel konumu biliniyor mu, yurt dışına aktarım varsa gerekçesi ve dayanağı yazılı mı, işleyen-alt işleyen zinciri çıkarılmış mı. Bu üçü tamamsa bulut kullanımı uyumla çelişmez. Türkiye'de tutma tercihi ise teknik olarak mümkün ve pek çok senaryoda uyum yükünü belirgin biçimde azaltıyor; bu yüzden karar, maliyet ve hizmet çeşitliliğiyle birlikte açıkça tartılıyor.
Salt okunur bir denetim rolü. Sağlayıcıların çoğunda bunun için hazır bir politika bulunuyor; yoksa gerekli okuma izinlerini kapsayan bir rol birlikte tanımlıyoruz. Rol kalıcı bir kullanıcıya değil, süreli bir erişime bağlanır ve denetim bittiğinde kaldırılır. Kaldırma işlemini siz yaparsınız, biz talep etmeyiz. Yetki verirken hangi izinlerin istendiğini kalem kalem yazılı veriyoruz — "tam yetki verin, gerisini biz hallederiz" diye başlayan bir çalışma modelimiz yok.
Rapor iki katmanlı hazırlanır. Yönetim özeti bir sayfadır: kaç bulgu var, kaçı kritik, en büyük üç risk ne ve düzeltme için tahmini efor ne kadar. Teknik bölümde her bulgu ayrı ayrı yer alır — hangi kaynakta olduğu, nasıl doğrulandığı, gerçekleşmesi halinde etkisinin ne olacağı ve düzeltme adımının ne olduğu. Bulgular kritik, yüksek, orta ve düşük olarak sınıflandırılır; sınıflandırma erişilebilirlik ve etkiye göre yapılır, teorik ciddiyete göre değil. Ayrıca doğru yapılandırılmış bulduğumuz alanlar da yazılır, çünkü neyin zaten yerinde olduğunu bilmek bir sonraki denetimin başlangıç noktasıdır.
Denetim sabit bedelli bir projedir; kapsamı hesap sayısı, bölge sayısı ve kullanılan hizmet çeşitliliği belirler. Kapsam belirleme görüşmesi ücretsizdir ve sonunda tek sayfalık bir teklif çıkar — neyin dahil olduğu ve neyin olmadığı aynı sayfada yazılıdır. Düzeltme işleri ayrı yazılır: kurum kendi ekibiyle uygulamak isterse denetim bedeli dışında ek bir kalem oluşmaz. Sürekli izleme ve dönemsel yeniden denetim isteyen kurumlar için aylık hizmet modeli tanımlıyoruz. Bulut sağlayıcısına ödenen kullanım bedelleri her durumda müşteri adına, üzerine pay konmadan geçilir.
İsteğe bağlı. Bazı kurumlar raporu alıp kendi ekibiyle uyguluyor; bu tamamen mümkün, çünkü rapor düzeltme adımlarını uygulanabilir düzeyde yazıyor. Uygulamayı bize devreden kurumlarda ise her değişiklik ayrı planlanır, geri alma adımı önceden hazırlanır ve üretimi etkileyebilecek olanlar planlı pencerede yapılır. Düzeltme sonrası yeniden test her iki durumda da yapılır; kapanmadığını gördüğümüz bir bulguyu kapandı olarak işaretlemiyoruz.
Evet, hatta küçük kurulumlarda getirisi daha yüksek oluyor. Az sayıda kaynak, denetimin kısa sürmesi ve bulguların hızla kapanması demek. Sahada gördüğümüz tablo şu: küçük kurulumlarda bulgu sayısı az ama kritik bulgu oranı yüksek — çünkü kurulum genellikle bir kişi tarafından, hızlıca, "sonra düzeltiriz" diyerek yapılmış oluyor ve o "sonra" gelmiyor. Birkaç sunucusu olan bir kurumda denetim çoğu zaman birkaç gün sürüyor ve çıkan bulguların önemli kısmı aynı hafta kapanabiliyor.
İlgili hizmetler
Sızma testi, açık taraması ve olay müdahalesi — bulut denetiminin kurum içi ve uygulama tarafındaki karşılığı.
Segmentasyon, güvenlik duvarı kuralları ve VPN — bulut ile kurum ağının birleştiği yerin tasarımı.
Sunucu kurulumu, sertifika yönetimi, izleme ve yama takvimi; denetimden çıkan düzeltmelerin uygulandığı katman.
Çapraz bölge kopyası, saklama politikası ve düzenli geri dönüş testiyle kurgulanmış yedekleme mimarisi.
Ekibimizle 30 dakikalık ücretsiz bir keşif görüşmesi planlayın.
Ağ ve siber güvenlik işlerini, uluslararası geçerli Cisco sertifikasyonuna sahip ekiple yürütüyoruz.
Veren kurum: Cisco · Sahibi: Devrim Tunçer
Güvenlik operasyon merkezi (SOC) yetkinliğini belgeleyen sertifika: güvenlik izleme, olay müdahalesi ve ağ saldırılarının analizi. Sızma tespiti, log korelasyonu ve olay sonrası müdahale gerektiren işlerde dayandığımız temel budur.
Cisco eğitim sertifikası · Ocak 2023'te tamamlandı
Ağ temellerini kapsar: yönlendirme, anahtarlama, IP adresleme ve ağ güvenliği. Kurumsal ağ kurulumu ile segmentasyon işlerinde kullandığımız bilgi tabanı.