آنچه باید بدانید
- ایمیل، ثبتکنندهٔ دامنه، هاست و حسابهای مدیریتی را در اولویت بگذارید.
- پیش از اجباریکردن روش ورود، بازیابی و تغییر اعضای تیم را طراحی کنید.
- پشتیبانی واقعی هر سرویس از passkey و کلید امنیتی را بررسی کنید.
از حسابهای دارای قدرت بازیابی شروع کنید
پیش از انتخاب ابزار، نقشهٔ دسترسی بسازید. ایمیل کاری، ثبتکنندهٔ دامنه، مدیریت هاست و سامانهٔ هویت میتوانند روی حسابهای دیگر اثر بگذارند. برای هر سرویس مسئول مشخص کنید و حسابهای مشترکی را که تحویلگیری شفافی ندارند شناسایی کنید.
سؤال فقط فعال بودن عامل دوم نیست؛ باید بدانید چه کسی آن را کنترل میکند، جایگزینی چگونه تأیید میشود و هنگام خروج کارمند چه اتفاقی میافتد.
Passkey چه تفاوتی ایجاد میکند؟
Passkey از اعتبارنامهٔ کلید عمومی استفاده میکند و به وبسایت یا برنامهٔ مورد نظر وابسته است. دستگاه سازگار میتواند با قفل صفحه، مانند PIN یا بررسی زیستی، ورود را تأیید کند. معرفی passkey در گوگل سازوکار مقاومت در برابر فیشینگ را توضیح میدهد. این حفاظت مربوط به مرحلهٔ احراز هویت است و دستگاه آلوده یا برنامهٔ ناامن را بیخطر نمیکند.
کد یکبارمصرف حفاظت متفاوتی است
کد برنامهٔ احراز هویت میتواند نسبت به رمز تنها پیشرفت خوبی باشد، اما کاربر همچنان ممکن است کد را در صفحهٔ فیشینگ وارد کند. روشهای MFA ریسک و نیاز بازیابی متفاوتی دارند. راهنمای MFA در OWASP این ملاحظات و اهمیت بازنشانی امن را توضیح میدهد.
فرض نکنید همهٔ سرویسها قابلیتهای یکسان passkey یا کلید امنیتی را دارند. مستندات ارائهدهنده و امکانات نوع حساب خود را بررسی کنید.
پیش از فعالسازی، بازیابی را طراحی کنید
برای مدیریت حساس، مسیر بازیابی مورد تأیید و در صورت پشتیبانی سرویس، مدیر دوم مجاز داشته باشید. اطلاعات بازیابی را جدا از دستگاه اصلی در محل محافظتشده نگه دارید. اگر تنها کلید و کد بازیابی در یک کیف باشند، گمشدن کیف هر دو را از دسترس خارج میکند.
شرایط احراز هویت برای بازنشانی عامل دوم را مکتوب کنید. این مرحله به اندازهٔ ثبت اولیه مهم است؛ بازنشانی ضعیف میتواند حفاظت ورود را کماثر کند.
با یک آزمایش کوچک شروع کنید
- یک حساب آزمایشی کمخطر و دو دستگاه نماینده انتخاب کنید.
- ثبت عامل، ورود و مسیر جایگزین مجاز را امتحان کنید.
- تعویض دستگاه و خروج یک عضو تیم را بررسی کنید.
- راهنمای کارکنان و مسئول انتشار را مشخص کنید.
- عاملهای ثبتشده و دسترسی بازیابی را دورهای بازبینی کنید.
برای توسعهدهندهٔ وب، ثبت و تأیید اعتبارنامه باید با پیادهسازی مورد پشتیبانی WebAuthn انجام شود. راهنمای ثبت passkey یک شروع فنی است؛ طراحی پروتکل اختصاصی ورود مسیر مناسبی نیست.
نگهداری مرورگر و حساب را کنار هم ببینید
کنترل هویت در کنار مرورگر بهروز، مجوز مناسب و فرایند بازیابی کار میکند. چکلیست نگهداری Chrome ارتباط مسئول دستگاه و امنیت حساب را روشنتر میکند.
برای بررسی دسترسی دفتر با خدمات فناوری اطلاعات کیاوا گفتگو کنید. برای پنل مشتری، نیاز ورود را در پروژهٔ برنامهنویسی وب مشخص کنید. امکانات واقعی باید در دامنهٔ پروژه تأیید شوند؛ این راهنما به معنی وجود passkey در تمام سرویسهای کیاوا یا شرکتهای دیگر نیست.
منابع و مطالعهٔ بیشتر
گزارش این مطلب بر پایهٔ منابع اصلی زیر است. توصیههای اجرایی، راهنمای عمومی کیاوا هستند و باید با شرایط پروژه تطبیق داده شوند.
