SSO Projesi Parola Sayısını Azaltmaktan Daha Fazlasıdır
Kullanıcıların çok sayıda parola hatırlaması SSO projesini başlatan görünür şikâyetti. Ancak envanter çalışmasında daha önemli bir sorun ortaya çıktı: işten ayrılan bir kişinin bazı bulut uygulamalarındaki yerel hesabı günler sonra kapatılıyordu. Parola sayısını azaltmak değerliydi, fakat merkezi kimliğin asıl getirisi erişimi tek politika ve yaşam döngüsü altında yönetebilmekti.
SSO, her uygulamaya aynı parolayı göndermek değildir. Kimlik sağlayıcı, SAML veya OpenID Connect gibi protokollerle uygulamaya doğrulanmış kimlik beyanı sunar. Uygulamanın oturum davranışı, yerel hesapları ve yetkilendirmesi yine ayrıca tasarlanır. Bu ayrım anlaşılmadığında başarılı giriş ekranı, yanlışlıkla başarılı bir IAM projesi sanılabilir.
Sorunun ortaya çıkışı
Kurumsal uygulamaların bir bölümü dizin hesabı, bir bölümü yerel kullanıcı, bazıları da ortak hesap kullanıyordu. Parola sıfırlama talepleri artıyor ve yeni çalışan açılışı uygulama sahiplerine e-postayla dağıtılıyordu. Ayrılış kontrol listesi uygulama envanteri güncel olmadığı için eksik kalabiliyordu. Yönetim tek giriş istedi; BT olarak kapsamı kimlik, provisioning ve yetki yaşam döngüsünü içerecek biçimde genişlettik.
İlk belirtiler ve yanlış varsayımlar
“Entra’ya bağlanınca bütün hesaplar kapanır” varsayımı doğru değildi. SSO oturumu engelleyebilir, fakat uygulamadaki yerel hesap, API anahtarı veya aktif oturum devam edebilir. Her uygulamanın SAML desteklemesi de aynı kaliteyi sağlamaz; grup claim sınırları, kullanıcı eşleme ve logout davranışı değişir. Ayrıca break-glass hesabını normal SSO akışına bağlamak acil durumda tek hata noktası yaratabilir.
Teknik analiz
Uygulama envanterine sahip, kullanıcı sayısı, veri sınıfı, protokol, provisioning yöntemi, yerel hesap ve kritik bağımlılık alanları eklendi. SAML ve OIDC seçenekleri ürün dokümanı ve test tenantında doğrulandı. NameID veya subject eşlemesinde değişebilir e-posta yerine kararlı kimlik değerlendirildi. MFA ve koşullu erişimin hangi uygulamalarda uygulanacağı, servis hesapları ve mobil istemcilerle birlikte analiz edildi.
Uygulanan çözüm veya önerilen mimari
Kimlik sağlayıcı merkezde, uygulamalar federasyon tarafında konumlandı. Pilot için etkisi yüksek fakat geri dönüşü kolay bir SaaS seçildi. Grup tabanlı atama ve mümkün olan uygulamalarda SCIM provisioning kullanıldı. Yerel parola ile giriş kontrollü biçimde kapatılmadan önce yönetici kurtarma yolu test edildi. İşe giriş, rol değişimi ve ayrılış akışları İK kaynağına bağlandı; başarılı giriş kadar erişim kaldırma testi de kabul kriterine girdi.
Alternatifler ve karar gerekçesi
Parola kasası, federasyon desteklemeyen eski uygulamalarda kontrollü bir geçiş çözümü olabilir; gerçek SSO ve yaşam döngüsü sağlamaz. Reverse proxy tabanlı erişim bazı web uygulamalarını kapsar, fakat protokol ve destek sınırları vardır. Uygulamayı değiştirmek pahalı olabilir, ancak kritik ve destek dışı kimlik yapısında uzun vadede doğru seçenek olabilir. Her uygulama için risk, maliyet ve emeklilik tarihiyle ayrı karar verdik.
Güvenlik ve operasyonel riskler
Merkezi kimlik sağlayıcının kesintisi çok sayıda uygulamayı etkiler; acil erişim hesapları, izleme ve iletişim planı hazırlandı. Koşullu erişim politikaları önce rapor modunda ve pilot grupla test edildi. Token ömrü, oturum iptali ve ayrılış gecikmesi ölçüldü. Claim içine gereksiz kişisel veya organizasyon verisi koyulmadı. Sertifika sona erme tarihleri sahipli bir takvime alındı ve değişiklikler çift taraflı koordine edildi.
Çıkarılan Dersler
- SSO ile provisioning aynı işlev değildir.
- Uygulama envanteri olmadan offboarding tamamlanamaz.
- Kararlı kullanıcı eşleme anahtarı seçilmelidir.
- Acil erişim normal federasyondan bağımsız düşünülmelidir.
- Erişim kaldırma kabul testine dahil edilmelidir.
Kontrol Listesi
- Uygulama sahibi ve protokol belli mi?
- Yerel hesap yolu kontrol edildi mi?
- MFA pilotta test edildi mi?
- Provisioning ve deprovisioning doğrulandı mı?
- Sertifika yenileme sahibi var mı?