Monosign MFA: tasarım, yaygınlaştırma ve sorun giderme
Neler değişti
Her içerik güncellemesi sürümlenir. Bir sürümü seçerek öncekiyle karşılaştırın.
Sürüm 9 → 10
GüncellemeErişim kararları ve kurtarma üzerine yeni modül: erişim kısıtlamaları ve politika tanımları, passkey'ler ve parolasız oturum açmanın işletimi, Kerberos ve MFA, parola kurtarma, hesap kilidini açma, Windows oturum açma kutucukları ve kimlik doğrulama (identity verification).
3 ders güncellendi
İçerik güncellemesi. Kayıtlı öğrenciler bilgilendirildi.
Monosign'da bir oturum açmanın devam edip edemeyeceğine karar veren iki araç vardır. Birbirine benzerler ama çok farklı davranırlar.
| Araç | Ne yapar | Tipik kullanım |
| --- | --- | --- |
| Erişim kısıtlaması | Bir nesneye, örneğin bir kullanıcıya, tek bir uygulamada izin verir ya da reddeder | Tek bir hesabı engellemek ya da belirli saatlerde dışarıda tutmak |
| Kimlik doğrulama politikası | Kapsama ve önceliğe göre bir oturum açmanın hangi faktör ve adımları gerektirdiğine karar verir | Ofis dışında MFA, yöneticiler için passkey |
Kısıtlama hiçbir zaman MFA istemez. Oturum açmaya yalnızca izin verir ya da onu reddeder.
### Erişim kısıtlamaları
Management → Security → `Restrictions` ya da kullanıcıdaki `Access Restrictions` sekmesi. Bir satırda `Object`, `Access Types` (`Allow` veya `Deny`), `Scope Object` (uygulama), `Start Date`, `End Date` ve isteğe bağlı bir `Cron` bulunur.
Destek kayıtlarının çoğunu üç kural açıklar:
- **Yalnızca oturum açarken kontrol edilir.** Yeni bir `Deny`, açık olan bir oturumu sonlandırmaz. Bir olay sırasında kısıtlamayı ekleyin ve ayrıca kullanıcının oturumlarını Management → `Sessions` sayfasından kapatın.
- **Eşleşen ilk `Allow` kazanır.** Değerlendirme orada durur ve sonraki bir `Deny` satırı yok sayılır. Bir `Deny` eklemeden önce kullanıcının mevcut satırlarını gözden geçirin.
- **Kapsam, kullanıcının oturum açtığı uygulama olmalıdır.** Başka bir uygulamaya kapsamlanmış satırın o oturum açmaya etkisi olmaz.
::diagram mfa-restriction-evaluation
`Cron`, bir `Deny` satırını günün belirli bir saat aralığıyla sınırlar. Saatleri **UTC**'dir; sunucunun ya da kullanıcının yerel saati değildir. İstanbul'daki (UTC+3) bir ofis yerel saatle 18:00 ile 08:00 arasını engellemek istiyorsa `0 15-23,0-4 * * *` yazar. v2026.10 sürümünden itibaren aralık yazıldığı gibi uygulanır. Önceki sürümlerde `Cron` içeren ve ömrü bir günden uzun olan bir `Deny` günün her saatinde engelliyordu; bu nedenle yükseltmeden sonra bu tür satırları yeniden test edin.
`Remove`, satırın bitiş tarihini ayarlayarak onu sonlandırır. Satır geçmiş olarak kalır.
### Politika tanımları
Tanımlar Management → Security → `Policies` altındadır. Koşullu erişim lab'ı tam bir politika seti kurar; buradakiler düzenleyicinin kendi kurallarıdır:
- **`Type` bir kez seçilir.** Yalnızca tanımı oluştururken seçilebilir. `Generic` yalnızca filtreleme içindir; bir oturum açma akışı için `Authentication` gerekir. Tanım klonlanamaz ve türü değiştirilemez; yanlış türle kaydedilen bir tanımın yerine yenisi oluşturulur.
- **`Authentication` türündeki bir tanım en az bir `Scope` öğesi ve bir `Flow` öğesi ister.** Akış öğeleri `Actions` sekmesindedir.
- `Priority` 1 ile 10 arasındadır ve her tanımın adı benzersiz olmalıdır.
- Bir erişim paketinin kullandığı tanım devre dışı bırakılamaz ve kaldırılamaz. Önce paketten ayırın.
Passkey'ler katalogdaki en güçlü faktördür ve kendi işletim kurallarını getirir. Bunları ilk destek kaydından sonra değil, yaygınlaştırmadan önce planlayın.
### Kayıt kullanıcıya aittir
Passkey, Account uygulamasında, kullanıcının kendi oturumu içinde kaydedilir. Bir yönetici Management üzerinden kullanıcı adına passkey kaydedemez; yardım masası da bir ekip için passkey'leri önceden hazırlayamaz. İnsanların kendi kayıtlarını yapacağı şekilde planlayın: kısa bir kılavuz, bir zaman aralığı ve geri dönüş yolu olarak ikinci bir passkey ya da başka bir faktör.
### Son passkey'i kaldırmak
Kullanıcı son passkey'ini sildiğinde `Passkeys` yöntemi onun için devre dışı kalır. Bu tek faktörüyse, yeniden kayıt yapana kadar hiçbir MFA faktörü olmaz. Otomatik olarak başka bir şeye dönülmez. Bunu cihaz emekliye ayırma sürecine ekleyin: önce yeni cihazda kayıt yapılır, sonra eskisi kaldırılır.
### Her oturum açma adresi bir tenant host olmalıdır
Passkey, kaydedildiği web adresine bağlıdır ve Monosign bu adresi account tenant host'larından türetir. Kullanıcılar oturum açma sayfalarına account tenant host olarak kayıtlı olmayan bir host adı üzerinden ulaşıyorsa, tarayıcı passkey adımını reddeder; aynı host üzerinde parola ile oturum açma ise çalışmaya devam eder. API günlüğünde o zaman `Tenant host not found for host` görünür.
Bu nedenle müşteri yeni bir host adı eklediğinde, önce bunun account tenant host olarak kayıtlı olduğunu kontrol edin. Ayrıca bir host üzerinde kaydedilen passkey'in başka bir host üzerinde kabul edilmediğini unutmayın.
### `Passwordless Login` ve neyin yerini aldığı
`Passwordless Login` açıkken kullanıcı yalnızca passkey ile oturum açabilir. Bu oturum açma, **kullanıcının kendi** iki faktör ayarı için MFA sayılır. İkinci faktör isteyen bir **kimlik doğrulama politikasını** ise karşılamaz: böyle bir politikanın kapsadığı uygulamada kullanıcıdan passkey'den sonra yine MFA istenir. Bekleyen bir parola değişikliği de yine istenir. Bunu müşteriye anlatın; yoksa ilk passkey kullanıcıları bunu arıza olarak bildirir.
### Kerberos yine farklıdır
Etki alanına bağlı cihazlarda Kerberos ile oturum açma parola istemini kaldırır; ancak diğer parolasız oturum açmalardan farklı olarak oturum MFA doğrulanmış sayılmaz. MFA'sı etkin bir kullanıcı ya da kimlik doğrulama düzeyi MFA gerektiren bir uygulama, ticket'tan sonra yine MFA sorgusu alır. Bu beklenen davranıştır. Müşteri belirli bir uygulamada istem istemiyorsa bu, uygulamanın MFA ayarıyla ilgili bir karardır; Kerberos arızası değildir.
::diagram mfa-passwordless-and-mfa
> İpucu: Hem platform passkey'leri hem de FIDO2 güvenlik anahtarları için kullanılacak yöntem `Passkeys` yöntemidir. Eski `Security Key` satırını devre dışı bırakın.
Oturum açamayan kullanıcılar, yardım masası çağrılarının en büyük bölümünü oluşturur. Monosign'da onlar için self servis yollar vardır ve her birinin, yardım masasının bilmesi gereken sınırları bulunur.
### Parola kurtarma
Parolasını unutan kullanıcı boarding sayfasında `I don't remember my password` ile başlar, kendini tanıtır ve kim olduğunu bir MFA faktörüyle, güvenlik sorularıyla ya da ikisiyle birlikte kanıtlar. Anahtarlar System → `Configurations` → `Boarding` sekmesindedir.
İki davranış destek kaydına yol açar:
- **Başka bir faktör varsa SMS gizlenir.** Kullanıcının birden fazla doğrulanmış faktörü varsa, kurtarma sayfasında SMS faktörü sunulmaz. Uygulaması sıfırlanan ya da telefonu değişen kullanıcı orada SMS'e dönemez ve yardım masasının destek olması gerekir. Kullanıcıların hangi faktörleri kaydetmesi gerektiğine karar verirken bunu hesaba katın.
- **Bir kod zaten yolda olabilir.** Kurtarma, yeniden gönderme bekleme süresini oturum açma ile paylaşır; kod gönderimi dersi bunu açıklar.
### Hesap kilidini açma
Kilitlenen kullanıcı, aynı sayfadan SMS veya mobil push ile gönderilen tek kullanımlık bir kodla hesabının kilidini açabilir. Sınırlar şunlardır:
- Kilit açma **yalnızca kilidi kaldırır**. Parolayı sıfırlamaz ve başka bir nedenle, örneğin İK ya da bir yönetici tarafından devre dışı bırakılmış bir hesabı yeniden etkinleştirmez. Böyle bir kullanıcı kilit açmayı tamamlar ve yine de oturum açamaz.
- Kod bir saat geçerlidir. v2026.09 sürümünden itibaren yanlış kodlar istek başına beş ile sınırlıdır.
- Yalnızca SMS ve push sunulur; o da yalnızca bunları daha önce kaydedip doğrulamış kullanıcılara.
### Windows oturum açma ekranında
Windows'a giremeyen bir kullanıcının bu sayfalara ulaşacak tarayıcısı yoktur. Monofor Identity Client oturum açma ekranına ayrı kutucuklar ekler ve her birinin tek bir işi vardır:
| Kutucuk | Amaç |
| --- | --- |
| `Monosign MFA Credential Provider` | Windows parolası, ardından Monosign MFA |
| `Monosign QR Login`, `Monosign Push Login` | Monofor Identity uygulamasıyla parolasız oturum açma |
| `Self Service Portal` | Kilit ekranından parola sıfırlama ve hesap kilidini açma |
İkinci bir cihazı olmayan saha personeli için kurulum programında seçilecek özellik `Self Service Portal` özelliğidir. Diğer kutucuklar unutulan bir parolayı sıfırlamaz.
::diagram mfa-self-service-paths
### Kimlik doğrulama (identity verification)
Bazı erişimler bir faktörden fazlasını gerektirir: kişinin iddia ettiği kişi olduğunun kanıtı. Identity → `Verification` altında bir kimlik kanıtlama sağlayıcısını kaynak olarak bağlarsınız. Kullanıcı, Account uygulamasından sağlayıcının barındırdığı akışta belge ve selfie kanıtlamasını tamamlar ve kullanıcıya kaydedilen, `IAL1` ile `IAL3` arasında bir güvence düzeyiyle geri döner.
Bunu zorunlu kılmanın iki yolu vardır:
- **Tek bir kullanıcı için, hemen**: kullanıcının `Identity Assurance` paneli → `Request identity verification`.
- **Bir politikanın eşleştiği herkes için**: bir kimlik doğrulama politikasındaki `Require Identity Verification` politika eylemi. Kullanıcının düzeyi istenenin altındaysa oturum açarken bir istek oluşturur.
Monosign belgeleri kendisi kontrol etmez; bunu sağlayıcı yapar. Güvenlik soruları, magic link'ler ve erişim kısıtlamaları kimlik kanıtlamanın yerini tutmaz.