Mimari ve çalışma modeli
SAML tek oturum açmada kimlik sağlayıcı (IdP), assertion veya protokol mesajını özel anahtarıyla imzalar; hizmet sağlayıcı (SP) yayımlanmış metadata içindeki açık anahtarla imzayı doğrular. Sertifika süresi dolduğunda asıl risk şifreleme algoritması değil, tarafların aynı güven anahtarını farklı zamanlarda kullanmasıdır. Rotasyon planı bu dağıtık güven durumunu ölçülebilir bir geçiş olarak ele almalıdır.
Kesintisiz yöntem, eski ve yeni doğrulama sertifikalarının bir örtüşme penceresinde birlikte yayımlanmasına dayanır. Önce yeni anahtar üretilir ve metadata’ya ikinci KeyDescriptor olarak eklenir; tüm SP’lerin yeni metadata’yı aldıkları kanıtlandıktan sonra IdP yeni anahtarla imzalamaya başlar. Eski sertifika yalnız geri dönüş penceresi ve en uzun metadata önbellek süresi tamamlandıktan sonra kaldırılır.
Otomatik metadata alan SP’lerle elle sertifika yüklenen uygulamaları aynı kabul etmeyin. Envanterde entityID, metadata URL’si, yenileme aralığı, sertifika parmak izi, sahip ekip, test hesabı ve acil geri dönüş yolu bulunmalıdır. İmzalama sertifikası ile HTTPS sunucu sertifikası farklı yaşam döngüleridir; birini yenilemek diğerini kendiliğinden güncellemez.
- 1SP ve metadata envanteri
- 2Yeni anahtarı ikinci doğrulayıcı olarak yayımlama
- 3Yeni anahtarla imzaya geçiş
- 4Eski anahtarı kontrollü kaldırma
Tasarım parametreleri
- Örtüşme süresi
- En uzun SP metadata önbelleği, değişiklik penceresi ve geri dönüş süresinin toplamından kısa olmamalıdır.
- Anahtar saklama
- Özel anahtarın HSM, yönetilen anahtar kasası veya IdP’nin korumalı deposunda üretilmesi ve dışa aktarım politikasının kaydedilmesi gerekir.
- Algoritma ve boyut
- IdP/SP uyumluluğunu laboratuvarda doğrulayın; yalnız sertifika adını değiştirerek algoritma desteği varsaymayın.
- Saat doğruluğu
- NotBefore/NotAfter ve assertion zaman kontrolleri için IdP, SP ve izleme sistemleri ortak güvenilir zaman kaynağı kullanmalıdır.
Hesap ve uygulama örneği
Bir kuruluşta 42 SP’nin 30’u metadata’yı 6 saatte bir, 8’i günde bir yeniliyor, 4’ü elle yönetiliyorsa örtüşme yalnız 24 saat seçilmemelidir. Dört manuel uygulamanın sorumlusu ve test sonucu tamamlanana kadar eski sertifika tutulur; 24 saat önbellek, 4 saat değişiklik penceresi ve 8 saat geri dönüş payı için en az 36 saat teknik alt sınır hesaplanır.
Pilot sırası düşük riskli bir uygulama, kritik olmayan bir SaaS ve son olarak iş açısından kritik uygulamalar şeklinde yürütülür. Her adımda metadata’da iki sertifika, yeni imzayla başarılı giriş, eski imzaya geri dönüş ve hatalı imza reddi ayrı test edilir.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
# Metadata içindeki doğrulama sertifikalarını listeleyin
xmlstarlet sel -N md='urn:oasis:names:tc:SAML:2.0:metadata' \
-N ds='http://www.w3.org/2000/09/xmldsig#' \
-t -m '//md:KeyDescriptor[@use="signing"]//ds:X509Certificate' \
-v 'normalize-space(.)' -n idp-metadata.xml
# Sertifika tarih ve parmak izini kontrollü geçici dosyada inceleyin
openssl x509 -in signing-cert.pem -noout -subject -issuer -dates -fingerprint -sha256Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Bazı uygulamalar giriş kabul etmiyor | SP metadata önbelleği yenilenmemiş veya yalnız tek sertifika kabul ediyor olabilir. | SP’nin etkin metadata kopyasını ve beklenen parmak izini uygulama sahibinden doğrulayın. |
| Signature validation failed | Yanlış entityID, bozuk XML canonicalization veya beklenmeyen imzalama anahtarı söz konusu olabilir. | SAML trace içindeki issuer, certificate ve signature algorithm değerlerini güvenli bir testte karşılaştırın; assertion içeriğini loglarda maskeleyin. |
| Giriş aralıklı çalışıyor | Yük dengeleyici arkasındaki düğümlerde farklı güven depoları bulunabilir. | Her düğümü ayrı hedefleyerek yapılandırma sürümünü ve sertifika listesini karşılaştırın. |
Kabul ve doğrulama kontrolleri
- Tüm SP’ler için sahip, entityID ve metadata yenileme yöntemini kaydedin.
- Yeni ve eski sertifikayı aynı metadata’da doğrulayın.
- Yeni anahtarın özel kısmının yalnız IdP’de bulunduğunu doğrulayın.
- Başarılı ve hatalı imza testlerini en az bir pilot SP’de çalıştırın.
- Giriş hata oranı ve imza doğrulama olayları için değişiklik penceresi alarmı kurun.
- Geri dönüş süresi dolmadan eski sertifikayı kaldırmayın.
İlgili kavramlar
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
Güven sınırı ve hata alanı
Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
TLS ve sertifika doğrulaması
TLS iletişimin gizliliğini ve bütünlüğünü sağlar; sertifika doğrulaması karşı taraf kimliğinin kontrolüne yardımcı olur. Sertifika adı, zincir, geçerlilik süresi ve güvenilen kökler birlikte değerlendirilmelidir. Bir bağlantının şifreli olması uygulamanın yetkilendirmesinin doğru olduğu anlamına gelmez. Reverse proxy veya inspection kullanılıyorsa TLS oturumunun hangi noktada sonlandırıldığını çizimde açıkça gösterin. Hata teşhisinde sertifika kontrolünü kapatmak kalıcı çözüm değildir; yanlış hostname, eksik ara sertifika ve cihaz saatini ayrı inceleyin.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.