مقاله
اعتماد صفر، بدون شعار: از کجا شروع کنیم
چند سالی است «اعتماد صفر» در هر ارائه فروش تکرار میشود. این نوشته برای مدیران فنیای است که میخواهند بدانند پشت این عبارت چه تغییری در معماری دسترسی نهفته است و در سازمانی که دهها سامانه قدیمی دارد، از کجا باید شروع کرد.
در چند سال گذشته با دهها سازمان درباره «پروژه اعتماد صفر» صحبت کردهایم. در بیشتر آنها گفتوگو با پیشنهاد قیمت یک محصول شروع شده بود، پیش از آنکه کسی بپرسد چه کسانی به چه چیزی دسترسی دارند. این ترتیب معکوس است. اعتماد صفر محصول نیست؛ یک تصمیم معماری است که چند محصول میتوانند به اجرای آن کمک کنند.
اعتماد صفر واقعاً یعنی چه
اگر شعارها را کنار بگذاریم، اعتماد صفر سه گزاره فنی است که هر سه باید همزمان برقرار باشند:
- هویت، مرز جدید است. در مدل قدیمی، «داخل شبکه بودن» یعنی مورد اعتماد بودن؛ لپتاپی که به شبکه داخلی وصل میشد به هر چیزی که فایروال جلویش را نگرفته بود میرسید. در مدل جدید، تنها چیزی که اعتماد میسازد هویت تأییدشده کاربر و وضعیت تأییدشده دستگاه اوست، نه اینکه بسته از کدام کابل آمده.
- مجوز به ازای هر درخواست. یک بار ورود و بعد دسترسی نامحدود تا پایان روز، همان الگویی است که مهاجم پس از دزدیدن یک نشست از آن سود میبرد. در اعتماد صفر، هر درخواست به هر سرویس جداگانه ارزیابی میشود: این کاربر، با این دستگاه، در این ساعت، از این مکان، به این منبع مشخص، آیا مجاز است؟ پاسخ میتواند برای دو درخواست پشتسرهم متفاوت باشد.
- فرض نفوذ. طراحی طوری انجام میشود که انگار مهاجم همین حالا داخل شبکه است. پرسش این نیست که «چطور جلوی ورود را بگیریم»، بلکه «اگر یک ایستگاه کاری آلوده شد، تا کجا میرود و کِی میفهمیم».
نتیجه مشترک هر سه: شبکه دیگر واحد اعتماد نیست. فایروال محیطی و VPN بیفایده نمیشوند، اما دیگر مرکز طراحی هم نیستند. مرکز طراحی، سامانه هویت و سیاستهای دسترسی است.
چرا اجرای یکباره شکست میخورد
الگوی شکست تقریباً همیشه یکسان است. سازمان محصولی میخرد که وعده «دسترسی مبتنی بر هویت به همه برنامهها» میدهد. پروژه با چند برنامه وب جدید که احراز هویت مرکزی دارند خوب جلو میرود. بعد نوبت سامانههای اصلی میرسد: سامانه مالی با اتصال مستقیم به پایگاه داده، اتوماسیون اداری با پروتکل اختصاصی، نرمافزار خط تولید که فروشندهاش سالهاست پشتیبانی نمیکند. هیچکدام با هویت مرکزی صحبت نمیکنند. تیم پروژه یا استثنا صادر میکند، یا سیاست را آنقدر شل میکند که چیزی از آن نمیماند. شش ماه بعد، سازمان یک محصول گران دارد و همان معماری قبلی.
دلیل عمیقتر این است که اعتماد صفر پیش از هر چیز به دانستن نیاز دارد: چه هویتهایی وجود دارند، چه سرویسهایی هستند، و کدام هویت به کدام سرویس نیاز واقعی دارد. سازمانی که این نقشه را ندارد نمیتواند سیاست بنویسد؛ و بدون سیاست، هر ابزاری فقط یک VPN گرانتر است.
دلیل دوم عملیاتی است: اگر ده برنامه همزمان پشت سیاست جدید بروند و کار کسی قطع شود، هیچکس نمیداند کدام سیاست عامل آن بوده. مرحلهبندی هزینه خطا را کوچک نگه میدارد.
یک مسیر مرحلهای واقعبینانه
مسیری که در سازمانهای متوسط تا بزرگ اجرا کردهایم پنج مرحله دارد. ترتیب ثابت است، چون هر مرحله ورودی مرحله بعد را میسازد. زمانها برای سازمانی با حدود هزار کاربر و پنجاه تا هشتاد سامانه داخلی است.
مرحله اول: سرشماری هویتها و سرویسها
پیش از هر خرید، سه پرسش را روی کاغذ پاسخ دهید. چند حساب فعال دارید و چند نفر واقعی پشت آنهاست؟ چند حساب سرویسی بیمالک وجود دارد؟ کدام سامانهها هویت را از دایرکتوری مرکزی میگیرند و کدامها پایگاه کاربر جداگانه دارند؟ در تجربه ما، در یک سازمان هزار نفره معمولاً ۱۵ تا ۲۵ درصد حسابهای فعال متعلق به افرادی است که دیگر در سازمان نیستند یا نقششان عوض شده. خروجی، یک فهرست دارایی دسترسی است: هویتها، سرویسها، و برای هر سرویس یک مالک فنی و یک مالک کسبوکاری. شش تا هشت هفته.
مرحله دوم: احراز هویت قوی
تا وقتی رمز عبور تنها عامل ورود است، هویت قابل اعتماد نیست و بقیه مراحل روی شن ساخته میشوند. احراز هویت چندعاملی را ابتدا برای حسابهای ممتاز (مدیران دامنه و پایگاه داده، دسترسی راه دور) و بعد برای همه اجرا کنید. به محدودیتهای عملی داخل کشور توجه کنید: پیامک همیشه قابل اتکا نیست و برنامه تولید کد روی گوشی شخصی برای همه کارکنان پذیرفتنی نیست. کلید سختافزاری برای حسابهای ممتاز و برنامه تولید کد برای بقیه، ترکیبی است که در عمل جواب داده. همزمان حسابهای سرویسی را از رمز ثابت به گواهی یا رمز مدیریتشده با چرخش خودکار ببرید. هشت تا دوازده هفته.
مرحله سوم: بخشبندی شبکه
حالا که هویتها معتبرند، شبکه را طوری تقسیم کنید که «فرض نفوذ» معنا پیدا کند. هدف، ریزبخشبندی کامل نیست؛ هدف این است که ایستگاههای کاری، سرورهای برنامه، پایگاههای داده و سامانههای صنعتی در ناحیههای جدا باشند و بین ناحیهها فقط ترافیک مستندشده عبور کند. فهرست مرحله اول اینجا به کار میآید: میدانید کدام سرویس با کدام صحبت میکند، پس بقیه را میبندید. اما نه یکباره. ابتدا قواعد را در حالت ثبتفقط بگذارید، دو تا چهار هفته ترافیک را نگاه کنید، بعد مسدود کنید. ده تا شانزده هفته.
مرحله چهارم: دسترسی به ازای هر برنامه
این همان چیزی است که محصولات «دسترسی شبکه اعتماد صفر» میفروشند و حالا وقت خریدش رسیده. به جای ورود با VPN و رسیدن به همهچیز، برای هر برنامه درگاهی تعریف میشود که هویت، وضعیت دستگاه و سیاست را پیش از عبور درخواست بررسی میکند. برنامهها را به ترتیب حساسیت و سادگی مهاجرت بچینید: اول برنامههای وب داخلی با احراز هویت مرکزی، بعد دسترسیهای مدیریتی (SSH و RDP)، و در آخر سامانههای قدیمی که در بخش بعد به آنها میرسیم. سیاستها را ساده نگه دارید؛ پنج سیاست که همه میفهمند بهتر از پنجاه سیاستی است که فقط نویسندهاش میفهمد. سه تا شش ماه.
مرحله پنجم: راستیآزمایی پیوسته
مجوز به ازای هر درخواست بدون داده وضعیت، فقط شعار است. اینجا سیگنالهای وضعیت به موتور سیاست وصل میشوند: دستگاه وصلههای امنیتی را دارد؟ عامل حفاظت نقطه پایانی روشن است؟ این کاربر در یک ساعت گذشته از دو شهر وارد شده؟ این سیگنالها به مرکز عملیات امنیت میرود و از آنجا بازخورد به سیاستها برمیگردد. این مرحله پایان ندارد؛ بخشی از بهرهبرداری روزمره است و اگر سازمان مرکز عملیات امنیت ندارد، انگیزه خوبی برای ساختن یا برونسپاری آن است.
| معیار | اجرای مرحلهای | جایگزینی یکباره |
|---|---|---|
| هزینه سال اول | پایینتر؛ خرید ابزار به مرحله چهارم میافتد و با شناخت دقیق نیاز انجام میشود. | بالاتر؛ لایسنس همه کاربران از روز اول و معمولاً ماژولهایی که استفاده نمیشود. |
| ریسک اختلال در کار | محدود به یک ناحیه یا برنامه در هر مرحله؛ عامل خطا مشخص و بازگشت ساده است. | بالا؛ تغییر همزمان چند لایه و ریشهیابی دشوار. شلکردن سیاستها برای رفع فوری تقریباً همیشه رخ میدهد. |
| زمان تا اولین نتیجه ملموس | ۶ تا ۸ هفته | ۶ تا ۹ ماه |
| نتیجه اول | حذف حسابهای بیصاحب و عامل دوم برای حسابهای ممتاز؛ کاهش واقعی سطح حمله. | درگاه دسترسی برای چند برنامه ساده؛ سطح حمله تقریباً بدون تغییر. |
| زمان تا پوشش کامل | ۱۲ تا ۱۸ ماه | نامشخص |
| سامانههای قدیمی | از ابتدا در نقشه دیده میشوند و راهحل جبرانی برایشان طراحی میشود. | در میانه پروژه کشف میشوند و به استثنا تبدیل میشوند. |
رایجترین اشتباه
شروع از ابزار به جای فهرست. سازمانی که درگاه دسترسی میخرد ولی نمیداند چند حساب سرویسی بیصاحب دارد، فقط مسیر ورود همان حسابها را مدرنتر کرده است. پیش از امضای قرارداد خرید بپرسید: آیا میتوانیم برای ده سامانه حساسمان فهرست کاملی از اینکه چه کسی و چه چیزی به آنها دسترسی دارد بیرون بدهیم؟ اگر نه، پروژه شما هنوز پروژه خرید نیست.
سامانههایی که هرگز همراه نمیشوند
در هر سازمان ایرانی که دیدهایم، ده تا سی درصد سامانهها هیچوقت با هویت مرکزی صحبت نخواهند کرد: نرمافزار مالی که فروشندهاش تعطیل شده، سامانه کنترل صنعتی با پروتکل بیستساله، برنامهای که با کاربر مشترک و رمز ثابت به پایگاه داده وصل میشود و کسی جرئت دستزدن به آن را ندارد. راهحل، پذیرفتن واقعیت و طراحی کنترل جبرانی است:
- محصورسازی. سامانه قدیمی را در ناحیه شبکهای مخصوص خودش قرار دهید که فقط از یک مسیر مشخص قابل دسترسی است. اگر خودش نمیتواند هویت را بررسی کند، مسیر ورود به آن میتواند.
- واسط دسترسی. برای برنامههای وب قدیمی، یک پراکسی معکوس جلوی برنامه بگذارید که احراز هویت مرکزی و سیاست را اعمال کند و با همان مکانیزم قدیمی به برنامه وصل شود. برنامه چیزی نمیفهمد، اما مسیر ورودش مدرن است.
- میزبان واسط با ضبط نشست. برای دسترسی مدیریتی به سامانههای صنعتی و سرورهای قدیمی، همه ورودها از میزبان واسطی عبور کند که عامل دوم را میپرسد و کل نشست را ضبط میکند. وقتی نمیتوانید هر درخواست را مجوزدهی کنید، دستکم هر نشست را ببینید.
- مدیریت رمز مشترک. رمزهای ثابت داخل پیکربندی برنامهها را به مخزن رمزی ببرید که چرخش دورهای انجام میدهد و هر استفاده را ثبت میکند. کد برنامه تغییر نمیکند؛ فقط محل خواندن رمز عوض میشود.
- تاریخ پایان. برای هر سامانهای که کنترل جبرانی میگیرد، تاریخ بازبینی و مالک بنویسید. کنترل جبرانی بدون تاریخ، دائمی میشود.
و این سامانهها بهترین جا برای شروع پایشاند، نه بدترین جا. رفتار یک سامانه بیستساله بسیار قابل پیشبینی است: همان چند کاربر، همان چند ساعت، همان چند مقصد. هر انحرافی از این الگو سیگنال روشنی است که بهسادگی میتوان روی آن قاعده نوشت.
از فردا چه کار کنیم
اگر قرار است فقط یک کار انجام دهید، فهرست حسابهای ممتاز را بیرون بکشید و برای هرکدام یک نام و یک دلیل بنویسید. ابزار نمیخواهد، یک هفته وقت میخواهد، و تقریباً همیشه چند حساب پیدا میکند که هیچکس نمیداند چرا وجود دارند. از همینجا مرحله اول شروع شده است.
اگر پروژه هوش مصنوعی هم در سازمان در حال شکلگیری است، همان منطق «اول بدانید چه دارید» آنجا هم صادق است.
ارزیابی وضعیت دسترسی سازمان شما
در یک جلسه فنی، فهرست هویتها و سامانههایتان را مرور میکنیم و میگوییم مرحله اول برای شما چقدر طول میکشد. بدون پیشنهاد خرید.