حل فشل التفويض في Azure بتتبّع الهوية والنطاق

افهم الأسباب المحتملة

• تشمل الأسباب الشائعة مستأجرًا أو اشتراكًا غير مقصود، أو هوية مُدارة مختلفة، أو دورًا مُسنَدًا في نطاق آخر، أو الخلط بين صلاحيات الدليل ومستوى الإدارة ومستوى البيانات. وقد تؤثر أهلية الدور وشروطه وضوابط المنع المنطبقة في النتيجة أيضًا.

سجّل عملية مرفوضة واحدة

اجمع رمز الخطأ والوقت ومعرّف الارتباط والإجراء المطلوب ومعرّف المورد الكامل في سجل واحد. حدّد هل وصل الطلب إلى Azure Resource Manager أم إلى نقطة بيانات خدمة. احفظ الأدلة اللازمة للتشخيص فقط؛ فلا مكان للرموز أو سلاسل الاتصال أو محتوى العملاء في تذكرة مشتركة. يتناول السجل المبتكر أدناه الوصول إلى بيانات التعريف، وليس تسجيل الدخول إلى نظام التشغيل أو قراءة بيانات التطبيق. يمنع هذا الفصل التحقيق في صلاحية أخرى لمجرد ارتباطها بالمورد نفسه.

principal kind: managed identity
operation: Microsoft.Compute/virtualMachines/read
request scope: /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/dc-lab/providers/Microsoft.Compute/virtualMachines/report-vm
result: AuthorizationFailed

تأكّد من الهوية وسياق الحساب

قارن المستأجر والاشتراك ومعرّف كائن الهوية التي يستخدمها حمل العمل الفاشل بالإعداد المقصود. بيانات اعتماد المطوّر وهوية التطبيق والهوية المُدارة هويات مختلفة. لا يكفي الاسم الظاهر عند وجود أسماء متشابهة في أدلة متعددة. افحص مسار اختيار بيانات الاعتماد دون نسخ قيمها. إذا اعتمد الوصول على دور مؤهّل، فتحقّق من حالة التفعيل المناسبة بدل اعتبار الأهلية إسنادًا نشطًا. يجب أن تستخدم إعادة الاختبار هوية حمل العمل الأصلية؛ فنجاح المسؤول الأوسع صلاحية يجيب عن سؤال آخر.

طابق الإجراء مع نطاق إسناد الدور الفعلي

افحص تعريف الدور ونطاق كل إسناد ذي صلة، بما في ذلك الإسنادات الموروثة. لا يغطي إسناد في مجموعة موارد مجموعةً مجاورة تلقائيًا. يمكن تضييق نطاق Azure RBAC من مجموعة الإدارة إلى الاشتراك ثم مجموعة الموارد ثم المورد. أدوار الدليل في Microsoft Entra ID لا تحل محل أدوار موارد Azure. كذلك لا تعني صلاحية إدارة خدمة بالضرورة امتلاك صلاحية عمليات بياناتها. اعتمد الإجراء أو إجراء البيانات المحدد بدل منح دور واسع لأن اسمه يبدو مناسبًا.

افحص الشروط والمنع وسلوك تحديث الصلاحيات

قد يظل إسناد دور ذي صلة غير كافٍ إذا لم يتحقق شرط أو حجب إسناد منع منطبق العملية. اقرأ سياق الخطأ كاملًا وتوثيق الخدمة قبل تعديل السياسة. وقد تحتاج صلاحية عُدّلت حديثًا إلى عملية الانتشار أو تحديث بيانات الاعتماد الموثّقة. تؤدي إضافة أدوار أوسع مرارًا أثناء تلك الفترة إلى صعوبة إثبات السبب النهائي. تسجّل الملاحظة أدناه فرضية للمراجعة ولا تنفّذ إسنادًا؛ وما زال على المراجع مطابقة الهوية والإجراء والنطاق بالأدلة المعتمدة.

{
  "requiredAction": "Microsoft.Compute/virtualMachines/read",
  "assignmentScope": "the intended report-vm resource",
  "hypothesis": "existing reader assignment belongs to a different resource group",
  "proposedReview": "verify inherited role permissions and correct the narrow scope"
}

طبّق تصحيحًا مبررًا وأثبت حدود الوصول

أكّد مع مالك المورد أن العملية ينبغي أن تكون مسموحة. صحّح الهوية أو معرّف المورد الخاطئ قبل توسيع التفويض. إذا غاب إسناد مطلوب فعلًا، فاطلب أقل صلاحية وفي أضيق نطاق مناسب عبر عملية المراجعة المعتادة. سجّل الحالة السابقة وخطة التراجع. أعد العملية المحددة بعد التحديث الموثّق، ثم تحقّق من مورد مجاور يجب أن يبقى غير متاح. احتفظ بدليل النتيجتين لتمييز التصحيح الناجح عن الحصول غير المقصود على وصول إداري.

امنع تكرار المشكلة

• وثّق هويات أحمال العمل ونطاقات الوصول مع عمليات النشر. راجع الإسنادات المحدودة والصلاحيات الموروثة والاختبارات السلبية المهمة عند تغير الهويات أو ملكية الموارد.