Seri 3 — Kurumsal Yazılımlarda Merkezi Kimlik Yönetimi: OIDC ile Güvenli ve Ölçeklenebilir…

İlk 2 serimizde OIDC nin ne olduğu , backend developerlar tarafından geliştirme aşamasında hangi konseptlere sahip geliştirilmesi gerektiği hakkında konuşmuştuk. Bu yazımızda ise OIDC'yi sürdürebilir şekilde kurmaya çalışan platform mühensileri ve karar verici ekipler için bir yazı olacaktır.Eğer direkt bu yazıya geldiyseniz ilk 2 yazıma göz atmanızı tavsiye ederim.

Seri 1 — OIDC Nedir? Bir uygulamaya girerken gördüğümüz giriş ekranı oldukça basittir bilgilerimizi girip kayıt oluruz fakat bu küçük…

Seri 2 — Yazılımlarda OIDC Kullanımı: Next.js, Java, Python ve PHP Seri 1'de OpenID Connect'in (OIDC) hangi problemi çözdüğünü gördük. Bu bölüm bir backend geliştiricisinin OIDC…

Sektörde OIDC ve OAuth 2.0 tabanlı merkezi kimlik platformlarının ortaya çıkmasının temel nedeni budur: Her uygulamanın kullanıcı kimliğini, parolayı, MFA'yı, kurumsal bağlantıları, oturumu ve güvenlik politikalarını ayrı ayrı yönetmesi sürdürülebilir değildir.

**Kısa cevap:**Merkezi Identity Platform, kimlik doğrulamayı her uygulamada yeniden geliştirilen bir özellik olmaktan çıkarır; standart protokollerle tüketilen, güvenliği ve yaşam döngüsü merkezi yönetilen bir platform kabiliyetine dönüştürür.

Bu yazıda önce böyle bir platforma neden ihtiyaç duyulduğunu gerçekçi bir "20 uygulama" problemi üzerinden anlatacağız. Ardından merkezi mimariyi, multi-application ve multi-tenant tasarımı, modern kimlik özelliklerini, güvenlik gereksinimlerini, ZITADEL'in bu mimarideki yerini, ZITADEL–Keycloak–Auth0–Okta karşılaştırmasını ve Aurora'nın sunduğu yönetilen Identity Platform yaklaşımını inceleyeceğiz.

Bu yazı kimler için?

Yazı özellikle şu ekipler için hazırlandı:

Platform Engineering ve DevOps ekipleri
Yazılım ve çözüm mimarları
Güvenlik ekipleri
SaaS ve kurumsal ürün geliştiren ekipler
Teknik karar vericiler
Birden fazla uygulamasını ortak kimlik sistemiyle yönetmek isteyen kurumlar

1. Bu sistemlere neden ihtiyaç duyuldu?

Yazılım dünyası tek parça kurumsal uygulamalardan web, mobil, SaaS, API ve mikroservislerden oluşan dağıtık yapılara geçti. Kullanıcılar artık yalnızca şirket çalışanları değildir; müşteriler, iş ortakları, tedarikçiler, bayiler ve makineler de sistemlere erişir.

Bu değişim kimlik tarafında beş temel baskı oluşturdu.

Uygulama sayısı arttı

Her yeni uygulama kendi login sistemini kurduğunda parola saklama, MFA, hesap kilitleme, parola sıfırlama, sosyal giriş ve oturum güvenliği tekrar tekrar geliştirilir.

Saldırılar kimliği hedeflemeye başladı

Phishing, parola tekrar kullanımı, credential stuffing, oturum çalma ve yetkili hesapların ele geçirilmesi modern saldırıların önemli giriş noktalarıdır. Kimlik güvenliği artık yalnızca uygulama geliştiricisinin yazdığı birkaç doğrulama kuralına bırakılamaz.

Kullanıcı yaşam döngüsü karmaşıklaştı

Bir çalışanın işe başlaması, departman değiştirmesi veya işten ayrılması bütün uygulamalara yansıtılmalıdır. Aynı durum müşteri çalışanları, iş ortakları ve teknik hesaplar için de geçerlidir.

Kurumsal bağlantı ihtiyacı oluştu

Müşteriler kendi Microsoft Entra ID, Google Workspace, LDAP veya Active Directory sistemleriyle giriş yapmak ister. Her uygulamanın bu sistemlerle ayrı entegrasyon kurması hem maliyetli hem de risklidir.

Denetim ve mevzuat gereksinimleri büyüdü

Kimin hangi uygulamaya ne zaman giriş yaptığı, hangi rolün kim tarafından verildiği ve bir hesabın ne zaman kapatıldığı merkezi biçimde izlenebilmelidir.

OIDC ve OAuth 2.0 bu ihtiyaçların tamamını tek başına çözen ürünler değildir. Ancak uygulamalar ile kimlik platformu arasında standart bir sözleşme kurar. Uygulama, sağlayıcının iç yapısını bilmeden kullanıcı girişi ve token tabanlı erişim sağlayabilir.

2. Problem: Bir müşteride 20 ayrı kimlik sistemi

Orta ölçekli bir kurum düşünelim. Kurumun zaman içinde geliştirdiği 20 uygulaması var:

İnsan kaynakları uygulaması
Finans ve muhasebe sistemi
Müşteri portalı
Bayi portalı
Destek uygulaması
Mobil uygulama

Kısacası bunun gibi daha sayacak olursak zaten önceden de bahsettiğimiz gibi her uygulama için ayrı bir parola politikası ve veritabanının gereksiz ve sürdürülebilir olmadığı çok bellidir.

İlk bakışta sistemler birbirinden bağımsız olduğu için bu yapı esnek görünebilir. Gerçekte ise aynı güvenlik problemi 20 kez çoğaltılmıştır.

Bir çalışan üzerinden problemi görelim

Ayşe'nin kuruma yeni katıldığını düşünelim.

İşe başladığında Ayşe için farklı uygulamalarda ayrı hesaplar açılır. Bazı ekipler hesabı otomatik oluştururken bazıları e-posta ile gelen talebi bekler. Uygulamalardan biri güçlü parola isterken diğeri daha zayıf bir politikaya izin verir. Yalnızca birkaç uygulama MFA kullanır.

Altı ay sonra Ayşe'nin rolü değişir. Finans uygulamasındaki yetkisi güncellenir ancak eski raporlama sistemindeki yönetici rolü unutulur.

Ayşe kurumdan ayrıldığında ana dizin hesabı kapatılır fakat bağımsız kullanıcı veritabanlarından birindeki hesabı açık kalır. Artık kullanılmayan bu hesap saldırgan için görünmeyen bir giriş kapısıdır.

Bu problem yalnızca operasyonel değildir:

Zayıf uygulama bütün kurumun saldırı yüzeyini büyütür.
Kullanıcı erişimleri zamanında kaldırılamaz.
Aynı kişi farklı sistemlerde farklı kimliklerle temsil edilir.
Güvenlik politikaları tutarsız uygulanır.
Olay incelemesi için 20 farklı log kaynağı birleştirilir.
Uygulama ekipleri ürün geliştirmek yerine login altyapısı bakımına zaman ayırır.
Kullanıcılar çok sayıda parola ve oturumla uğraşır.

3. Çözüm: Merkezi Identity Platform

Merkezi modelde uygulamalar kullanıcı parolasını doğrulamaz. Bu sorumluluk bir Identity Provider'a verilir. Uygulamalar kimlik sonucunu OIDC, erişim yetkisini OAuth 2.0, eski kurumsal bağlantıları gerektiğinde SAML ve kullanıcı yaşam döngüsünü SCIM gibi standartlarla tüketir.

Bu yapıda hedef yalnızca "tek parola" değildir. Asıl hedef, kimlik güvenliği ve yaşam döngüsü için tek bir kontrol düzlemi oluşturmaktır:

Tek kullanıcı yaşam döngüsü
Ortak MFA ve passkey politikaları
Merkezi oturum ve risk yönetimi
Standart uygulama bağlantıları
Merkezi rol ve claim tasarımı
Birleşik audit izi
Tek noktadan sosyal ve kurumsal federasyon
İnsan ve makine kimliklerinin birlikte yönetimi

Hangi sorumluluk nerede kalır?

Merkezileştirme, uygulamanın bütün güvenlik sorumluluğunu ortadan kaldırmaz.

| Identity Platform |Uygulama |

| Kullanıcının kimliğini doğrular | İşlem için yetki kararı verir |

| MFA, passkey ve parola politikasını uygular | Kaynak sahipliği ve iş kurallarını uygular |

| ID token ve access token üretir | Token'ı doğru hedef ve amaç için kullanır |

| Oturum ve federasyonu yönetir | Kendi uygulama oturumunu güvenli yönetir |

| Rol ve claim'leri sağlayabilir | Claim'leri kendi yetki modeline doğru eşler |

Kimlik doğrulama merkezi platforma devredilebilir; fakat erişim kararlarının doğruluğuna ilişkin hesap verebilirlik uygulama ve kurumda kalır.

4. Müşteriye ve yazılım ekiplerine katkıları

Yeni uygulama daha hızlı devreye alınır

Yeni ekiplerin parola ekranı, forgot password, MFA, Google Login, Microsoft Login veya LDAP entegrasyonu yazması gerekmez. Uygulama OIDC client olarak kaydedilir ve standart akışa bağlanır.

Kod ve bağımlılık sayısı azalır

Merkezi sistem olmadan tipik bir uygulama şu parçaların birkaçını veya tamamını taşır:

Merkezi modelde uygulamanın doğrudan sorumluluğu küçülür:

Bu değişim:

tekrar eden kodu,
güvenlik hatası üretme ihtimalini,
bağımlılık güncelleme yükünü,
framework'e özel kimlik kodunu,
bakım ve test maliyetini

azaltır.

Uygulamanın kullandığı OIDC istemci kütüphanesi yine güncel tutulmalıdır. Ancak MFA, passkey veya yeni bir kurumsal Identity Provider eklemek çoğu durumda 20 uygulamanın kodunu değiştirmek yerine merkezi platformun yapılandırmasını değiştirmekle sınırlı kalır.

Kullanıcı deneyimi tutarlı hale gelir

Kullanıcılar bütün uygulamalarda ortak bir giriş deneyimi görür. Aktif Identity Provider oturumu sayesinde SSO kullanılabilir. Parola sıfırlama, MFA kaydı ve hesap kurtarma süreçleri tek noktada yönetilir.

Audit ve erişim incelemesi kolaylaşır

Giriş denemeleri, MFA olayları, rol değişiklikleri, kullanıcı kapatma işlemleri ve yönetim operasyonları merkezi olarak izlenebilir. Bu, olay müdahalesi ve düzenli erişim gözden geçirmeleri için ortak bir veri kaynağı oluşturur.

5. Multi-application: Aynı kimlik, farklı istemciler

Merkezi Identity Platform yalnızca web uygulamalarını bağlamaz.

Her uygulama ve ortam için ayrı client tanımlamak önemlidir. Üretim, test ve geliştirme ortamlarının aynı client secret'ı veya redirect URI listesini paylaşması gereksiz risk oluşturur.

İnsan kullanıcı ile makine kimliği de ayrılmalıdır:

İnsan kullanıcı etkileşimli giriş yapar; MFA veya passkey kullanabilir.
Servis hesabı bir backend, CI/CD işi veya cihazı temsil eder.
Makine kimliğine insan parolası verilmez.
Her servis hesabı yalnızca gereken en düşük yetkiye sahip olur.
Anahtar ve client secret değerleri döndürülür, süreli tutulur ve secret manager içinde saklanır.

6. Multi-tenant kimlik mimarisi

B2B SaaS sisteminde yalnızca "kullanıcı kim?" sorusu yetmez. Kullanıcının hangi müşteri organizasyonu adına işlem yaptığı da bilinmelidir.

Tipik bir model şöyledir:

Bir organizasyon müşteriyi, proje bir ürün veya güvenlik bağlamını, application ise web, mobil veya API istemcisini temsil edebilir.

Tenant izolasyonu yalnızca bir claim değildir

Token içinde tenant_id veya organization bilgisi bulunması faydalıdır; ancak uygulama yalnızca bu alanı okuyarak izolasyonu tamamlamış olmaz.

Uygulama:

token'ın imzasını, issuer'ını ve audience'ını doğrulamalı,
kullanıcının ilgili tenant ile ilişkisini doğrulamalı,
bütün veri sorgularını tenant bağlamıyla sınırlandırmalı,
tenant değişimini açık ve denetlenebilir yapmalı,
cache anahtarları ve arka plan işlerinde tenant bağlamını korumalı,
global yönetici yetkilerini çok sınırlı vermelidir.

Rol isimleri de tenant bağlamından bağımsız düşünülmemelidir. admin rolü, "bütün platformun yöneticisi" değil "Müşteri A içindeki belirli projenin yöneticisi" anlamına gelebilir.

7. Modern Identity Platform özellikleri

Merkezi platform yalnızca OIDC endpoint'leri sunan bir token servisi değildir.

MFA, WebAuthn ve passkey

MFA, parola ele geçirilse bile ek doğrulama ister. WebAuthn ve passkey ise açık anahtar kriptografisiyle phishing'e karşı daha güçlü bir giriş deneyimi sağlayabilir.

Bu yetenek merkezi sunulduğunda her uygulama biyometrik doğrulama veya güvenlik anahtarı desteğini ayrı geliştirmez.

Passwordless ve magic link

Kullanım senaryosuna göre parola yerine passkey, e-posta bağlantısı veya başka doğrulama yöntemleri kullanılabilir. Hesap kurtarma ve risk politikası yöntemin kendisi kadar dikkatli tasarlanmalıdır.

Social ve enterprise login

Google, Microsoft, GitHub gibi sosyal veya kurumsal sağlayıcılar merkezi platforma bağlanır. Uygulamalar her harici sağlayıcıyla doğrudan konuşmak yerine aynı OIDC sözleşmesini kullanmaya devam eder.

SCIM, provisioning ve yaşam döngüsü

OIDC kullanıcının giriş anını çözer; SCIM ise hesabın oluşturulması, güncellenmesi, devre dışı bırakılması ve kaldırılması gibi yaşam döngüsü işlemlerini standartlaştırır.

Örneğin müşteri kendi dizininden bir çalışanı çıkardığında bu değişiklik SCIM üzerinden merkezi kimlik platformuna aktarılabilir. Böylece erişim yalnızca bir sonraki başarısız girişe bırakılmadan kapatılabilir.

Provisioning ile authentication farklı sorumluluklardır:

OIDC giriş yapan kişinin kimliğini bildirir.
SCIM hesabın sistemlerdeki yaşam döngüsünü yönetir.
Uygulama verisinin silinmesi veya saklanması yine iş ve mevzuat kurallarına göre ele alınır.

8. Güvenlik: Merkezileştirme tek başına yeterli değildir

Merkezi Identity Platform güvenlik politikalarını güçlendirir; fakat aynı zamanda kritik bir altyapı bileşeni haline gelir. Yanlış yapılandırılır veya erişilemez hale gelirse bütün uygulamalar etkilenebilir.

Bu nedenle merkezi sistem "tek kontrol noktası" olarak tasarlanmalı, "tek hata noktası" olarak bırakılmamalıdır.

ID token ve access token ayrımı korunmalıdır

ID token uygulamanın kullanıcıyı tanıması içindir. API çağırmak için access token kullanılır.

Bir API access token kabul ettiğinde en az şu kontrolleri yapmalıdır:

İmza güvenilen JWKS anahtarıyla doğrulanır.
iss beklenen Identity Provider ile eşleşir.
aud bu API'yi hedefler.
exp süresi geçmemiştir.
Gerekli scope veya permission mevcuttur.
Tenant ve kaynak bazlı iş kuralları ayrıca uygulanır.

Token'ı yalnızca decode etmek doğrulama değildir.

Yönetici ve servis hesapları daha güçlü korunmalıdır

Merkezi platform yöneticileri yüksek etkiye sahiptir. Yönetici hesaplarında:

phishing'e dayanıklı MFA,
ayrı yönetici hesabı,
en düşük yetki,
süreli yetki yükseltme,
kritik işlemler için onay,
ayrıntılı audit ve alarm

uygulanmalıdır.

Servis hesapları da görünmez süper kullanıcılar haline gelmemelidir. Her otomasyon için ayrı kimlik, sınırlı rol, süreli anahtar ve düzenli rotasyon kullanılmalıdır.

Operasyon güvenliği

Self-hosted bir Identity Platform işletmek yalnızca container çalıştırmak değildir. Şu konuların sahibi açıkça belirlenmelidir:

Güvenlik güncellemeleri ve sürüm yükseltmeleri
Veritabanı yedekleme ve geri yükleme testleri
İmza anahtarı ve secret rotasyonu
TLS, ingress ve network policy yönetimi
Yüksek erişilebilirlik ve kapasite planlama
Log, metric, trace ve alarm yönetimi
Şüpheli giriş ve yönetim olaylarının SIEM'e aktarılması
Olay müdahalesi ve felaket kurtarma
Veri yerleşimi, saklama süresi ve mevzuat gereksinimleri

9. ZITADEL neden öne çıkıyor?

ZITADEL, OIDC ve OAuth 2.0 tabanlı kimlik ihtiyaçlarını modern uygulama ve B2B SaaS mimarilerine taşıyan bir Identity Platform seçeneğidir.

Öne çıkan mimari özellikleri şunlardır:

Organization ve multi-tenancy modeli

ZITADEL'de organization; kullanıcıların, projelerin ve politikaların bulunduğu tenant benzeri sınırdır. Bir instance içinde birden fazla organization yönetilebilir. Bu model, müşterilerin kendi kullanıcılarını veya belirli ayarlarını yönetebildiği B2B senaryoları için anlamlıdır.

Human ve service account ayrımı

Etkileşimli giriş yapan insanlar ile backend, cihaz ve otomasyonları temsil eden servis hesapları ayrı modellenir. Böylece makine kimlikleri insan parolalarıyla yönetilmez.

Standart protokoller ve federasyon

OIDC, OAuth 2.0 ve SAML bağlantılarının yanında harici Identity Provider entegrasyonları sunar. SCIM v2 arayüzü kullanıcı oluşturma, güncelleme ve devre dışı bırakma gibi provisioning işlemlerini standartlaştırır.

SCIM kapsamı sürüme göre ayrıca doğrulanmalıdır. Güncel ZITADEL dokümantasyonunda User şeması desteklenirken group provisioning için sınırlamalar belirtilmektedir; müşteri gereksinimi buna göre test edilmelidir.

Passkey ve modern giriş yöntemleri

Passkey, MFA ve passwordless seçenekleri merkezi giriş deneyimine eklenebilir. Uygulamaların bu doğrulama yöntemlerini ayrı ayrı geliştirmesi gerekmez.

API-first ve otomasyon

Yönetim işlevlerinin API'lerle sunulması; tenant, proje, uygulama ve politika işlemlerinin otomasyona bağlanmasını kolaylaştırır. Resmi Terraform Provider ile kimlik kaynakları deklaratif olarak yönetilebilir.


resource "zitadel_org" "customer_a" {

name = "Müşteri A"

}

resource "zitadel_project" "platform" {

name = "Kurumsal Platform"

org_id = zitadel_org.customer_a.id

}


resource "zitadel_org" "customer_a" {

name = "Müşteri A"

}

resource "zitadel_project" "platform" {

name = "Kurumsal Platform"

org_id = zitadel_org.customer_a.id

}

Bu yalnızca örnek bir iskelettir. Üretimde provider kimliği, yetkiler, state saklama, ortam ayrımı ve değişiklik onayı ayrıca tasarlanmalıdır.

Cloud ve self-hosted seçenekleri

ZITADEL Cloud yönetilen hizmet olarak kullanılabilir. Veri yerleşimi veya altyapı kontrolü gereksinimi olan kurumlar self-hosted modeli Linux, container veya Kubernetes üzerinde çalıştırabilir.

Kubernetes dağıtımı için resmi Helm chart bulunur. Üretim ortamında harici PostgreSQL, TLS, secret yönetimi, çoklu replica, Pod Disruption Budget, yedekleme ve gözlemlenebilirlik ayrıca tasarlanmalıdır.

Event Sourcing ve audit

ZITADEL değişiklikleri Event Store içinde olaylar olarak saklayan Event Sourcing ve CQRS yaklaşımını kullanır. Bu yapı kullanıcı, rol ve politika değişiklikleri için güçlü bir tarihçe ve audit izi sağlar.

Event Sourcing aynı zamanda bazı okuma modellerinde eventual consistency davranışının anlaşılmasını gerektirir. Entegrasyon ve otomasyonlar, yazma işleminden hemen sonra bütün sorgu görünümlerinin aynı anda güncelleneceğini varsaymamalıdır.

Gözlemlenebilirlik

Self-hosted dağıtımda metric endpoint'i, OpenTelemetry tabanlı metric ve trace bağlantıları ile log toplama seçenekleri bulunur. Bunların alarm, dashboard, SLO ve olay müdahalesine dönüştürülmesi platformu işleten ekibin sorumluluğudur.

ZITADEL, Keycloak, Auth0 ve Okta karşılaştırması

Dört platform aynı temel standartların önemli bir bölümünü desteklese de aynı probleme aynı ürün ve işletim modeliyle yaklaşmaz. ZITADEL ve Auth0 modern uygulama/CIAM ile B2B SaaS senaryolarını öne çıkarır; Keycloak altyapı kontrolü ve özelleştirme isteyen ekiplerin yönettiği açık kaynaklı bir yapı sunar; Okta ise özellikle çalışan kimliği, uygulama erişimi, cihaz bağlamı, yaşam döngüsü ve yönetişim tarafında geniş bir kurumsal ürün ailesine sahiptir.

Kapsam notu (Ağustos 2026): Aşağıdaki karşılaştırma ürünlerin genel yönünü ve resmi dokümantasyonda görülen kabiliyetleri özetler. Paket, lisans, bölge, limit ve erken erişim durumu değişebilir. Satın alma kararında hedef sürüm ve teklif ayrıca doğrulanmalıdır. "Var" ifadesi de her ürünün aynı kapsamı veya yönetim deneyimini sunduğu anlamına gelmez.

Ürün ve mimari yaklaşım

Kimlik, protokol ve güvenlik kabiliyetleri

|Otomasyon, operasyon ve seçim etkisi

Hangi durumda hangisi öne çıkar?

Bu tablolar bir sıralama değildir. Kısa bir karar özeti şöyle okunabilir:

ZITADEL: B2B organization/delegasyon, API-first otomasyon ve cloud/self-hosted esnekliği birlikte isteniyorsa güçlü adaydır.
Keycloak: Lisans bağımsızlığı, altyapı kontrolü ve derin özelleştirme en önemli gereksinimlerse; bunu işletecek ekip de varsa güçlü adaydır.
Auth0: Müşteri kimliği için yönetilen hizmet, hızlı entegrasyon, hazır bağlantılar ve geliştirici deneyimi öncelikliyse güçlü adaydır.
Okta: Çalışan kimliği, kurumsal uygulama SSO'su, provisioning, cihaz güveni ve erişim yönetişimi birlikte aranıyorsa güçlü adaydır.

Nihai seçimde şu sorular cevaplanmalıdır:

Kullanıcılar çalışan mı, müşteri mi, iş ortağı mı?
B2B organization ve yetki delegasyonu gerekiyor mu?
SaaS mı, self-hosted mı kullanılacak?
Veri hangi ülkede veya altyapıda kalmalı?
Ekip kritik kimlik altyapısını 7/24 işletebilir mi?
LDAP, Active Directory, Entra ID veya Google Workspace bağlantıları neler?
Audit, SLA, destek ve sertifikasyon beklentileri neler?
Lisans ve büyüme maliyeti nasıl değişiyor?
Çıkış ve taşıma stratejisi var mı?
Hangi özellikler temel pakette, hangileri ek lisans veya erken erişimdedir?
Pilot senaryoda login, provisioning, tenant izolasyonu, audit ve felaket davranışı ölçüldü mü?

10. Şirket perspektifi: Kimlik platformunu yönetilen bir hizmet olarak sunmak

Şirket perspektifinde amaç müşteriye yalnızca bir ZITADEL kurulumu teslim etmek değildir. Asıl değer; kimlik mimarisinin tasarlanması, uygulamaların bağlanması, güvenliğin sertleştirilmesi ve platformun yaşam döngüsü boyunca işletilmesidir.

10.1 Kurumsal Identity Platform kurulumu

Aurora müşterinin teknik, güvenlik ve mevzuat gereksinimlerine göre hedef dağıtım modelini tasarlar:

ZITADEL Cloud entegrasyonu
Müşteri bulutunda self-hosted Kubernetes dağıtımı
On-premise veya özel bulut dağıtımı
Kurumsal dizinlerle hibrit federasyon

Self-hosted modelde yalnızca Helm kurulumu değil; PostgreSQL, ingress, TLS, secret yönetimi, yüksek erişilebilirlik, yedekleme ve felaket kurtarma birlikte ele alınır.

10.2 Tenant, organization ve proje tasarımı

Yanlış tenant modeli ileride veri izolasyonu ve yetki sorunlarına dönüşebilir.

müşteri ve alt organizasyon sınırlarını,
organization ve project yapısını,
uygulama ve ortam ayrımını,
yönetim delegasyonunu,
domain ve branding yaklaşımını,
tenant bağlamının token ve uygulama verisine taşınmasını

tasarlar.

Amaç yalnızca tenant oluşturmak değil, kimlik katmanındaki sınırlarla uygulama verisindeki sınırların aynı modeli izlemesini sağlamaktır.

10.3 Rol ve yetki modeli

Aurora, "herkese admin verip sonra daraltma" yaklaşımı yerine least privilege temelli bir model kurar:

Bu süreçte:

rol ve permission sözlüğü,
tenant bağlamı,
kullanıcı ve servis hesabı yetkileri,
uygulama içi authorization sınırları,
rol talep ve onay süreci,
periyodik erişim incelemesi

tanımlanır.

10.4 Kurumsal federasyon ve kullanıcı yaşam döngüsü

Aurora; LDAP, Active Directory, Microsoft Entra ID, Google Workspace ve uygun diğer sağlayıcıları merkezi platforma bağlar.

Federasyon tasarımı yalnızca login ekranına bir düğme eklemek değildir. Şu kararlar birlikte alınır:

Kullanıcının kalıcı kimliği hangi alanla eşleştirilecek?
Aynı e-posta ile gelen hesaplar otomatik bağlanacak mı?
Hangi sağlayıcı hangi organization için kullanılacak?
Grup ve roller nasıl eşlenecek?
Kullanıcı dizinden kaldırıldığında erişim ne kadar sürede kapanacak?
SCIM mi, event tabanlı otomasyon mu, periyodik senkronizasyon mu kullanılacak?
Acil durumda yerel yönetici hesabı nasıl korunacak?

10.5 Uygulamaların OIDC entegrasyonu

Aurora, farklı teknoloji ekiplerine ortak entegrasyon standardı sağlar:

Güvenli OIDC client kaydı
Doğru flow ve PKCE seçimi
Redirect ve logout URI yönetimi
Token doğrulama standardı
Session ve cookie güvenliği
Claim ve rol eşleme
API access token doğrulaması
Next.js, Java, Python, PHP ve diğer platformlar için referans uygulamalar

Bu sayede her ekip protokolü baştan yorumlamak yerine doğrulanmış bir entegrasyon kalıbını kullanır.

10.7 Identity as Code ve GitOps

Manuel console işlemleri hızlı başlamak için yararlıdır; ancak çok sayıda müşteri ve uygulamada değişikliklerin izlenmesini zorlaştırır.

Aurora, uygun kaynakları Terraform ve CI/CD süreçleriyle yöneterek:

değişikliklerin code review'dan geçmesini,
test ve üretim ortamlarının ayrılmasını,
yapılandırma sapmasının azaltılmasını,
geri alınabilir sürümlerin oluşmasını,
kimlik kaynaklarının tekrarlanabilir kurulmasını

sağlar.

Secret değerleri Terraform koduna veya state dosyasına açık biçimde yazılmaz. Secret manager, sınırlı CI/CD kimliği ve güvenli state backend kullanılır.

10.8 Güvenlik sertleştirmesi

Aurora'nın güvenlik çalışması ürünün varsayılan ayarlarına güvenmekle sınırlı değildir:

Yönetici rollerinin daraltılması
Admin hesaplarında güçlü MFA
Servis hesaplarının ayrılması ve anahtar rotasyonu
TLS ve güvenli header ayarları
Network policy ve erişim sınırları
Secret yönetimi
Token ve session yaşam süreleri
Redirect URI ve CORS politikaları
Audit olaylarının SIEM'e aktarılması
Güvenlik güncelleme ve zafiyet yönetimi
Yedekleme ve geri dönüş testleri
Olay müdahale prosedürleri

10.9 Operasyon, izleme ve yaşam döngüsü yönetimi

Kimlik platformu bütün uygulamaların giriş kapısı olduğundan performans ve erişilebilirlik doğrudan müşteri deneyimini etkiler.

Aurora operasyon modelinde şu göstergeler izlenir:

Login başarı ve hata oranı
Token endpoint gecikmesi
MFA başarısızlıkları
Harici Identity Provider hataları
HTTP ve gRPC hata oranları
Veritabanı bağlantıları ve kaynak kullanımı
Sertifika ve secret süreleri
Şüpheli yönetim olayları
Yedekleme başarısı
Sürüm ve güvenlik güncelleme durumu

Yalnızca dashboard oluşturmak yeterli değildir. Alarm eşikleri, sorumlu ekip, müdahale süresi, bakım penceresi ve felaket senaryoları önceden tanımlanır.

11. Aurora ile geçiş nasıl ilerler?

20 uygulamayı aynı gün merkezi sisteme geçirmek gereksiz risk oluşturur. Kademeli bir yol izlenir.

Aşama 1: Envanter ve risk analizi

Uygulamalar ve kullanıcı tipleri çıkarılır.
Mevcut login, session ve rol modelleri incelenir.
LDAP, AD, sosyal ve kurumsal bağlantılar belirlenir.
Kritik uygulamalar ve güvenlik açıkları önceliklendirilir.

Aşama 2: Hedef mimari

Cloud veya self-hosted model seçilir.
Organization, project ve application yapısı tasarlanır.
Rol, claim, tenant ve federasyon sözleşmesi oluşturulur.
Güvenlik, audit, yedekleme ve SLO gereksinimleri belirlenir.

Aşama 3: Pilot uygulama

Temsil gücü yüksek fakat kontrollü risk taşıyan bir uygulama OIDC'ye geçirilir. Login, logout, MFA, rol eşleme, token doğrulama ve olay kayıtları uçtan uca test edilir.

Aşama 4: Geçiş dalgaları

Uygulamalar teknoloji, önem ve kullanıcı grubuna göre dalgalar halinde taşınır. Eski hesaplarla merkezi kimlik arasındaki eşleme, kesinti ve geri dönüş planı hazırlanır.

Aşama 5: Yönetilen operasyon

Platform izleme, sürüm yükseltme, güvenlik sertleştirme, erişim incelemesi ve yeni uygulama onboarding süreçleri sürekli hizmete dönüşür.

12. Sorumlulukların açık paylaşımı

Yönetilen hizmet modelinin başarılı olması için Aurora, müşteri ve uygulama ekiplerinin sorumlulukları baştan belirlenir.

Sonuç: Login özelliğinden Identity Platform hizmetine

Kurumsal yapılarda asıl problem kullanıcıya bir login ekranı göstermek değildir. Problem; onlarca uygulama, farklı kullanıcı türleri, müşteri organizasyonları, kurumsal dizinler, roller, servis hesapları ve güvenlik politikaları arasında tutarlı bir kimlik sistemi kurmaktır.

20 uygulamanın 20 farklı login sistemi olduğunda:

aynı güvenlik problemi tekrar tekrar çözülür,
hesap ve yetki yaşam döngüsü parçalanır,
audit zorlaşır,
uygulama ekipleri iş mantığından uzaklaşır,
saldırı yüzeyi büyür.

Merkezi Identity Platform bu sorumlulukları standartlaştırır. OIDC ve OAuth 2.0 uygulamalarla ortak dili kurar; MFA, passkey, federasyon, SCIM, audit ve servis hesapları merkezi kabiliyetlere dönüşür.

ZITADEL; organization tabanlı multi-tenancy, standart protokoller, API ve Terraform otomasyonu, cloud ve self-hosted seçenekleri, Kubernetes uyumu ve Event Sourcing tabanlı audit modeliyle bu mimari için güçlü bir seçenektir. Ancak ürün seçimi tek başına çözüm değildir. Tenant modeli, yetki sınırları, güvenlik, entegrasyon ve operasyon doğru tasarlanmalıdır.

Resmi kaynaklar