دیگر سازمانها نمیتوانند عاملهای هوش مصنوعی را از کارمندان خود تشخیص دهند
بیشتر تیمهای امنیت سازمانی دفاع خود را بر یک فرض ساده بنا کردهاند: هر ورود به سیستم نماینده یک انسان است. این فرض در دو سال اخیر شکسته شده و اغلب سازمانها هنوز خود را با آن تطبیق ندادهاند. عاملهای هوش مصنوعی امروزی به سرویسهای داخلی احراز هویت میکنند، API فراخوانی میکنند، دادههای حساس بازیابی میکنند و جریانهای کاری چندمرحلهای را بدون تأیید انسانی در هر مرحله زنجیر میکنند. لایه هویتی که معماری Zero Trust برای محافظت از آن ساخته شده دیگر با دقت مشخص نمیکند چه کسی — یا چه چیزی — واقعاً در حال عمل کردن است.
اعداد ابعاد این تحول را ملموس میکنند. در محیطهای سازمانی سنتی، هویتهای ماشینی از قبل حدود ۵۰ به ۱ بیشتر از کاربران انسانی هستند. در معماریهای مبتنی بر میکروسرویس — که استاندارد هر شرکتی است که زیرساخت ابری مدرن دارد — این نسبت به سمت ۵۰۰ به ۱ میرود، طبق تحقیقات گردآوریشده توسط Cloud Security Alliance. هر یک از این هویتهای ماشینی یک اعتبارنامه، حساب سرویس یا کلید API است که میتواند نفوذپذیر شود، سوءاستفاده شود یا صرفاً فراموش شود.
اپیدمی دسترسیهای بیشازحد
مشکل عمیقتر تعداد صرف هویتهای ماشینی نیست — بلکه آن است که چه کارهایی مجاز به انجامشان هستند. طبق یافتههای Cloud Security Alliance، حدود ۹۹ درصد هویتهای غیرانسانی مجوزهایی فراتر از نیاز واقعی بار کاریشان دارند. بیشتر این تجهیز بیشازحد به دلایل پیشپاافتاده رخ میدهد: یک توسعهدهنده دسترسی گسترده میدهد تا استقراری را باز کند، هیچکس بعداً آن مجوز را بازبینی نمیکند و اعتبارنامه با امتیازات دائمی که هرگز واقعاً لازم نبوده، برای همیشه باقی میماند.
عاملهای هوش مصنوعی همین الگو را به ارث میبرند، با این تفاوت که خطرات بالاترند چون این عاملها با اختیار تفویضشده در جریانهای کاریای عمل میکنند که طوری طراحی شدهاند که عادی به نظر برسند. شرکت DTEX Systems شبیهسازیهای کنترلشدهای اجرا کرد که نشان میدهد یک عامل با دسترسی بیشازحد چقدر سریع میتواند حرکت کند: در یک آزمایش، یک عامل در عرض ۲۴ دقیقه از دسترسی مورد اعتماد به Salesforce به نوشتن پیشنویس ایمیل در Outlook ارتقا یافت. در آزمایش دیگر، دسترسی به فایلهای محلی در عرض ۱۰ دقیقه از طریق یک دستیار کدنویسی به انتقال داده آرشیوشده تبدیل شد. هیچکدام از این اقدامات هشداری فعال نکردند، چون هیچکدام قانون دسترسی صریحی را نقض نکردند — عامل دقیقاً همان کاری را میکرد که اعتبارنامهاش اجازه میداد.
۶۸ درصد نمیدانند چه کسی چه کاری کرده
اینجاست که بحران هویت به بحران ممیزی تبدیل میشود. وقتی تیمهای امنیتی یک حادثه را بررسی میکنند، اولین سؤال همیشه این است: «چه کسی این کار را کرده؟» با تنیدهشدن عاملهای هوش مصنوعی در عملیات روزانه، سهم رو به رشدی از سازمانها دیگر نمیتوانند این سؤال را بهروشنی از لاگهایشان پاسخ دهند. تشخیص یک اقدام قانونی انسانی از یک عامل خودمختار که تحت همان اعتبارنامه تفویضشده انسان عمل میکند، نیازمند تلهمتری رفتاریای است که اغلب شرکتها هرگز نساختهاند: الگوهای تایپ، حرکت ماوس، توالیهای ناوبری و زمانبندی فراخوانی API، بهجای یک نام کاربری ثابت در لاگ دسترسی.
چارچوب Zero Trust خود Anthropic برای عاملهای هوش مصنوعی سازمانی — که بهعنوان راهنمای داخلی منتشر شده و امسال در سراسر صنعت بازتاب یافته — سؤال اصلی امنیتی را بازتعریف میکند. دیگر سؤال این نیست که «آیا این ابزار مجاز به اجرا هست؟» آن سؤال همیشه با یک سیاست ثابت قابل پاسخ بود. سؤال سختتر این است که آیا سازمانی میتواند کل زنجیره را از قصد انسانی، تا اقدام عامل، تا جابهجایی داده، تا نتیجه بازسازی کند. بیشتر شرکتها در حال حاضر نمیتوانند.
چه چیزی واقعاً این را حل میکند
راهحل، فهرستهای کنترل دسترسی بیشتر نیست. تغییر به سمت چهار رویه مشخص است که هر هویت عامل را زودگذر در نظر میگیرد نه دائمی:
- اعتبارنامههای زودگذر و محدود به وظیفه. چارچوبهایی مانند SPIFFE هویتهایی صادر میکنند که پس از یک تراکنش منقضی میشوند نه اینکه برای همیشه باقی بمانند. این کار شعاع آسیب را از «هر کاری که این عامل نظری میتواند انجام دهد» به «این یک اقدام مشخص، برای این یک وظیفه مشخص» کاهش میدهد.
- موجودی خودکار هویتهای غیرانسانی. بیشتر سازمانها فهرست کاملی از هر کلید API، حساب سرویس و هویت عامل در حال اجرا در سیستمهای ابری و داخلی خود ندارند. کشف باید پیوسته باشد، نه یک ممیزی فصلی.
- تأیید مستمر رفتاری. پلتفرمهای ITDR که الگوهای غیرعادی را در میانه نشست — نه فقط هنگام ورود — رصد میکنند، عاملی را میگیرند که کاری فراتر از وظیفهاش را شروع میکند.
- تدارک دسترسی بهموقع. مجوزهای دائمی ریشه مشکل ۹۹ درصدی تجهیز بیشازحد هستند. مجوز آگاه از زمینه و محدود به زمان که با پایان وظیفه منقضی میشود، این شکاف را از طریق طراحی میبندد نه از طریق اعمال سیاست پس از وقوع.
هیچکدام از اینها عجیب نیست. معماری Zero Trust از قبل فرض کرده بود هیچ اعتماد ضمنیای برای هیچ بازیگری وجود ندارد — مشکل عاملهای هوش مصنوعی در واقع آزمونی است که آیا سازمانها واقعاً آن اصل را پیاده کردهاند یا فقط واژگانش را پذیرفتهاند. تیمهای امنیتیای که هر اعتبارنامه عامل را بهعنوان هویتی دائمی و مورد اعتماد در نظر میگیرند، همان معماریای را اجرا میکنند که پیش از وجود Zero Trust سازمانها را نفوذپذیر میکرد. تنها فرق این است که عاملها سریعتر از انسانهایی که آن اشتباه را میکردند حرکت میکنند.
این فصل چه باید کرد
اگر سازمان شما در حال استقرار عاملهای هوش مصنوعی در جریانهای کاری تولیدی است — و اغلب سازمانها همین وضعیت را دارند، چه امنیت روی آن دید داشته باشد چه نه — از مشکل موجودی شروع کنید. چیزی را که نمیبینید نمیتوانید ایمن کنید. یک بررسی کشف هویت غیرانسانی در سراسر IAM ابری، حسابهای سرویس و هر دستیار کدنویسی یا ابزار خودکارسازی با دسترسی API اجرا کنید. سپس اعتبارنامههای عامل با بالاترین امتیاز را اول به توکنهای زودگذر و محدود به وظیفه منتقل کنید. این یک تغییر، بزرگترین شعاع آسیب را با کمترین اختلال معماری میبندد و زمان میخرد تا نظارت رفتاری را پیش از آنکه حادثه بعدی این سؤال را اجباری کند، بسازید.