Bir tedarikçinin "Office 365 SSO desteği vardır" cümlesi, aslında beş farklı teknik gerçeği kastedebilir. Bazıları yalnızca OAuth üzerinden temel oturum açmayı sunar; bazıları SCIM ile otomatik kullanıcı sağlama yapar; bazıları ise SAML 2.0 iddiasını sadece pazarlama sayfasında taşır, sözleşme ekinde değil. İhale değerlendiren ekipler için asıl risk, teknik bir eksiklik değil, bu belirsizliğin satın alma sonrası entegrasyon fazına taşınmasıdır. Aşağıdaki kontrol listesi, o belirsizliği ihale aşamasında kapatmak için hazırlandı.
İhale şartnamesine "SSO destekleniyor mu?" yazmak yeterli değil. Tedarikçiye hangi protokolü, hangi sürümde desteklediğini yazılı olarak sorun. Office 365 ortamında beklentiniz genellikle şudur:
Pratik bir uyarı: birçok satıcı SSO'yu destekler ama SCIM sağlamayı desteklemez. Bu durumda 500 kullanıcılı bir dağıtımda hesap yaşam döngüsünü elle yönetmek zorunda kalırsınız. Bu farkı ihale masasında görmek, altı ay sonra bir denetimde görmekten çok daha ucuzdur.
SSO, kim olduğunuzu doğrular; ancak o kimliğin sistem içinde neye eriştiğini belirlemez. İhale değerlendirmesinde bu iki katmanı ayrı ayrı sorgulayın. Rol tabanlı erişim kontrolü (RBAC) Azure AD grup üyeliklerinden otomatik türetilebiliyor mu, yoksa yetkilerin ürün içinde ikinci kez tanımlanması mı gerekiyor? İkinci senaryo, kimlik yönetiminizin ikiye bölünmesi demektir ve compliance ekibiniz için sürekli bir mutabakat yükü yaratır.
Vemco gibi mevcut IT sistemlerinizle entegre olacak şekilde tasarlanmış çözümlerde, kimlik federasyonunun mevcut Azure AD kiracınızla nasıl konuşacağını erken netleştirmek, dağıtım süresini kısaltır.
Office 365 tarafında zaten koşullu erişim politikalarınız varsa, SSO ile bağlanan üçüncü taraf uygulamanın bu politikalara saygı gösterip göstermediğini sorun. Bazı entegrasyonlar, federasyondan sonra kendi oturum sürelerini uygular ve Azure AD'nin belirlediği token yaşam süresini yok sayar. Bu, güvenlik ekibinizin belirlediği zaman aşımı kurallarını sessizce delen bir açıktır.
SSO teknik bir konu gibi görünse de, compliance ekibi için asıl mesele hangi verinin nerede işlendiğidir. Kimlik doğrulamada hangi kullanıcı öznitelikleri (e-posta, UPN, grup adları) tedarikçiye aktarılıyor? Bunlar nerede saklanıyor, ne kadar süre tutuluyor?
Örneğin Vemco'nun ziyaretçi sayım yaklaşımı, kişisel tanımlama yapmadan, personeli hariç tutarak ve yalnızca toplu sayılar üreterek GDPR uyumlu çalışır. Kimlik doğrulama katmanınızı seçerken de aynı prensibi uygulayın: yalnızca gerekli öznitelikler aktarılmalı. İhale şartnamesine barındırma seçeneklerini (barındırılan bulut ya da özel bulut) ve veri saklama sürelerini açıkça yazın. Sertifikasyon iddialarını — SOC 2, ISO 27001 gibi — tedarikçiden yazılı olarak belge halinde isteyin; pazarlama sayfasındaki bir logo, denetim kanıtı sayılmaz.
Teknik yeterlilik kadar, o yeterliliğin sözleşmeye nasıl yansıdığı da önemlidir. Değerlendirme sürecinde şunları netleştirin:
2005'ten bu yana faaliyet gösteren ve 95'ten fazla ülkede 2000'i aşkın müşteriye hizmet veren tedarikçilerle çalışırken gördüğümüz ortak nokta şu: entegrasyonun sağlamlığı, ürünün ana işlevi kadar önemlidir. Bir mağaza analitiği çözümünün sayım doğruluğu sözleşmeyle taahhüt edilen minimum %96, koşullar — aydınlatma, mağaza düzeni, ziyaretçi davranışı — elverdiğinde tipik olarak %98–99 olabilir; ancak bu değer, sistemin doğru kişiler tarafından güvenle erişilebildiği ölçüde iş değerine dönüşür. Kimlik katmanı düzgün kurulmazsa, en doğru veri bile yanlış ellerde ya da erişilemez halde kalır.
Kısacası ihale kontrol liste