Hoşgeldin Misafir

Bulut Güvenliğine Giriş: "Benim Verim Başkasının Bilgisayarında Güvende mi?"

Conrado Sol

Conrado Sol

Conrado Sol

29 Nis 2026
62 Mesaj

Aktiflik

Seviye

Deneyim

TIM / GÖREV:
🏗️ Cloud & Infrastructure Security Serisi
Makale 1: Bulut Güvenliğine Giriş - "Benim Verim Başkasının Bilgisayarında Güvende mi?"

Kategori: Siber Güvenlik / Bulut Bilişim / Sistem Yönetimi


Selamlar herkese, hayırlı forumlar abiler, kardeşler! 👋

Bugün modern sistem dünyasının ve altyapı mimarilerinin kalbi olan, ama nedense piyasada hala acayip yanlış anlaşılan, efsanelerin havada uçuştuğu devasa bi konuya giriş yapıyoruz: Bulut Güvenliği (Cloud Security).

Şirketlerin kritik verilerini, gece gündüz kodlayıp ayağa kaldırdığımız kendi projelerimizi falan AWS'ye, Azure'a ya da Google Cloud'a taşırken hepimizin aklından en az bir kere şu soru kesin geçmiştir: "Ulan bu bulut dedikleri şey aslında internete bağlı başkasının bilgisayarı. Peki benim verim elin adamının sunucusunda gerçekten güvende mi? Yarın öbür gün biri fişi çekse ya da veritabanını patlatsa ne yapacaz?"

Sektörde dolaşan "Bulut zaten güvenli abi, adamlar milyar dolarlık şirket" geyiği ile "Buluta veri atan delidir, her an her şey patlayabilir" paranoyası arasında sıkışıp kalan çok insan var. Bu makalede öyle sıkıcı akademık tanımlara, resmi dökümantasyon ağızlarına hiç girmeden; hem mülakatlarda karşınıza çıkacak, hem de canlı ortam yönetirken hayatınızı kurtaracak olan o meşhur Ortak Sorumluluk Modeli'ni (Shared Responsibility Model) tam bi sektör elemanı gözünden, acı tecrübelerle konuşcaz. Çayınızı kahvenizi kapın, arkanıza yaslanın. Yazı biraz uzun ve detaylı olacak, baştan uyarayım! ☕


🛡️ 1. Büyük Yanılgı: "Parasını Verdik Abi, Güvenliği Onlar Sağlasın!"

Bulut altyapılarına yeni adım atan veya şirketini buluta göç ettiren (cloud migration) ekiplerin düştüğü en büyük, en ölümcül hata tam olarak bu: "Parayı bastık, güvenliği de Amazon halletsin artık." Arkadaşlar, maalesef kazın ayağı öyle değil. Sektörde duyduğunuz, haber sitelerine düşen o meşhur ve devasa veri sızıntılarının %95'inden fazlası bulut sağlayıcısının (AWS, Azure, GCP) bir açığından veya hatasından kaynaklanmıyor. Tamamen bizlerin, yani sistemcilerin ve yazılımcıların yaptığı salakça yapılandırma hatalarından (misconfiguration) kaynaklanıyor. Yani adamlar bize tank gibi sağlam bir altyapı veriyor ama biz tankın kapısını açık bırakıp gidiyoruz.

Bulut devleri bu karmaşayı önlemek için güvenliği çok net bir çizgiyle tam ortadan ikiye ayırır. Bu kavrama siber güvenlik dünyasında şunlar denir:

A) Security OF the Cloud (Bulutun Kendi Güvenliği)
Burası tamamen bulut sağlayıcısının (örneğin AWS'nin) namus borcudur. Bizim fiziksel olarak müdahale edemediğimiz, göremediğimiz alt katmanların tamamı buraya girer.
  • **Fiziksel Güvenlik:** Sunucuların fiziksel olarak durduğu o gizli devasa veri merkezlerinin binaları. Kapıdaki biyometrik geçiş sistemleri, x-ray cihazları, kameralar ve silahlı korumalar.
  • **Altyapı Dayanıklılığı:** Elektrik kesintilerine karşı arkada bekleyen devasa endüstriyel jeneratörler, yangın söndürme sistemleri ve sunucuların erimesini engelleyen iklimlendirme (HVAC) sistemleri.
  • **Donanım Katmanı:** Kabinetler, sunucu kasaları, NVMe diskler, SAN/NAS depolama üniteleri, yönlendiriciler (Router) ve switchlerin bakımı. Bozulan veya ömrü dolan disklerin içindeki veriler kurtarılamasın diye fiziksel olarak makinelerde parçalanıp imha edilmesi.
  • **Sanallaştırma Katmanı (Hypervisor):** Fiziksel donanım üzerinde çalışan ve bizim sanal makinelerimizin (EC2, VM vb.) birbirlerinin bellek (RAM) ve işlemci alanlarına sızmasını donanımsal düzeyde engelleyen sanallaştırma yazılımlarının güvenliği ve yamalanması.

B) Security IN the Cloud (Bulutun İçindeki Güvenlik)
İşte dananın kuyruğunun koptuğu, bizim forumda sayfalarca tartışabileceğimiz yer burasıdır ve sorumluluk TAMAMEN BİZE ait. Sağlayıcının bize teslim ettiği o ham, tertemiz altyapının üzerinde ne yapıyorsak, her bir tıkımız ve ayarımız bizden sorulur:

  • **Müşteri Verilerinin Güvenliği:** Sunucudaki veya depolama alanındaki veriyi şifreledin mi (Encryption at Rest)? Ağda taşınan veriyi TLS ile koruyor musun (Encryption in Transit)? Verileri hassaslık derecesine göre sınıflandırdın mı?
  • **İşletim Sistemi ve Yama Yönetimi:** Bulutta ayağa kaldırdığın Linux (Ubuntu, CentOS vb.) veya Windows sunucunun işletim sistemi düzeyindeki güvenlik yamalarını (Patch Management) düzenli geçiyor musun? Yoksa internete açık sunucuda 3 senelik log4j ya da kernel zafiyetiyle mi takılıyorsun?
  • **Kimlik ve Erişim Yönetimi (IAM):** Kullanıcı hesapları ne alemde? Herkese admin yetkisi mi verdin? API secret key'leri gidip GitHub'da public repoya mı bastın? Şifre politikaların ne kadar sıkı?
  • **Ağ ve Güvenlik Duvarı Konfigürasyonları:** Sanal ağları (VPC/VNet) doğru böldün mü? Yoksa tüm sunucuları tek bir public subnet'e atıp geçtin mi? İnternete sadece 80 ve 443 portlarını açman gerekirken üşengeçlikten `0.0.0.0/0` şeklinde tüm portları (Any-Any) dışarıya hunharca açtın mı?

image2.png

📸 GÖRSEL 1: Ortak Sorumluluk Modeli Şeması (Security OF the Cloud vs Security IN the Cloud ayrımını gösteren katmanlı infografik)

[💡]Ufak bi benzetme yapalım daha iyi otursun: Dünyanın en lüks, en iyi korunan, depreme dayanıklı rezidansından bi daire kiraladığını düşün. Rezidans yönetimi (Bulut Sağlayıcı) site girişindeki güvenliği sağlar, kameraları izler, asansörlerin bakımını yapar, binayı ayakta tutar. Bina taş gibidir. Ama sen akşam evden çıkarken dairenin çelik kapısını kilitlemeden ardına kadar açık bırakırsan, içeri giren hırsız evi soyduğunda gidip rezidans yönetimini suçlayamazsın di mi? "E hani bina güvenliydi?" diyemezsin. İşte bulut işi de aynen bu şekıl.


📊 2. Hizmet Modellerine Göre Sorumluluk Nasıl Değişiyor?

Tabi bulut dünyası tek bir yapıdan ibaret değil. Kullandığın servisin türüne göre (IaaS, PaaS, SaaS) senin sorumluluk alanın daralıyor ya da genişliyor. Yani arkana yaslanıp kahve içeceğin süre, seçtiğin bulut modeline bağlı. Gelin bunu iyice bi netleştirelim.

kxbzlpy.png

📸 GÖRSEL 2: IaaS, PaaS ve SaaS Modellerinde Sorumluluk Dağılım Grafiği (Mavi alanlar sağlayıcıyı, turuncu alanlar müşteriyi temsil eder)

🛠️ IaaS (Infrastructure as a Service) - Altyapı Servisi
Örnekler: AWS EC2, Azure Virtual Machines, Google Compute Engine.
Sağlayıcı sana sadece boş bir bilgisayar kasası, boş bir disk alanı ve network kablosunu sanal olarak teslim eder, gerisine asla karışmaz. İşletim sistemini kurmak (veya imajdan seçmek), onu güncellemek, firewall (Security Group) ayarlarını yapmak, içine kuracağın MySQL veya PostgreSQL veritabanının konfigürasyonu tamamen senin ellerindedir.
En amelece, en çok uğraştıran ve güvenlik sorumluluğunun en fazla sende olduğu model budur. Sunucuya yama geçmediğin için bi RCE (Remote Code Execution) zafiyeti üzerinden hacklenirsen geçmiş olsun, Amazon dönüp yüzüne bile bakmaz, "Sunucuyu ayağa kaldırdım, çalışıyordu" der geçer.


📦 PaaS (Platform as a Service) - Platform Servisi
Örnekler: AWS RDS (Managed Database), Azure SQL, AWS Elastic Beanstalk, Google App Engine.
Burada biraz nefes alıyoruz işte. Sağlayıcı diyor ki: "Sen sunucu işletim sistemiyle, yama geçmekle uğraşma. Ben arkada sunucuyu yönetirim, veritabanı motorunu güncellerim, hatta yedekleri de otomatik alırım." Süper di mi? İşletim sistemi güvenliği tamamen onlara geçiyor. Peki senin sorumluluğun ne?
  • Kendi yazdığın uygulamanın kaynak kodundaki açıklar (yazdığın kodda SQL Injection veya XSS varsa sağlayıcı seni koruyamaz).
  • Veritabanına veya platforma kimlerin erişebileceğini belirleyen IAM rolleri ve network erişim kuralları.

💻 SaaS (Software as a Service) - Yazılım Servisi
Örnekler: Microsoft 365 (Office), Google Workspace (Gmail, Drive), Salesforce.
Bulutun son aşaması. Her şeyi adamlar yönetir, altyapı, işletim sistemi, kod, her şey onlardadır. Sen sadece web tarayıcısından kullanıcı adın ve şifrenle girip sistemi tüketirsin. Güvenlik sorumluluğunun en az olduğu yer burasıdır. Ama tamamen sıfırlanır mı? KESİNLİKLE HAYIR!
  • Kullanıcıların şifrelerinin çalınması (Phishing/Oltalama saldırıları ile).
  • Hesaplarda MFA (Çok Faktörlü Kimlik Doğrulama) açık mı değil mi?
  • Şirket içi hassas bi Drive dökümanını yanlışlıkla "linke sahip olan herkese açık" şeklinde dışarıya sızdırdın mı? Bunlar hala senin sorumluluğunda. Bir çalışanın hesabı hacklenirse bu Google'ın zafiyeti değil, senin yönetim hatandır.


⚠️ 3. Gerçek Dünyadan Can Yakan, İbretlik Vakalar

Teoriyi geçelim, bize yaşanmış canlı örnek ver derseniz, buyrun size siber güvenlik tarihine geçmiş, milyar dolarlık şirketlerin canını yakan iki büyük senaryo analizi:

💥 Senaryo A: Açık Kalan S3 Bucket Rezilliği (Misconfiguration)
Büyük bi e-ticaret şirketinin mobil yazılımcı ekipi, uygulama içindeki kullanıcı profil fotoğrafları hızlı yüklensin, gecikme (latency) olmasın diye AWS S3 (Simple Storage Service) üzerindeki bir depolama alanının (Bucket) erişim politikasını (Bucket Policy) yanlışlıkla internetteki herkese açık (Public) hale getiriyor. İşin daha da kopuk tarafı, sistem ekibi de sunucu hata loglarını (error logs) yedeklemek için yanlışlıkla aynı bucket'ı kullanıyor. Logların içinde ne var? Kullanıcıların açık T.C. Kimlik numaraları, adresleri, şifre hashleri ve API tokenları...
Bir hacker botu interneti tararken bu açık bucket'ı şak diye yakalıyor ve tüm veriyi çekip dark webde satışa koyuyor. Şirket ertesi gün prestij olarak yerle bir.
Sorumluluk Analizi: Burada AWS suçlu mu? Hayır. AWS S3 altyapısı verinin fiziksel olarak kaybolmaması için dünya üzerindeki en saglam dayanıklılık oranını sunuyor. Ama kapının kilidini "Herkes girebilir" diye ayarlayan bizim üşengeç yazılımcı ekibi olduğu için bu sızıntı tamamen müşteri sorumluluğundaki Security IN the Cloud hatasıdır.

🔑 Senaryo B: Root Hesabıyla Canlı Ortam Yönetme Çılgınlığı
Şirketin kıdemli sistem yöneticisi abimiz, günlük operasyonları (yeni sunucu açma, network ayarları değiştirme, veritabanı silme vb.) daha rahat ve hızlı yapmak adına, bulut hesabı ilk açıldığında verilen en yetkili hesap olan "Root Account" (Kök Hesap) bilgilerini kullanıyor. "Her seferinde başka kullanıcıyla mı uğraşacam" kafası yani. Üstelik telefona kod gelmesiyle falan uğraşmamak için bu hesapta MFA (İki Aşamalı Doğrulama) bile aktif edilmemiş.
Bir gün bu abimizin bilgisayarına tıkladığı bi linkten dolayı "infostealer" (bilgi çalıcı zararlı yazılım) bulaşıyor. Tarayıcıda kayıtlı olan tüm AWS root şifreleri, cookieler saldırganların eline geçiyor. Saldırganlar gece saat 03:00'te hesaba bi giriyor; şirketin tüm canlı sunucularını, müşteri veritabanlarını, yedekleme disklerini (Snapshot) saniyeler içinde tamamen siliyor. Şirket sabah işe geldiğinde ortada hiçbir şey yok, dımdızlak kalıyorlar. Sonra saldırgan mail atıyor: "Şu kadar Bitcoin verirseniz verileri geri veririz" (ki genelde vermezler).
Sorumluluk Analizi: Bulut sağlayıcılarının ilk açılış dökümanlarında kalın harflerle şu yazar: "Root hesabını güçlü bir şifre ve MFA ile kilitleyin, anahtarını gizli bir yere saklayın ve acil durumlar dışında ASLA kullanmayın. Günlük işler için kısıtlı yetkilere sahip IAM kullanıcıları oluşturun." Bu kuralı çiğnemek doğrudan müşterinin kendi topuğuna sıkmasıdır.

1swotol.png

📸 GÖRSEL 3: Bir Bulut Sızıntısının Anatomisi (Hatalı yapılandırmadan saldırganın veriyi sızdırmasına kadar geçen sürenin zaman tüneli şeması)

🚀 Bulut Güvenliğine Başlarken 3 Altın Kural

Eğer siz de kendi projelerinizde veya şirkette bu tarz felaketler yaşamak istemiyorsanız, yarın sabahtan itibaren şu 3 altın kuralı altyapınıza uygulamak zorundasınız:

Eğer siz de kendi projelerinizde veya şirkette bu tarz felaketler yaşamak istemiyorsanız, yarın sabahtan itibaren şu 3 altın kuralı altyapınıza uygulamak zorundasınız:

  1. En Az Yetki Prensibi (Least Privilege): Kimsenin ihtiyacından bir gıdım fazla yetkisi olmasın. Şirkete yeni giren stajyere ya da sadece test yapacak bir otomasyon botuna tüm sistemi uçurabilecek veya fatura detaylarını görebilecek yetkiyi vermeyin. Kimin işi neyse, sadece o servise erişebilsin.
  2. MFA İstisnasız Zorunlu Olacak: Sistemdeki en alt düzey kullanıcıdan en tepe yöneticine kadar istisnasız tüm hesaplarda İki Aşamalı Doğrulamayı zorunlu yapın. Şifre istediği kadar uzun olsun, günümüz siber dünyasında MFA yoksa o hesap her an patlamaya hazırdır.
  3. Sürekli İzleme ve Loglama (Karanlıkta Yürümeyin): Bulut ortamında kim, ne zaman, hangi ip adresinden hangi API çağrısını yapmış? Hangi sunucuyu kim kapatmış? Bunları izlemiyorsanız kör uçuşu yapıyorsunuz demektir. *AWS CloudTrail*, *Azure Activity Log* ya da *GCP Audit Logs* gibi nimetleri asla ama asla kapatmayın, gelen logları da düzenli analiz edin. Göremediğin şeyi koruyamazsın abi, net.

🎯 Bi Toparlayalım (Sonuç)

Özetle beyler, makaleyi çok uzattım farkındayım ama konu hayati. "Benim verim başkasının bilgisayarında güvende mi?" sorusunun cevabı: Evet güvende, ama sen izin verdiğin sürece! Bulut sağlayıcıları altyapının fiziksel ve donanımsal kısmını bizden çok daha iyi koruyor, orası kesin. Ancak o altyapının üzerindeki mimariyi kurarken güvenlik duvarlarını düzgün ayarlamak, rolleri otomatize tarayan CSPM (Cloud Security Posture Management) araçları kullanmak ve en önemlisi ekibin bu konudaki farkındalığını artırmak bizim elimizde. Unutmayın, teknik bilgi eksikliği ve üşengeçlik, en kral, en pahalı firewall cihazından daha büyük bi deliktir altyapıda.
 
Cevap yazmak için giriş yap yada kayıt ol.
Geri
Üst