Herkese açık S3, Azure Blob ve GCS depolarını bir öğleden sonra bulun

Üç büyük sağlayıcının her birinde, tek tek bucket'ların üzerinde yer alan ve altta yapılan her yapılandırmayı geçersiz kılan bir anahtar bulunur. Öğleden sonranızın iki işi var: önce hâlihazırda açık olanları bulmak, sonra da bu anahtarları açarak bir sonraki özensiz politikanın hiçbir etki yaratmamasını sağlamak. Bu sırayı koruyun, çünkü anahtarlar herkese açık olmaya dayanan her şeyi bozacaktır.

"Herkese açık" her platformda ne anlama gelir

Tanımlar platformlara göre farklılaşır ve denetimin her birini ayrı ayrı aramesi gerekir.

S3, bir bucket policy'yi aksi kanıtlanana kadar herkese açık sayar. Bir policy ancak joker karakter ya da policy değişkeni içermeyen sabit değerlere erişim veriyorsa herkese açık olmayan sayılır. Belirli bir principal veya aws:SourceIp üzerinden bir CIDR bloğu kümesi buna örnektir. Joker karakterli bir principal bu testi bu nedenle geçemez.

Azure'da iki koşulun da sağlanması gerekir. Hesap anonim erişime izin vermiyorsa container ayarının önemi kalmaz. Hesap izin veriyorsa, biri düzeyi Container veya Blob olarak ayarlayana kadar container yine de özel kalır.

Adım 1: Açık olanı bulun

S3. AWS kılavuzu, herkese açık bucket'ları incelemek için IAM Access Analyzer for S3'ü işaret ediyor, bu yüzden oradan başlayın. Ardından her hesapta dört Block Public Access ayarını kontrol edin: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy ve RestrictPublicBuckets. GetBucketAcl çağrısının etkin izinleri döndürdüğünü unutmayın. Herkese açık bir ACL'ye sahip olup IgnorePublicAcls etkin olan bir bucket, gerçek ACL'yi gizleyen bir ACL gösterir.

Azure. Portal size önce anonim isteklerin sayısını verir. Depolama hesabında Monitoring, ardından Metrics bölümünü açın. Blob namespace'ini, Transactions metriğini ve Sum toplama yöntemini kullanın, ardından Authentication değeri Anonymous olan bir filtre ekleyin.

Hangi container'ların söz konusu olduğunu görmek için logları bir Log Analytics workspace'e gönderen bir diagnostic setting oluşturun. Ardından son yedi günü kapsayan şu sorguyu çalıştırın:

StorageBlobLogs
| where TimeGenerated > ago(7d) and AuthenticationType == "Anonymous"
| project TimeGenerated, AccountName, AuthenticationType, Uri

Uri sütunu, okunan container ve blob'ları gösterir. Metrikler ve loglar yalnızca anonim olarak kimin okuduğunu gösterir, nelerin açıkta olduğunu göstermez. Bu yüzden kimsenin istek yapmadığı açık bir container görünmez kalır. Container erişim düzeylerini de ayrıca kontrol edin.

Google Cloud. Bucket IAM policy'lerinde allUsers veya allAuthenticatedUsers kimliklerine verilmiş rolleri inceleyin. Cloud Asset Inventory, bir proje, klasör veya organizasyondaki tüm bucket'ların policy'lerini gösterir ve sizi tek tek bucket gezmekten kurtarır. Nesne ACL'leri için ayrıca bakmanız gerekir, managed folder'ların da kendi IAM policy'leri vardır. Hangi iş yüklerinin herkese açık verilere eriştiğini görmek için usage logs özelliğini açın. Cloud Audit Logs herkese açık nesnelere erişimi izlemez, bu yüzden burada işe yaramaz.

Adım 2: Guardrail'leri devreye alın

S3. AWS, dört ayarın tamamının hesap düzeyinde etkinleştirilmesini önerir. Security Hub kontrolü S3.8'i karşılamak için dördünün her bucket üzerinde de etkinleştirilmesini önerir. Birden fazla hesap için organizasyon düzeyinde bir policy kullanın. Bu policy ya hep ya hiç mantığıyla çalışır, ayar bazında seçim sunmaz ve seçilen üye hesaplardaki hesap düzeyi ayarları geçersiz kılar. S3, düzeyler arasında en kısıtlayıcı kombinasyonu uygular, dolayısıyla bir bucket hesabın zorunlu kıldığı korumayı zayıflatamaz.

Özellikle BlockPublicPolicy ayarını hesap düzeyinde uygulayın. Aksi halde bir bucket policy'yi düzenleyebilen herkes, bucket düzeyindeki ayarı devre dışı bırakan bir policy ekleyebilir. Hesap düzeyindeki değişiklikler tüm Region'lara uygulanır ancak her yerde aynı anda yansımayabilir. Access point ayarları yalnızca oluşturma sırasında yapılabilir, bu nedenle onları ayrıca kontrol edin.

Azure. Her depolama hesabında AllowBlobPublicAccess değerini False yapın. Bu, her container ayarını geçersiz kılar, dolayısıyla container'lara dokunmanız gerekmez. Azure Storage resource provider'ın 2019-04-01 veya daha yeni bir sürümünü gerektirir. Kullanıcının Microsoft.Storage/storageAccounts/write iznine sahip olması gerekir. Owner, Contributor ve Storage Account Contributor rolleri bu izni taşır. Bu rol atamalarını dar tutun.

Google Cloud. Bucket'larda public access prevention'ı zorunlu kılın ya da storage.publicAccessPrevention organizasyon policy constraint'ini proje, klasör veya organizasyon düzeyinde ayarlayın. Google, mümkün olan en üst düzeyde zorunlu kılmayı önerir. Bir bucket'ın durumu ya enforced ya da inherited'dır. Ayarı enforced olan bir bucket, üstündeki constraint'i sonradan devre dışı bırakmış olsanız bile enforced kalır.

Nelerin bozulacağı ve nelerin bozulmayacağı

Bozulmaya hazırlıklı olun, çünkü bu çalışmanın amacı tam olarak budur.

• S3: Ayarlar mevcut policy'leri veya ACL'leri değiştirmez. Bir ayarı kaldırmak, herkese açık policy ya da ACL'si olan her şeyi yeniden herkese açık hale getirir, bu yüzden alttaki yetkilendirmeleri de temizleyin. Ayrıca identity-based policy'leri ve Block Public Access'in kapsamadığı KMS key policy'leri gibi resource policy'leri de gözden geçirin.
• Azure: Anonim okuma istekleri başarısız olmaya başlar. Dönen kod servis sürümüne bağlıdır: 2019-12-12 ve üzeri sürümlerde 401, daha eski sürümlerde hesap anonim erişime izin vermiyorsa 409, izin veriyorsa 404.
• Google Cloud: allUsers kullanan istekler HTTP 401 veya 403 ile başarısız olur. Mevcut binding'ler yerinde kalır ancak geçersiz kılınır. Yeni binding eklemeye çalışmak 412 Precondition Failed hatasıyla sonuçlanır. Signed URL'ler etkilenmez. Uygulamanın devreye girmesi 10 dakikayı bulabilir ve önbelleğe alınmış nesneler, varsayılan değeri 3600 saniye olan Cache-Control süresi boyunca herkese açık kalabilir.

Statik bir web sitesi gibi gerçekten herkese açık olması gereken içerikler için istisna gerekir. Azure, bu içeriği anonim erişime ayrılmış ayrı bir depolama hesabına taşımanızı önerir. Google Cloud'da bucket'ı barındıran projede prevention'ı devre dışı bırakın. S3'te ise ihtiyacı olan bucket'lar için ayarları tek tek özelleştirin.

Nereden başlamalı

1. Depolama barındıran tüm AWS hesaplarını, Azure aboneliklerini ve Google Cloud projelerini listeleyin. Kimsenin oluşturduğunu hatırlamadığı olanlar da dahil.
2. Yukarıdaki keşfi çalıştırın: S3 için Access Analyzer, Azure anonim istek metriği ve log sorgusu, bucket IAM policy'leri için Cloud Asset Inventory.
3. Herkese açık her bulgu için bunun bilinçli olup olmadığına karar verin. Meşru herkese açık içerikleri ayrılmış hesaplara veya projelere taşıyın.
4. Hesap veya organizasyon düzeyindeki kontrolleri etkinleştirin: S3'ün dört ayarının tamamı, AllowBlobPublicAccess değerinin False yapılması ve storage.publicAccessPrevention constraint'i.
5. Birkaç gün sonra sorguları yeniden çalıştırarak anonim isteklerin sıfıra düştüğünü doğrulayın ve Azure anonim istek metriği için bir alarm tanımlayın.
6. Geriye kalanların dışarıdan erişilebilir olup olmadığını bağımsız olarak kontrol ettirmek isterseniz, penetrasyon testi hizmetimiz bulut maruziyetini kapsar ve danışmanlık ekibimiz hesap yapınızı gözden geçirebilir.