Parola Karmaşasına Son Verin
Bir çalışanın hatırlamak zorunda olduğu parolaları düşünün. Etki alanı, ERP, seyahat sistemi, departmanın aldığı iki SaaS aracı, finans ekibinin kullandığı başka bir uygulama… Sekiz ile yirmi arasında parola. Her birinin uzunluk, karakter, son kullanma tarihi ve kullanıcı adı kuralları farklı.
İnsanlar doğal olarak aynı parolayı yeniden kullanır, bir yere not eder veya her üç ayda bir sonuna yeni bir rakam ekler. Dikkatsizlikten değil; yirmi ayrı parolayı güvenle yönetmek gerçekçi olmadığı için.
Bedelini hem çalışan hem kurum öder:
| Çalışan için | Kurum için |
|---|---|
| Farklı tarihlerde süresi dolan yirmi ayrı parola | İşe girişte her uygulamada elle hesap açılması |
| Süresi dolan her parola için sıfırlama talebi | İşten ayrılışta her uygulamadaki hesabı bulup kapatma yükü |
| Her uygulamada güçlü ve benzersiz parola kullanmanın zorluğu | Her araçta yönetici yetkisini farklı bir kişinin belirlemesi |
| Aynı parolanın fark edilmeden birden çok yerde kullanılması | Bu kişi nelere erişebilir? sorusuna tek yanıtın olmaması |
Tek oturum açma bütün bu dağınıklığın yerine bir kez, güçlü biçimde doğrulanan tek kimliği koyar. Güçlü doğrulamayı uygulanabilir kılan da budur. Çalışandan yirmi ayrı girişte donanım anahtarı kullanmasını isteyemezsiniz. Bir kez kullanmasını isteyebilirsiniz.
Nasıl Çalışır?
Kimliği Uygulama Değil, Mirket Doğrular
Mirket kimlik sağlayıcı (IdP) olur. Uygulama ise servis sağlayıcı (SP) olarak kendi kullanıcı kayıtlarını, rollerini ve oturumlarını tutmaya devam eder; ancak parolanın doğruluğunu kontrol eden taraf olmaktan çıkar.
- Kullanıcı giriş yapar — Mirket portalından veya doğrudan uygulamadan başlayıp Mirket’e yönlendirilerek. Bazı uygulamalar yalnızca bir akışı desteklediği için her iki yol da önemlidir.
- Mirket kimliği doğrular — parola ve ikinci faktörle ya da FIDO2 veya WebAuthn gibi parolasız bir yöntemle.
- Mirket imzalı bir kimlik beyanı üretir — kullanıcının kimliği, öznitelikleri ve üye olduğu gruplar bu beyanda yer alır.
- Uygulama imzayı doğrular ve kullanıcıyı grup üyeliğine karşılık gelen rolüyle içeri alır.
Öznitelikler ve grup üyelikleri her girişte aktarıldığından dizindeki bir değişiklik, uygulamanın elle güncellenmesi beklenmeden sonraki kimlik beyanına yansır.

Federasyon ve kimlik doğrulama
SAML 2.0 · OpenID Connect (OIDC)

Yetkilendirme
OAuth 2.0 — devredilmiş yetkilendirme gerektiren uygulama ve API’ler için OIDC’nin temelini oluşturan çatı.
Uygulamalar da Sunucular da Tek Ekranda
Asıl fark burada ortaya çıkar: Kimlik sistemi ile PAM sonradan birbirine bağlanmış iki ayrı ürün değildir. Modüller aynı platformun parçalarıdır.
Modüllerin görevlerini net ayıralım. SSO, uygulamaların federatif girişini sağlar. Windows sunucusuna RDP, Linux sunucusuna SSH veya yayımlanmış masaüstü uygulamasına erişim ise Mirket PAM yetkilendirir; kimlik bilgilerini PAM aktarır, oturumu PAM kaydeder. SSO’nun katkısı bu kaynakları aynı portalda göstermesidir.
Kullanıcı bir kez giriş yapar; portal erişim yetkisi bulunan tüm kaynakları gösterir.
Yönetici, uygulamalar için ayrı bir portala, sunucular için başka bir araca geçmez. Her kaynağın yetkisi ilgili modülden gelir ama hepsi yalnızca erişim izni olan kaynakları içeren tek listede görünür.
BT ekipleri için bu liste erişim gözden geçirmesini de kolaylaştırır. Bu kişi nelere erişebilir? sorusunun yanıtı artık sekiz farklı sistem yöneticisinden toplanmaz.
Kimlik Sağlayıcı ve MFA Aynı Platformda. Güvenlik Daha Güçlü.
Mirket ile federasyon, tüm uygulamaların önüne tek bir giriş noktası koyar. Bu noktayı korumak, yirmi dağınık girişi ayrı ayrı korumaktan çok daha etkilidir.
| Parolasız oturum açma | SSO ile kullanıcılar parola yazmak yerine tarayıcıda FIDO2 veya WebAuthn ya da kayıtlı telefondan onay gibi desteklenen parolasız yöntemlerle doğrulanabilir. Tek girişle uygulamalar açılır; oltalamayla çalınacak, yeniden kullanılacak veya sıfırlanacak parola yoktur |
| Oltalamaya dayanıklı yöntemler | FIDO2 ve WebAuthn; Windows Hello, Touch ID, passkey veya donanım anahtarıyla yirmi ayrı giriş yerine tek bir giriş noktasını korur |
| Sayı eşleştirmeli Push | Ekrandaki sayı telefona girilmeden onay verilemez; alışkanlıkla yapılan onaylar önlenir |
| Uygulama bazlı politika | Finans sistemi intranetten daha güçlü doğrulama isteyebilir. Kimlik aynı, güvenlik seviyesi farklıdır |
| Uyarlanabilir doğrulama | Kaynak IP, cihaz, zaman planı ve grup bilgisi doğrulama seviyesini belirler |
Bunlar için kimlik sağlayıcının önüne ikinci bir üretici koymanız gerekmez. Doğrulama yöntemleri ve kimlik sağlayıcı aynı platformda olduğundan politika, entegrasyonla birbirine bağlanan iki kural değil, tek kuraldır.
Tehdit Tespiti
Tüm Uygulama Girişleri Tek Noktada Görünür
Federasyondan önce her giriş, uygulama kayıt tutuyorsa kendi günlüğünde bir satırdır. Otuz ayrı uygulamanın kayıtlarını ilişkilendirmek kolay değildir.
Federasyondan sonra tüm uygulama girişleri aynı noktadan geçer. Bunun iki önemli sonucu vardır.
Lisans kullanımına net bakış. Lisanslar kullanıcı bazında alınır ve yenilenir. Giriş kayıtları, hangi kullanıcıların hangi uygulamaları gerçekten açtığını gösterir.
Çok daha güçlü alarmlar. Mirket ITDR aynı girişleri davranış, kaynak ve örüntü bakımından değerlendirir. Federasyon sayesinde analiz tek uygulamayla sınırlı kalmaz. On beş uygulamaya erişen bir kimliğin davranış örüntüsü oluşur; çalınmış bir oturum, tek tek girişler başarılı olsa bile bu örüntüden sapabilir.
Yetenekler
| SAML 2.0 kimlik sağlayıcı | Mirket, SAML 2.0 destekleyen uygulamalarda IdP olarak çalışır |
| OpenID Connect kimlik sağlayıcı | OIDC kimlik belirteci kullanan uygulamalar, IdP ve SP tarafından başlatılan akışlarda aynı kimliğe bağlanır |
| OAuth 2.0 yetkilendirme | Oturum açma beyanı yerine devredilmiş yetki gerektiren uygulama ve API’ler için OIDC’nin temelindeki yetkilendirme çatısı |
| IdP ve SP tarafından başlatılan giriş | Kullanıcı portaldan veya doğrudan uygulamadan başlayabilir |
| Tek çıkış | Çıkış işlemi federatif uygulamalara iletilir; açık oturumlar geride kalmaz |
| İmzalı SAML yanıtı | İmzalı beyan sayesinde servis sağlayıcı, yanıtı Mirket’in ürettiğini ve aktarım sırasında değişmediğini doğrular |
| Meta veri ve sertifika dışa aktarımı | Meta veri XML’i ve imzalama sertifikası, servis sağlayıcıya aktarılmak üzere .crt veya .pem biçiminde dışa aktarılır |
| Öznitelik eşleme | Dizin öznitelikleri, her uygulamanın beklediği user.email, user.principalName, user.givenname gibi claim adlarına eşlenir |
| Özel dizin öznitelikleri | Dizininizdeki standart dışı öznitelikler kimlik beyanına eklenebilir |
| Rol ve grup ataması | Grup üyelikleri kimlik beyanıyla taşınır; uygulama içindeki yetkilendirme dizini takip eder |
| Uygulama bazlı politika ve RBAC | Her uygulamanın kendine özgü politikaları, atanmış kullanıcıları ve grupları vardır |
| Uygulama bazlı markalama | Portaldaki her uygulama kendi adı ve logosuyla gösterilir |
Dizinler: Active Directory · OpenLDAP · Entra ID · Google Workspace · üçüncü taraf kimlik sağlayıcıları. Birden çok kaynak eş zamanlı kullanılabilir; iki etki alanındaki aynı kullanıcı adı, önek girilmeden çözümlenir.
- Array Networks
- Barracuda
- Check Point
- Cisco
- Citrix
- CyberArk
- Delinea
- SonicWall
- Fortinet
- F5
- Ivanti
- Microsoft
- Palo Alto Networks
- Proofpoint
- Sophos
- Canonical
- VMware
- WatchGuard
- XLOG
Denetim ve Uyumluluk
Hiçbir ürün tek başına mevzuata uyumluluk sağlamaz. Ancak denetçiye incelenebilir, somut kanıtlar sunabilir. Federatif kimlik doğrulama özellikle şu maddelerle ilişkilidir.
ISO/IEC 27001:2022
A.5.16, A.5.18Kimlik yaşam döngüsü ve erişim hakları: hesap açma, gözden geçirme ve kaldırma. Federasyon, uygulama başına ayrı işlem yerine merkezi yönetim sağlar
PCI DSS v4.x
Req. 8.2Her kullanıcının ayrı tanımlanması ve paylaşılan hesapların kaldırılması. Federasyonla erişilen uygulamalar yerel giriş yerine doğrulanmış kimliği kullanır
NIS2
Art. 21Erişim kontrolü ve kimlik doğrulamanın her araçta ayrı ayrı değil, sistemler genelinde tutarlı uygulanması
GDPR
Art. 32Kişisel verilere erişimin kontrol edilmesi ve kimin eriştiğinin izlenebilmesi; kurum içi kurulumda ilgili kimlik verilerinin ortamınızdan çıkmaması
Kurulum Seçenekleri
Kurum içinde veya hizmet olarak. Aynı modül, iki kurulum seçeneği.
Kurum içi kurulum, SSO için özellikle önemlidir. Kendi kimlik sağlayıcınızı çalıştırmak eskiden olağandı; bugün büyük platformlar bulut öncelikli, kurum içi alternatifler ise çoğunlukla eski sistemler veya bakımını kendiniz üstlendiğiniz projeler. Mirket, desteklenen kurum içi SSO çözümüyle veri merkezinizde çalışır; dizin, kimlik beyanları ve doğrulama verileri sizin altyapınızda kalır.
Hizmet olarak kullanımda aynı ürünü Mirket çalıştırır; dizin entegrasyonu ağınızdaki bir ajan üzerinden sağlanır.
Uygulama tarafında kurulacak bir bileşen yoktur. Federasyon, yapılandırma bilgilerinin karşılıklı paylaşılmasıyla kurulur: Mirket Entity ID, giriş ve çıkış URL’leri ile sertifikayı sağlar; uygulama ise kendi tanımlayıcısını, yanıt URL’sini ve beklediği öznitelik adlarını iletir.
Lisanslama, federasyona bağladığınız uygulama sayısından bağımsız olarak tanımlı kullanıcı sayısına dayanır. Otuzuncu uygulamayı eklemek lisans sayısını değiştirmez.

