Bulut Güvenliği için CIS Benchmark Uygulaması

Bulut ortamlarında güvenliği sağlamak, on-premise sistemlere kıyasla çok daha karmaşık bir hal alıyor. Kaynaklar dinamik olarak oluşup yok oluyor, erişim politikaları çakışıyor ve konfigürasyon hataları dakikalar içinde milyonlarca kaydın sızmasına neden olabiliyor. İşte bu noktada CIS (Center for Internet Security) Benchmark’ları devreye giriyor. CIS Benchmark, bulut ortamları için sektörde kabul görmüş, somut ve uygulanabilir güvenlik standartları sunuyor. Bu yazıda AWS, Azure ve GCP üzerinde CIS Benchmark uygulamasını gerçek dünya senaryolarıyla ele alacağız.

CIS Benchmark Nedir ve Neden Önemlidir?

CIS Benchmark’lar, güvenlik uzmanları, sistem yöneticileri ve kurumsal kullanıcılar tarafından oluşturulan konsensüs tabanlı kılavuzlardır. Her büyük bulut sağlayıcısı için ayrı Benchmark dökümanları mevcut. Önemli olan nokta şu: bu kılavuzlar teorik değil, sahada test edilmiş ve uygulanabilir kontroller içeriyor.

CIS kontrolleri iki seviyeye ayrılıyor:

  • Level 1: Temel güvenlik önlemleri, production ortamlarda hemen uygulanabilir
  • Level 2: Daha katı güvenlik gereksinimleri, yüksek güvenlik ihtiyacı olan ortamlar için

Bir finans şirketinde çalışırken PCI-DSS uyumluluğu için CIS Benchmark uygulamak zorunda kaldım. Başlangıçta “bu kadar konfigürasyon değişikliği sistemi bozar” diye itiraz eden meslektaşlarım vardı. Ama sistematik bir şekilde ilerlediğimizde, hem uyumluluk hedeflerine ulaştık hem de gerçek güvenlik açıklarını kapattık.

AWS CIS Benchmark Uygulaması

IAM Güvenliği

AWS CIS Benchmark’ın en kritik bölümü IAM yapılandırmasıdır. Root hesabın günlük kullanımını engellemek, MFA zorunlu kılmak ve şifre politikalarını sıkılaştırmak ilk adımlar.

# Root hesabın MFA durumunu kontrol et
aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled'

# Tüm IAM kullanıcılarının MFA durumunu listele
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d | 
  awk -F',' 'NR>1 {print $1, $8, $9}'

# Şifre politikasını CIS uyumlu hale getir
aws iam update-account-password-policy 
  --minimum-password-length 14 
  --require-symbols 
  --require-numbers 
  --require-uppercase-characters 
  --require-lowercase-characters 
  --allow-users-to-change-password 
  --max-password-age 90 
  --password-reuse-prevention 24 
  --hard-expiry

Pratikte karşılaştığım en yaygın sorun şu: şirketler onlarca IAM kullanıcısı oluşturmuş ama hiçbirinin erişim anahtarlarını rotate etmemiş. 90 günden eski anahtarları tespit etmek için şu scripti kullanıyorum:

#!/bin/bash
# 90 günden eski access key'leri tespit et
THRESHOLD=90
TODAY=$(date +%s)

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[?Status==`Active`].[UserName,AccessKeyId,CreateDate]' 
    --output text | while read LINE; do
      USERNAME=$(echo $LINE | awk '{print $1}')
      KEY_ID=$(echo $LINE | awk '{print $2}')
      CREATE_DATE=$(echo $LINE | awk '{print $3}')
      KEY_AGE=$(( ($TODAY - $(date -d "$CREATE_DATE" +%s)) / 86400 ))
      
      if [ $KEY_AGE -gt $THRESHOLD ]; then
        echo "ESKI ANAHTAR: Kullanici=$USERNAME, KeyID=$KEY_ID, Yas=${KEY_AGE} gun"
      fi
  done
done

CloudTrail ve Loglama Konfigürasyonu

CIS Benchmark, tüm bölgelerde CloudTrail’in aktif olmasını şart koşuyor. Bunu manuel kontrol etmek yerine otomatize etmek gerekiyor.

# Tüm bölgelerde CloudTrail durumunu kontrol et
for REGION in $(aws ec2 describe-regions --query 'Regions[*].RegionName' --output text); do
  STATUS=$(aws cloudtrail get-trail-status 
    --name default 
    --region $REGION 
    --query 'IsLogging' 
    --output text 2>/dev/null || echo "TRAIL_YOK")
  echo "Bolge: $REGION - CloudTrail: $STATUS"
done

# S3 bucket log dosyası doğrulama hash kontrolü
aws cloudtrail validate-logs 
  --trail-arn arn:aws:cloudtrail:us-east-1:123456789:trail/management-events 
  --start-time 2024-01-01 
  --end-time 2024-01-31

S3 Bucket Güvenliği

Gerçek hayatta gördüğüm en tehlikeli durum: public S3 bucket’lar. Bir müşterinin audit’ini yaparken 47 bucket’tan 12’sinin public erişime açık olduğunu tespit ettim. CIS Benchmark bu konuda çok nettir.

# Tüm S3 bucket'larının public erişim durumunu kontrol et
aws s3api list-buckets --query 'Buckets[*].Name' --output text | tr 't' 'n' | while read BUCKET; do
  PUBLIC_STATUS=$(aws s3api get-public-access-block 
    --bucket "$BUCKET" 
    --query 'PublicAccessBlockConfiguration' 
    --output json 2>/dev/null)
  
  if echo "$PUBLIC_STATUS" | grep -q '"BlockPublicAcls": false|"IgnorePublicAcls": false'; then
    echo "DIKKAT - Public erisim acik olabilir: $BUCKET"
  fi
  
  # Bucket ACL kontrolü
  ACL=$(aws s3api get-bucket-acl --bucket "$BUCKET" 
    --query 'Grants[?Grantee.URI==`http://acs.amazonaws.com/groups/global/AllUsers`]' 
    --output text)
  
  if [ ! -z "$ACL" ]; then
    echo "KRITIK - Herkese acik ACL: $BUCKET"
  fi
done

# Tüm hesap genelinde public erişimi kapat
aws s3control put-public-access-block 
  --account-id $(aws sts get-caller-identity --query Account --output text) 
  --public-access-block-configuration 
    BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Azure CIS Benchmark Uygulaması

Azure Security Center Konfigürasyonu

Azure’da CIS Benchmark uygulaması için Microsoft Defender for Cloud (eski adıyla Security Center) kullanmak en verimli yol. Ancak Defender for Cloud’u aktif etmek tek başına yeterli değil, doğru politikaları atamanız gerekiyor.

# Azure CLI ile CIS Benchmark politika girişimini ata
SUBSCRIPTION_ID=$(az account show --query id --output tsv)

# CIS Microsoft Azure Foundations Benchmark politikasını ata
az policy assignment create 
  --name "cis-azure-benchmark" 
  --display-name "CIS Azure Foundations Benchmark" 
  --policy-set-definition "/providers/Microsoft.Authorization/policySetDefinitions/1a5bb27d-173f-493e-9568-eb56638dde4d" 
  --scope "/subscriptions/$SUBSCRIPTION_ID" 
  --enforcement-mode Default

# Uyumluluk durumunu sorgula
az policy state summarize 
  --subscription $SUBSCRIPTION_ID 
  --query 'results.policyDetails[*].{Policy:policyDefinitionId,Compliant:results.compliantResources,NonCompliant:results.nonCompliantResources}' 
  --output table

Azure Active Directory MFA ve Conditional Access

Azure CIS Benchmark’ın en önemli gereksinimlerinden biri, özellikle ayrıcalıklı hesaplar için MFA zorunluluğu. PowerShell ile mevcut durumu hızlıca analiz edebilirsiniz.

# Azure AD MFA durumunu kontrol et (Azure CLI)
# Önce MS Graph API modülünü kur
az extension add --name account

# Tüm Global Admin rolündeki kullanıcıları listele
az role assignment list 
  --all 
  --query "[?roleDefinitionName=='Owner' || roleDefinitionName=='Contributor'].{User:principalName,Role:roleDefinitionName,Scope:scope}" 
  --output table

# Storage account'larda HTTPS zorunluluğunu kontrol et
az storage account list 
  --query "[?enableHttpsTrafficOnly==false].{Name:name,ResourceGroup:resourceGroup,HTTPSOnly:enableHttpsTrafficOnly}" 
  --output table

# HTTPS zorunluluğunu tüm storage account'lara uygula
az storage account list --query '[*].{name:name,rg:resourceGroup}' --output tsv | 
  while IFS=$'t' read -r NAME RG; do
    az storage account update 
      --name "$NAME" 
      --resource-group "$RG" 
      --https-only true
    echo "Guncellendi: $NAME"
  done

GCP CIS Benchmark Uygulaması

GCP’de CIS Benchmark uygulaması, Organization Policy’leri ve Cloud Security Command Center (SCC) üzerinden yönetilir. Google’ın CIS Benchmark’ı özellikle IAM ve logging konularında çok detaylı kontroller içeriyor.

# GCP Organization Policy CIS kontrolü
PROJECT_ID=$(gcloud config get-value project)

# Uniform bucket-level access kontrolü
gsutil ls | while read BUCKET; do
  UNIFORM=$(gsutil uniformbucketlevelaccess get $BUCKET 2>/dev/null | grep "Enabled")
  if [ -z "$UNIFORM" ]; then
    echo "Uniform bucket-level access kapali: $BUCKET"
    # Etkinleştir
    gsutil uniformbucketlevelaccess set on $BUCKET
  fi
done

# Cloud Audit Logs durumunu kontrol et
gcloud projects get-iam-policy $PROJECT_ID 
  --flatten="auditConfigs[].auditLogConfigs" 
  --format="table(auditConfigs.service,auditConfigs.auditLogConfigs.logType)"

# Tüm servisler için DATA_READ ve DATA_WRITE loglarını aktif et
cat > audit_config.json << 'EOF'
{
  "auditConfigs": [
    {
      "service": "allServices",
      "auditLogConfigs": [
        {"logType": "ADMIN_READ"},
        {"logType": "DATA_READ"},
        {"logType": "DATA_WRITE"}
      ]
    }
  ]
}
EOF

gcloud projects set-iam-policy $PROJECT_ID audit_config.json

Otomatik CIS Compliance Tarama Araçları

Prowler ile AWS Audit

Prowler, AWS CIS Benchmark kontrolleri için açık kaynaklı en popüler araçlardan biri. Yüzlerce kontrolü dakikalar içinde çalıştırıp raporlayabiliyor.

# Prowler kurulumu ve çalıştırma
pip3 install prowler

# Tüm CIS kontrolleri için tarama başlat
prowler aws --compliance cis_level1_aws 
  --output-formats html json csv 
  --output-directory /tmp/prowler-report 
  --log-level INFO

# Sadece kritik bulgular için filtreleme
prowler aws --compliance cis_level2_aws 
  --severity critical high 
  --output-formats json 
  --output-directory /tmp/prowler-critical

# Belirli bir kategori için tarama (IAM)
prowler aws 
  --checks iam_password_policy_number iam_password_policy_uppercase 
  iam_password_policy_lowercase iam_root_mfa_enabled 
  --output-formats csv

Prowler çıktısını bir CI/CD pipeline’ına entegre etmek pratikte çok işe yarıyor. Özellikle infrastructure değişikliklerinden önce bir güvenlik taraması yapmak, sonradan uğraşacağınız sorunları önlüyor.

Checkov ile Infrastructure as Code Taraması

Terraform veya CloudFormation şablonlarını deploy etmeden önce CIS kontrolleri açısından taramak, “shift-left security” yaklaşımının temel taşı.

# Checkov kurulumu
pip3 install checkov

# Terraform kodu üzerinde CIS taraması
checkov -d ./terraform/ 
  --framework terraform 
  --check CIS 
  --output json > checkov_report.json

# AWS CIS Benchmark'a göre spesifik kontroller
checkov -d ./cloudformation/ 
  --framework cloudformation 
  --check CKV_AWS_18,CKV_AWS_19,CKV_AWS_20 
  --compact

# Yüksek şiddetli bulguları filtrele ve raporla
checkov -d ./terraform/ 
  --framework terraform 
  --check CIS 
  --soft-fail 
  --output junitxml > checkov_junit.xml

Sürekli Uyumluluk Takibi

CIS Benchmark uygulamak tek seferlik bir iş değil. Ortam sürekli değişiyor, yeni kaynaklar ekleniyor, konfigürasyonlar güncelleniyor. Bu yüzden sürekli takip mekanizmaları kurmak şart.

#!/bin/bash
# Günlük CIS compliance özeti gönder
REPORT_DATE=$(date +%Y-%m-%d)
REPORT_FILE="/tmp/cis_daily_${REPORT_DATE}.txt"

echo "CIS Compliance Gunluk Raporu - $REPORT_DATE" > $REPORT_FILE
echo "==========================================" >> $REPORT_FILE

# Kritik kontroller
echo "## IAM Root Access Key Kontrolu" >> $REPORT_FILE
ROOT_KEY=$(aws iam get-account-summary 
  --query 'SummaryMap.AccountAccessKeysPresent' 
  --output text)
if [ "$ROOT_KEY" != "0" ]; then
  echo "KRITIK: Root hesapta aktif access key mevcut!" >> $REPORT_FILE
else
  echo "OK: Root access key yok" >> $REPORT_FILE
fi

echo "## Public S3 Bucket Kontrolu" >> $REPORT_FILE
aws s3api list-buckets --query 'Buckets[*].Name' --output text | tr 't' 'n' | while read BUCKET; do
  BLOCK=$(aws s3api get-public-access-block --bucket "$BUCKET" 2>/dev/null 
    --query 'PublicAccessBlockConfiguration.BlockPublicAcls' --output text)
  if [ "$BLOCK" != "True" ]; then
    echo "UYARI: $BUCKET - Public block aktif degil" >> $REPORT_FILE
  fi
done

echo "## VPC Flow Logs Kontrolu" >> $REPORT_FILE
aws ec2 describe-vpcs --query 'Vpcs[*].VpcId' --output text | tr 't' 'n' | while read VPC; do
  FLOW=$(aws ec2 describe-flow-logs 
    --filter "Name=resource-id,Values=$VPC" 
    --query 'FlowLogs[*].FlowLogStatus' 
    --output text)
  if [ -z "$FLOW" ]; then
    echo "UYARI: VPC $VPC icin flow log aktif degil" >> $REPORT_FILE
  fi
done

# Raporu e-posta ile gonder (aws sns üzerinden)
aws sns publish 
  --topic-arn "arn:aws:sns:us-east-1:123456789:security-alerts" 
  --subject "Gunluk CIS Compliance Raporu - $REPORT_DATE" 
  --message file://$REPORT_FILE

Yaygın Hatalar ve Çözümleri

Sahada CIS Benchmark uygularken en çok karşılaştığım sorunları paylaşmak istiyorum:

Konfigürasyon sürüklemesi (configuration drift): Güvenlik ekibi CIS uyumlu bir ortam kuruyor, ama aylarca sonra uygulama ekipleri manuel değişiklikler yapıyor ve ortam giderek uyumsuz hale geliyor. Bunun önüne geçmek için AWS Config kurallarını kullanmak gerekiyor.

# AWS Config ile CIS kural paketi deploy et
aws configservice put-config-rule 
  --config-rule '{
    "ConfigRuleName": "cis-iam-password-policy",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "IAM_PASSWORD_POLICY"
    },
    "InputParameters": "{"RequireUppercaseCharacters":"true","RequireLowercaseCharacters":"true","RequireSymbols":"true","RequireNumbers":"true","MinimumPasswordLength":"14","PasswordReusePrevention":"24","MaxPasswordAge":"90"}"
  }'

# CIS Benchmark conformance pack deploy et
aws configservice put-conformance-pack 
  --conformance-pack-name "CIS-AWS-Foundations-Benchmark" 
  --template-s3-uri "s3://aws-configservice-us-east-1/conformance-packs/Operational-Best-Practices-for-CIS-AWS-v1.4-Level1.yaml" 
  --delivery-s3-bucket "my-config-bucket"

False positive yönetimi: Prowler veya benzer araçlar bazen gerçek olmayan uyarılar üretiyor. Özellikle legacy sistemlerle çalışırken bazı kontrolleri suppress etmek gerekebiliyor. Bunları belgelemek ve periyodik review yapmak şart.

Uygulama önceliklendirmesi: 200’den fazla CIS kontrolü var. Hepsini aynı anda uygulamaya çalışmak hem zaman alıyor hem de risk taşıyor. Level 1 kontrollerinden başlayıp kritik bulguları önceliklendirmek en sağlıklı yaklaşım.

Maliyet Optimizasyonu ile Güvenliği Dengelemek

CIS Benchmark bazı kontrollerin etkinleştirilmesi ek maliyete yol açıyor. Örneğin CloudTrail loglarını tüm bölgelerde aktif etmek, S3 maliyetlerini artırıyor. Bu konuyu yöneticilere anlatırken şöyle bir yaklaşım işe yarıyor:

  • CloudTrail: Aylık birkaç dolar maliyet, ama bir incident sonrası forensic analiz yapabilmek paha biçilmez
  • VPC Flow Logs: CloudWatch yerine S3’e loglamak maliyeti ciddi ölçüde düşürüyor
  • Config Rules: Her kural değerlendirme başına ücretlendiriliyor, bu yüzden sadece kritik kaynakları izlemek maliyeti kontrol altında tutuyor
  • GuardDuty: 30 günlük ücretsiz deneme süresi var, önce pilot ortamda test etmek mantıklı

Sonuç

CIS Benchmark uygulaması, bulut güvenliğinin en temel yapı taşlarından biri. Ancak “bir kere uygula ve unut” anlayışıyla ele alınamaz. Ortamınız büyüdükçe, yeni servisler devreye girdikçe ve tehdit landscape’i değiştikçe uyumluluk durumunuz da değişiyor.

Pratik bir öneri olarak şunu söyleyebilirim: önce Prowler veya benzeri bir araçla mevcut durumu tespit edin, kritik ve yüksek şiddetteki bulguları bir backlog olarak oluşturun, ardından her sprint’e birkaç kontrol alarak ilerlemeye başlayın. AWS Config conformance pack’leri veya Azure Policy girişimleri gibi yönetilen çözümler, compliance takibini otomatize etmenin en iyi yolu.

Son olarak, CIS Benchmark’ı sadece uyumluluk için değil, gerçek güvenlik açıklarını kapatmak için kullandığınızda en büyük faydayı görürsünüz. Bir denetimden geçmek için checkbox doldurmak ile ortamınızı gerçekten güvence altına almak arasındaki fark, bu araçları nasıl kullandığınızda gizli.

Bir yanıt yazın

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