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

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

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

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

چرا هویت‌های غیرانسانی به یک ریسک اولویت‌دار تبدیل شده‌اند

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

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

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

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

۱. آن‌ها هویت‌ها را سریع‌تر از آنکه حاکمیت بتواند به آن برسد، تکثیر می‌کنند

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

۲. آن‌ها برای راحتی، مجوزهای گسترده را تشویق می‌کنند

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

۳. آن‌ها مسیرهای سوءاستفاده غیرمستقیم ایجاد می‌کنند

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

۴. آن‌ها پاسخگویی را تضعیف می‌کنند

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

شکاف‌های کنترلی رایجی که سازمان‌ها باید انتظار داشته باشند پیدا کنند

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

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

توصیه‌های حاکمیتی که اکنون اهمیت دارند

یک موجودی از هویت ماشین با مالکیت مشخص ایجاد کنید

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

مجوزهای عامل را بر اساس حساسیت اقدام طبقه‌بندی کنید

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

به طور پیش‌فرض از اعتبارنامه‌های موقت و دسترسی واسطه‌ای استفاده کنید

در هر کجا که ممکن است، API key های استاتیک و اسرار با عمر طولانی را با token های کوتاه‌مدت، فدراسیون workload identity، دسترسی به موقع و بازیابی اسرار با واسطه مرکزی جایگزین کنید. اگر یک پلتفرم عامل نتواند از مدیریت اعتبارنامه مدرن پشتیبانی کند، این محدودیت باید علیه تأیید تولیدی آن به حساب آید.

اصل حداقل امتیاز را بر اساس وظیفه، نه بر اساس پلتفرم، الزامی کنید

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

دروازه‌های سیاستی برای اقدامات پرخطر پیاده‌سازی کنید

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

تصمیمات عامل و استفاده از هویت را به گونه‌ای ثبت کنید که بازرسان بتوانند آن را دنبال کنند

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

یک مسیر بازبینی رسمی برای استقرار عامل‌ها ایجاد کنید

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

تغییر استراتژیکی که رهبران امنیتی باید ایجاد کنند

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

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

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

اشتراک‌گذاری:
عامل‌های هوش مصنوعی و هویت‌های غیرانسانی، سطح حمله جدید سازمانی هستند | AIO APEX