Почему вайб-кодинг порождает новые теневые ИТ

Инструменты, основанные на искусственном интеллекте, смещают теневые ИТ из сферы SaaS в сферу кода. Энди Гомбар, ведущий инженер Webflow по обнаружению и реагированию, рассказывает на портале The New Stack о том, как можно проактивно защитить свою облачную инфраструктуру.

Раньше теневые ИТ были проблемой SaaS. Кто-то из маркетинговой команды регистрировался в инструменте, подключал его к Google Workspace, и первым сигналом было разрешение OAuth, которое вы не авторизовали. Раздражающе. Обнаруживаемо. Ликвидируемо.

Эта эпоха закончилась.

Новые теневые ИТ не отображаются в ваших журналах OAuth. Они отображаются как работающая в вашей облачной учетной записи инфраструктура, созданная с благими намерениями инженером, который попросил агента ИИ запустить ее в тот же день. Никаких тикетов, никакого ревью, никакого участия команды безопасности. Просто кто-то с хорошей идеей и инструментом, который устранил все препятствия, замедлявшие его работу.

Такое поведение вызвано не только существующей неэффективностью. Частично оно связано с реальной работой по обеспечению безопасности.

Проблема с благими намерениями

В классических теневых ИТ чувствовалось присутствие кого-то, сознательно обходящего утвержденную ИТ-инфраструктуру. Команда, которая не хотела ждать закупок. История безопасности, по крайней мере частично, касалась здесь обеспечения соблюдения политик.

Теперь все иначе.

Инженер, который разрабатывает с помощью вайб-кодинга внутренний инструмент для своей команды, не пытается ничего обойти; он пытается помочь. У него есть доступ к агенту ИИ, который может писать код, генерировать программы Pulumi и развертывать инфраструктуру быстрее, чем любой процесс проверки. И если он не потратил время на размышления о безопасности облачных вычислений, у него нет оснований полагать, что то, что он только что выпустил, представляет собой проблему.

Вот что усложняет ситуацию: вы не можете навязать свой способ выйти из нее; вы должны быстро ее предотвратить.

Пример того, как выглядит подобная проблема: инженер создает легковесное внутреннее приложение для автоматизации ручной работы своей команды. Он просит ИИ-агента заняться инфраструктурой. Агент выделяет ресурсы в учетной записи AWS команды, открывает необходимые порты и развертывает приложение. Оно работает, и команда в полном восторге. Никто не создает тикет, потому что нечего создавать. Шесть недель спустя ваша CSPM обнаруживает общедоступную конечную точку с избыточно разрешенной IAM-ролью. К тому времени приложение уже достаточно долго работает в продакшене, и латеральное перемещение является реалистичным сценарием, а не теоретическим.

Намерение было благим. Результат имеет радиус поражения.

Почему это отличается от разрастания SaaS

Когда теневые ИТ означали несанкционированный SaaS, ваша поверхность обнаружения была определена. Предоставление прав OAuth, сетевой трафик, отчеты о расходах, аномалии SSO. Инструмент существовал вне вашей инфраструктуры. Он был внешним. Вы могли его обнаружить, вы могли его отключить, и ущерб обычно был ограничен.

Внутренние инструменты, созданные агентами, находятся внутри вашей инфраструктуры. У них есть IAM-роли. Они могут иметь прямой доступ к производственным данным, внутренним API или конфиденциальным системам. Они выглядят легитимно, потому что были созданы легитимным сотрудником с использованием легитимных инструментов. Нет очевидного признака, который можно было бы обнаружить. Код не заявляет о своей неконтролируемости. Он просто работает.

Этот сдвиг заслуживает четкого названия: мы перешли от разрастания SaaS к разрастанию кода. Сценарий обнаружения для одного не подходит для другого.

Базовые требования, которые действительно нужны

Цель здесь не в том, чтобы замедлить работу инженеров. Цель в том, чтобы сделать безопасный путь легким. Базовые требования, к которым следует стремиться, имеют два уровня, и различие между ними имеет значение.

Платформенный контроль — это то, что структурно затрудняет случайное совершение неправильных действий и что вы настраиваете один раз на уровне организации или учетной записи.

IAM-ограничения по принципу наименьших привилегий. Доступные для командных учетных записей AWS разрешения должны быть ограничены по умолчанию. Инженер не должен иметь возможность создавать общедоступный ресурс с широкими правами доступа, не нарушая защитный механизм. Защитный механизм не останавливает работу. Он предотвращает незаметную отправку худшей версии работы.

Принудительное использование менеджера секретов. Жестко закодированные учетные данные в приложениях, созданных с помощью вайб-кодинга, — это не гипотетическая ситуация. Это почти неизбежная ситуация, если вы не сделаете правильный путь очевидным. Принудительное использование менеджера секретов на уровне инфраструктуры полностью снимает с отдельного инженера право принятия решения.

Цели развертывания с использованием VPN. Внутренние инструменты должны по умолчанию размещаться за корпоративным VPN. Если что-то действительно должно быть общедоступным, это должно требовать явного решения, а не случайного значения по умолчанию.

Контроль процессов — это то, что должно происходить на уровне инструмента, прежде чем что-либо будет выпущено.

Автоматизированная проверка базовых требований. Прежде чем специалист по безопасности начнет проверку, автоматически проверьте код и конфигурацию инфраструктуры на соответствие базовым требованиям. Выявите нарушения, оцените их по степени серьезности и предоставьте инженеру конкретные рекомендации по устранению. Это тот уровень, который может обеспечить навык Claude или аналогичный инструмент. Дальнейшая проверка человеком фокусируется на результатах автоматической проверки, а не начинается с нуля.

Проверка кода с учетом требований безопасности и эскалацией. Каждый инструмент, разработанный внутри компании и взаимодействующий с производственной инфраструктурой, требует проверки человеком, обладающим опытом в области безопасности, прежде чем он будет выпущен. Для инструментов с низким уровнем риска это может быть коллега-инженер, понимающий масштабы проблемы, которую он проверяет. Для всего, что связано с облачной инфраструктурой, прямым доступом к данным или новыми ролями IAM, проверка эскалируется в формальную проверку безопасности. Тот же контроль, но с разбивкой по степени риска. Ключевой момент заключается в том, что проверяющий должен действительно понимать код. В случае с инструментами, разработанными с использованием вайб-кодинга, автор может не до конца понимать, что он создал. Это делает проверку более важной, а не просто формальной. Это не просто врата качества. Это своего рода «врата понимания».

Защитная сетка

Базовые требования — это профилактика. Обнаружение — это то, что выявляет то, что проскальзывает.

Ваша CSPM — это подходящий инструмент для обнаружения неправильных конфигураций в уже существующих системах. Wiz и подобные ему инструменты выявят общедоступную конечную точку, роль с избыточными правами доступа, хранилище без надлежащего контроля доступа.

Но CSPM обнаруживает только то, что уже развернуто. Базовые требования и процесс ревью — это то, на что вы рассчитываете в плане предотвращения. Обнаружение — это уровень выявления, а не первая линия защиты.

Более сложная задача обнаружения — это знание о существовании чего-либо. Инструмент вайб-кодинга, работающий локально или в командной учетной записи, может не оставлять следов в вашем обычном слое видимости. Нет конвейера развертывания. Нет заявок на изменение. Нет записей в инвентаризацию активов.

Вот где начинают иметь значение поведенческие сигналы из вашей облачной телеметрии. Создание ролей IAM вне вашей обычной активности конвейера. Появление новых общедоступных ресурсов без соответствующей записи об изменении. Вызовы API, исходящие с машин разработчиков непосредственно в производственные учетные записи, а не через стандартные инструменты. Ни один из этих сигналов сам по себе не является определяющим. В совокупности они начинают выглядеть как нечто, заслуживающее более пристального внимания.

Большинство команд не ищут эти сигналы именно в контексте инструментов, созданных агентами. Именно этот пробел стоит закрыть.

Кодифицированные базовые требования

Документация, хранящаяся в вики, — это базис, который никто не использует, когда это необходимо. Лучший путь — сделать базовые требования доступным в инструментах, которые уже используют инженеры, на этапе разработки.

Навык Claude или аналогичный ИИ-нативный инструмент, который проверяет описания архитектуры или сгенерированную инфраструктуру на соответствие вашему конкретному базовому уровню безопасности, полезнее, чем контрольный список в Confluence. Инженер получает конкретную, действенную обратную связь до того, как ее увидит человек-рецензент. Команда безопасности получает первый вариант, уже отфильтрованный по очевидным недостаткам. Проверка становится лучше, потому что она начинается с более полной картины.

Ничего из этого не сработает, если инженеры не осведомлены об этом навыке или если отсутствует процесс проверки. Осведомленность сама по себе является уровнем предотвращения. Внедрение обоих аспектов во время адаптации делает безопасный путь видимым, а использование обратной связи от навыка в качестве двойного инструмента обучения тому, почему важна каждая проверка, помогает закрепить знания. Защитный барьер, который не афиширует себя, не является профилактическим.

Вывод

Внутренние инструменты, основанные на вайб-кодинге, никуда не денутся. Трение, которое раньше замедляло работу неуправляемой инфраструктуры, исчезло и не вернется. Вопрос в том, успеет ли ваш базовый уровень безопасности достичь своих целей раньше, чем CSPM.

Платформенный контроль делает безопасный путь путем по умолчанию. Контроль процессов гарантирует, что человек, обладающий контекстом безопасности, увидит все до того, как это будет реализовано. Обнаружение дает вам уровень защиты от того, что все равно проскальзывает.

Для всего этого не требуется выделенная команда AppSec или SOC. Необходимы четкие базовые требования, инструменты для их обеспечения и инженеры, понимающие, что именно они проверяют. Эту проблему может решить небольшая, хорошо структурированная команда безопасности. Платформенный контроль осуществляется на уровне организации или инженера по безопасности, устанавливается один раз и применяется повсюду. Контроль процессов является распределенным: коллега-инженер, имеющий опыт работы с безопасностью, занимается инструментами с низким уровнем риска, в то время как все, что касается облачной инфраструктуры, прямого доступа к данным или IAM-новшеств, передается на формальную проверку безопасности. Это распределенная ответственность с четким путем эскалации, а не одна команда, проверяющая все.