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/NAMEPolicy 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/*İ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.