Paylaşılan sorumluluk modeli

Bir şirket sunucularını buluta taşır ve güvenlik ekibi rahatlar. Artık yamaları sağlayıcı geçiyordur, diye düşünülür. Altı ay sonra bir sızıntı olur ve nedeni beş yıllık bir çekirdek açığıdır. O makineyi kimse yamamamıştır.

Sağlayıcı da yamamamıştır, çünkü makinenin içine hiç girmez. Bu derste bu yanlış varsayımın kaynağını, yani paylaşılan sorumluluk modelini çözeceksin. Sınırın servis türüne göre nasıl kaydığını göreceksin. Hukuki payının neden hiç kaymadığını ve devraldığın bir hesapta ilk hangi komutları çalıştıracağını da öğreneceksin.

Model tek cümleyle özetlenir: sağlayıcı bulutun güvenliğinden, müşteri buluttaki her şeyin güvenliğinden sorumludur. Bu ayrım neden gerekir? Sağlayıcı aynı donanımı binlerce müşteriye paylaştırır.

Veri merkezinin kapısını, sunucu donanımını ve sanallaştırma katmanını yalnız o yönetebilir. Buna karşılık senin sanal makinenin içini görmez, parolanı bilmez, hangi portu açtığına karışmaz. İki taraf da ancak kendi eliyle yönettiği katmanı koruyabilir.

Model bu gerçeği yazıya döker. Sınır ise sabit değildir. Servis ne kadar hazır gelirse sağlayıcının payı o kadar büyür. Seninki küçülür ama hiçbir zaman sıfıra inmez.

Servis türlerinin adı NIST'in SP 800-145 belgesinden gelir. Altyapı hizmeti (IaaS) sana işlem gücü, depolama ve ağ verir; işletim sistemini sen kurar, sen yönetirsin. Platform hizmeti (PaaS) çalışma ortamını hazır verir; sen uygulamanı ve ayarlarını getirirsin.

Yazılım hizmeti (SaaS) hazır bir uygulamadır, e-posta ya da ofis paketi gibi. Sonradan bir de fonksiyon hizmeti (FaaS) yaygınlaştı: yalnız kodu yüklersin, sunucuyu hiç görmezsin. Dört modelin ortak noktası şudur: veri, kimlikler ve yapılandırma her birinde müşteride kalır.

Modeli uygulamaya çevirmenin ilk adımı kendi konumunu bilmektir. Hangi hesaptasın, hangi kimlikle bağlısın? Yanlış hesapta yapılan inceleme boşa gider, yanlış kimlikle çalışan komut yanıltıcı sonuç verir. AWS'de bu soruyu STS servisi yanıtlar.

get-caller-identity çağrısı hesap numarasını, kullanıcı kimliğini ve ARN bilgisini döner. İlginç bir ayrıntısı var: bu çağrı hiçbir izin istemez. Bir yönetici bu eylemi açıkça yasaklasa bile çağrı çalışır. AWS'nin gerekçesi basittir: aynı bilgi, erişim reddedildiğinde hata iletisinde de görünür.

$ aws sts get-caller-identity
{
    "UserId": "AIDASAMPLEDENETCI01",
    "Account": "111122223333",
    "Arn": "arn:aws:iam::111122223333:user/denetci"
}

Çıktıyı satır satır oku. Account alanı on iki haneli hesap numarasıdır; doğru hesapta olup olmadığını buradan anlarsın. UserId alanının ilk dört harfi kimlik türünü söyler.

AIDA bir IAM kullanıcısını, AROA ise bir rolü gösterir. Arn alanı kimliğin tam adresidir ve sonu user/denetci ile biter. Yani kalıcı bir kullanıcıyla bağlısın.

Rol üstlenmiş olsaydın ARN assumed-role içerir ve oturum adını taşırdı. Bu ayrım önemlidir, çünkü kalıcı kullanıcı genelde uzun ömürlü bir anahtar demektir. Denetimin ilk bulgusu bazen daha ilk komutta çıkar.

$ aws sts get-caller-identity

Sanal makine kiraladığında sınır çok aşağıdadır. Fiziksel bina, donanım, sanallaştırma katmanı ve omurga ağ sağlayıcıdadır. İşletim sistemi, üstündeki paketler, güvenlik duvarı kuralları ve veri tamamen sende kalır. Makineyi başlattığın an, veri merkezine sunucu kurmuş gibi sorumluluk alırsın.

Tek farkın donanıma dokunmamandır. Yamalar, kullanıcı hesapları, SSH anahtarları ve disk şifrelemesi senin iş listendedir. Yedeği de sağlayıcı senin yerine düşünmez. Disk anlık görüntüsü (snapshot) için bir takvim ve saklama süresi belirlemek sana düşer.

Şekli aşağıdan yukarı oku. En alttaki iki katman, yani donanım ve sanallaştırma, IaaS'ta sağlayıcıya aittir. İşletim sistemi, çalışma ortamı, uygulama ve veri katmanları senindir.

Girişteki şirketin hatası tam bu çizgide duruyordu. Ekip yamayı sağlayıcının yaptığını sandı. Oysa sağlayıcı yalnız kendi hipervizörünü yamar, misafir işletim sisteminin çekirdeğine dokunmaz.

Beş yıllık açık bu yüzden makinede bekledi. Doğru kurulumda bir yama yöneticisi her makineyi tarar, eksik yamayı raporlar ve bakım penceresinde uygular. Aynı düzen güvenlik grubu kuralları ve disk şifrelemesi için de kurulur.

Yönetilen bir veritabanı servisine geçtiğinde çizgi yukarı çıkar. Motor yamalarını sağlayıcı yapar, yedek zamanlamasını o yürütür. Ama kimin bağlanacağına, parolanın gücüne ve şifrelemenin açık olup olmadığına yine sen karar verirsin. Veritabanını internete açan tek bir ayar da senin elindedir.

Otomatik yedeklerin kaç gün saklanacağını da sen seçersin. Kısacası sağlayıcı motoru çalışır tutar, sen motorun kime hizmet ettiğini belirlersin. Aşağıdaki tablo üç temel modeli yan yana koyar.

Sorumluluk alanı        IaaS       PaaS       SaaS
Fiziksel veri merkezi   Sağlayıcı  Sağlayıcı  Sağlayıcı
Fiziksel ağ ve sunucu   Sağlayıcı  Sağlayıcı  Sağlayıcı
İşletim sistemi         Müşteri    Sağlayıcı  Sağlayıcı
Ağ denetimleri          Müşteri    Ortak      Sağlayıcı
Uygulamalar             Müşteri    Ortak      Ortak
İstemci cihazları       Müşteri    Müşteri    Ortak
Kimlikler ve kullanıcı  Müşteri    Müşteri    Müşteri
Yapılandırma ve ayar    Müşteri    Müşteri    Müşteri
Müşteri verisi          Müşteri    Müşteri    Müşteri

Tabloyu yukarıdan aşağı oku. Üstteki satırlar model değiştikçe sağlayıcıya ya da ortak alana kayar. Son üç satır ise hiç kıpırdamaz: kimlikler, yapılandırma ve veri her modelde müşteridedir. Fonksiyon hizmetini (FaaS) ayrı bir sütunda arama; Azure fonksiyon servisini PaaS sayar.

Sunucuyu görmezsin, ama fonksiyonun kodu, bağımlılıkları ve çalışma rolü senindir. Fonksiyona geniş bir rol bağlarsan ya da ortam değişkenine sır yazarsan hata sana aittir. SaaS tarafında payın küçük görünür ama kritiktir. Kullanıcı hesapları, dış paylaşım ayarları ve çok adımlı doğrulama senin kararındır.

Konteynerler çizginin en çok karıştırıldığı yerdir. Bir ekip yönetilen konteyner servisine geçer ve düğümleri artık sağlayıcı yamar. Ama konteyner imajının içindeki kütüphaneler yine ekibe aittir.

İmajdaki eski bir kütüphane, düğüm ne kadar taze olursa olsun açığı taşımaya devam eder. Bu katmanlı yapıyı anlatmak için 4C modeli kullanılır: Cloud (bulut), Cluster (küme), Container (konteyner) ve Code (kod). Model, Kubernetes güvenlik sertifikasının (KCSA) müfredatında ilk konulardan biridir.

Her katman bir öncekinin içinde durur. Bulut katmanında pay ortaktır, kod katmanı ise her zaman sende kalır.

Teknik sorumluluk servis türüyle kayar, hukuki sorumluluk ise yerinde durur. 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) iki rol tanımlar. Veri sorumlusu, verinin işleme amaçlarını ve vasıtalarını belirleyen kişidir. Veri işleyen ise veri sorumlusunun verdiği yetkiye dayanarak onun adına veri işler.

Buluta müşteri verisi koyan şirket veri sorumlusudur. Sağlayıcı çoğu durumda veri işleyen konumunda durur. Yani bir sızıntıda Kurul'a hesap veren taraf sensin. Sözleşmedeki bir madde bu rolü değiştirmez.

Kanunun 12. maddesi bu ilişkiyi açıkça yazar. Veri sorumlusu, hukuka aykırı işlemeyi ve erişimi önlemek için gerekli teknik ve idari tedbirleri almak zorundadır.

Veri başkası eliyle işleniyorsa, bu tedbirlerde o kişiyle birlikte müştereken sorumludur. Aynı madde bir bildirim de ister: veri kanuni olmayan yollarla ele geçirilirse, veri sorumlusu durumu en kısa sürede ilgilisine ve Kurul'a bildirir. Bulutta bir de bölge seçimi vardır.

Veriyi yurt dışındaki bir bölgede tutmak, 9. maddedeki yurt dışına aktarım kurallarını devreye sokar. Bu madde 2024'te 7499 sayılı Kanun ile değişti. Aktarım artık, arızi hâller dışında, yeterlilik kararına ya da standart sözleşme gibi uygun güvencelere dayanır.

Yeni bir hesabı devraldığında ilk üç komutun şu olur: kim olduğunu sor, hangi bölgelerin açık olduğunu listele, günlük kaydının açık olup olmadığını kontrol et. Üçü de birkaç saniye sürer ve zeminin nerede durduğunu söyler. Kimlik sorusunu get-caller-identity ile yanıtladın. Bölge sorusu da önemlidir, çünkü kullanılmayan bölgelerde unutulmuş kaynak durur.

Oraya kimse bakmaz ve saldırgan için sessiz bir çalışma alanıdır. Günlük sorusu ise bir olay anında geriye dönüp bakıp bakamayacağını gösterir.

$ aws ec2 describe-regions --query 'Regions[].[RegionName,OptInStatus]' --output text
eu-central-1    opt-in-not-required
eu-west-1       opt-in-not-required
us-east-1       opt-in-not-required
eu-south-1      opted-in

$ aws cloudtrail describe-trails --query 'trailList[].[Name,IsMultiRegionTrail]' --output text
kurumsal-iz     True

İlk komut yalnız hesabında açık bölgeleri listeler. opt-in-not-required değeri, bölgenin varsayılan olarak açık geldiğini söyler. opted-in ise birinin o bölgeyi sonradan elle açtığını gösterir.

Son satır bu yüzden dikkat ister: eu-south-1'i kim, neden açtı? Kapalı bölgeleri de görmek istersen --all-regions bayrağını eklersin; onlar not-opted-in olarak gelir. İkinci komut izlerin adını ve tüm bölgeleri kapsayıp kapsamadığını yazar. IsMultiRegionTrail değeri False olsaydı, iz yalnız kurulduğu bölgeyi görürdü.

Üç komut zemini gösterir, ama varsayılanların tamamını görmez. Onları toplu görmek için açık kaynak denetim araçları işini hızlandırır. ScoutSuite ve Prowler kendi hesabını okur, yüzlerce kontrolü çalıştırır ve raporu tek dosyada verir. İkisi de yalnız okuma yetkisiyle çalışır.

Prowler belgeleri AWS'nin hazır SecurityAudit ve ViewOnlyAccess politikalarını önerir. Denetçiye yazma izni vermemek, taramanın kendisini bir risk olmaktan çıkarır. Kapsamı daraltmak da iyi bir alışkanlıktır: --list-services servisleri listeler, --services yalnız seçtiğin servisleri tarar.

$ prowler aws --services iam cloudtrail s3 --status FAIL
FAIL  iam_root_mfa_enabled               hesap: 111122223333
FAIL  iam_rotate_access_key_90_days      kullanıcı: eski-yedekleme
FAIL  cloudtrail_multi_region_enabled    bölge: eu-south-1
FAIL  s3_bucket_public_access            kova: pazarlama-arsiv

Her FAIL satırını bir soru olarak oku: bu ayarın sahibi kim? Kök hesapta çok adımlı doğrulamanın kapalı olması hesap yöneticisinin işidir. Doksan günü aşmış anahtarın sahibi, o kullanıcıyı açan ekiptir.

eski-yedekleme adlı kullanıcıyı çoğu zaman kimse hatırlamaz; sahipsiz ayar tam olarak böyle görünür. Sektör raporları bu tablonun yaygın olduğunu söyler. 2025 tarihli bir bulut güvenliği raporuna göre IAM kullanıcılarının yüzde 59'unda bir yıldan eski etkin bir erişim anahtarı var.

Raporun önceki sürümleri, uzun ömürlü kimlik bilgilerini kamuya açık bulut ihlallerinin en sık nedeni olarak gösterdi. Taramayı kalıcı bir işe çevirmenin yolu sahiplenme tablosudur. Her servis için üç sütun yazarsın: ayar adı, kimin yaptığı, nasıl denetlendiği. Yeni bir servis geldiğinde de üç soru sorarsın.

Bu servis hangi katmanı devralıyor? Bana ne bırakıyor? Bıraktığını nasıl doğrularım? Yanıtlar bir toplantıda çıkar ve yazılı kalır.

Aylar sonra bir bulgu geldiğinde sahibi tablodan hızla bulunur. Hesap yapısı da tablonun parçasıdır. Üretim, test ve günlük verisi ayrı hesaplarda durursa, bir hesabın ele geçmesi diğerlerini doğrudan açmaz.