TurkTeam | Türk Siber Güvenlik Topluluğu - Bulut Güvenliği

GCP Dataflow Gölge Bağımlılık: Tahmin Edilebilir Bucket ile Kiracılar Arası RCE

Sat, 24 Oct 2026 11:28:54 +0300

Selamlar,

Varonis Threat Labs, Google Cloud Dataflow'ta kiracılar arası (cross-tenant) bir saldırı yolunu açıkladı: varsayılan staging bucket adının proje kimliği + bölgeden tahmin edilebilir olması. Saldırgan bu adı önceden kendi projesinde oluşturursa (bucket squatting), kurbanın ilk Dataflow işi kodunu saldırganın kovasına yükleyebiliyor. --save_main_session ile pickle edilen oturum değiştirilince Dataflow işçilerinde kod çalışıyor. Google sorunu küresel olarak kapatmış; yine de dersleri kalıcı.

Konuda anlatılacaklar

Saldırı zinciri
Kimler risk altındaydı?
Google'ın üç katmanlı düzeltmesi
Sizin yapmanız gerekenler

1. Saldırı zinciri

Saldırgan dataflow-staging-- adını önceden oluşturur, AllUsers yazma verir.
Kurban, açık staging konumu vermeden Beam Python ile ilk işi çalıştırır; pickle oturumu bu kovaya iner.
Saldırgan pickled_main_session dosyasını kendi zararlı pickle'ı ile değiştirir.
İşçiler unpickle ederken kod, Dataflow servis hesabı yetkisiyle çalışır.

Varonis, kurban projesine hiç IAM izni gerekmediğini vurguluyor; proje ID'si çoğu zaman gizli değildir.

2. Kimler risk altındaydı?

Apache Beam Python SDK kullanan işler (Java SDK zaten sahiplik kontrolü yapıyordu).
Bölgede henüz varsayılan staging bucket'ı oluşmamış projeler.
--save_main_session açık, --staging_location verilmemiş işler.

3. Üç katmanlı düzeltme

Beam 2.75.0: istemci tarafı bucket sahiplik doğrulaması.
Dataflow kontrol düzlemi: varsayılan kova başka projeye aitse FAILED_PRECONDITION.
SHA-256 bütünlük: staging sonrası değiştirilen artefaktlar işçi tarafından reddedilir.

Eski/pinlanmış SDK'lar bile sunucu tarafı kontrol sayesinde korunuyor.

4. Sizin yapmanız gerekenler

Kod:
# Isinizde staging konumunu acikca verin
--staging_location=gs://SIZIN-PROJE-staging/beam
--temp_location=gs://SIZIN-PROJE-temp/beam

Staging kovalarını kod deposu gibi koruyun; yazma yetkisini sıkı tutun.
Pickle hâlâ pickle'dır: --save_main_session kullanımını gözden geçirin.
Servis hesabına Compute Engine varsayılanı yerine en az yetkili özel hesap verin.

Dataflow/Beam işlerinizde staging_location'ı açık mı veriyorsunuz, yoksa varsayılan mı?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

https://www.varonis.com/blog/shadow-depe...oss-tenant

13-b03-gcp-dataflow-shadow.png (Dosya Boyutu: 117.13 KB / İndirme Sayısı: 2)

Railway Ortam Değişkenleri İhlali: Tüm Kullanıcılara Acil Sır Rotasyonu Çağrısı

Fri, 23 Oct 2026 11:26:10 +0300

Selamlar,

Geliştirici bulut platformu Railway, 21 Ekim 2026 sabahı müşteri ortam değişkenlerini (environment variables) saklayan sistemlerde anormal etkinlik tespit ettiğini açıkladı. Şirketin ifadesine göre yetkisiz bir üçüncü taraf şifrelenmiş ortam değişkenlerine erişmiş ve bir kısmının şifresi çözülmüş içeriğini elde etmiş olabilir. BleepingComputer'a göre Railway'in yaklaşık 4,8 milyon kullanıcısı ve 16 milyondan fazla servisi var.

Konuda anlatılacaklar

Ne oldu?
Railway'in kendi aldığı önlemler
Kullanıcı olarak yapmanız gerekenler
Bucket ve GitHub sıfırlamasından sonra servisi ayağa kaldırmak
Platform ihlallerinden çıkarılacak ders

Ne oldu?

Railway olayı, son dönemde YZ çıkarım (inference) sağlayıcılarını ele geçirmeyi amaçlayan platform şirketlerine yönelik saldırı serisinin parçası olarak görüyor ve bu sağlayıcılara tüm anahtarları proaktif olarak iptal etmelerini bildirdi.
İlk analiz etkinin bir kullanıcı alt kümesiyle sınırlı olabileceğini gösterse de şirket tüm kullanıcılara önlem almalarını önerdi.
Soruşturma süresince tüm deploy'lar durduruldu. 22 Ekim'de Pro ve Enterprise için build'ler geri açıldı; Hobby, Free ve Trial sırayla açılacak.
TechCrunch'a göre kök neden açıklanmadı; CEO Jake Cooper bir post-mortem yayımlanacağını söyledi.

Not: Dün paylaştığımız Zeabur ihlaliyle aynı dönemde, benzer hedeflemeyle (platformdaki sırlar üzerinden YZ sağlayıcı anahtarları) gelmesi dikkat çekici.

Railway'in aldığı önlemler

22 Ekim 04:39 UTC itibarıyla tüm Railway API token'ları geçersiz kılındı. Public API entegrasyonlarınız için yeni token üretmeniz gerekiyor.
Her ortamdaki her storage bucket'ın ACCESS_KEY_ID ve SECRET_ACCESS_KEY değerleri yenilendi.
Railway'in tuttuğu GitHub token'ları geçersiz kılındı; registry kimlik bilgisi olarak saklanan GitHub token'ları Railway'den silindi. Ancak bu token'lar GitHub tarafında siz iptal edene kadar hâlâ çalışıyor.

Yapmanız gerekenler

Railway'de saklanan tüm ortam değişkenlerini döndürün: veritabanı parolaları, üçüncü taraf API anahtarları (ödeme, e-posta, YZ sağlayıcıları), JWT imzalama anahtarları.
Özel registry kimlik bilgilerini yenileyin.
GitHub'da Railway'e verilmiş personal access token'ları ve deploy key'leri kendiniz iptal edin, ardından bağlantıyı yeniden kurun.
Döndürdüğünüz her anahtarın sağlayıcı tarafındaki loglarını (bulut, ödeme, YZ API kullanım panelleri) 21 Ekim öncesinden itibaren inceleyin.

Sıralama önemli: önce sağlayıcıda yeni anahtar üretin, uygulamaya girin, deploy edin, sonra eskisini iptal edin; aksi halde kendi kendinize kesinti yaratırsınız.

Bucket ve GitHub sonrası yeniden deploy
Railway'in rehberine göre konteynerler değişkenleri yalnızca başlangıçta okur. Bucket'ın yeni kimlik bilgileri hazır ama servisinizin yeniden deploy edilmesi gerekiyor:

Kod:
railway redeploy --service uploads-api
railway bucket credentials --bucket my-bucket

Bir servis hâlâ InvalidAccessKeyId veya SignatureDoesNotMatch hatası veriyorsa ya eski deployment çalışıyordur ya da değişkene düz metin olarak yapıştırılmış eski anahtar vardır. Railway, düz metin yerine referans değişken (örneğin ${{ my-bucket.SECRET_ACCESS_KEY }}) kullanmayı öneriyor; bir sonraki rotasyonda elle düzenleme gerekmez. Denetim kayıtlarında bu sıfırlamalar "Railway Staff" aktör tipiyle görünüyor; kendi olay kaydınız için bu girdileri dışa aktarın.

Ders
PaaS platformundaki env değişkenleri, uygulamanızın tüm dış dünyaya açılan anahtarlık halkasıdır. Kısa ömürlü kimlik bilgileri (OIDC, workload identity), anahtar başına en az yetki ve harcama limitleri, platform ihlal olduğunda patlama yarıçapını ciddi şekilde küçültür.

Railway veya benzeri bir PaaS kullanıyorsanız sır rotasyonunu ne kadar sürede tamamlayabildiniz? Otomasyon önerilerinizi paylaşın.

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

07-t07-railway-env-ihlal.png (Dosya Boyutu: 120.26 KB / İndirme Sayısı: 3)

Railway Ortam Değişkenleri İhlali: Tüm Kullanıcılara Acil Sır Rotasyonu Çağrısı

Fri, 23 Oct 2026 11:22:49 +0300

Ne oldu?
Railway'in kendi aldığı önlemler
Kullanıcı olarak yapmanız gerekenler
Bucket ve GitHub sıfırlamasından sonra servisi ayağa kaldırmak
Platform ihlallerinden çıkarılacak ders

Ne oldu?

Railway olayı, son dönemde YZ çıkarım (inference) sağlayıcılarını ele geçirmeyi amaçlayan platform şirketlerine yönelik saldırı serisinin parçası olarak görüyor ve bu sağlayıcılara tüm anahtarları proaktif olarak iptal etmelerini bildirdi.
İlk analiz etkinin bir kullanıcı alt kümesiyle sınırlı olabileceğini gösterse de şirket tüm kullanıcılara önlem almalarını önerdi.
Soruşturma süresince tüm deploy'lar durduruldu. 22 Ekim'de Pro ve Enterprise için build'ler geri açıldı; Hobby, Free ve Trial sırayla açılacak.
TechCrunch'a göre kök neden açıklanmadı; CEO Jake Cooper bir post-mortem yayımlanacağını söyledi.

22 Ekim 04:39 UTC itibarıyla tüm Railway API token'ları geçersiz kılındı. Public API entegrasyonlarınız için yeni token üretmeniz gerekiyor.
Her ortamdaki her storage bucket'ın ACCESS_KEY_ID ve SECRET_ACCESS_KEY değerleri yenilendi.
Railway'in tuttuğu GitHub token'ları geçersiz kılındı; registry kimlik bilgisi olarak saklanan GitHub token'ları Railway'den silindi. Ancak bu token'lar GitHub tarafında siz iptal edene kadar hâlâ çalışıyor.

Yapmanız gerekenler

Railway'de saklanan tüm ortam değişkenlerini döndürün: veritabanı parolaları, üçüncü taraf API anahtarları (ödeme, e-posta, YZ sağlayıcıları), JWT imzalama anahtarları.
Özel registry kimlik bilgilerini yenileyin.
GitHub'da Railway'e verilmiş personal access token'ları ve deploy key'leri kendiniz iptal edin, ardından bağlantıyı yeniden kurun.
Döndürdüğünüz her anahtarın sağlayıcı tarafındaki loglarını (bulut, ödeme, YZ API kullanım panelleri) 21 Ekim öncesinden itibaren inceleyin.

Kod:
railway redeploy --service uploads-api
railway bucket credentials --bucket my-bucket

07-t07-railway-env-ihlal.png (Dosya Boyutu: 120.26 KB / İndirme Sayısı: 3)

Zeabur İkinci İhlal: 3,2 Milyon Ortam Değişkeni Okundu, Platform Kapanıyor

Thu, 22 Oct 2026 11:22:33 +0300

Selamlar,

Geliştirici barındırma platformu Zeabur, 19 Ekim 2026'da Ekim ayı güvenlik olayının ön raporunu yayınladı. Özet: saldırgan, sızdırılmış Zeabur dahili kimlik bilgileriyle paylaşımlı kümeyi, bazı GCP Dedicated Server'ları ve dahili sistemleri ele geçirdi; sonunda platform veritabanını okudu. Onaylanan sayılar: 3.218.965 ortam değişkeni kaydı ve 321.810 hesap verisi. Zeabur ayrıca 31 Aralık 2026'da kapanacağını duyurdu.

Konuda anlatılacaklar

İki yol nasıl birleşti?
Hangi veriler okundu?
Ağustos olayından sonra neden yine oldu?
Etkilenen kullanıcılar için eylem listesi
PaaS güvenliği için çıkarılacak dersler

İki yol nasıl birleşti?
Zeabur'un raporuna göre saldırgan iki yoldan ilerledi:

Yol A - paylaşımlı küme ve AWS: 14 Ekim 01:36 UTC'den itibaren Zeabur'un dahili AWS anahtarları ve paylaşımlı küme yönetici token'ları kullanıldı. Bu kimlik bilgileri düz metin olarak özel bir yapılandırma deposundaydı. Yönetici arayüzü internete açıktı ve token'ların son kullanma tarihi yoktu. Saldırgan 9 bölgedeki paylaşımlı kümeye dışarıdan erişti; 12:39'dan itibaren tüm servislerin ayarlarını ve sırlarını (ortam değişkenleri dahil) okudu; 865 veritabanı servisi içinde okuma komutları çalıştırdı.

Yol B - GCP Dedicated Server'lar: Aynı gün 13:40'tan itibaren saldırgan, Zeabur'un GCP üzerinde yönettiği 101 Dedicated Server'a root olarak giriş yaptı. Sunucu başlatma ayarlarında root parolası düz metindi; eski bir GCP anahtarıyla bu ayarlar okunabiliyordu.

İki yol 15 Ekim'de birleşti: Saldırgan, ele geçirdiği bir GCP sunucusundan Yol A'dan elde ettiği dahili ağ yönetici kimlik bilgileriyle Zeabur'un dahili ağına bir düğüm ekledi. Dahili ağ kuralları bu düğümün platform veritabanına bağlanmasına izin veriyordu. 16:10-16:47 arasında salt okunur bir hesapla veritabanı okundu; 8.903 işlem kaydı eşleştirildi.

Hangi veriler okundu?

Platform veritabanı: 3.218.965 ortam değişkeni (ad ve değer), 321.810 hesabın profil verileri, 566 zSend API anahtarı (düz metin), Access Token'lar (yalnızca hash; hepsi iptal edildi)
Paylaşımlı küme: 9 bölgede servis sırları; 865 veritabanı konteyneri içinde okuma komutları (n8n, PostgreSQL, new-api/one-api dahil)
GCP Dedicated Server: 101 sunucu, 92 kullanıcı; 50'sine kalıcılık için SSH anahtarı eklendi
GitHub App özel anahtarı: 15:05-18:54 arası okundu; şirket şu ana kadar kullanım bulamadığını söylüyor

Saldırganın davranışı AI servis anahtarlarını aramaya yoğunlaşmış görünüyor; n8n ve new-api/one-api okumaları ve Amazon Bedrock çağrı denemeleri (başarısız) bunu destekliyor. Zeabur yine de okunan her şeyi sızmış kabul ediyor.

Ağustos'tan sonra neden yine?
Bu, iki aydan kısa sürede Zeabur'un ikinci güvenlik olayı. Ağustos'ta sızdığı doğrulanan dahili anahtarlar döndürülmüştü; ancak yapılandırma deposundaki düz metin küme yönetici token'ları ve AWS anahtarları o rotasyona dahil edilmemişti. GCP sunucu başlatma ayarlarındaki root parolaları da Eylül'de tespit edilmesine rağmen olay öncesi düzeltilmemişti. Zeabur, Ağustos raporundaki "tüm dahili yönetici anahtarları devre dışı bırakıldı veya döndürüldü" ifadesinin eksik olduğunu bu raporda düzeltiyor.

Olumlu taraf: Ağustos rehberliğini takip edip ortam değişkenlerini kendi Dedicated Server'ına taşıyan projeler, platform veritabanı okumasının kapsamı dışında kaldı.

Etkilenen kullanıcılar için eylem listesi
Zeabur'un vurgusu: beklemeyin, hemen harekete geçin; Ağustos'tan sonra değiştirdiğiniz kimlik bilgilerini de yeniden değiştirin.

Ortam değişkenlerindeki tüm API anahtarlarını, bulut anahtarlarını, veritabanı parolalarını, imzalama/şifreleme anahtarlarını sağlayıcıda iptal edip yenileyin, yeniden deploy edin.
Platform Access Token'larını yeniden oluşturun (hepsi iptal edildi).
zSend kullananlar: API anahtarlarını yeniden yaratın.
GitHub: 15 Ekim 15:05-18:54 UTC arasında Zeabur GitHub App'inin beklenmeyen clone/push, deploy key veya webhook değişikliklerini denetleyin.
14 Ekim'den (GCP Dedicated kullanıcıları için 1 Eylül'den) itibaren faturaları ve kullanım kayıtlarını gözden geçirin.
Paylaşımlı küme: Veritabanı içindeki parolaları değiştirin; n8n encryption key'ini yenileyip üçüncü taraf kimlik bilgilerini yeniden oluşturun; new-api/one-api için üst akış anahtarlarını iptal edin.
GCP Dedicated: Sunucuyu yeniden kurmak en güvenli yol. En azından /root/.ssh/authorized_keys içinde @zeabur-pentest yorumlu veya tanınmayan anahtarları silin, root parolasını değiştirin, parola ile SSH'yi kapatın.

PaaS güvenliği için dersler

Yönetici token'larının son kullanma tarihi olmalı, internete açık olmamalı ve rotasyon listesinde unutulmamalıdır.
Küme yedekleri sırları içermemeli; yedek erişim anahtarı diğer sırlarla aynı ortamda tutulmamalıdır.
Kullanıcı servisleri ile dahili servisler aynı kümede çalışıyorsa, bir kullanıcı konteynerinin ele geçirilmesi dahili kimlik bilgilerine giden yol olabilir.
16 saatten fazla saldırı etkinliğinin alarm üretmemesi, denetim ve tespit kapsamının en az yetki kadar kritik olduğunu gösteriyor.

PaaS üzerinde ortam değişkeni tutanlar: sırlarınızı kendi sunucunuza taşıma planınız var mı?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

07-t07-zeabur-ihlal.png (Dosya Boyutu: 120.92 KB / İndirme Sayısı: 5)

Zeabur İkinci İhlal: 3,2 Milyon Ortam Değişkeni Okundu, Platform Kapanıyor

Thu, 22 Oct 2026 11:21:41 +0300

İki yol nasıl birleşti?
Hangi veriler okundu?
Ağustos olayından sonra neden yine oldu?
Etkilenen kullanıcılar için eylem listesi
PaaS güvenliği için çıkarılacak dersler

Platform veritabanı: 3.218.965 ortam değişkeni (ad ve değer), 321.810 hesabın profil verileri, 566 zSend API anahtarı (düz metin), Access Token'lar (yalnızca hash; hepsi iptal edildi)
Paylaşımlı küme: 9 bölgede servis sırları; 865 veritabanı konteyneri içinde okuma komutları (n8n, PostgreSQL, new-api/one-api dahil)
GCP Dedicated Server: 101 sunucu, 92 kullanıcı; 50'sine kalıcılık için SSH anahtarı eklendi
GitHub App özel anahtarı: 15:05-18:54 arası okundu; şirket şu ana kadar kullanım bulamadığını söylüyor

Ortam değişkenlerindeki tüm API anahtarlarını, bulut anahtarlarını, veritabanı parolalarını, imzalama/şifreleme anahtarlarını sağlayıcıda iptal edip yenileyin, yeniden deploy edin.
Platform Access Token'larını yeniden oluşturun (hepsi iptal edildi).
zSend kullananlar: API anahtarlarını yeniden yaratın.
GitHub: 15 Ekim 15:05-18:54 UTC arasında Zeabur GitHub App'inin beklenmeyen clone/push, deploy key veya webhook değişikliklerini denetleyin.
14 Ekim'den (GCP Dedicated kullanıcıları için 1 Eylül'den) itibaren faturaları ve kullanım kayıtlarını gözden geçirin.
Paylaşımlı küme: Veritabanı içindeki parolaları değiştirin; n8n encryption key'ini yenileyip üçüncü taraf kimlik bilgilerini yeniden oluşturun; new-api/one-api için üst akış anahtarlarını iptal edin.
GCP Dedicated: Sunucuyu yeniden kurmak en güvenli yol. En azından /root/.ssh/authorized_keys içinde @zeabur-pentest yorumlu veya tanınmayan anahtarları silin, root parolasını değiştirin, parola ile SSH'yi kapatın.

PaaS güvenliği için dersler

Yönetici token'larının son kullanma tarihi olmalı, internete açık olmamalı ve rotasyon listesinde unutulmamalıdır.
Küme yedekleri sırları içermemeli; yedek erişim anahtarı diğer sırlarla aynı ortamda tutulmamalıdır.
Kullanıcı servisleri ile dahili servisler aynı kümede çalışıyorsa, bir kullanıcı konteynerinin ele geçirilmesi dahili kimlik bilgilerine giden yol olabilir.
16 saatten fazla saldırı etkinliğinin alarm üretmemesi, denetim ve tespit kapsamının en az yetki kadar kritik olduğunu gösteriyor.

07-t07-zeabur-ihlal.png (Dosya Boyutu: 120.92 KB / İndirme Sayısı: 2)

Azure Blob Storage Yanlış Yapılandırması: Genel Erişim, SAS ve Denetim

Mon, 19 Oct 2026 01:52:01 +0300

Merhaba,

Azure Blob'da yanlışlıkla public container bırakmak hâlâ klasik bulgu. Bu yazıda genel erişim seviyeleri, SAS riskleri ve denetim için pratik kontrolleri anlatıyorum. Örnekler kendi lab aboneliğim üzerinden.

Erişim katmanları

Private: anonim erişim yok
Blob: anonim kullanıcı blob bilgisini URL ile okuyabilir
Container: listeleme de açık (daha kötü)

Depolama hesabında "Allow blob public access" kapalıysa container public yapsanız bile engellenir. İkisini birden kontrol edin.

Kod:
az storage account show -n LABSTORE -g LABRG --query allowBlobPublicAccess
az storage container show --account-name LABSTORE -n uploads --query publicAccess

SAS token tuzakları
Shared Access Signature geçici yetki verir; fakat:

Çok uzun expiry (yıllarca) = fiilen anahtar
İzinlerin fazla olması (write+delete+list)
HTTPS zorunluluğu olmaması
SAS'ın GitHub'a / mobil uygulamaya gömülmesi

Tercihen user delegation SAS (Azure AD kimliğiyle) kullanın; hesap anahtarıyla üretilen SAS sızıntısında rotasyon daha acı olur.

Denetim ve tespit

Azure Resource Graph / Policy ile public container taraması
Diagnostic settings: StorageRead/Write loglarını Log Analytics'e
Microsoft Defender for Storage (ortamınızda varsa) anomali uyarısı
CI'da Terraform plan: public_access != null ise fail

Örnek Resource Graph düşüncesi: storage container'larında publicAccess alanı boş olmayanlar.

Sıkılaştırma adımları

Hesapta public access'i kapat
Gerekli anonim dağıtım varsa Azure CDN + kontrollü origin kullan
Firewall: selected networks + private endpoint
Shared key access'i mümkünse kapatıp AAD'ye geç
SAS için kısa TTL + minimum permission

Kod:
az storage account update -n LABSTORE -g LABRG --allow-blob-public-access false

Olay senaryosu
Public container'da müşteri verisi bulunduysa: hemen private yap, SAS/account key rotate et, logdan kim indirmiş bak, KVKK sürecini tetikle. "URL'yi gizledik" yetmez; URL zaten indekslenmiş olabilir.

Kaynaklar

Microsoft Learn: Azure Storage security guide
Azure Security Benchmark - Storage
SAS best practices (Microsoft Docs)

Siz storage hesaplarında shared key'i kapatabildiniz mi, yoksa eski uygulamalar mı engelliyor?

Private endpoint ve DNS
Storage'ı private endpoint arkasına alınca eski public URL'ler kırılır; uygulamaları güncelleyin. DNS zone'ları (privatelink) doğru değilse geliştirici "Azure bozuldu" diye public'i geri açar — en sık regressiyon.

Lifecycle ve soft delete
Yanlışlıkla silinen kanıt / yedek için soft delete ve versioning açın. Fidye senaryosunda immutable storage (WORM) politikaları ayrı başlıktır; en azından kritik konteynerlerde versioning açık olsun.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.

100-n18-4ecc77.png (Dosya Boyutu: 67.04 KB / İndirme Sayısı: 13)

n18-inner.png (Dosya Boyutu: 20.26 KB / İndirme Sayısı: 14)

AWS IAM En Az Yetki: Access Analyzer ve Policy Simulator Pratikleri

Mon, 19 Oct 2026 01:34:50 +0300

Selam,

AWS'te en sık gördüğüm bulgu hâlâ aşırı geniş IAM izinleri: Action "*" ve Resource "*". Bu yazıda en az yetki için Access Analyzer ve Policy Simulator'ı kendi hesabınızda (lab) nasıl kullanacağınızı anlatıyorum.

En az yetki pratiği

İnsan kullanıcı yerine rol + kısa ömürlü kimlik bilgisi
Admin Access'i günlük iş için vermeyin; break-glass hesabı ayırın
Wildcard Action'ları gerekçelendirin veya kaldırın
SCPs ile organizasyon sınırları (AWS Organizations)

IAM Access Analyzer
Analyzer, hesap dışına açılan erişimleri ve (kullanım tipine göre) kullanılmayan izinleri bulmanıza yardım eder. Konsolda IAM > Access Analyzer veya CLI:

Kod:
aws accessanalyzer list-analyzers
aws accessanalyzer list-findings --analyzer-arn arn:aws:access-analyzer:REGION:ACCOUNT:analyzer/NAME

Bulgular: public S3, çapraz hesap rol güveni, beklenmeyen principal'lar. Her bulguyu "bilinçli mi?" diye işaretleyin; bilinçliyse arşivleyip gerekçe yazın.

Policy Simulator
Bir rolün belirli Action'ı yapıp yapamayacağını denemek için:

Kod:
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::ACCOUNT:role/AppRole \
  --action-names s3:GetObject ec2:TerminateInstances \
  --resource-arns arn:aws:s3:::lab-bucket/*

Çıktıdaki EvalDecision: allowed / implicitDeny / explicitDeny. CI boru hattında yeni policy PR'ları için simülasyon koşturmak FP'li prod olaylarını azaltır.

İzin sınırları (permissions boundary)
Geliştiriciye politika ekleme hakkı verirken boundary ile tavan koyun. Böylece kendini admin yapamaz. CloudFormation / Terraform modüllerinde boundary ARN'sini zorunlu tutun.

Son 90 gün erişim önerileri
IAM konsolunda Access Advisor, bir rolün kullandığı servisleri gösterir. Kullanılmayan geniş yönetilen politikaları daraltmak için başlangıç noktasıdır; körlemesine silmeyin, önce staging'de deneyin.

Kontrol listesi

Root kullanıcıda MFA + kasa; günlük iş yok
Access Analyzer aktif, haftalık gözden geçirme
Public bulgular için alarm (EventBridge)
CI'da policy-as-code (например, IAM Access Analyzer policy validation / OPA)

Kaynaklar

AWS IAM User Guide - Access Analyzer
AWS Policy Simulator dokümantasyonu
CIS AWS Foundations Benchmark

Siz wildcard temizliği için Access Advisor mı, yoksa CloudTrail tabanlı araçlar mı kullanıyorsunuz?

Örnek daraltma hikâyesi
AmazonS3FullAccess yerine ListBucket + GetObject + belirli bucket ARN. PutObject gerekiyorsa ayrı rol. CI rolü ile insan rolünü ayırın. Access Analyzer unused access bulgularını 30 günde bir sprint backlog'una taşıyın; birikirse kimse okumaz.

Policy as code
Terraform aws_iam_policy_document kullanırken heredoc JSON yapıştırmayın; argument'ler review edilebilir kalsın. PR'da simulate-principal-policy veya IAM Access Analyzer policy validation çalıştırın.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.

100-n17-9fb51c.png (Dosya Boyutu: 62.22 KB / İndirme Sayısı: 13)

n17-inner.png (Dosya Boyutu: 21.15 KB / İndirme Sayısı: 12)

Prowler ile AWS Güvenlik Denetimi 2026: Açık Kaynak CSPM ile Kendi Hesabınızı Tarayın

Sun, 18 Oct 2026 20:13:16 +0300

Merhaba arkadaşlar,

Bulut hesabınızda yüzlerce kaynak varsa, "acaba bir yerde açık bir S3 bucket ya da fazla yetkili bir IAM kullanıcısı mı kaldı?" sorusunu elle cevaplamak imkansızdır. İşte bu noktada bulut güvenlik duruşu yönetimi (CSPM) araçları devreye girer. Prowler, AWS başta olmak üzere birçok sağlayıcıyı tarayan, açık kaynak ve ücretsiz bir CSPM aracıdır. Bu rehberde Prowler'ı resmi belgelerine dayanarak kurup kendi AWS hesabınızda nasıl güvenlik denetimi yapacağınızı, raporları nasıl okuyacağınızı ve bulguları nasıl önceliklendireceğinizi anlatıyorum. Tüm komutlar yalnızca kendi hesabınızda veya yazılı izniniz olan hesaplarda çalıştırılmalıdır.

Konuda Anlatılacaklar

CSPM nedir, Prowler ne yapar?
Kurulum ve kimlik doğrulama
En az yetkili denetim kullanıcısı
İlk tarama ve raporlar
Uyumluluk çerçeveleriyle tarama
Belirli servis/kontrol çalıştırma
Bulguları önceliklendirme ve düzenli denetim

CSPM Nedir, Prowler Ne Yapar?

CSPM araçları, bulut yapılandırmanızı bilinen güvenlik en iyi uygulamaları ve uyumluluk çerçeveleriyle karşılaştırır; yanlış yapılandırmaları (açık bucket, şifresiz disk, MFA'sız kök hesap, aşırı geniş IAM) tespit eder. Prowler, resmi belgelerine göre AWS, Azure, GCP, Kubernetes, Microsoft 365, GitHub ve daha fazlasını destekler. Yüzlerce hazır kontrol ve CIS, NIST gibi uyumluluk çerçeveleriyle gelir.

Kurulum ve Kimlik Doğrulama

Prowler, Python ile kurulur (resmi belgelere göre Python 3.10-3.13):

Kod:
pip install prowler
prowler -v

Prowler, komut çalıştırıldığında ortam değişkeni veya profil üzerinden AWS kimlik bilgilerini kullanır. Önce AWS CLI ile kimliğinizi doğrulayın:

Kod:
aws sts get-caller-identity

Prowler sağlayıcıyı ilk argüman olarak alır (belirtmezseniz geriye dönük uyumluluk için AWS varsayılır):

Kod:
prowler aws
prowler aws --profile kendi-profilim

En Az Yetkili Denetim Kullanıcısı

Prowler yalnızca okuma yapar; bu yüzden ona yazma yetkisi vermeyin. AWS'nin yönetilen SecurityAudit ve ViewOnlyAccess politikaları çoğu kontrol için yeterlidir. En az yetki ilkesine uygun olarak Prowler için ayrı bir IAM rolü/kullanıcısı oluşturun ve yalnızca bu salt okunur politikaları bağlayın. Kök hesapla veya AdministratorAccess ile tarama yapmak, gereksiz risktir.

İlk Tarama ve Raporlar

En basit haliyle tüm hesabı tüm bölgelerde tarayın:

Kod:
prowler aws

Prowler resmi belgelerine göre varsayılan olarak CSV, JSON-OCSF ve HTML raporları üretir ve bunları output dizinine kaydeder. Çıktı formatını kendiniz de seçebilirsiniz:

Kod:
prowler aws -M csv json-ocsf html

Belirli bir profil ve bölgeyle sınırlamak:

Kod:
prowler aws --profile kendi-profilim -f eu-central-1 eu-west-1

HTML raporu tarayıcıda açıp bulguları önem (severity) ve servis bazında filtreleyebilirsiniz. İlk taramada yüzlerce bulgu görmek normaldir; panik yapmayın, önceliklendirin.

Uyumluluk Çerçeveleriyle Tarama

Prowler, taramayı bir uyumluluk çerçevesine göre yapabilir. Örneğin CIS AWS Benchmark'a göre:

Kod:
prowler aws --compliance cis_3.0_aws

Mevcut çerçeveleri ve kontrolleri listelemek için:

Kod:
prowler aws --list-compliance
prowler aws --list-checks
prowler aws --list-services

Uyumluluk modu, denetim raporlarına ve yönetime sunum yaparken özellikle değerlidir; her bulguyu bir çerçeve maddesiyle eşler.

Belirli Servis veya Kontrol Çalıştırma

Tüm hesabı taramak yerine tek bir servise odaklanabilirsiniz. Belgelerdeki örneklere göre:

Kod:
prowler aws --services s3 ec2
prowler aws --checks s3_bucket_public_access

Belirli kontrolleri hariç tutmak da mümkündür:

Kod:
prowler aws --excluded-checks s3_bucket_public_access

Böylece "önce S3'ü düzeltelim" gibi odaklı iyileştirme turları yapabilirsiniz.

Prowler Nasıl Tarar? Kontrol Mantığı

Prowler her kontrolü küçük, bağımsız bir modül olarak çalıştırır. Bir kontrol, ilgili AWS API'sini salt okunur biçimde çağırır (örneğin S3 için get-public-access-block, bucket politikası), sonucu beklenen güvenli duruma göre değerlendirir ve PASS/FAIL olarak işaretler. Bu yüzden Prowler hiçbir şeyi değiştirmez; yalnızca mevcut yapılandırmayı okur ve yorumlar. Her bulgu; kontrol kimliği, önem düzeyi, etkilenen kaynak, açıklama ve düzeltme (remediation) önerisiyle birlikte gelir. Bu alanlar HTML raporunda sütun olarak görünür ve JSON-OCSF çıktısında makine tarafından işlenebilir biçimde yer alır, böylece bulguları bir SIEM'e veya tablolama aracına aktarabilirsiniz.

İleri Seviye: Bulguları Önceliklendirme ve Düzenli Denetim

İlk taramadan sonra bir eylem planı çıkarın:

Önce kritik ve yüksek (critical/high) bulgular: açık bucket, herkese açık güvenlik grubu (0.0.0.0/0), MFA'sız kök hesap, şifresiz veritabanı.
Sonra orta (medium): loglama eksikleri, eski erişim anahtarları.
Düzenli tekrar: Prowler'ı CI/CD veya zamanlanmış bir görev olarak çalıştırıp değişimi izleyin.

Taramayı tarih damgalı bir dizine kaydedip zamanla karşılaştırmak, duruşunuzun iyileşip iyileşmediğini gösterir:

Kod:
prowler aws -M json-ocsf html \
  --output-directory ./denetim-$(date +%F)

Not: Çoklu hesap (AWS Organizations) ortamlarında Prowler'ı bir denetim rolüyle tüm hesaplarda çalıştırabilirsiniz; ancak bu, yalnızca bu hesapların sahibi veya yetkili yöneticisiyseniz yapılmalıdır. Prowler'ın yönetilen SaaS sürümü (Prowler Cloud) ve açık kaynak yerel paneli de sürekli izleme için kullanılabilir.

Sonuç

Prowler, kendi AWS hesabınızın güvenlik duruşunu ücretsiz ve hızlı biçimde ölçmenin en pratik yollarından biri. Salt okunur bir denetim kullanıcısıyla kurun, varsayılan CSV/JSON/HTML raporlarıyla başlayın, CIS gibi bir çerçeveye göre tarayın ve kritik bulgulardan başlayarak düzenli iyileştirme turları yapın. Siz hangi CSPM aracını kullanıyorsunuz, ilk taramada en çok hangi bulguyla karşılaştınız? Yorumlarda paylaşın.

Kaynakça

Prowler belgeleri, Basic Usage: https://docs.prowler.com/getting-started...rowler-cli
Prowler belgeleri, Installation: https://docs.prowler.com/getting-started...rowler-cli
Prowler belgeleri, Reporting: https://docs.prowler.com/user-guide/cli/.../reporting
Prowler belgeleri, Compliance: https://docs.prowler.com/user-guide/comp...compliance
Prowler (PyPI): https://pypi.org/project/prowler/
AWS CLI, get-caller-identity: https://docs.aws.amazon.com/cli/latest/r...ntity.html
AWS, SecurityAudit yönetilen politikası: https://docs.aws.amazon.com/aws-managed-...Audit.html

Yasal Uyarı

Bu rehberdeki tarama komutları yalnızca kendi AWS hesabınızda veya yazılı olarak yetkilendirildiğiniz hesaplarda çalıştırılmalıdır. Başkasına ait bulut kaynaklarını izinsiz taramak veya bunlara erişmek 5237 sayılı Türk Ceza Kanunu'nun 243, 244 ve 245. maddeleri kapsamında suçtur. TurkTeam yalnızca savunma ve eğitim amaçlı paylaşımları destekler.

Görsel: TurkTeam özgün kapak ve diyagramları

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

  09-cover.png (Dosya Boyutu: 242.22 KB / İndirme Sayısı: 8)

  09-a.jpg (Dosya Boyutu: 54.27 KB / İndirme Sayısı: 8)

  09-b.jpg (Dosya Boyutu: 61.99 KB / İndirme Sayısı: 8)

  09-c.jpg (Dosya Boyutu: 53.15 KB / İndirme Sayısı: 8)

Entra ID Güvenliği 2026: Koşullu Erişim, Zorunlu MFA ve PIM ile Kimlik Sertleştirme

Sun, 18 Oct 2026 20:09:47 +0300

Merhaba arkadaşlar,

Bulut saldırılarının büyük kısmı bir açıktan değil, ele geçirilmiş bir kimlikten başlıyor. Microsoft'un kimlik servisi Entra ID (eski adıyla Azure AD) üzerinde doğru yapılandırılmış üç kontrol, saldırı yüzeyinin büyük bölümünü kapatır: Koşullu Erişim (Conditional Access), çok faktörlü kimlik doğrulama (MFA) ve ayrıcalıklı erişim yönetimi (PIM). 2026'da Microsoft Azure için MFA'yı kademeli olarak zorunlu hale getirdi. Bu rehberde bu üç kontrolü resmi Microsoft Learn belgelerine dayanarak savunma gözüyle ele alıyorum. Amaç saldırmak değil, kendi kiracınızı (tenant) güvenli kurmak.

Konuda Anlatılacaklar

Entra ID kimlik güvenliğinin temeli
2026 zorunlu MFA: ne, ne zaman, kimi kapsıyor?
Koşullu Erişim nasıl çalışır?
Örnek politikalar
PIM ile en az ayrıcalık ve tam zamanında erişim
İzleme ve doğrulama
Yaygın hatalar

Entra ID Kimlik Güvenliğinin Temeli

Bulutta "ağ çevresi" yerini "kimlik çevresine" bıraktı. Entra ID'de güvenliğin üç ayağı vardır: güçlü kimlik doğrulama (parola + MFA), bağlama göre erişim kararı (Koşullu Erişim) ve ayrıcalıklı rollerin sürekli değil ihtiyaç anında verilmesi (PIM). Bu üçünü birlikte kurduğunuzda, çalınmış bir parola tek başına işe yaramaz hale gelir.

2026 Zorunlu MFA: Ne, Ne Zaman, Kimi Kapsıyor?

Microsoft'un resmi planına göre Azure için zorunlu MFA iki aşamalı devreye girdi. İkinci aşama (Phase 2) 1 Ekim 2025'ten itibaren kiracılara kademeli olarak uygulanmaya başladı ve şunları kapsar:

Azure CLI, Azure PowerShell, SDK'lar, IaC araçları, REST API ve mobil uygulama üzerinden yapılan oluşturma, güncelleme ve silme (CUD) işlemleri.
Yalnızca okuma (read) işlemleri bu zorunluluğun dışındadır.

En iyi deneyim için Azure CLI 2.76+ ve Azure PowerShell 14.3+ önerilir. Önemli: Kullanıcı kimliğiyle çalışan otomasyonlar bundan etkilenir; bu tür işleri yönetilen kimliklere (managed identity) veya hizmet sorumlularına (service principal) taşıyın, çünkü bunlar kullanıcı MFA zorunluluğuna tabi değildir. Kiracılar bu aşamayı 1 Temmuz 2026'ya kadar erteleyebiliyordu; bu erteleme penceresi kapandı.

Koşullu Erişim Nasıl Çalışır?

Microsoft Learn'e göre Koşullu Erişim politikası bir "eğer-ise" (if-then) ifadesidir: belirli sinyaller (kullanıcı, uygulama, cihaz, konum, risk) karşılanırsa belirli erişim kontrolleri (grant/block) uygulanır. Aynı anda birden çok politika uygulanıyorsa hepsi birden sağlanmalıdır (mantıksal AND). Kullanılabilen "grant" (izin) kontrollerinden bazıları:

Require multifactor authentication (MFA iste)
Require authentication strength (belirli kimlik doğrulama gücü)
Require device to be marked as compliant (Intune uyumlu cihaz)
Require Microsoft Entra hybrid joined device
Require approved client app / app protection policy
Require password change / terms of use

Örnek Politikalar

Aşağıdaki politikalar kavramsal örneklerdir; kendi test kiracınızda önce "yalnızca rapor" (report-only) modunda deneyin.

1) Yöneticiler için her zaman MFA:

Atamalar: Hedef kullanıcılar = dizin yönetici rolleri.
Hedef kaynaklar: Tüm bulut uygulamaları.
Erişim kontrolü: Grant -> Require multifactor authentication.

2) Eski (legacy) kimlik doğrulamayı engelle: Temel kimlik doğrulama (basic auth) MFA'yı atlatır. Koşullu Erişim'de "Other clients / legacy authentication clients" koşulunu seçip Block uygulayın. Bu, kimlik güvenliğinin en etkili tek adımlarından biridir.

3) Riskli oturum açmada MFA (Entra ID Protection gerektirir): Sign-in risk = medium/high olduğunda MFA iste.

Her politika için report-only modunu kullanarak önce etkisini loglardan izleyin, sonra açın. Yanlışlıkla kendinizi dışarıda bırakmamak için en az bir "acil erişim" (break-glass) hesabını politikaların dışında tutun.

PIM ile En Az Ayrıcalık ve Tam Zamanında Erişim

Privileged Identity Management (PIM), ayrıcalıklı rolleri sürekli atamak yerine "uygun" (eligible) hale getirir; kullanıcı rolü ihtiyaç duyduğunda, süreli olarak etkinleştirir (just-in-time). Microsoft Learn'e göre PIM ile yapılabilecekler:

Rol etkinleştirmede MFA zorunlu kılma.
Etkinleştirmede Koşullu Erişim kimlik doğrulama bağlamı (authentication context) isteme.
Onay (approval) gerektirme ve etkinleştirme gerekçesi (justification) isteme.
Süreli (time-bound) atama ve etkinleştirme bildirimleri.
Düzenli erişim incelemeleri (access reviews).

Belgelere göre önemli bir pratik: Kimlik doğrulama bağlamını PIM ayarına eklemeden önce o bağlamı hedefleyen Koşullu Erişim politikasını oluşturup etkinleştirin. Eğer bağlamı hedefleyen hiçbir politika yoksa, PIM yedek koruma olarak etkinleştirmede MFA'yı zaten zorunlu tutar.

İzleme ve Doğrulama

Yapılandırmayı kurduktan sonra doğrulayın. Microsoft Graph PowerShell ile mevcut Koşullu Erişim politikalarını listeleyebilirsiniz (yalnızca kendi kiracınızda, yetkili hesapla):

Kod:
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy |
  Select-Object DisplayName, State |
  Format-Table -AutoSize

Oturum açma günlüklerini (sign-in logs) inceleyerek hangi politikanın hangi oturuma uygulandığını görebilir, report-only sonuçlarını buradan okuyabilirsiniz. Düzenli olarak: MFA kaydı olmayan kullanıcıları, kullanılmayan ayrıcalıklı rolleri ve legacy auth denemelerini kontrol edin.

İleri Seviye: Yaygın Hatalar

Break-glass hesabı unutmak: Tüm hesapları MFA/CA politikasına bağlayıp kilitli kalmak. En az bir acil erişim hesabını istisna tutun ve güçlü biçimde koruyun.
Legacy auth'u açık bırakmak: MFA'yı atlatan en büyük açık budur.
Ayrıcalıkları kalıcı atamak: Global Administrator gibi rolleri sürekli vermek yerine PIM ile eligible yapın.
Otomasyonu kullanıcı hesabıyla çalıştırmak: Zorunlu MFA sonrası bozulur; managed identity/service principal kullanın.
Politikaları test etmeden açmak: Önce report-only.

Sonuç

Entra ID güvenliğinde üçlü sacayağı nettir: her yönetici için MFA, legacy auth'u kapatan ve bağlama göre karar veren Koşullu Erişim, kalıcı ayrıcalık yerine PIM ile tam zamanında erişim. 2026 zorunlu MFA'sını fırsata çevirin: otomasyonlarınızı managed identity'ye taşıyın ve kimlik duruşunuzu sadeleştirin. Siz kiracınızda hangi kontrolü olmazsa olmaz görüyorsunuz? Yorumlarda konuşalım.

Kaynakça

Microsoft Learn, Plan for mandatory Entra MFA: https://learn.microsoft.com/en-us/entra/...entication
Azure Blog, Mandatory MFA Phase 2: https://azure.microsoft.com/en-us/blog/a...ober-2025/
Microsoft Learn, Build Conditional Access policies: https://learn.microsoft.com/en-us/entra/...s-policies
Microsoft Learn, Configure Entra role settings in PIM: https://learn.microsoft.com/en-us/entra/...t-settings
Microsoft Learn, Plan a PIM deployment: https://learn.microsoft.com/en-us/entra/...yment-plan
Microsoft Learn, Get-MgIdentityConditionalAccessPolicy: https://learn.microsoft.com/en-us/powers...cesspolicy

Yasal Uyarı

Bu rehberdeki tüm yapılandırma ve komutlar yalnızca kendi Entra ID kiracınızda veya yazılı olarak yetkilendirildiğiniz ortamlarda uygulanmalıdır. Başkasına ait kimlik sistemlerine izinsiz erişim 5237 sayılı Türk Ceza Kanunu'nun 243, 244 ve 245. maddeleri kapsamında suçtur. TurkTeam yalnızca savunma ve eğitim amaçlı paylaşımları destekler.

Görsel: TurkTeam özgün kapak ve diyagramları

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

  07-cover.png (Dosya Boyutu: 234.16 KB / İndirme Sayısı: 9)

  07-a.jpg (Dosya Boyutu: 74.83 KB / İndirme Sayısı: 8)

  07-b.jpg (Dosya Boyutu: 57.98 KB / İndirme Sayısı: 9)

  07-c.jpg (Dosya Boyutu: 61.55 KB / İndirme Sayısı: 8)

Kubernetes Güvenliği 2026: RBAC, Pod Security Standards, NetworkPolicy ve kube-bench

Sun, 18 Oct 2026 20:07:32 +0300

Merhaba arkadaşlar,

Kubernetes, modern uygulamaların çalıştığı fiili standart haline geldi; ama varsayılan bir küme güvenli değildir. Yanlış yapılandırılmış RBAC, ayrıcalıklı pod'lar ve kısıtlanmamış ağ trafiği, saldırganın bir konteynerden tüm kümeye yayılmasına zemin hazırlar. Bu rehberde Kubernetes güvenliğinin dört temel taşını resmi Kubernetes belgelerine dayanarak savunma gözüyle ele alıyorum: RBAC, Pod Security Standards, NetworkPolicy ve kube-bench ile CIS denetimi. Tüm komutlar kendi test kümenizde (örneğin minikube/kind) çalıştırılmalıdır.

Konuda Anlatılacaklar

Kubernetes saldırı yüzeyi
RBAC ile en az yetki
Pod Security Standards ve Admission
NetworkPolicy ile ağ segmentasyonu
Secret yönetimi
kube-bench ile CIS denetimi
Test lab kurulumu

Kubernetes Saldırı Yüzeyi

Bir Kubernetes kümesinde başlıca risk alanları: API sunucusuna aşırı geniş erişim (RBAC), konteyner kaçışına izin veren ayrıcalıklı pod'lar, pod'lar arası sınırsız yatay trafik (lateral movement), açıkta kalan Secret'lar ve güncellenmemiş bileşenler. Savunma, bu alanların her birine bir kontrol koymaktır.

RBAC ile En Az Yetki

Role-Based Access Control (RBAC), kimin hangi kaynak üzerinde ne yapabileceğini belirler. Kubernetes belgelerine göre Role (namespace kapsamlı) veya ClusterRole (küme geneli) ile izinler tanımlanır, RoleBinding/ClusterRoleBinding ile özneye (kullanıcı, grup, ServiceAccount) atanır. Altın kural: geniş "cluster-admin" dağıtmak yerine dar roller verin.

Yalnızca belirli bir namespace'te pod okuyabilen bir rol örneği:

Kod:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: uygulama
  name: pod-okuyucu
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Bu rolü bir ServiceAccount'a bağlamak:

Kod:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-okuyucu-baglama
  namespace: uygulama
subjects:
- kind: ServiceAccount
  name: izleme-sa
  namespace: uygulama
roleRef:
  kind: Role
  name: pod-okuyucu
  apiGroup: rbac.authorization.k8s.io

Kendi yetkinizi kontrol etmek için kubectl'in yerleşik aracı:

Kod:
kubectl auth can-i create deployments --namespace uygulama
kubectl auth can-i '*' '*' --all-namespaces

İkinci komut "yes" dönüyorsa fazla yetkiniz var demektir; bunu daraltın.

Pod Security Standards ve Admission

Kubernetes, PodSecurityPolicy'yi kaldırdı ve yerine yerleşik Pod Security Admission denetleyicisini getirdi. Üç profil vardır: privileged (kısıtsız), baseline (bilinen ayrıcalık yükseltmelerini engeller) ve restricted (sıkı en iyi uygulamalar). Belgelerine göre profiller namespace etiketleriyle uygulanır. "restricted" profili zorunlu kılan etiketleme:

Kod:
kubectl label namespace uygulama \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=v1.37

enforce dışında audit ve warn modları da vardır; önce warn/audit ile etkisini görmek iyi bir yaklaşımdır:

Kod:
kubectl label namespace uygulama \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted --overwrite

Pod tanımında da sertleştirme yapın: ayrıcalıklı çalıştırmayın, kök olmayan kullanıcı kullanın, salt okunur kök dosya sistemi tercih edin:

Kod:
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

NetworkPolicy ile Ağ Segmentasyonu

Varsayılan olarak bir kümedeki tüm pod'lar birbiriyle serbestçe konuşabilir. NetworkPolicy ile bunu kısıtlarsınız (CNI eklentinizin NetworkPolicy desteklemesi gerekir). Önce namespace'te tüm gelen trafiği varsayılan olarak reddeden bir politika:

Kod:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: varsayilan-ingress-reddet
  namespace: uygulama
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Boş podSelector tüm pod'ları seçer; ingress kuralı tanımlanmadığı için hiçbir gelen trafiğe izin verilmez. Sonra yalnızca gereken trafiği açarsınız (örneğin frontend'den backend'e). Bu "önce hepsini kapat, sonra gerekeni aç" yaklaşımı sıfır güven (zero trust) ağ modelinin temelidir.

Secret Yönetimi

Kubernetes Secret'ları varsayılan olarak yalnızca base64 ile kodlanır, şifrelenmez. Belgelere göre etcd'de bekleyen veri şifrelemesini (encryption at rest) etkinleştirmek ve Secret'lara RBAC ile erişimi kısıtlamak gerekir. Secret'ları asla git deposuna düz metin olarak koymayın; dışarıdan bir gizli bilgi yöneticisi (ör. harici KMS) ile entegrasyon tercih edin. Bir Secret'ı kimlerin okuyabildiğini RBAC ile sınırlayın; "get secrets" iznini herkese vermeyin.

kube-bench ile CIS Denetimi

Aqua Security'nin açık kaynak aracı kube-bench, kümeyi CIS Kubernetes Benchmark'a göre denetler. Resmi belgelere göre küme içinde bir Job olarak çalıştırılır:

Kod:
kubectl apply -f job.yaml
kubectl get pods
# kube-bench-xxxxx Completed olduğunda:
kubectl logs kube-bench-xxxxx

Belgelerde belirtildiği gibi Job hostPID ve host yolu bağlamaları kullanır; kontrol düzlemi düğümünde çalışması için gerekirse nodeSelector ve toleration ekleyin. Çıktı [PASS]/[FAIL]/[WARN] olarak gelir; FAIL maddelerini önceliklendirin.

İleri Seviye: Test Lab Kurulumu

Üretim kümesinde deneme yapmayın. Kendi bilgisayarınızda bir test kümesi kurun:

Kod:
# minikube ile
minikube start --kubernetes-version=stable
kubectl create namespace uygulama
kubectl label namespace uygulama pod-security.kubernetes.io/warn=restricted
# ihlal eden bir pod deneyin, uyariyi gorun
kubectl run test --image=nginx -n uygulama

Bu lab'da RBAC rollerini, PSA profillerini ve NetworkPolicy'leri güvenle deneyip davranışı gözlemleyebilirsiniz. Ardından bir zafiyet tarayıcısıyla (örneğin imajlar için Trivy) konteyner imajlarınızı da tarayın.

Sonuç

Kubernetes güvenliğinde dört temel: RBAC ile en az yetki, Pod Security Admission ile restricted profil, NetworkPolicy ile "önce kapat sonra aç" segmentasyon ve kube-bench ile düzenli CIS denetimi. Bunları bir test kümesinde deneyip sonra üretime taşıyın. Siz kümelerinizde hangi kontrolü ilk uyguluyorsunuz? Yorumlarda paylaşın.

Kaynakça

Kubernetes, Using RBAC Authorization: https://kubernetes.io/docs/reference/acc...uthz/rbac/
Kubernetes, Pod Security Admission: https://kubernetes.io/docs/concepts/secu...admission/
Kubernetes, Enforce Pod Security Standards with Namespace Labels: https://kubernetes.io/docs/tasks/configu...ce-labels/
Kubernetes, Network Policies: https://kubernetes.io/docs/concepts/serv...-policies/
Kubernetes, Encrypting Confidential Data at Rest: https://kubernetes.io/docs/tasks/adminis...rypt-data/
Kubernetes, Authorization (kubectl auth can-i): https://kubernetes.io/docs/reference/acc...orization/
Aqua Security, kube-bench: https://aquasecurity.github.io/kube-bench/

Yasal Uyarı

Bu rehberdeki tüm komutlar yalnızca kendi test kümenizde veya yazılı olarak yetkilendirildiğiniz ortamlarda çalıştırılmalıdır. Başkasına ait Kubernetes kümelerine izinsiz erişim veya denetim 5237 sayılı Türk Ceza Kanunu'nun 243, 244 ve 245. maddeleri kapsamında suçtur. TurkTeam yalnızca savunma ve eğitim amaçlı paylaşımları destekler.

Görsel: TurkTeam özgün kapak ve diyagramları

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

  08-cover.png (Dosya Boyutu: 257.02 KB / İndirme Sayısı: 10)

  08-a.jpg (Dosya Boyutu: 112.32 KB / İndirme Sayısı: 8)

  08-b.jpg (Dosya Boyutu: 60.54 KB / İndirme Sayısı: 10)

  08-c.jpg (Dosya Boyutu: 69.96 KB / İndirme Sayısı: 9)

ConnectWise Cloud Backup OAuth Uygulaması Ele Geçirildi: 173 Microsoft 365 Kiracısı

Sat, 17 Oct 2026 16:14:31 +0300

Selamlar,

Bu sabah düşen haber, özellikle MSP (yönetilen hizmet sağlayıcı) ile çalışan ya da Microsoft 365 tenant'ı yöneten herkesi ilgilendiriyor. Saldırganlar, ConnectWise Cloud Backup (eski adıyla SkyKick) uygulamasına ait bir kimlik bilgisini ele geçirip bu uygulamanın kurulu olduğu müşteri tenant'larına giriş yaptı. Huntress'in açıklamasına göre doğrulanmış yetkisiz giriş sayısı 173 tenant.

Bu olay, "kullanıcı parolası çalındı" türünden bir olay değil. Burada çalınan şey bir uygulama kimliği. Ve bu fark, savunma tarafında yapılacak her şeyi değiştiriyor.

Ne oldu?

ConnectWise Cloud Backup, MSP'lerin müşteri M365 verilerini yedeklemesi için kullanılan bir servis. Görevini yapabilmek için posta kutularına, OneDrive, SharePoint, Teams ve dizin verilerine geniş izinle erişiyor.
Huntress'e göre saldırgan, 15 Ekim 2026'da 06:13-08:34 UTC arasında (Türkiye saatiyle 09:13-11:34) 144.172.64[.]128 adresinden müşteri tenant'larında Microsoft Graph token'ı aldı.
Saldırgan tenant'ları GUID sırasına göre, birkaç saniye arayla dolaştı. Araştırmacılar bunun bir hedef listesiyle çalışan bir script olduğunu düşünüyor.
Aynı IP'nin 13-14 Ekim'de dört hukuk bürosu tenant'ına parola püskürtme (password spraying) denediği, ancak başarılı kullanıcı girişi görülmediği belirtildi.
En az bir tenant'ta ConnectWise'ın Teams için olan başka bir uygulamasının kendini Global Administrator rolüne eklediği ve iki başka güvenilir uygulamaya yeni client secret eklediği gözlendi.

ConnectWise, Cloud Backup uygulama erişimini ikinci bir duyuruya kadar kapattığını ve yedek verilerin ele geçirildiğine dair kanıt bulmadığını açıkladı. Microsoft da olayı "aktif tedarik zinciri saldırısı" olarak nitelendirdi.

Neden kullanıcı oturumlarını kapatmak yetmiyor?
Todyl'in tespit mühendisliği ekibinin vurguladığı nokta çok önemli: kullanıcı oturumlarını iptal etmek bu erişimi sonlandırmıyor. Çünkü saldırgan bir kullanıcı olarak değil, servis sorumlusu (service principal) olarak giriş yapıyor. Uygulamayı tenant'ta devre dışı bırakmak yeni token alınmasını engelliyor, ancak önceden verilmiş token'lar 90 dakikaya kadar geçerli kalabiliyor.

Hemen yapılacaklar (kontrol listesi)

Entra yönetim merkezinde Monitoring > Sign-in logs > Service principal sign-ins sekmesine gidin. Varsayılan "User sign-ins" sekmesi bu kayıtları göstermez.
Application ID 506e08f9-6e9a-4da4-942b-a099a03644ae ile filtreleyin.
IP sütununda Microsoft/Azure dışından gelen girişlere, özellikle 144.172.64[.]128 adresine bakın.
ConnectWise kimlik bilgilerini yenilediğini teyit edene kadar uygulamayı devre dışı bırakın.
13 Ekim 2026'dan bu yana herhangi bir uygulamaya eklenen yeni secret/sertifikaları denetleyin.
Audit loglarında ConnectWise veya SkyKick uygulamalarının kendilerini bir dizin rolüne eklemesini arayın.
Microsoft Graph activity log'larını etkinleştirin (açık değilse bundan sonraki olaylar için).

PowerShell ile servis sorumlusunu hızlıca bulmak için (Microsoft Graph PowerShell modülü):

Kod:
Connect-MgGraph -Scopes "Application.Read.All","AuditLog.Read.All"
Get-MgServicePrincipal -Filter "appId eq '506e08f9-6e9a-4da4-942b-a099a03644ae'" |
  Select-Object DisplayName, Id, AccountEnabled

# Uygulamaya eklenmis kimlik bilgilerini listelemek icin
Get-MgServicePrincipal -All | ForEach-Object {
  [pscustomobject]@{ Ad=$_.DisplayName; Secret=$_.PasswordCredentials.Count; Sertifika=$_.KeyCredentials.Count }
} | Where-Object { $_.Secret -gt 0 } | Sort-Object Ad

Çıkarılacak ders: Uygulama izinleri de bir saldırı yüzeyidir
Çoğu kurumda "Enterprise Applications" listesine son ne zaman bakıldığını kimse hatırlamaz. Bir kez onay verilmiş bir uygulama, yıllarca Directory.ReadWrite.All gibi çok güçlü izinlerle oturur. Bu olay bize şunu söylüyor:

Her üçüncü taraf uygulama için bir sahip belirleyin.
Gerçekten gerekmeyen yüksek izinleri kaldırın.
Servis sorumlusu girişlerini SIEM'e alın ve bilinmeyen IP'lerden gelenlere alarm kurun.
Kullanıcıların uygulamalara kendi başına onay vermesini (user consent) kısıtlayın.

Hikaye hâlâ gelişiyor; yeni bilgi geldikçe bu konuyu güncelleyeceğim.

Kaynaklar

The Hacker News - "Hackers Use Compromised ConnectWise Credential to Sign In to 173 Microsoft 365 Tenants" (17 Ekim 2026)
Huntress, Todyl ve Microsoft açıklamaları (haber içinde aktarıldığı şekliyle)
ConnectWise güvenlik duyurusu

002-connectwise.png (Dosya Boyutu: 81.45 KB / İndirme Sayısı: 8)

AWS Güvenlik Temelleri: S3 ve IAM Yanlış Yapılandırmalarından Korunma

Sat, 17 Oct 2026 11:30:29 +0300

Son yılların büyük veri sızıntılarının önemli bir kısmı sofistike bir sıfırıncı günden değil, basit bir bulut yanlış yapılandırmasından çıktı. "Açık S3 bucket" artık neredeyse bir klişe. Bu rehberde AWS'de en sık karşılaşılan iki hata alanını, S3 ve IAM'i, savunma gözüyle ele alıyorum. Amaç saldırmak değil, kendi hesabınızı güvenli kurmak.

Konuda anlatılacaklar

Bulutta paylaşımlı sorumluluk modeli
S3 neden sızıyor?
S3 sertleştirme adımları
IAM: en az yetke ilkesi
Tehlikeli IAM desenleri
Tespit ve izleme
Yasal uyarı

Paylaşımlı Sorumluluk Modeli

AWS güvenliğinin temeli bu kavramı anlamaktan geçer: AWS bulutun kendisinin güvenliğinden (donanım, veri merkezi, altyapı) sorumludur; siz ise buluttaki her şeyin güvenliğinden (verileriniz, erişim politikaları, yapılandırma) sorumlusunuz. Açık kalan bir bucket AWS'nin değil, sizin hatanızdır.

S3 Neden Sızıyor?

S3 (Simple Storage Service), dosya depolama hizmetidir. Sızıntıların tipik sebepleri:

Bucket veya nesnelerin yanlışlıkla herkese açık (public) yapılması.
Aşırı geniş bucket politikaları (Principal "*").
"Herkes okuyabilsin ama yazamaz" sanılan ama aslında listeleme/indirmeye açık ayarlar.
Yedeklerin/logların ayrı ve korumasız bir bucket'ta tutulması.

S3 Sertleştirme Adımları

Block Public Access özelliğini hesap ve bucket seviyesinde açık tutun (varsayılan böyledir, kapatmayın).
Gerçekten herkese açık olması gereken içerik dışında hiçbir bucket'ı public yapmayın; statik web sitesi gibi durumlar için bile CloudFront + OAC tercih edin.
Varsayılan şifrelemeyi (SSE-S3 veya SSE-KMS) etkinleştirin.
Erişim için bucket politikası yerine mümkünse IAM rolleri ve en dar kapsamı kullanın.
Nesne sürümleme ve silme koruması ile fidye/kaza senaryolarına karşı dayanıklılık ekleyin.

Hızlı kontrol fikri (yetkiliyseniz kendi hesabınızda):

Kod:
aws s3api get-public-access-block --bucket BUCKET_ADI
aws s3api get-bucket-policy --bucket BUCKET_ADI

IAM: En Az Yetki İlkesi

IAM (Identity and Access Management), kimin neye erişebileceğini yönetir. Altın kural: en az yetki (least privilege). Her kimliğe yalnızca işini yapması için gereken izinleri verin.

Kök (root) hesabı günlük işler için kullanmayın; MFA ile kilitleyip kenara kaldırın.
İnsanlar için mümkünse uzun ömürlü erişim anahtarları yerine geçici kimlik (SSO/rol) kullanın.
Uygulamalara anahtar gömmek yerine IAM rolleri atayın (EC2 instance profile gibi).

Tehlikeli IAM Desenleri

Politikalarda şu kalıplardan kaçının:

Kod:
{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

"Her şeye izin" demek olan bu kalıp, tek bir kimliğin sızması halinde tüm hesabı tehlikeye atar. Ayrıca:

iamassRole ile aşırı geniş rol geçişi, yetki yükseltmeye yol açar.
"Principal": "*" içeren kaynak politikaları (S3, KMS) dikkatle incelenmeli.
Kullanılmayan eski erişim anahtarları düzenli olarak devre dışı bırakılmalı.

Tespit ve İzleme

CloudTrail'i tüm bölgelerde açın; kim ne yaptı kaydı budur.
AWS Config ile yanlış yapılandırmaları (public bucket, şifresiz volume) otomatik yakalayın.
GuardDuty ile anormal API çağrılarını ve bilinen kötü IP'leri izleyin.
IAM Access Analyzer ile hesap dışına açılan kaynakları tespit edin.

Sonuç

Bulut güvenliğinde haberlere düşen çoğu olayın kökeni basit bir ayar hatası. S3'te Block Public Access'i koruyun, IAM'de en az yetki ilkesini uygulayın, CloudTrail/Config/GuardDuty üçlüsünü açın; bu temel adımlar riskin büyük kısmını kapatır. Siz bulut tarafında hangi otomatik kontrolü olmazsa olmaz görüyorsunuz, yorumlarda konuşalım.

Yasal Uyarı

Bu rehberdeki komut ve kontroller yalnızca kendi AWS hesabınızda veya yetkilendirildiğiniz ortamlarda çalıştırılmalıdır. Başkasının bulut kaynaklarını izinsiz taramak/erişmek TCK 243-245 kapsamında suçtur.

Görsel: TurkTeam özgün kapak görseli

tonyukuk-18-aws.jpg (Dosya Boyutu: 79.97 KB / İndirme Sayısı: 12)