Yardım Masası Farkında Olmadan Bir Kimlik Doğrulama Sistemine Dönüştü
Neredeyse her kurumda parola sıfırlama aynı şekilde ilerler. Biri arar, kim olduğunu söyler ve birkaç soruyu yanıtlar: çalışan numarası, yönetici adı, doğum tarihi veya kurum içi wiki ya da LinkedIn profilinde bulunabilecek bir bilgi. Telefona yanıt veren kişi parolayı sıfırlar ve geçici parolayı paylaşır.
Bu aslında bir kimlik doğrulama kararıdır. Üstelik bu kararı, duyduğu bilgileri gerçekten doğrulayamayan ve başarısı talepleri ne kadar hızlı kapattığıyla ölçülen biri saniyeler içinde veriyor.
Bu, büyük kurumlara sızmak için en sık istismar edilen yollardan biridir. Kullanıcı adını bilen bir saldırgan, doksan saniye boyunca ikna edici olabiliyorsa bir güvenlik açığına ihtiyaç duymaz. Savunması zor, istismarı kolaydır: ne yaması ne de imzası vardır. Kandırılan çalışan ise kendisine öğretilen işi yapmıştır.
İş yükü arttıkça sorun büyür. Haftada onlarca sıfırlama talebiyle uğraşan bir ekip her talebi güvenlik olayı gibi ele alamaz; aksi hâlde başka hiçbir işe zaman kalmaz.
Çözüm, telefondaki çalışana daha iyi bir konuşma metni vermek değil. Doğrulamayı telefon görüşmesine bırakmamaktır.
Nasıl Çalışır?
Girişinizi Koruyan Doğrulama, Kurtarma İşlemini de Korur
- Kullanıcı portalı açar ve kimliğini belirtir.
- Mirket ikinci faktörle doğrulama ister: push bildirimi, uygulama kodu, TOTP, SMS veya izin verdiğiniz başka bir yöntem. Güvenlik sorusu, tek başına doğrulama yerine ek adım olarak kullanılabilir.
- Doğrulama başarılıysa kullanıcı politikanıza uygun yeni parola belirler, hesabının kilidini açar veya yeni telefonunu kaydeder.
- Değişiklik dizine yazılır ve işlem diğer güvenlik olayları gibi kayıt altına alınır.
Parolayı sıfırlayan kişi, kayıtlı cihazın da sahibidir. İkna edilecek veya acele ettirilecek bir görevli yoktur; cuma günü mesai bitiminde yanlış verilebilecek bir karar da yoktur.
Peki Ya Telefonun Kendisi Kaybolursa?
Bir güvenlik mimarının Self-Servis portalı hakkında soracağı ilk sorulardan biridir. Diyagramdan önce açık bir yanıtı hak eder.
Eski telefon hâlâ kullanıcıdaysa geçiş kolaydır. Yedek QR koduyla kayıtlı tüm hesaplar tek taramada yeni telefona taşınır; yardım masasına ihtiyaç duyulmaz.
Asıl zor senaryo telefonun kaybolmasıdır. Çünkü kullanıcının kimliğini doğrulayan cihaz da kayıptır. Kurtarma yolu bulunmalı, ancak kaldırmak istediğimiz telefonla doğrulama sürecine gizlice geri dönmemelidir.
Mirket, kurtarma sürecini sabit bir akış yerine yapılandırılabilir hâle getirir. Çünkü bir bankanın hazine ekibiyle perakende mağazasındaki dönemsel çalışanlar aynı güvenlik seviyesine ihtiyaç duymaz. Üç mekanizmadan hangisinin tek başına yeterli olacağını, hangilerinin birlikte kullanılacağını siz belirlersiniz:
| Süreli kayıt bağlantısı | Kullanıcının e-posta kutusuna, belirlediğiniz geçerlilik süresiyle gönderilir. Kurumsal hesaba erişimi kanıtlar; bu önemli olsa da tek başına her şeyi kanıtlamaz |
| Kişisel güvenlik soruları | Portalda yanıtlanır; doğrulamanın tamamı yerine ek bir kontrol olarak kullanılır |
| Yöneticinin oluşturduğu bağlantı | Kontrollü kurtarma seçeneği: yetkili bir kişi yeniden kaydı onaylar ve bu onay kayıt altına alınır |
Güvenlik dengesini açıkça belirtmek gerekir: Bu kategorideki her üründe kurtarma süreci, kayıp cihazın yerine kabul ettiği kanıt kadar güçlüdür. Üç yöntemden yalnızca birini değil ikisini zorunlu tutmak, güvenli kurtarmayla doğrulamayı baypas etmek arasındaki farkı yaratabilir. Yapılandırılabilir kurallar sayesinde finans ekibine depo ekibinden daha sıkı koşullar uygulamak için ikinci bir ürün gerekmez.
Üstelik yardım masası talebi hiç oluşmaz. Parola sıfırlama ve hesap kilitleri, her ölçekte kurumun en yoğun destek konularındandır. Bu yaklaşım talepleri hızlandırmak yerine büyük bölümünü ortadan kaldırır.
Tehdit Tespiti
Başarısız Sıfırlama Denemesi Bir Güvenlik Sinyalidir
Kullanıcı adı aşamasını geçen ancak ikinci faktörde sürekli başarısız olan sıfırlama denemesi önemli bir sinyaldir: Birisi geçerli kullanıcı adını biliyor, fakat o hesaba kayıtlı cihazı doğrulayamıyor.
Tek başına kesin kanıt değildir. Telefonun şarjı bitebilir, push bildirimi yanlışlıkla kapatılabilir, kod hatalı girilebilir veya eski telefon hâlâ kullanılıyor olabilir. Her başarısızlığı ayrı alarm saymak gürültü üretir; sonunda alarmlar susturulur.
Diğer sinyallerle birleştiğinde anlam kazanır. Aynı hesaba tekrarlanan denemeler, beklenmedik kaynaklardan gelen istekler veya tek kaynağın peş peşe farklı hesapları denemesi, tekil hatalara göre çok daha şüphelidir. Bunları SIEM platformunuza tekil olay yerine davranış örüntüsü olarak aktarın.
Yetenekler
| Self-Servis parola sıfırlama | Kullanıcı, MFA doğrulamasını tamamladıktan sonra unuttuğu dizin parolasını kendisi sıfırlar |
| Self-Servis hesap kilidi açma | Kullanıcı kimliğini doğrulayıp kilitlenen hesabını parolasını değiştirmeden açar; çoğu durumda ihtiyaç duyulan işlem tam olarak budur |
| Kişisel güvenlik soruları | Kurtarma sürecinde ikinci faktörün yerine değil, yanında ek doğrulama adımı olarak zorunlu tutulabilir |
| Self-Servis MFA kaydı | Kullanıcılar kendi doğrulama yöntemlerini ve cihazlarını kaydeder, değiştirir veya kaldırır; yeni telefon işlemleri destek talebine dönüşmez |
| Cihazlarım | Kullanıcı yeni ActiveSync cihazını yöneticiyi beklemeden kendisi onaylar |
| Parola politikası uygulama | Parola uzunluğu ve karakter türleriyle ilgili kurallarınız parola belirlenirken uygulanır; Self-Servis işlemi politikaya aykırı parola oluşturamaz |
| Yasaklı parola listesi | Şirket adı, mevcut yıl veya şehir gibi tahmin edilebilir ifadeler reddedilir. Böylece karmaşıklık kurallarını karşılayan ama kolayca tahmin edilebilen parolalar engellenir |
| Parola süresi dolma hatırlatmaları | Kullanıcılar belirlediğiniz sayıda gün önceden uyarılır, ardından günlük hatırlatma alır. Böylece hesap kilitleri oluşmadan önlenebilir |
| Yapılandırılabilir yöntemler ve varsayılan seçenek | Yönetici portalda hangi yöntemlerin gösterileceğini ve hangisinin varsayılan olacağını belirler |
| Kullanıcı hesabı sona erme yönetimi | Hesaba bitiş tarihi atanır; süre dolduğunda hesap otomatik devre dışı bırakılır |
| Sizin diliniz, sizin üslubunuz | Bildirim ve kayıt e-postaları kurumunuzun iletişim diline göre özelleştirilir |
Parola Sıfırlama Akışını Kendi Dizininizde Görün
Devredilen yetkileri, kullanıcı portalını, parola sıfırlama, kilit açma ve yeniden kayıt süreçlerini uçtan uca gösteren teknik demo.
Güvenlik Ekibinin İlk Sorduğu Sorular
Domain Yöneticisi Yetkisi Gerekmez
Güvenlik ekibinin ilk toplantıda bunu sorması çok doğaldır. Dizin genelinde parola sıfırlayan bir ürüne yüksek düzeyde güvenmeniz gerekir. “Domain admin gerekiyor” yanıtı, aracı ortamın en yetkili bileşenlerinden birine dönüştürür. Pek çok kurulum bu noktada takılır.
Mirket, seçtiğiniz organizasyon birimleriyle (OU) sınırlandırılmış az sayıda devredilmiş Active Directory yetkisiyle çalışır:
| Yetki | Tür |
|---|---|
| Parola sıfırlama | Control Access — extended right |
pwdLastSet | Okuma + Yazma |
userAccountControl | Yazma |
lockoutTime | Okuma + Yazma |
ADUC üzerinden devredilebilir veya doğrudan tanımlanabilir:
dsacls "OU=SALES,DC=example,DC=local" /I:S /G "EXAMPLE\mirket:CA;Reset password;user"
dsacls "OU=SALES,DC=example,DC=local" /I:S /G "EXAMPLE\mirket:WP;pwdLastSet;user"
dsacls "OU=SALES,DC=example,DC=local" /I:S /G "EXAMPLE\mirket:RP;pwdLastSet;user"
dsacls "OU=SALES,DC=example,DC=local" /I:S /G "EXAMPLE\mirket:WP;userAccountControl;user"
dsacls "OU=SALES,DC=example,DC=local" /I:S /G "EXAMPLE\mirket:RP;lockoutTime;user"
dsacls "OU=SALES,DC=example,DC=local" /I:S /G "EXAMPLE\mirket:WP;lockoutTime;user"Bunun sağladığı güvenlik: Bu şekilde yetkilendirilen servis hesabı yalnızca belirttiğiniz OU içindeki kullanıcı nesnelerinin parolasını sıfırlayabilir ve kilidini açabilir. Ayrıcalıklı grup üyeliği yoktur; posta kutuları, dosya paylaşımları veya domain yapılandırması üzerinde yetki verilmez. Yetki kapsamının OU yapısına ve kalıtım ayarlarına bağlı olduğunu unutmayın; varsaymak yerine denetleyin.
/I:S yetkiyi OU nesnesinin kendisine değil, içindeki kullanıcı nesnelerine uygular. Bu ayrıntı atlanırsa yetki verilmiş gibi görünse de işlem çalışmayabilir.
İkinci Kritik Konu: Kullanıcıların Sistemi Benimsemesi
Kimsenin bilmediği bir Self-Servis portalı, destek çağrılarını azaltmaz; yalnızca başarısız sayılan yeni bir projeye dönüşür.
Başarılı kullanım, canlıya geçmeden önce başlar. Kullanıcılar hesapları kilitlenmeden önce portalı tanımalı ve kayıtlarını tamamlamalıdır. Sorun yaşandığında portalı anlatmak için artık geçtir; kullanıcı yardım masasını arar. İki adım özellikle önemlidir: Kullanıcıları önceden kaydedin. Telefon kaydı mevcut MFA yaygınlaştırma sürecine eklenebilir. Parola süresi hatırlatmalarını kullanın. Böylece kullanıcılar acil duruma düşmeden, kendi masalarında işlemlerini tamamlar. Değişikliği duyurmak yine gerekir; ancak bu adımlar benimsemeyi kolaylaştırır.
Denetim ve Uyumluluk
Hiçbir ürün tek başına uyumluluk sağlamaz. Aşağıdaki maddeler kimlik bilgisi kurtarma süreçleriyle ilişkilidir; Mirket’in sunduğu kontrolleri bu çerçevede değerlendirebilirsiniz.
PCI DSS v4.x
Req. 8.3.5Parolalar benzersiz değerlerle oluşturulur veya sıfırlanır ve ilk kullanımdan sonra değiştirilir. Self-Servis işleminde kullanıcı politikaya uygun parolayı kendisi belirler; telefonda okunup başkalarınca duyulabilecek veya yeniden kullanılabilecek geçici parola yoktur
PCI DSS v4.x
Req. 8.3.6Asgari parola gücü. Parola belirlenirken politika uygulanır; yasaklı liste, karmaşıklık şartlarını sağlasa bile kolay tahmin edilen ifadeleri reddeder
ISO/IEC 27001:2022
A.5.17Kimlik doğrulama bilgilerinin tahsisi ve yönetimi; kayıp durumunda yeniden sağlanması da buna dahildir. Yukarıda açıklanan kurtarma süreci bu konuyu ele alır
NIST SP 800-63B
Kayıp doğrulayıcının yenilenmesinden önce hangi kanıtların gerektiğini tanımlar; yeniden kaydı yalnızca idari işlem olarak ele almaz. Yeni cihazın doğrulanmış bir faktöre bağlanması ve onaylayan kişinin kaydedilmesi bu yaklaşımı destekler
GDPR
Art. 32Kişisel verilere erişim kontrolü; bu verilere ulaşmayı sağlayan hesap kurtarma yolu da dahildir
Kurulum Seçenekleri
İki seçenek de var. Aynı modül, aynı yetenekler.
Kurum içinde, kendi sunucularınızda ya da hizmet olarak. Her iki modelde de yukarıda açıklanan dizin servis hesabı bulut konsolunda değil, ağınızdaki ajan üzerinde yapılandırılır. Böylece devrettiğiniz yetkilerin kontrolü sizde kalır.
MFA veya SSO için Mirket Portal zaten kullanılıyorsa, Güvenli Self-Servis aynı portalın bir modülüdür; ikinci sunucu veya ikinci yönetim konsolu gerektirmez.
Kullanıcı bilgisayarlarına yazılım yüklenmez. Portal web üzerinden çalışır.
Tanımlı kullanıcı sayısına göre lisanslanır. Parola sıfırlama ve kilit açma taleplerinin maliyetini kendi yardım masası verilerinizle ölçebilirsiniz; tasarruf hesaplama yöntemimize göz atın.
