پلتفرم و معماری
اعتماد صفر در سازمانهای بزرگ: از شعار تا پیادهسازی مرحلهای
اعتماد صفر یک محصول نیست، یک اصل تصمیمگیری دربارهٔ هر درخواست دسترسی است. هویت، مجوزدهی در سطح درخواست و نقشهٔ راه مرحلهای برای سازمانی که نمیتواند…
«اعتماد صفر» در چند سال گذشته به برچسبی تبدیل شده که روی تقریباً هر محصول امنیتی میچسبد. سازمان محصول را میخرد، نصب میکند، و بعد متوجه میشود که چیزی در وضعیت واقعیاش عوض نشده: همچنان هر کسی که وارد شبکهٔ داخلی شود، به بخش بزرگی از منابع دسترسی دارد.
اعتماد صفر محصول نیست. یک اصل تصمیمگیری است: هیچ درخواستی بهدلیل محل شبکهای مبدأ آن قابل اعتماد نیست. هر درخواست باید بر اساس هویت درخواستکننده، وضعیت دستگاهش و حساسیت منبع، جداگانه ارزیابی شود. پیادهسازی این اصل، پروژهٔ چندسالهای است که از چند جبهه پیش میرود — و دقیقاً به همین دلیل باید مرحلهای باشد.
هویت، مرز جدید
در معماری قدیمی، مرز دفاعی لبهٔ شبکه بود: هر چه بیرون دیوار آتش، نامطمئن؛ هر چه داخل، مطمئن. این تقسیمبندی وقتی فرو ریخت که کاربر از خانه وصل شد، سرویس روی ابر رفت، و پیمانکار به یک سامانهٔ داخلی دسترسی گرفت.
جایگزین، هویت است. یعنی پیش از هر چیز باید یک منبع واحد هویت داشته باشید که بداند هر کارمند، پیمانکار و سرویس کیست و چه نقشی دارد. سازمانی که ده مخزن کاربر جداگانه دارد — یکی در دایرکتوری، یکی در سامانهٔ مالی، یکی در پورتال سرویس — نمیتواند اعتماد صفر پیاده کند، چون اصلاً نمیتواند به سؤال «این شخص کیست» پاسخ قطعی بدهد.
یکپارچهسازی هویت کار جذابی نیست و معمولاً هجده تا بیستوچهار ماه طول میکشد، اما هر گام دیگری روی آن سوار میشود. همینجا باید چرخهٔ عمر هویت هم درست شود: حساب کارمندی که سازمان را ترک کرده، در همان روز باید غیرفعال شود — و این بیش از آنکه یک مسئلهٔ فنی باشد، یک مسئلهٔ فرایندی بین منابع انسانی و فاوا است.
مجوزدهی در سطح درخواست
گام بعدی این است که دسترسی از «یک بار در ورود» به «هر بار در هر درخواست» منتقل شود. تفاوت عملی این است: کاربری که صبح وارد شده و لپتاپش ظهر آلوده شده، نباید تا پایان روز اعتبار کامل داشته باشد.
آنچه در هر تصمیم دسترسی باید دیده شود:
- هویت و نقش: کاربر کیست و بر اساس شغلش به چه چیزی نیاز دارد.
- وضعیت دستگاه: دستگاه شناختهشده است؟ وصلههای امنیتی خورده؟ رمزگذاری دیسک فعال است؟
- حساسیت منبع: خواندن یک گزارش عمومی با تغییر یک تراکنش مالی یکی نیست.
- بافت درخواست: زمان، مکان تقریبی، و الگوی رفتاری غیرعادی.
نکتهٔ عملی این است که سیاستها را از ابتدا پیچیده ننویسید. سیاستی که کسی نمیتواند بخواند و توضیح دهد، در اولین اختلال کنار گذاشته میشود.
ریزبخشبندی بدون بازسازی شبکه
بیشتر سازمانهای بزرگ نمیتوانند شبکهٔ خود را از نو طراحی کنند؛ نه بودجهاش هست و نه تحمل توقفش. خبر خوب این است که لازم هم نیست.
رویکرد عملی، شروع از داراییهای حیاتی است، نه از کل شبکه. سه یا چهار سامانهای را که بیشترین حساسیت را دارند مشخص کنید، و دور هر کدام یک محدودهٔ کنترلشده بکشید: فقط مبدأهای مشخص، فقط پروتکلهای لازم، با احراز هویت مستقل و ثبت کامل. بقیهٔ شبکه فعلاً همانطور که هست باقی میماند.
بعد از اینکه این الگو روی چند سامانه جواب داد، دامنه را گسترش دهید. این مسیر کندتر به نظر میرسد، اما تنها مسیری است که در سازمانهای بزرگ به نتیجه میرسد؛ طرحهای بازسازی سراسری شبکه معمولاً در سال دوم متوقف میشوند.
احراز هویت چندعاملی بدون متوقف کردن عملیات
بیشترین مقاومت سازمانی، اینجا ظاهر میشود. ترتیب اجرا اهمیت زیادی دارد:
- اول مدیران فناوری و حسابهای دارای دسترسی ممتاز. هم بیشترین ریسک همینجاست و هم این گروه از عهدهٔ حل مشکلات اولیه برمیآید.
- بعد دسترسی از راه دور — هر چیزی که از بیرون سازمان وارد میشود.
- بعد سامانههای حساس کسبوکار، به ترتیب حساسیت.
- در انتها کاربران عمومی داخلی.
سه نکته که تفاوت بین اجرای موفق و شکستخورده را میسازند: مسیر بازیابی برای کسی که گوشیاش را گم کرده باید از قبل طراحی و تمرین شده باشد، وگرنه میز خدمت در روز اول فلج میشود. برای خطوط عملیاتی که کاربر دستکش دارد یا گوشی همراهش ممنوع است، باید گزینهٔ سختافزاری در نظر گرفته شود. و هر موج اجرا باید یک دورهٔ داوطلبانه قبل از اجباری شدن داشته باشد.
هویت سرویسبهسرویس و ثبت رخداد
بخشی که معمولاً فراموش میشود، ارتباط بین خود سامانههاست. در اغلب سازمانها، سرویسها با رمز عبور ثابتی که در فایل پیکربندی نوشته شده به هم وصل میشوند — رمزی که سالهاست عوض نشده و چند نفر آن را میدانند.
حداقل کاری که باید انجام شود: هر سرویس هویت مستقل خودش را داشته باشد، اعتبارنامهها در یک مخزن اسرار نگهداری شوند نه در کد یا فایل پیکربندی، و چرخش دورهای اعتبارنامه خودکار باشد. بدون این، اعتماد صفر فقط روی کاربران انسانی پیاده شده و مسیر نفوذ اصلی باز مانده است.
ثبت رخداد هم شرط لازم است، نه یک قابلیت جانبی. اگر نتوانید بگویید چه کسی، چه زمانی، به چه چیزی دسترسی گرفت، نمیتوانید بگویید سیاستهایتان کار میکنند. ثبت باید تغییرناپذیر باشد و از دسترس مدیر همان سامانه خارج.
نقشهٔ راه صادقانه
- سال اول — هویت. یکپارچهسازی مخازن کاربر، اصلاح فرایند ورود و خروج کارکنان، و احراز چندعاملی برای دسترسیهای ممتاز و از راه دور.
- سال اول تا دوم — دید. ثبت متمرکز دسترسیها و فهرستبرداری از اینکه واقعاً چه کسی به چه چیزی دسترسی دارد. این فهرست تقریباً همیشه شگفتزدهتان میکند.
- سال دوم — داراییهای حیاتی. ریزبخشبندی و مجوزدهی در سطح درخواست، فقط برای سه تا پنج سامانهٔ اول.
- سال دوم تا سوم — سرویسها. هویت سرویسبهسرویس، مخزن اسرار، و حذف اعتبارنامههای ثابت.
- پیوسته — کاهش دسترسی. بازبینی دورهای و حذف دسترسیهایی که دیگر لازم نیستند.
در تجربهٔ ما، بیشترین کاهش ریسک در سال اول از دو کار ساده میآید که هیچکدام محصول تازهای لازم ندارند: بستن بهموقع حساب افرادی که سازمان را ترک کردهاند، و حذف دسترسیهایی که کسی دیگر استفاده نمیکند. اگر پروژهٔ اعتماد صفر شما با خرید شروع میشود، احتمالاً از جای اشتباهی شروع شده است.
