با ظهور عوامل هوش مصنوعی، SOC 2 باید تطبیق یابد یا خطر بی ربط باشد
عوامل هوش مصنوعی می توانند از طریق اعتبار انسانی عمل کنند و اقداماتی را انجام دهند که کنترل های موجود SOC 2 ممکن است از فعالیت های انسانی متمایز نشوند. Token Security توضیح می دهد که چرا SOC 2 باید برای رسیدگی به شکاف های امنیتی ایجاد شده توسط هویت های عامل سازگار شود. [...]
برخی از انطباق ها بیشتر برای نمایش است و آن خیریه است. شما آن را برای نشان وب سایت مرور می کنید، نه برای یافتن نقاط ضعف در سازمان خود. SOC 2 اینطور نیست.
دلیلی وجود دارد که تیم های تدارکات مشتریان شما آن را درخواست می کنند. آنها می خواهند بدانند که آیا می توانند اطلاعات خود را به شما اعتماد کنند یا خیر، و مطابقت با SOC 2 روش پذیرفته شده برای نشان دادن آن است. ممکن است دلیل بسته شدن یک معامله نباشد، اما آن معامله بدون آن بسته نمی شد.
ما آنقدر طولانی زندگی کردهایم که «سریع حرکت کن و چیزها را بشکن» که فرض میکنیم اختلال باید به معنای شکستن چیزها باشد. فقط وقتی صحبت از عوامل هوش مصنوعی می شود، به دلیل استفاده از زیرساخت های موجود، کار چندان آسانی نیست.
یک ردیف بررسی دسترسی را در نظر بگیرید. پایگاه داده تولید 10:03 صبح 50 پرس و جو به نام مهندس ارشد. شما حق داشتید که آن را تایید کردید. همه چیز به طور دقیق با کنترل مطابقت دارد. فقط آن مهندس در آن زمان قهوه می گرفت، در حالی که نماینده آنها به روز رسانی را برای تولید فشار می آورد.
معیارهای فناوری خنثی SOC 2 میتوانند عوامل هوش مصنوعی را پوشش دهند، اما به طور صریح از سازمانها یا حسابرسان نمیخواهند که با نمایندگان بهعنوان یک کلاس هویتی متمایز رفتار کنند. این اختیار به عوامل هوش مصنوعی اجازه می دهد تا بدون شکست در یک کنترل، خطر را به محیط اضافه کنند.
اگر SOC 2 به شما اجازه می دهد که از این موضوع خلاص شوید، چارچوب یا باید تغییر کند یا خطر قدیمی شدن را دارد.
در طول ممیزی، شما روی دو چیز آزمایش میشوید: اینکه آیا کنترل با معیار انطباق مطابقت دارد یا خیر، و اینکه آیا در طول دوره بررسی عمل کرده است. اما در مورد آزمایش اینکه آیا طرح هنوز مرتبط است یا خیر، چطور؟
گاهی اوقات، زمانی که یک جابجایی وجود دارد، یک آزمون سخت تر می شود. اما اغلب، فقط خالی می شود، زیرا فعالیت در جای دیگری اتفاق می افتد، که ما را به معیارهای خدمات اعتماد در SOC 2 می رساند. اینطور نیست که آنها اشتباه می کنند، اما چهار مورد از فرضیات رایج دیگر قابل اجرا نیستند و در نتیجه، سه کنترل از بین می روند. مفروضات عبارتند از:
هر معیار دسترسی بر اساس فرضیاتی در مورد آنچه که کنترل می کند است. و تا زمانی که بازیگران انسان بودند، این فرضیات به اندازه کافی امن بودند که نیازی به نوشتن آنها نبود. در مورد ماموران دیگر اینطور نیست.
1. شخصی یک حساب را قبل از ایجاد آن تأیید می کند.
SOC 2 از شما می خواهد که قبل از دادن قابلیت های ورود، یک کاربر را ثبت و تایید کنید. برای انسانها، این بدان معناست که شخصی درخواست ورود به سیستم را میدهد، و شخص دیگری آن را تأیید کرده و ثبت میکند. از سوی دیگر، عامل ها شبیه به یک اثر جانبی یک عمل فراگیر هستند.
این می تواند یک توسعه دهنده باشد که روی «Allow» روی صفحه OAuth کلیک می کند، یک کلید API که در یک فایل پیکربندی جایگذاری شده است، یا یک سرور MCP که به فایل JSON اضافه شده است. از هیچکس خواسته نشد که ایجاد یک عامل را تایید کند. این اتفاق افتاد
در روشهای بررسی دسترسی، یک انسان با نام تأیید میکند که حساب بازبینی شده همچنان باید دسترسی داشته باشد. برای نمایندگان، معمول است که صاحب نامی نداشته باشند. شما باید آن را پس از واقعیت، از روی شواهد و حدسهای غیرواقعی، با بررسی مصنوعات عامل مرتبط با انسانها، مانند کلیدها و مخازن، کنار هم بگذارید.
در مقیاس، مالکیت عامل یک حدس تحصیل شده است تا یک سابقه قطعی. SOC 2 این را در نظر نمی گیرد: یک مالک حدس زده و یک مالک ثبت شده در صفحه گسترده مرور یکسان به نظر می رسند.
این گران قیمت است که قبلا در مثال 10:03 صبح به آن اشاره کردیم. اغلب، نمایندگان با اعتبارنامه های قرض گرفته شده کار می کنند: یک جلسه ورود به سیستم، یک نشانه توسعه دهنده، یا یک حساب خدمات. این شخصی است که در گزارش های شما و در بررسی دسترسی شما ظاهر می شود. این بررسی را پشت سر می گذارد، در حالی که کاملا تفاوت های امنیتی بین افراد و عوامل را نادیده می گیرد.
از یک طرف، بررسی دسترسی کاملا دقیق خواهد بود. از سوی دیگر، آنچه را که واقعا باید بدانید به شما نمی گوید. مطالعه اخیر با Cloud Security Alliance نشان داد که بیش از دو سوم سازمان ها نمی توانند به وضوح اقدامات عامل هوش مصنوعی را از اقدامات انسانی تشخیص دهند.
4. کاری که یک حساب میتواند انجام دهد به شما میگوید که انتظار میرود چه کاری انجام دهد.
حداقل امتیاز با این فرض عمل میکند که یک حساب کار دائمی دارد، و فهرست کارهایی که میتواند انجام دهد به ما میگوید برای چه کاری است. و برای مردم، این معمولا درست است. مگر اینکه مدیر عامل شما بخواهد در همه جا مدیر باشد، سطوح دسترسی متناسب با کار است.
برای عوامل، دسترسی شعاع انفجار را محدود می کند، اما به شما نمی گوید که در هر لحظه از عامل انتظار می رود چه کاری انجام دهد. این به دستورالعمل های دریافت شده، زمینه جذب شده و تصمیماتی که عامل می گیرد بستگی دارد. بنابراین، بررسی مجوزها به شما گستردهترین دید ممکن را از آنچه میتواند بدون ارائه زمینه برای اقدامات عامل رخ دهد، میدهد.
گزارش SOC 2 شما میگوید که کنترلها کار کردهاند، اما هرگز نمیگوید چه چیزی را از دست دادهاند. نمایندگان با اعتبارنامه های قرض گرفته شده، بدون مالک و بدون کلید خاموش کار می کنند.
Token Security هر عاملی را پیدا میکند، هویتی را تعیین میکند و دسترسی آن را به کاری که برای انجام آن ساخته شده است اصلاح میکند.
در اینجا آمده است که چگونه مفروضاتی که ذکر کردیم، اثربخشی سه کنترل SOC 2 را کاهش می دهد.
هر حسابرسی SOC 2 خارج شدن از هواپیما را آزمایش می کند، و برای کارکنان انسانی، شرکت ها در آن بسیار خوب شده اند. سیستمهای منابع انسانی، سیستمهای IdP و SaaS زمانی کار میکنند که بخش منابع انسانی یک فرد را برای خارج شدن از هواپیما علامتگذاری میکند و در نتیجه قدرت غیرقابل انکار خود را اعمال میکند. حتی شواهد خود را می نویسد.
هیچ سیستم منابع انسانی برای نمایندگان وجود ندارد. هیچ نهاد متمرکز و مورد توافقی وجود ندارد که بتواند بگوید یک نماینده خاص باید متوقف شود. این یک کنترل شکسته نیست، بلکه کنترلی است که فقط عوامل و هویتی که آنها استفاده می کنند را در بر نمی گیرد.
چیزی که این وضعیت را بدتر میکند این است که عاملها عمدتا به انسانها گره میخورند، بنابراین وقتی فردی ترک میکند، ممکن است عواملی که به نام او تنظیم شدهاند با استفاده از کمکهای OAuth یا کلیدهای API به کار خود ادامه دهند، مگر اینکه این سناریو در نظر گرفته شود.
SOC 2 فرآیندهای مربوط به روابط فروشنده را مدیریت می کند. شما قرارداد می بندید، ارزیابی می کنید، گزارشی را جمع آوری می کنید و سالانه آن را بررسی می کنید. برای فروشندگانی که با سفارش خرید وارد می شوند، به خوبی کار می کند. سرور MCP از هر نظر یک فروشنده است: داده های شما را دریافت می کند، از طرف شما عمل می کند و کدهایی را اجرا می کند که هیچ کس در شرکت نمی خواند.
به جای سفارش خرید و قرارداد داده، در یک فایل پیکربندی وارد می شود. اغلب، اصلا شرکتی در آن طرف وجود ندارد.
حدود سه نام از هر ده نام موجود در رجیستری ما با یک شرکت موجود مطابقت ندارد. این یک رقم فضای نامگذاری است، نه یک محیط خاص، اما به یک مسئله انطباق اساسی برای بسیاری از MCPها اشاره می کند: شما نمی توانید گزارش SOC 2 را از یک فروشنده ناشناس دریافت کنید.
همین مشکل برای عوامل هوش مصنوعی ظاهر می شود. وقتی آنها را در ماشین های کارمند پیدا می کنیم، فقط برخی از آنها می توانند مسدود شوند. بقیه به تعویق افتاده اند زیرا نام برنامه می تواند با چیزی که مشتری ساخته است برخورد کند. شناسایی یک عامل سخت تر از شناسایی یک شخص است. اگر آماده کاوش در کنترلهای AI Agent Security هستید، یک نسخه نمایشی با امنیت Token رزرو کنید تا ببینید چه چیزی در محیط شما پنهان شده است.
هنگام اجرای مدیریت تغییر، تغییرات باید مجاز، آزمایش، تایید و اجرا شوند. در اکثر اجراها به دلیل تفکیک وظایف، نویسنده و تایید کننده باید افراد متفاوتی باشند.
هنگامی که یک عامل تغییری ایجاد می کند و یک نماینده دوم آن را بررسی می کند، جدایی فقط اسمی است، حتی اگر دو هویت در آن دخیل باشد.
در همین حال، مجوز از محدوده ممیزی خارج شد. تصمیم در مورد تغییر می تواند در یک اعلان اتفاق بیفتد، در ابزاری که در هیچ کجای توضیحات سیستم ظاهر نمی شود. تنها مدرک، درخواست کشش است.
شایان ذکر است که هیچ چیز در معیارهای خدمات اعتماد "انسان" را بیان نمی کند. CC6.2 از "کاربران داخلی و خارجی" استفاده می کند، در حالی که CC6.1 از "دارایی اطلاعات محافظت شده" استفاده می کند. معیارها برای اجتناب از نامگذاری فناوری ها و توصیف نتایج به جای روش ها نوشته شده اند. بنابراین دلیلی برای پوشش ندادن نمایندگان وجود ندارد.
شما با حسابهای ماشینی بهعنوان کاربر رفتار میکنید، عوامل را در توضیحات سیستم فهرست میکنید و آنها را به درستی آزمایش میکنید. این چیزی است که در دنیای واقعی اتفاق می افتد.
گفته می شود، با توجه به سطح فعلی اختلال، ابهام ممکن است کافی نباشد. بدون ذکر خاصی از نمایندگان در معیارها، آنچه تحت پوشش قرار می گیرد بین شما و حسابرس شما توافق می شود.
هر دوی شما دلیلی برای ترجیح دامنه ای دارید که اثبات آن آسان است. تا زمانی که بتوانید نمایندگان را بدون ثبت یک استثنا کنار بگذارید، برخی افراد این کار را انجام می دهند.
یک گزارش تمیز به این معنی است که کنترلهای شما همانطور که گفتهاید رفتار میکنند، نه اینکه توضیحات کامل شده است. شکاف قبلا به اندازهای کوچک بود که بتوان نادیده گرفت، اما دیگر نیست.
اکنون کاملا امکان پذیر است که یک گزارش نوع 2 فاقد صلاحیت داشته باشید و نتوانید در روز صدور آن به چهار سؤال در مورد محیط تولید خود پاسخ دهید.
این نماینده هرگز ثبت نشد، بنابراین چیزی گم نشده بود
این تصمیم در یک جریان سریع و بالادست شواهد اتفاق افتاد
اعتبار یک کارمند واقعی، با نقش تایید شده
Offboarding به درستی اجرا شد و هرگز نمایندگان را علامت گذاری نکرد
SOC 2 اشتباه نیست. در مورد جهانی که حرکت کرده است دقیق است. بنابراین حسابهای ماشینی را بهعنوان کاربر در نظر بگیرید و فراتر از آنچه گزارش میخواهد بروید. لیست مجوز می تواند به شما بگوید که یک نماینده به چه چیزی می تواند دسترسی داشته باشد. به شما نمی گوید که یک نماینده برای انجام چه کاری وجود دارد.
منظور ما از امنیت مبتنی بر هدف از بین بردن این شکاف است: شما تعیین می کنید که هر عامل قرار است چه کاری انجام دهد، سپس دسترسی آن را مطابقت می دهید. هویت لایه ای است که در واقع آن کنترل در آن قرار دارد زیرا هر سیستمی را که عامل لمس می کند را در بر می گیرد.
گزارش تغییر نخواهد کرد، اما این کنترل ها به دلایلی وجود دارند و مهاجمان به چک لیست ها اهمیت نمی دهند.
هر محیطی دارای یک خط بررسی دسترسی است که به نظر تایید شده است اما چیزی نمی گوید. Token Security عاملی را که در پشت آن قرار دارد به شما نشان میدهد: چه کسی مالک آن است، از اعتبار چه کسی استفاده میکند، و اینکه آیا آنچه میتواند به آن برسد همچنان با آنچه که باید انجام دهد مطابقت دارد یا خیر.
یک نسخه نمایشی رزرو کنید و ما با هم در محیط شما قدم می زنیم.
متن اصلی (انگلیسی)
With the Rise of AI Agents, SOC 2 Should Adapt or Risk Irrelevance
AI agents can operate through human credentials and take actions that existing SOC 2 controls may not distinguish from human activity. Token Security explains why SOC 2 needs to adapt to address the security gaps created by agent identities. [...]