تحديات وحلول نشر مفاتيح المرور في المؤسسات

1. مقدمة: الواقع التشغيلي لمفاتيح المرور الخاصة بالمؤسسات للموظفين#

لقد وصلت مفاتيح المرور إلى القوى العاملة. لم يعد السؤال هو "هل تعمل التكنولوجيا؟". السؤال الآن هو "كيف ندير هذا على نطاق واسع؟". انتقلت نقاط الاحتكاك إلى الطبقة التشغيلية: مشكلة "الدجاجة والبيضة" الخاصة بالتسجيل الأولي (التشغيل الأولي)، والفرق بين مفاتيح المرور المرتبطة بالجهاز والمتزامنة، وإمكانية التشغيل البيني عبر الأنظمة الأساسية وآليات الاسترداد التي لا تعود إلى عدم أمان كلمة المرور.

يتناول هذا الدليل التحديات الواقعية لنشر مفاتيح المرور في بيئات Microsoft Entra ID، ويغطي مآزق التكوين، وسير العمل التشغيلي واستراتيجيات الاسترداد. وعلى وجه التحديد، سنتناول الأسئلة التالية:

1. ما الفرق بين مفاتيح المرور المرتبطة بالجهاز والمتزامنة في Entra ID؟
2. كيف أقوم بالتشغيل الأولي لمفاتيح المرور للموظفين الجدد بدون كلمات مرور؟
3. كيف يتعافى المستخدمون عندما يحصلون على هاتف جديد ويفقدون إمكانية الوصول إلى المصدق (authenticator) الخاص بهم؟
4. ما هي أخطاء التكوين التي تتسبب في فشل تسجيل مفتاح المرور؟
5. كيف أتعامل مع ضيوف B2B عند طلب مصادقة متعددة العوامل مقاومة للتصيد؟
6. هل يجب استخدام مفاتيح أمان الأجهزة (YubiKeys) أم مفاتيح المرور المحمولة؟
7. كيف أتعامل مع أجهزة macOS إلى جانب Windows في نشر مفتاح المرور؟
8. ما هي التدابير الاستباقية التي تمنع الحمل الزائد على مكتب المساعدة بسبب استبدال الهاتف؟

2. فهم مفاتيح المرور في Microsoft Entra#

في Entra، "مفاتيح المرور" = بيانات اعتماد FIDO2/WebAuthn. بدلاً من كلمة المرور، يثبت المستخدم حيازته لمفتاح خاص (private key) مخزن في مصدق. إنها مقاومة للتصيد لأن WebAuthn يربط بيانات الاعتماد بأصل تسجيل الدخول الحقيقي (لذا لا يمكن لموقع تصيد مشابه إعادة تشغيلها). راجع نظرة عامة لشركة Microsoft في وثائق مفاهيم مفاتيح المرور (FIDO2) Passkeys (FIDO2) concepts documentation.

يدعم Entra فعليًا "وضعين" لمفاتيح المرور يعملان بشكل مختلف.

2.1 مفاتيح المرور المرتبطة بالجهاز في Entra#

مفاتيح المرور هذه مرتبطة بجهاز مادي واحد (غير قابلة للتزامن). يوجد المفتاح الخاص على عنصر جهاز معين (TPM على جهاز كمبيوتر محمول، Secure Element على جهاز YubiKey). وهي غير قابلة للتصدير.

في Entra، تُترجم قصة المرتبطة بالجهاز عادةً إلى:

• مفاتيح مرور Microsoft Authenticator
• Windows Hello أو مفاتيح مرور Windows Hello for Business (WHfB) (غير متزامنة اعتبارًا من يناير 2026)
• مفاتيح أمان FIDO2 (مفاتيح الأجهزة مثل YubiKeys)
• البطاقات الذكية (Smartcards)

يمكن العثور على إرشادات الإعداد الأساسية من Microsoft لمفاتيح المرور المرتبطة بالجهاز هنا: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2

حالات الاستخدام: الوصول عالي الامتياز، وحسابات "كسر الزجاج (break-glass)"، وبيئات محطات العمل المشتركة. الجانب السلبي: احتكاك عالٍ. فقدان الجهاز يعني فقدان بيانات الاعتماد. تكلفة تشغيلية عالية (مثل شحن YubiKeys).

2.2 مفاتيح المرور المتزامنة في Entra#

هذه هي مفاتيح المرور المخزنة في نظام بيئي لمزود الخدمة والمتزامنة عبر أجهزة المستخدم (مثل iCloud Keychain، أو Google Password Manager، أو مزودي الطرف الثالث). يتم تشفير المفتاح الخاص وتخزينه في نسيج مزامنة مزود السحابة.

اعتبارًا من يناير 2026، في Entra، يتم التعامل مع مفاتيح المرور المتزامنة عبر ميزة المعاينة (preview feature): مفاتيح المرور المتزامنة (معاينة) (Synced passkeys (preview)). لتمكين مفاتيح المرور المتزامنة والتحكم فيها، يستخدم Entra ملفات تعريف مفاتيح المرور (معاينة) (Passkey Profiles (preview)).

التوافق التنظيمي: تم التحقق منه مؤخرًا بواسطة NIST SP 800-63B Supplement 1 باعتباره يلبي متطلبات AAL2. يُعد هذا فوزًا تنظيميًا هائلاً يثبت أن مفاتيح المرور المتزامنة "مقاومة للتصيد" بدرجة كافية للاستخدام العام للقوى العاملة.

حالات الاستخدام: العاملون في مجال المعرفة، ومستخدمو BYOD (أحضر جهازك الخاص)، وراحة المديرين التنفيذيين. الجانب السلبي: ضمان "أقل" من الأجهزة. الاعتماد على أمان تدفق استرداد حساب مزود السحابة.

تجد هنا نظرة عامة على مزودي مفاتيح المرور المتزامنة المدعومين من Entra:

في صفحة معلومات الأمان (Security Info) الخاصة بالمستخدم، يتم التمييز بوضوح بين مفاتيح المرور المتزامنة والمرتبطة بالجهاز. يمكنك أن ترى أدناه كيف يظهر مفتاح مرور متزامن (من 1Password) ومفتاح مرور مرتبط بالجهاز (YubiKey 5C NFC):

2.3 التوافق التنظيمي: مستويات NIST AAL#

• AAL3 تاريخياً تطلبت مصدقات تستند إلى الأجهزة ومرتبطة بالأجهزة (مثل YubiKeys أو البطاقات الذكية) التي تستخدم مفتاحًا خاصًا غير قابل للتصدير.
• AAL2 يمكن الآن تحقيقها باستخدام مفاتيح المرور المتزامنة وفقًا لإرشادات NIST.
• فروق دقيقة: في حين أن مفاتيح المرور المتزامنة (مثل تلك الموجودة في iCloud) ممتازة للمستخدمين العاديين، إلا أنها قد لا تلبي بصرامة متطلبات "عدم القابلية للتصدير" الخاصة بـ AAL3 لأعلى مستويات الامتياز. لذلك، يلزم اتباع استراتيجية مجزأة: مفاتيح الأجهزة للمسؤولين (AAL3)، ومفاتيح المرور المتزامنة للقوى العاملة (AAL2).

2.4 متطلبات جاهزية الجهاز#

لضمان إعداد الأجهزة للمصادقة بدون كلمة مرور المقاومة للتصيد، يجب تشغيلها بهذه الإصدارات الدنيا:

قد تتطلب أنظمة التشغيل الأقدم مصدقات خارجية (مفاتيح أمان FIDO2) لدعم المصادقة بدون كلمة مرور المقاومة للتصيد.

بخلاف متطلبات الحد الأدنى من الإصدارات، يختلف دعم إمكانيات جانب المتصفح أيضًا حسب النظام الأساسي. وفقًا لـ Corbado Passkey Benchmark 2026 WebAuthn client capabilities analysis، فإن دعم المتصفحات في الربع الأول من عام 2026 يبلغ 97-100% بالنسبة لـ Conditional Get وHybrid Transport ولكنه يبلغ 83-92% فقط بالنسبة لـ Conditional Create في مزيج متصفحات المستهلكين النموذجي - وهو قيد يقع بأشد تأثير على Windows لأن Windows Hello ليس مسار Conditional Create، ويفيد متصفح Edge تحديدًا بدعم منخفض جدًا لـ Conditional Create في نفس مجموعة البيانات. يغطي المؤشر عمليات النشر الموجهة للمستهلكين B2C بدلاً من بيئات القوى العاملة، ولكن نفس الحدود القصوى لقدرات المتصفح/نظام التشغيل الأساسية لا تزال تنطبق على عمليات نشر Entra ID؛ يمكن أن يهبط مجتمع Edge الكثيف في المؤسسات بشكل مادي أقل من النطاق المدمج لـ Conditional Create بنسبة 83-92%.

2.5 توصيات بيانات الاعتماد حسب شخصية المستخدم#

توصي Microsoft بنهج يعتمد على شخصية المستخدم لنشر بيانات الاعتماد. تختلف متطلبات الأمان ومستويات الاحتكاك المقبولة باختلاف الأدوار:

بيانات الاعتماد المحمولة (يمكن استخدامها عبر الأجهزة):

بيانات الاعتماد المحلية (خاصة بالجهاز):

الهدف النهائي: يجب أن يكون لدى معظم المستخدمين بيانات اعتماد محمولة واحدة على الأقل بالإضافة إلى بيانات اعتماد محلية على كل جهاز كمبيوتر.

3. تجارب من عمليات نشر مفاتيح المرور المباشرة#

عند التحدث إلى المؤسسات التي نشرت مفاتيح المرور، يتم التعرف على بعض نقاط الاحتكاك والأنماط الواقعية.

3.1 التحول التشغيلي#

"التحديات ليست في مجموعة التكنولوجيا ولكن في الطبقة التشغيلية." وهذا يؤكد أن العقبات الفنية مثل أخطاء "مفتاح المرور غير مسجل" أو عدم رؤية خيارات Windows Hello على الأجهزة الشخصية ليست حالات شاذة فريدة بل نقاط احتكاك منهجية متأصلة في النضج الحالي للنظام البيئي. بالنسبة لعمليات المؤسسة، فإن المفتاح هو فصل الإخفاقات المتوقعة وغير المتوقعة في المراقبة. قم بتجميع أخطاء WebAuthn بوضوح وتتبع NotAllowedError و AbortError و أخطاء مفتاح مرور Credential Manager كإشارات مميزة. يوفر كتيب تحليلات المصادقة الخاص بنا إطار عمل لتصنيف هذه الإشارات، وتغطي تحليلات مفاتيح المرور مؤشرات الأداء الرئيسية الخاصة بمفتاح المرور مثل معدلات التنشيط وتسجيل الدخول.

3.2 التسجيل: لحظة "النجاح أو الفشل"#

التسجيل هو أصعب مرحلة في النشر، ويتطلب إدارة تغيير كبيرة.

• تعقيد ما قبل التسجيل: إن تأهيل الموظفين الجدد الذين ليس لديهم بيانات اعتماد سابقة هو عنق الزجاجة الأساسي. يؤدي الاعتماد على التسجيل بوساطة المسؤول إلى تجربة مستخدم مفككة.
• تجزئة النظام الأساسي: "إحباط المستخدم من الخطوات" بسبب التكرارات المستقلة للمتصفحات وأنظمة التشغيل ومديري كلمات المرور. يؤدي هذا إلى تفاوتات مؤقتة حيث يعمل التدفق على Chrome/Windows ولكنه يفشل على Safari/macOS أو يفشل على الأجهزة الشخصية غير المُدارة بينما ينجح على الأجهزة الخاصة بالشركة.

3.3 فجوة النموذج العقلي#

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

• مفتاح المرور (Passkey)
• مفتاح الأمان (Security Key)
• مفتاح الجهاز (Hardware Key)
• YubiKey
• بدون كلمة مرور (passwordless)
• أمان Windows (Windows Security)
• Windows Hello
• Windows Hello للأعمال (WHfB)
• Microsoft Authenticator
• تسجيل الدخول عبر الهاتف (Phone Sign-in)

بالنسبة للمستخدمين غير المتمرسين في مجال التكنولوجيا أو حتى المتمرسين في مجال التكنولوجيا، فإن الاختلافات بين هذه المصطلحات ليست واضحة.

نوصي بتجنب المصطلحات المعقدة مثل "مقاوم للتصيد" أو "زوج المفاتيح (key-pair)" في اتصالات المستخدم النهائي. بدلاً من ذلك، ركز على مفهوم "إلغاء القفل": "استخدم وجهك لإلغاء قفل أنظمة المؤسسة"، على غرار إلغاء قفل هواتفهم.

3.4 قيود الاتصال#

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

4. تعمق في تكوين Microsoft Entra ID#

يتطلب نشر مفاتيح المرور في بيئة مؤسسية فهم وإعداد السياسات المترابطة. مفاتيح المرور ليست مجرد ميزة يمكنك تشغيلها ببساطة، حيث إن لها تأثيرًا كبيرًا على كل موظف في عمله اليومي.

4.1 سياسة طرق المصادقة#

تم إهمال بوابات MFA وSSPR القديمة. يجب أن يتم كل تكوين FIDO2 في شفرة سياسة طرق المصادقة الموحدة Authentication Methods Policy.

• طريقة مفتاح أمان FIDO2: يجب تمكين هذا واستهدافه. نوصي باستهداف "جميع المستخدمين" للتمكين ولكن مع التحكم في الإنفاذ عبر الوصول المشروط (Conditional Access).
• قيود المفاتيح (AAGUIDs): كل جهاز FIDO2 (مثل YubiKey 5 NFC، وMicrosoft Authenticator على iOS، وGoogle Password Manager) له معرف فريد لإثبات المصدق (AAGUID). كأفضل ممارسة، بالنسبة للبيئات عالية الأمان، استخدم إعداد "فرض قيود المفاتيح" للسماح فقط بمعرفات AAGUID المعتمدة. هذا يمنع المستخدمين من تسجيل مفاتيح أمان "السوق الرمادية" الرخيصة وغير المتحقق منها.

4.2 الإثبات: نقطة القرار الحاسمة#

أحد أهم قرارات التكوين هو "فرض الإثبات (Enforce Attestation)".

• ما تفعله: تجبر المصدق على إثبات صنعه وطرازه مشفرًا لـ Entra ID أثناء التسجيل.
• التعارض: مفاتيح المرور المتزامنة (المخزنة في مزودي البرامج مثل iCloud Keychain، أو Bitwarden، أو Google Password Manager) عمومًا لا تدعم الإثبات لأنها تستند إلى البرامج ومستقلة عن النظام الأساسي. لا يمكنهم توقيع تحدٍ بشهادة مجموعة الأجهزة.
• المقايضة:
  • تم التعيين على نعم: مطلوب للضمان العالي (AAL3). يضمن أن المفتاح مرتبط بالأجهزة. يحظر مزودي مفاتيح المرور المستندة إلى البرامج.
  • تم التعيين على لا: يسمح بمفاتيح المرور المتزامنة. يقلل من الضمان قليلاً (AAL2). يُمكّن مزودي مفاتيح المرور المستندة إلى البرامج.

لا يمكنك تطبيق سياسة "بدون إثبات" عالمية إذا كان لديك مسؤولون ذوو امتيازات عالية يحتاجون إلى مفاتيح الأجهزة. يجب عليك استخدام ملفات تعريف مفاتيح المرور (معاينة) Passkey Profiles (Preview):

• الملف التعريفي أ (المسؤولون): فرض الإثبات = نعم
• الملف التعريفي ب (الموظفون بشكل عام): فرض الإثبات = لا

4.3 شرح ملفات تعريف مفاتيح المرور#

فكر في ملفات تعريف مفاتيح المرور Passkey Profiles كآلية لتحديد:

• "يمكن لهؤلاء المستخدمين استخدام مفاتيح المرور المتزامنة"
• "يجب على هؤلاء المستخدمين استخدام المرتبطة بالجهاز فقط"
• "الإثبات مطلوب مقابل غير مطلوب" (وبالتالي: مفاتيح المرور المتزامنة مسموح بها مقابل مستبعدة)
• "تقييد بأنواع معينة من المصدقات (قيود AAGUID)"

يمكنك أن ترى أدناه صفحة إعدادات مفتاح المرور (FIDO2) في مركز إدارة Microsoft Entra حيث تقوم بتكوين ملفات تعريف مفتاح المرور:

عند تحرير ملف تعريف مفتاح مرور، يمكنك تكوين فرض الإثبات، والأنواع المستهدفة (مرتبطة بالجهاز أو متزامنة أو كليهما) وقيود AAGUID المحددة:

4.4 الوصول المشروط وقوة المصادقة#

يمكن التعامل مع الإنفاذ عبر سياسات الوصول المشروط (CA) باستخدام نقاط قوة المصادقة Authentication Strengths.

• قوة المصادقة متعددة العوامل المقاومة للتصيد: تتطلب هذه القوة المدمجة FIDO2، أو Windows Hello for Business (WHfB) أو المصادقة المستندة إلى الشهادة (CBA).
• فخ التأمين (Lockout Trap): إذا أنشأت سياسة CA تتطلب "مصادقة متعددة العوامل مقاومة للتصيد" لـ "جميع التطبيقات السحابية" وطبقتها على "جميع المستخدمين"، فستقوم على الفور بحظر كل مستخدم لم يقم بتسجيل مفتاح مرور بعد. لن يتمكنوا حتى من تسجيل الدخول لتسجيل واحد.
• مفارقة "تسجيل معلومات الأمان": هذا إجراء مستخدم (User Action) محدد في CA. إذا كنت تتطلب مصادقة متعددة العوامل مقاومة للتصيد لتنفيذ الإجراء الخاص بـ تسجيل معلومات الأمان (Register Security Information)، فأنت تنشئ تبعية دائرية (الدجاجة والبيضة). لا يمكن للمستخدم تسجيل مفتاح المرور الأول الخاص به لأنه يحتاج إلى مفتاح مرور للوصول إلى صفحة التسجيل.

فيما يلي نظرة عامة على طرق المصادقة التي تفي بمتطلبات القوة:

4.5 المصادقة المفضلة للنظام#

تجبر ميزة "المصادقة متعددة العوامل المفضلة للنظام" في Entra ID محرك تسجيل الدخول على مُطالبة المستخدم بالطريقة المسجلة الأكثر أمانًا prompt the user for the most secure registered method.

إذا كان المستخدم قد قام بتسجيل كل من الرسائل القصيرة (SMS) ومفتاح المرور، فسيتحول النظام افتراضيًا إلى مفتاح المرور. هذا يدفع إلى تبني مفاتيح المرور بشكل طبيعي دون فرض صارم. فهو يقوم بشكل أساسي "بترقية" الوضع الأمني للمستخدم تلقائيًا بمجرد تسجيل بيانات الاعتماد.

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

4.6 اعتبارات macOS: Platform SSO#

بالنسبة للمؤسسات التي لديها بيئات Windows/macOS مختلطة، يوفر macOS Platform SSO المعادل لـ Apple لـ Windows Hello for Business. عند دمجه مع حلول MDM، يمكنك تحقيق:

• بيانات اعتماد مرتبطة بالجهاز ومقيدة بـ Secure Enclave الخاص بجهاز Mac
• تجربة تسجيل دخول أحادي (SSO) عبر التطبيقات الأصلية وتطبيقات الويب
• مصادقة مقاومة للتصيد تلبي متطلبات AAL2/AAL3

ملاحظة: يتطلب macOS Platform SSO إصدار macOS 13+ و تكوين MDM مناسب. يختلف الإعداد بشكل كبير عن Windows WHfB، لذا خطط لمسارات نشر منفصلة.

5. التكوينات الخاطئة الشائعة: لماذا "يعمل فقط مع Microsoft Authenticator"#

إذا كان هدفك هو مفاتيح المرور المتزامنة على أجهزة غير مُدارة، فهذه هي أكثر العقبات شيوعًا:

5.1 مفاتيح المرور المتزامنة غير ممكنة/مستهدفة#

لا يكفي مجرد تمكين "FIDO2" بشكل عام في Entra. بالنسبة لمفاتيح المرور المتزامنة، ستحتاج عادةً إلى:

• مسار ميزة المعاينة الموصوف في مفاتيح المرور المتزامنة (معاينة) Synced passkeys (preview)
• تكوين ملف تعريف باستخدام ملفات تعريف مفاتيح المرور Passkey Profiles

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

5.2 الإثبات مفروض (يحظر مفاتيح المرور المتزامنة)#

يسبب هذا معظم الأسئلة في المؤسسات المهتمة بالأمان:

• يمكن أن يتطلب Entra الإثبات (attestation) لبعض سيناريوهات مفاتيح المرور (يساعد في التحقق من نوع المصدق/مصدره)
• لا تدعم مفاتيح المرور المتزامنة الإثبات في Entra، لذلك إذا تم فرض الإثبات، يفشل تسجيل مفاتيح المرور المتزامنة وسينتهي بك الأمر بخيارات المرتبطة بالجهاز فقط

5.3 قوائم السماح لـ AAGUID تحظر مزودي الخدمة#

يتيح لك Entra تقييد المصدقات المسموح بها (غالبًا عبر قوائم السماح/الحظر لـ AAGUID). إذا سمحت فقط لـ Microsoft Authenticator (أو مجموعة ضيقة من المصدقات)، فقد يتم حظر مزودي الخدمة المتزامنة من جهات خارجية ضمنيًا. الجزء المربك هو أن المصادقة المحلية (مثل Touch ID، وFace ID، ومسح المقاييس الحيوية لنظام Windows) تعمل ولكن صفحة تسجيل دخول Entra تعرض خطأ بعد ذلك.

5.4 يفرض الوصول المشروط أنواعًا معينة من مفاتيح المرور#

حتى لو تم تمكين مفاتيح المرور، يمكن للوصول المشروط أن يجبر المستخدمين فعليًا على مجموعة فرعية من الطرق (مثل "المصدق فقط" أو تكوين قوة لا يسمح بملف تعريف مفتاح المرور المقصود). من الناحية العملية، يؤدي هذا إلى إنشاء "تبعية Authenticator" حتى عندما تكون الخطة هي مفاتيح مرور متزامنة.

5.5 حسابات الضيوف B2B مقابل حسابات الأعضاء#

إذا كان الشركاء الخارجيون مستخدمين ضيوف B2B في مستأجر الموارد، فهناك قيود معروفة حول أين/كيف يمكنهم تسجيل طرق المصادقة. هذا هو غالبًا "السبب الخفي لعدم عمله" عندما يكون القصد "يستخدم الشركاء مفاتيح المرور في المستأجر الخاص بنا".

6. التحديات والحلول التشغيلية#

6.1 مفارقة التشغيل الأولي#

المشكلة الأكثر انتشارًا ("التسجيل هو الجزء الأصعب") هي مشكلة التشغيل الأولي: كيف تصدر بأمان بيانات اعتماد عالية الضمان لمستخدم ليس لديه حاليًا أي بيانات اعتماد (أو لديه بيانات اعتماد منخفضة الضمان فقط)؟

6.1.1 رمز الوصول المؤقت (TAP)#

يعتبر رمز الوصول المؤقت (TAP) Temporary Access Pass (TAP) نهجًا معماريًا للتأهيل بدون كلمة مرور.

• ماهيته: رمز مرور محدد بوقت (على سبيل المثال ساعة واحدة)، عالي الإنتروبيا (high-entropy) يتعامل معه Entra ID كطريقة "مصادقة قوية". يتجاوز الحاجة إلى كلمة مرور أو مصادقة متعددة العوامل (MFA) حالية.
• سير العمل:
  1. التحقق من الهوية: يتم التحقق من هوية الموظف الجديد (مثل عبر عملية الموارد البشرية أو تحقق المدير).
  2. الإصدار: يقوم المسؤول (أو Logic App الآلي) بإنشاء رمز TAP للمستخدم.
  3. "تسجيل الدخول السحري": ينتقل المستخدم إلى aka.ms/mysecurityinfo. يُدخل اسم المستخدم الخاص به ورمز TAP.
  4. التسجيل: نظرًا لأن رمز TAP يفي بمتطلبات "المصادقة القوية"، يُسمح للمستخدم بالوصول إلى شفرة معلومات الأمان. ينقر فوق "إضافة طريقة (Add Method)" ويسجل مفتاح المرور الخاص به.
  5. الحالة المستقرة: تنتهي صلاحية رمز TAP. يمتلك المستخدم الآن بيانات اعتماد مقاومة للتصيد. لم يكتب كلمة مرور مطلقًا.

6.1.2 الأتمتة عبر Graph API#

بالنسبة للمؤسسات الكبيرة، لا يمكن توسيع نطاق إصدار رمز TAP اليدوي. أفضل الممارسات هي الأتمتة عبر Microsoft Graph API automate via Microsoft Graph API.

• السيناريو: تتم معالجة موظف جديد في نظام الموارد البشرية (Workday/SuccessFactors).
• المُشغل: يؤدي حدث التوفير (provisioning event) إلى تشغيل Azure Logic App.
• الإجراء: يستدعي تطبيق Logic App طلب Graph API POST /users/{id}/authentication/temporaryAccessPassMethods.
• التسليم: يتم تسليم رمز TAP بشكل آمن إلى مدير التوظيف الخاص بالمستخدم أو البريد الإلكتروني الشخصي (المشفر) للوصول في اليوم الأول.

6.1.3 Microsoft Entra Verified ID للتأهيل عالي الضمان#

بالنسبة للتأهيل عن بُعد أو السيناريوهات التي تتطلب ضمانًا عاليًا للهوية، يوفر معرف Entra Verified ID الخاص بـ Microsoft Entra Verified ID مع Face Check مسار تسجيل يركز على الاستغناء عن كلمة المرور أولاً:

1. إثبات الهوية: يتحقق المستخدم الجديد من هويته عبر شريك تحقق من الهوية (IDV) (مسح الهوية الحكومية).
2. المطابقة البيومترية: يقارن Face Check Face Check صورة شخصية (selfie) حية بصورة مستند الهوية باستخدام Azure AI Vision. يتم مشاركة درجة ثقة المطابقة فقط (لا توجد بيانات بيومترية أولية).
3. إصدار بيانات الاعتماد التي تم التحقق منها: يتلقى المستخدم بيانات اعتماد Verified ID.
4. إصدار رمز TAP: عند التحقق الناجح، يُصدر النظام رمز وصول مؤقت.
5. التشغيل الأولي لمفتاح المرور: يسجل المستخدم مفتاح المرور الأول الخاص به باستخدام رمز TAP.

يوجه تدفق فحص الوجه (Face Check) المستخدمين من خلال ثلاث خطوات: التحقق (مشاركة بيانات الاعتماد)، والتأكيد (إجراء فحص الوجه) والمراجعة (رؤية نتيجة المطابقة):

يتيح هذا التدفق حسابات بدون كلمة مرور حقًا من اليوم الأول. لا يتم إنشاء كلمة مرور مطلقًا.

6.2 مشكلة استبدال الهاتف (تحدي النطاق الخفي)#

غالبًا ما يكون هذا هو المصدر الأكبر لمكالمات مكتب المساعدة في عمليات نشر مفاتيح المرور. يمكن للمؤسسات ذات التعداد الكبير من أجهزة BYOD (على سبيل المثال، أكثر من 10,000 جهاز) أن تشهد عددًا هائلاً من مكالمات الدعم فقط بسبب حصول المستخدمين على هواتف جديدة وعدم معرفتهم بالعملية لإعادة تسجيل طرق المصادقة.

عندما تُدخل مفاتيح المرور في هذا المزيج، يصبح الأمر أكثر أهمية بسبب:

• يقوم المستخدمون بتثبيت التطبيقات (مثل Outlook) على هواتفهم الجديدة
• تطلب هذه التطبيقات المصادقة
• تظهر مطالبة المصادقة متعددة العوامل (MFA) على الهاتف القديم (والذي ربما قاموا بالفعل باستبداله أو مسحه)
• يتم حظر المستخدم ويتصل بمكتب المساعدة

6.2.1 مصفوفة السيناريوهات لاستبدال الهاتف#

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

6.2.2 حيلة تسجيل Intune#

رؤية ذكية: إن اشتراط مفتاح مرور لتسجيل Intune يجبر المستخدمين على إكمال إعداد Microsoft Authenticator على هواتفهم الجديدة فورًا - قبل أن يتمكنوا من الوصول إلى تطبيقات الشركة.

• اليوم: يتطلب تسجيل Intune ترقية (step-up) للمصادقة متعددة العوامل (MFA). وهذا يعني أنه إذا كنت ترغب في تسجيل الدخول على هاتف جديد، فيجب عليك تثبيت Outlook هناك. ومع ذلك، تذهب مطالبة MFA إلى الهاتف القديم.
• مع متطلب مفتاح المرور: يجب على المستخدمين إعداد مفاتيح مرور Microsoft Authenticator على الهاتف الجديد أولاً لإكمال التسجيل. يحدث هذا بسرعة (يوم تبديل الهاتف) بدلاً من حدوثه بعد أشهر عندما يكون الهاتف القديم قد ذهب.

هذا لا يحل مشكلة الاسترداد، ولكنه يغير الجدول الزمني. يقوم المستخدمون بتسجيل أجهزتهم الجديدة بينما لا يزال لديهم إمكانية الوصول إلى الأجهزة القديمة.

6.3 مفاتيح أمان الأجهزة تأتي مع مشكلات لوجستية#

تُوضع مفاتيح الأجهزة (YubiKeys، وما إلى ذلك) أحيانًا على أنها الحل الشامل. من الناحية النظرية هي كذلك، ومع ذلك يُظهر العالم الحقيقي المزيد من التحديات:

• كابوس لوجستي: المؤسسات التي نشرت سابقًا رموزًا مادية (مثل RSA SecurID) غالبًا ما أمضت سنوات في محاولة التخلص منها. إن استبدال برنامج رمز مادي بآخر ليس أمرًا جذابًا.
• الشحن المباشر (Drop-shipping): يمكن لـ Yubico شحن المفاتيح مباشرة إلى المستخدمين ولا يحتاجون إلى استبدال البطارية كل بضع سنوات (على عكس SecurID). ولكن إذا نسي شخص ما مفتاحه، فلا يمكنه تسجيل الدخول (لأجهزة سطح المكتب المشتركة).
• عبء تكنولوجيا المعلومات المحلي: لا ينبغي أن يصبح المشرفون المحليون دعمًا لتكنولوجيا المعلومات بحكم الأمر الواقع للمفاتيح المنسية.
• التكلفة: تضيف مفاتيح الأجهزة تكلفة لكل مستخدم تتزايد مع عدد الموظفين.

متى تكون مفاتيح الأجهزة منطقية:

• مسؤولو الطبقة 0 (Tier 0): مسؤولو المجال (Domain admins)، وحسابات "كسر الزجاج (break-glass)"
• محطات العمل المشتركة: بيئات الأكشاك، وأرضيات المصانع، والأجهزة اللوحية الميدانية
• المقاولون بدون أجهزة BYOD: المستخدمون الخارجيون الذين لن يستخدموا الأجهزة الشخصية

6.4 تحديات الأجهزة غير المُدارة#

يشتكي العديد من المستخدمين من عدم تمكنهم من رؤية خيارات استخدام مفتاح المرور على جهاز شخصي. هذه نقطة احتكاك كلاسيكية لـ "جهاز غير مُدار".

6.4.1 تحليل خطأ "مفتاح المرور غير مسجل"#

قد لا يتمكن المستخدمون من إضافة مفاتيح مرور على جهاز شخصي، بينما تعمل على جهاز الشركة. هذا يرجع على الأرجح إلى سياسات امتثال Intune (Intune Compliance Policies) التي تتفاعل مع تدفق التسجيل.

• الآلية: يعد Windows Hello for Business (WHfB) بمثابة بيانات اعتماد للنظام الأساسي. وهو مرتبط بـ TPM الخاص بالجهاز المعين (مفتاح مرور مرتبط بالجهاز).
• القيود: لتسجيل WHfB، يجب أن يكون الجهاز عادةً منضمًا (joined) (Entra Joined أو Hybrid Joined) إلى المستأجر. قد يتم تطبيق قيود على السياسة عبر Intune على الجهاز الشخصي "المسجل" فقط (Workplace Joined) تمنع توفير حاويات WHfB إذا لم يكن الجهاز مُدارًا بالكامل أو غير متوافق. راجع متطلبات تسجيل الدخول لمفتاح أمان FIDO2 FIDO2 security key sign-in requirements.
• خيار "مفتاح المرور": على جهاز شخصي، يجب أن يحاول المستخدم تسجيل مفتاح أمان FIDO2 (متجول - roaming) أو مفتاح مرور عبر الأجهزة (Cross-Device Passkey) (على هاتفه)، وليس Windows Hello for Business (ما لم يكن تسجيل BYOD مدعومًا بالكامل).
• مشكلة رؤية Entra ID: إذا لم يظهر "Windows Hello" كخيار، فلم يكمل الجهاز تسجيل MDM الأساسي.

6.4.2 إخفاقات المصادقة عبر الأجهزة (CDA)#

على الأجهزة غير المُدارة، غالبًا ما يجرب المستخدمون تدفق المصادقة عبر الأجهزة (CDA) (مسح رمز استجابة سريعة (QR) على الكمبيوتر باستخدام هواتفهم).

• اعتماد البلوتوث: تتطلب CDA تمكين البلوتوث (Bluetooth) على كل من الكمبيوتر والهاتف. لا يحتاجون إلى الاقتران، ولكن يجب عليهم إجراء مصافحة Bluetooth Low Energy (BLE) لإثبات القرب. راجع مفاتيح المرور المرتبطة بالجهاز في Microsoft Authenticator device-bound passkeys in Microsoft Authenticator للحصول على التفاصيل.
• حظر سياسة الشركة: إذا تم تعطيل البلوتوث على أجهزة الكمبيوتر المحمولة الخاصة بالشركة عبر BIOS أو GPO بسبب "الأمان"، فقد كسرت بالفعل الآلية الأساسية لمفاتيح المرور المتجولة.
• حظر Websocket: يستخدم تدفق CDA اتصال websocket بـ cable.ua5v.com أو cable.auth.com. غالبًا ما تقوم جدران حماية الشركات الصارمة أو تكوينات Zscaler بحظر هذه المجالات، مما يتسبب في توقف فحص رمز الاستجابة السريعة أو فشله بصمت. راجع وثائق مفتاح مرور Microsoft Authenticator Microsoft Authenticator passkey documentation.

6.5 B2B والهويات الخارجية#

نقطة ضعف أخرى بالنسبة للمؤسسات هي التعامل مع المستشارين الخارجيين (ضيوف B2B).

• المشكلة: يحاول مستشار الوصول إلى موقع SharePoint. يفرض المستأجر سياسة وصول مشروط (Conditional Access) تتطلب "مصادقة متعددة العوامل مقاومة للتصيد".
• الفشل: يحاول المستشار تسجيل مفتاح FIDO2 في مستأجر الموارد. هذا يفشل. لا يدعم Entra ID للمستخدمين الضيوف تسجيل مفاتيح FIDO2 في مستأجر الموارد.
• الحل: إعدادات الوصول عبر المستأجرين (Cross-Tenant Access Settings)
  • المنطق: بدلاً من إجبار الضيف على تسجيل بيانات اعتماد في المستأجر الخاص بك، يجب أن تثق ببيانات الاعتماد التي يستخدمونها في المستأجر الخاص بهم.
  • التكوين: انتقل إلى الهويات الخارجية (External Identities) > إعدادات الوصول عبر المستأجرين. حدد المنظمة الشريكة. ضمن الثقة الواردة (Inbound Trust)، تحقق من "الوثوق بالمصادقة متعددة العوامل من مستأجري Microsoft Entra".
  • النتيجة: عندما يقوم المستشار بتسجيل الدخول باستخدام YubiKey في المستأجر الرئيسي الخاص به، يتلقى المستأجر الخاص بك مطالبة تقول "MFA Satisfied + Phishing Resistant". يتم منح الوصول دون حاجة المستخدم لتسجيل أي شيء. يؤدي هذا إلى الاستعانة بمصادر خارجية لإدارة دورة حياة بيانات الاعتماد إلى الشريك، مما يقلل من التزاماتك وعبء مكتب المساعدة.

7. استراتيجيات الاسترداد#

غالبًا ما تتأخر قرارات الاسترداد عن النشر الفعلي. توجد خيارات استرداد متعددة اعتمادًا على احتياجات مؤسستك.

7.1 استرداد حساب الخدمة الذاتية (SSAR) مع Verified ID#

يسمح تدفق استرداد حساب الخدمة الذاتية (SSAR) الجديد الخاص بـ Microsoft Entra ID Self-Service Account Recovery (SSAR) (في وضع المعاينة) بالاسترداد عالي الضمان دون تدخل مكتب المساعدة.

1. المُشغل: لا يستطيع المستخدم تسجيل الدخول. يحدد "استرداد حسابي".
2. التحقق من الهوية: يُعاد توجيه المستخدم إلى مزود التحقق من الهوية (IDV) تابع لجهة خارجية (مثل Onfido، أو IDemia).
3. فحص المستندات: يقوم المستخدم بمسح رخصة القيادة المادية الخاصة به، أو بطاقة الهوية الوطنية أو جواز السفر باستخدام كاميرا هاتفه المحمول.
4. فحص الحيوية: يُجري المستخدم فحص الوجه (Face Check) Face Check عبر صورة شخصية (selfie). تتم مطابقة هذا مع مستند الهوية (وربما الصورة المخزنة في Entra ID). تستخدم المطابقة واجهات برمجة تطبيقات (APIs) لـ Azure AI Vision Face ويتم مشاركة درجة الثقة فقط. لا تذهب أي بيانات بيومترية أولية إلى التطبيق.
5. الاستعادة: عند النجاح، يُصدر النظام تلقائيًا رمز وصول مؤقت (TAP) للمستخدم.
6. إعادة التسجيل: يستخدم المستخدم رمز TAP لتسجيل مفتاح مرور جديد على الفور.

التوصية: يعتبر مسار الاسترداد الآلي المدعوم بالمقاييس الحيوية هذا أفضل من "الاتصال بمكتب المساعدة"، والذي يكون عرضة للهندسة الاجتماعية (هجمات الصوت العميق - Deepfake voice).

7.2 الاسترداد بمساعدة المدير باستخدام My Staff#

إذا كنت ترغب في تقليل عبء مكتب الخدمة ولكن لا يمكنك تمكين الخدمة الذاتية الكاملة، فإن Microsoft Entra يتضمن ميزة إدارة مفوضة أصلية تسمى My Staff.

• كيف تعمل: تفويض أذونات محدودة لـ "مديري الفرق" (عبر الوحدات الإدارية في Entra).
• التدفق: إذا فقد أحد المستخدمين الوصول، فيمكنه الاتصال بمسؤول محلي مفوض، والذي يمكنه استخدام بوابة My Staff لمهام الاسترداد المدعومة مثل إعادة تعيين كلمة مرور أو تحديث رقم هاتف.
• سبب المساعدة: يحول مهام استرداد الحساب الشائعة بعيدًا عن مكتب المساعدة المركزي ويسرع الدعم.

7.3 كشك استرداد للخدمة الذاتية (الإنترانت)#

نظرًا لأن المستخدمين غالبًا ما لا يزالون يمتلكون كمبيوترًا محمولاً موثوقًا به ومؤمنًا بـ WHfB، فيمكنك إنشاء صفحة إنترانت (intranet) بسيطة لـ "كسر الزجاج (break glass)".

• الإنشاء: تطبيق ويب داخلي بسيط يتطلب تسجيل الدخول باستخدام WHfB (مصادقة قوية).
• الإجراء: بمجرد المصادقة، ينقر المستخدم على "لدي هاتف جديد". يستخدم التطبيق Microsoft Graph API (خدمة خلفية) لإنشاء رمز وصول مؤقت (TAP) قصير الأجل ويعرضه على الشاشة.
• النتيجة: يكتب المستخدم رمز TAP هذا في هاتفه الجديد للتشغيل الأولي لتطبيق Microsoft Authenticator. لا يوجد تدخل من مكتب المساعدة.

هذه هي الرافعة الرئيسية لتقليل إعادة تعيين "طرق المصادقة الواضحة" دون إضعاف السياسة. إذا كان لديك آلية قوية لـ "الكمبيوتر المحمول كأداة تشغيل أولي"، فينخفض عبء الاتصالات الخاص بك بشكل كبير لأن المستخدمين يمكنهم الاسترداد دون معرفة التسلسل المثالي.

8. توصيات لعمليات نشر مفتاح مرور المؤسسة#

قم ببناء عملية النشر الخاصة بك حول مراحل النضج (Maturity Stages). اعترف بالاحتكاك ("التكنولوجيا جاهزة، والعمليات صعبة") وقم بتطبيق عوامل التخفيف هذه.

8.1 الإجراءات الفورية (مرحلة "الإصلاح")#

1. تدقيق البلوتوث وجدران الحماية: تأكد من أن أجهزة الكمبيوتر المحمولة الخاصة بالشركة تسمح بالبلوتوث (لفحوصات القرب) وقم بإدراج نطاقات ترحيل FIDO/WebAuthn في القائمة البيضاء (\*.cable.auth.com) لإصلاح أعطال الأجهزة المشتركة.
2. تمكين الثقة عبر المستأجرين (Cross-Tenant Trust): توقف عن محاولة تسجيل مفاتيح مرور الضيوف. قم بتكوين الثقة الواردة للمصادقة متعددة العوامل للشركاء الرئيسيين لحل مشكلات وصول B2B على الفور.
3. تنفيذ رمز TAP للتأهيل: فرض استخدام رمز الوصول المؤقت لجميع عمليات تأهيل المستخدمين الجدد لحل مشكلة "الدجاجة والبيضة" الخاصة بالتسجيل.

8.2 القرارات الاستراتيجية (مرحلة "الهندسة المعمارية")#

1. تبني نموذج "الضمان الهجين":
   • الطبقة 0 (المسؤولون): فرض الإثبات (Attestation) و قيود المفاتيح (Key Restrictions). فقط YubiKeys/Hardware مسموح بها (AAL3).
   • الطبقة 1 (القوى العاملة): تعطيل فرض الإثبات عبر ملفات تعريف مفاتيح المرور (Passkey Profiles). السماح بمفاتيح المرور المتزامنة لتقليل الاحتكاك والتكاليف (AAL2).
2. التخطيط لنظام macOS: نشر Platform SSO مع MDM كمسار موازٍ لـ Windows WHfB.

8.3 الاستعداد للمستقبل (مرحلة "التحسين")#

1. التخطيط لـ SSAR: ابدأ برنامجًا تجريبيًا لاسترداد حساب الخدمة الذاتية مع Verified ID لـ القضاء على مكتب المساعدة كمتجه للهندسة الاجتماعية.
2. المصادقة المفضلة للنظام: قم بتمكين هذه السياسة "لترقية" المستخدمين تلقائيًا إلى مفاتيح المرور بمجرد تسجيلهم لها، مما يدفع إلى التبني دون تكليف صارم.
3. نشر خيارات الاسترداد: نفذ رمز TAP بمساعدة المدير عبر My Staff و/أو كشك استرداد للخدمة الذاتية.
4. متطلبات مفتاح مرور Intune: فكر في اشتراط مفتاح مرور لتسجيل Intune لإجبار التسجيل المبكر على الأجهزة الجديدة.

8.4 مصفوفة استكشاف الأخطاء وإصلاحها#

9. مراقبة النشر باستخدام مصنف Phishing-Resistant Passwordless Workbook#

أصدرت Microsoft مصنف Phishing-Resistant Passwordless Phishing-Resistant Passwordless Workbook الذي يمكن للمؤسسات التي لديها سجلات في Azure Monitor استخدامه لتتبع تقدم النشر. يمكنك الوصول إليه عبر مركز إدارة Entra ضمن المراقبة (Monitoring) > المصنفات (Workbooks):

يحتوي المصنف على قسمين رئيسيين:

9.1 مرحلة جاهزية التسجيل (Enrollment Readiness Phase)#

استخدم علامة التبويب هذه لتحليل سجلات تسجيل الدخول وتحديد المستخدمين الجاهزين للتسجيل مقابل المستخدمين الذين قد يتم حظرهم. يمكنك التصفية حسب نظام التشغيل الأساسي (Windows، وmacOS، وiOS، وAndroid) ونوع بيانات الاعتماد (مفتاح مرور تطبيق Authenticator، أو مفتاح أمان FIDO2، أو مصادقة مستندة إلى الشهادة):

يُظهر المصنف:

• أزواج المستخدم/الجهاز الجاهزة للتسجيل: المستخدمون الذين يمكنهم تسجيل نوع بيانات الاعتماد المحدد
• أزواج المستخدم/الجهاز غير الجاهزة: المستخدمون الذين قد يواجهون مشكلات في التسجيل (مثل إصدارات أنظمة التشغيل القديمة)

يمكنك تصدير قوائم المستخدمين الذين يحتاجون إلى إجراءات إصلاحية (مثل ترقيات أنظمة التشغيل، أو استبدال الأجهزة أو خيارات بيانات اعتماد بديلة).

9.2 مرحلة جاهزية الإنفاذ (Enforcement Readiness Phase)#

بمجرد أن يصبح المستخدمون جاهزين للمصادقة المقاومة للتصيد فقط، استخدم علامة التبويب جاهزية الإنفاذ. أولاً، قم بإنشاء سياسة وصول مشروط (Conditional Access) للإبلاغ فقط (Report-Only) تتطلب مصادقة متعددة العوامل مقاومة للتصيد. يؤدي هذا إلى ملء سجلات تسجيل الدخول بالبيانات حول ما إذا كان الوصول قد تم حظره في حال كان الإنفاذ نشطًا.

تُظهر لوحة المعلومات:

• إجمالي المستخدمين في النطاق
• نجاح الإبلاغ فقط - المستخدمون الذين سيجتازون الإنفاذ
• السياسة غير مستوفاة - المستخدمون الذين سيتم حظرهم (ابحث في هؤلاء!)
• تقسيمات حالة الجهاز، والنظام الأساسي للجهاز وتطبيق العميل

استخدم علامة التبويب تحليل بيانات إضافي (Further Data Analysis) للتحقيق في سبب حظر مستخدمين معينين. تساعدك هذه البيانات في استهداف المستخدمين للمعالجة قبل تمكين الإنفاذ.

9.3 النشر القائم على الموجات مع مراقبة مكتب المساعدة#

توصي Microsoft بتنفيذ عمليات النشر على شكل موجات مع نطاقات زمنية مرنة. راقب حجم تذاكر مكتب المساعدة كإشارة:

• زيادة حجم التذاكر: قم بإبطاء عمليات النشر والاتصالات وإجراءات الإنفاذ
• انخفاض حجم التذاكر: قم بزيادة الأنشطة مرة أخرى

أنشئ مجموعات أمان Microsoft Entra ID لكل موجة وأضف المجموعات إلى سياساتك بشكل تدريجي. هذا يمنع إرهاق فرق الدعم.

10. قائمة التحقق التجريبية لمفاتيح المرور المتزامنة#

إذا كان الهدف هو مفاتيح المرور المتزامنة بدون الاعتماد على Microsoft Authenticator، فاتبع وضع الإصدار التجريبي هذا:

1. تمكين مفاتيح المرور المتزامنة (معاينة) اتبع مفاتيح المرور المتزامنة (معاينة) Synced passkeys (preview).

2. استخدام ملفات تعريف مفاتيح المرور (معاينة) واستهداف المجموعة التجريبية قم بإنشاء/تعيين ملف تعريف يسمح بمفاتيح المرور المتزامنة كما هو موضح في ملفات تعريف مفاتيح المرور Passkey Profiles.

3. عدم فرض الإثبات (على الأقل للمجموعة التجريبية) إن فرض الإثبات يستبعد مفاتيح المرور المتزامنة وفقًا لـ وثائق مفاهيم مفاتيح المرور (FIDO2) Passkeys (FIDO2) concepts documentation.

4. تجنب قوائم السماح الصارمة لـ AAGUID في البداية ابدأ بالتساهل لتأكيد التدفق، ثم قم بتشديد القيود بمجرد أن تعرف مزودي الخدمة الذين ترغب في السماح لهم. راجع تمكين مفاتيح المرور (FIDO2) Enable passkeys (FIDO2).

5. التأكد من أن الوصول المشروط لا يفرض Microsoft Authenticator تأكد من أن نقاط قوة CA/المصادقة لا تزال تسمح بملف تعريف مفتاح المرور الذي تقصده (وإلا فسيشبه الاعتماد على Microsoft Authenticator).

6. التحقق من صحة نموذج الهوية (عضو مقابل ضيف) إذا كان المستخدمون ضيوفًا، فتأكد من قابلية الدعم المتوقعة في نموذج المستأجر الخاص بك قبل قضاء الوقت في ضبط ملفات التعريف.

11. الخاتمة#

يُعد نشر مفاتيح المرور في المؤسسات معقدًا تشغيليًا، ولكن الطريق للمضي قدمًا محدد جيدًا. إليك الإجابات الرئيسية، المتوافقة مع الأسئلة التشغيلية الرئيسية المطروحة أعلاه:

1. مفاتيح المرور المرتبطة بالجهاز مقابل المتزامنة: بيانات الاعتماد المرتبطة بالجهاز (مثل Microsoft Authenticator، وWindows Hello، وYubiKeys، والبطاقات الذكية) مرتبطة ارتباطًا وثيقًا بجهاز واحد وتفي بـ AAL3. تعمل مفاتيح المرور المتزامنة (مثل iCloud Keychain، وGoogle Password Manager) عبر الأجهزة وتفي بـ AAL2. تحتاج معظم المؤسسات إلى كليهما: مصدقات أجهزة للمسؤولين (AAL3) ومفاتيح مرور متزامنة للقوى العاملة الأوسع (AAL2).

2. التشغيل الأولي للموظفين الجدد: استخدم رمز الوصول المؤقت (TAP) لحل مشكلة "الدجاجة والبيضة" عند التأهيل. بالنسبة لعمليات النشر واسعة النطاق، قم بأتمتة هذا عبر Graph API. لحالات الاستخدام عالية الضمان، أكمل عملية التأهيل باستخدام Entra Verified ID و Face Check.

3. استرداد الهاتف المستبدل: قدّم طرق استرداد متعددة: كشك استرداد للخدمة الذاتية (استخدم جهاز كمبيوتر محمول كجهاز للتشغيل الأولي)، ورمز TAP بمساعدة المدير عبر My Staff وSSAR (استرداد حساب الخدمة الذاتية) مع Verified ID لحالات الحافة.

4. أخطاء التكوين: تتضمن الأخطاء الأكثر شيوعًا فرض الإثبات عالميًا، وعدم تمكين ميزات المعاينة لمفاتيح المرور المتزامنة، وقوائم السماح لـ AAGUID الصارمة للغاية، وسياسات الوصول المشروط (CA) التي تنشئ تبعيات دائرية.

5. ضيوف B2B: تجنب تسجيل مفاتيح المرور مباشرة لضيوف B2B في المستأجر الخاص بك. بدلاً من ذلك، قم بتمكين ثقة الوصول عبر المستأجرين (Cross-Tenant Access Trust) للتحقق من صحة بيانات الاعتماد من المستأجر الرئيسي للضيف.

6. مفاتيح الأجهزة مقابل مفاتيح المرور المحمولة: مفاتيح أمان الأجهزة مطلوبة لأدوار معينة عالية الأمان (المسؤولون، محطات العمل المشتركة) ولكنها تمثل عقبات لوجستية على نطاق واسع. تُعد مفاتيح المرور المحمولة أكثر عملية بشكل عام للقوى العاملة.

7. macOS إلى جانب Windows: استخدم Platform SSO مع JAMF/MDM لتمكين دعم مفتاح المرور على macOS بالتوازي مع عمليات نشر Windows. خطط لسير عمل خاص بالنظام الأساسي.

8. التدابير الاستباقية: استخدم Intune لتحديد الأجهزة غير النشطة وحث المستخدمين على المعالجة قبل حدوث الحظر. فكر في جعل تسجيل مفتاح المرور شرطًا أساسيًا لتسجيل Intune لتعزيز التبني المبكر. قم ببناء سير عمل لاسترداد الخدمة الذاتية باستخدام أجهزة الكمبيوتر المحمولة كأجهزة للتشغيل الأولي.

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

حول Corbado

Corbado هي Passkey Intelligence Platform لفِرَق CIAM التي تُدير المصادقة الاستهلاكية على نطاق واسع. نُمكّنك من رؤية ما لا تستطيع سجلات IDP وأدوات التحليل العامة إظهاره: أي الأجهزة وإصدارات أنظمة التشغيل والمتصفحات ومديري بيانات الاعتماد تدعم passkeys، ولماذا لا تتحوّل عمليات التسجيل إلى عمليات دخول، وأين يفشل تدفق WebAuthn، ومتى يُعطّل تحديث نظام التشغيل أو المتصفح تسجيل الدخول بصمت — كل ذلك دون استبدال Okta أو Auth0 أو Ping أو Cognito أو IDP الداخلي لديك. منتجان: Corbado Observe يُضيف observability للـ passkeys وأي طريقة دخول أخرى. Corbado Connect يُقدّم managed passkeys مع تحليلات مدمجة (إلى جانب IDP الخاص بك). تُشغّل VicRoads passkeys لأكثر من 5 ملايين مستخدم مع Corbado (تفعيل passkey بنسبة +80%). تحدث مع خبير Passkey →

الأسئلة الشائعة#

لماذا يؤدي تمكين المصادقة متعددة العوامل المقاومة للتصيد في الوصول المشروط إلى حظر جميع المستخدمين لدي؟#

إن إنشاء سياسة وصول مشروط تتطلب مصادقة متعددة العوامل (MFA) مقاومة للتصيد لجميع التطبيقات السحابية يؤدي على الفور إلى حظر أي مستخدم لم يقم بتسجيل مفتاح مرور بعد، بما في ذلك حظر الوصول إلى صفحة تسجيل معلومات الأمان نفسها. هذا الاعتماد الدائري، الذي يُسمى مفارقة "تسجيل معلومات الأمان"، يعني أنه يجب عليك إصدار رمز وصول مؤقت (TAP) للمستخدمين المتأثرين قبل تمكين الإنفاذ حتى يتمكنوا من إكمال التسجيل الأولي.

كيف أتعامل مع المستخدمين الضيوف من نوع B2B عندما يتطلب المستأجر الخاص بي مصادقة متعددة العوامل مقاومة للتصيد؟#

لا يدعم Entra ID قيام المستخدمين الضيوف بتسجيل مفاتيح FIDO2 في مستأجر الموارد، لذا فإن محاولة فرض تسجيل مفتاح المرور للضيوف ستفشل. الإصلاح الصحيح هو تكوين إعدادات الوصول عبر المستأجرين ضمن الهويات الخارجية للوثوق بمطالبات المصادقة متعددة العوامل (MFA) من المستأجر الرئيسي للضيف، مما يعني أن مفتاح YubiKey المُستخدم في مؤسستهم الخاصة يلبي متطلباتك الخاصة بالمصادقة متعددة العوامل المقاومة للتصيد دون أي تسجيل في المستأجر الخاص بك.

ما الذي يتسبب في فشل مصادقة رمز الاستجابة السريعة (QR) عبر الأجهزة بصمت عند تسجيل الدخول باستخدام مفتاح مرور؟#

تتطلب المصادقة عبر الأجهزة تمكين البلوتوث (Bluetooth) على كل من الكمبيوتر والهاتف لإكمال مصافحة القرب عبر تقنية Bluetooth Low Energy (BLE)، لذلك فإن أي سياسة خاصة بالمؤسسة تؤدي إلى تعطيل البلوتوث ستؤدي إلى كسر التدفق بالكامل. يستخدم التدفق أيضًا اتصال WebSocket إلى cable.auth.com، والذي غالبًا ما يتم حظره بواسطة جدران الحماية أو تكوينات Zscaler، مما يتسبب في توقف فحص رمز الاستجابة السريعة أو فشله دون رسالة خطأ واضحة.

كيف يمكنني مراقبة الموظفين المستعدين لفرض المصادقة متعددة العوامل المقاومة للتصيد قبل تشغيلها؟#

يوفر مصنف Phishing-Resistant Passwordless من Microsoft، والذي يمكن الوصول إليه عبر مركز إدارة Entra ضمن المراقبة > المصنفات، طريقة عرض جاهزية التسجيل توضح أزواج المستخدمين/الأجهزة التي يمكنها التسجيل حسب النظام الأساسي ونوع بيانات الاعتماد. لمعرفة جاهزية الإنفاذ، قم بإنشاء سياسة وصول مشروط مخصصة لإعداد التقارير فقط تتطلب مصادقة متعددة العوامل (MFA) مقاومة للتصيد بحيث تكشف سجلات تسجيل الدخول عن المستخدمين الذين سيتم حظرهم قبل تنشيط الإنفاذ المباشر.

ما هي أفضل استراتيجية استرداد للموظفين الذين يحصلون على هاتف جديد ويفقدون إمكانية الوصول إلى مفتاح المرور الخاص بهم؟#

النهج الموصى به متعدد الطبقات: كشك استرداد للخدمة الذاتية باستخدام كمبيوتر محمول مؤمن بواسطة WHfB يقوم بإنشاء رمز وصول مؤقت عبر Graph API ويغطي معظم الحالات دون تدخل مكتب المساعدة. بالنسبة للمستخدمين الذين ليس لديهم كمبيوتر محمول، يقوم TAP بمساعدة المدير عبر بوابة فريق العمل الخاص بي (My Staff) بتفويض الاسترداد إلى المديرين المباشرين، كما يعالج استرداد حساب الخدمة الذاتية مع التحقق من الوجه البيومتري الخاص بـ Entra Verified ID الحالات التي تتطلب إعادة التحقق الكامل من الهوية.

قراءة متعمقة#

للاطلاع على عمليات الغوص العميق في عمليات نشر FIDO2/مفتاح المرور الخاصة بالمؤسسات، تابع الخبراء مثل Merill Fernando و Jan Bakker الذين ينشرون بانتظام إرشادات عملية حول مصادقة Microsoft Entra.