بررسی فنی انطباق کلیدهای عبور(PassKeys) با استاندارد ISO/IEC 27001 در امنیت سایبری - XNET | اخبار مقالات امنیت سایبری
احراز هویت بدون رمز عبور (Passwordless) یعنی بهجای اینکه کاربر هر بار پسورد تایپ کند، با «چیزی که دارد» (گوشی، توکن، کلید سختافزاری) و/یا «چیزی که هست» (بیومتریک) هویت خودش را ثابت میکند. دلیل استقبال هم مشخص است: فیشینگ، Credential Theft و Brute Force هنوز…
خلاصه تحلیلی خبر
احراز هویت بدون رمز عبور (Passwordless) یعنی بهجای اینکه کاربر هر بار پسورد تایپ کند، با «چیزی که دارد» (گوشی، توکن، کلید سختافزاری) و/یا «چیزی که هست» (بیومتریک) هویت خودش را ثابت میکند. دلیل استقبال هم مشخص است: فیشینگ، Credential Theft و Brute Force هنوز…
موضوعات اصلی: پشتیبانی شبکه، امنیت سایبری، Passkey، باید، پسورد، 27001
احراز هویت بدون رمز عبور (Passwordless) یعنی بهجای اینکه کاربر هر بار پسورد تایپ کند، با «چیزی که دارد» (گوشی، توکن، کلید سختافزاری) و/یا «چیزی که هست» (بیومتریک) هویت خودش را ثابت میکند. دلیل استقبال هم مشخص است: فیشینگ، Credential Theft و Brute Force هنوز تو اکثر سازمانها به وفور اتفاق میافتد و مدل «پسورد + سیاست پیچیدگی» عملاً بهتنهایی جواب نمیدهد.
از آن طرف، اگر سازمان دنبال انطباق با ISO/IEC 27001 است، نمیتواند صرفاً بگوید «پسورد رو حذف کردیم، پس امن شدیم». 27001 ریسکمحوره؛ یعنی باید نشان بدهید این تغییر در کنترل دسترسی، ریسکها را کم کرده، کنترلهای جبرانی دارد، و همهچیز قابل ممیزی و مستندسازی است. Passkey و FIDO2 اگر درست پیادهسازی شوند، معمولاً هم از نظر امنیتی بهترند، هم از نظر ممیزی دستتان را پرتر میکنند؛ ولی «درست پیادهسازی شدن» کل ماجراست.
Passkey دقیقاً چی هست و چرا با FIDO2 فرق میکند؟
Passkey در عمل پیادهسازی کاربرپسندِ FIDO2/WebAuthn است. هسته ماجرا این است
روی دستگاه کاربر یکجفت کلید عمومی/خصوصیساخته میشود.
کلید خصوصیاز دستگاه بیرون نمیآید (Secure Enclave/TPM/Authenticator).
سرور فقطکلید عمومیرا نگه میدارد و در زمان لاگین، امضای Challenge را چک میکند.
نتیجه مستقیم: دیتابیس پسورد ندارید که لو برود، Credential Stuffing بیمعنا میشود، و فیشینگ کلاسیک خیلی سختتر جواب میدهد (چون امضا به Origin/سایت مقصد گره خورده).
تحلیل امنیتی: کجاها Passkey قویتر است و کجاها باید حواسجمع بود؟
مزیتهای امنیتی نسبت به پسورد
مقاومت بالا در برابر فیشینگپسوردی وجود ندارد که کاربر تو صفحه تقلبی وارد کند.
حذف Credential Stuffingچیزی برای تستکردن از لیست لو رفتهها ندارید.
کاهش ریسک نشت Credential Storeسرور پسورد ذخیره نمیکند.
مقاومت در برابر Replayلاگین مبتنی بر Challenge/Response است.
ریسکهای واقعی (که اگر جدی نگیرید تبدیل به باگ امنیتی میشوند)
گمشدن/سرقت دستگاهاگر سیاست قفل صفحه/بیومتریک/MDM ضعیف باشد، این میشود نقطه نفوذ.
Enrollment اشتباهاگر ثبت دستگاه جدید با فرآیند شل انجام شود (مهندسی اجتماعی، سیمسواپ، Helpdesk ضعیف)، کل مدل میریزد به هم.
پیادهسازی ناقص کلاینت/سروراشتباه در Origin Validation، مدیریت Session یا لاگگیری، دقیقاً همانجایی است که ممیز و مهاجم هر دو گیر میدهند.
انطباق با ISO/IEC 27001: ممیزی دنبال چی میگردد؟
ISO 27001 از شما «Passkey» نمیخواهد؛ از شماکنترل، ریسک، شواهد ممیزی و فرآیندمیخواهد. اگر Passwordless میآورید وسط، باید بتوانید ثابت کنید کنترلهای دسترسیتان حداقل همسطح گذشته است و جاهایی هم بهتر شده.
مستندسازی فرآیند Enrollment (ثبت Passkey)
برای ممیزی، Enrollment باید دقیق و قابل دفاع باشد. حداقل اینها را شفاف کنید
روش ایجاد کلید و اینکهکلید خصوصی کجا نگهداری میشود
اینکه چه کسی/چه سیستمی مجاز است Passkey جدید ثبت کند
سیاستهایتأیید هویت اولیه(Initial Identity Proofing)
لاگهای امنیتی: چه چیزی لاگ میشود، کجا میرود، چقدر نگه میدارید، و چه کسی میبیند
نکته عملی: اگر Helpdesk بتواند با یک تماس و چند سؤال ساده Passkey جدید ثبت کند، عملاً یک مسیر دور زدن کنترل ساختهاید.
تأیید هویت قبل از صدور Passkey
قبل از اینکه Passkey صادر/ثبت شود، سطح اطمینان (Assurance) باید متناسب با ریسک دسترسی باشد. سناریوهای رایج
MFA اولیه (برای اولین ورود/ثبت)
تأیید حضوری یا با مدرک معتبر (برای نقشهای حساس)
اتصال به فرآیندهای HR/IT (Joiner-Mover-Leaver) برای سازمانها
این بخش همان جایی است که اگر سهلگیری کنید، Passwordless فقط ظاهر شیک دارد ولی امنیتش روی هواست.
سناریوی از دست رفتن دستگاه و بازیابی حساب (Recovery)
ISO 27001 روی تداوم و کنترل عملیاتی حساس است. پس باید Recovery را مثل یک مسیر حمله ببینید، نه فقط یک خدمت پشتیبانی.
فرآیند بازیابی امن حساب (با سطح اطمینان مشخص)
سیاست غیرفعالسازی Passkeyهای قدیمی
Fallback کنترلشده (مثلاً کدهای بازیابی، توکن ثانویه، یا روشهای تأیید قوی)
قاعده طلاییFallback ضعیف، یعنی باگ امنیتی تضمینی.
اجزای فنی: بیومتریک، TPM/Secure Enclave و توکنهای سختافزاری
بیومتریک در مدل استاندارد FIDO2
بیومتریک در FIDO2 معمولاً نقش «باز کردن قفل کلید خصوصی» را دارد، نه اینکه خودِ بیومتریک به سرور ارسال شود. برای انطباق و حریم خصوصی مهم است که
داده بیومتریک روی سرور ذخیره نشود
کلیدها داخل Secure Enclave/TPM یا Authenticator امن نگهداری شوند
YubiKey و مشابهها (Authenticator سختافزاری)
توکنهایی مثل YubiKey برای سناریوهای ادمین و دسترسیهای حساس عالیاند، چون
کلید خصوصی را در محیط مقاوم نگه میدارند
نسبت به بدافزارهای EndPoint معمولاً مقاومترند
مدیریت چرخه عمرشان (صدور/تعویض/ابطال) قابل فرآیندسازی است
فلو لاگین با Challenge/Response
مکانیزم کلی لاگین
1. سرور یک Challenge میدهد
2. Authenticator با کلید خصوصی آن را امضا میکند
3. سرور با کلید عمومی اعتبارسنجی میکند
اینجا خبری از «راز مشترک» مثل پسورد نیست؛ همین موضوع سطح حمله را کم میکند.
کاهش ریسک: کنترلهای عملیاتی که باید واقعاً اجرا شوند
ارزیابی ریسک رسمی و دورهای
اگر سازمان ادعای 27001 دارد، باید بتواند نشان بدهد
Threat Scenarioها مشخص شدهاند
احتمال/اثر تحلیل شده
کنترلها و Ownerها تعیین شدهاند
بازبینی دورهای انجام میشود
Passwordless را هم مثل هر تغییر امنیتی دیگر، باید وارد Risk Register کنید.
آیا MFA هنوز لازم است؟
برای خیلی از سناریوها Passkey بهاندازه کافی قوی است، ولی برای نقشهای حساس (ادمین، مالی، دسترسی خارج از کشور/شبکه، سیستمهای حیاتی) معمولاً منطقی است
MFA تکمیلی
سیاستهای Context-Aware (موقعیت، دستگاه Managed/Unmanaged، ریسکاسکور)
چالش Legacy و مسیر مهاجرت
واقعیت سازمانی: خیلی از سیستمهای قدیمی
WebAuthn را نمیفهمند
API درستوحسابی ندارند
به AD و روشهای سنتی Login قفلاند
راه حل معمولاً مهاجرت فازبندیشده است
Identity Proxy / Gateway برای پل زدن
Hybrid مدل (تا وقتی Legacyها جمع شوند)
محدودسازی دسترسی Legacy با شبکه/Jump Host/Privileged Access
ملاحظات اجرایی در سازمانهای ایرانی
تو ایران چندتا عامل کار را سختتر میکند
محدودیت دسترسی به بعضی سرویسهای ابری و وابستگی به On-Prem
ناهمگونی Endpointها و نبود MDM استاندارد در بعضی جاها
ضعف فرآیندهای رسمی IAM و Joiner-Mover-Leaver
با این حال، اگر هدف شما گرفتن/تمدید ISO/IEC 27001 است، Passwordless (بهخصوص با Passkey/FIDO2) وقتی با Enrollment و Recovery درست همراه شود، هم از نظر فنی سطح بلوغ را بالا میبرد، هم در ممیزی شواهد بهتری میدهد (لاگ، سیاست، کنترل، سنجه).
جمعبندی
Passkey/FIDO2 از نظر معماری معمولاً از پسورد سنتی امنتر است: دیتابیس پسورد حذف میشود، فیشینگ و Credential Stuffing سخت میشوند، و کنترل دسترسی قابل دفاعتر میشود. اما برای همراستایی واقعی با ISO/IEC 27001 باید اینها را جدی بگیرید
ارزیابی رسمی ریسک و ثبت در چرخه ISMS
مستندسازی کامل Enrollment/Recovery و سختگیری روی Helpdesk
لاگگیری، مانیتورینگ و سیاستهای ابطال/تعویض کلیدها
برنامه مهاجرت برای Legacy و تعریف Fallback امن
Passwordless اگر «فرآیند» نداشته باشد، فقط ظاهر مدرن است؛ اگر فرآیند داشته باشد، هم امنیت را بالا میبرد، هم ممیزی را راحتتر میکند.
برای ارزیابی پایداری، امنیت و نگهداری این زیرساخت، راهنمای پشتیبانی شبکه را نیز مطالعه کنید.