از IAM سنتی تا Identity Fabric؛ معماری هویت در سازمان‌های بزرگ چگونه در حال تغییر است؟

در سازمان‌های بزرگ، گام بعدی بحث هویت به خودِ معماری آن می‌رسد. IAM، SSO، MFA و PAM هر کدام بخش مهمی از زنجیره هویت و دسترسی را پوشش می‌دهند، اما محیط سازمانی امروز بسیار گسترده‌تر شده است. کاربران به سامانه‌های داخلی، خدمات ابری و نرم‌افزارهای متعدد دسترسی دارند؛ پیمانکاران و شرکای تجاری وارد زنجیره دسترسی شده‌اند و APIها و حساب‌های مورد استفاده سرویس‌ها نیز بخشی از محیط عملیاتی‌اند. 

به گزارش روابط عمومی شرکت ره‌آورد سامانه‌های امن (ره‌سا)، در نتیجه، تصمیم‌های هویتی دیگر در یک نقطه گرفته نمی‌شوند و ممکن است هر سامانه منطق متفاوتی برای احراز هویت، سطح دسترسی و کنترل ریسک داشته باشد. Identity Fabric پاسخی معماری به همین پراکندگی است؛ رویکردی برای هماهنگ‌کردن اجزای مختلف مدیریت هویت و دسترسی، بدون اینکه لازم باشد همه آنها در یک محصول واحد ادغام شوند.

چرا معماری هویت در سازمان‌های بزرگ در حال تغییر است؟

اگر در یک سازمان بزرگ IAM، PAM، سامانه‌های ابری و ابزارهای کنترل دسترسی هرکدام به‌صورت مستقل عمل کنند، مسئله اصلی کمبود قابلیت نیست؛ هماهنگ نبودن تصمیم‌هاست. هر جزء ممکن است به‌تنهایی درست کار کند، اما اگر هر کدام تصویر متفاوتی از هویت، سطح دسترسی و ریسک داشته باشند، سازمان همچنان با سیاست‌های پراکنده و کنترل‌های ناهماهنگ روبه‌رو خواهد بود.

زیرساخت‌های داخلی و ابری در کنار نرم‌افزارهای سازمانی گسترش یافته‌اند و دسترسی دیگر فقط به کارکنان محدود نیست. پیمانکاران، شرکای تجاری، سرویس‌های نرم‌افزاری و حساب‌های سیستمی نیز به بخشی از منابع سازمان دسترسی دارند. بنابراین سؤال امروز فقط این نیست که «چه کسی وارد شده است؟»؛ باید روشن باشد این هویت از کجا آمده، با چه سطح اطمینانی شناسایی شده، چه مجوزی دارد و در چه شرایطی درخواست دسترسی می‌کند.

محدودیت معماری IAM در سازمان‌های بزرگ

تغییر معماری هویت به معنای کنار گذاشتن IAM نیست. IAM همچنان برای مدیریت چرخه عمر حساب، نقش‌ها، سیاست‌های دسترسی، اتصال به دایرکتوری، فدراسیون و کنترل‌های پایه حیاتی است. آنچه تغییر کرده، گستره محیطی است که این کنترل‌ها باید در آن عمل کنند و تعداد سامانه‌هایی است که در تصمیم دسترسی نقش دارند. از همین زاویه، بحثی که در «هویت دیجیتال، حلقه مفقوده اقتصاد دیجیتال؛ چرا کد ملی و پیامک کافی نیستند؟» درباره کامل‌بودن چرخه هویت مطرح شد، در مقیاس سازمانی یک پیامد معماری پیدا می‌کند: کافی نیست هر مرحله از چرخه هویت به‌تنهایی درست کار کند؛ این مراحل باید در سطح سازمان نیز با یکدیگر هماهنگ باشند.

در معماری سنتی، فرض غالب این بود که کاربر وارد محیطی نسبتاً مشخص می‌شود و پس از احراز هویت می‌توان تا پایان نشست به تصمیم اولیه اعتماد کرد. امروز تصمیم درباره دسترسی ممکن است در سامانه IAM، نرم‌افزار سازمانی، PAM، خدمات ابری، لایه API یا ابزارهای کنترل ریسک گرفته شود. وقتی این نقاط تصمیم‌گیری زیاد می‌شوند، مسئله دیگر صرفاً «داشتن IAM» نیست؛ هماهنگ‌کردن هویت، سیاست و سطح دسترسی در تمام این نقاط است.

در عمل، تصمیم درباره هویت و دسترسی در نقاط مختلفی گرفته می‌شود: نرم‌افزارهای سازمانی و خدمات ابری، API ها و سرویس‌های داخلی، دستگاهی که کاربر با آن وارد می‌شود، سامانه‌های ارزیابی ریسک و همچنین PAM برای دسترسی‌های ممتاز. هرکدام از این اجزا بخشی از اطلاعات را در اختیار دارند و ممکن است سیاست خاص خود را اجرا کنند. هرچه این نقاط بیشتر شوند، نیاز به سازوکاری برای هماهنگ‌کردن آنها نیز جدی‌تر می‌شود.

وقتی تصمیم‌گیری درباره هویت و دسترسی میان چند سامانه پخش می‌شود، یک IAM مرکزی به‌تنهایی نمی‌تواند همه مسئله را حل کند. چالش اصلی دیگر فقط مدیریت کاربر و ورود او نیست؛ سازمان باید بتواند میان چرخه عمر هویت، سطح دسترسی، شرایط استفاده و کنترل‌های مختلفی که در نقاط گوناگون اجرا می‌شوند ارتباط برقرار کند.

نمونه روشن این مسئله را می‌توان در دسترسی‌های ممتاز دید. PAM برای کنترل حساب‌ها و دسترسی‌های مدیریتی شکل گرفته است؛ از نگهداری و مدیریت حساب‌های ممتاز گرفته تا محدودکردن دسترسی، ثبت نشست‌ها و کنترل استفاده از حساب‌های حساس. وجود چنین کنترلی در سازمان‌های بزرگ ضروری است، اما مسئله زمانی ایجاد می‌شود که مدیریت دسترسی ممتاز کاملاً جدا از چرخه هویت کاربران انجام شود.

برای مثال ممکن است IAM وضعیت استخدام، نقش سازمانی یا غیرفعال‌شدن یک کاربر را مدیریت کند، در حالی که PAM منطق مستقلی برای دسترسی همان فرد به حساب‌های مدیریتی داشته باشد. هرچه تعداد سامانه‌ها و سطوح دسترسی بیشتر شود، هماهنگ نگه‌داشتن این دو حوزه دشوارتر می‌شود. در نتیجه، مسئله فقط داشتن IAM یا PAM نیست؛ مسئله این است که تصمیم‌های مربوط به هویت و دسترسی در سطح کل سازمان تا چه اندازه با یکدیگر هماهنگ هستند.

نشانه‌های پراکندگی هویت و دسترسی

پراکندگی هویت معمولاً با چند نشانه ساده آغاز می‌شود، اما با بزرگ‌شدن سازمان به مسئله‌ای ساختاری تبدیل می‌شود. ممکن است این نشانه‌ها در ابتدا جدا از هم دیده شوند، در حالی که در واقع همگی از نبود یک منطق مشترک برای مدیریت هویت و دسترسی ناشی می‌شوند.

یکی از نخستین نشانه‌ها، هویت‌های تکراری و ناسازگار است. کاربر در چند سامانه چند حساب دارد، با چند سطح دسترسی متفاوت. حذف دسترسی‌ها هم به‌موقع انجام نمی‌شود.

نشانه دیگر، چندپارگی سیاست‌های امنیتی است. یک تیم می‌گوید MFA اجباری است، تیم دیگر در یک سامانه استثناء می‌زند و تیم سوم در SaaS اصلاً کنترل ندارد. نتیجه: سیاست داریم، اما اجرا نداریم.

این پراکندگی در تجربه کاربری نیز خود را نشان می‌دهد. ورودهای چندمرحله‌ای، ریدایرکت‌های متعدد، رمزهای فراموش‌شده، OTP های ناپایدار؛ امنیتی که به قیمت ریزش کاربر ساخته شود، پایدار نیست. با رشد APIها و سرویس‌های سازمانی، مسئله به هویت‌های غیرانسانی نیز گسترش پیدا می‌کند.

حساب‌های سرویس (Service Accounts)، کلیدهای API، توکن‌ها و دسترسی‌های ماشینی تبدیل به «حفره‌های دائمی» می‌شوند. دسترسی‌های ممتاز نیز نمونه روشنی از همین مشکل هستند. PAM هست، اما جدا از سایر تصمیم‌های هویتی عمل می‌کند؛ یا بدتر، به‌خاطر پیچیدگی دور زده می‌شود.

این‌ها لزوماً خطای یک تیم یا یک محصول نیستند؛ نتیجه طبیعی معماری‌ای هستند که هویت را در چند جزیره مستقل نگه می‌دارد. این پراکندگی در ابتدا با چند استثناء و چند اتصال اختصاصی قابل تحمل به نظر می‌رسد، اما با رشد سازمان، هزینه آن در امنیت، پشتیبانی، ممیزی و سرعت ارائه خدمت آشکار می‌شود.

هویت سرویس‌ها و حساب‌های غیرانسانی

مسئله فقط به کاربران انسانی محدود نیست. APIها، سرویس‌های نرم‌افزاری، برنامه‌های خودکار و حساب‌های سیستمی نیز برای انجام کار به اعتبارنامه و سطح دسترسی نیاز دارند. بسیاری از فرایندهای سنتی IAM حول چرخه عمر کارکنان طراحی شده‌اند، در حالی که یک سرویس ممکن است بسیار سریع ایجاد، تغییر یا حذف شود و دسترسی آن نیز باید متناسب با همین چرخه مدیریت شود.

وابستگی طولانی‌مدت این حساب‌ها به رمزها یا کلیدهای ثابت، همان مشکلی را ایجاد می‌کند که سال‌ها در مورد گذرواژه‌های انسانی دیده شده است: اعتبارنامه‌ای ایجاد می‌شود که ممکن است مدت زیادی فعال بماند، مالک مشخصی نداشته باشد یا پس از تغییر سرویس به‌موقع لغو نشود. این هویت‌ها نیز باید وارد همان چارچوب مدیریتی شوند؛ یعنی برای هر حساب مالک مشخص باشد، سطح دسترسی به حداقل نیاز محدود شود، اعتبارنامه‌ها چرخه عمر داشته باشند و فعالیت آنها قابل ثبت و پیگیری باشد.

Identity Fabric؛ پاسخ معماری به پراکندگی هویت

وقتی IAM، PAM، سامانه‌های سازمانی، خدمات ابری و حساب‌های سیستمی هرکدام بخشی از هویت و دسترسی را مدیریت می‌کنند، مسئله اصلی به هماهنگی میان آنها تبدیل می‌شود. Identity Fabric از همین نقطه مطرح می‌شود؛ نه به‌عنوان محصولی که جای همه اجزا را بگیرد، بلکه به‌عنوان یک رویکرد معماری برای ایجاد ارتباط میان منابع هویت، سیاست‌های دسترسی و اطلاعات مربوط به ریسک. در این مدل قرار نیست همه داده‌ها در یک پایگاه واحد متمرکز شوند؛ مهم این است که اجزای مختلف بتوانند بر اساس اطلاعات و قواعدی سازگار با یکدیگر کار کنند.

چرا افزودن ابزارهای بیشتر کافی نیست؟

افزودن یک محصول جدید همیشه به معنای کامل‌ترشدن معماری هویت نیست. ممکن است هر ابزار بخشی از مسئله را به‌خوبی حل کند، اما اگر منبع هویت، سیاست دسترسی و اطلاعات مربوط به ریسک میان آنها هماهنگ نباشد، تعداد نقاط تصمیم‌گیری و استثناء ها بیشتر می‌شود. در چنین شرایطی، سازمان ابزارهای بیشتری دارد اما همچنان نمی‌تواند با اطمینان پاسخ دهد که یک کاربر چرا به منبعی خاص دسترسی دارد و این دسترسی بر چه مبنایی ایجاد یا لغو شده است.

مشکل اصلی بنابراین کمبود محصول نیست، بلکه نبود معماری مشترک است. Identity Fabric تلاش می‌کند این ابزارها را حذف نکند، بلکه میان آنها ارتباطی ایجاد کند که تغییر وضعیت هویت، سطح دسترسی یا ریسک به‌صورت منسجم در سراسر سازمان دیده شود. این تفاوت میان «داشتن مجموعه‌ای از ابزارهای هویتی» و «داشتن یک معماری هویت» است.

اجزای اصلی معماری Identity Fabric

برای اینکه Identity Fabric از یک مفهوم کلی به معماری قابل اجرا تبدیل شود، بهتر است آن را نه به‌صورت فهرستی از محصولات و فناوری‌ها، بلکه به‌عنوان چهار حوزه مرتبط ببینیم. هر حوزه بخشی از مسیر هویت و دسترسی را پوشش می‌دهد و ارزش Fabric زمانی شکل می‌گیرد که این بخش‌ها بتوانند اطلاعات و تصمیم‌های خود را با یکدیگر هماهنگ کنند.

بخش نخست به «منابع هویت و چرخه عمر» مربوط است. در یک سازمان بزرگ، هویت فقط به کارکنان رسمی محدود نمی‌شود؛ پیمانکاران، نیروهای موقت، شرکای تجاری و حتی حساب‌هایی که سرویس‌های نرم‌افزاری از آنها استفاده می‌کنند نیز باید به‌درستی مدیریت شوند. در این بخش باید مشخص باشد هر هویت از کدام منبع ایجاد شده، مالک آن چه کسی است، کدام سامانه مرجع اطلاعات آن محسوب می‌شود و چه زمانی باید سطح دسترسی آن تغییر کند یا به‌طور کامل لغو شود. برای مثال، تغییر سمت یک کارمند، پایان قرارداد یک پیمانکار یا غیرفعال‌شدن یک سرویس باید بتواند به‌صورت قابل پیش‌بینی بر دسترسی‌های مرتبط اثر بگذارد. اگر این چرخه به‌درستی مدیریت نشود، حتی بهترین سازوکار احراز هویت نیز نمی‌تواند مانع باقی‌ماندن حساب‌ها و مجوزهای قدیمی شود.

بخش دوم به «احراز هویت و ارتباط میان سامانه‌ها» مربوط می‌شود. در اینجا سؤال اصلی این است که سازمان چگونه مطمئن می‌شود فردی که درخواست دسترسی دارد واقعاً همان هویتی است که ادعا می‌کند و چگونه نتیجه این احراز هویت میان سامانه‌های مختلف قابل استفاده می‌شود. ورود یکپارچه یا SSO کمک می‌کند کاربر برای هر سامانه دوباره از ابتدا احراز هویت نشود و احراز هویت چندعاملی نیز می‌تواند سطح اطمینان بیشتری ایجاد کند. برای دسترسی‌های حساس‌تر، روش‌های مقاوم در برابر فیشینگ مانند FIDO2 و Passkey اهمیت پیدا می‌کنند. نکته مهم این است که همه دسترسی‌ها نباید با یک سطح کنترل انجام شوند؛ ورود به یک سامانه عمومی سازمانی، دسترسی به کنسول مدیریتی و تأیید یک عملیات حساس می‌توانند به سطوح متفاوتی از اطمینان نیاز داشته باشند. جزئیات استانداردهایی که این ارتباط را ممکن می‌کنند در ادامه مقاله بررسی می‌شود.

بخش سوم «مجوزدهی و اجرای سیاست دسترسی» است. احراز هویت فقط مشخص می‌کند چه کسی در حال درخواست دسترسی است؛ اما هنوز باید تعیین شود این فرد دقیقاً به چه چیزی، در چه سطحی و تحت چه شرایطی مجاز است. نقش سازمانی کاربر، وضعیت همکاری او، حساسیت سامانه مقصد، نوع عملیات و در برخی موارد وضعیت دستگاه یا سطح ریسک می‌توانند در این تصمیم اثر داشته باشند. در یک سازمان بزرگ، این تصمیم ممکن است در IAM، PAM، سامانه‌های سازمانی، خدمات ابری یا لایه دسترسی به API ها اجرا شود. اگر هر کدام منطق مستقلی داشته باشند، یک کاربر ممکن است در دو سامانه مشابه سطوح دسترسی متفاوتی بگیرد. هدف Identity Fabric این است که تا حد امکان یک منطق مشترک بر این تصمیم‌ها حاکم باشد؛ به‌طوری‌که سازمان بتواند توضیح دهد چرا یک دسترسی ایجاد شده، بر چه اساسی ادامه پیدا کرده و چه زمانی باید محدود یا لغو شود.

بخش چهارم به «نظارت و ارزیابی ریسک» مربوط است. مدیریت هویت با صدور دسترسی پایان پیدا نمی‌کند. سازمان باید بتواند ببیند چه کسی وارد شده، چه دسترسی‌ای دریافت کرده، از حساب‌های حساس چگونه استفاده شده و آیا در طول استفاده رفتار غیرعادی یا تغییر شرایطی رخ داده است یا نه. این اطلاعات برای حسابرسی و بررسی رخدادها ضروری است، اما ارزش آن زمانی بیشتر می‌شود که بتواند دوباره وارد فرایند تصمیم‌گیری شود. برای مثال، اگر سطح ریسک یک نشست افزایش پیدا کند، سازمان می‌تواند از کاربر احراز هویت قوی‌تری بخواهد، دامنه دسترسی را محدود کند یا یک دسترسی ممتاز را متوقف کند. به این ترتیب، تصمیم دسترسی یک تصمیم ثابت و همیشگی نیست و می‌تواند با تغییر شرایط بازبینی شود.

ارتباط میان این چهار بخش همان چیزی است که تفاوت میان «داشتن چند ابزار هویتی» و «داشتن یک معماری هویت» را ایجاد می‌کند. ممکن است هر کدام از این قابلیت‌ها با محصول یا سامانه متفاوتی اجرا شوند؛ Identity Fabric قرار نیست همه آنها را در یک محصول واحد جمع کند. هدف این است که چرخه عمر هویت، احراز هویت، تصمیم دسترسی و ارزیابی ریسک از یکدیگر جدا و بی‌خبر نباشند و تغییر در یک بخش بتواند در صورت نیاز بر تصمیم بخش‌های دیگر اثر بگذارد.

Identity Fabric چگونه این اجزا را یکپارچه می‌کند؟

Identity Fabric را بهتر است یک معماری و مجموعه‌ای از اصول طراحی بدانیم، نه یک محصول آماده. در این رویکرد، سرویس‌های هویتی موجود حذف نمی‌شوند؛ بلکه در قالب یک لایه منسجم به یکدیگر متصل می‌شوند تا داده و سیگنال به اشتراک بگذارند، سیاست‌های سازگار اعمال کنند و در برابر تغییر محیط یا ریسک، واکنش هماهنگ نشان دهند.

هدف Fabric ساخت یک ابرسامانه نیست؛ هدف ایجاد زبان و منطق مشترک میان اجزایی است که از قبل در سازمان وجود دارند. هویت در این مدل به‌جای یک پروژه جانبی، به لایه‌ای زیرساختی برای اعمال اعتماد در سراسر سازمان تبدیل می‌شود.

در عمل، Identity Fabric زمانی معنا پیدا می‌کند که اطلاعات هویتی و نشانه‌های مرتبط با ریسک در نقاط مختلف سازمان قابل استفاده باشند و سیاست‌های دسترسی نیز تا حد ممکن با منطق مشترکی اعمال شوند. به این ترتیب، تغییر وضعیت کاربر، دستگاه یا سطح ریسک در یک بخش از سازمان می‌تواند در تصمیمی که بخش دیگری درباره دسترسی می‌گیرد اثر بگذارد. هدف، متمرکز کردن تمام تصمیم‌ها در یک سامانه نیست؛ هدف این است که تصمیم‌های پراکنده بر اساس اطلاعات و اصول مشترک گرفته شوند.

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

این معماری برای محیطی مناسب است که مرز شبکه دیگر معیار کافی اعتماد نیست و وضعیت هویت، دستگاه، نشست و ریسک می‌تواند در طول تعامل تغییر کند. در چنین محیطی، اعتماد باید قابل بازبینی باشد، نه اینکه با یک ورود موفق برای مدت طولانی ثابت فرض شود.

تصمیم‌گیری مستمر درباره دسترسی

در اینجا ارتباط Identity Fabric با الگوی Zero Trust روشن می‌شود. در این الگو، تصمیم دسترسی نباید فقط بر یک ورود موفق در ابتدای نشست متکی باشد و لازم است با تغییر شرایط قابل بازبینی باشد.

به بیان ساده، سطح اعتماد می‌تواند در طول یک نشست تغییر کند.

IAM سنتی معمولاً در لحظه ورود تصمیم می‌گیرد و بعد «جلسه» را تا مدت‌ها معتبر نگه می‌دارد.

Identity Fabric اما می‌گوید اعتماد یک وضعیت قابل تغییر است، نه یک رویداد یک‌باره. اگر دستگاه ناامن شود، رفتار کاربر از الگوی معمول خارج شود، ریسک افزایش یابد یا کاربر به عملیاتی حساس برسد، سیاست باید بتواند همان لحظه واکنش نشان دهد: احراز هویت قوی‌تر، محدود سازی سطح دسترسی، کوتاه‌کردن نشست یا قطع دسترسی. این همان نقطه‌ای است که معماری هویت با اصول Zero Trust هم‌راستا می‌شود.

نقش استانداردهای باز در Identity Fabric

Identity Fabric بدون استانداردهای باز به مجموعه‌ای از اتصال‌های اختصاصی و پرهزینه تبدیل می‌شود. استانداردهایی مانند OpenID Connect و SAML امکان فدراسیون و ورود یکپارچه را فراهم می‌کنند، SCIM می‌تواند چرخه ایجاد، تغییر و حذف حساب‌ها را میان سامانه‌ها هماهنگ کند و FIDO2 و WebAuthn نیز برای احراز هویت مبتنی بر کلید عمومی و مقاوم در برابر فیشینگ اهمیت دارند. نقش این استانداردها آن است که اجزای مختلف بتوانند بدون وابستگی کامل به یک محصول واحد، با زبان مشترکی با یکدیگر تعامل کنند.

در نقطه ورود نیز پایه اعتماد باید محکم باشد. مسئله‌ای که در «رمز عبور، گلوگاه امنیت دیجیتال؛ وقت تغییر مدل احراز هویت است» از زاویه ضعف گذرواژه و احراز هویت قابل‌فیشینگ مطرح شد، در معماری Identity Fabric هم همچنان نقطه شروع است؛ زیرا اگر احراز هویت اصلی بر روشی شکننده متکی باشد، ضعف همان نقطه می‌تواند بر تصمیم‌های بعدی دسترسی نیز اثر بگذارد. FIDO2، WebAuthn و Passkey به این دلیل اهمیت دارند که احراز هویت را به سرویس معتبر و کلید خصوصی محافظت‌شده متصل می‌کنند. بااین‌حال، احراز هویت قوی به‌تنهایی کافی نیست و چرخه عمر، بازیابی، مجوزدهی و حفاظت از نشست نیز باید با همان سطح دقت طراحی شوند.

پیامدهای ادامه معماری جزیره‌ای

ادامه معماری جزیره‌ای فقط یک مسئله امنیتی ایجاد نمی‌کند. هر سامانه جدید به اتصال و تنظیمات اختصاصی بیشتری نیاز پیدا می‌کند، تیم پشتیبانی زمان بیشتری صرف خطاهای دسترسی و بازیابی حساب می‌کند و ممیزی نیز دشوارتر می‌شود، زیرا تصویر واحدی از اینکه چه کسی به چه چیزی دسترسی دارد وجود ندارد. در چنین شرایطی، پروژه‌های تحول دیجیتال نیز کندتر می‌شوند، چون هر خدمت تازه باید بخشی از مسئله هویت و دسترسی را دوباره حل کند.

هزینه این وضعیت معمولاً به‌تدریج انباشته می‌شود. سازمان ممکن است در کوتاه‌مدت بدون رخداد جدی به کار خود ادامه دهد، اما با افزایش تعداد سامانه‌ها، کاربران، پیمانکاران و دسترسی‌های ممتاز، استثناء های بیشتری شکل می‌گیرد و اصلاح معماری دشوارتر و پرهزینه‌تر می‌شود. از این منظر، Identity Fabric فقط یک برنامه امنیتی نیست؛ تلاشی برای کاهش هزینه و پیچیدگی مدیریت هویت در مقیاس سازمانی است.

سازمانی که معماری هویت خود را اصلاح نمی‌کند، الزاماً فردا دچار رخنه نمی‌شود؛ اما هزینه تأخیر به‌تدریج انباشته می‌شود: اتصال هر سامانه جدید زمان بیشتری می‌گیرد، استثناء های امنیتی افزایش می‌یابند، ممیزی دشوارتر می‌شود و پروژه‌های Cloud و API به‌جای استفاده از یک لایه اعتماد مشترک، هویت را دوباره از ابتدا حل می‌کنند.

Identity Fabric در سازمان‌های بزرگ ایرانی

برای سازمان‌های بزرگ ایرانی، مسئله اصلی آشنایی با اصطلاح Identity Fabric نیست؛ مسئله این است که پروژه‌های جدید IAM، SSO و PAM با همان منطق جزیره‌ای گذشته طراحی نشوند. سازمانی که امروز در حال نوسازی زیرساخت هویت و دسترسی است، فرصت دارد معماری را از ابتدا طوری طراحی کند که هویت، سیاست و اطلاعات مربوط به ریسک میان اجزای مختلف قابل استفاده باشد.

به‌ویژه در بانک‌ها، شرکت‌های پرداخت، اپراتورها، هلدینگ‌های بزرگ و سازمان‌هایی که هم‌زمان زیرساخت داخلی، خدمات ابری، شبکه‌ای از پیمانکاران و تعداد زیادی API دارند، ارزش سرمایه‌گذاری در هویت فقط به «ورود یکپارچه‌تر» محدود نمی‌شود. هدف باید ایجاد زیرساختی باشد که هویت و دسترسی را در محیط‌های مختلف با منطق مشترک مدیریت کند و در صورت تغییر شرایط، امکان بازبینی تصمیم دسترسی وجود داشته باشد.

بنابراین سؤال درست در خرید بعدی این نیست که «کدام IAM امکانات بیشتری دارد؟» سؤال بهتر این است: معماری پیشنهادی چگونه با سامانه‌های فعلی تعامل می‌کند، چه استانداردهایی را واقعاً پیاده می‌کند، چگونه سیگنال ریسک را وارد تصمیم می‌کند، هویت انسانی و ماشینی را چگونه پوشش می‌دهد و آیا تغییر یک جزء در آینده، بازطراحی کل زنجیره هویت را تحمیل می‌کند یا نه.

اگر پاسخ این پرسش‌ها روشن نباشد، سازمان ممکن است محصولی مدرن بخرد اما همان بدهی هویتی گذشته را با فناوری جدید بازتولید کند.

مسیر مهاجرت به Identity Fabric

سازمان‌ها معمولاً به دو دلیل مهاجرت را عقب می‌اندازند: ترس از پیچیدگی و ترس از اختلال.

مهاجرت به Identity Fabric نباید با تعویض یک‌شبه IAM اشتباه گرفته شود. مسیر عملی معمولاً مرحله‌ای است و از شناخت وضعیت موجود آغاز می‌شود: منابع هویت کجاست؟ مالک هر هویت کیست؟ کدام سامانه مرجع است؟ دسترسی‌ها در کجا تصمیم‌گیری می‌شوند؟ کدام حساب‌ها بدون مالک یا خارج از چرخه عمر رسمی‌اند؟ و کدام فرایندها بیشترین ریسک یا هزینه عملیاتی را دارند؟ سپس می‌توان به‌تدریج جزیره‌ها را کاهش داد:

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

در همین مسیر، PAM باید از یک جزیره مستقل برای مدیریت حساب‌های ممتاز خارج شود و با چرخه عمر هویت و سیاست‌های دسترسی هماهنگ شود؛ به‌گونه‌ای که دسترسی ممتاز تا حد امکان موقت، محدود و متناسب با نیاز واقعی باشد. هم‌زمان، حساب‌های حساس باید به روش‌های احراز هویت مقاوم‌تر در برابر فیشینگ منتقل شوند و حساب‌های مورد استفاده سرویس‌ها و APIها نیز زیر همان منطق مدیریتی قرار گیرند. به این ترتیب مهاجرت به Identity Fabric نه با تعویض یک‌باره سامانه‌ها، بلکه با کاهش تدریجی تصمیم‌های مستقل و ایجاد منطق مشترک میان آنها پیش می‌رود.

در ادامه باید اطلاعات مربوط به وضعیت دستگاه، رفتار کاربر و سطح ریسک به تصمیم‌های دسترسی متصل شوند؛ حساب‌های پرریسک به احراز هویت قوی‌تر منتقل شوند و حساب‌های سرویس و دسترسی‌های ماشینی نیز وارد همان مدل مدیریتی شوند. معیار موفقیت نیز فقط تعداد کاربران مهاجرت‌کرده نیست؛ زمان ایجاد و لغو دسترسی، تعداد حساب‌های بدون مالک، پوشش احراز هویت مقاوم در برابر فیشینگ، تعداد دسترسی‌های دائمی و استثناء های سیاستی شاخص‌های دقیق‌تری هستند.

IAM همچنان بخش حیاتی امنیت و تحول دیجیتال باقی می‌ماند، اما شکل موفق آن در حال تغییر است. سازمان‌ها دیگر نمی‌توانند هویت را به یک صفحه ورود، یک دایرکتوری یا یک محصول منفرد محدود کنند. هویت باید به لایه‌ای زیرساختی تبدیل شود که چرخه عمر، احراز هویت، مجوزدهی، ریسک، دستگاه، نشست و هویت‌های ماشینی را در یک منطق قابل‌ردیابی به هم متصل کند.

Identity Fabric نامی برای همین گذار است: از مجموعه‌ای از ابزارهای هویتی به معماری‌ای که آنها را به‌صورت یک سیستم هماهنگ به کار می‌گیرد. سازمانی که این گذار را زودتر آغاز کند، فقط سطح حمله را کاهش نمی‌دهد؛ توسعه خدمات جدید را سریع‌تر، ممیزی را ساده‌تر، تجربه کاربر را کم‌اصطکاک‌تر و تصمیم‌های دسترسی را قابل‌توضیح‌تر می‌کند.

نکته اصلی این نیست که IAM سنتی کنار گذاشته شود؛ مسئله این است که اگر IAM، PAM و سایر کنترل‌های دسترسی به‌صورت جزیره‌ای باقی بمانند، هر ابزار جدید می‌تواند پیچیدگی بیشتری ایجاد کند. آینده مدیریت هویت در یک محصول تازه خلاصه نمی‌شود؛ در معماری‌ای است که بتواند هویت و دسترسی را در سراسر سازمان به‌صورت هماهنگ، استاندارد و متناسب با ریسک مدیریت کند.