شرکت‌ها مدیریت هویت را برای عامل‌های هوش مصنوعی از نو می‌سازند، نه برای انسان‌ها

اشتراک‌گذاری:
شرکت‌ها مدیریت هویت را برای عامل‌های هوش مصنوعی از نو می‌سازند، نه برای انسان‌ها

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

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

چرا دسترسی‌های دائمی خطر واقعی هستند

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

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

مدیریت هویت عامل‌محور واقعاً چه چیزی نیاز دارد

ارائه‌دهندگان امنیتی و معماران سازمانی که به سمت راه‌حل همگرا می‌شوند، به چند رویه مشخص می‌رسند، نه یک محصول معجزه‌آسا:

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

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

مجوزدهی دقیق. کنترل دسترسی مبتنی بر نقش (RBAC)، استاندارد پیش‌فرض برای IAM انسانی، برای عامل‌هایی که هزاران تصمیم کوچک وابسته به زمینه می‌گیرند بیش از حد کلی است. مدل‌های کنترل دسترسی مبتنی بر ویژگی (ABAC) یا رابطه (ReBAC) اجازه می‌دهند مجوزها به داده‌های خاص، وظیفه و زمینه ریسک هر اقدام بستگی داشته باشند، نه فقط یک برچسب نقش ثابت.

اختیار تفویض‌شده و قابل تأیید رمزنگاری‌شده. وقتی عاملی از طرف کاربر یا سیستم دیگری عمل می‌کند، این تفویض باید صریح و قابل اثبات باشد — معمولاً از طریق استانداردهایی مانند تبادل توکن OAuth 2.0 یا فدراسیون هویت بار کاری — تا عامل آلوده نتواند به طور بی‌صدا هویتی با امتیاز بالاتر را جعل کند.

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

چشم‌انداز ارائه‌دهندگان هنوز در حال شکل‌گیری است

ارائه‌دهندگان هویت از جمله SailPoint، Okta و CyberArk در سال گذشته ابزارهایی مخصوص هویت‌های غیرانسانی و عامل‌محور عرضه یا اعلام کرده‌اند، معمولاً تحت عناوینی مانند IAM عامل‌محور یا بافت هویت. هیچ‌کدام از این محصولات به طور کامل جایگزین یک استقرار IAM انسان‌محور نمی‌شوند — اکثر شرکت‌ها هر دو سیستم را به موازات هم اجرا می‌کنند، که خود این کار ریسک یکپارچگی و سازگاری ایجاد می‌کند. واقعیت عملی برای بیشتر تیم‌های امنیتی در حال حاضر ترکیبی است: IAM موجود که با سیاست‌های خاص عامل گسترش یافته، مدیریت اسرار که برای صدور اعتبارنامه‌های کوتاه‌مدت سخت‌گیرانه‌تر شده، و لایه‌های نظارتی جدید برای شناسایی رفتار غیرعادی عامل‌ها در زمان واقعی.

این برای شما که عامل‌های هوش مصنوعی مستقر می‌کنید چه معنایی دارد

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

اشتراک‌گذاری:
مدیریت هویت عامل‌های هوش مصنوعی در سازمان | IRCNF | AIO APEX