Rol üstlenme ve güven zincirleri

Rol üstlenme (assume role), bir kimliğin geçici olarak başka bir kimliğe bürünmesidir. Bulut mimarisinin bel kemiğidir: bir kişi kurum hesabıyla girer ve denetçi rolüne bürünür, bir makine kendi rolüyle başka bir hesaptaki role geçer. Her seferinde alınan kimlik geçici ve dar kalır, bu yüzden bir sızıntının hem ömrü hem kapsamı küçülür. Bu derste üstlenmenin iki kapısını, dönen geçici kimliğin parçalarını, güven politikasındaki tehlikeli hataları ve zincirlerin yetki haritasını nasıl gizlediğini adım adım kuracaksın.

Altay Kargo'nun bulut ekibinde sıradan bir gün böyle geçer. Geliştirici kurum hesabıyla girer, okuma işleri için okuyucu rolüne, sürüm çıkarırken dağıtımcı rolüne bürünür. Gece çalışan yedekleme işi kendi makine rolüyle arşiv hesabındaki bir role geçer ve kovaya yazar. Bu düzende diskte bekleyen tek bir kalıcı anahtar yoktur.

Çalınan bir geçici anahtar en geç birkaç saat içinde kendiliğinden geçersiz olur. Kimse tam yetkiyle dolaşmaz, herkes o anki işin gerektirdiği rolü taşır. İyi kurulmuş bir hesapta kalıcı anahtar neredeyse hiç bulunmaz.

Mekanizma iki kapıya dayanır. Birinci kapı çağıranın kimlik politikasıdır: sts:AssumeRole eylemine izni var mı? İkinci kapı hedef rolün güven politikasıdır: bu çağıranı kabul ediyor mu? Hesaplar arası üstlenmede ikisi birden açık olmalıdır, biri kapalıysa istek reddedilir.

Aynı hesapta bir istisna vardır. Güven politikası çağıranın ARN'sini doğrudan Principal alanına yazmışsa, bir kaynak politikası gibi çalışır ve kimlik tarafında ayrıca izin aranmaz. Güven politikası yalnız hesabı gösteriyorsa kapıyı yine kimlik politikası açar. Bu yüzden bir rolün kime açık olduğunu incelerken her zaman iki yere birden bakarsın.

Güven politikası bu iki kapıdan ikincisidir ve rolün kendi içinde durur. Aşağıdaki örnek hangi hesaptan ve hangi koşulla üstlenilebileceğini aynı belgede tanımlar. Principal alanı çağıranı belirtir, Condition alanı ise ek bir şart taşır.

Burada rol yalnız belirli bir hesaptan ve yalnız doğru harici kimlik (external id) gönderildiğinde üstlenilebilir; ikisi de tutmazsa istek reddedilir. Bir güven politikasını okurken bu iki alan yeter: kimi kabul ediyor ve hangi ek şartı arıyor. Principal geniş, Condition boşsa kapı olması gerekenden açıktır.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "musteri-4821" }
    }
  }]
}

$ aws sts assume-role \
    --role-arn arn:aws:iam::111122223333:role/lab-denetci \
    --role-session-name denetim-01

Komut çalışınca dönen çıktıyı okumak öğreticidir. STS geçici bir kimlik üçlüsü ve bir de son kullanma zamanı döner. Bu üçlü, kalıcı bir kullanıcı anahtarından iki yönüyle ayrılır: üç parça birlikte kullanılır ve belirli bir anda kendiliğinden geçersiz olur.

Yanıtın içinde bir de üstlenilmiş rolün adresi gelir; bu adres çağrıda yazdığın oturum adını taşır ve sonradan kimin ne yaptığını bulmaya yarar. Aşağıdaki yanıt, yukarıdaki üstlenme çağrısının tipik sonucudur ve alanlarını tek tek okuyacağız.

{
  "Credentials": {
    "AccessKeyId": "ASIAIOSFODNN7EXAMPLE",
    "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY",
    "SessionToken": "IQoJb3JpZ2luX2VjEXAMPLE...",
    "Expiration": "2026-09-30T14:34:41Z"
  },
  "AssumedRoleUser": {
    "Arn": "arn:aws:sts::111122223333:assumed-role/lab-denetci/denetim-01",
    "AssumedRoleId": "AROA...:denetim-01"
  }
}

Alanları oku. AccessKeyId geçici olduğu için ASIA ile başlar; kalıcı bir kullanıcı anahtarı ise AKIA ile başlar, ilk dört harf ikisini anında ayırır. SecretAccessKey istekleri imzalayan gizli anahtardır ve ağ üstünden hiç gönderilmez.

SessionToken her isteğe eklenir ve anahtarın geçici bir oturuma ait olduğunu kanıtlar; üç parçadan biri eksikse istek reddedilir. Expiration kimliğin düşeceği andır. Arn alanının sonundaki denetim-01, çağrıda yazdığın oturum adıdır ve bu ad CloudTrail kaydında görünür; anlamlı bir ad, sonradan bir işlemi kimin yaptığını bulmayı kolaylaştırır.

Güven politikasındaki en tehlikeli hata yıldızdır. Principal alanına yıldız yazmak rolü her AWS hesabına açar. Koşul da yoksa dünyadaki herhangi bir hesap bu rolü üstlenip yetkilerini kullanır.

Kapıyı ardına kadar açık bırakıp anahtarı kilidin üstünde unutmak gibidir; rolün ne yaptığından bağımsız olarak, o role bağlı bütün yetkiler artık herkese açıktır. Denetimde bir güven politikasında yıldız görmek, hemen durup incelenmesi gereken bir işarettir.

İkinci sık hata, dış sağlayıcıya açılan rollerde harici kimlik (external id) koşulunun atlanmasıdır. Bir dış hizmet, hesabına erişmek için senin rolünü üstlenir. Aynı hizmeti kullanan başka bir müşteri, senin rolünün ARN değerini öğrenir ya da tahmin ederse rolü üstlenmeye kalkar.

Hesap numarası ve rol adresi gizli bir bilgi değildir, kayıtlarda ve adreslerde açıkça görünür. Bu duruma karışık vekil sorunu (confused deputy) denir: aracı hizmet, kimin adına çalıştığını karıştırır ve yanlış müşteriye senin kaynaklarını açar.

Üstlenme sırasında ne olduğunu görmek karışıklığı dağıtır. Önce çağıranın kimlik politikası sts:AssumeRole eylemini açar ve STS'ye hedef rolün adresiyle bir istek gider. Rolün güven politikası çağıranı kontrol eder. İki kapı da açıksa STS geçici kimlik üçlüsünü döner.

Sonraki her çağrı bu geçici kimlikle imzalanır. CloudTrail bu akışın iki ucunu ayrı kaydeder.

AssumeRole olayı üstlenmeyi ve dönen geçici anahtarın kimliğini yazar. Sonraki olaylarda aynı anahtar kimliği ve üstlenilmiş rol adresi görünür. Soruşturmada iki ucu bu anahtar kimliği ve oturum adı birbirine bağlar.

Zincirler yetki haritasını bulanıklaştırır. A rolü B'yi, B de C'yi üstlenebiliyorsa, A aslında C'nin yetkilerine sahiptir. Politikalara tek tek bakan bir denetim bunu göremez, çünkü A'nın kendi politikasında C hiç geçmez; yetki üç ayrı belgeye dağılmıştır.

Gerçek yetki, üstlenme köprülerinin toplamıdır. Bu yüzden test hesabındaki dar bir rolün, birkaç köprü üstünden üretim hesabındaki yönetici bir role çıktığı çoğu ekipte fark edilmeden durur.

Bu yüzden zinciri çıkarmak için grafik düşünmek gerekir. Her rol bir düğüm, her üstlenme izni bir kenardır. Açık kaynak araçlar bu grafiği çıkarır.

PMapper kimlikleri düğüm, aralarındaki erişimi kenar olarak modelleyip kimin neyi yapabileceğini sorgular ve yönetici yetkisine çıkan yolları işaretler; örneğin kimin iam:CreateUser yapabileceğini tek komutla sorabilirsin. awspx ise benzer bir grafiği görsel olarak gezmene yarar. İkisi de kendi hesabında, savunma amaçlı çalıştırılır ve beklenmedik köprüleri görünür kılar.

Geçici kimliğin bir ömrü vardır. assume-role çağrısında süreyi DurationSeconds ile istersin. En kısa süre on beş dakikadır. Üst sınır, rolde bir ile on iki saat arasında ayarlanan en uzun oturum süresidir.

Süre belirtmezsen bir saat alırsın, ayardan uzun bir süre istersen çağrı hata verir. Bir rolün geçici kimliğiyle başka bir rolü üstlendiğinde, yani zincir kurduğunda, tavan bir saate iner. Rolün ayarı on iki saat olsa bile zincirdeki çağrı bir saatten uzun süre alamaz.

Dış hesaba açılan rollerde güven politikası iki soruya birden cevap verir: hangi hesap ve hangi koşulla. Kendi organizasyonundaki başka bir hesaba rol açarken Principal alanına o hesabı ya da tek bir rolün ARN'sini yazarsın. aws:PrincipalOrgID koşulu da isteği kendi organizasyonuna bağlar.

Bir dış hizmete açılan rolde ise harici kimlik koşulu şarttır, çünkü o hizmetin hesabı başka müşterilerin adına da çağrı yapar. Hesaplar arası üstlenmede çağıranın kimlik politikası da sts:AssumeRole iznini ayrıca vermelidir.

Boru hatları tarafında rol üstlenme federasyonla birleşir. GitHub Actions işi kısa ömürlü bir OIDC jetonu üretir, rol bu jetonu kabul eder ve depoda kalıcı anahtar saklanması ortadan kalkar. Koşulu doğru yazmak burada kritiktir.

Yalnız kimlik yayıncısını kontrol eden bir güven politikası, aynı platformdaki her depoya kapıyı açar. Bu yüzden token.actions.githubusercontent.com:sub koşuluna depo ve dal bilgisi de yazılır. AWS bu kuralı zorlar: bu koşul hiç yoksa ya da yalnız yıldızdan ibaretse, güven politikasını kaydetmeyi reddeder. Jetonun hedef kitle (aud) değeri de STS servisine sabitlenir.

Süre ve federasyon birlikte düşünülünce zincir sayısını bilinçli tutmak gerekir. Kısa ömürlü bir OIDC jetonuyla role giren bir iş, üstünde başka bir rolü üstlenmeye kalkarsa aynı bir saatlik tavana çarpar.

Uzun süren dağıtım işlerinde bu tavan sessizce vurur ve iş yarıda kalır. Bu yüzden federasyon kurulumlarında rol, işi tek adımda görecek yetkiyi taşır ve gereksiz köprüler eklenmez. Zincir gerçekten gerekiyorsa her adımın bir saatlik sınıra sığdığını önceden ölçersin, yoksa hata mesajı seni yanlış yere bakmaya iter.

Üstlenme olayları izlenmesi gereken kayıtlardır. Yeni bir kaynaktan gelen AssumeRole çağrısı, olağan dışı oturum adları ve gece saatlerinde üstlenilen yönetici rolleri iyi uyarı kurallarıdır. Acil durum rolleri ayrı düşünülür: normalde kimseye bağlı durmaz, çünkü geniş yetki taşırlar.

Kullanıldıklarında bir uyarı üretirler, oturumları kaydedilir ve olay sonrası gözden geçirilir. Böylece hem hızlı müdahale için gereken geniş yetki hazır durur, hem de o yetkiyi kimin ne zaman kullandığı hesap verebilir kalır.

Bulut dışında çalışan sunucular ve uygulamalar için de kalıcı anahtar tutmaya gerek yoktur. IAM Roles Anywhere, bir sertifika otoritesine güvenerek bu iş yüklerine geçici kimlik verir.

Otoriteyi bir güven çıpası olarak kaydedersin, iş yükü kendi X.509 sertifikasıyla kimliğini kanıtlar ve karşılığında rolün geçici anahtarlarını alır. Böylece bir fabrikadaki ya da başka bir buluttaki sunucu bile kalıcı anahtar taşımadan buluta bağlanır ve buluttaki iş yükleriyle aynı rol ve politikaları kullanır. Kalıcı anahtarın nerede saklandığı sorusu tamamen ortadan kalkar.