AWS IAM ile Bulut Güvenliği Temelleri

Tarafındankomut
0 Yorum

Bulut altyapısı kurdunuz, EC2 instance’larınız çalışıyor, S3 bucket’larınız var, veritabanlarınız ayakta. Peki ya bu kaynaklara kim erişebiliyor? Hangi servis hangi bucket’a yazabiliyor? Bir geliştirici yanlışlıkla production veritabanını silerse ne olur? İşte tam bu noktada AWS IAM devreye giriyor ve “kimsin, ne yapabilirsin” sorularının cevabını veriyor. IAM yanlış yapılandırıldığında bulut faturanız patlar, verileriniz sızar ya da her ikisi birden olur. Doğru yapılandırıldığında ise uyku rahat olur.

IAM Nedir ve Neden Bu Kadar Kritik?

IAM (Identity and Access Management), AWS kaynaklarına erişimi kontrol eden merkezi bir servistir. Ücretsizdir, global’dir (region’a bağlı değildir) ve AWS’deki her şeyin temel güvenlik katmanını oluşturur.

IAM’in yönettiği üç temel kavram şunlardır:

  • Authentication (Kimlik Doğrulama): Sen kimsin?
  • Authorization (Yetkilendirme): Ne yapabilirsin?
  • Audit (Denetim): Ne yaptın?

Gerçek dünyadan bir senaryo düşünelim. Bir startup’ın CTO’su bana ulaştı, sabah 3’te AWS faturasında 47.000 dolar şişme görmüşlerdi. Araştırdığımızda bir geliştirici ortamındaki access key’in GitHub’a commit edildiğini, botların bunu bulup cryptocurrency mining için kullandığını gördük. IAM politikaları doğru olsaydı, o key’in EC2 başlatma yetkisi olmayacaktı ve bu felaket yaşanmayacaktı.

IAM Bileşenlerini Tanıyalım

Users (Kullanıcılar)

IAM user’lar, AWS konsoluna veya API’ye erişen gerçek insanları temsil eder. Her kullanıcının kendine ait kimlik bilgileri olur.

# AWS CLI ile yeni IAM user oluşturma
aws iam create-user --user-name ali.yilmaz

# Kullanıcıya console erişimi için login profili oluşturma
aws iam create-login-profile 
  --user-name ali.yilmaz 
  --password "Gecici123!" 
  --password-reset-required

# Kullanıcının bilgilerini görüntüleme
aws iam get-user --user-name ali.yilmaz

Groups (Gruplar)

Her kullanıcıya tek tek politika atamak hem hatalı hem de yönetilemez hale gelir. Gruplar bu sorunu çözer.

# Geliştirici grubu oluşturma
aws iam create-group --group-name Developers

# Kullanıcıyı gruba ekleme
aws iam add-user-to-group 
  --user-name ali.yilmaz 
  --group-name Developers

# Gruba politika ekleme
aws iam attach-group-policy 
  --group-name Developers 
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess

Roles (Roller)

Roller, IAM’in en güçlü özelliğidir. İnsan kullanıcılar için değil, AWS servisleri veya uygulamalar için tasarlanmıştır. Access key yoktur, geçici credential üretilir.

Policies (Politikalar)

Politikalar JSON formatında yazılır ve kimin neye erişebileceğini tanımlar. Her politika Statement’lardan oluşur ve her Statement şu bileşenleri içerir:

  • Effect: Allow veya Deny
  • Action: Hangi AWS işlemleri
  • Resource: Hangi kaynaklar üzerinde
  • Condition: Hangi koşullarda (opsiyonel)

En Az Ayrıcalık İlkesi (Least Privilege)

Bu ilke IAM’in kalbidir. Bir kullanıcı veya servis, görevini yapmak için gereken minimum yetkiye sahip olmalıdır. “Her şeyi ver, sonra kısarız” yaklaşımı felakete davetiye çıkarır.

Kötü örnek: Bir uygulamaya AdministratorAccess vermek.

İyi örnek: Sadece ihtiyacı olan S3 bucket’a okuma/yazma yetkisi vermek.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "S3BucketAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::uygulama-bucket-prod/*"
      ]
    },
    {
      "Sid": "S3ListBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::uygulama-bucket-prod"
    }
  ]
}
# Özel politika oluşturma
aws iam create-policy 
  --policy-name S3AppBucketPolicy 
  --policy-document file://s3-policy.json

# Politikayı role veya kullanıcıya ekleme
aws iam attach-user-policy 
  --user-name ali.yilmaz 
  --policy-arn arn:aws:iam::123456789012:policy/S3AppBucketPolicy

IAM Rollerini Doğru Kullanmak

Roller, özellikle EC2 instance’ları, Lambda fonksiyonları ve diğer AWS servisleri için kritiktir. Uygulama sunucunuza access key hardcode etmek yerine instance role kullanın.

EC2 Instance Role Oluşturma

Önce role için trust policy hazırlayın. Bu dosya, EC2’nun bu rolü üstlenebileceğini söyler:

# Trust policy dosyası oluşturma
cat > ec2-trust-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

# Role oluşturma
aws iam create-role 
  --role-name EC2AppRole 
  --assume-role-policy-document file://ec2-trust-policy.json

# Role'a politika ekleme
aws iam attach-role-policy 
  --role-name EC2AppRole 
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# Instance profile oluşturma ve role ekleme
aws iam create-instance-profile 
  --instance-profile-name EC2AppProfile

aws iam add-role-to-instance-profile 
  --instance-profile-name EC2AppProfile 
  --role-name EC2AppRole

Artık EC2 instance’ınız bu profille başlatıldığında, instance metadata üzerinden geçici credential alır. Hiçbir yerde access key saklanmaz.

MFA Zorunluluğu

MFA (Multi-Factor Authentication) olmadan IAM güvenliği yarım kalır. Root account ve tüm admin kullanıcılar için MFA kesinlikle zorunlu olmalı.

# Kullanıcının MFA cihazlarını listeleme
aws iam list-mfa-devices --user-name ali.yilmaz

# MFA zorunlu olmadan erişimi engelleyen politika
cat > require-mfa-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyWithoutMFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}
EOF

Bu politikayı tüm kullanıcılara uygulayan gruba eklerseniz, MFA olmadan kimse kritik işlem yapamaz.

Gerçek Dünya Senaryosu: Ortam Bazlı Erişim Kontrolü

Çoğu şirkette dev, staging ve production ortamları bulunur. Her ortama erişim farklı seviyelerde olmalıdır.

# Production'a sadece okuma yetkisi veren politika
cat > prod-readonly-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EC2ReadOnly",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "ec2:Get*"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "eu-west-1"
        }
      }
    },
    {
      "Sid": "DenyProductionWrite",
      "Effect": "Deny",
      "Action": [
        "ec2:RunInstances",
        "ec2:TerminateInstances",
        "ec2:StopInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Environment": "production"
        }
      }
    }
  ]
}
EOF

Grupları şu şekilde organize etmek mantıklıdır:

  • DevTeam: Dev ortamına tam erişim, staging’e okuma, production’a erişim yok
  • DevOpsTeam: Her ortama erişim, production’da değişiklik için MFA zorunlu
  • ReadOnlyTeam: Tüm ortamlarda sadece okuma
  • AdminTeam: Tam erişim, MFA zorunlu, IP kısıtlaması var

Access Key Yönetimi

Access key’ler en büyük güvenlik risklerinden biridir. Bunları yönetmek için birkaç kritik kural var.

# Tüm kullanıcıların access key yaşını kontrol etme
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d

# Belirli bir kullanıcının access key'lerini listeleme
aws iam list-access-keys --user-name ali.yilmaz

# 90 günden eski key'leri bulmak için script
aws iam list-users --query 'Users[*].UserName' --output text | 
  tr 't' 'n' | while read user; do
    aws iam list-access-keys --user-name "$user" 
      --query "AccessKeyMetadata[?CreateDate<='$(date -d '90 days ago' --iso-8601)'].{User:'$user',KeyId:AccessKeyId,Status:Status}" 
      --output table 2>/dev/null
  done

# Eski key'i devre dışı bırakma
aws iam update-access-key 
  --user-name ali.yilmaz 
  --access-key-id AKIAIOSFODNN7EXAMPLE 
  --status Inactive

# Key rotasyonu: Yeni key oluştur, eski key'i sil
aws iam create-access-key --user-name ali.yilmaz
aws iam delete-access-key 
  --user-name ali.yilmaz 
  --access-key-id AKIAIOSFODNN7EXAMPLE

Access key yönetimi için temel kurallar:

  • 90 gün kuralı: Access key’leri her 90 günde bir rotate edin
  • Kod içinde asla: Key’leri kaynak kodda, config dosyasında saklamayın
  • Secrets Manager kullanın: Key’leri AWS Secrets Manager’da tutun
  • CloudTrail’i aktif edin: Her key kullanımını loglayın
  • Root key kullanmayın: Root account’un access key’i olmamalı

IAM Policy Simulator ile Test

Politikaları production’a atmadan önce test etmek hayat kurtarır.

# Policy Simulator CLI ile test
aws iam simulate-principal-policy 
  --policy-source-arn arn:aws:iam::123456789012:user/ali.yilmaz 
  --action-names s3:GetObject s3:PutObject 
  --resource-arns arn:aws:s3:::uygulama-bucket-prod/*

# Birden fazla aksiyon test etme
aws iam simulate-principal-policy 
  --policy-source-arn arn:aws:iam::123456789012:role/EC2AppRole 
  --action-names 
    ec2:DescribeInstances 
    ec2:StartInstances 
    ec2:TerminateInstances 
  --resource-arns "*"

Çıktı her aksiyon için allowed veya explicitDeny / implicitDeny gösterir. Bir politika değişikliği yapmadan önce bu komutu çalıştırma alışkanlığı edinin.

Service Control Policies ile Organizasyon Güvenliği

Eğer AWS Organizations kullanıyorsanız, SCP’ler (Service Control Policies) tüm hesaplar için üst düzey politikalar belirlemenizi sağlar.

# Belirli region'ları kısıtlayan SCP
cat > restrict-regions-scp.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideEurope",
      "Effect": "Deny",
      "NotAction": [
        "cloudfront:*",
        "iam:*",
        "route53:*",
        "support:*",
        "sts:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotIn": {
          "aws:RequestedRegion": [
            "eu-west-1",
            "eu-central-1",
            "eu-west-3"
          ]
        }
      }
    }
  ]
}
EOF

# SCP oluşturma
aws organizations create-policy 
  --name "RestrictToEurope" 
  --description "Only European regions allowed" 
  --content file://restrict-regions-scp.json 
  --type SERVICE_CONTROL_POLICY

SCP, hesap içindeki root user dahil hiç kimsenin bu kısıtlamayı aşamamasını sağlar. Compliance gereksinimleri olan (GDPR gibi) organizasyonlar için çok değerlidir.

CloudTrail ile IAM Aktivitelerini İzleme

Kim ne yaptı sorusunun cevabı CloudTrail’de.

# Son 24 saatte IAM üzerinde yapılan değişiklikleri bulma
aws cloudtrail lookup-events 
  --lookup-attributes AttributeKey=EventSource,AttributeValue=iam.amazonaws.com 
  --start-time $(date -d '24 hours ago' --iso-8601=seconds) 
  --query 'Events[*].{Time:EventTime,User:Username,Event:EventName}' 
  --output table

# Başarısız login denemelerini bulma
aws cloudtrail lookup-events 
  --lookup-attributes AttributeKey=EventName,AttributeValue=ConsoleLogin 
  --query 'Events[?contains(CloudTrailEvent, `"responseElements":{"ConsoleLogin":"Failure"}`)].{Time:EventTime,User:Username}' 
  --output table

# Belirli bir kullanıcının aktivitelerini izleme
aws cloudtrail lookup-events 
  --lookup-attributes AttributeKey=Username,AttributeValue=ali.yilmaz 
  --start-time $(date -d '7 days ago' --iso-8601=seconds) 
  --query 'Events[*].{Time:EventTime,Event:EventName,Source:EventSource}' 
  --output table

CloudTrail loglarını S3’e aktarıp Athena ile sorgulamak çok daha güçlü analiz imkanı sağlar. Bunu mutlaka bir sonraki adımınız yapın.

IAM Güvenlik Değerlendirmesi

Mevcut hesabınızın güvenlik durumunu hızlıca değerlendirmek için bu kontrolleri yapın.

# IAM credential report oluştur ve analiz et
aws iam generate-credential-report
sleep 5
aws iam get-credential-report 
  --query 'Content' 
  --output text | base64 -d > credential-report.csv

# Root account MFA kontrolü
aws iam get-account-summary 
  --query 'SummaryMap.AccountMFAEnabled'

# Inline policy olan kullanıcıları bul (kötü pratik)
aws iam list-users --query 'Users[*].UserName' --output text | 
  tr 't' 'n' | while read user; do
    count=$(aws iam list-user-policies --user-name "$user" 
      --query 'length(PolicyNames)' --output text)
    if [ "$count" -gt "0" ]; then
      echo "UYARI: $user kullanıcısının inline policy'si var"
    fi
  done

# Console erişimi olan ama MFA'sı olmayan kullanıcıları bul
aws iam get-credential-report 
  --query 'Content' --output text | base64 -d | 
  awk -F',' 'NR>1 && $4=="true" && $8=="false" {print "MFA yok: " $1}'

Pratik IAM Güvenlik Kontrol Listesi

Sistemlerinizi değerlendirirken şu başlıkları gözden geçirin:

  • Root account: Access key silinmiş olmalı, MFA aktif olmalı, günlük kullanımda kullanılmamalı
  • Password policy: Min 14 karakter, büyük/küçük harf, sayı, özel karakter zorunlu, 90 günde expire
  • MFA: Admin ve hassas role sahip tüm kullanıcılarda zorunlu
  • Access key rotasyonu: 90 günden eski key yoktu olmamalı
  • Kullanılmayan kullanıcılar: 90 gündür login olmayan kullanıcılar disable edilmeli
  • Inline policies: Kullanmayın, managed policy tercih edin
  • Wildcard actions: "Action": "*" yazmaktan kaçının
  • CloudTrail: Tüm region’larda aktif, S3’e loglanıyor olmalı
  • IAM Access Analyzer: Dış erişime açık kaynakları tespit etmek için aktif olmalı

Sonuç

AWS IAM, bulut güvenliğinin temel taşıdır ve doğru yapılandırılmadan diğer tüm güvenlik önlemleri yetersiz kalır. Yazıda ele aldığımız konuların özeti şöyle:

En az ayrıcalık ilkesini her zaman uygulayın. Birisine “şimdilik admin verelim, sonra düzeltiriz” yaklaşımı sonra hiç düzeltilmiyor. Rolleri servislerin kimlik yönetimi için kullanın ve access key’leri koddan uzak tutun. MFA’yı opsiyonel değil zorunlu yapın. CloudTrail ile her hareketi kaydedin ve düzenli olarak inceleyin.

IAM yapılandırması tek seferlik bir iş değildir. Hesabınız büyüdükçe, ekibiniz değiştikçe, yeni servisler ekledikçe IAM politikalarınızı gözden geçirmeniz gerekir. Bunu aylık rutin kontrollerinize ekleyin.

Güvenlik her zaman kullanım kolaylığıyla bir denge içindedir ama bulut ortamında bu dengeyi güvenlik lehine kurmak uzun vadede çok daha az baş ağrısı demektir. 47.000 dolarlık o fatura, o şirketin IAM’e bir daha asla kayıtsız kalmayacağının garantisidir. Umarım siz o dersi başkasının deneyiminden öğrenirsiniz.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir