Break-Glass Account Strategy That Survives an Incident | استراتيجية Break-Glass Accounts اللي فعلا بتنجيك وقت الكارثة

استراتيجية Break-Glass Accounts اللي فعلا بتنجيك وقت الكارثة




حكاية حساب طوارئ اتعمل صح من أول مرة، مش بس اتعمل وخلاص


المقدمة

تخيل معايا الموقف ده: عميل عنده Conditional Access policy جديدة اتعملها الصبح، وبعد ساعتين كل الـ Global Admins بتاعته اتقفلهم الدخول لأن الـ policy طلعت أشمل مما المفروض وطلبت MFA من جهاز مش متسجل. الحل الطبيعي كان إنه يستخدم الـ break-glass account، بس المفاجأة إن الحساب ده كان متضمن غصب عنه جوا نفس الـ Conditional Access policy لأنه اتحط في exclusion group غلط من سنة. يعني الحساب اللي المفروض ينجيك، هو نفسه واقع في نفس المشكلة. من هنا بقى واضح إن عمل break-glass account مش بس "خد حساب وحط عليه Global Admin"، ده استراتيجية كاملة لازم تتختبر بجد قبل ما تحتاجها فعلا.

💡 المتطلبات: صلاحية Global Administrator أو Privileged Role Administrator على الـ tenant، وصول لـ Microsoft Entra admin center، Microsoft Graph PowerShell SDK أو Graph Explorer، Microsoft Sentinel أو Defender XDR (لو عايز alerting)، ومكان آمن فيزيقي أو digital vault (زي Azure Key Vault أو physical safe) لتخزين الباسوردات.

إيه اللي بيخلي الحساب "Break Glass" فعلا مش بس اسم على حساب عادي

كتير بيتعامل مع الموضوع إنه مجرد حساب Global Admin احتياطي، بس الفرق الحقيقي في المواصفات دي:

  • Cloud-only: الحساب لازم يتعمل مباشرة في Entra ID، مش synced من on-premises Active Directory، عشان لو مشكلة الـ Incident أصلا في الـ AD DS أو ADFS، الحساب يفضل شغال.
  • مفيش اعتماد على MFA device شخصي: متربطش الحساب برقم موبايل موظف معين أو Authenticator app على جهازه، لأن الموظف ده ممكن يكون مش موجود وقت الأزمة.
  • مستبعد من كل الـ Conditional Access policies: بدون استثناء، حتى لو الـ policy "بسيطة".
  • Role دايم مش Eligible عن طريق PIM: لو الـ PIM نفسه هو اللي واقع أو محتاج approval مش متاح وقت الأزمة، الحساب ده لازم يكون معاه Global Administrator Active بشكل دائم.

إنشاء الحسابين خطوة بخطوة

1. إنشاء الحساب عن طريق Microsoft Graph PowerShell

Connect-MgGraph -Scopes "User.ReadWrite.All","RoleManagement.ReadWrite.Directory"

$passwordProfile = @{
    Password = "GenerateA-VeryLong-RandomPassword!2024#"
    ForceChangePasswordNextSignIn = $false
}

New-MgUser -DisplayName "SVC-EmergencyAccess-01" `
    -UserPrincipalName "svc-ea01@tenant.onmicrosoft.com" `
    -MailNickname "svceA01" `
    -PasswordProfile $passwordProfile `
    -AccountEnabled

2. تعيين Global Administrator بشكل دائم (مش عبر PIM)

$userId = (Get-MgUser -Filter "userPrincipalName eq 'svc-ea01@tenant.onmicrosoft.com'").Id
$roleId = (Get-MgDirectoryRole -Filter "displayName eq 'Global Administrator'").Id

New-MgDirectoryRoleMemberByRef -DirectoryRoleId $roleId -BodyParameter @{
    "@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$userId"
}

⚠️ تنبيه: متعملش الـ role assignment ده عبر PIM eligible. الفكرة كلها إن الحساب ده ميعتمدش على أي layer إضافي ممكن يكون هو نفسه سبب المشكلة.

3. إعداد المصادقة: بدون MFA مسجل على شخص

الطريقة المعتمدة من Microsoft هي استخدام FIDO2 security key فيزيقي مخزن في خزنة، أو باسورد طويل عشوائي (16 حرف أو أكتر) بدون أي MFA مرتبط بجهاز شخص. لو هتستخدم الخيار التاني، لازم يكون فيه compensating control قوي زي الـ alerting اللي هنتكلم عنه بعدين.

استبعاد الحسابات من Conditional Access

اعمل security group مخصص، مثلا "Break-Glass-CA-Exclusion"، وضيف فيه الحسابين بس. بعدين روح على كل Conditional Access policy موجودة في الـ tenant وضيف الجروب ده في خانة الـ Exclude Users. الخطوة دي لازم تتعمل مرة واحدة لكل policy جديدة، فبقول دايما اعملها Standard Operating Procedure جوا فريقك.

GET https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies

استخدم الاستعلام ده عشان تراجع كل الـ policies وتتأكد إن الـ exclusion group موجود جوا الـ conditions.users.excludeGroups في كل واحدة منهم.

المراقبة: لو حد استخدم الحساب لازم تعرف فورا

الحساب ده مفروض يفضل ساكت طول الوقت، فأي sign-in عليه هو بحد ذاته حدث أمني يستاهل تنبيه فوري. لو عندك Microsoft Sentinel أو Defender XDR، اعمل custom detection rule بالـ KQL دي:

SigninLogs
| where UserPrincipalName in ("svc-ea01@tenant.onmicrosoft.com", "svc-ea02@tenant.onmicrosoft.com")
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType, Location
| order by TimeGenerated desc

اربط الاستعلام ده بـ Analytics Rule يبعت alert فوري لقناة Teams أو email لفريق الأمان، وخليه Severity High بلا نقاش.

الاختبار الدوري: النقطة اللي معظم الناس بتنساها

حساب Break Glass ماتم اختباره من 8 شهور هو حساب مش موثوق فيه، ممكن الباسورد يكون اتغير غلط، أو الـ account يكون اتعطل بالخطأ في تنظيف دوري. اعمل جدول اختبار كل 60 إلى 90 يوم، سجل دخول فعلي بالحساب، تأكد إنه بيوصل للـ Entra admin center من غير أي مشاكل، وسجل النتيجة في مستند تتبع.

✅ نجاح الاختبار معناه: تسجيل الدخول تم من غير أي MFA prompt غير متوقع، الحساب معاه Global Admin فعال، والـ alert وصل لفريق الأمان خلال دقائق.

مقارنة سريعة: Cloud-Only مقابل Synced Account للـ Break Glass

المعيار حساب Cloud-Only حساب Synced/Federated
الاعتماد على On-Premises مفيش أي اعتماد معتمد بالكامل على AD DS أو ADFS
التأثر بمشاكل الـ ADFS غير متأثر لو ADFS واقع، الحساب مش هيقدر يسجل دخول
الموثوقية وقت الكارثة عالية منخفضة جدا
التوصية الخيار المعتمد دايما غير مقبول لـ Break Glass

مشاكل شائعة وحلولها

المشكلة الحل
الحساب اتنسى ومحدش اختبره من شهور طويلة جدولة اختبار دوري كل 60 إلى 90 يوم مع تذكير في الكالندر لفريق الأمان

Comments

Popular posts from this blog

Entra ID Free vs P1 vs P2: What You Actually Get at Each License Tier | Entra ID Free ولا P1 ولا P2: الفرق الحقيقي بين الباقات

Conditional Access Design Mistakes That Lock Admins Out of Microsoft Entra ID | لما الـ Conditional Access يقفل عليك الباب وأنت جوه Tenant

Entra ID Built-in Roles vs Custom Roles for Least Privilege | أدوار مدمجة ولا Custom Roles؟ إزاي تطبق مبدأ الصلاحية الأقل في Entra ID