Kimlik ve Erişim Yönetimi

Kısa Özet

IAM, kimin neye, hangi koşullar altında ve nasıl kontrol edildiğine erişmesini sağlayan süreçler, politikalar ve araçlar topluluğudur. Hedefler: Gereksiz hakların en aza indirilmesi, saldırı yüzeyinin azaltılması, işe alım ve denetimin hızlandırılması, uyumluluk (PCI DSS, GDPR, vb.) ve ölçülebilir erişim güvenilirliği.

Temel kavramlar

Kimlik: kişi (çalışan, yüklenici), hizmet/uygulama, cihaz.
Authentication (AuthN): kontrol eden (password, MFA, parola içermeyen FIDO2/passkeys şemaları).
Yetkilendirme (AuthZ): "Neye izin verilir" kararı (RBAC/ABAC/ReBAC, politikalar).
Kimlik bilgileri: şifreler, anahtarlar, belirteçler, sertifikalar (mTLS).
Gizli yönetim: KMS/HSM/Vault, rotasyonlar, kısa TTL, dinamik sırlar.
Yaşam döngüsü: Joiner-Mover-Leaver (JML) - oluşturma, rolleri değiştirme, hatırlama.

Hedef IAM Mimarisi

• IdP (kimlik sağlayıcı): SSO, MFA, dizin, federasyon (OIDC/SAML), risk politikaları.
• PDP/PEP: Karar/Uygulama - politika motoru (OPA/Cedar) + uygulama noktaları (API ağ geçitleri, proxy'ler, servis ağları).
• Kataloglar/İK Sistemi: Çalışan ve Role Göre Gerçeğin Kaynağı
• Provizyon: Erişimler oluşturmak/değiştirmek/iptal etmek için SCIM/Otomasyon.
• Denetim: merkezi günlükler, UEBA, rol ve erişim raporları.

• SSO (+ MFA) - belirteç sorunu (OIDC/JWT/SAML) - PEP belirteci/bağlamı kontrol eder - PDP politikaya karar verir (rol/öznitelikler/risk) - uygulama erişim sorunlarını/erişimini reddeder.

Kimlik doğrulama: parolalardan parolalara

Parolalar: Yalnızca parola yöneticileri ile, en az 12-14 karakter, "takvime göre" rotasyon olmadan, ancak bir olay durumunda zorunludur.
Varsayılan MFA: TOTP/WebAuthn/Push; SMS'i önemli bir faktör olarak kullanmaktan kaçının.
Şifresiz giriş: Kritik alanlar için FIDO2/passkeys.
Adaptif AuthN: Risk sinyalini (geo, ASN, cihaz, anomaliler) düşünün - ek faktör/blok gerektirir.

Yetkilendirme: RBAC, ABAC, ReBAC

RBAC: fonksiyonlara karşılık gelen roller (Destek, Finans, DevOps). Basit ve anlaşılır, ama "büyüyor".
ABAC: özniteliklerle ilgili kurallar (departman, risk seviyesi, zaman, bölge, kaynak etiketleri). Ölçeklenebilir.
ReBAC:'kim neye ait "ilişkileri (proje sahipleri, ekip üyeleri). Çok kiracılı senaryolar için uygundur.

• RBAC (temel ızgara) + ABAC/ReBAC (bağlam/sınırlar) birleştirin.
• JIT (Just-In-Time): İstek/uygulama yoluyla geçici ayrıcalıkların verilmesi, otomatik iptal.
• JEA (Just-Enough Access): İşlem için minimum yeterli haklar.
• PAM: oturum komisyoncusu, ekran/komut kaydı ve kısa ömürlü krediler yayınlayan izole "güçlü" erişimler (DB/bulut yöneticileri).

Federasyon ve SSO

Protokoller: OIDC (JWT belirteçleri), SAML 2. 0 (XML iddiaları) - dış sağlayıcılar/ortaklar için.
SSO: MFA ile tek giriş noktası, kimlik avı azaltma, merkezi geri çağırma.
B2B/B2C: ortaklarla federasyon, etki alanı kısıtlaması, etki alanı tabanlı politikalar.
mTLS/m2m: hizmetler için kısa ömürlü x.509 (SPIFFE/SVID) veya OAuth2 İstemci Kimlik Bilgilerini kullanın.

Yaşam Döngüsü (JML) ve Provizyon

Marangoz: İK/dizinden hesapların ve temel rollerin otomatik SCIM provizyonu.
Taşıyıcı: roller niteliklere göre otomatik olarak değişir (bölüm, proje, konum).
Leaver: SSO'ların, anahtarların, belirteçlerin, deponun/bulutun/CI/CD erişimlerinin derhal geri çağrılması.
Süreçler: erişim istekleri (ITSM), SoD matrisi (görevlerin bölünmesi), periyodik erişim incelemesi.

Sırlar, anahtarlar ve rotasyonlar

KMS/HSM: Kök/kritik anahtarları saklayın, işlem denetimini etkinleştirin.
Vault/Secrets yöneticileri: dinamik krediler (DB, bulutlar), TTL tamamlanmasında otomatik revok.
Rotasyonlar: OAuth belirteçleri, JWT imzalama anahtarları, servis şifreleri - zamanında ve olay durumunda.
mTLS: Kısa ömürlü sertifikalar (saat/gün), otomatik yeniden basım.

Politikalar ve çözüm motoru

Bildiricilik: Git'te mağaza politikaları; Check in CI (policy-tests).
Bağlam: zaman/konum/ASN/risk seviyesi/cihaz durumu (MDM/EDR).

rego package authz. payments default allow = false

allow {
input. user. role == "finance"
input. device. compliant == true input. action == "read"
input. resource. type == "report"
time. now_hh >= 8 time. now_hh <= 20
}

İzleme, SLO ve denetim

• AuthN/AuthZ (%) başarısı, p95 oturum açma/karar verme süresi, MFA/parola içermeyen girişlerin paylaşımı.
• JIT/PAM yükselme sayısı, ortalama ayrıcalık süresi.
• Uyumlu cihazların kapsamı, kısa ömürlü sırların paylaşımı.

• SSO/IdP ≥ 99 kullanılabilirliği. Ayda %95.
• P95 AuthZ kararı ≤ 50 мс.
• Offboarding'den sonra 15 dakika ≤ hesabın %100 kapatılması.
• Denetim ve UEBA: merkezi değişmez günlükler (erişimler, rol değişiklikleri, başarısız girişler, PDP çözümleri), davranışsal analitik ve anomali alarmları.

IAM'de olay yanıtı

Belirteçlerin/anahtarların uzlaşması: derhal iptal, zorla çıkış, imza anahtarlarının döndürülmesi, kısa ömürlü sırların yeniden verilmesi.
Hakların kötüye kullanılması: hesabı askıya alın, JIT/JEA'yı engelleyin, komşu kuruluşların erişim incelemesini yapın.
IdP kullanılamıyor: çevrimdışı modlar (kısa TTL ile belirteçlerin geçici önbellek doğrulaması), öncelikli kurtarma prosedürleri.
Kimlik avı: zorunlu MFA, oturumların risk kontrolleri, kullanıcılara bildirimler, eğitim.

Bulutlar ve Kubernetes (desenler)

Genel Bulut IAM: yerel rolleri en az ayrıcalıkla kullanın; "Ebedi" anahtarlar yerine - buluta OIDC federasyonu ile iş yükleri (IRSA/İş Yükü Kimliği).
Kubernetes: RBAC by neimspaces/roles, limit 'cluster-admin'; sırlar - dış yöneticiler aracılığıyla; L7 politikaları için servis ağı + OPA; Giriş kontrolörleri (imzalı görüntüler, yasak ": en son").
API ağ geçitleri: hassas uç noktalar için JWT/mTLS, hız sınırları, istek imzaları (HMAC) kontrolü.

iGaming/fintech için uygulama

Erişim alanları: ödemeler, dolandırıcılıkla mücadele, PII, içerik sağlayıcılar - roller ve ağ segmentleriyle izole edin.
SoD: Çakışan rolleri birleştirmeyin (örn. promosyon oluşturun + ödemeleri onaylayın).
PAM ve JIT: PSP/bankalara ve prod-DB'ye erişim için - yalnızca bir oturum aracısı aracılığıyla, kayıt ve otomatik geri çağırma ile.
Uyumluluk: PCI DSS - MFA, minimum ayrıcalıklar, CHD bölge segmentasyonu; GDPR - PII'ye erişimin veri minimizasyonu ve nokta günlükleri ilkesi.
Ortaklar ve içerik sağlayıcılar: federasyon ve kiracı politikaları; Kısa ömürlü belirteçler ve IP/ASN izin listesi.

Yaygın hatalar

"Ebedi" anahtarlar ve belirteçler: rotasyon ve TTL yok - yüksek sızıntı riski.
Manuel offboarding: hakların iptalinde gecikmeler - "hayalet" erişim.
Monolit roller: Kompozisyon ve nitelikler yerine bir "süper rol".
MFA sadece yönetici panelinde: MFA tüm girişler ve kritik işlemler için olmalıdır.
Günlükleri "hiçbir yere": hiçbir merkezileştirme ve UEBA - olayların daha sonra tespiti yoktur.

IAM Uygulama Yol Haritası

1. Kullanıcıların/hizmetlerin/kaynakların envanteri; veri ve duyarlılık haritası.
2. Herkes için SSO + MFA, kimlik avı dirençli faktörleri içerir.
3. Rol modeli: bağlam için temel RBAC + nitelikleri (ABAC); SoD matrisi.
4. SCIM provizyonu: İK/katalogdan otomatik oluşturma/değiştirme/hakların iptali; ITSM'deki uygulamalar ve güncellemeler.
5. PAM ve JIT/JEA: ayrıcalıklı erişimler için; Kayıt seansları, kısa TTL'ler.
6. Gizli yönetim: statik anahtarların reddi; Dinamik sırlar, rotasyonlar, kısa sertifikalarla mTLS.
7. Git + CI'daki politikalar: kural testleri, değişiklik kontrolü, kanarya politikası dağıtımları.
8. Gözlemlenebilirlik ve SLO: AuthN/AuthZ panoları, uyarılar, düzenli erişim incelemesi.

Artifaktlara örnekler

AWS IAM Politikası (S3 raporlarını okumak için minimum)

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ReadOnlyReports",
"Effect": "Allow",
"Action": ["s3:GetObject","s3:ListBucket"],
"Resource": [
"arn:aws:s3:::reports-bucket",
"arn:aws:s3:::reports-bucket/"
],
"Condition": {
"IpAddress": { "aws:SourceIp": "203. 0. 113. 0/24" }
}
}]
}

Kubernetes RBAC (ad alanı kapsamlı geliştirici)

yaml apiVersion: rbac. authorization. k8s. io/v1 kind: Role metadata:
name: dev-read-write namespace: app-prod rules:
- apiGroups: ["","apps"]
resources: ["pods","deployments","services","configmaps"]
verbs: ["get","list","watch","create","update","patch","delete"]
apiVersion: rbac. authorization. k8s. io/v1 kind: RoleBinding metadata:
name: dev-bind namespace: app-prod subjects:
- kind: User name: alice@example. com roleRef:
kind: Role name: dev-read-write apiGroup: rbac. authorization. k8s. io

OIDC: ABAC için onaylar (örnek)

json
{
"sub": "d81f0b5c-...",
"email": "bob@example. com",
"dept": "finance",
"role": "analyst",
"device_compliant": true,
"tenant": "casino-eu"
}

Politika, kaynağın eşleşmesi için 'device _ compliant = true've' tenant 'gerektirebilir.

Check-list

• SSO tüm uygulamalar için etkindir; Varsayılan olarak MFA, öncelikli anahtarlar.
• RBAC tanımlı; ABAC/ReBAC ek bağlam; JIT/JEA tarafından uygulanmaktadır.
• PAM ayrıcalıklı erişimleri korur; oturumlar kaydediliyor.
• İK'dan SCIM provizyonu; Offboard tamamen otomatiktir.
• Sırlar kısa TTL ile dinamik; rotasyonlar otomatiktir.
• Politikalar Git'te çevrilmiş, CI'da test edilmiştir; Kanarya hesaplamaları var.
• AuthN/AuthZ'ye göre gösterge panoları ve SLO; Merkezi günlükler ve UEBA.
• Periyodik erişim incelemesi ve SoD kontrolleri; Uyumluluk raporları.

SSS

ReBAC'ın herkese ihtiyacı var mı?
Hayır. RBAC + ABAC basit ortamlar için yeterlidir. ReBAC, karmaşık bir kaynak sahipliği ve çoklu kiracılık hiyerarşisinde kullanışlıdır.

Yerel hesaplardan ayrılabilir miyim?
Sadece sıkı kısıtlamalar ve periyodik doğrulama ile kırık cam ve çevrimdışı senaryolar için.

"Rollerin patlaması" nasıl azaltılır?
Kaynak ayrıntılılığını artırın, ABAC/şablonları kullanın, incelemeleri otomatikleştirin ve kullanılmayan rolleri atın.

Toplam

Olgun IAM mimarisi SSO + MFA, minimum gerekli haklar, otomatik JML, merkezi politikalar ve gözlemlenebilirliktir. RBAC'yi nitelik ve ilişkisel modellerle birleştirerek, JIT/JEA ve PAM uygulayarak ve provizyon ve gizli rotasyonları otomatikleştirerek, güvenlik ve iş gereksinimlerini karşılayan yönetilebilir, denetlenebilir ve ölçeklenebilir erişim elde edersiniz.