Passkeys در مقیاس سازمانی: درس‌های عملی از استقرارهای واقعی

در سال ۲۰۲۳، گزارش تحقیقات نقض داده‌های Verizon نشان داد که ۷۴٪ از تمام نقض‌ها شامل عامل انسانی — فیشینگ، سرقت اعتبارنامه یا سوءاستفاده — با هزینه متوسط ۴.۴۵ میلیون دلار به ازای هر حادثه بوده است. رمزهای عبور ریشه مشکل هستند. با وجود دهه‌ها الزام به MFA، کدهای SMS با SIM Swap جابجا می‌شوند، اعلان‌های فشاری با خستگی بمباران می‌شوند، و seedهای TOTP توسط پراکسی‌های میان‌افزار مخرب مانند Evilginx2 استخراج می‌شوند. Passkeys — مبتنی بر استاندارد FIDO2 — اولین نوع اعتبارنامه هستند که از نظر معماری در برابر فیشینگ مقاوم هستند. اما تیم‌های فناوری اطلاعات سازمانی که از اسلایدهای براق فروشندگان عبور می‌کنند، به سرعت متوجه می‌شوند که استقرار در محیط تولید کاملاً متفاوت است.

چرا رمزهای عبور — و اکثر MFA — همچنان شکست می‌خورند

مشکل رفتار کاربر نیست؛ مشکل پروتکل است. اسرار مشترک (رمزهای عبور، OTP) باید منتقل و در سمت سرور تأیید شوند که سطوح رهگیری در هر گام ایجاد می‌کند. دسته‌بندی‌های MFA مقاوم در برابر فیشینگ در NIST SP 800-63B نیاز به تأییدکننده‌های مبتنی بر مالکیت دارند که در آن کلید خصوصی هرگز دستگاه را ترک نمی‌کند و دامنه طرف متکی به صورت رمزنگاری به چالش مرتبط می‌شود. فقط کلیدهای امنیتی سخت‌افزاری (FIDO2/CTAP2) و passkeys این معیار را برآورده می‌کنند. با این حال، کلیدهای سخت‌افزاری در مقیاس مصرف‌کننده به دلیل هزینه و اصطکاک تجربه کاربری متوقف شدند. Passkeys مشکل توزیع را با همگام‌سازی از طریق فروشگاه‌های کلید پلتفرم حل می‌کنند.

Passkeys در واقع چه هستند (از نظر فنی)

یک passkey یک اعتبارنامه FIDO2 است که به صورت یک جفت کلید نامتقارن ذخیره می‌شود. کلید خصوصی در داخل یک محفظه امن یا تأییدکننده پلتفرم — Secure Enclave اپل، Strongbox اندروید، TPM ویندوز Hello — قرار دارد و هرگز صادر نمی‌شود. ثبت نام یک شناسه اعتبارنامه، یک کلید عمومی که به سرور طرف متکی ارسال می‌شود، و به صورت اختیاری یک زنجیره گواهی تصدیق تولید می‌کند. احراز هویت یک اظهارنامه امضا شده بر روی یک چالش سرور که با مبدأ (طرح + میزبان + پورت) ترکیب شده است تولید می‌کند و امضا را در هر دامنه دیگری نامعتبر می‌سازد. این تضمین ضد فیشینگ است.

مشخصات WebAuthn سطح ۳ سه نوع اعتبارنامه مرتبط با سازمان را اضافه می‌کند:

• Platform passkeys (همگام‌سازی شده): ذخیره شده در iCloud Keychain، Google Password Manager یا Windows Hello — از طریق vaultهای رمزگذاری شده سرتاسری بین دستگاه‌ها همگام‌سازی می‌شوند. راحت، اما مواد کلید خصوصی مرز دستگاه را ترک می‌کند (رمزگذاری شده).
• Platform passkeys (مقید به دستگاه): به یک TPM یا Secure Enclave دستگاه متصل می‌شوند. اطمینان بالا، در صورت پاک شدن دستگاه به شدت آسیب می‌بیند — اعتبارنامه به سادگی از بین می‌رود.
• Roaming authenticators (CTAP2): کلیدهای فیزیکی مانند سری YubiKey 5 یا FEITIAN BioPass. بالاترین سطح اطمینان، بدون همگام‌سازی، و گلوگاه توزیع در مقیاس بزرگ سازمانی.

CTAP2.1 پروتکل PIN/UV Auth 2، مدیریت اعتبارنامه (لیست/حذف اعتبارنامه روی دستگاه) و ذخیره blob بزرگ را اضافه کرد. استقرارهای سازمانی که هدف AAL3 (NIST) یا Authenticator Assurance Level 3 را دارند معمولاً تأییدکننده‌های مقید به دستگاه یا roaming authenticators را الزام می‌کنند.

واقعیت‌های استقرار سازمانی

مدیریت دستگاه و تأیید تصدیق

دموهای گذرواژه مصرف‌کننده تصدیق را نادیده می‌گیرند؛ استقرارهای سازمانی نمی‌توانند. تصدیق به طرف متکی اجازه می‌دهد قبل از پذیرش ثبت نام، مدل و سازنده تأییدکننده را تأیید کند. Microsoft Entra ID از اعمال خط‌مشی تصدیق پشتیبانی می‌کند — می‌توانید ثبت نام passkey را به سری YubiKey 5 یا دستگاه‌های اندرویدی خاص با کلیدهای پشتیبانی شده سخت‌افزاری محدود کنید. Okta FastPass نیز به طور مشابه تصدیق دستگاه را از طریق ویژگی Device Trust به وضعیت انطباق MDM مرتبط می‌کند؛ یک دستگاه macOS که در Jamf Pro ثبت نشده باشد در ثبت نام شکست می‌خورد. Duo Trusted Endpoints از طریق عامل نقطه پایانی خود، گیت‌های مشابهی را اعمال می‌کند.

چالش: گواهی‌های تصدیق باید از سرویس ابرداده FIDO (MDS3) واکشی، ذخیره و دوباره اعتبارسنجی شوند. ورودی‌های MDS3 دارای ابطال هستند — یک مدل تأییدکننده به خطر افتاده می‌تواند در لیست سیاه قرار گیرد و کد شما باید این کار را به آرامی انجام دهد بدون اینکه کاربران موجود در اعتبارنامه‌های ثبت شده قبلی را قفل کند.

همگام‌سازی بین پلتفرمی و مشکل تکه‌تکه شدن اکوسیستم

اپل، گوگل و مایکروسافت هر کدام vaultهای passkey جداگانه‌ای دارند. کارمندی که یک passkey را در آیفون خود (iCloud Keychain) ثبت می‌کند نمی‌تواند از آن در لپ‌تاپ شرکتی ویندوز ۱۱ خود استفاده کند مگر اینکه از جریان احراز هویت متقابل دستگاه — اسکن کد QR از طریق حمل و نقل ترکیبی CTAP2 که به نزدیکی Bluetooth LE متکی است — استفاده کند. این در Chrome 109+ و Safari 16+ در تمام پلتفرم‌ها پشتیبانی می‌شود، اما نیاز به فعال بودن بلوتوث دارد — چیزی که بسیاری از خط‌مشی‌های سخت‌افزاری نقطه پایانی سازمانی آن را غیرفعال می‌کنند.

Windows Hello for Business با Entra ID hybrid join در اکوسیستم مایکروسافت به خوبی کار می‌کند. اما یک محیط ترکیبی BYOD+Corporate با macOS, iOS, Android و Windows تا چهار vault اعتبارنامه جداگانه ایجاد می‌کند که باید مدیریت، نظارت و در هنگام خروج از سازمان حساب شوند. هیچ‌کدام به طور بومی با یکدیگر فدره نمی‌شوند. پیشنهاد passkey تجاری 1Password — موجود از 1Password 8 — به عنوان یک مدیر passkey شخص ثالث عمل می‌کند که اکوسیستم‌ها را پل می‌زند، اما یک مرز اعتماد جدید معرفی می‌کند و نیاز به افزونه مرورگر 1Password برای مدیریت تماس‌های WebAuthn از طریق API navigator.credentials.get().

استخدام و خروج کارکنان

استخدام نیمه آسان‌تر است. اکثر IdPها اکنون از ثبت نام passkey پشتیبانی می‌کنند: Okta و Entra ID می‌توانند یک لینک ثبت نام با زمان محدود ارسال کنند که به یک کارمند جدید اجازه می‌دهد بلافاصله پس از تأیید هویت خود از طریق یک کانال جداگانه (OTP ایمیل یا تأیید هویت توسط مدیر) یک passkey ثبت کند. نیمه سخت، خروج کارکنان است. ابطال یک passkey نیاز به ابطال اعتبارنامه در طرف متکی دارد — که یک عملیات فوری سمت سرور است — اما اعتبارنامه ممکن است همچنان در iCloud Keychain یا Google Password Manager وجود داشته باشد و بتواند تلاش احراز هویتی انجام دهد که اکنون رد می‌شود. کارمندانی که با شرایط بد ترک می‌کنند نمی‌توانند "passkey خود را با خود ببرند" تا با موفقیت احراز هویت کنند، اما تیم‌های IT نیاز به runbookهای واضح دارند تا ابطال اعتبارنامه (انجام شده) را با حذف اعتبارنامه از vault دستگاه شخصی کاربر (تحت صلاحیت شما نیست) اشتباه نگیرند.

بازگشت‌های UI شرطی

همه مرورگرها، دستگاه‌ها یا نسخه‌های سیستم عامل از passkeys پشتیبانی نمی‌کنند. سافاری پشتیبانی passkey را در iOS 16 / macOS Ventura 13 اضافه کرد. کروم UI پایدار passkey را در نسخه ۱۰۸ اضافه کرد. فایرفاکس پشتیبانی passkey را در نسخه ۱۲۲ اضافه کرد — به طور قابل توجهی دیر. Windows Hello passkeys حداقل به Windows 10 22H2 یا Windows 11 21H2 نیاز دارند. جریان احراز هویت شما باید Conditional Mediation را پیاده‌سازی کند — فراخوانی navigator.credentials.get() با mediation: "conditional" — تا passkeys را به سبک تکمیل خودکار بدون مسدود کردن کاربران در مرورگرهای پشتیبانی‌نشده از بازگشت به رمزهای عبور یا TOTP نمایش دهد. حذف زودهنگام بازگشت، کاربران دستگاه‌های قدیمی را قفل می‌کند و بلافاصله تیکت‌های پشتیبانی ایجاد می‌کند.

چشم‌انداز فروشندگان

Microsoft Entra ID امروزه کامل‌ترین داستان passkey سازمانی است. پشتیبانی از کلید امنیتی FIDO2 (مقید به دستگاه) از سال ۲۰۲۱ در دسترس عموم بوده است؛ passkeys همگام‌سازی شده برای Windows Hello در سال ۲۰۲۴ اضافه شد. فیلتر تصدیق، تطبیق شماره برای MFA push، و خط‌مشی‌های دسترسی شرطی می‌توانند ثبت نام passkey را فقط به دستگاه‌های منطبق محدود کنند. نقطه ضعف: سناریوهای Hybrid Azure AD Join در محیط‌های Active Directory قدیمی ویندوز سرور دارای لبه‌های ناهمواری هستند، به ویژه با برنامه‌های داخلی که از AD FS به جای Entra عبور می‌کنند.

Okta از FIDO2 WebAuthn به عنوان یک عامل تأیید کننده در Okta Verify FastPass پشتیبانی می‌کند. ادغام‌های Device Trust آن (Jamf, Microsoft Intune, VMware Workspace ONE) اجازه می‌دهند قبل از اجازه ثبت نام، تأیید شود که دستگاه تحت MDM است. پشتیبانی passkey Okta به عنوان یک عامل بدون رمز عبور اولیه (جایگزینی کامل رمزهای عبور، نه فقط به عنوان گام MFA) در اواخر سال ۲۰۲۴ به دسترسی عمومی رسید.

Duo Security (Cisco) پشتیبانی WebAuthn را به عنوان یک عامل Duo اضافه کرد اما داستان passkey آن برای جریان‌های کاملاً بدون رمز عبور کمتر از Entra یا Okta بالغ است. Duo در محیط‌های ناهمگن که همه برنامه‌ها از SAML/OIDC پشتیبانی نمی‌کنند برتری دارد — افزونه‌های Unix PAM و Windows Credential Provider آن اجازه اطمینان معادل passkey را برای جریان‌های SSH و RDP می‌دهند.

1Password Business امکان ذخیره و استفاده از passkeys در داخل vault 1Password را با خط‌مشی‌های اشتراک‌گذاری در سطح تیم و لاگ‌های حسابرسی فراهم می‌کند. برای حساب‌های خدمات مشترک مفید است اما خطر قفل شدن فروشنده را معرفی می‌کند و نیاز به ارزیابی این دارد که آیا الزامات AAL شما یک مدیر passkey مبتنی بر نرم‌افزار را مجاز می‌کند.

حالت‌های شکست رایج در تولید

• خط‌مشی تصدیق استقرار را می‌شکند: فعال کردن تصدیق سختگیرانه قبل از حسابرسی مدل‌های تأییدکننده ناوگان دستگاه شما، کارمندان را در دستگاه‌های اندرویدی قدیمی یا سخت‌افزار غیرمعتبر FIDO2 مسدود می‌کند. با تصدیق: "indirect" شروع کنید و بعداً سخت‌گیرانه‌تر کنید.
• بلوتوث غیرفعال شده توسط خط‌مشی، احراز هویت متقابل دستگاه را از بین می‌برد: جریان‌های احراز هویت متقابل دستگاه مبتنی بر کد QR که به BLE متکی هستند را شناسایی کرده و استثنا قائل شوید یا کاربران را به کلیدهای سخت‌افزاری roaming هدایت کنید.
• iCloud Keychain به دستگاه‌های شخصی همگام‌سازی می‌شود: مک‌های ثبت شده شرکتی iCloud Keychain را با آیفون‌های شخصی کارمندان در صورت استفاده از همان 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، و هدف حذف رمزهای عبور به عنوان عامل اصلی در عرض ۱۸ ماه است.

1. ماه ۱-۲ — حسابرسی: مدل‌های تأییدکننده در ناوگان خود را از طریق MDM فهرست کنید. نسخه‌های مرورگر را بررسی کنید. روش احراز هویت هر برنامه (SAML, OIDC, NTLM قدیمی) را نقشه‌برداری کنید. الزامات AAL را به ازای هر لایه برنامه شناسایی کنید.
2. ماه ۲-۳ — طراحی خط‌مشی: مشخص کنید کدام بخش‌های کاربر passkeys همگام‌سازی شده در مقابل مقید به دستگاه دریافت می‌کنند. خط‌مشی تصدیق را پیش‌نویس کنید (با indirect شروع کنید). runbookهای بازیابی حساب را تعریف کنید. تأیید کنید خط‌مشی‌های دسترسی شرطی / MFA تطبیقی ثبت نام را مسدود نمی‌کنند.
3. ماه ۳-۵ — آزمایشی: به کارکنان IT و کاربران اولیه استقرار دهید. passkeys را به عنوان یک عامل اضافی اختیاری در کنار رمزهای عبور فعال کنید. نرخ موفقیت ثبت نام، تلاش‌های احراز هویت متقابل دستگاه و نرخ بازگشت را در لاگ‌های IdP خود اندازه‌گیری کنید.
4. ماه ۵-۱۰ — ثبت نام گسترده: کمپین‌های ثبت نام با لینک‌های ثبت نام خودخدمت ارسال کنید. هدف ۸۰٪ از نیروی کار ثبت نام شده. رمزهای عبور را به عنوان بازگشت فعال نگه دارید. حجم تیکت‌های پشتیبانی را نظارت کنید — تیکت‌های بازیابی حساب و passkey گمشده سیگنال شما هستند.
5. ماه ۱۰-۱۸ — حذف رمز عبور: برای کاربران ثبت نام شده، خط‌مشی‌های دسترسی شرطی را اعمال کنید که نیاز به passkey (FIDO2) به عنوان روش احراز هویت دارند. احراز هویت با رمز عبور را برای لایه‌های برنامه تحت پوشش غیرفعال کنید. یک فرآیند بازیابی break-glass با توکن‌های سخت‌افزاری برای حساب‌های مدیریتی حفظ کنید.

آنچه اکوسیستم هنوز کم دارد

Passkeys تمام نشده‌اند. چندین شکاف تا اواسط ۲۰۲۵ باقی مانده است:

• بدون استاندارد roaming 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 را برای اعتبارنامه‌های ثبت شده موجود مدیریت نمی‌کنند. شما به منطق سفارشی یا تعهد فروشنده نیاز دارید.
• عقب‌ماندگی فایرفاکس: پشتیبانی passkey فایرفاکس (v122+) هنوز لبه‌های ناهموار UX برای شرطی‌سازی میانجی و جریان‌های متقابل دستگاه دارد و سهم بازار آن در محیط‌های سازمانی — به ویژه خدمات دولتی و مالی — قابل توجه است.

پذیرش passkey سازمانی از مرحله اولیه عبور کرده است — مایکروسافت، گوگل و Okta همه ویژگی‌های GA را عرضه می‌کنند. تیم‌هایی که موفق می‌شوند آنهایی هستند که آن را به عنوان یک مهاجرت زیرساختی درمان می‌کنند، نه یک به‌روزرسانی برنامه: اول حسابرسی، آزمایشی بی‌امان، و بازگشت‌ها را بیشتر از آنچه راحت است زنده نگه دارند. مقاومت در برابر فیشینگ در انتهای دیگر ارزش هزینه عملیاتی را دارد.