Devralınan Bir Bulut Ortamını Mirasa Aldınız. Nereden Başlarsınız?

Biraz önce birisi tarafından üç yıl boyunca hiç dokümantasyon olmadan, rotasyonda değişen müteahhitlerle ve 2022'den beri aktif olmayan #aws-help adlı bir Slack kanalıyla inşa edilen bir bulut hesabına (veya ona on tanesine) sahip oldunuz. Bu, bulut güvenliği işinde en yaygın durumlardan biridir ve rahatsız edicidir çünkü henüz açıklayamadığınız bir şeyden siz sorumlusunuz.

Sıfır görünürlükten savunulabilir bir konuma işi aşırıya çıkarmadan nasıl geçeceğiniz aşağıda açıklanmıştır.

Tahminde bulunmayı bırakın ve önce bir envanter alın

Göremediğiniz şeyi güvenli hale getiremezsiniz. Tek bir IAM politikasına dokunmadan önce bir envanter taraması yapın:

• AWS: tam hesap yapısını görmek için aws organizations list-accounts kullanın, ardından Steampipe veya AWS Config toplayıcılarını kullanarak hesaplar arasında kaynakları bir sorgulanabilir görünüme çekin.
• Azure: Resource Graph sorguları (az graph query) abonelikler arasında, çünkü Azure'un kiracı/abonelik modeli genişlemeyi kolayca gizleyebilir.
• GCP: gcloud asset search-all-resources kuruluş düzeyinde kullanın.

Bunu faturalandırma verileriyle çapraz referans alın. Faturalandırma, etiketler ve dokümantasyon yalan söylese bile, ne çalıştığı hakkında yalan söylemez. Yerleştirmede hiç kimse tarafından belirtilmeyen bir hizmet üzerinde harcama görürseniz, bu sizin ilk bulgusu.

Neyin kırık olduğunu bulmadan önce kimin ne yapabileceğini bulun

Yanlış konfigürasyonlar manşetleri alır, ancak devralınan bir ortamda gerçek maruz kalma genellikle kimliktedir. Her IAM kullanıcısını, rolünü ve hizmet hesabını çekin ve üç soru sorun: bunu hala var olması gerekir mi, kullanmadığı erişime sahip mi, insan mı yoksa makine mi.

AWS IAM Access Analyzer'ı veya iam-lint tarzı araçlamayı çalıştırarak son 90 gündeki kullanılmayan izinleri işaretleyin. Uygulamada, devralınan hesaplar neredeyse her zaman olması gereken uzun ömürlü erişim anahtarlarına sahip en az bir IAM kullanıcısına sahip