تکنولوژی
وقتی می‌توان از رمز عبور صرف‌نظر کرد، چرا باید از آن محافظت کنیم؟
چطور مدل همیشگی دسترسی مدیریتی را از نو بررسی کردم و چرا تصمیم گرفتم تجربه‌ام را به اشتراک بگذارم
مشکلی که به عادی‌بودنش عادت کرده‌ایم
تقریباً هر برنامهٔ وبی یک پنل مدیریت دارد. پنل مدیریت هم معمولاً نشانی ورود، فرم احراز هویت، نام کاربری و رمز عبور دارد.
آن‌قدر به این ساختار عادت کرده‌ایم که تقریباً دیگر از خودمان نمی‌پرسیم: آیا واقعاً همه‌چیز باید همین‌طور کار کند؟
وقتی فقط یک وب‌سایت دارید، مشکل چندان مهم به نظر نمی‌رسد. یک رمز عبور پیچیده می‌سازید، احراز هویت دومرحله‌ای را فعال می‌کنید، تعداد تلاش‌های ورود را محدود می‌کنید و به کارتان ادامه می‌دهید.
اما وقتی تعداد پروژه‌ها به ده، بیست یا سی تا می‌رسد چه اتفاقی می‌افتد؟
در مورد من، موضوع اکوسیستم DigiMeld است که بیش از سی پروژهٔ نرم‌افزاری مستقل را دربرمی‌گیرد. هرکدام معماری، منطق سمت سرور و رابط مدیریتی خودش را دارد.
بنابراین، هرکدام به سازوکاری برای دسترسی مدیریتی نیاز دارند.
مدت‌ها از روشی کاملاً متداول استفاده می‌کردم: اطلاعات ورود مدیریتی جداگانه، رمزهای عبور پیچیده و ذخیره‌کردن آن‌ها در مرورگر.
این روش جواب می‌داد.
اما در مقطعی از خودم پرسیدم: اصلاً چرا باید این‌همه رمز عبور مدیریتی را نگه دارم؟ چرا باید نه‌تنها از سرورها، بلکه از ابزارهای دسترسی به آن‌ها هم محافظت کنم؟
آیا نمی‌توان از این ضرورت صرف‌نظر کرد؟
به این فکر رسیدم که بعدها پایهٔ راه‌حل من شد:
شاید به‌جای محافظت از یک نقطهٔ ورود دائمی، باید از حق دریافت موقت دسترسی محافظت کنیم.
رمز عبور پیچیده، خودِ مشکل را برطرف نمی‌کند
ابزارهای امروزی امکان ساخت رمزهای عبور با آنتروپی بسیار بالا را فراهم می‌کنند. حدس‌زدن یک رمز عبور تصادفیِ طولانی که به‌درستی تولید شده باشد، با جست‌وجوی فراگیر تقریباً ناممکن است.
اما هرقدر هم رمز عبور پیچیده باشد، باید جایی نگه‌داری و سپس استفاده شود.
می‌توان از مدیران رمز عبور، کلیدهای سخت‌افزاری، احراز هویت چندعاملی و محدودیت‌های بیشتر استفاده کرد. همهٔ این‌ها واقعاً امنیت را افزایش می‌دهند.
بااین‌حال، ساختار معماری همچنان پابرجاست: رابط مشخصی وجود دارد که کاربر از طریق آن اطلاعات ورودش را ارائه می‌کند.
می‌توان به آن درخواست فرستاد. می‌توان آن را اسکن کرد. ممکن است هدف حملات خودکار قرار بگیرد.
می‌توان نشانی پنل مدیریت را پنهان کرد، مسیر پیش‌فرض را با رشته‌ای تصادفی و طولانی جایگزین کرد یا دسترسی را به IPهای مشخص محدود کرد.
اما آن‌وقت پرسش تازه‌ای پیش می‌آید: این نشانی را کجا نگه داریم و چطور از آن استفاده کنیم؟
و از همه مهم‌تر، اگر فقط در زمان‌های مشخصی به دسترسی مدیریتی نیاز داریم، چرا باید یک نقطهٔ ورود دائمی را حفظ کنیم؟
به این نتیجه رسیدم که:
شاید به‌جای محافظت از یک نقطهٔ ورود دائمی، باید حق دریافت موقت دسترسی را ایمن کنیم.
اگر اصلاً صفحهٔ ورود همیشگی وجود نداشته باشد چه؟
تصمیم گرفتم در پروژه‌هایم از مدل سنتی احراز هویت مدیریتی صرف‌نظر کنم.
نه اینکه فقط فرم ورود را پنهان کنم.
نه اینکه نشانی را تغییر بدهم.
نه اینکه رمز عبور را با رمزی پیچیده‌تر جایگزین کنم.
بلکه نیاز به وجود دائمیِ نقطهٔ ورود با رمز عبور را از میان بردارم.
البته رابط‌های مدیریتی از بین نرفته‌اند. آن‌ها همچنان برای مدیریت برنامه‌ها ضروری‌اند.
آنچه تغییر کرده، روش دسترسی به آن‌هاست.
حالا برای ورود به پنل‌های مدیریتی پروژه‌های متصل، نیازی به واردکردن نام کاربری و رمز عبور ذخیره‌شده نیست.
در عوض، از سامانهٔ خودم برای شناسایی و مدیریت دسترسی، یعنی MeldID، استفاده می‌کنم.
ایده ساده است: دسترسی مدیریتی فقط زمانی ارائه می‌شود که واقعاً لازم باشد، آن هم به کاربر مشخص و برای پروژه‌ای مشخص.
صرفِ داشتن حساب کاربری به‌معنای حق بازکردن پنل مدیریت نیست.
این حق باید جداگانه اعطا شود.
دسترسی‌ای که یک دقیقه پیش وجود نداشت
به‌گمانم این جالب‌ترین بخش کل این ایده است.
در مدل سنتی، مدیر همیشه ابزارهای ورود را در اختیار دارد. تا وقتی این اطلاعات معتبر باشند، می‌تواند امروز، فردا یا یک ماه دیگر از آن‌ها استفاده کند.
تصمیم گرفتم این اصل را تغییر بدهم.
به‌جای اطلاعات ورود مدیریتی دائمی، امکان موقتی برای آغاز فرایند ورود در نظر گرفته شده است.
این امکان با درخواست کاربر و از طریق یک دستگاه همراهِ مورداعتماد ایجاد می‌شود، مؤلفه‌ای تصادفی و از نظر رمزنگاری امن دارد و برای مدت محدودی معتبر است.
اما حتی داشتن این پیوند موقت هم به‌تنهایی به‌معنای دسترسی نیست.
این نکته‌ای اساسی است.
فرض کنید کسی به هر طریقی پیوند را به دست آورده است. در یک سامانهٔ معمولی که امنیتش فقط به مخفی‌ماندن نشانی وابسته است، چنین افشایی می‌تواند مشکل جدی‌ای ایجاد کند.
در مدل من، پیوند فقط امکان آغاز فرایند تأیید را فراهم می‌کند.
برای ادامه، باید از طریق دستگاه همراهِ مورداعتمادِ MeldID مجوز جداگانه‌ای تأیید شود.
بدون تأیید لازم، نشست مدیریتی ایجاد نمی‌شود.
به همین دلیل، پیوند موقت را جایگزین رمز عبور نمی‌دانم؛ آن را یکی از اجزای فرایند اعطای دسترسی می‌دانم.
دانستن اینکه کجا باید مراجعه کرد با داشتن حق ورود، دو چیز کاملاً متفاوت‌اند.
تلفن به ابزاری برای مدیریت دسترسی تبدیل می‌شود
در این مدل، دستگاه همراه نقشی بسیار مهم‌تر از یک تولیدکنندهٔ معمولی کدهای یک‌بارمصرف دارد.
از آن برای تأیید اقدام‌های مرتبط با دسترسی مدیریتی استفاده می‌شود.
وقتی می‌خواهم پنل مدیریت را باز کنم، سامانه از طریق MeldID درخواست تأیید می‌فرستد.
درخواست مربوطه را روی دستگاه مورداعتمادم می‌بینم و آن را تأیید می‌کنم.
سامانه فقط پس از تأیید موفق اجازه می‌دهد فرایند ورود ادامه پیدا کند.
این تأیید به یک اقدام مشخص مربوط است، نه صرفاً به بازشدن قفل تلفن.
زیست‌سنجی دستگاه همراه، کاربر را به‌صورت محلی بررسی می‌کند و بخش سمت سرور نیز تأیید رمزنگاری‌شدهٔ دستگاه ثبت‌شده را اعتبارسنجی می‌کند.
این رویکرد کمک می‌کند فقط به رمز عبور یا پیامی مبنی بر اینکه گویا کاربر ورود را تأیید کرده است، متکی نباشیم.
مزیت دیگری هم دارد: می‌توان دستگاه‌های مورداعتماد را مدیریت کرد.
اگر دیگر نباید از دستگاهی برای تأیید دسترسی استفاده شود، می‌توان وضعیت مورداعتماد آن را لغو کرد.
پس از آن، این دستگاه دیگر ابزار معتبر احراز هویت برای عملیات مربوطه نخواهد بود.
یک سامانه، چندین پروژهٔ مستقل
وقتی توسعهٔ این سازوکار را شروع کردم، یکی از مهم‌ترین هدف‌هایم این بود که استقلال هر پروژه حفظ شود.
نمی‌خواستم همهٔ پنل‌های مدیریتی را در یک برنامهٔ عظیم ادغام کنم.
هر سرویس DigiMeld باید همچنان منطق، تنظیمات، کاربران و داده‌های خودش را مدیریت کند.
به همین دلیل، این دو وظیفه را از هم جدا کردم.
MeldID مسئول شناسایی و اعطای مجوز مدیریتی است.
خود پروژه هم مسئول قابلیت‌های مدیریتی خاص خودش و بررسی اعتبار مجوزهای فعال است.
به این ترتیب، مدلی متمرکز برای مدیریت دسترسی شکل گرفت، بی‌آنکه لازم باشد خود برنامه‌ها را متمرکز کنیم.
علاوه بر این، مجوزها جداگانه اعطا می‌شوند.
مدیر یک پروژه صرفاً به این دلیل که حساب MeldID دارد، به‌طور خودکار به پروژه‌های دیگر دسترسی پیدا نمی‌کند.
برای هر بخش مدیریتی می‌توان گروه جداگانه‌ای از کاربران مجاز تعریف کرد.
در عین حال، دسترسی کاربران عادی و اختیارات مدیریتی از هم جدا هستند.
این روش برای اکوسیستمی با ده‌ها سرویس بسیار کاربردی از آب درآمد.
چرا دسترسی موقت را به دسترسی دائمی ترجیح می‌دهم
اصل دیگری هم هست که آگاهانه در سامانه گنجاندم.
دسترسی مدیریتی نباید تا ابد باقی بماند.
مجوز برای مدت محدودی اعتبار دارد و حتی اگر کاربر همچنان با مرورگر کار کند، اعتبار آن پایان می‌یابد.
برای ادامهٔ کار پس از پایان اعتبار، باید فرایند تأیید تازه‌ای انجام شود.
به این ترتیب، احراز هویت یک‌باره به حقی دائمی و همیشگی تبدیل نمی‌شود.
اما محدودکردن زمان به‌تنهایی کافی نیست.
امکان پایان‌دادن زودهنگام به دسترسی‌ای که قبلاً اعطا شده نیز اهمیت دارد.
به همین دلیل، MeldID امکان لغو متمرکز مجوزهای مدیریتی را فراهم می‌کند.
وقتی مجوزی لغو می‌شود، پروژه‌های متصل رویداد مربوطه را دریافت می‌کنند و نشست‌های مدیریتی مرتبط را باطل می‌کنند.
به این ترتیب، مدیریت دسترسی با ورود موفق کاربر به پایان نمی‌رسد.
از نظر من، امکان لغو اختیارات به‌اندازهٔ امکان اعطای آن‌ها اهمیت دارد.
در عین حال، یک سامانهٔ توزیع‌شده باید تأخیر در ارسال رویدادها، ازکارافتادن موقت برخی اجزا و شرایط عملیاتی دیگر را هم در نظر بگیرد. محدودبودن اعتبار نشست‌ها، مرز حفاظتی دیگری ایجاد می‌کند.
کار روزمره چه تغییری کرده است؟
پیش از هر چیز، دیگر نیازی نیست مدام سراغ رمزهای عبور مدیریتی ذخیره‌شده بروم.
لازم نیست مجموعه‌ای از اطلاعات ورود را در مرورگر نگه دارم تا بتوانم وارد تک‌تک پنل‌های مدیریتی متصل شوم.
در عوض، مجوزها را از طریق یک سازوکار واحد مدیریت می‌کنم.
پروژهٔ موردنیاز را انتخاب می‌کنم، دسترسی را تأیید می‌کنم و کارم را انجام می‌دهم.
وقتی دیگر به دسترسی مدیریتی نیاز ندارم، می‌توانم آن را لغو کنم.
نکتهٔ بسیار کاربردی این است که با اضافه‌شدن پروژه‌ای جدید، لازم نیست کل سامانهٔ احراز هویت مدیریتی را از نو طراحی کنم.
کافی است آن را به مدل موجود متصل کنم و مجوزهای لازم را تعیین کنم.
البته این به‌معنای ازبین‌رفتن همهٔ خطرهای امنیتی نیست.
مجوزهای موقت، دستگاه‌های مورداعتماد، نشست‌های سرور و زیرساخت مرکزی همگی به محافظت نیاز دارند.
اما دیگر لازم نیست مسئلهٔ مدیریت رمزهای عبور مدیریتی را برای هر برنامه جداگانه حل کنم.
و این یکی از هدف‌های اولیه‌ام بود.
مگر این فناوری‌ها از قبل وجود ندارند؟
چرا، وجود دارند.
احراز هویت بدون رمز عبور، مدیریت دسترسی‌های ممتاز، مجوزهای موقت و تأیید از طریق دستگاه‌های مورداعتماد، مدت‌هاست که در صنعت امنیت اطلاعات شناخته شده‌اند.
این رویکردها در سامانه‌های مدیریت هویت و دسترسی (Identity and Access Management)، مدیریت دسترسی ممتاز (Privileged Access Management) و چارچوب‌های اعتماد صفر (Zero Trust) دیده می‌شوند.
ادعا نمی‌کنم این اصول را من اختراع کرده‌ام.
هدفم چیز دیگری بود.
لازم داشتم سامانه‌ای یکپارچه و اختصاصی بسازم که مشکلات مشخص زیرساخت DigiMeld را حل کند و امکان مدیریت دسترسی مدیریتی به چندین پروژهٔ مستقل را فراهم آورد.
در نتیجه، چند رویکرد شناخته‌شده را در معماری واحدی متناسب با نیازهایم ترکیب کردم.
به‌نظر من، ارزش کار مهندسی لزوماً در اختراع فناوری‌ای کاملاً جدید نیست.
گاهی ارزش آن در این است که مسئله را به‌درستی صورت‌بندی کنیم و راه‌حل مناسبی برایش پیدا کنیم.
MeldID فقط برای پنل‌های مدیریتی نیست
در اینجا باید توضیح جداگانه‌ای بدهم.
MeldID فقط به‌عنوان ابزاری برای دسترسی مدیریتی خودم ساخته نشده است.
این سامانه همچنین SDKهایی در اختیار توسعه‌دهندگان می‌گذارد تا سازوکارهای شناسایی و تأیید ورود را در برنامه‌های خودشان ادغام کنند.
این SDK به‌صورت رایگان در دسترس است.
برای مثال، توسعه‌دهنده‌ای بیرون از مجموعه می‌تواند از MeldID به‌عنوان لایهٔ تکمیلی برای تأیید احراز هویت کاربران استفاده کند.
حتی اگر برنامه همچنان ورود سنتی با نام کاربری و رمز عبور را داشته باشد، واردکردن موفق این اطلاعات ممکن است برای تکمیل احراز هویت کافی نباشد.
درخواست تأییدی به دستگاه همراهِ مورداعتماد کاربر ارسال می‌شود و او تلاش برای ورود را تأیید یا رد می‌کند.
این کار در صورت افشای اطلاعات ورود، خطر دسترسی غیرمجاز را کاهش می‌دهد.
مهم است که این قابلیت عمومی MeldID را از مدلی که برای دسترسی مدیریتی به پروژه‌های DigiMeld طراحی کرده‌ام، متمایز بدانیم.
هر دو از اصول مشترک اعتماد و تأیید اقدام‌ها استفاده می‌کنند، اما مسائل متفاوتی را حل می‌کنند.
امنیت فقط محافظت از چیزهای موجود نیست
کار روی این سامانه باعث شد به سازوکارهای همیشگی احراز هویت از زاویه‌ای دیگر نگاه کنم.
ما اغلب می‌کوشیم از چیزهایی محافظت کنیم که به‌دلیل دلایل تاریخی وجود دارند.
بررسی‌های تازه، محدودیت‌ها، رمزهای عبور بیشتر و لایه‌های حفاظتی جدید اضافه می‌کنیم.
گاهی این کار واقعاً ضروری است.
اما گاهی بهتر است پرسش دیگری مطرح کنیم:
آیا سازوکاری که از آن محافظت می‌کنیم، حتماً باید به شکل قبلی وجود داشته باشد؟
در مورد من، پاسخ منفی بود.
به فرم ورود مدیریتیِ همیشه در دسترس نیاز نداشتم.
نیازم این بود که درست در همان زمانی که لازم است، بتوانم اختیارات مدیریتی را به‌شکلی امن دریافت کنم.
این‌ها دو مسئلهٔ متفاوت‌اند.
و گذار از اولی به دومی، نه‌فقط معماری فنی، بلکه کار روزمره با پروژه‌ها را هم تغییر داد.
نه پایان کار، بلکه مسیری که انتخاب کرده‌ام
امروز این معماری در بخش بزرگی از اکوسیستم DigiMeld فعال است.
پروژه‌های باقی‌مانده هم به‌تدریج به مدل تازهٔ دسترسی مدیریتی منتقل می‌شوند.
این مهاجرت را مرحله‌به‌مرحله انجام می‌دهم، عملکرد هر برنامه را بررسی می‌کنم و پس از پایان انتقال، قصد دارم ممیزی دیگری روی کل سامانه انجام دهم.
ممکن است برخی بخش‌های رابط کاربری و قواعد مدیریت نشست‌ها هنوز تغییر کنند.
اما ایدهٔ اصلی مشخص شده است.
نمی‌خواهم به مدلی برگردم که در آن برای مدیریت ده‌ها پروژهٔ خودم، مجبور باشم دائماً ده‌ها رمز عبور مدیریتی را نگه دارم و از آن‌ها استفاده کنم.
بااین‌حال، فکر نمی‌کنم پیاده‌سازی خودم راه‌حلی فراگیر برای همه باشد.
سازمان‌های مختلف نیازمندی‌ها، زیرساخت‌ها، مدل‌های تهدید و روش‌های مدیریتی متفاوتی دارند.
چیزی که برای اکوسیستم DigiMeld مناسب و موجه است، لزوماً برای توسعه‌دهنده‌ای دیگر بهینه نیست.
بااین‌حال، اصل اعطای موقت اختیارات ارزش توجه دارد.
به‌جای نتیجه‌گیری
تصمیم گرفتم این تجربه را به اشتراک بگذارم، نه چون خودم را مخترع روش تازه‌ای برای احراز هویت می‌دانم.
و نه چون می‌خواهم سامانه‌ای دیگر را کاملاً امن جلوه بدهم.
امنیت مطلق وجود ندارد.
صرفاً خودِ طرح این پرسش برایم جالب است.
به‌جای اینکه بی‌وقفه از یک نقطهٔ ورود مدیریتی دائمی محافظت کنیم، می‌توانیم ضرورت وجود آن را از نو بررسی کنیم.
به‌جای نگه‌داری تعداد زیادی رمز عبور، از مجوزهای موقت استفاده کنیم.
به‌جای اعتماد خودکار پس از نخستین احراز هویت، اعطای اختیارات مشخص را تأیید کنیم.
به‌جای اینکه منتظر پایان نشست بمانیم، امکان لغو متمرکز دسترسی را فراهم کنیم.
و در نهایت، به‌جای استفاده از سازوکار ورود جداگانه در هر پروژه، سامانه‌ای واحد برای مدیریت مجوزهای مدیریتی بسازیم و در عین حال استقلال برنامه‌ها را حفظ کنیم.
ادعا نمی‌کنم این رویکرد احتمال نفوذ را از بین می‌برد.
این رویکرد فقط تمرکز را از محافظت از اطلاعات ورود دائمی به سمت اعطای کنترل‌شده و پایان‌دادن به اختیارات منتقل می‌کند.
شاید گاهی مؤثرترین راه برای کوچک‌کردن سطح حمله این نباشد که سازوکار حفاظتی دیگری اضافه کنیم، بلکه از چیزی صرف‌نظر کنیم که سامانه می‌تواند بدون آن هم کار کند.
برای من، داستان MeldID Admin Gateway دقیقاً با همین فکر آغاز شد.