Короткий ответ
#Три предложения на одном столе
Эту сцену я видел много раз, и она почти не меняется. У основателя на столе три предложения про безопасность, и все три пришли за одну неделю.
Первое принёс подрядчик: годовая подписка на платформу управления политиками для ИИ-агентов. В презентации есть слово «enterprise» и схема из двенадцати блоков. Второе прислал знакомый инвестора: тест на проникновение перед раундом, потому что «так принято». Третье сказал собственный технический руководитель: до раунда ничего не трогаем, у нас четыре человека и горит релиз.
Все три предложения звучат разумно, и ни одно не сравнить с другими. У платформы есть цена и нет ответа на вопрос, что именно она предотвратит у компании из четырёх человек. У теста есть отчёт на выходе и нет ответа, кто будет чинить найденное. У «ничего не трогаем» есть нулевая строка в бюджете и нет оценки, сколько стоит один плохой вторник.
Основатель в этот момент обычно делает одно из двух. Либо покупает самое солидное на вид, либо откладывает всё. Оба решения принимаются без главного числа, и об этом числе вся статья.
#Вопрос, который упорядочивает список
Вопрос «сколько безопасности нам нужно» не имеет ответа. Безопасность не продаётся килограммами, и после любой покупки можно купить ещё. Ответ есть у другого вопроса.
Главный вопрос
Какой максимальный ущерб останется, если завтра ошибётся агент, сотрудник или подрядчик, а базовые ограничения уже стоят? Ущерб считают в деньгах, в данных клиентов и в днях простоя, а не в баллах.
У этого вопроса есть три полезных свойства. Первое: он переводит разговор с инструментов на последствия, а последствия основатель понимает лучше любого инженера. Второе: он сразу сортирует предложения. Мера, которая уменьшает максимальный ущерб, стоит выше меры, которая добавляет строчку в отчёт. Третье: он показывает, где можно честно остановиться. Если после базовых ограничений худший день стоит компании одного неприятного письма и двух часов работы, платформа за годовой бюджет на маркетинг ничего к этому не добавит.
Откладывать сам вопрос дорого, и цена копится тихо. Каждый месяц к системе подключают ещё один инструмент, выдают ещё один ключ «на время», заводят ещё одного подрядчика под общей учётной записью. Максимальный ущерб растёт вместе с продуктом, а бюджет на него остаётся нулевым, потому что его никто не считал. Через год вопрос всё равно зададут. Задаст его крупный клиент в анкете, инвестор на проверке или инцидент.
#За что платить сейчас
Есть короткий список мер, которые стоят дней, а не месяцев, и ограничивают самый крупный ущерб. На них не экономят при любом размере компании. Ни одна из них не требует покупки, все они делаются в собственном серверном коде и в настройках того, что у вас уже есть.
-
Минимальные права для каждого агента и сервиса
Отдельная учётная запись на каждый сценарий, доступ только к тем объектам, которые нужны этому сценарию. Агент поддержки видит обращение и заказы одного клиента, а не таблицу клиентов целиком.
Что это ограничивает: размер любой ошибки. Общий административный ключ превращает мелкую ошибку в максимальную.
-
Разделение сред и ролей
Разработка, тест и рабочая система живут с разными ключами и разными базами. Человек или агент, который пишет код, не имеет рабочих секретов и не выкатывает сам.
Что это ограничивает: путь от эксперимента до данных клиентов. Он перестаёт быть одним шагом.
-
Лимиты на объём и сумму
Потолок на число операций в час, на сумму возврата, на число писем, на размер выгрузки. Лимит проверяет сервер, а не инструкция для модели.
Что это ограничивает: массовость. Большинство громких историй это одна ошибка, применённая к тысяче объектов.
-
Журнал действий
Кто, когда, каким инструментом и над каким объектом. Журнал пишется туда, где его не может изменить сам агент.
Что это ограничивает: время до обнаружения и стоимость разбора. Без журнала инцидент расследуют неделями и по догадкам.
-
Подтверждение опасных действий
Деньги, письма наружу, удаление и изменение прав проходят через человека. В запросе на подтверждение видно, что именно произойдёт.
Что это ограничивает: необратимое. Это единственный класс действий, где вторая пара глаз окупается всегда.
-
Секреты только на сервере
Ключи платёжного провайдера, почты и облака не попадают ни в текст для модели, ни в клиентское приложение, ни в репозиторий. Агент вызывает серверную функцию, а функция сама знает ключ.
Что это ограничивает: утечку через текст. Модель не может выдать то, чего никогда не видела.
На небольшом продукте этот список закрывается за две или три недели работы одного инженера. Подписок в нём нет. Поэтому его так часто пропускают: его никто не продаёт, и за него некому выставить счёт.
#Сейчас, по триггеру, потом
Остальные меры удобно разложить по двум осям. По вертикали откладывается ущерб, который мера ограничивает. По горизонтали откладывается её цена: деньги, время команды и сложность, которую потом придётся сопровождать.
Отмеченный квадрант не откладывают никогда. Пунктирный можно оставить пустым, если это решение записано и у него есть дата пересмотра.
| Корзина | Что в ней | Когда платить |
|---|---|---|
| Сейчас | Права, разделение, лимиты, журнал, подтверждения, секреты на сервере | До первого пользователя с настоящими данными |
| По триггеру | Песочница для исполнения кода, общий шлюз инструментов, единая идентичность агентов, контроль исходящих соединений | Когда сработало заранее названное условие |
| Потом | Платформа политик, собственный центр мониторинга, выделенная команда, формальная сертификация | Когда одно и то же правило переписывают в третьей команде или этого требует договор |
Средняя корзина важнее, чем кажется. «По триггеру» не означает «когда-нибудь». Это означает, что условие записано сегодня, а деньги тратятся в день, когда оно выполнилось. Без записанного условия средняя корзина тихо сливается с третьей.
#Один сценарий и пять инструментов
Компания из шести человек продаёт подписку небольшим магазинам. У неё один агент и один сценарий: он разбирает обращения в поддержку. Инструментов пять. Агент читает обращение, читает заказы этого клиента, пишет черновик ответа, меняет статус заказа и ставит задачу менеджеру.
Подрядчик предлагает платформу политик: отдельный сервис, язык правил, консоль, интеграция на шесть недель. Основатель спрашивает, что платформа будет проверять. Выясняется, что правил пять. Читать можно только заказы клиента из обращения. Статус можно менять у одного заказа за обращение. Возвраты агенту недоступны совсем. Письмо уходит после нажатия кнопки человеком. Всё записывается в журнал.
Пять правил помещаются в пять серверных функций и сорок строк проверок. Инженер делает это за четыре дня, и правила лежат рядом с кодом, который они защищают. Платформа появится позже, когда агентов станет десять, а правила начнут копировать из проекта в проект.
Здесь нет экономии на безопасности. Запреты стоят там же, где стояли бы с платформой: на сервере, вне досягаемости модели. Отложен только способ ими управлять. Централизованное управление окупается повторяемостью, а у одного сценария повторять нечего.
#Где экономить нельзя
Есть две области, где правило «начнём с простого» не работает. Дорогие инструменты там тоже не обязательны. Просто ошибка в этих областях не имеет второй попытки.
Необратимые действия. Перевод денег, письмо на тысячу адресов, удаление данных, смена владельца учётной записи, выкладка в рабочую систему. Общий признак простой: кнопки «отменить» не существует. Для каждого такого действия ещё до запуска нужны три вещи: подтверждение человеком, лимит и запись в журнале. Это дёшево, пока действий пять. Это очень дорого, когда их пятьдесят и половину никто не помнит.
Чувствительные данные. Платёжные сведения, документы, медицинские и персональные данные, переписка клиентов. Вопрос «взломают ли нас» здесь вторичен. Важнее, сколько записей можно прочитать за один раз одним ключом. Прочитанное нельзя вернуть обратно. Поэтому объём чтения ограничивают так же строго, как запись: доступ по одному клиенту, потолок на выгрузку, отдельная копия базы для аналитики с правом только на чтение.
Если в вашем продукте есть хотя бы одно из двух, базовый список из шести пунктов перестаёт быть рекомендацией. Он становится условием запуска.
#Когда «потом» наступает
Я не верю в пороги вроде «после двадцати сотрудников» или «после раунда A». Размер компании плохо предсказывает риск. Команда из пяти человек с платёжными данными рискует больше, чем команда из пятидесяти с каталогом статей. Работают триггеры, привязанные к самой системе.
Сигналы, что простых серверных правил уже мало
Один сработавший пункт это повод пересмотреть среднюю корзину, а не купить всё сразу.
- Одно и то же правило доступа написано в третьем месте, и копии уже расходятся. Это и есть момент, когда общий шлюз дешевле трёх копий.
- Агент начал исполнять код или открывать файлы, которые прислал кто-то снаружи. Нужна изоляция исполнения. Серверная проверка прав от этого не защищает.
- Никто не может за десять минут ответить, какие агенты и с какими ключами сейчас работают. Нужен реестр агентов и единая идентичность. Без списка нечем управлять.
- Появился клиент, который присылает анкету по безопасности или требует отчёт аудитора. Требование пришло из договора. Дешевле подготовиться заранее, чем к дате подписания.
- Агент получил доступ к деньгам, персональным данным или рабочей инфраструктуре. Класс ущерба сменился. Меры, которых хватало для черновиков, перестали соответствовать.
- Инцидент или почти-инцидент, который нашли случайно, а не по журналу. Наблюдаемость отстала от системы. Это чинят первым.
#Сколько стоит переделка
У отсрочки есть цена, и она разная для разных мер. Отсюда простое правило, что можно откладывать. Откладывайте то, что потом добавляется сбоку. Не откладывайте то, что потом придётся встраивать внутрь.
Платформа политик добавляется сбоку. Если правила уже живут на сервере отдельными функциями, перенести их в общий сервис можно за один проект без остановки продукта. Мониторинг тоже добавляется сбоку, если журнал уже пишется.
Права доступа встраиваются внутрь. Если два года все сервисы ходили в базу под одной учётной записью, то сузить права значит найти каждое место, где код молча полагался на «мне всё можно». На одном проекте я видел, как такая работа заняла четыре месяца. В первый год она заняла бы неделю. С разделением сред та же история, и с секретами, которые успели разойтись по репозиториям, ноутбукам и чатам.
Отсюда два сценария. В первом шесть базовых мер делают сейчас за три недели, а платформу покупают через полтора года, когда она нужна. Во втором всё откладывают до раунда. Перед раундом выясняется, что у инвестора есть техническая проверка. Команда три месяца вместо продукта распутывает общие ключи, а платформу покупают в спешке и ставят поверх того, что она не может исправить. По деньгам второй сценарий дороже в несколько раз. По срокам он обычно попадает на самый неудобный квартал.
#Принятый риск на одной странице
Отложить меру нормально. Отложить и забыть уже ошибка. Разница в одной странице текста, и основатель может вести её сам.
- Принятый риск
- Риск, про который владелец знает, по которому он сознательно решил пока не действовать, и для которого записаны причина, предел ущерба, ответственный и дата пересмотра.
- Если проще Вы знаете про дыру, решили пока её не закрывать и записали почему.
На каждую отложенную меру нужна одна строка из пяти полей. Что не сделано. Что в худшем случае произойдёт и во сколько это обойдётся. Почему сейчас это приемлемо. Какой триггер отменяет решение. Кто и когда пересмотрит. Десять строк занимают одну страницу и читаются за пять минут раз в квартал.
Эта страница делает ещё одну важную вещь. Она отделяет «мы решили» от «мы не подумали». Клиенту, инвестору и новому техническому руководителю можно показать первое. Второе показать нельзя, потому что показывать нечего.
#Три способа потратить не туда
Театр безопасности: политика на сорок страниц, значок на сайте, ежегодный тест, а агент работает под общим административным ключом.
Вместо этого Проверяйте каждую трату одним вопросом: какое конкретное действие станет невозможным после неё. Если ответа нет, это расход на спокойствие, а не на безопасность.
Ничего не делаем до раунда, потому что нас четверо и мы никому не интересны.
Вместо этого Ошибке агента и уволенному подрядчику размер компании безразличен. Шесть базовых мер стоят трёх недель. Их отсутствие перед раундом стоит трёх месяцев и скидки в оценке.
Покупка инструмента без архитектурной проблемы: платформу купили, потому что она есть у больших, а правил в ней пять.
Вместо этого Сначала назовите проблему: что повторяется, что не масштабируется, что нельзя проверить. Инструмент выбирают под названную проблему. Если проблемы нет, инструмент станет ещё одной системой, которую некому вести.
#Как мы решали это у себя
1ADK сам построен вокруг агента, который читает чужую систему, поэтому этот выбор нам пришлось делать на себе. Платформы политик у нас нет. Правила живут в серверном коде, и их немного.
Задание на анализ ограничено заранее. Агент только читает, ничего не запускает, секреты в результат не попадают, пути только относительные, у задания есть срок жизни. Текст репозитория считается данными, а не инструкцией. 1ADK не требует доступа к вашему репозиторию и не требует загружать исходный код в сервис: анализ выполняет агент на вашей стороне, а к нам приходят структурированные сведения и доказательства. Это решение из первой корзины. Оно ограничивает максимальный ущерб с нашей стороны и не потребовало ни одной подписки.
В третьей корзине у нас лежит всё, что окупается повторяемостью: общий слой политик для многих агентов, отдельная команда, формальная сертификация. Это записано как отложенное, с условиями пересмотра. Говорю об этом прямо, потому что статья про честный выбор была бы странной без собственного примера.
#Чего этот подход не даёт
Чего это не делает
- Он не даёт универсального бюджета. Доля расходов на безопасность зависит от данных и действий в вашем продукте, и честной цифры для всех не существует.
- Он не заменяет требований закона и договора. Если регулятор или клиент требует конкретную меру, она переезжает в первую корзину без обсуждения цены.
- Он не защищает от взлома самой инфраструктуры. Базовые меры ограничивают ущерб от ошибки и от украденного ключа до пределов этого ключа, но не дальше.
- Он не работает без пересмотра. Корзины, составленные один раз, через год описывают другую компанию.
Возьмите лист бумаги и выпишите действия вашей системы, которые нельзя отменить. Рядом с каждым напишите, что сегодня мешает выполнить его по ошибке. Где у вас оказалось пусто: у денег, у писем наружу или у удаления данных?