Giriş
Bir IAM kullanıcısı için üretilen uzun vadeli erişim anahtarı (AKIA*), oluşturulduğu andan itibaren siz onu silinceye veya devre dışı bırakıncaya kadar yaşar. Kulağa masum geliyor olabilir, ancak bu anahtar yanlışlıkla bir Git reposuna itildiğinde, bir yapılandırma dosyasına gömüldüğünde ya da bir log çıktısında göründüğünde, hesabınıza süresiz bir "anahtar" teslim etmiş olursunuz.
IBM'in 2024 Veri Sızıntısı Maliyeti Raporu'na göre, küresel ortalama veri ihlali maliyeti 4,88 milyon dolar ile rekor kırdı ve çalınan veya sızdırılmış kimlik bilgileri en yaygın ilk saldırı vektörü olmaya devam etti (tüm ihlallerin %15'i) (
IBM, 2024). AWS Security Token Service (STS) ise tam da bu noktada devreye girerek, kalıcı anahtarları yalnızca başlangıç noktası haline getirmenizi ve asıl işleri kısa ömürlü, denetlenebilir oturumlarla yapmanızı sağlar. Bu yazıda, bir IAM kullanıcısından başlayıp AssumeRole ile geçici rol kimlik bilgilerine nasıl geçildiğini, bu mimarinin saldırı yüzeyini nasıl daralttığını ve savunma tarafında hangi pratik adımları atmanız gerektiğini ele alacağız.
- Uzun vadeli
AKIAanahtarları süresizdir ve sızdığında hesabın tamamen ele geçirilmesine yol açabilir (GitGuardian, 2024). - AWS STS ile alınan
ASIAanahtarları, oturum belirteci (SessionToken) ile birlikte kullanılır ve en fazla 12 saat geçerlidir. - Rol geçişi (
AssumeRole), en az yetki ilkesini uygulamanın, denetim izlerini netleştirmenin ve anahtar yönetimini merkezileştirmenin temelidir.
Uzun vadeli anahtarlar neden bu kadar tehlikeli?
Bir IAM kullanıcısına ait uzun vadeli erişim anahtarı (AKIA...), kullanıcıya tanımlanan yetkileri sonsuza kadar taşır. Oysa GitGuardian'ın 2024 yılında yayımladığı "State of Secrets Sprawl" raporuna göre, 2023 yılında kamuya açık GitHub repolarında 12,8 milyon yeni secret tespit edildi (%28 artış) ve bunların içinde 140.000'den fazla AWS erişim anahtarı bulunuyordu (
GitGuardian, 2024). Bu anahtar herhangi bir süre sınırı olmadığı için, saldırgan onu ele geçirdiği anda o kullanıcının tüm yetkilerini kullanmaya başlayabilir.
Daha da vahimi, geliştirme ortamında test amacıyla üretilen bir anahtarın, üretim ortamındaki S3 bucket'larını okumak veya DynamoDB tablolarını listelemek gibi hiç beklenmedik yetkilere sahip olmasıdır. Bulut güvenliğinde "zaman" en kritik savunma katmanlarından biridir. Süresiz anahtarlar bu katmanı tamamen ortadan kaldırır.
Atıf Kapsülü: GitGuardian'ın 2024 raporuna göre 2023'te GitHub'da 12,8 milyon yeni kimlik bilgisi sızıntısı tespit edildi ve bunların içinde 140.000'den fazla AWS uzun vadeli anahtarı bulunuyor (GitGuardian, 2024). Sızan bir AKIA anahtarı, kullanıcıyla aynı yetkilere süresiz erişim sağladığı için, bulut hesaplarında kalıcı bir arka kapıya dönüşür.
AWS STS ve AssumeRole: Geçici kimliğe nasıl geçilir?
AWS STS (Security Token Service), geçici ve sınırlı süreli güvenlik bilgileri talep etmenizi sağlayan bir web servisidir. En yaygın kullanımı, güvenilir bir varlığın (örneğin bir IAM kullanıcısının) bir IAM rolünü assume-role çağrısıyla üstlenmesidir.
Süreç tipik olarak şöyle işler:
stajyeradlı IAM kullanıcısı,stajyerlergrubunun bir üyesidir.stajyerlergrubuna,uzmanrolünü üstlenme izni veren bir politika tanımlanmıştır.- Kullanıcı, uzun vadeli
AKIAanahtarını kullanarak STS'ye "bu rolü benim için üstlen" talebinde bulunur. - STS, rolün güven ilişkisini (
trust policy) denetler; izin varsa geçici erişim anahtarı (ASIA...), gizli anahtar ve bir oturum belirteci (SessionToken) döner.
Pek çok bulut güvenlik eğitimi, STS'i yalnızca "yardımcı bir servis" gibi tanıtır. Oysa STS, modern bulut güvenlik mimarisinin bel kemiğidir; zira her API isteğinin kısa ömürlü bir kimlikle yapılmasını zorunlu kılarak, saldırı yüzeyini geçici ve daraltılabilir hale getirir.
Yapılan pek çok bulut güvenlik denetimi, üretim ortamında kullanılmayan ancak AssumeRole izni açık bırakılmış IAM kullanıcılarının ciddi bir risk oluşturduğunu gösteriyor. Geçici ihtiyaçlar için oluşturulup unutulan bu kullanıcılar, saldırganlar için kritik birer "arka kapı" haline gelebiliyor.
Kimlik prefix'leri: CloudTrail'de olay incelemeyi hızlandıran ipuçları
AWS, her kaynak türünü belirli bir kimlik ön eki (prefix) ile işaretler. Bir güvenlik olayı anında CloudTrail loglarına baktığınızda, UserId veya AccessKeyId alanında gördüğünüz bu prefix'ler, olayın kaynağını saniyeler içinde anlamanızı sağlar.
| Prefix | Kaynak Türü | Açıklama |
|---|---|---|
| AIDA | IAM Kullanıcı (User) | UserId alanında görülür. |
| AKIA | Uzun vadeli erişim anahtarı | Süresiz, yüksek risk. |
| ASIA | Geçici erişim anahtarı (STS) | Mutlaka SessionToken ile gelir. |
| AROA | IAM Rolü | AssumedRoleId içinde yer alır. |
| AGPA | IAM Grubu | GroupId için kullanılır. |
Aşağıdaki karar ağacı, bir olay anında hızlı sınıflandırma yapmanıza yardımcı olur:
Saldırı yüzeyi ve tehdit modeli
Senaryoyu saldırgan perspektifinden kurgulayalım. Bir geliştirici, stajyer kullanıcısına ait AKIA... anahtarını yanlışlıkla bir GitHub reposuna itti. Saldırgan bu anahtarı tarayıcılarla bulup kendi ortamına alır. İlk iş olarak kimliğini doğrular:
aws sts get-caller-identity --profile stolen
Dönen ARN’den yetkili bir IAM kullanıcısı olduğunu gören saldırgan, hangi rolleri üstlenebileceğini anlamak için IAM'i yoklar. Eğer stajyerler grubu uzman rolünü üstlenme iznine sahipse ve güven ilişkisinde MFA gibi ek bir koşul yoksa, saldırgan aşağıdaki çağrı ile yüksek yetkili bir oturum açar:
Komut içindeki 123456789012 yerine kendi AWS hesap ID'nizi yazmayı unutmayın.
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/uzman \
--role-session-name malicious
CloudTrail'de bu olay şu izleri bırakır:
userIdentity.arn:arn:aws:iam::123456789012:user/stajyereventName:AssumeRoleresponseElements.credentials.accessKeyId:ASIA...assumedRoleUser.arn:arn:aws:sts::123456789012:assumed-role/uzman/malicious
Atıf Kapsülü: AWS'nin kendi güvenlik rehberlerinde de belirttiği gibi, rol güven politikasında "aws:MultiFactorAuthPresent": "true" koşulu ve sts:ExternalId kullanımı, en kritik iki savunma katmanıdır (
AWS, 2024). Bu kontroller, sızan bir anahtarın doğrudan rol üstlenmesini engelleyerek saldırganın işini katlanarak zorlaştırır.
En iyi güvenlik pratikleri
Artık teorik ve pratik akışı gördüğümüze göre, uygulayabileceğiniz somut, savunmacı ve eyleme dönük adımları sıralayalım:
- Uzun vadeli anahtarı yalnızca başlangıç noktası yapın.
AKIAanahtarınız sadeceassume-roleçağrısı için kullanılmalı; sonraki tüm işlemler dönenASIAanahtarı veSessionTokenile gerçekleştirilmelidir. - Rol güven ilişkisinde MFA'yı zorunlu kılın. Trust policy içerisine
"Bool": {"aws:MultiFactorAuthPresent": "true"}koşulunu ekleyin. Daha esnek bir denetim için BoolIfExists operatörü de değerlendirilebilir. - Oturum süresini iş için yeterli en kısa değere ayarlayın.
--duration-secondsile istek başına süre sınırı koyun. Gereksiz uzun oturumlar riski artırır. - Çapraz hesap erişimlerinde ExternalId'yi zorunlu tutun. Üçüncü parti araçlar sizin hesabınıza erişirken, karşı tarafın bilmesi gereken rastgele bir
ExternalIdtanımlayın. - Erişim anahtarlarını otomatik rotasyona alın. AWS Config kuralları ve IAM Access Analyzer ile uzun süre kullanılmayan anahtarları tespit edin.
- CloudTrail'de AssumeRole olaylarını sürekli izleyin. Beklenmedik
roleSessionNamedeğerleri için anomali kuralları oluşturun. - Rol yetkilerini en az yetki ilkesine göre sınırlayın. Rolün permission policy'sini sadece ihtiyaç duyulan kaynaklara ve eylemlere izin verecek şekilde sıkılaştırın.
- Mümkünse uzun vadeli anahtarı tamamen ortadan kaldırın. AWS IAM Identity Center veya Instance Profile kullanarak, kullanıcılar ve uygulamalar için hiç uzun vadeli anahtar üretmeden çalışabilirsiniz. GCP'de bu kavramın karşılığı Service Account impersonation ve Workload Identity'dir; Azure'da ise Managed Identity olarak karşımıza çıkar. Her platformun ortak hedefi, sabit anahtarların oluşturduğu statik riski ortadan kaldırmaktır.
Sonuç
AWS STS ve AssumeRole mekanizması, bulut güvenliğinde "kısa vadeli düşün" prensibinin en güçlü uygulamalarından biridir. Uzun vadeli anahtarların taşıdığı süresiz riski, geçici ve sıkı denetlenebilir oturumlarla ikame eder. Ancak bu yapının gerçek anlamda güvenli olması, rol güven politikalarına eklenen MFA zorunluluğuna, ExternalId kullanımına, kısa oturum sürelerine ve rolün kendi yetkilerinin de en aza indirilmesine bağlıdır.
Sıkça sorulan sorular
STS ile alınan ASIA anahtarını ne kadar süre kullanabilirim?
AWS STS, assume-role çağrısı başına minimum 900 saniye (15 dakika) ile maksimum rol MaxSessionDuration değeri (12 saate kadar) arasında oturum süresi talep etmenize izin verir. Varsayılan değer genellikle 1 saattir. Güvenlik açısından işleminiz için yeterli olan en kısa süreyi talep etmelisiniz.
SessionToken olmadan ASIA anahtarı çalışır mı?
Hayır, çalışmaz. STS'den dönen SessionToken, isteğin geçici oturuma ait olduğunu doğrulamak için güvenlik belirteci olarak kullanılır. Eksik olduğunda, AWS API'leri isteğinizi otomatik olarak reddeder.
Role üstlenme olaylarını CloudTrail'de nasıl bulurum?
CloudTrail Event History içinde EventName = "AssumeRole" filtresiyle arama yapabilirsiniz. AWS CloudTrail, hesap başına son 90 günün olay geçmişini ücretsiz olarak saklar; AssumeRole olayları bu süre içinde sorgulanabilir. Dönen kayıtlarda ASIA* anahtarları ve assumedRoleUser bilgileri yer alır.
Uzun vadeli anahtar kullanımını tamamen sıfırlayabilir miyim?
Evet. AWS IAM Identity Center veya EC2 Instance Profile’lar kullanarak, kullanıcılar ve uygulamalar için hiç uzun vadeli AKIA anahtarı üretmeden, yalnızca geçici kimliklerle çalışan bir ortam kurabilirsiniz.
Kaynakça ve ek okuma
- AWS Documentation, “Temporary security credentials in IAM” - AWS
- AWS Documentation, “Using IAM roles” - AWS
- GitGuardian, “2024 State of Secrets Sprawl Report” - GitGuardian
- Unit 42, “Cloud Threat Report: Expanding Attack Surface” -
Unit 42 - IBM, “2024 Cost of a Data Breach Report” - IBM
- OWASP, “Cloud-Native Application Security Top 10” -
OWASP
Comments