Zero Trust دیگر اختیاری نیست: معماری امنیت سازمانی در ۲۰۲۶ چگونه دگرگون شد

در اغلب سال‌های دهه ۲۰۱۰، Zero Trust چارچوبی بود که فروشندگان امنیتی برای فروش محصولات خود و مشاوران برای توجیه قراردادهایشان به کار می‌بردند. ایده اصلی — هرگز صرفاً به این دلیل که یک درخواست از داخل محیط شبکه می‌آید به آن اعتماد نکن — درست بود؛ اما رهنمودهای پیاده‌سازی آن‌قدر مبهم بودند که سازمان‌ها می‌توانستند ادعای انطباق کنند بدون آن‌که چیزی را به‌طور بنیادی تغییر داده باشند.

آن دوران به سر رسیده است. ترکیبی از الزامات نظارتی، نقض‌های امنیتی پرسروصدا و بلوغ ابزارها، Zero Trust را از یک فلسفه معماری به حداقل استاندارد پذیرفتنی در امنیت سازمانی تبدیل کرده است.

Zero Trust واقعاً به چه معناست

Zero Trust یک محصول نیست که بخرید؛ مجموعه‌ای از اصول است که در سراسر زیرساخت شما اعمال می‌شود. هر درخواست دسترسی — از هر کاربر، دستگاه و برنامه‌ای — پیش از اعطا باید احراز هویت، مجوزدهی و اعتبارسنجی مستمر شود. در عمل، این اصول به پنج رکن خلاصه می‌شوند:

• هویت: احراز هویت چندعاملی برای هر درخواست دسترسی، با روش‌های مقاوم در برابر فیشینگ (FIDO2، کلیدهای سخت‌افزاری و Passkey) به‌جای کدهای SMS.
• دستگاه‌ها: بررسی سلامت دستگاه تأیید می‌کند که لپ‌تاپ یا گوشی هوشمند به‌روز، رمزگذاری‌شده و منطبق با سیاست‌های سازمانی است، پیش از آن‌که دسترسی اعطا شود.
• شبکه: Microsegmentation حرکت جانبی را محدود می‌کند تا یک نقطه پایانی در معرض خطر نتواند کل شبکه را در اختیار بگیرد.
• برنامه‌ها: کنترل دسترسی در لایه برنامه، نه در لایه شبکه.
• داده: طبقه‌بندی داده و کنترل‌های دسترسی که داده را دنبال می‌کنند، صرف نظر از محل ذخیره‌سازی آن.

چه چیزی این موضوع را از فلسفه به الزام تبدیل کرد

فرمان اجرایی دولت بایدن در ۲۰۲۱ سازمان‌های فدرال آمریکا را ملزم کرد تا پایان ۲۰۲۴ معماری Zero Trust را پیاده‌سازی کنند. دستورالعمل NIS2 اتحادیه اروپا که از اکتبر ۲۰۲۴ لازم‌الاجرا شد، الزامات مشابهی را برای اپراتورهای زیرساخت حیاتی به ارمغان آورد. نقض‌های امنیتی پرمخاطب — از جمله SolarWinds و حملات Exchange مایکروسافت — همگی از اعتماد ضمنی محیط شبکه سوءاستفاده کردند. از سوی دیگر، ابزارها به بلوغ کافی رسیده‌اند: Microsoft Entra، Zscaler، Cloudflare Zero Trust، Okta و CrowdStrike Falcon اکنون به‌قدری یکپارچه و آماده‌اند که بدون نیاز به پروژه‌ای سفارشی و چندساله بتوان آن‌ها را راه‌اندازی کرد.

جایگزینی VPN با ZTNA

VPN ها دسترسی گسترده‌ای در سطح شبکه اعطا می‌کنند؛ کاربری که از طریق VPN متصل می‌شود معمولاً می‌تواند به مراتب بیش از آنچه برای انجام یک کار مشخص نیاز دارد دسترسی داشته باشد. ZTNA این مدل را وارونه می‌کند: کاربر پس از تأیید هویت و سلامت دستگاه، تنها به یک برنامه مشخص متصل می‌شود. Gartner پیش‌بینی کرده بود که ZTNA بیش از ۷۰ درصد از استقرارهای دسترسی از راه دور جدید را تا ۲۰۲۵ در اختیار بگیرد — و بازار سازمانی به‌طور گسترده این مسیر را طی کرده است.

واقعیت MFA

رمزهای یک‌بارمصرف مبتنی بر SMS اکنون به‌سادگی در برابر حملات فیشینگ man-in-the-middle از کار می‌افتند. CISA و NIST اکنون MFA مقاوم در برابر فیشینگ را به‌عنوان حداقل استاندارد توصیه می‌کنند: کلیدهای امنیتی سخت‌افزاری FIDO2 مانند YubiKey، Passkey های بومی در سیستم‌عامل‌های مدرن، یا احراز هویت مبتنی بر گواهینامه.

اشتباهات رایج در پیاده‌سازی

• تلقی Zero Trust به‌عنوان یک خرید محصول. خریدن یک محصول ZTNA به‌تنهایی شما را Zero Trust نمی‌کند.
• شروع از رکن اشتباه. هویت بیشترین کاهش ریسک فوری را به همراه دارد.
• نادیده گرفتن احراز هویت سرویس به سرویس. ارتباط ماشین به ماشین اغلب پس از قفل شدن دسترسی کاربران انسانی همچنان بر اعتماد ضمنی تکیه می‌کند.
• دست‌کم گرفتن مدیریت تغییر. Zero Trust تجربه کاربری دسترسی به برنامه‌ها را دگرگون می‌کند و آمادگی سازمانی برای آن ضروری است.

نقاط شروع عملی

1. MFA مقاوم در برابر فیشینگ را برای همه کاربران مستقر کنید، با اولویت مدیران.
2. پیش از اعطای دسترسی به برنامه‌های حساس، سلامت دستگاه را بررسی کنید.
3. VPN را با ZTNA برای دسترسی از راه دور جایگزین کنید؛ با یک برنامه شروع کنید.
4. حساس‌ترین سیستم‌های داخلی را ممیزی و با دقت تقسیم‌بندی کنید.
5. طبقه‌بندی داده را پیاده‌سازی کرده و کنترل‌های دسترسی متناسب را اعمال کنید.

Zero Trust مقصدی نیست که به آن برسید و متوقف شوید. سازمان‌هایی که با آن مانند یک چک‌لیست رفتار می‌کنند دیر یا زود درمی‌یابند که مهاجمان خود را محدود به همان چک‌لیست‌ها نمی‌کنند.