Passkeys على نطاق المؤسسات: دروس عملية من عمليات النشر الحقيقية

في عام 2023، وجد تقرير تحقيقات خرق البيانات لشركة Verizon أن 74% من جميع الاختراقات تضمنت العنصر البشري — التصيد الاحتيالي، سرقة بيانات الاعتماد، أو إساءة الاستخدام — بتكلفة متوسطة تبلغ 4.45 مليون دولار لكل حادث. كلمات المرور هي السبب الجذري. على الرغم من عقود من تفويض MFA، يتم تبديل رموز SMS عبر SIM، ويتم إرهاق إشعارات الدفع، ويتم استخراج بذور TOTP عبر وكلاء وسيط خبيثين مثل Evilginx2. Passkeys — المتجذرة في معيار FIDO2 — هي أول نوع من بيانات الاعتماد مقاومة للتصيد الاحتيالي من الناحية المعمارية. لكن فرق تكنولوجيا المعلومات في المؤسسات التي تتسرع في تجاوز الشرائح التسويقية البراقة تكتشف بسرعة أن النشر في الإنتاج هو وحش مختلف تمامًا.

لماذا تستمر كلمات المرور — ومعظم MFA — في الفشل

المشكلة ليست سلوك المستخدم؛ إنها البروتوكول. يجب نقل الأسرار المشتركة (كلمات المرور، رموز OTP) والتحقق منها من جانب الخادم، مما يخلق أسطح اعتراض في كل خطوة. تتطلب فئات MFA المقاومة للتصيد الاحتيالي في NIST SP 800-63B موثّقات قائمة على الحيازة حيث لا يغادر المفتاح الخاص الجهاز أبدًا ويكون مجال الطرف المعتمد مرتبطًا بالتحدي تشفيريًا. فقط مفاتيح الأمان المادية (FIDO2/CTAP2) وpasskeys تفي بهذا المعيار. ومع ذلك، توقفت المفاتيح المادية عند نطاق المستهلك بسبب التكلفة واحتكاك تجربة المستخدم. تحل Passkeys مشكلة التوزيع عن طريق المزامنة عبر مخازن المفاتيح الخاصة بالمنصة.

ما هي Passkeys في الواقع (تقنيًا)

Passkey هو بيانات اعتماد FIDO2 مخزنة كزوج مفاتيح غير متماثل. المفتاح الخاص موجود داخل حاوية آمنة أو موثّق منصة — Apple Secure Enclave، Android Strongbox، Windows Hello TPM — ولا يتم تصديره أبدًا. يؤدي التسجيل إلى إنشاء معرف بيانات اعتماد، ومفتاح عام يتم إرساله إلى خادم الطرف المعتمد، واختياريًا سلسلة شهادة توثيق. ينتج عن المصادقة بيان موقع على تحدي الخادم متسلسل مع الأصل (المخطط + المضيف + المنفذ)، مما يجعل التوقيع غير صالح على أي نطاق آخر. هذا هو ضمان مكافحة التصيد.

تضيف مواصفات WebAuthn المستوى 3 ثلاثة أنواع من بيانات الاعتماد ذات الصلة بالمؤسسات:

• Platform passkeys (متزامنة): مخزنة في iCloud Keychain، Google Password Manager، أو Windows Hello — متزامنة عبر الأجهزة عبر خزائن مشفرة من طرف إلى طرف. مريحة، لكن مادة المفتاح الخاص تغادر حدود الجهاز (مشفرة).
• Platform passkeys (مقيدة بالجهاز): مرتبطة بـ TPM أو Secure Enclave لجهاز واحد. ضمان عالٍ، تتعطل بشدة عند مسح الجهاز — تختفي بيانات الاعتمام ببساطة.
• Roaming authenticators (CTAP2): مفاتيح مادية مثل سلسلة YubiKey 5 أو FEITIAN BioPass. أعلى ضمان، وبدون مزامنة، ويمثل عنق الزجاجة للتوزيع على نطاق واسع في المؤسسات.

أضاف CTAP2.1 بروتوكول PIN/UV Auth 2، وإدارة بيانات الاعتماد (قائمة/حذف بيانات الاعتماد على الجهاز)، وتخزين الكتل الكبيرة. تتطلب عمليات النشر المؤسسية التي تستهدف AAL3 (NIST) أو مستوى ضمان الموثّق 3 عادةً موثّقات مقيدة بالجهاز أو متجوّلة.

واقع النشر في المؤسسات

إدارة الجهاز والتحقق من التوثيق

تتجاهل عروض passkey للمستهلكين التوثيق؛ لا يمكن لعمليات النشر المؤسسية ذلك. يسمح التوثيق للطرف المعتمد بالتحقق من طراز الموثّق والشركة المصنعة قبل قبول التسجيل. يدعم Microsoft Entra ID تطبيق سياسة التوثيق — يمكنك تقييد تسجيلات passkey بسلسلة YubiKey 5 أو أجهزة Android محددة بمفاتيح مدعومة بالأجهزة. يربط Okta FastPass بالمثل توثيق الجهاز بحالة الامتثال لـ MDM عبر ميزة Device Trust؛ سيفشل جهاز macOS غير المسجل في Jamf Pro في التسجيل. تفرض Duo Trusted Endpoints بوابات مماثلة عبر وكيل نقطة النهاية الخاص بها.

التحدي: يجب جلب شهادات التوثيق من خدمة البيانات الوصفية لـ FIDO (MDS3)، وتخزينها مؤقتًا، وإعادة التحقق من صحتها. تحتوي إدخالات MDS3 على إبطال — يمكن وضع نموذج موثّق مخترق في القائمة السوداء، ويجب أن يتعامل كودك مع ذلك بلطف دون حظر المستخدمين الحاليين على بيانات الاعتماد المسجلة مسبقًا.

المزامنة عبر المنصات ومشكلة تجزئة النظام البيئي

تدير Apple وGoogle وMicrosoft كل منها خزائن passkey منفصلة. الموظف الذي يسجل passkey على iPhone الخاص به (iCloud Keychain) لا يمكنه استخدامه على كمبيوتره المحمول الخاص بالشركة الذي يعمل بنظام Windows 11 إلا إذا استخدم تدفق مصادقة عبر الأجهزة — مسح رمز QR عبر النقل الهجين لـ CTAP2، والذي يعتمد على قرب Bluetooth LE. هذا مدعوم في Chrome 109+ و Safari 16+ على جميع المنصات، لكنه يتطلب تمكين Bluetooth — وهو شيء تقوم العديد من سياسات تعزيز نقطة النهاية المؤسسية بتعطيله.

يعمل Windows Hello for Business مع Entra ID hybrid join بشكل جيد داخل نظام Microsoft البيئي. لكن بيئة BYOD+Corporate مختلطة مع macOS و iOS و Android و Windows تخلق ما يصل إلى أربع خزائن بيانات اعتماد منفصلة يجب إدارتها ومراقبتها ومراعاتها أثناء إنهاء الخدمة. لا يتحد أي منها مع الآخر بشكل أصلي. يعمل عرض passkey التجاري من 1Password — المتاح من 1Password 8 — كمدير passkey تابع لجهة خارجية يربط بين الأنظمة البيئية، لكنه يقدم حدود ثقة جديدة ويتطلب ملحق متصفح 1Password للتعامل مع استدعاءات WebAuthn عبر API navigator.credentials.get().

انضمام الموظفين وإنهاء خدمتهم

الانضمام هو النصف الأسهل. تدعم معظم IdPs الآن تسجيل passkey التمهيدي: يمكن لـ Okta و Entra ID إرسال رابط تسجيل محدد المدة يسمح للموظف الجديد بتسجيل passkey فور التحقق من هويته عبر قناة منفصلة (OTP عبر البريد الإلكتروني أو التحقق من الهوية بواسطة المدير). النصف الصعب هو إنهاء الخدمة. يتطلب إبطال passkey إبطال بيانات الاعتماد في الطرف المعتمد — وهي عملية فورية من جانب الخادم — لكن بيانات الاعتماد قد تظل موجودة في iCloud Keychain أو Google Password Manager، قادرة على محاولة المصادقة التي سيتم رفضها الآن. الموظفون الذين يغادرون بشروط سيئة لا يمكنهم "أخذ passkey الخاص بهم" للمصادقة بنجاح، لكن فرق تكنولوجيا المعلومات بحاجة إلى runbook واضحة حتى لا يخلطوا بين إبطال بيانات الاعتماد (تم) وحذف بيانات الاعتماد من خزينة الجهاز الشخصي للمستخدم (ليس ضمن اختصاصك).

التراجعات الشرطية لواجهة المستخدم

ليست كل المتصفحات أو الأجهزة أو إصدارات نظام التشغيل تدعم passkeys. أضاف Safari دعم passkey في iOS 16 / macOS Ventura 13. أضاف Chrome واجهة مستخدم ثابتة لـ passkey في الإصدار 108. أضاف Firefox دعم passkey في الإصدار 122 — متأخرًا بشكل ملحوظ. تتطلب Windows Hello passkeys الحد الأدنى Windows 10 22H2 أو Windows 11 21H2. يجب أن يطبق تدفق المصادقة الخاص بك الوساطة الشرطية — استدعاء navigator.credentials.get() مع mediation: "conditional" — لعرض passkeys بأسلوب الإكمال التلقائي دون حظر المستخدمين على المتصفحات غير المدعومة من التراجع إلى كلمات المرور أو TOTP. سيؤدي إسقاط التراجع مبكرًا إلى حظر مستخدمي الأجهزة القديمة وإنشاء تذاكر دعم فوري.

مشهد البائعين

Microsoft Entra ID هو أكثر قصة passkey مؤسسية اكتمالاً اليوم. دعم مفتاح الأمان FIDO2 (المقيد بالجهاز) متاح بشكل عام منذ 2021؛ تمت إضافة passkeys المتزامنة لـ Windows Hello في 2024. يمكن لتصفية التوثيق، ومطابقة الأرقام لدفع MFA، وسياسات الوصول الشرطي أن تحصر تسجيل passkey بالأجهزة المتوافقة فقط. النقطة الضعيفة: سيناريوهات Hybrid Azure AD Join في بيئات Active Directory القديمة على Windows Server بها حواف خشنة، خاصة مع التطبيقات المحلية التي تمر عبر AD FS بدلاً من Entra.

Okta تدعم FIDO2 WebAuthn كعامل مصادقة داخل Okta Verify FastPass. تسمح تكاملات Device Trust (Jamf, Microsoft Intune, VMware Workspace ONE) بالتحقق من أن الجهاز مسجل في MDM قبل السماح بالتسجيل. وصل دعم passkey من Okta كعامل أساسي بدون كلمة مرور (استبدال كلمات المرور بالكامل، وليس فقط كخطوة MFA) إلى التوفر العام في أواخر 2024.

Duo Security (Cisco) أضافت دعم WebAuthn كعامل Duo لكن قصة passkey الخاصة بها لتدفقات بدون كلمة مرور بالكامل أقل نضجًا من Entra أو Okta. تتفوق Duo في البيئات غير المتجانسة حيث لا تدعم جميع التطبيقات SAML/OIDC — تسمح إضافات Unix PAM و Windows Credential Provider بضمان مماثل لـ passkey لتدفقات SSH و RDP.

1Password Business يسمح بتخزين واستخدام passkeys داخل خزينة 1Password، مع سياسات مشاركة على مستوى الفريق وسجلات تدقيق. مفيد لحسابات الخدمات المشتركة لكنه يقدم مخاطر حصر البائع ويتطلب تقييم ما إذا كانت متطلبات AAL الخاصة بك تسمح بمدير passkey قائم على البرامج.

أنماط الفشل الشائعة في الإنتاج

• سياسة التوثيق تعطل النشر: تمكين التوثيق الصارم قبل تدقيق نماذج الموثّق في أسطول أجهزتك سيحجب الموظفين على أجهزة Android القديمة أو الأجهزة غير المعتمدة لـ FIDO2. ابدأ بالتوثيق: "indirect" وشدد لاحقًا.
• تعطيل Bluetooth بواسطة السياسة يقتل المصادقة عبر الأجهزة: حدد تدفقات المصادقة عبر الأجهزة القائمة على رمز QR التي تعتمد على BLE وأنشئ استثناءات أو وجه المستخدمين إلى مفاتيح الأمان المتجوّلة بدلاً من ذلك.
• مزامنة iCloud Keychain مع الأجهزة الشخصية: تشارك أجهزة Mac المسجلة في الشركة iCloud Keychain مع أجهزة iPhone الشخصية للموظفين إذا تم استخدام نفس Apple ID. لا تستطيع ملفات تعريف MDM عزل هذا بدون Apple ID مُدار — خطط لتسجيل Apple Business Manager الخاص بك وفقًا لذلك.
• عدم تطابق RP ID يعطل تطبيقات الطرف الثالث: التطبيقات المسجلة بمعرف طرف معتمد app.company.com سترفض passkeys المسجلة مقابل company.com والعكس صحيح. قم بتدقيق جميع تكوينات RP ID الخاصة بك قبل النشر.
• لا يوجد مسار لاسترداد الحساب: جهاز مفقود مع passkey مقيد بالجهاز وبدون موثّق احتياطي يعني إعادة إثبات الهوية بمساعدة مكتب المساعدة من البداية. حدد SLA الاسترداد قبل الإطلاق المباشر.

إطار عمل النشر خطوة بخطوة

يفترض الإطار التالي أن Entra ID أو Okta هو IdP، وأسطول مختلط من Windows/macOS/iOS/Android، وهدف القضاء على كلمات المرور كعامل أساسي في غضون 18 شهرًا.

1. الشهر 1-2 — التدقيق: قم بجرد نماذج الموثّق في أسطولك عبر MDM. تحقق من إصدارات المتصفح. قم بتخطيط طريقة المصادقة لكل تطبيق (SAML, OIDC, NTLM القديم). حدد متطلبات AAL لكل طبقة تطبيق.
2. الشهر 2-3 — تصميم السياسة: حدد أي شرائح المستخدمين تحصل على passkeys متزامنة مقابل مقيدة بالجهاز. قم بصياغة سياسة التوثيق (ابدأ بـ indirect). حدد runbooks استرداد الحساب. تأكد من أن سياسات الوصول الشرطي / MFA التكيفي لن تحظر التسجيل.
3. الشهر 3-5 — التجربة: انشر لموظفي تكنولوجيا المعلومات والمتبنين الأوائل. قم بتمكين passkeys كعامل إضافي اختياري إلى جانب كلمات المرور. قم بقياس معدلات نجاح التسجيل، ومحاولات المصادقة عبر الأجهزة، ومعدلات التراجع في سجلات IdP الخاصة بك.
4. الشهر 5-10 — التسجيل الواسع: أرسل حملات تسجيل مع روابط تسجيل ذاتية الخدمة. استهدف تسجيل 80% من القوى العاملة. أبق كلمات المرور نشطة كتراجع. راقب حجم تذاكر مكتب المساعدة — تذاكر استرداد الحساب وفقدان passkey هي إشارتك.
5. الشهر 10-18 — إلغاء كلمة المرور: للمستخدمين المسجلين، قم بتطبيق سياسات الوصول الشرطي التي تتطلب passkey (FIDO2) كطريقة مصادقة. قم بتعطيل مصادقة كلمة المرور لطبقات التطبيق المغطاة. حافظ على عملية استرداد break-glass برموز أجهزة للحسابات الإدارية.

ما لا يزال النظام البيئي ينقصه

Passkeys لم تنته بعد. لا تزال هناك عدة فجوات حتى منتصف 2025:

• لا يوجد معيار تجوال passkey مؤسسي أصلي: لا يوجد معيار من FIDO Alliance لترحيل passkeys بين المنصات (مثل iCloud Keychain إلى Google Password Manager). حصر البائع حقيقي.
• دعم محدود لـ SSH/RDP/VPN: WebAuthn هو API متصفح. توجد وكلاء SSH تدعم مفاتيح أجهزة FIDO2 (عبر ssh-keygen -t ecdsa-sk)، لكن passkeys المتزامنة لا يمكن استخدامها في تدفقات SSH الأصلية بدون طبقة جسر.
• معالجة إبطال التوثيق غير ناضجة: معظم تطبيقات IdP لا تتعامل بشكل مناسب مع أحداث إبطال MDS3 لبيانات الاعتماد المسجلة حالياً. أنت بحاجة إلى منطق مخصص أو التزام من البائع.
• تأخر Firefox: دعم passkey من Firefox (v122+) لا يزال به حواف خشنة في تجربة المستخدم للوساطة الشرطية والتدفقات عبر الأجهزة، وحصته السوقية في البيئات المؤسسية — خاصة الخدمات الحكومية والمالية — غير تافهة.

تبني passkey المؤسسي تجاوز مرحلة المتبنين الأوائل — مايكروسوفت وجوجل وOkta جميعها تشحن ميزات GA. الفرق التي تنجح هي تلك التي تعاملها على أنها ترحيل بنية تحتية، وليس تحديث تطبيق: تدقيق أولاً، تجربة بلا كلل، وأبقِ التراجعات حية لفترة أطول مما هو مريح. مقاومة التصيد في الطرف الآخر تستحق التكلفة التشغيلية.