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

أدوار مدمجة ولا Custom Roles؟ إزاي تطبق مبدأ الصلاحية الأقل في Entra ID

حكاية عملية عن الفرق بين إنك تدي حد صلاحية "تقريبًا كفاية" وإنك تدي حد الصلاحية "بالظبط اللي محتاجها"، ومتى تستخدم إيه من الاتنين.

---

المقدمة

حصلت معايا قبل كده موقف كلاسيكي: عضو في فريق الـ Helpdesk طلب صلاحية يعمل reset password لمستخدمين قسم معين بس. أقرب Built-in Role ليها هو Password Administrator أو Helpdesk Administrator، بس المشكلة إن الدور ده بيدي صلاحية على كل المستخدمين في الـ tenant تقريبًا، مش بس القسم المطلوب. يعني عشان أحل مشكلة صغيرة، أنا فتحت باب كبير قوي. المشكلة دي بتتكرر كتير في الشركات اللي بتكبر وتحتاج تفصيل الصلاحيات على مستوى أدق من اللي الأدوار المدمجة بتقدمه، وهنا بالظبط بييجي دور الـ Custom Roles.

💡 المتطلبات:

• Microsoft Entra ID P1 على الأقل عشان تقدر تعمل Custom Roles (P2 لو هتستخدم PIM مع الأدوار دي).
• صلاحية Privileged Role Administrator أو Global Administrator عشان تنشئ وتخصص الأدوار.
• Microsoft Graph PowerShell SDK مثبت (Install-Module Microsoft.Graph).
• فهم أساسي لـ Administrative Units لو هتعمل scoping على مستوى قسم أو فرع.

ليه الأدوار المدمجة مش دايمًا الاختيار الأمثل

الأدوار المدمجة (Built-in Roles) زي Global Administrator, User Administrator, Helpdesk Administrator مصممة عشان تغطي سيناريوهات واسعة وعامة. ده معناه إنها في الغالب بتدي صلاحيات أكتر من اللي المستخدم فعلاً محتاجه. مثلًا:

• Helpdesk Administrator: بيقدر يعمل reset password لأي مستخدم في التينانت (ماعدا الأدوار الإدارية العليا)، حتى لو انت محتاج بس reset لقسم واحد.
• User Administrator: بيقدر ينشئ ويعدل ويحذف مستخدمين وجروبات في كل حتة، مش بس في الوحدة التنظيمية المطلوبة.

لو انت شغال بمبدأ Least Privilege بجد (مش بس شعار)، هتلاقي إن الأدوار المدمجة دي بتفشل في نقطة أساسية: الـ scope. هي إما "كله" أو "لا حاجة"، مافيش تفصيل أدق غير اللي بييجي من دمجها مع Administrative Units، وده برضو محدود.

إمتى فعلًا تحتاج Custom Role

مش كل موقف يستاهل تعقيد Custom Role. القاعدة اللي بستخدمها: لو لقيت نفسك بتدور على دور مدمج وبتقول "ده قريب من اللي عايزه بس فيه صلاحيات زيادة مش لازمة"، دي علامة إنك محتاج Custom Role.

المعيار	Built-in Role	Custom Role
مرونة تحديد الصلاحيات	محدودة، صلاحيات ثابتة من مايكروسوفت	كاملة، تحدد أي actions تحتاجها بالظبط
التراخيص المطلوبة	مجاني (Free tier)	Entra ID P1 على الأقل
سهولة الصيانة	جاهز، متجدد تلقائيًا مع مايكروسوفت	مسؤوليتك تحدّثه لو ظهرت actions جديدة
التكامل مع PIM	مدعوم بالكامل	مدعوم بالكامل (بشرط P2)
أفضل استخدام	سيناريوهات عامة وواسعة	سيناريوهات دقيقة ومحددة النطاق

إزاي تنشئ Custom Role خطوة بخطوة

1. حدد الـ Resource Actions المطلوبة بالظبط

قبل ما تكتب أي كود، افتح قائمة الـ Permissions Reference بتاعة Entra ID وحدد الـ actions اللي فعلًا محتاجها. في مثالنا، الهدف هو: reset password بس، وقراءة بيانات المستخدم الأساسية.

2. أنشئ الدور عن طريق Microsoft Graph PowerShell

Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory"

$permission = @{
    allowedResourceActions = @(
        "microsoft.directory/users/password/update"
        "microsoft.directory/users/basic/read"
    )
}

$params = @{
    displayName     = "Custom Password Reset - Sales Only"
    description     = "يقدر يعمل reset password ويقرأ بيانات المستخدمين الأساسيين بس"
    rolePermissions = @($permission)
    isEnabled       = $true
}

New-MgRoleManagementDirectoryRoleDefinition -BodyParameter $params

3. اعمل Scope للدور على Administrative Unit

عشان الدور ده يشتغل بس على قسم Sales مثلًا، لازم تربطه بـ Administrative Unit بدل ما تديه صلاحية على التينانت كله.

$auId = "00000000-0000-0000-0000-000000000000"
$roleDefId = "11111111-1111-1111-1111-111111111111"
$principalId = "22222222-2222-2222-2222-222222222222"

$body = @{
    "@odata.type"    = "#microsoft.graph.unifiedRoleAssignment"
    roleDefinitionId = $roleDefId
    principalId      = $principalId
    directoryScopeId = "/administrativeUnits/$auId"
}

New-MgRoleManagementDirectoryRoleAssignment -BodyParameter $body

✅ لو كل حاجة تمام، هتلاقي المستخدم بيقدر يعمل reset password بس للمستخدمين اللي جوه الـ Administrative Unit دي، ومش هيقدر يلمس أي حساب برا النطاق ده.

4. اربط الدور بـ PIM بدل Permanent Assignment

حتى لو الدور Custom ومحدود، ماينفعش يتدي كـ Active Assignment دايم. خليه Eligible في PIM عشان يتفعل وقت الحاجة بس.

$params = @{
    Action           = "adminAssign"
    RoleDefinitionId = $roleDefId
    PrincipalId      = $principalId
    DirectoryScopeId = "/administrativeUnits/$auId"
    ScheduleInfo     = @{
        StartDateTime = (Get-Date)
        Expiration    = @{
            Type     = "afterDuration"
            Duration = "P90D"
        }
    }
}

New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -BodyParameter $params

⚠️ لو عملت Custom Role من غير ما تربطه بـ PIM، هيتحسب Active Assignment دايم من غير انتهاء صلاحية، وده بيرجعك لنفس مشكلة الـ Over-Privileged Access اللي أنت أصلًا بتحاول تتجنبها.

مراقبة استخدام الأدوار بـ KQL

لو الـ Audit Logs بتاعتك متصدرة لـ Log Analytics Workspace، ممكن تتابع مين استخدم الـ Custom Role ده وامتى، عشان تتأكد إن الـ scope شغال زي ما متوقع.

AuditLogs
| where OperationName == "Add member to role"
    or OperationName == "Update user"
| where TargetResources has "Custom Password Reset - Sales Only"
| project TimeGenerated, OperationName, InitiatedBy, TargetResources
| order by TimeGenerated desc

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

المشكلة	الحل
مش لاقي خيار إنشاء Custom Role في الـ Portal	تأكد إن التينانت فيه Entra ID P1 على الأقل، الخيار مش بيظهر أصلًا مع الرخصة المجانية
الدور اتعمل بس المستخدم لسه واخد نفس الصلاحيات القديمة	راجع لو فيه Role Assignment قديم لدور مدمج متعارض، لازم تشيله عشان الصلاحيات متتراكمش بشكل يفتح الباب من غير قصد
الـ allowedResourceActions مش متعرف بالظبط الـ action الصح	استخدم Get-MgRoleManagementDirectoryResourceNamespace عشان تدور على الـ action الدقيق قبل ما تبني الدور
Custom Role اتربط بـ Administrative Unit بس بره النطاق برضو بيشتغل	تأكد إن directoryScopeId متظبط صح في الـ Role Assignment، لو سبته "/" كده يبقى Tenant-wide بالغلط

نصائح الأمان 🔐

• ابدأ دايمًا بأقل صلاحية ممكنة، وزود بعدين لو ظهرت حاجة فعلًا محتاجينها، مش العكس.
• خلي كل Custom Role ليها Description واضح يشرح ليه اتعملت وإيه نطاقها، عشان أي حد يراجعها بعدين يفهم القرار.
• راجع الـ Custom Roles دوريًا (كل 3 أو 6 شهور) عشان تتأكد إنها لسه مطابقة للاحتياج الفعلي ومحدش زودها actions زيادة بمرور الوقت.
• متسيبش أي Custom Role كـ Active Assignment دايم، اربطها بـ PIM دايمًا حتى لو الصلاحيات محدودة.
• استخدم Administrative Units مع الـ Custom Roles دايمًا، الدور المحدود Actions من غير scope جغرافي أو تنظيمي لسه بيدي تحكم أوسع من اللازم.

الخلاصة

الأدوار المدمجة سريعة ومريحة، بس بتفشل لما تيجي تطبق Least Privilege بجد. الـ Custom Roles بتديك التحكم الدقيق اللي محتاجه في البيئات الكبيرة أو الحساسة، بس محتاجة صيانة ومتابعة مستمرة عشان متتحولش لفوضى تانية. النقط الأساسية اللي لازم تفتكرها:

1. حدد الـ Resource Actions بالظبط قبل ما تبني أي دور.
2. استخدم Administrative Units عشان تحدد الـ Scope بدل ما تدي صلاحية على التينانت كله.
3. اربط أي Custom Role بـ PIM، حتى لو الصلاحيات محدودة.
4. راجع الأدوار دوريًا وماتسبهاش تتقادم من غير مراجعة.

إنت جربت تعمل Custom Role قبل كده ولاقيت فيها تحدي مختلف؟ شاركنا تجربتك في التعليقات.