Çoğu işletme sahibi tek oturum açmayı "kullanıcı bir kere şifre yazsın, her yere girsin" kolaylığı olarak düşünür. Bu bakış tam olarak yanlış değil ama meselenin küçük yarısıdır. SSO'nun asıl işi rahatlık değil kontroldür: kimin nereye girdiğini tek yerden tanımlamak, bir personelin işten çıktığı gün tüm erişimini tek tıkla kapatmak, bayinin destek sistemine ayrı bir şifreyle girip o şifreyi bir forumda paylaşmasını engellemek. Kolaylık kullanıcıya kalan kısımdır; işletmeye kalan kısım denetlenebilirliktir.
Bir dijital ürün işinde kaç farklı kapı olduğunu düşün: satış paneli, bayi paneli, yönetim arayüzü, destek/talep sistemi, belki bir blog yönetimi, belki bir raporlama ekranı. Her kapının kendi kullanıcı tablosu olduğunda şifreler çoğalır, personel aynı şifreyi her yerde kullanır ve bir kapıdan giren saldırgan diğerlerini de açar. Dijital ürün satış yazılımı tarafında bu tabloyu düzeltmenin yolu, kimliği uygulamadan ayırıp merkezi bir kimlik sağlayıcıya taşımaktan geçer. Bu yazıda SSO'nun bir e-pin satış yazılımı üzerinde nasıl kurulduğunu, hangi protokolü seçmen gerektiğini ve en sık yapılan üç kritik hatayı anlatıyorum.
Tek şifre mi, tek kapı mı? SSO'nun yanlış anlaşılan tarafı
SSO, aynı şifreyi her yere yazmak demek değildir; şifrenin sadece bir yerde doğrulanması demektir. Kullanıcı kimlik sağlayıcıda oturum açar, sağlayıcı imzalı bir bilet üretir, uygulamalar o bileti doğrular. Şifre uygulamaların hiçbirine ulaşmaz. Bu ayrımı kavradığın anda güvenlik tartışması da netleşir: "tek noktadan girilirse tek noktadan kırılır" itirazı, şifrenin beş ayrı veritabanında hash'lenmiş halde durduğu senaryoyla karşılaştırıldığında zayıflar. Beş kasa yerine bir kasayı korumak, beş kasanın hepsini eşit özenle korumaktan her zaman gerçekçidir. Kritik olan, o tek kasayı güçlü kilitle donatmaktır: MFA, oturum süresi, cihaz kaydı ve giriş denemesi limiti.
OIDC, SAML yoksa kendi jeton mantığın mı?
Seçim, kimleri içeri alacağına göre değişir. Sadece kendi ekibin ve bayilerin girecekse, kurulumu en hızlı yol OpenID Connect'tir; JSON tabanlıdır, PHP tarafında kütüphane desteği geniştir ve mobil uygulamayla da uyumludur. Kurumsal bir müşteri kendi Active Directory hesaplarıyla girmek istiyorsa SAML 2.0 gerekir; daha ağırdır ama kurumsal dünyanın ortak dilidir. Kendi jeton mantığını yazmak ise üçüncü ve en riskli seçenektir: imza doğrulama, anahtar döndürme, süre kontrolü ve yeniden oynatma saldırısı korumasını sıfırdan doğru kurmak zordur. Pratik öneri şu: e-pin scripti tarafında OIDC'yi temel al, kurumsal talep geldiğinde SAML köprüsünü ek katman olarak devreye sok.
| Yöntem | Kime uygun | Kurulum eforu | Güçlü yanı | Dikkat |
|---|---|---|---|---|
| OpenID Connect (OIDC) | Ekip + bayi + mobil | Düşük | Modern, JSON tabanlı, yaygın kütüphane | Yenileme jetonunu güvenli sakla |
| SAML 2.0 | Kurumsal müşteri | Yüksek | Şirket dizinleriyle tam uyum | XML imza doğrulaması titizlik ister |
| Sosyal giriş (Google vb.) | Son müşteri tarafı | Çok düşük | Kayıt sürtünmesini azaltır | Yönetim paneline asla tek başına verilmez |
| LDAP doğrudan bağlama | Tek ofis, yerel ağ | Orta | Mevcut dizinle çalışır | Dışarıdan erişimde zayıf |
| Kendi jeton altyapın | Özel senaryolar | Yüksek | Tam esneklik | Güvenlik hatası riski en yüksek |
Bayi paneli, admin arayüzü ve destek sistemi: üç kapı bir anahtar
SSO'yu kurarken en çok atlanan nokta yetkilendirmenin kimlikten ayrı bir mesele olduğudur. Kimlik sağlayıcı sana "bu kişi gerçekten Ahmet" der; "Ahmet fiyat listesini değiştirebilir" demez. İkincisini uygulamanın kendi rol tablosu söyler. Doğru tasarım şöyle işler: bilet içinde grup/rol bilgisi taşınır, uygulama bu bilgiyi kendi izin matrisine çevirir ve her istekte yeniden kontrol eder. Böylece bir bayi, adres satırını kurcalayarak yönetim ekranına ulaşamaz. Ayrıca roller kimlik sağlayıcıda tanımlandığı için, yeni personel işe başladığında tek bir gruba eklenmesi yeterli olur; beş panelde beş kez kullanıcı açmakla uğraşmazsın. Bu, ölçeklenen bir dijital ürün satış scripti için görünmez ama çok büyük bir operasyon kazancıdır.
SSO kurulumu sonrası azalan destek taleplerinin dağılımı
- Şifre sıfırlama talepleri 45%
- Yetki ve erişim karmaşası 25%
- Çoklu hesap / mükerrer kayıt 20%
- Oturum ve cihaz sorunları 10%
"Çıkış yaptım ama çıkmamışım": oturum ömrü ve tek noktadan çıkış
SSO'nun en sinsi tarafı çıkış tarafıdır. Kullanıcı bir panelden çıkar, ama diğer panellerdeki yerel oturumu hâlâ geçerlidir; ortak bilgisayarda bu doğrudan bir güvenlik açığıdır. Çözüm, tek noktadan çıkış (single logout) akışını baştan kurmaktır: kullanıcı çıkış dediğinde kimlik sağlayıcıya bildirilir, sağlayıcı bağlı tüm uygulamalara sonlandırma sinyali gönderir. Buna ek olarak kısa erişim jetonu + kontrollü yenileme jetonu modelini benimse. Erişim jetonu 15-30 dakika yaşasın, yenileme jetonu sunucu tarafında iptal edilebilir olsun. Bir personelin yetkisini kaldırdığın anda en kötü senaryoda yarım saat içinde tüm kapılar kapanır. Yenileme jetonunu asla tarayıcı depolamasında tutma; HttpOnly ve Secure işaretli çerez tek doğru yerdir.
MFA'yı SSO'nun üstüne nasıl oturtursun?
Merkezi kimliğin en büyük avantajı, çok adımlı doğrulamayı bir kez kurup her yerde kullanmaktır. Ama herkese aynı sertliği uygulamak operasyonu boğar. Risk tabanlı bir kademe kur: son müşteri girişinde MFA isteğe bağlı olsun; bayi girişinde yeni cihaz veya yeni ülke tespit edildiğinde zorunlu olsun; yönetim paneline erişimde ise koşulsuz zorunlu olsun. SMS yerine TOTP uygulaması tercih et, mümkünse donanım anahtarını da destekle. Bir de kurtarma senaryosunu önceden yaz: telefonunu kaybeden yöneticinin sisteme nasıl döneceğini kriz anında düşünmek istemezsin. Yedek kodları kapalı zarf mantığıyla sakla, kurtarma işlemini iki kişinin onayına bağla ve her kurtarma denemesini ayrı bir güvenlik olayı olarak kaydet.
| Kontrol maddesi | Amaç | Nasıl test edilir | Öncelik |
|---|---|---|---|
| Jeton imzası her istekte doğrulanıyor | Sahte bilet üretimini engeller | İmzayı bozup istek gönder, 401 beklenir | Kritik |
| Rol bilgisi uygulamada yeniden kontrol ediliyor | Yetki yükseltmeyi önler | Bayi hesabıyla admin adresini dene | Kritik |
| Tek noktadan çıkış çalışıyor | Artık oturum bırakmaz | Bir panelden çık, diğerini yenile | Kritik |
| Erişim jetonu ömrü 30 dakikanın altında | Sızan jetonun değerini düşürür | Bekleyip isteği tekrarla | Yüksek |
| Yönetim erişiminde MFA zorunlu | En değerli kapıyı korur | MFA'sız admin girişi dene | Kritik |
| Giriş denemesi hız limiti var | Kaba kuvvet saldırısını kırar | Ardışık hatalı giriş yap | Yüksek |
| Kimlik sağlayıcı erişilemezse acil giriş yolu tanımlı | Kilitlenmeyi önler | Sağlayıcıyı kapatıp senaryoyu dene | Yüksek |
| Tüm giriş olayları denetim kaydına yazılıyor | Sonradan inceleme imkânı | Kayıtta IP, cihaz, sonuç alanlarını gör | Orta |
Kimlik sağlayıcı erişilemez olduğunda yönetim paneline girebileceğin, MFA korumalı ve IP kısıtlı tek bir yerel kırılma-cam hesabı tut. Bu hesabın her kullanımı sana bildirim göndersin. Yoksa sağlayıcı çöktüğünde kendi sistemine bakamaz hale gelirsin.
Son müşteri tarafında SSO işine yarar mı?
Burada dengeyi iyi kurmak gerekir. Son müşteri için amaç güvenlik yönetimi değil, kayıt sürtünmesini azaltmaktır. Google veya Apple ile tek tıkla giriş, ilk sipariş dönüşümünü hissedilir şekilde yükseltir çünkü kullanıcı şifre üretmek zorunda kalmaz. Ancak burada üç kural var. Birincisi: e-posta adresini doğrulanmış kabul etmeden önce sağlayıcının doğrulama alanını kontrol et. İkincisi: aynı e-postayla hem klasik hem sosyal kayıt olan kullanıcıları birleştirmek için hesap eşleştirme akışı yaz, yoksa bakiyesi bir hesapta, siparişi diğerinde kalır. Üçüncüsü: bakiye, cüzdan veya iade gibi para içeren işlemlerde ek doğrulama iste. Böylece epin yazılım tarafında hem kolaylığı hem hesap güvenliğini aynı anda korursun.
Kimliği tek yerden yönet, kapıları tek tıkla kapat
Pinova'nın rol ve yetki mimarisi merkezi kimlik entegrasyonuna hazırdır; bayi, yönetim ve destek erişimini tek matriste yönetirsin. Yetki katmanına ve lisans seçeneklerine göz at.
SSO kurunca tek noktadan kırılma riski artar mı?
Yönetilmezse artar, yönetilirse azalır. Beş ayrı şifre veritabanını eşit özenle korumak pratikte imkânsızdır; tek kimlik sağlayıcıyı MFA, hız limiti ve kısa oturum ömrüyle sertleştirmek ise mümkündür. Risk dağılmaz, yoğunlaşır ve yoğunlaşan riski korumak daha kolaydır.
Küçük bir ekibim var, SSO benim için abartı mı?
Üç kişilik bir ekipte bile panel sayısı dörde çıkmışsa değer üretir. Asıl fayda personel ayrılığında ortaya çıkar: erişimi tek yerden kapatmak, dört panelde dört kez hesap silmeye çalışıp birini atlamaktan güvenlidir.
Mevcut kullanıcı şifrelerim ne olacak?
Geçiş kademeli yapılır. Bir süre hem yerel giriş hem SSO açık kalır, kullanıcı ilk SSO girişinde mevcut hesabıyla eşleştirilir, eşleştirme tamamlanan hesaplarda yerel şifre kapatılır. Böylece kimse kapıda kalmaz.
SSO oturumu ne kadar yaşamalı?
Erişim jetonu için 15-30 dakika, yenileme jetonu için 7-30 gün makul bir aralıktır. Yönetim paneli erişimini bu aralığın kısa ucunda tut ve hassas işlemlerde şifreyi yeniden sor.
Tek oturum açma, panel sayısı arttıkça lüksten ihtiyaca dönüşen bir altyapı kararıdır; erken kurarsan sessizce çalışır, geç kurarsan göç maliyeti öder. Yetki matrisinin, bayi rollerinin ve yönetim erişiminin gerçek bir kurulumda nasıl ayrıştığını görmek için canlı demo üzerinden farklı rollerle dolaş, hangi ekranın kime açıldığını kendin test et; kararını verdiğinde lisanslama adımı sadece bir formalite olacak.