Bulut Ortamında Kimlik Federasyonu ve SSO ile Merkezi Erişim Yönetimi

Yazar:komut.io ekibi Bulut Güvenliği ve Maliyet
0 Yorum

Büyük bir şirketin BT ekibindesiniz ve her sabah onlarca farklı sistemin şifresiyle boğuşan kullanıcılardan şikayet alıyorsunuz. Biri AWS konsoluna girememiş, biri Salesforce şifresini unutmuş, biri de Jira’ya erişemiyor. Güvenlik ekibi ise ayrı bir dert: kim, ne zaman, hangi sisteme girdi? Bunları takip etmek neredeyse imkansız hale gelmiş. İşte bu kaos, kimlik federasyonu ve SSO’nun neden bu kadar kritik olduğunu en iyi anlatan gerçek dünya senaryosudur.

Kimlik Federasyonu ve SSO Nedir?

SSO (Single Sign-On), kullanıcının bir kez kimlik doğrulaması yaparak birden fazla uygulamaya erişebildiği sistemdir. Kullanıcı sabah bir kez kurumsal hesabıyla giriş yapar, gün boyu AWS, GitHub, Slack, Jira gibi onlarca uygulamaya ayrıca şifre girmeden erişir.

Kimlik Federasyonu ise bu konsepti organizasyonlar arası boyuta taşır. Bir şirketin kimlik sağlayıcısına (IdP) güvenen başka bir sistem veya organizasyonun, o şirketin kullanıcılarını kendi sistemine kabul etmesidir. Yani “sen bu kullanıcıya güveniyorsan, ben de güveniyorum” prensibiyle çalışır.

Temel bileşenler şunlardır:

  • Identity Provider (IdP): Kimlik doğrulamanın yapıldığı merkezi sistem. Okta, Azure AD, Google Workspace, Keycloak bunlara örnektir.
  • Service Provider (SP): IdP’ye güvenerek erişim sağlayan uygulama veya servis.
  • SAML 2.0: XML tabanlı kimlik federasyonu protokolü, kurumsal sistemlerde yaygındır.
  • OIDC (OpenID Connect): OAuth 2.0 üzerine inşa edilmiş modern kimlik protokolü, bulut native uygulamalarda tercih edilir.
  • OAuth 2.0: Yetkilendirme protokolü, API erişim senaryolarında kullanılır.

Neden Merkezi Kimlik Yönetimi?

Dağıtık kimlik yönetiminin maliyeti genellikle görünmez ama son derece yüksektir. Her uygulama kendi kullanıcı veritabanını yönettiğinde şu sorunlar kaçınılmaz olur:

  • Bir çalışan işten ayrıldığında onlarca sistemden manuel olarak silinmesi gerekir ve bu çoğu zaman tam yapılmaz
  • Parola politikaları her sistemde farklıdır, zayıf parola kullanan hesaplar güvenlik açığı oluşturur
  • Denetim ve uyumluluk raporları hazırlamak çok zaman alır
  • Helpdesk çağrılarının büyük çoğunluğu parola sıfırlama talepleridir

Merkezi kimlik yönetimiyle bir çalışan Active Directory veya Okta hesabı devre dışı bırakıldığında, bağlı tüm sistemlere erişimi anında kesilir. Bu, güvenlik açısından son derece kritiktir.

AWS IAM Identity Center ile Federasyon Kurulumu

AWS ortamında merkezi erişim yönetiminin en pratik yolu AWS IAM Identity Center (eski adıyla AWS SSO) kullanmaktır. Birden fazla AWS hesabını tek noktadan yönetmenizi sağlar.

Önce AWS CLI ile IAM Identity Center’ı yapılandıralım:

# AWS Organizations'da IAM Identity Center'ı etkinleştir
aws sso-admin create-account-assignment 
  --instance-arn "arn:aws:sso:::instance/ssoins-xxxxxxxxx" 
  --target-id "123456789012" 
  --target-type "AWS_ACCOUNT" 
  --permission-set-arn "arn:aws:sso:::permissionSet/ssoins-xxxxxxxxx/ps-xxxxxxxxx" 
  --principal-type "GROUP" 
  --principal-id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

# Mevcut permission set'leri listele
aws sso-admin list-permission-sets 
  --instance-arn "arn:aws:sso:::instance/ssoins-xxxxxxxxx"

Permission set oluşturmak için:

# Yeni permission set oluştur
aws sso-admin create-permission-set 
  --instance-arn "arn:aws:sso:::instance/ssoins-xxxxxxxxx" 
  --name "DevOps-ReadOnly" 
  --description "DevOps ekibi için salt okunur erişim" 
  --session-duration "PT8H"

# Permission set'e AWS managed policy ekle
aws sso-admin attach-managed-policy-to-permission-set 
  --instance-arn "arn:aws:sso:::instance/ssoins-xxxxxxxxx" 
  --permission-set-arn "arn:aws:sso:::permissionSet/ssoins-xxxxxxxxx/ps-xxxxxxxxx" 
  --managed-policy-arn "arn:aws:iam::aws:policy/ReadOnlyAccess"

Azure AD ile SAML Federasyonu

Birçok kurumda Active Directory zaten var ve bunu buluta taşımak için Azure AD en doğal seçimdir. Azure AD’yi IdP olarak kullanarak AWS, GitHub Enterprise veya herhangi bir SAML destekleyen uygulamaya federasyon kurabilirsiniz.

Azure AD’de enterprise application oluştururken PowerShell kullanımı:

# Azure CLI ile SAML uygulaması yapılandırma
az ad app create 
  --display-name "AWS-SSO-Federation" 
  --sign-in-audience "AzureADMyOrg" 
  --web-redirect-uris "https://signin.aws.amazon.com/saml"

# Service Principal oluştur
az ad sp create --id <app-id>

# SAML token imzalama sertifikasını dışa aktar
az ad app credential list --id <app-id>

Azure AD ile AWS arasında federasyon kurulduktan sonra kullanıcılar Azure AD kimlik bilgileriyle AWS konsoluna giriş yapabilir. Bu noktada şunu vurgulamak gerekir: Azure AD’deki gruplar, AWS tarafında permission set’lere eşlenir. HR sisteminde bir kullanıcı “DevOps” grubundan çıkarıldığında, AWS erişimi otomatik olarak kesilir.

Keycloak ile Self-Hosted IdP Kurulumu

Bazı organizasyonlar veri gizliliği veya düzenleyici gereksinimler nedeniyle kendi IdP’lerini çalıştırmak ister. Keycloak bu durumda açık kaynak ve kurumsal düzeyde bir çözüm sunar.

Docker Compose ile Keycloak kurulumu:

# docker-compose.yml oluştur
cat > docker-compose.yml << 'EOF'
version: '3.8'
services:
  keycloak-db:
    image: postgres:15
    environment:
      POSTGRES_DB: keycloak
      POSTGRES_USER: keycloak
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - keycloak_db_data:/var/lib/postgresql/data

  keycloak:
    image: quay.io/keycloak/keycloak:23.0
    command: start
    environment:
      KC_HOSTNAME: auth.sirketiniz.com
      KC_HOSTNAME_STRICT: false
      KC_DB: postgres
      KC_DB_URL: jdbc:postgresql://keycloak-db/keycloak
      KC_DB_USERNAME: keycloak
      KC_DB_PASSWORD: ${DB_PASSWORD}
      KEYCLOAK_ADMIN: admin
      KEYCLOAK_ADMIN_PASSWORD: ${ADMIN_PASSWORD}
      KC_PROXY: edge
      KC_HTTP_ENABLED: true
    ports:
      - "8080:8080"
    depends_on:
      - keycloak-db

volumes:
  keycloak_db_data:
EOF

# Servisi başlat
docker compose up -d

# Log'ları kontrol et
docker compose logs -f keycloak

Keycloak’ta realm ve client yapılandırmasını Keycloak Admin CLI ile otomatize edebilirsiniz:

# Keycloak Admin CLI ile token al
TOKEN=$(curl -s -X POST 
  "https://auth.sirketiniz.com/realms/master/protocol/openid-connect/token" 
  -H "Content-Type: application/x-www-form-urlencoded" 
  -d "username=admin&password=${ADMIN_PASSWORD}&grant_type=password&client_id=admin-cli" 
  | jq -r '.access_token')

# Yeni realm oluştur
curl -s -X POST 
  "https://auth.sirketiniz.com/admin/realms" 
  -H "Authorization: Bearer ${TOKEN}" 
  -H "Content-Type: application/json" 
  -d '{
    "realm": "sirket-realm",
    "enabled": true,
    "displayName": "Şirket Kimlik Yönetimi",
    "registrationAllowed": false,
    "loginWithEmailAllowed": true,
    "bruteForceProtected": true,
    "permanentLockout": false,
    "maxFailureWaitSeconds": 900,
    "minimumQuickLoginWaitSeconds": 60,
    "waitIncrementSeconds": 60,
    "quickLoginCheckMilliSeconds": 1000,
    "maxDeltaTimeSeconds": 43200,
    "failureFactor": 5
  }'

Terraform ile Kimlik Altyapısını Kodlamak

Kimlik altyapısını manuel kurmak hem hata riskini artırır hem de tekrarlanabilirliği engeller. Infrastructure as Code yaklaşımı bu noktada devreye girer.

# Okta Terraform provider ile grup ve uygulama tanımı
cat > okta_sso.tf << 'EOF'
terraform {
  required_providers {
    okta = {
      source  = "okta/okta"
      version = "~> 4.0"
    }
  }
}

provider "okta" {
  org_name  = var.okta_org_name
  base_url  = "okta.com"
  api_token = var.okta_api_token
}

# DevOps grubu oluştur
resource "okta_group" "devops" {
  name        = "devops-engineers"
  description = "DevOps mühendisleri grubu"
}

# AWS SSO uygulamasını tanımla
resource "okta_app_saml" "aws_sso" {
  label             = "AWS-SSO"
  sso_url           = "https://signin.aws.amazon.com/saml"
  recipient         = "https://signin.aws.amazon.com/saml"
  destination       = "https://signin.aws.amazon.com/saml"
  audience          = "https://signin.aws.amazon.com/saml"
  subject_name_id_template = "$${user.email}"
  subject_name_id_format   = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
  response_signed   = true
  signature_algorithm = "RSA_SHA256"
  digest_algorithm    = "SHA256"
  honor_force_authn   = false
  authn_context_class_ref = "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"
}

# Gruba uygulama erişimi ver
resource "okta_app_group_assignment" "devops_aws" {
  app_id   = okta_app_saml.aws_sso.id
  group_id = okta_group.devops.id
}
EOF

terraform init
terraform plan
terraform apply

OIDC ile Modern Uygulama Entegrasyonu

SAML kurumsal sistemlerde hakimiyetini korusa da modern bulut native uygulamalar OIDC’yi tercih eder. Özellikle Kubernetes ve container ortamlarında OIDC entegrasyonu kritik bir konudur.

Kubernetes’te OIDC tabanlı kimlik doğrulama yapılandırması:

# kube-apiserver OIDC parametreleri (kubeadm kullanıyorsanız)
# /etc/kubernetes/manifests/kube-apiserver.yaml dosyasına eklenecek
cat > oidc-config-patch.yaml << 'EOF'
spec:
  containers:
  - name: kube-apiserver
    command:
    - kube-apiserver
    - --oidc-issuer-url=https://auth.sirketiniz.com/realms/sirket-realm
    - --oidc-client-id=kubernetes
    - --oidc-username-claim=email
    - --oidc-username-prefix=oidc:
    - --oidc-groups-claim=groups
    - --oidc-groups-prefix=oidc:
EOF

# kubectl ile OIDC token kullanımı
# kubelogin plugin kurulumu
curl -Lo kubelogin.tar.gz 
  https://github.com/int128/kubelogin/releases/latest/download/kubelogin_linux_amd64.tar.gz
tar xzf kubelogin.tar.gz
sudo mv kubelogin /usr/local/bin/kubectl-oidc_login

# kubeconfig'e OIDC kullanıcısı ekle
kubectl config set-credentials oidc-user 
  --exec-api-version=client.authentication.k8s.io/v1beta1 
  --exec-command=kubectl 
  --exec-arg=oidc-login 
  --exec-arg=get-token 
  --exec-arg=--oidc-issuer-url=https://auth.sirketiniz.com/realms/sirket-realm 
  --exec-arg=--oidc-client-id=kubernetes 
  --exec-arg=--oidc-client-secret=${CLIENT_SECRET}

# OIDC grubuna Kubernetes RBAC ile yetki ver
kubectl create clusterrolebinding devops-cluster-admin 
  --clusterrole=cluster-admin 
  --group=oidc:devops-engineers

Gerçek Dünya Senaryosu: Çalışan Ayrılma Süreci

Bir çalışanın işten ayrıldığını düşünelim. Eskiden bu süreç şöyle işliyordu: IT’ye bir mail gelir, IT teker teker her sistemden hesabı kapatmaya çalışır, birkaç sistem mutlaka unutulurdu. Merkezi kimlik yönetimiyle bu süreç dakikalar içinde tamamlanır.

# Azure AD üzerinden kullanıcıyı devre dışı bırakma scripti
#!/bin/bash

AYRILAN_KULLANICI="[email protected]"

# Azure CLI ile kullanıcıyı devre dışı bırak
az ad user update 
  --id "${AYRILAN_KULLANICI}" 
  --account-enabled false

# Aktif oturumları sonlandır
USER_ID=$(az ad user show --id "${AYRILAN_KULLANICI}" --query id -o tsv)

az rest 
  --method POST 
  --url "https://graph.microsoft.com/v1.0/users/${USER_ID}/revokeSignInSessions"

# Tüm uygulama erişimlerini logla
echo "$(date): ${AYRILAN_KULLANICI} hesabı devre dışı bırakıldı" >> /var/log/offboarding.log

# Slack bildirimi gönder (opsiyonel)
curl -s -X POST "${SLACK_WEBHOOK_URL}" 
  -H "Content-Type: application/json" 
  -d "{"text": "🔒 ${AYRILAN_KULLANICI} hesabı devre dışı bırakıldı. Tüm federe sistemlere erişimi kesildi."}"

echo "İşlem tamamlandı. Kullanıcının tüm federe sistem erişimleri kesildi."

Bu script çalıştıktan sonra kullanıcı; AWS, GitHub Enterprise, Jira, Confluence, Salesforce ve diğer tüm SAML/OIDC entegreli sistemlere erişemez hale gelir. Çünkü bu sistemler, her oturum açma girişiminde IdP’ye sorar ve IdP “bu hesap devre dışı” yanıtı döner.

MFA ve Koşullu Erişim Politikaları

SSO’nun güçlü taraflarından biri MFA’yı merkezi olarak zorunlu kılmaktır. Her uygulamaya ayrı MFA eklemek yerine IdP seviyesinde yapılandırırsınız.

Yaygın koşullu erişim senaryoları:

  • Konum bazlı kısıtlama: Türkiye dışından gelen oturum açma girişimlerinde ek doğrulama veya engelleme
  • Cihaz uyumluluk kontrolü: Sadece kurumsal MDM’e kayıtlı cihazlardan erişime izin verme
  • Risk tabanlı kimlik doğrulama: Alışılmadık saatte veya konumdan giriş yapılırsa MFA’yı zorunlu kılma
  • Uygulama hassasiyeti: Finans sistemlerine erişimde her zaman MFA, düşük öncelikli uygulamalarda duruma göre MFA

Azure AD Conditional Access politikası örneği:

# Azure CLI ile conditional access politikası oluşturma
az rest 
  --method POST 
  --url "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" 
  --headers "Content-Type=application/json" 
  --body '{
    "displayName": "Yurt disi erisim - MFA zorunlu",
    "state": "enabled",
    "conditions": {
      "users": {
        "includeGroups": ["all-employees-group-id"]
      },
      "applications": {
        "includeApplications": ["All"]
      },
      "locations": {
        "includeLocations": ["All"],
        "excludeLocations": ["turkiye-named-location-id"]
      }
    },
    "grantControls": {
      "operator": "OR",
      "builtInControls": ["mfa"]
    }
  }'

Denetim ve Uyumluluk

Merkezi kimlik yönetiminin en büyük faydalarından biri denetim kolaylığıdır. Kim, ne zaman, hangi uygulamaya, hangi cihazdan giriş yaptı? Bu soruların yanıtları tek bir merkezde toplanır.

# Azure AD sign-in loglarını sorgulama
az monitor activity-log list 
  --start-time "2024-01-01T00:00:00Z" 
  --end-time "2024-01-31T23:59:59Z" 
  --query "[?contains(operationName.value, 'Sign-in')]" 
  --output table

# AWS CloudTrail ile IAM Identity Center aktivitelerini sorgula
aws cloudtrail lookup-events 
  --lookup-attributes AttributeKey=EventSource,AttributeValue=sso.amazonaws.com 
  --start-time "2024-01-01" 
  --end-time "2024-01-31" 
  --query 'Events[*].{Zaman:EventTime, Kullanici:Username, Eylem:EventName}' 
  --output table

Sık Yapılan Hatalar

Kimlik federasyonu projelerinde en çok karşılaşılan sorunlar şunlardır:

  • Token süresi yanlış ayarlamak: Çok kısa token süresi kullanıcı deneyimini bozar, çok uzun süre güvenlik riskidir. 8 saatlik iş günü için 8 saatlik session süresi makul bir başlangıçtır.
  • Grup senkronizasyonunu ihmal etmek: IdP’deki grup değişikliklerinin SP’ye yansıması gecikebilir. JIT (Just-In-Time) provisioning yapılandırmasını kontrol edin.
  • Fallback mekanizması olmamak: IdP çöktüğünde hiç kimse sisteme giremez. Acil durum hesapları ve prosedürleri önceden belirleyin.
  • Sertifika yenilemeyi unutmak: SAML imzalama sertifikası sona erdiğinde tüm federasyon durur. Sertifika yenileme sürecini ve takvimini belgelendirin.
  • Sadece Happy Path’i test etmek: Hesap devre dışı bırakma, grup değişikliği, parola sıfırlama gibi senaryoları da mutlaka test edin.

Sonuç

Kimlik federasyonu ve SSO, modern bulut altyapısının temel taşlarından biridir. Doğru kurulduğunda kullanıcı deneyimini iyileştirir, güvenliği artırır, operasyonel yükü azaltır ve uyumluluk gereksinimlerini karşılamayı kolaylaştırır.

Nereden başlayacaksınız? Önce mevcut durumu belgeleyin: kaç farklı kimlik deposu var, hangi uygulamalar IdP entegrasyonunu destekliyor, güvenlik ekibinin öncelikleri neler? Küçük başlayın; bir pilot grup ve birkaç uygulama ile başlayıp başarıyı kanıtladıktan sonra genişletin.

Unutmayın, kimlik altyapısı bir kez kurulup unutulan bir şey değildir. Düzenli gözden geçirme, sertifika takibi ve kullanılmayan erişimlerin temizlenmesi bu altyapının sağlıklı çalışması için şarttır. Ama tüm bu çabaya değer; çünkü iyi bir kimlik yönetim sistemi hem güvenlik ekibini hem de son kullanıcıları mutlu eden nadir çözümlerden biridir.

Bir yanıt yazın

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