İtiraf edeyim, Bakın şimdi, bulutta güvenlik konuşurken çoğu kişi ilk olarak firewall, WAF, IAM ya da şifreleme tarafına bakıyor. Haklılar da. Ama işin aslı şu ki, en sinsi risk bazen tam ortadaki “güvenilir” parçalardan geliyor. Geçenlerde okuduğum iki olay bunu baya net gösterdi: biri AWS CodeBuild tarafında gizli uç noktalarla privilege escalation meselesi, diğeri ise GDDR6 üzerinde Rowhammer tekniğiyle root shell alınabilmesi. İkisi de kulağa farklı dünyalardan geliyormuş gibi duruyor. Aslında aynı derse çıkıyor: güven zinciri kırılırsa, gerisi domino taşı gibi gidiyor.
Ben 20+ yıllık BT hayatımda çok şey gördüm; hosting odalarında disk arızası da gördüm, kurumsal Azure geçişlerinde yanlış yapılandırılmış kimlik yetkileri de. 2018’de bir finans müşterisinde CI/CD hattını gözden geçirirken fark etmiştik mesela: geliştirici ekibi kendi işini kolaylaştırmak için build servis hesabına gereğinden fazla yetki vermişti. O zaman “idare eder” gibi görünen bu detay, gerçek hayatta çok pahalıya patlayabilirdi. İşte bu yüzden bu tür haberleri sadece “oh be yine açık çıktı” diye okumuyorum; direkt mimari ders olarak okuyorum.
Evet, doğru duydunuz.
Tedarik zincirinde en zayıf halka çoğu zaman dışarıdan görünmez. Bazen bir scanner, bazen bir build servisi, bazen de donanımın kendisi sorun çıkarır.
Güvenilir Araçlar Neden Hedef Oluyor?
Doğrusu, Trivy gibi araçlar normalde savunma tarafının yıldızlarıdır. Container imajı tararsın, Kubernetes manifestini kontrol edersin, açık var mı bakarsın… Ama saldırgan açısından bakınca bu araçların değeri bambaşka. Çünkü bunlar üretim hattına yakın durur, repo erişimi görür, pipeline içinde çalışır ve çoğu zaman yüksek güven kazanır. Yani tam tabiriyle “kapıyı tutan adam” olurlar.
Size bir şey söyleyeyim, Bir dakika, şunu da ekleyeyim: burada mesele sadece yazılım açığı değil. Asıl mesele güven ilişkisi. Bir ürünün popüler olması onu otomatik olarak güvenli yapmıyor. Ben Logosoft’ta bir kamu projesinde buna benzer bir tartışma yaşamıştım; ekip herkesin kullandığı bir güvenlik aracını körü körüne standart kabul ediyordu. AZ-500 sınavına hazırlanırken de aynı şeyi tekrar tekrar görüyorsun zaten: kimlik doğrulama ve yetkilendirme düzgün değilse geri kalan katmanlar makyaj kalıyor.
Küçük bir startup için bu konu biraz farklı ilerliyor. Ekip az olur, herkes her şeye bakar ve hız baskısı yüksektir. Enterprise seviyede ise iş büyür; araç sayısı artar, entegrasyon çoğalır, denetim zorlaşır. Ha bu arada en tehlikeli kombinasyon da şu oluyor: küçük ekiplerin hız alışkanlığı ile büyük kurumların karmaşıklığı birleşince ortaya karmakarışık bir saldırı yüzeyi çıkıyor.
Tedarik zinciri saldırısının çekici yani
Saldırgan doğrudan hedefe girmek yerine araya giriyor. Bu daha sessiz, daha ucuz ve bazen daha iş gören oluyor.
Bir şey dikkatimi çekti: Geçen sene Berlin’de görüştüğüm bir müşteri bunu çok iyi anlatmıştı: “Biz ana uygulamayı koruyoruz ama onu yapan pipeline’ı kim koruyacak?” İşte doğru soru buydu (buna dikkat edin)
AWS CodeBuild Tarafında İşler Nasıl Karışıyor?
AWS CodeBuild ve CodeConnections etrafındaki araştırmalar bana hep aynı hissi veriyor: bulut servisleri ne kadar yönetilen olursa olsun, yanlış varsayım varsa açık kapı kalıyor. Undocumented endpoint meselesi özellikle can sıkıcı; çünkü dokümantasyonda görünmeyen şeyler genelde denetim ekiplerinin radarına da geç gecikir. Saldırgan böyle bir yüzey buldu mu önce token peşine düşer, sonra build ortamına sızar, sonra lateral movement başlar… klasik ama hala işe yarayan bir yol.
Bilmem anlatabiliyor muyum, Ben 2021’de İstanbul’da bir e-ticaret firmasında benzer mantıkta bir risk incelemesi yapmıştım. Orada problem AWS değildi; başka bir CI aracında servis hesabı token’ları gereksiz uzun süre saklanıyordu. Sonuç? Bir pipeline ele geçirilse bütün çevreye yayılabilecek yetkiler vardı. Kağıt üstünde süper görünüyordu ama pratikte biraz hamdı; hani üstüne güzel kaplama çekilmiş ama içi boş kutu gibi.
Hmm, bunu nasıl anlatsamdı…
| Alan | Risk | Ne yapmalı? |
|---|---|---|
| CodeBuild job kimliği | Aşırı yetki | Least privilege uygula |
| Token yönetimi | Sızma / yeniden kullanım | Kısa ömürlü secret kullan |
| Lateral movement | Büyük alan yayılımı | Ağ ve IAM segmentasyonu kur |
| Gizli endpointler | Denetim dışı yüzey | Düzenli keşif ve log analizi yap |
Neden CI/CD hattı bu kadar hassas?
Yani, Çünkü pipeline aslında üretim anahtarlarının geçtiği mutfak gibi çalışıyor. Mutfakta biri tuzu fazla kaçırırsa yemek bozulur; burada biri token çalarsa bütün sistem bozulabilir.
Bak şimdi, Açık konuşayım, birçok kurum hala build sunucusunu “sadece teknik detay” sanıyor (ben de ilk duyduğumda şaşırmıştım). Değil işte… Orası artık kritik varlık.
GDDR6 Rowhammer ile Root Shell Meselesi Neyi Gösteriyor?
Daha açık söyleyeyim, bilmem anlatabiliyor muyum, Dürüst olayım, donanım tarafındaki bazı zero-day’ler insanı afallatıyor! Yazılım yamalarıyla çözülebilecek sandığın şeyin altında fiziksel seviyede ciddi kusurlar çıkabiliyor. GDDR6 üzerinde Rowhammer ile root shell elde edilmesi fikri ilk duyduğumda aklımdan şu geçti: “Tamam da bu artık sadece GPU sürücüsü konusu değil.” Evet aynen öyle değilmiş meğer; bellek davranışıyla oynayınca iş kernel seviyesine kadar uzayabiliyor.
Bunu geçen yıl Ankara’da yaptığımız bir güvenlik atölyesinde de tartışmıştık. Bir katılımcı “Cloud’da oturuyoruz ya bize — itiraz edebilirsiniz tabi — donanım saldırısı olmaz” demişti… halbuki altyapının altında çalışan fiziksel dünya hala orada duruyor. Hypervisor var diye atomlar yok olmuyor sonuçta (yanlış duymadınız)
Garip gelecek ama, Kritik nokta şu: Bulut soyutlaması seni rahatlatmasın. Uyutmasın da! Bilhassa GPU kiralama yapan platformlarda veya yüksek performanslı hesaplama ortamlarında donanım yan kanalları ciddiye alınmalı.
Burası neden enterprise için daha önemli?
Büyük organizasyonlarda GPU kaynakları sadece render için kullanılmıyor artık; AI/ML eğitiminden veri analitiğine kadar her yerde varlar.
Bir yerde açık varsa etki alanı geniş olur. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
Küçük ekipler genelde “bizde GPU yok” diyerek rahatlıyor ama cloud’da kiraladığın managed hizmet bile seni büyük ölçüde korumaz.
Savunmada Ne Yapılır? Lafı Gevelemeden Anlatayım
Neyse uzatmayalım… burada yapılacak işler belli ama disiplin istiyor.
İlk adım görünürlüğü artırmak olmalı; ikinci adım yetkiyi kısmak; üçüncü adım ise sürekli test etmek.
Güvenlik araçlarını bile güvenlik kontrolünden geçirmek gerekiyor ki bu kısım çoğu yerde atlanıyor.
Kısacası sistemin içine girip ne olduğunu gerçekten görmek lazım.
# Basit kontrol mantığı
if tool_is_security_related:
verify_signature()
pin_version()
review_permissions()
else:
continue_monitoring()- Tedarik zinciri araçlarını sabit sürümle kullanın. — bunu es geçmeyin
- Paket imzalarını ve provenance bilgisini doğrulayın.
- CI/CD servis hesaplarına gereksiz rol vermeyin.
- Sırlarınızı kısa ömürlü tutun; uzun yaşayan secret sevimsizdir.
- Düzenli log korelasyonu yapın ve olağan dışı endpoint çağrılarını izleyin.
Ben AZ-104 ve AZ-305 çalışmalarında da hep aynı prensibi savundum:
tasarım aşamasında kısıt koymazsan operasyon aşamasında ağlarsın.
Mesela network segmentation güzel konuşulur ama uygulanmadığında tek düzlemde koşan sistem ortaya çıkar — sonra biri içeri girerse durdurmak zorlaşır.
Baya can sıkıcı olur yani.
Bunun örneğini defalarca gördüm açıkçası.
“Bir de şu var:
supply chain security yalnızca DevOps ekibinin işi değil.
Satın alma ekibi bile etkilenir çünkü kullandığınız üçüncü parti ürünlerin yaşam döngüsü sizin risk profilinizi belirler.
2019’da Hollanda’daki bir müşteride bunu yaşayarak öğrenmiştik;
lisanslı güvenlik ürünü güncelleme kanalından problem taşımıştı ve olay haftalarca analiz edilmişti…
İnsan bazen sorunun tam nereden geldiğini anlamak için epey uğraşıyor.”
Hmm, bunu nasıl anlatsamdı…
Kurumlar İçin Pratik Yol Haritası
Eğer küçük bir startup iseniz önce temel hijyeni kurun:
secret management düzgün olsun,
branch protection açık olsun,
build agent’lar ephemeralsa iyi olur (kalıcı makineler biraz nazlıdır). Enterprise tarafta ise bunun üstüne governance binmeli;
policy as code yaklaşımı şart hale geliyor çünkü manuel kontrol ölçeklenmiyor. Şey yani,
her şeyi elle takip etmeye kalkınca iş çabuk dağılıyor. Aslında — dur bir saniye,
önce şunu söyleyeyim — politika tek başına çözüm değil ama politikası olmayan yapı da kumdan kale gibi dağılıyor. Bir bankacılık projesinde Azure DevOps dönüşümü yaparken bunu çok net gördük;
repo erişimleri iyileşince incident sayısı bariz düştü ama asıl fark audit sırasında çıktı…
Kısaca neye bakmalı?
– Kim hangi secret’a erişiyor?
– Build job hangi role sahip?
– Üçüncü parti araç nereden güncelleniyor?
– Loglarda anormal token kullanımı var mı?
– Donanım seviyesinde izolasyon yeterli mi?
Sıkça Sorulan Sorular
Tedarik zinciri saldırısı tam olarak nedir?
Tedarik zinciri saldırısı, doğrudan hedef sistemi değil aradaki güvenilen yazılım veya hizmeti hedefler. Böylece saldırgan dolaylı yoldan daha geniş erişim elde edebilir.
AWS CodeBuild neden riskli olabilir?
Eğer build ortamındaki roller veya token yönetimi gevşekse saldırgan bunları kötüye kullanabilir. En çok da de undocumented endpoint’ler veya fazla yetkili servis hesapları riski büyütür.
Rowhammer saldırısı bulutta gerçekten önemli mi?
Evet, çünkü bulut soyutlama sağlasa da altta fiziksel donanım çalışmaya devam eder. Bellek yan etkileri bazı senaryolarda ciddi sonuçlara yol açabilir.
Kurumlar ilk hangi önlemleri almalı?
Önce least privilege uygulanmalı ve secret yönetimi toparlanmalı. Sonra CI/CD hattının loglama ve izleme tarafı güçlendirilmelidir.
Kaynaklar ve İleri Okuma
Azure Identity Management Best Practices
AWS CodeBuild Resmi Dokümantasyonu
CISA Supply Chain Risk Management Rehberi
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
