В това интервю за Help Net Security Винай Такър, главен технологичен директор на KloudStax, обяснява как да се зададат самоличност, идентификационни данни и мрежови ограничения за AI агенти. Той твърди, че агентите трябва да работят под собствена самоличност, като самоличността на човека се прикачва, когато действат от нечие име. Той разглежда къде прокси сървърите за идентификационни данни се провалят, какво трябва да гласят първите десет реда от политиката за команди на един агент за програмиране и как да се спре изтичането на данни чрез инсталиране на пакети или URL параметри. Той също така описва как червените екипи (red teams) трябва да тестват внедряванията на агенти.
Нито една от двете крайности. Решаващият въпрос е дали агентът върши работа за бизнеса, или изпълнява задача за конкретен човек.
Ако върши работа за бизнеса, той получава собствена самоличност с права, ограничени до тази работа. Ако изпълнява задача за един човек, той отново получава собствена самоличност, но всяка заявка носи и самоличността на човека, който я е поискал. Тогава агентът може да прави само това, което е разрешено и на двамата, а в логовете се записват и двете имена. Директното заемане на потребителския профил на човека е вариантът, който бих изключил, защото действията на агента стават неразличими от тези на човека и той наследява всичко, до което този човек има достъп.
Агент за триаж на тикети върши работа за бизнеса. Той работи с тикетите на всички клиенти и не принадлежи на нито един конкретен служител, затова функционира от свое име, с права за четене на опашката и права за запис само върху маршрутизирането и етикетите.
Инфраструктурен агент обикновено изпълнява задача за даден инженер, така че носи самоличността на този инженер заедно със своята собствена. Но предлагането на промяна и нейното прилагане трябва да бъдат отделни права. Агентът може да отвори промяната и да изпълни плана. Прилагането ѝ минава през същия преглед и конвейер (pipeline), през които би минала и промяна, направена от човек.
Никога не давайте на агент дългосрочна тайна (long-lived secret). Отвъд това, въпросът обединява две решения, които си струва да бъдат разграничени: колко дълго е валидна дадена идентификационна данна и дали агентът изобщо някога я съхранява.
Краткосрочните идентификационни данни ограничават времето, през което една изтекла данна остава полезна. Прокси сървър, който прикачва идентификационната данна в момента на повикването, ограничава възможността тя изобщо да изтече, тъй като агентът никога не я вижда. Двете мерки работят заедно, а най-надеждните конфигурации правят и двете: проксито проверява самоличността на агента, получава краткосрочна идентификационна данна, ограничена до това конкретно повикване, и я прикачва на излизане.
За услуги, които приемат само статични API ключове, проксито е единственият начин ключът да се държи далеч от агента. Ако даден агент все пак държи директно краткосрочен токен, проверете какво се намира до него. Токен за опресняване (refresh token) в същата среда е просто дългосрочна тайна под друго име. Още по-добре е да обвържете токена с машината или контейнера, който го е заявил, така че ако копие от него изтече, то да е безполезно навсякъде другаде.
Нито един от двата контрола не спира един компрометиран агент да злоупотреби с достъпа, който легитимно притежава, и точно тук прокситата се провалят. Прокси, което прикачва идентификационни данни към всяка заявка, направена от агента, е „объркан заместник“ (confused deputy), чакащ инструкции. Такова, което препраща токена на извикващия надолу по веригата, превръща всяка стъпка (hop) в място, откъдето той може да бъде откраднат. Една споделена идентификационна данна зад проксито прави всеки агент да изглежда идентичен в логовете. А трезор за тайни (vault) на същия хост като агента не е защитил тайната, а само я е преместил. Проксито не премахва правомощията на агента. То ги концентрира, затова се нуждае от индивидуална самоличност за всеки агент, минимални привилегии и списък с разрешени дестинации (allowlist), както всичко останало.
Кратък списък със строги забрани е разумна първа стъпка за екип, който тепърва започва. За агент с достъп до терминал обаче бих написал политиката като списък с разрешени действия (allowlist), защото един агент за програмиране винаги ще намери командата, която не сте се сетили да забраните. Също така бих се уверил, че всеки ред се налага от управляващата среда (harness), вместо да се разчита на модела да се държи правилно. Общо взето:
1. Агентът работи в рамките на едно изтеглено хранилище (checked-out repository) в среда за еднократна употреба и не може да чете или записва нищо извън него. 2. Изпълнява само одобрени команди: инструментите за компилиране (build), тестване, статичен анализ (lint) и форматиране на проекта, git само за четене и редакции на файлове вътре в хранилището. За всичко останало първо пита. 3. В неговата среда не се съхраняват никакви идентификационни данни. Всичко, което се нуждае от такива, минава през брокер, който агентът не може да чете. 4. Не може да отваря файлове, съдържащи тайни, като например .env файлове, SSH ключове или файлове с облачни идентификационни данни, дори ако такъв се появи в работното пространство. 5. Мрежовият достъп е изключен, освен към вътрешното огледално хранилище за пакети (package mirror) и конкретните хостове, от които се нуждае този проект. 6. Пакетите идват само от вътрешното хранилище за артефакти, а добавянето на нова зависимост изисква намеса на човек. 7. Може да прави комити (commit) в собствения си клон (branch) и да отваря заявка за сливане (pull request). Не може да качва промени (push) в защитени клонове, да прави принудително качване (force-push) или да слива (merge). 8. Всяко действие, което променя споделена инфраструктура или данни, като например прилагане на промени (apply), внедряване (deploy), миграция или изтриване, спира и пита. 9. Не може да повишава привилегиите си или да променя собствената си политика, куки (hooks) или конфигурация. 10. Всяка команда се записва в лог със самоличността на агента и задачата, която я е задействала, а лимит за разходи или време за изпълнение прекратява сесията при достигането му.
Няколко от тези правила изобщо не би трябвало да зависят от политиката за команди. Защитата на клоновете принадлежи към системата за контрол на версиите, мрежовите правила – към защитната стена, а достъпът до идентификационни данни – към системата за управление на самоличността, така че те да действат дори ако агентът намери начин да заобиколи собствената си политика. Нищо от това не е ново.
Това е дисциплината, която вече прилагаме към CI конвейерите, приложена към нещо, което само пише своите команди.
Бих стартирал всеки агент без мрежов достъп и бих надграждал на базата на това, с което разполага. Тестът, който използвам, е дали един-единствен агент комбинира лични данни, съдържание от хора, които не контролирате, и начин за изпращане на данни навън. При наличието и на трите, един компрометиран имейл или тикет е достатъчен за изнасяне на данни извън компанията. Изследователски агент, който чете отворената мрежа, но не вижда нищо вътрешно, може да има сравнително широк обхват. Агент за поддръжка, който чете клиентски имейли редом с клиентски записи, изобщо не трябва да има отворен изходящ път, а отговорите му трябва да минават през канал, който някой контролира.
Когато даден агент все пак се нуждае от мрежата, бих забранил достъпа по подразбиране, бих изброил точни хостове вместо заместващи символи (wildcards) и бих наложил това ограничение на място, което агентът не може да редактира. Инсталирането на пакети е мястото, където повечето списъци с разрешени дестинации тихомълком се провалят, защото публичните регистри в крайна сметка попадат в списъка. От години разполагаме с вътрешни хранилища за артефакти точно поради тази причина. Насочването на агентите към вашето вътрешно хранилище вместо към публичния регистър затваря по-голямата част от тази пролука и ви дава едно централно място, където да задържате нови версии или пакети, които никой не е прегледал.
Параметърът в URL адреса е по-трудният случай и не мисля, че мрежата го решава. Обикновена GET заявка към одобрен хост може да пренася данни в низа си за заявка (query string), а одобряването на един хост означава да се доверяваш на платформата, а не на всичко, което хората могат да публикуват в нея. Инспекцията си струва заради видимостта, но не бих разчитал на нея за улавяне на инжектирани инструкции, тъй като на атакуващия му трябва само един вариант, който филтърът пропуска. Повече вярвам в дизайна: щом един агент е прочел недоверено съдържание, не би трябвало да може да изпраща данни навън или да предприема действие с последствия, без някой да го одобри.
Бих накарал червен екип да тества системата около модела, а не самия модел. Приемете, че рано или късно някоя инжекция ще сработи, и измерете какво може да направи компрометираният агент оттам нататък: докъде е стигнал, кои контроли са издържали и колко време е отнело на някого да забележи. Известните пътища, като четене на собствените му идентификационни данни, достъп до хост извън списъка с разрешени или редактиране на собствената му конфигурация, трябва да се изпълняват като автоматизирани тестове всеки път, когато някой добави инструмент или конектор, защото тогава експозицията се променя. Така човешкият червен екип остава свободен да търси пътищата, за които още никой не е написал тест.
При учението тип „tabletop“ бих внимавал кой инцидент репетирате. Най-скъпият инцидент с агенти, който съм виждал тази година, беше когато агенти от акаунта на един инженер похарчиха около 500 000 долара за облачна инфраструктура за около 36 часа. Той беше шумен и сметката в крайна сметка го издаде. Компрометираният агент е създаден да мълчи: чете данните, които винаги чете, и извиква системите, които има право да извиква, така че репетирането на шумния случай внушава грешни инстинкти.
Вместо това бих го провел на етапи. Агент за поддръжка обработва тикет със скрити инструкции и през следващата седмица записи на други клиенти напускат системата по малко, вътре в отговорите му към атакуващия. Разкривайте по една улика: оплакване от клиент, после странна закономерност в логовете на агента, после самият отровен тикет. На всеки етап питайте залата какво би направила само с това, което знае. Могат ли да свържат активността с един агент? Могат ли да я спрат, без да спрат поддръжката? Кой решава и колко бързо?
След това задайте въпроса, на който повечето екипи не могат да отговорят: след като прекратите сесията, откъде знаете, че проблемът е изчезнал? Ако атакуващият е накарал агента да запише инструкция в паметта си, в споделен конфигурационен файл или в шаблон за отговор, следващата сесия я прихваща и започва отначало. Възстановяването означава почистване на всичко, в което агентът може да записва, а не само отнемане на идентификационните му данни.
Изтеглете: Ръководство на ИТ и сигурността за внедряване на ИИ
- CXO
- киберсигурност
- мнение
- стратегия
- съвети