ISMS uyumluluğu sırasında başlayan AWS Access Key temizliği: Role tabanlı kimliğe doğrulamaya geçiş hikayesi

ISMS takip denetimine hazırlık sürecinde AWS hesabında birikmiş Access Key'leri incelerken, Role tabanlı kimlik doğrulamaya geçiş deneyimini derleyen bir yazı.

Geçişin arka planı

• IAM konsoluna bakınca Access Key'lerin birçok yere yayıldığı görülüyordu (CI/CD, dağıtım script'leri, yerel geliştirme vb.) ve nerede nasıl kullanıldıklarını takip etmek zordu
• Access Key'ler süre sonu olmadan kalıyor ve ele geçirildiklerinde verilen yetkiler olduğu gibi açığa çıktığı için risk yüksekti
• AWS de uzun süreli kimlik bilgileri (Access Key) yerine geçici kimlik bilgileri (role/STS) kullanımını öneriyor

Sorun

• Anahtarlar oraya buraya kopyalanıp kullanıldıkça, “Bu anahtar ele geçirilirse etki alanı nereye kadar uzanır?” sorusuna yanıt vermek zorlaşıyordu
• Rotasyon yapmak için dağınık ayarların aynı anda değiştirilmesi gerekiyordu ve tek bir IAM User üzerinde birden fazla kullanım amacına ait yetkiler toplandığından en az ayrıcalık ilkesini uygulamak zordu
• O dönemde CI/CD için kullanılan tek bir IAM User üzerinde ECR/S3/SSM/ECS dağıtım yetkileri gibi izinler bir arada toplanmıştı

Geçilen yöntemler (özet)

• Assume Role: Gerektiği anda başka bir Role'un yetkilerini geçici olarak ödünç alma yöntemi
• OIDC Web Identity: GitHub Actions/EKS(=IRSA) gibi dış sistem kimlikleriyle Role verilmesi yöntemi
• Instance Profile: EC2/Lambda gibi servislerde Role'u doğrudan ekleyip otomatik yetki verme yöntemi

Gerçek geçiş süreci

• 1. adım: Geniş kapsamlı policy bağlı IAM User yetkilerini kullanım amacına göre Role'lara ayırma (ECR push/pull, ECS dağıtımı, S3 cache vb.)
• 2. adım: GitHub Actions'a OIDC uygulama (Identity Provider kaydı → Trust Policy koşullarıyla repo kapsamını sınırlama → workflow içinde configure-aws-credentials kullanma)

Etki

• Koddan ve secret'lardan Access Key kaldırıldı; yapı geçici token tabanlı olduğu için ele geçirilse bile süresi dolduğunda etki alanı sınırlı kalıyor
• Anahtar rotasyonu yükü ortadan kalktı ve workflow/görev bazında yetki takibi netleşti

Dikkat edilmesi gerekenler

• Trust Policy koşullarını geniş tutmayın; en dar kapsamla sınırlayın (org/repo, mümkünse branch'e kadar)
• Mevcut Access Key'leri hemen silmeyin; geçişten sonra bir süre devre dışı bırakıp/doğrulama süresi tanıyıp ardından silin