Hiçbir şey çalışmazken çalışan Entra ID break-glass hesapları

Bir tenant, ortada hiçbir saldırgan olmadan da kendi kendini kilitleyebilir. Tüm Global Administrator ve Privileged Role Administrator atamaları eligible (uygun) durumdaysa, aktivasyon onay gerektiriyorsa ve hiç onaylayıcı seçilmemişse, kimse hiçbir şeyi onaylayamaz. Varsayılan onaylayıcılar aktif yöneticilerdir ve hiç aktif yönetici yoktur. Önceden kurulmuş ve tatbikatla denenmiş iki cloud-only break-glass hesabı, bu durumdan çıkışın yoludur.

Bu hesaplara ne zaman ihtiyaç duyarsınız

Microsoft'un acil erişim rehberi bu durumları sıralar. Kimlik sağlayıcınızın sunucusu arızalandığı için federasyon çalışmıyor olabilir. Tüm yöneticiler MFA için yalnızca telefon aramasını ve kısa mesajı kaydetmiş olabilir ve mobil şebeke kesintide olabilir. Global Administrator erişimine sahip son kişi şirketten ayrılmış ve hesabı şirket içinde (on-premises) devre dışı bırakılmış ya da silinmiş olabilir. Entra ID bunun önüne geçmez.

Hesapları oluşturun

En az iki hesap oluşturun. Hesapları *.onmicrosoft.com alan adında, cloud-only olarak açın; federe olmasınlar ve şirket içinden senkronize edilmesinler. Her birine Global Administrator rolünü atayın.

Privileged Identity Management (PIM) içinde bu atamayı eligible değil, active permanent yapın. Gündelik yöneticiler just-in-time erişim kullanmalıdır, ancak bu hesaplar bir aktivasyon adımına bağımlı olamaz, çünkü kullanılamayan şey tam da bu adım olabilir. PIM için Microsoft Entra ID P2 ya da Entra ID Governance gerekir.

Kaynaklar PIM bulunmayan tenant'ları ele almıyor, bu nedenle bu kısım bizim çıkarımımızdır. Active ile eligible ayrımı PIM içinde yer alır ve orada geçerli olmaz. Hesaplara yine de doğrudan ve kalıcı bir Global Administrator ataması gerekir, aynı gerekçeyle: hiçbir şeyin aktive edilmesi gerekmemelidir.

Kimlik doğrulama için MFA gereksinimini karşılayan, parolasız bir yöntem seçin:

• Microsoft'un önerdiği passkey (FIDO2).
• Zaten bir PKI işletiyorsanız certificate-based authentication.

Gündelik yöneticilerinizden farklı bir yöntem kullanın. Onlar Microsoft Authenticator uygulamasını kullanıyorsa, acil durum hesaplarına bir FIDO2 güvenlik anahtarı verin. Ortak hesapları bir kişiye ya da telefon gibi çalışanın getirdiği bir cihaza bağlamayın. Microsoft ayrıca her yönetici için bireysel acil durum hesaplarına izin verir; bu, hesap verebilirlik sağlar ve kişilerin bu hesapları uzak konumlardan kullanmasına imkân tanır. Modelinizi bilinçli olarak seçin.

Anahtarları, güvenli ve birbirinden ayrı konumlardaki yangına dayanıklı kasalarda saklayın ve yetkili kişilerin erişimine açık tutun. Bu hesaplarla her oturum açıldığında, Privileged Access Workstation gibi ayrılmış ve güvenli bir iş istasyonu kullanın.

Conditional Access dışında tutun

MFA, uyumlu cihaz ya da başka bir kontrol gerektiren, uygulanan bir politika acil durum sırasında hesabı kullanılamaz hale getirebilir. Hesabı koruyan şey kimlik avına dayanıklı kimlik bilgisidir; bu yüzden hesabı oturum açmayı engelleyen ya da kısıtlayan tüm politikaların dışında tutun. Conditional Access için Entra ID P1 gerekir.

Örneğin EmergencyAccess adında özel bir güvenlik grubu oluşturun, iki hesabı bu gruba ekleyin ve grubu söz konusu politikalardan hariç tutun. Report-only politikalar erişimi engellemez ve hariç tutma gerektirmez.

Tek başına bir grup yeterli değildir, çünkü yeni politikaları, bu hesapların varlığını hatırlamayabilecek kişiler yazar. Etkin her politikayı açın ve Exclude bölümünde grubu kontrol edin. Report-only politikaları da biri etkinleştirmeden önce yeniden kontrol edin. Her yeni politikanın gözden geçirme listesine "EmergencyAccess hariç tutuldu mu?" sorusunu ekleyin ve her önemli değişiklikten sonra bir oturum açma testi yapın.

Her oturum açmada alarm üretin

Bu hesaplar yalnızca tatbikatlarda ve gerçek acil durumlarda oturum açmalıdır; bu yüzden her oturum açma bir alarmı hak eder. Microsoft'un örneği Azure Monitor kullanır ve önce Entra sign-in loglarınızın bir Log Analytics workspace'e gönderilmesini gerektirir.

1. Entra admin center'da, en az User Administrator rolüyle Entra ID > Users bölümüne gidin, her acil durum hesabını açın ve Object ID değerini kopyalayın.
2. Azure portal'da, en az Monitoring Contributor rolüyle Monitor > Alerts bölümünü açın ve + Create > Alert rule seçeneğini seçin.
3. Scope sekmesinde Log Analytics workspace'inizi seçin.
4. Condition sekmesinde sinyal adı olarak Custom log search, sorgu türü olarak Aggregated logs seçin.
5. Her iki Object ID'yi içeren bir sorgu girin:

SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

1. Measurement altında ölçüyü, aggregation type'ı ve aggregation granularity'yi seçin. Split by dimensions altında Resource ID sütununu seçin.
2. Alert logic altında threshold type'ı Static, operatörü Greater than ve threshold value'yu 0 olarak ayarlayın. Evaluation frequency'yi, alarmdan ne kadar hızlı haberdar olmak istediğinize göre belirleyin.
3. Alarmı tek bir kişiye değil, birkaç yöneticiye e-posta ve SMS ile yönlendirin.

Microsoft ayrıca UserPrincipalName ile yazılmış bir sorgu da gösterir. Biz alışkanlıktan Object ID kullanıyoruz, çünkü bir ada göre yazılmış sorgu, o adın değişmeden kalmasına bağımlıdır. Her ek hesap için bir or UserId == "ObjectGuid" ifadesi daha ekleyin.

Ekibinizde mesai dışında alarmları izleyen kimse yoksa, yönetilen izleme hizmeti bu kısmı üstlenebilir.

Test edin ve her kullanımı gözden geçirin

Hesapları en az 90 günde bir doğrulayın. Bir tatbikat; yetkili kullanıcı listesini, güvenlik anahtarıyla gerçek bir oturum açmayı ve bir yönetim görevini kapsamalıdır. Hesapların güncel Conditional Access yapılandırmanız altında hâlâ oturum açabildiğini, ayrıca her anahtarın ya da sertifikanın yerinde olduğunu, süresinin dolmadığını ve otomatik temizlik tarafından kaldırılmadığını doğrulamalıdır.

Her tatbikat alarmınızı tetiklemelidir. Workspace'te ya da onu besleyen diagnostic settings ayarlarında bir değişiklik yapıldığında testi tekrarlayın. Kısa bir kayıt tutun:

Gerçek bir kullanımdan sonra bir post-mortem toplantısı yapın. Kullanımın yetkili olup olmadığına ve yapılan işlemlerin uygun olup olmadığına karar verin. Düzenlemeye tabi kuruluşlar bu kaydı, loglar ve tatbikat kaydıyla birlikte, acil erişimin yönetildiğinin kanıtı olarak sunabilir. Dışarıdan bir kontrol isterseniz, danışmanlık ekibimiz yapılandırmayı gözden geçirebilir.

Nereden başlamalı

1. Entra admin center'da Global Administrator'larınızı listeleyin ve sayıyı Microsoft'un beşten az olması yönündeki önerisiyle karşılaştırın. Acil durum için ayrılmış bir hesap olup olmadığını öğrenin.
2. Kalıcı ve aktif Global Administrator atamasına sahip, cloud-only iki .onmicrosoft.com hesabı oluşturun ve her birine farklı bir FIDO2 anahtarı kaydedin.
3. EmergencyAccess grubunu oluşturun ve oturum açmayı engelleyen ya da kısıtlayan her Conditional Access politikasından hariç tutun.
4. Sign-in loglarını Log Analytics'e gönderin ve her iki Object ID için eşiği 0'dan büyük olarak ayarlayan alarm kuralını oluşturun.
5. Anahtarları ayrı, yangına dayanıklı konumlara koyun, yetkili kullanıcıları belirleyin ve hiçbir kimlik bilgisinin süresinin dolmadığını ya da otomatik temizlik kapsamında olmadığını kontrol edin.
6. Her hesapla oturum açın, alarmın tetiklendiğini doğrulayın, tatbikat kaydının ilk satırını doldurun ve bir sonraki tatbikatı 90 gün içinde takvime ekleyin.