Kimlik merkezli güvenlik

Geleneksel ağda bir varsayım vardı: içeriye giren güvenilirdir. Güvenlik duvarı kapıyı tutar, iç ağdaki makineler birbirine görece serbest konuşur. Bulut bu varsayımı kırar. Kovana, anahtar kasana ya da veritabanı yönetimine giden her istek bir kimlik taşır.

İsteği kabul ya da ret eden şey ağ değil, o kimliğe bağlı politikadır. Bu derste iki tür sırrı ayırt etmeyi, makinelerin anahtarsız kimlik almasını ve boru hatlarında kalıcı anahtarı kaldırmayı göreceksin. Son olarak bir olay anında kimliği nasıl durduracağını öğreneceksin.

Bulut API'sine giden her istek bir kimlik bilgisiyle imzalanır. AWS'de bu bilgi iki parçalıdır: erişim anahtarı kimliği ve gizli erişim anahtarı. Kimlik kısmı kullanıcı adına benzer, gizli kısım ise paroladır.

Kalıcı anahtar bir IAM kullanıcısına bağlıdır, diskte durur ve sen iptal edene kadar çalışır. Geçici kimlik ise üç parçalıdır: anahtar kimliği, gizli anahtar ve oturum jetonu. Bir rol üstlenildiğinde STS servisi bu üçlüyü üretir ve üçlü belirli bir süre sonra kendiliğinden düşer.

# Kalıcı anahtar: diskte durur, süresi yoktur
AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalr...

# Geçici kimlik: rol üstlenince gelir, birkaç saatte düşer
AWS_ACCESS_KEY_ID=ASIA...
AWS_SECRET_ACCESS_KEY=...
AWS_SESSION_TOKEN=IQoJb3JpZ2lu...

Örneğe bakarsan iki farklı sır türü görürsün. AKIA ile başlayan anahtar konsoldan oluşturduğun kalıcı bir kullanıcı anahtarıdır. ASIA ile başlayan anahtar ise STS'nin ürettiği geçici bir anahtardır ve yalnız gizli anahtar ile oturum jetonuyla birlikte anlam taşır. Bu önek bir olay anında zaman kazandırır.

Bir kod deposunda sızmış bir AKIA anahtarı bulursan, sen iptal edene kadar çalışacağını bilirsin. ASIA anahtarı ise süresi dolunca düşer. Ama o süre boyunca sahibinin bütün yetkisini taşır, bu yüzden onu da bekletmezsin. Kısa ömürlü kimliğin en yaygın biçimi makineye bağlı roldür.

Bir sanal makineye rol bağlarsın, makine anahtarı yerel üstveri servisinden (IMDS) alır. Diskte kalıcı sır durmaz ve rotasyonu elle yapmazsın. AWS yeni geçici kimliği, eskisinin süresi dolmadan en az beş dakika önce hazırlar.

Makinedeki SDK ve komut satırı aracı bu kimliği kendiliğinden bulur. Aşağıdaki örnekte kendi laboratuvar makinende yalnız bağlı rolün adını okursun. Anahtarın kendisini ekrana dökmezsin.

$ TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
    -H "X-aws-ec2-metadata-token-ttl-seconds: 300")
$ curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
    http://169.254.169.254/latest/meta-data/iam/security-credentials/
lab-rapor-yazici

İlk komut üstveri servisine bir PUT isteği atar ve beş dakika geçerli bir oturum jetonu alır. Bu adım IMDS'nin ikinci sürümüne (IMDSv2) özgüdür.

İkinci komut jetonu başlıkta taşır ve bağlı rolün adını döner: lab-rapor-yazici. Adresin sonuna rol adını eklersen servis bir JSON belgesi verir. Belgede ASIA ile başlayan anahtar kimliği, gizli anahtar, oturum jetonu ve bitiş zamanı durur.

Savunma tarafında ilk kural IMDSv2'yi zorunlu kılmaktır. Sunucu tarafı istek sahteciliği (SSRF) açıkları üstveri servisini hedefler ve eski sürüm tek bir GET isteğiyle yanıt verir.

# makinede ne aws configure var ne de ~/.aws/credentials
$ aws s3 cp rapor.txt s3://lab-kovam/rapor.txt
upload: ./rapor.txt to s3://lab-kovam/rapor.txt

Kimliğin neden merkeze geçtiğini mimari açıklar. S3 kovası senin ağının içinde durmaz. KMS anahtarı bir sunucuda çalışmaz. Bunlara erişim, genel bir uç noktaya atılan imzalı bir API çağrısıyla olur.

İmza, gizli anahtardan türetilir ama gizli anahtar istekle gitmez. AWS aynı hesaplamayı kendi tarafında yeniden yapar ve imzalar tutarsa isteği politikaya sorar. İmza ayrıca eski isteklerin tekrar oynatılmasını da zorlaştırır. AWS belgelerine göre istek, çoğu durumda üzerindeki zaman damgasından sonraki beş dakika içinde ulaşmalıdır.

Sonuç şudur: çalınan bir erişim anahtarı dünyanın herhangi bir yerinden çalışır. Saldırganın senin ağına girmesi gerekmez. NIST'in 2020'de yayımladığı SP 800-207 sıfır güven (zero trust) mimarisi bu gerçeği ilke hâline getirir.

Belgeye göre bir varlığa ya da hesaba, yalnız fiziksel ya da ağ konumuna bakılarak örtük güven verilmez. Her istek kimliğiyle, bağlamıyla ve politikasıyla ayrı ayrı değerlendirilir. Bulut bu ilkeye doğal olarak uyar, çünkü zaten her isteği imzalı bir kimlikle karşılar.

Gerçek hayatta bu zincir sık görülür. 2024'te bir bulut veri platformunun müşterilerini hedef alan bir kampanyada, olayı inceleyen ekip yaklaşık 165 kuruluşu olası mağdur olarak uyardı. Saldırgan yeni bir açık kullanmadı.

Kullanıcı bilgisayarlarına bulaşmış bilgi hırsızı zararlılardan toplanmış kullanıcı adı ve parolaları denedi. Bu parolaların bir kısmı 2020'den beri sızmış durumdaydı ve hiç değiştirilmemişti. Etkilenen hesaplarda çok adımlı doğrulama yoktu.

Erişimi güvenilir adreslerle sınırlayan bir ağ izin listesi de yoktu. Üç savunma da kimlik tarafında durur.

Hesabında kaç kalıcı anahtar var ve ne kadar eskiler? Bu sorunun hazır bir yanıtı vardır: IAM kimlik bilgisi raporu. Rapor her kullanıcının parolasını, ilk iki erişim anahtarını ve çok adımlı doğrulama durumunu tek bir CSV dosyasında toplar.

En fazla dört saatte bir yeniden üretilir; daha sık istersen son rapor gelir. Rapor yalnız okuma yetkisiyle alınır ve hiçbir şeyi değiştirmez. Denetimde kalıcı anahtar sorusuna ilk bu dosyayla yanıt verirsin.

$ aws iam generate-credential-report
$ aws iam get-credential-report --query Content --output text | base64 -d \
    | cut -d, -f1,8,9,10,11
user,mfa_active,access_key_1_active,access_key_1_last_rotated,access_key_1_last_used_date
<root_account>,true,false,N/A,N/A
denetci,true,true,2026-08-02T09:14:00+00:00,2026-09-28T07:40:00+00:00
eski-yedekleme,false,true,2023-03-11T10:02:00+00:00,2025-01-19T22:31:00+00:00
ci-dagitim,false,true,2025-06-30T12:00:00+00:00,2026-09-28T03:05:00+00:00

Satırları tek tek oku. Kök hesabın satırında etkin anahtar yok; olması gereken de budur. Kök hesaba da anahtar açılabilir, ama AWS bunu önermez.

denetci kullanıcısının anahtarı ağustosta döndürülmüş ve düzenli kullanılıyor. eski-yedekleme ise alarm verir. Anahtarı 2023'ten beri değişmemiş, son kez Ocak 2025'te kullanılmış. Yani bir buçuk yılı aşkın süredir kimse kullanmıyor ama anahtar hâlâ etkin.

Doğru adım önce anahtarı devre dışı bırakmak, bir süre bekleyip sonra silmektir. ci-dagitim ise her gün kullanılıyor. Onu silmek boru hattını durdurur; çözüm bir sonraki bölümdeki anahtarsız kimliktir. Tek bir kullanıcıya odaklanmak istersen list-access-keys komutu o kullanıcının anahtar kimliklerini, durumunu ve oluşturma tarihini verir.

Tespit tarafında rapor tek başına yetmez, çünkü anlık bir fotoğraftır. Denetim günlüğünde CreateAccessKey olayı için bir uyarı kuralı yazarsın. Saldırganlar ele geçirdikleri hesaba kalıcı olmak için yeni anahtar ekler.

MITRE ATT&CK bunu T1098.001 (Additional Cloud Credentials) olarak kaydeder. Bir anahtarın hiç kullanılmadığı bir bölgeden ya da tanımadığın bir adresten kullanılması da ikinci kuraldır. İki kural da nadiren tetiklenir, tetiklendiğinde ise hemen bakılacak kadar anlamlıdır.

Boru hatları uzun süre kalıcı anahtarla çalıştı. Anahtar deponun gizli değişkenlerine yazılır, her dağıtımda kullanılır ve yıllarca değişmez. Bir iş günlüğüne yanlışlıkla basılan tek satır bu anahtarı dışarı çıkarır. OIDC federasyonu bu anahtarı tamamen kaldırır.

GitHub Actions işi, GitHub'ın kimlik sağlayıcısından imzalı bir kimlik jetonu (JWT) ister. Bunun için iş akışında id-token: write izni gerekir. İş, jetonu STS'nin AssumeRoleWithWebIdentity çağrısıyla bir role çevirir ve geçici kimlik alır. Çoğu ekip bu adımı aws-actions/configure-aws-credentials eylemiyle yapar.

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:sub": "repo:ornek-org/lab-deposu:ref:refs/heads/main"
    }
  }
}

Güven politikasını yukarıdan aşağı oku. Principal alanı rolü yalnız GitHub'ın kimlik sağlayıcısından gelen jetonlara açar. Action alanı bu jetonla yapılacak tek işi, yani rol üstlenmeyi tanımlar.

Asıl kilit Condition bloğundadır. sub değeri jetonun hangi depodan ve hangi daldan geldiğini söyler. Burada yalnız lab-deposu adlı deponun main dalı rolü üstlenebilir.

Gerçek belgede bir de aud koşulu durur ve jetonun STS için üretildiğini doğrular. Sık yapılan hata sub koşulunu geniş bırakmaktır. Kimlik sağlayıcı bütün GitHub için ortaktır. Geniş bir koşul, rolü başkalarının deposundaki iş akışlarına da açar.

Çok bulutlu ortamlarda terimler değişir ama kavram sabit kalır. AWS'de makineye bağlı IAM rolü, Azure'da yönetilen kimlik (managed identity), Google Cloud'da ise hizmet hesabıdır. Üçünde de kodun bir anahtar dosyası taşıması gerekmez.

Geçici kimliği AWS'de STS, Azure'da Microsoft Entra ID üretir. Google Cloud'da bulut dışındaki iş yükleri, iş yükü kimlik federasyonu (Workload Identity Federation) ile hizmet hesabı anahtarı olmadan kısa ömürlü kimlik alır. Ekip iki bulutu birlikte kullanıyorsa, eşleme tablosunu baştan yazmak tartışmayı kısaltır.

Kimlik merkezli modelde izleme de kimlik olaylarına bakar. Bir anahtarın olağandışı bir bölgeden kullanılması, yeni bir kaynaktan rol üstlenilmesi ve IAM politikasının değişmesi ilk uyarı kurallarıdır. Çok adımlı doğrulamanın kapatılması da bu listeye girer. Bu olayların hiçbiri ağ trafiğinde görünmez, yalnız denetim günlüğünde durur.

Dış hizmet sağlayıcılar için de aynı mantık geçerlidir. Sağlayıcıya kullanıcı açıp anahtar vermek yerine, kendi hesabından üstlenebileceği dar bir rol tanımlarsın. Sözleşme bitince rolü silersin ve elinde kalan hiçbir kimlik çalışmaz.

Bir olay anında ilk soru hangi makine değil, hangi kimlik olur. Kimliği durdurmak makineyi kapatmaktan hızlıdır ve etkisi hemen görülür.

Kalıcı anahtar için anahtarı devre dışı bırakırsın. Rol için ise konsoldaki oturumları iptal etme adımını kullanırsın. Bu adım role AWSRevokeOlderSessions adlı bir satır içi politika ekler.

Politika, belirli bir andan önce üretilmiş bütün oturumları aws:TokenIssueTime koşuluyla reddeder. Yeni oturum açan meşru kullanıcı etkilenmez. Sıra şöyledir: kimliği durdur, oturumları düşür, sonra incelemeye geç.