سالها معماری امنیت سازمانی بر یک فرض ساده بنا شده بود: آنچه داخل شبکه سازمان قرار دارد، قابلاعتمادتر از چیزی است که بیرون آن قرار دارد. کاربری که از داخل شعبه، دیتاسنتر یا شبکه خصوصی بانک متصل میشد، پس از عبور از دیواره آتش، VPN یا چند کنترل اولیه، معمولاً وارد محدودهای میشد که بخش مهمی از اعتماد از همان نقطه به بعد به او داده میشد. اما بانکداری امروز دیگر در چنین مرز مشخصی زندگی نمیکند.
به گزارش روابط عمومی شرکت رهآورد سامانههای امن (رهسا)، موبایلبانک، بانکداری باز، API ها، سرویسهای ابری، پیمانکاران، دورکاری، فینتکها و معماریهای مبتنی بر Microservice باعث شدهاند مفهوم داخل و خارج شبکه بسیار کمرنگتر از گذشته شود. همین تغییر، یک پرسش بنیادی را پیش روی مدیران فناوری و امنیت قرار داده است: اگر دیگر نتوان به محل اتصال کاربر یا سرویس بهعنوان مبنای اعتماد تکیه کرد، اعتماد باید بر چه چیزی بنا شود؟
در یادداشتهای قبلی درباره ضعف مدلهای مبتنی بر رمز عبور، ضرورت ایجاد زیرساخت هویت دیجیتال، نقش IAM در معماری سازمان و حرکت به سمت Passwordless ،FIDO و Passkey صحبت شده است و در گفتوگو درباره اعتماد دیجیتال، موضوع گذار از امنیت سنتی به اعتماد مبتنی بر هویت را از زاویهای کلانتر بررسی کردیم.
این مباحث در ظاهر موضوعاتی جداگانهاند، اما همگی به یک نقطه مشترک میرسند: در معماری امنیت جدید، هویت به یکی از مهمترین مبانی تصمیمگیری درباره اعتماد تبدیل شده است. Zero Trust را میتوان ادامه طبیعی همین مسیر دانست.
Zero Trust؛ اعتماد حذف نمیشود، پیشفرض بودن آن حذف میشود
Zero Trust گاهی با عبارت هرگز اعتماد نکن، همیشه بررسی کن خلاصه میشود، اما مسئله صرفاً بیاعتمادی به همهچیز نیست. موضوع اصلی این است که اعتماد نباید صرفاً بر اساس حضور در شبکه داخلی، مالکیت یک دستگاه یا یک بار احراز هویت در ابتدای روز ایجاد شود.
NIST در معماری Zero Trust تأکید میکند که نباید به کاربر یا دارایی صرفاً به دلیل موقعیت فیزیکی یا شبکهای آن اعتماد ضمنی داد و تصمیم دسترسی باید حول کاربر، دستگاه، منبع و سیاستهای دسترسی شکل بگیرد. به بیان سادهتر، هر درخواست دسترسی باید بتواند پاسخ روشنی به چند سؤال بدهد: چه کسی درخواست را ارسال کرده است؟ از چه دستگاهی؟ به چه منبعی؟ در چه شرایطی؟ و با چه سطحی از ریسک؟
بنابراین Zero Trust یک محصول مشخص نیست که سازمان آن را خریداری و نصب کند؛ بلکه یک مدل معماری و عملیاتی است که نحوه ایجاد و تداوم اعتماد را تغییر میدهد.
اگر قرار باشد هر درخواست دسترسی بهصورت مستقل ارزیابی شود، نخستین مسئله این است که بدانیم دقیقاً چه هویتی پشت آن درخواست قرار دارد. به همین دلیل Identity در معماری Zero Trust صرفاً یکی از اجزای امنیت نیست؛ بلکه به یکی از مهمترین ورودیهای تصمیمگیری تبدیل میشود.
در مدل سنتی، IAM عمدتاً با ایجاد حساب کاربری، SSO، مدیریت نقشها و احراز هویت شناخته میشد. در معماری هویتمحور، نقش IAM گستردهتر میشود. هویت باید با سیاستهای دسترسی، سطح حساسیت منبع، وضعیت دستگاه، روش احراز هویت و اطلاعات مرتبط با ریسک ترکیب شود تا درباره مجاز بودن یک درخواست تصمیمگیری شود.
این فرایند را میتوان بهصورت یک زنجیره منطقی دید که از شناخت هویت آغاز میشود و در نهایت به تصمیم درباره دسترسی میرسد.
نخست، باید مشخص شود چه هویتی پشت درخواست قرار دارد (Identity)؛ این هویت میتواند یک کاربر، مدیر، اپراتور، پیمانکار یا حتی یک سرویس و حساب ماشینی باشد. تا زمانی که هویت بهدرستی شناخته نشده باشد، تصمیمگیری درباره سطح دسترسی قابل اتکا نیست.
در مرحله بعد، سیستم باید بررسی کند این هویت چگونه اثبات شده است (Authentication). تفاوت زیادی میان ورود صرف با نام کاربری و رمز عبور، استفاده از MFA یا احراز هویت مبتنی بر FIDO وجود دارد. هرچه روش احراز هویت مقاومتر و قابلاعتمادتر باشد، سطح اطمینان نسبت به هویت نیز افزایش پیدا میکند.
سپس زمینه و سطح ریسک درخواست (Context & Risk) بررسی میشود. اینکه کاربر از چه دستگاهی، در چه زمان و شرایطی، از چه شبکهای و برای دسترسی به کدام منبع درخواست ارسال کرده است، میتواند بر تصمیم دسترسی اثر بگذارد. ممکن است همان کاربر در شرایط عادی مجاز به دسترسی باشد، اما در شرایط غیر معمول نیازمند کنترل یا احراز هویت قویتری شود.
در ادامه، این اطلاعات در کنار سیاستهای دسترسی (Access Policies) سازمان ارزیابی میشوند. سیاستها مشخص میکنند که برای هر گروه از کاربران، سامانهها و عملیات، چه شرایطی باید برقرار باشد؛ برای مثال آیا استفاده از MFA الزامی است، چه نوع دستگاهی قابل قبول است یا برای یک عملیات حساس چه سطحی از احراز هویت مورد نیاز است.
بر اساس مجموع این اطلاعات، تصمیم مجوز دسترسی (Authorization) گرفته میشود. احراز هویت موفق به این معنا نیست که کاربر باید به همه منابع یا همه عملیات دسترسی داشته باشد. نتیجه میتواند اجازه دسترسی، محدود کردن سطح دسترسی، درخواست احراز هویت تکمیلی یا در شرایط پرریسک، مسدود کردن درخواست باشد.
به این ترتیب، Zero Trust بهجای یک تصمیم ساده و ایستا درباره «اجازه دادن یا ندادن»، یک تصمیم پویا بر اساس هویت، قدرت احراز هویت، شرایط درخواست، سطح ریسک و سیاستهای امنیتی ایجاد میکند.
برای مثال، ممکن است کارمند یک بانک هر روز از لپتاپ سازمانی خود و در ساعت کاری به یک سامانه مشخص متصل شود. همان کاربر اگر در ساعت غیرمعمول، از دستگاهی جدید و برای دسترسی به یک سامانه حساستر درخواست ارسال کند، نباید لزوماً همان سطح اعتماد قبلی را دریافت کند. سیستم میتواند دسترسی را محدود کند، احراز هویت قویتری درخواست کند یا حتی دسترسی را تا بررسی بیشتر متوقف کند.
این همان نقطهای است که مفاهیمی مانند Adaptive Authentication ،Risk-based Access و Step-up Authentication از یک قابلیت جانبی به بخشی از معماری امنیت تبدیل میشوند.
اگر هویت پایه اعتماد است، احراز هویت آن هم باید قابلاعتماد باشد
اینجا یک مسئله دیگر مطرح میشود. اگر معماری Zero Trust را بر هویت بنا کنیم اما اثبات آن هویت همچنان متکی بر Username و Password یا روشهای آسیبپذیر باشد، عملاً پایه این معماری ضعیف باقی میماند.
در یادداشت احراز هویت بدون رمز عبور؛ FIDO و Passkey در بانکداری به این موضوع پرداختیم که Passwordless صرفاً حذف یک فیلد از صفحه ورود نیست. استانداردهایی مانند FIDO2 با استفاده از رمزنگاری کلید عمومی، وابستگی به رمز مشترکی را که میتواند سرقت، فیش یا باز استفاده شود کاهش میدهند. در اینجا FIDO خودِ Zero Trust نیست، اما میتواند یکی از پایههای مهم ایجاد اطمینان از هویت در چنین معماریای باشد.
در بسیاری از سناریوهای عمومی، Passkey روی تلفن همراه یا دستگاه شخصی کاربر میتواند تجربه مناسبی ایجاد کند. اما در محیطهای حساس بانکی و سازمانی، گاهی سازمان نیاز دارد عامل احراز هویت تحت کنترل خودش باشد، به دستگاه شخصی وابسته نباشد و کلید رمزنگاری نیز از یک عامل سختافزاری مستقل خارج نشود. در چنین شرایطی، توکنهای سختافزاری FIDO2 و بهویژه توکنهای مجهز به PIN یا بیومتریک میتوانند سطح اطمینان بالاتری برای برخی کاربران و عملیات حساس فراهم کنند.
احراز هویت قوی، پایان مسیر نیست
یکی از خطاهای رایج این است که Zero Trust را با MFA یا Passwordless معادل بدانیم. حتی اگر کاربر با یک روش بسیار قوی احراز هویت شود، این به آن معنا نیست که باید برای مدت طولانی و به همه منابع دسترسی داشته باشد.
کاربری که با یک توکن FIDO احراز شده است ممکن است مجاز به مشاهده اطلاعات یک سامانه باشد، اما برای انجام عملیات حساستر نیازمند سیاست متفاوتی باشد. همچنین ممکن است تغییر دستگاه، الگوی دسترسی، ساعت ورود یا حساسیت عملیات باعث شود سامانه دوباره سطح اعتماد را ارزیابی کند.
به همین دلیل، احراز هویت قوی باید در کنار SSO ،MFA، سیاستهای دسترسی، Least Privilege و ارزیابی زمینهای قرار گیرد. ارزش واقعی زمانی ایجاد میشود که این اجزا بهصورت جزیرهای عمل نکنند و از یک سیاست هویتی منسجم پیروی کنند.
نشانه؛ هویت بهعنوان لایه امنیت
در شرکت رهآورد سامانههای امن (رهسا) نیز پلتفرم نشانه با همین نگاه توسعه پیدا کرده است؛ یعنی هویت صرفاً یک صفحه ورود نیست، بلکه باید به لایهای برای کنترل دسترسی و ایجاد اعتماد دیجیتال در سازمان تبدیل شود. قابلیتهایی مانند IAM ،SSO ،MFA، احراز هویت Passwordless و پشتیبانی از FIDO میتوانند در کنار سیاستهای متناسب با سطح حساسیت سامانهها و کاربران، بخشی از زیرساخت هویتمحور سازمان را شکل دهند.
در سناریوهایی که سطح اطمینان بیشتری مورد نیاز است، این معماری میتواند با توکنهای سختافزاری FIDO2 و توکنهای بایومتریک ترکیب شود تا عامل احراز هویت مستقل از رمز عبور و تحت کنترل سازمان قرار گیرد. این رویکرد بهویژه برای کاربران ممتاز، مدیران، اپراتورهای سامانههای حساس و فرایندهایی که نیازمند سطح بالاتری از اطمینان هویتی هستند، اهمیت بیشتری پیدا میکند.
البته Zero Trust به IAM یا FIDO محدود نمیشود و برای پیادهسازی کامل آن به کنترلهای دیگری در حوزه شبکه، Endpoint، مانیتورینگ، سیاستگذاری و حفاظت از داده نیز نیاز است. اما بدون هویت قابلاعتماد و سیاست دسترسی منسجم، بخش مهمی از تصمیمگیری Zero Trust عملاً فاقد پایه خواهد بود.
از داخل شبکه بودن تا مجاز بودن در این لحظه
حرکت به سمت Zero Trust برای بانکها بیش از آنکه خرید یک فناوری جدید باشد، تغییر در منطق اعتماد است. سازمان دیگر صرفاً به دلیل حضور کاربر در شبکه داخلی، داشتن VPN یا حتی انجام یک احراز هویت موفق، اعتماد دائمی ایجاد نمیکند. اعتماد باید متناسب با هویت، روش احراز هویت، دستگاه، زمینه درخواست، منبع مقصد و سطح ریسک ساخته و در صورت تغییر شرایط دوباره ارزیابی شود.
شاید بتوان تفاوت دو نگاه را در یک سؤال خلاصه کرد. در معماری سنتی میپرسیدیم: آیا این کاربر داخل شبکه ماست؟ اما در معماری Zero Trust سؤال دقیقتر این است: آیا این هویت، با این عامل احراز هویت، از این دستگاه و در این شرایط، مجاز به انجام این عملیات است؟
در جهانی که مرز شبکه هر روز کمرنگتر میشود، پاسخ به همین سؤال میتواند مرز جدید امنیت را تعریف کند.