С навлизането на AI агентите, SOC 2 трябва да се адаптира или ще рискува да загуби значението си

Някои съответствия за сигурност (compliance) са предимно за показност, и това е най-меко казано. Преминавате през тях заради значката на уебсайта, а не за да откриете слабите си места в организацията. SOC 2 не е такъв.

Има причина екипите по обществени поръчки на вашите клиенти да го изискват. Те искат да знаят дали могат да ви поверят данните си, а съответствието със SOC 2 еженият приет начин да го докажете. Това може да не е причината за сключване на сделката, но тя нямаше да бъде сключена без него.

Живяхме според принципа „движи се бързо и руши неща“ толкова дълго, че приемаме, че иновацията по дефиниция означава чупене на неща. Само че когато става въпрос за AI агенти, това не е толкова просто поради начина, по който те използват съществуващата инфраструктура.

Разгледайте ред от преглед на достъпа (access review). Производствена база данни, 10:03 сутринта, 50 заявки от името на старши инженер. Правилно сте направили, че сте го одобрили; всичко съответства точно на контрола. Само че този инженер по това време е пиел кафе, докато неговият агент е качвал актуализации в производствената среда.

Технологично неутралните критерии на SOC 2 могат да покрият AI агентите, но те не изискват изрично от организациите или одиторите да третират агентите като отделен клас идентичност. Това дискреционно право позволява на AI агентите да добавят риск към средата, без да се проваля нито един контрол.

Ако SOC 2 ви позволява да се разминете с това, рамката трябва или да се промени, или да рискува да остарее.

Какво се случва

По време на одит ви тестват за две неща: дали контролът отговаря на критерий за съответствие и дали е работил през целия период на преглед. Но какво ще кажете за тестване дали дизайнът все още е уместен?

Понякога, когато има промяна, даден тест става по-труден. Но често той просто се изпразва от съдържание, защото активността се случва на друго място, което ни води до критериите за доверителни услуги (Trust Services Criteria) в SOC 2. Не че са погрешни, но четири от основните допускания вече не са валидни и в резултат на това три контрола се обезсмислят. Допусканията са:

• Някой одобрява акаунт, преди той да бъде създаден.
• Всеки акаунт има известен собственик.
• Името в логовете идентифицира конкретния субект.
• Това, което даден акаунт може да прави, ви казва какво се очаква да прави.

Четири допускания, които вече не са валидни (CC6.1–CC6.3)

Всеки критерий за достъп се основава на допускания относно това какво контролира. И докато субектите бяха хора, тези допускания бяха достатъчно сигурни, за да не се налага никой да ги записва. При агентите това вече не е така.

1. Някой одобрява акаунт, преди той да бъде създаден.

SOC 2 изисква да регистрирате и одобрите потребител, преди да му предоставите възможности за вход. За хората това означава някой да поиска вход, а друг да го одобри и регистрира. Агентите, от друга страна, са подобни на страничен ефект от някое по-голямо действие.

Това може да бъде програмист, който натиска „Allow“ на OAuth екран, API ключ, който е поставен в конфигурационен файл, или MCP сървър, добавен към JSON файл. Никой не е бил помолен да одобри създаването на агент; то просто се е случило.

2. Всеки акаунт има известен собственик.

В процедурите за преглед на достъпа конкретно посочено лице потвърждава, че преглежданият акаунт все още трябва да има достъп. За агентите е обичайно да нямат посочен собственик. Трябва да сглобите това постфактум от косвени доказателства и предположения, като проучите артефактите на агента, свързани с хора, като ключове и хранилища (repos).

В голям мащаб собствеността върху агентите е по-скоро предположение, отколкото детерминиран запис. SOC 2 не отчита това: предполагаемият собственик и регистрираният собственик изглеждат по един и същи начин в електронната таблица за преглед.

3. Името в логовете идентифицира конкретния субект.

Това е скъпоструващото допускане, което вече споменахме в нашия пример от 10:03 сутринта. Често агентите работят със заемки на идентификационни данни: активна сесия, токен за разработка или сервизен акаунт. Това е лицето, което ще се появи във вашите логове и във вашия преглед на достъпа. Това ще премине прегледа, докато напълно пренебрегва разликите в сигурността между хората и агентите.

От една страна, прегледът на достъпа ще бъде напълно точен. От друга страна, той няма да ви каже това, което всъщност трябва да знаете. Скорошно проучване с Cloud Security Alliance установи, че повече от две трети от организациите не могат ясно да разграничат действията на AI агентите от тези на хората.

4. Това, което даден акаунт може да прави, ви казва какво се очаква да прави.

Минималните привилегии (least privilege) работят при допускането, че даден акаунт има постоянна роля и списъкът с неща, които може да прави, ни казва за какво е предназначен. И за хората това обикновено е правилно. Освен ако вашият главен изпълнителен директор не иска да бъде администратор навсякъде, нивата на достъп са съобразени с работата.

При агентите достъпът ограничава радиуса на щетите (blast radius), но не ви казва какво се очаква да прави агентът във всеки един момент. Това зависи от получените инструкции, усвоения контекст и решенията, които агентът взема. И така, проверката на разрешенията ви дава възможно най-широкия изглед за това какво може да се случи, без да предоставя контекст за действията на агента.

Отвъд отмятането на кутийките

Вашият SOC 2 доклад казва, че контролите са работили, но никога не казва какво са пропуснали. Агентите работят със заети идентификационни данни, без собственик и без превключвател за изключване.

Token Security открива всеки агент, присвоява идентичност и коригира достъпа му спрямо задачата, за която е създаден.

Три контрола, които преминават, без да покриват нищо

Ето как допусканията, които споменахме, намаляват ефективността на три контрола от SOC 2.

Нищо никога не казва, че даден агент трябва да спре (CC6.3)

Всеки SOC 2 одит тества прекратяването на достъпа (offboarding) и за служителите хора компаниите са станали много добри в това. HR системите, IdP и SaaS системите работят в тандем, когато HR отделът маркира дадено лице за отстраняване, като по този начин упражнява неоспоримата си власт. Дори доказателствата се генерират сами.

Няма HR системи за агенти. Няма централизиран, общоприет орган, който е в състояние да каже, че даден агент трябва да спре. Това не е счупен контрол, а такъв, който просто не обхваща агентите и идентичностите, които те използват.

Това, което влошава нещата, е, че агентите са предимно свързани с хора, така че когато дадено лице напусне, агентите, настроени от негово име, могат да продължат да работят с помощта на OAuth права или API ключове, освен ако този сценарий не е предвиден.

Прегледът на доставчиците започва от покупката (CC9.2)

SOC 2 управлява процесите, свързани с отношенията с доставчиците. Сключвате договор, оценявате, събирате доклад и го преглеждате ежегодно; това работи добре за доставчици, които идват с поръчка за покупка. Един MCP сървър е доставчик във всяко едно отношение: той получава вашите данни, действа от ваше име и изпълнява код, който никой в компанията не чете.

Вместо поръчка за покупка и споразумение за данни, той пристига в конфигурационен файл. Често от другата страна изобщо няма компания.

Около три от десет имена в нашия регистър не могат да бъдат свързани със съществуваща компания. Това е цифра за пространството от имена, а не за конкретна среда, но тя показва основен проблем със съответствието за много MCP-та: не можете да получите SOC 2 доклад от безименен доставчик.

Същият проблем се появява и при AI агентите. Когато ги открием на компютрите на служителите, само някои от тях могат безопасно да бъдат блокирани; останалите се задържат, тъй като името на програмата може да съвпадне с нещо, създадено от клиента. Идентифицирането на агент е по-трудно от идентифицирането на човек. Ако сте готови да проучите контролите за сигурност на AI агенти, резервирайте демо с Token Security, за да видите какво се крие във вашата среда.

Разделение на задълженията между две екземпляра на една и съща политика (CC8.1)

При внедряване на управлението на промените, промените трябва да бъдат оторизирани, тествани, одобрени и внедрени. В повечето внедрявания авторът и одобряващият трябва да бъдат различни хора поради разделението на задълженията.

Когато агент извърши промяна и втори агент я прегледа, разделението е само номинално, въпреки че са участвали две самоличности.

Междувременно оторизацията се премести извън обхвата на одита. Решението за промяната може да се случи в подкана (prompt), в инструмент, който не се появява никъде в описанието на системата. Единственото доказателство е заявка за изтегляне (pull request).

Най-силният аргумент срещу всичко това

Заслужава да се отбележи, че нищо в Trust Services Criteria не казва „човек“. CC6.2 използва „вътрешни и външни потребители“, докато CC6.1 използва „защитени информационни активи“. Критериите са написани така, че да избягват назоваването на технологии и да описват резултати, а не методи. Така че няма причина да не се покриват агентите.

Третирате акаунтите на машините като потребители, вписвате агентите в описанията на системата и ги тествате правилно. Това е нещо, което се случва в реалния свят.

Въпреки това, като се има предвид настоящото ниво на смущения, двусмислието може да не е достатъчно. Без конкретни споменавания на агенти в критериите, това, което се покрива, се договаря между вас и вашия одитор.

И двамата имате причина да предпочитате обхват, който е лесен за доказване. Докато можете да оставяте агентите извън обхвата, без да записвате нито едно изключение, някои хора ще го правят.

Какво никога не е означавал чистият доклад

Чистият доклад означава, че вашите контроли са се държали по начина, по който сте казали, че ще се държат, а не че описанието е било пълно. Пролуката се използваше да бъде достатъчно малка, за да се игнорира, но вече не е.

Сега е напълно възможно да притежавате квалифициран доклад от тип 2 (Type 2) и да не можете да отговорите, в деня на издаването му, на четири въпроса за вашата собствена производствена среда.

SOC 2 не греши. То е точно за един свят, който се е променил. Така че третирайте акаунтите на машините като потребители и стигнете по-далеч, отколкото иска докладът. Списъкът с разрешения може да ви каже до какво има достъп даден агент; той не ви казва за какво е предназначен да прави този агент.

Затварянето на тази пролука е това, което имаме предвид под сигурност, базирана на намерения (intent-based security): вие установявате какво е предназначен да прави всеки агент, след което правите достъпа му да съответства. Идентичността е слоят, където този контрол действително се държи, защото той обхваща всяка система, до която агентът се докосва.

Докладът няма да се промени, но тези контроли са там с причина, а атакуващите не се интересуват от контролни списъци.

Всяка среда има ред за преглед на достъпа, който изглежда одобрен, но не казва нищо. Token Security ви показва агента зад него: кой го притежава, чии идентификационни данни използва и дали това, до което има достъп, все още съответства на това, за което е предназначен да прави.

Резервирайте демо и ще преминем през вашата среда заедно.

Спонсорирано и написано от Token Security.