امنیت

Passkey آماده ورود عمومی است؛ آزمون واقعی، بازیابی حساب است

ورود بدون رمز از تیم امنیت به زندگی عادی کاربران رسیده، اما سؤال سخت محصول این است: اگر گوشی گم شود، حساب خانوادگی مشترک باشد یا دستگاه کاری عوض شود چه اتفاقی می‌افتد؟

سینا فرزان
سینا فرزان

نویسنده امنیت و کسب‌وکار دیجیتال

۱۱ تیر ۱۴۰۵5 دقیقه مطالعه
Passkey آماده ورود عمومی است؛ آزمون واقعی، بازیابی حساب است

چرا الان مهم است

ورود passkey به امنیت عمومی حساب‌ها دیگر موضوعی مخصوص چند متخصص نیست؛ به یک سؤال عملیاتی برای مدیریت محصول و کسب‌وکار تبدیل شده است. FIDO Alliance و پلتفرم‌های بزرگ passkey را به‌عنوان جایگزینی مقاوم‌تر در برابر phishing جلو می‌برند، اما اجرای عمومی به بازیابی، دستگاه مشترک و طراحی پشتیبانی وابسته است. معنی‌اش این نیست که همه باید وحشت کنند، اما یعنی فرض قدیمی که «زیرساخت خودش درست می‌شود» دیگر کافی نیست.

اهمیت ماجرا از اینجاست که تیم امنیت از مقاومت در برابر phishing خوشحال است، اما کاربر وقتی گوشی عوض می‌کند یا نمی‌داند کلیدش کجا ذخیره شده، ممکن است قفل شود. تیم‌های محصول معمولاً این را دیر می‌فهمند. جلسه لانچ درباره فیچر، قیمت و رشد حرف می‌زند، اما محدودیت واقعی ممکن است در permission، بازیابی حساب، برق، certificate، vendor یا پشتیبانی پنهان باشد.

برای مدیران محصول، تیم‌های امنیت، پشتیبانی مشتری و طراحان تجربه ورود تغییر اصلی ساده است: تصمیم فنی حالا تبدیل به وعده قابل لمس به کاربر می‌شود. ورود امن یعنی بازیابی قابل فهم. عامل AI یعنی اختیار محدود. دیتاسنتر یعنی برق و سرمایش قابل اتکا. رمزنگاری یعنی محرمانگی امروز و فردا.

برای کاربر فارسی‌زبان، چالش فقط تکنولوژی نیست؛ بسیاری از سرویس‌ها روی شماره، ایمیل، دستگاه قدیمی یا پشتیبانی کند تکیه دارند و همین بازیابی را حساس‌تر می‌کند. به همین دلیل این موضوع فقط یک خبر تکنولوژی نیست. روی بودجه، زمان تحویل، متن پشتیبانی، قرارداد خرید و نحوه توضیح ریسک به مشتری اثر می‌گذارد.

مقاله‌های مرتبط

دیتاسنترهای هوش مصنوعی به گلوگاه تازه رسیده‌اند: برق، خنک‌سازی و اعتماد محلی

واقعیت محصول پشت تیتر خبر

اولین واقعیت این است که تکنولوژی انتزاعی فقط وقتی دردناک می‌شود که به workflow واقعی برسد. تا وقتی همه‌چیز کار می‌کند کسی سراغ معماری نمی‌رود. مشکل وقتی شروع می‌شود که حساب برنگردد، مدل scale نشود، agent کار اشتباه انجام دهد یا vendor جواب امنیتی روشن نداشته باشد.

واقعیت دوم وابستگی است. محصول دیجیتال امروز روی regionهای cloud، provider هویت، مدل AI، مرورگر، API، certificate، موبایل و تیم پشتیبانی سوار است. یک فیچر ساده روی صفحه ممکن است زنجیره‌ای پیچیده زیر خود داشته باشد.

واقعیت سوم اعتماد است. کاربر محدودیت روشن را راحت‌تر از شکست مبهم می‌پذیرد. اگر محصول بگوید چه چیزی مجاز است، چه چیزی مسدود می‌شود، بازیابی چطور انجام می‌شود و مسئول کیست، حس طراحی‌شده بودن می‌دهد. اگر این جواب‌ها بعد از incident پیدا شوند، محصول بداهه به نظر می‌رسد.

برای همین باید ثبت passkey، fallback، بازیابی، انتقال دستگاه و آموزش کاربر باید یک مسیر واحد باشند، نه چند صفحه تنظیمات جدا. این کاغذبازی نیست؛ راه تبدیل ابهام به مدل عملیاتی قابل مدیریت است.

شکست‌هایی که آرام شروع می‌شوند

شکست‌های خطرناک معمولاً با بحران بزرگ شروع نمی‌شوند. با استثنا شروع می‌شوند: حساب ویژه، راه‌حل موقت vendor، تغییر دستگاه، محدودیت ظرفیت region، permissionی که در تست داده شد و بعد کسی آن را پس نگرفت.

حالت دوم، کوری متریک است. تیم ممکن است adoption را اندازه بگیرد اما recoverability، فشار پشتیبانی، مصرف انرژی، عمل برگشت‌ناپذیر، drift امنیتی یا آمادگی vendor را نبیند. متریک کاربردی اینجاست: نرخ بازیابی امن و موفق بدون تماس با پشتیبانی.

حالت سوم زبان سازمانی است. اگر مدیران سیستم را ساده توصیف کنند ولی اپراتورها بدانند شکننده است، سازمان شروع می‌کند به فریب دادن خودش. زبان خوب باید عدم قطعیت را نام‌گذاری کند بدون اینکه تیم را فلج کند.

حالت چهارم اعتمادبه‌نفس بیش از حد است. دمو اول که کار کرد، سیستم آماده نیست. آمادگی واقعی یعنی سیستم بتواند degrade شود، توضیح بدهد، اعتماد کاربر را حفظ کند و وقتی فرض‌ها شکستند، قابل بازیابی باشد.

برنامه عملی ۹۰ روزه

در ۳۰ روز اول سطح تماس را نقشه‌برداری کنید. بنویسید موضوع کجا به کاربر، ابزار داخلی، داده، vendor، زیرساخت، پشتیبانی و compliance وصل می‌شود. هدف اسلاید زیبا نیست؛ هدف inventory مشترکی است که حتی آدم‌های نگران هم بگویند دقیق است.

از روز ۳۱ تا ۶۰ control point تعریف کنید. کدام تغییر review می‌خواهد؟ کدام مسیر کاربر fallback لازم دارد؟ کدام vendor باید جواب مکتوب بدهد؟ چه اتفاقی rollback را فعال می‌کند؟ چه logی قبل از لانچ باید وجود داشته باشد؟

از روز ۶۱ تا ۹۰ failure rehearsal اجرا کنید. گم شدن دستگاه، مسدود شدن region، tool injection، تاخیر vendor، وابستگی certificate یا کمبود ظرفیت را شبیه‌سازی کنید. هدف ترساندن تیم نیست؛ هدف ساختن حافظه عملیاتی است.

در پایان این چرخه، سازمان باید بداند مالک چیست، به چه چیزی وابسته است، چه چیزی را می‌تواند برگرداند و چه چیزی را باید برای کاربر توضیح دهد. همین شفافیت یک trend بزرگ را به roadmap قابل اجرا تبدیل می‌کند.

مزیت پایدار از کجا می‌آید

مزیت پایدار معمولاً شبیه پرصداترین لانچ نیست. شبیه تیمی است که می‌تواند منتشر کند، ببیند، توضیح بدهد، بازیابی کند و بهتر شود بدون اینکه همه اطراف محصول را فرسوده کند.

مشتری‌ها بیشتر از قبل evidence می‌خرند، نه فقط قابلیت. می‌خواهند بدانند تصمیم‌ها چطور log می‌شوند، vendor چطور ارزیابی شده، بازیابی چطور کار می‌کند، هزینه چطور کنترل می‌شود و شرکت وقتی سیستم به مرز می‌رسد چه رفتاری دارد.

سؤال مدیریتی ساده است: اگر فرض اصلی تغییر کند، شرکت هنوز می‌تواند وعده‌اش را نگه دارد؟ اگر جواب وابسته به قهرمانی پنهان چند نفر است، سیستم بالغ نیست. اگر وابسته به کنترل‌های مستند است، محصول در حال تبدیل شدن به زیرساخت واقعی است.

آینده بدون رمز فقط با رمزنگاری زیبا پیروز نمی‌شود؛ با مسیری پیروز می‌شود که کاربر در روز بد هم از آن سالم عبور کند.

خبر خوب، خبری است که کاربر بعد از خواندن آن تصمیم بهتری بگیرد.
NovaNews
Passkeyهویت دیجیتالورود بدون رمزphishingبازیابی حساب

درباره نویسنده

سینا فرزان

سینا فرزان

نویسنده امنیت و کسب‌وکار دیجیتال

سینا روی امنیت سایبری، بلاک‌چین، اعتماد دیجیتال و کاربرد فناوری در کسب‌وکارهای کوچک تمرکز دارد.

مقاله‌های مرتبط