← Blog'a dön
2026-07-20 | 0gulcandogan | Medium'dan aktar&305;ld&305; | 8 dk okuma

Bir anahtara sahip olmak her zaman her kapıyı açmaz: Her Yerde IAM Rolleri

Having a Key Doesn’t Always Open Every Door: IAM Roles Anywhere

AWS içindeyseniz hayat çok kolay. Bir EC2 örneğine bir IAM rolü atayın, hepsi bu kadar. Peki ya sunucunuz AWS'de çalışmıyorsa? Ya veri merkezinde bulunan eski bir uygulama, fabrika zemininde duran bir IoT cihazı veya hatta masanızın altına saklanmış ve AWS'ye erişmesi gereken bir Raspberry Pi ise? (Şaka yapıyorum, bu makalede hiçbir şeye izinsiz girmeyeceğiz :d)

Geleneksel yaklaşım her zaman aynıydı: makineye bir erişim anahtarı yerleştirin, bunu ~/.aws/credentials dosyasına ekleyin ve her şeyin yolunda gitmesini umun. Daha önce de tartıştığımız gibi, bugün statik bir erişim anahtarını bıraktığınız her yer, yarın muhtemelen unutacağınız bir yerdir.

IAM Roles Anywhere, tam da bu sorunu çözmek için var. “Erişim anahtarları yerine roller kullanın” felsefesini AWS’nin ötesine, dış dünyaya taşıyor. Bu yazıda, sadece nasıl çalıştığını değil, aynı zamanda gerçek bir ortamda adım adım nasıl kurulacağını da inceleyeceğiz.

Kimlik, Erişim Anahtarları Değil

IAM Roles Anywhere’in temel fikri basittir. AWS dışında çalışan bir iş yükü, uzun ömürlü bir erişim anahtarı taşımak yerine, bir X.509 sertifikası kullanarak kimliğini kanıtlar. Bu sertifika, ister kendi yönettiğiniz bir Sertifika Yetkilisi (CA) tarafından ister AWS Özel CA tarafından imzalanmış olsun, kendi Açık Anahtar Altyapınız (PKI) kaynaklıdır.

Aradaki fark çok önemlidir. Bir erişim anahtarı kopyalanabilir, paylaşılabilir, yanlışlıkla GitHub'a kaydedilebilir veya sayısız başka yolla ifşa edilebilir. X.509 sertifikası ise farklı şekilde çalışır. Özel anahtarı cihazdan asla çıkmaz. Yalnızca kriptografik bir imza oluşturmak için kullanılır ve AWS'ye yalnızca bu imza gönderilir. Özel anahtar her zaman sizin kontrolünüz altında kalır.

İşte pratik bir örnek. Her gece Amazon S3’e veri yükleyen bir şirket içi yedekleme sunucunuz olduğunu düşünün. Bir IAM kullanıcısı oluşturup bu sunucuda bir erişim anahtarı depolamak yerine, bir sertifika yükleyip IAM Roles Anywhere'in bu sunucu adına geçici kimlik bilgilerini almasına izin verirsiniz. Sunucu ele geçirilse bile, saldırgan kalıcı bir erişim anahtarı yerine yalnızca kısa süreli kimlik bilgilerine sahip olur.

Üçgenin Üç Köşesi (Güven Çapası, Profil ve Rol)

IAM Roles Anywhere'i anlamanın en kolay yolu, üç temel bileşeninin birbiriyle nasıl uyum içinde çalıştığını incelemektir.

Bu üç bileşen olmadan sistem çalışmaz. Üçgenin bir köşesi eksik olursa, tüm model çöker.

Şimdi bu üçgeni kendimiz oluşturma zamanı. Teoriyi ele aldık, şimdi pratik kurulum aşamasına geçelim.

IAM Roles Anywhere Akışı

Şimdiye kadar, IAM Roles Anywhere’in üç temel bileşenini inceledik. Şimdi bunları tek bir uçtan uca akışa yerleştirelim. Aşağıdaki şema, her şeyin nasıl birbirine uyduğunu gösterir ve bir şeyi netleştirir: sınırı geçen tek şey bir sertifikadır. Uzun ömürlü erişim anahtarları söz konusu değildir.

Şirket içi iş yükü, X.509 sertifikasını sunarak sınırı aşar. AWS tarafında, IAM Roles Anywhere kimliğini doğrular, AWS Security Token Service (STS) geçici kimlik bilgilerini verir ve bu kimlik bilgileri daha sonra hedef AWS kaynağına erişmek için kullanılır. Şimdi, sertifikadan başlayarak bu akışı adım adım oluşturalım.

Sertifika Nasıl Oluşturulur?

İlk soru basit: Bu sertifika nereden geliyor? Cevap, ya AWS Private CA ya da kendi Açık Anahtar Altyapınız (PKI)dır. Kuruluşunuz halihazırda bir Sertifika Yetkilisi (CA) işletmiyorsa, AWS Private CA bunu yönetilen bir hizmet olarak sunar.

AWS Özel CA'da bir CA oluştururken birkaç önemli karar vermeniz gerekecektir:

Laboratuvar ortamı için kendi kendinden imzalı Kök Sertifika Otoritenizi (Root CA) oluşturabilir ve kullanabilirsiniz. Bunu asla üretim ortamında yapmamalısınız, ancak sürecin nasıl işlediğini anlamak için mükemmeldir. Kök sertifikamız ve özel anahtarımızın (root-cert.pem ve root-key.pem) zaten elimizde olduğunu varsayalım. Şimdi bir istemci sertifikası düzenleme zamanı.

# 1. Generate a private key and Certificate Signing Request (CSR) for the client
openssl req \
    -nodes \
    -new \
    -keyout certificates_data/client/client-key.pem \
    -out certificates_data/client/client-csr.pem \
    -config certificates_data/client/client.conf

Output:
Generating a RSA private key
..............+++++
writing new private key to 'certificates_data/client/client-key.pem'
-----
# 2. Sign the CSR with the Root CA to issue the client certificate
openssl x509 \
    -req \
    -in certificates_data/client/client-csr.pem \
    -CA certificates_data/root-ca/root-cert.pem \
    -CAkey certificates_data/root-ca/root-key.pem \
    -set_serial 2 \
    -out certificates_data/client/client-cert.pem \
    -days 365 \
    -sha256 \
    -extfile certificates_data/client/client.conf \
    -extensions v3

Output:
Certificate request self-signature ok
subject=CN = backup-server-01

İlk komut iki şey üretir: iş yükünün kimliğini temsil edecek özel anahtar ve esasen iş yükünün “Sertifikamı imzalayabilir misiniz?” diye sorduğu Sertifika İmzalama İsteği (CSR). İkinci komut, Kök CA’nın özel anahtarını kullanarak bu isteği imzalar ve asıl sertifikayı (client-cert.pem) düzenler. Bunu, resmi bir belge düzenlemeden önce kimliğinizi doğrulayan bir noter gibi düşünün.

Üçgeni Gerçekten Oluşturmak

Artık sertifikamız olduğuna göre, IAM Roles Anywhere'in üç temel bileşenini oluşturma zamanı geldi: Güven Ankrajı, IAM Rolü ve Profil.

Adım 1: Bir Güven Çapası Oluşturun

aws rolesanywhere create-trust-anchor \
    --name "on-prem-backup-ca" \
    --source sourceType=CERTIFICATE_BUNDLE,sourceData="{x509CertificateData=$(cat certificates_data/root-ca/root-cert.pem)}" \
    --enabled

Output:
...
{
  "trustAnchor": {
    "trustAnchorId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
    "name": "on-prem-backup-ca",
    "enabled": true,
    "trustAnchorArn": "arn:aws:rolesanywhere:eu-west-1:123456789012:trust-anchor/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
  }
}
...

Adım 2: Bir IAM Rolü Oluşturun (Güven Politikası ile)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "rolesanywhere.amazonaws.com" },
      "Action": ["sts:AssumeRole", "sts:SetSourceIdentity", "sts:TagSession"],
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:rolesanywhere:eu-west-1:123456789012:trust-anchor/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
        }
      }
    }
  ]
}

Koşul bloğu önemlidir. Bu rolün yalnızca belirli Güven Çapası aracılığıyla üstlenilebilmesini sağlar.

aws iam create-role \
    --role-name backup-server-role \
    --assume-role-policy-document file://trust-policy.json

Adım 3: Bir Profil Oluşturun

aws rolesanywhere create-profile \
    --name "backup-server-profile" \
    --role-arns "arn:aws:iam::123456789012:role/backup-server-role" \
    --enabled

Output:

...
{
  "profile": {
    "profileId": "f9e8d7c6-1234-5678-90ab-EXAMPLE22222",
    "name": "backup-server-profile",
    "profileArn": "arn:aws:rolesanywhere:eu-west-1:123456789012:profile/f9e8d7c6-1234-5678-90ab-EXAMPLE22222"
  }
}
Bu noktada, üçgenin üç köşesi de yerine oturmuş oldu.

Rolü İşe Koyma (Erişim Anahtarlarının Olmadığı Bir Gün)

Son adım, yedekleme sunucumuzun sertifikasını kullanarak geçici AWS kimlik bilgilerini almasını sağlamaktır. İsteği kendimiz oluşturmamız veya imzalamamız gerekmez. AWS, tüm imza sürecini yöneten ve bizim adımıza geçici kimlik bilgilerini alan resmi aws_signing_helper yardımcı programını sağlar.

aws_signing_helper credential-process \
    --certificate certificates_data/client/client-cert.pem \
    --private-key certificates_data/client/client-key.pem \
    --trust-anchor-arn arn:aws:rolesanywhere:eu-west-1:123456789012:trust-anchor/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
    --profile-arn arn:aws:rolesanywhere:eu-west-1:123456789012:profile/f9e8d7c6-1234-5678-90ab-EXAMPLE22222 \
    --role-arn arn:aws:iam::123456789012:role/backup-server-role
# Use the ARN values of the Trust Anchor, IAM Role, and Profile you created earlier.

Output: 

...
{
  "Version": 1,
  "AccessKeyId": "ASIAEXAMPLE1234567",
  "SecretAccessKey": "wJalrXUtEXAMPLEKEYEXAMPLEKEYEXAMPLE",
  "SessionToken": "IQoJb3JpZ2luX2VjEXAMPLE...",
  "Expiration": "2026-07-18T14:32:00Z"
}
...

Şimdi tek yapmamız gereken, bu yapılandırmayı ~/.aws/config dosyamıza eklemek.

# ~/.aws/config
[profile backup-server]
credential_process = aws_signing_helper credential-process --certificate ... --private-key ... --trust-anchor-arn ... --profile-arn ... --role-arn ...

Şimdi gerçek bir komut deneyelim. Bu yedekleme sunucumuz olduğu için, bir backup.tar.gz dosyasını S3’e yükleyeceğiz.

aws s3 cp backup.tar.gz s3://my-backup-bucket/ --profile backup-server
upload: ./backup.tar.gz to s3://my-backup-bucket/backup.tar.gz

Sertifikaların da Kuralları Vardır

IAM Roles Anywhere, herhangi bir sertifikayı kabul etmez. Bir istemci sertifikası birkaç gereksinimi karşılamalıdır:

Ayrıca, sertifikanın Konu veya Düzenleyen alanlarına göre IAM rolünüzün güven politikasına ek kısıtlamalar da ekleyebilirsiniz. Örneğin, yalnızca CN=backup-server-01 değerine sahip sertifikaların rolü üstlenmesine izin verilebilir.

Unutulmaması gereken son bir nokta, AWS Özel CA'nın bölgesel bir hizmet olduğudur. İş yükleriniz birden fazla AWS Bölgesinde çalışıyorsa, sertifika vermek veya yönetmek istediğiniz her Bölgede ayrı bir Özel CA oluşturmanız gerekir.

Özel Anahtarınızı Nasıl Saklamalısınız?

Şimdiye kadar, client-key.pem dosyasını diskte normal bir dosya olarak sakladık. Bu, laboratuvar ortamı için gayet uygundur, ancak üretim ortamında pratik olarak sorunlara davetiye çıkarmak anlamına gelir. Diskte saklanan bir özel anahtar, yine de kopyalanabilecek veya çalınabilecek bir gizli bilgidir. Başka bir deyişle, IAM Roles Anywhere'in çözmeye çalıştığı sorunu yeniden yaratmış olursunuz. Tek fark, statik bir erişim anahtarını statik bir özel anahtarla değiştirmiş olmanızdır.

Çözüm, özel anahtarın dışa aktarılmasını engellemek, yani anahtarın oluşturulduğu donanımdan asla çıkmamasını sağlamaktır.

Uygulamada, aws_signing_helper komutu neredeyse aynı kalır. Tek fark, diskteki bir anahtar dosyasına işaret etmek yerine, donanım içinde depolanan anahtara referans veren bir PKCS#11 URI'si sağlamanızdır.

aws_signing_helper credential-process \
    --cert-selector "Url=pkcs11:token=backup-server-token;object=client-cert" \
    --trust-anchor-arn arn:aws:rolesanywhere:eu-west-1:123456789012:trust-anchor/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
    --profile-arn arn:aws:rolesanywhere:eu-west-1:123456789012:profile/f9e8d7c6-1234-5678-90ab-EXAMPLE22222 \
    --role-arn arn:aws:iam::123456789012:role/backup-server-role

Basit bir kural: Sunucunuz kritik öneme sahipse — örneğin, finansal verileri işliyorsa veya bir devlet ya da savunma ortamına aitse — özel anahtarı diskte saklamayın. Bunun yerine, HSM veya TPM içinde güvende tutun. Eğer mutlaka bir dosya olarak saklamanız gerekiyorsa, izinlerini kilitleyin (örneğin, chmod 400) ve bu özel anahtarı asla bir makine görüntüsüne veya anlık görüntüsüne dahil etmeyin.

Aynı Ders, Farklı Bir Yaklaşım

Daha önce, IAM kullanıcıları yerine IAM rollerini kullanmaktan bahsettiğimizde, temel ders basitti: uzun ömürlü kimlik bilgileri uzun ömürlü risk yaratırken, geçici kimlik bilgileri kontrollü risk yaratır. IAM Roles Anywhere, bu ilkeyi AWS sınırlarının ötesine taşır.

Bu noktada, iş yükünüzün AWS içinde mi yoksa başka bir yerde mi çalıştığı artık önemli değildir. Kural aynı kalır: kalıcı bir erişim anahtarı taşımayın. Kimliğinizi kanıtlayın, geçici kimlik bilgilerini alın ve işinizi halledin.

Unutmayın, birisi bir sertifikayı çalsa bile kalıcı bir anahtarı çalmış olmaz. En fazla, sadece birkaç saat geçerli olan bir bilet elde etmiş olur. Ancak sertifikanın arkasındaki özel anahtar baştan itibaren güvenli bir şekilde depolanmamışsa, bu koruma bile anlamsız hale gelir.

IAM Roles Anywhere, yepyeni bir güvenlik modeli getirmiyor. Sadece, yıllardır AWS içinde uyguladığımız en iyi uygulamaları, AWS dışında çalışan iş yüklerine de getiriyor. Uygulamalarınız nerede barındırılırsa barındırılsın, ilke aynı kalır: uzun ömürlü gizli bilgiler yerine geçici kimlik bilgileri ve erişim anahtarları yerine kimlik.

Kaynakça

Orijinal: https://medium.com/@0gulcandogan/having-a-key-doesnt-always-open-every-door-iam-roles-anywhere-3bd160404307?source=rss-746132cb79a8------2

#devsecops#security#iam-roles#iam-anywhere#aws

İlgili yazılar

2026-07-17Eski Bir Arkadaş Bir Anahtarla Ortaya Çıktı: İnsan Dışı Kimlik Yönetimi2026-07-28Sevgili Bucket: Başkası Bulmadan Önce Sırlarını Güvende Tutmak, Veri Koruma - 1. Bölüm2026-08-05Vault’un Koruyucuları: Anahtarları Gerçekte Kim Elinde Tutuyor? Veri Koruma – 2. Bölüm
Okuduğunuz için teşekkürler

Bu yazı işinize yaradıysa paylaşmayı veya logdaki diğer yazıları keşfetmeyi düşünebilirsiniz.

← Tüm yaz&305;lar Yazar hakk&305;nda