Как мы даем ИИ доступ к боевым сайтам: безопасные исправления и автоматика

Подробности изложены в материале первоисточника. Во второй части нашего проекта по внедрению нейросетей в администрирование сайтов я решил полностью делегировать искусственному интеллекту не только диагностику, но и внесение правок на production-серверах. После того как ИИ научился понимать структуру CMS, мне надоело вручную выполнять рутинные действия: подключаться по SSH, делать бэкапы, заливать код и проверять работоспособность страниц.

Теперь задача звучит просто: «Найди ошибку, исправь и проверь», а всю техническую обвязку и безопасность берёт на себя разработанная нами система защиты.

Как мы усмирили SSH для ИИ

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

На одном из хостингов такое поведение привело к мгновенным блокировкам из-за шквала коротких соединений. Поскольку белые списки IP у провайдера отсутствовали, пришлось полностью переписать логику работы с SSH-подключениями под капотом нашей обёртки.

Настройка пула соединений и ControlMaster

Сначала мы научили скрипт анализировать конфигурацию OpenSSH и строить пул соединений строго по фактическому адресу целевого сервера, очищая ключи для корректного использования в путях:

effective_config="$("$REAL_SSH" -G "$@" 2>/dev/null || true)"
resolved_host="$( printf '%s
' "$effective_config" | awk '$1 == "hostname" {print $2; exit}' )"
resolved_user="$( printf '%s
' "$effective_config" | awk '$1 == "user" {print $2; exit}' )"
resolved_port="$( printf '%s
' "$effective_config" | awk '$1 == "port" {print $2; exit}' )"

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

Безопасность файлов и изоляция через site-file

Оставлять ИИ прямую запись в терминале через произвольные команды вроде sed или скрипты на Python было слишком рискованно. Даже при наличии SSH боевые файлы теперь меняются исключительно через специализированный инструмент site-file.

Через этот файловый канал мы жестко заблокировали доступ на чтение и запись к критически важным системным каталогам:

• Служебным директориям .git/, .ssh/, node_modules/;
• Файлам окружения .env, конфигам авторизации и закрытым ключам (*.pem, *.key, *.p12);
• Системным папкам CMS с логами, сессиями и настройками.

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

Жизненный цикл безопасного изменения файла

Любая правка физического файла через команду site-file put строится на принципе «сначала проверь, потом запиши». Инструмент автоматически считывает актуальную версию с боевого сервера, вычисляет контрольную сумму и выводит diff.

Если параметры заданы верно, процесс выполняется по следующему алгоритму:

• Создается резервная копия предыдущей версии файла вместе с метаданными;
• Новый код пишется во временный файл в том же каталоге с нужными правами доступа и только потом атомарно подменяет оригинал;
• Происходит контрольное чтение файла с сервера для сверки SHA256-сумм;
• Для PHP-файлов обязательно запускается проверка синтаксиса php -l;
• При малейшем сбое на любом из этапов система автоматически выполняет откат (rollback) к предыдущей рабочей версии.

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

Координация агентов и проектные блокировки

Когда с одним сайтом начинают параллельно работать несколько ИИ-агентов, возникает риск перезаписи чужих изменений. Локальные блокировки внутри отдельных утилит эту проблему не решают, поэтому мы внедрили глобальный механизм блокировки на уровне проекта.

Для каждого сайта создается файл project.lock, а в owner.json фиксируется информация о запущенном процессе. Если второй агент пытается начать правку занятого проекта, он получает вежливый отказ со ссылкой на текущего владельца задачи.

Чтобы защитить систему от зависших блокировок при аварийном падении процессов или отключении электричества, мы сохраняем идентификатор Linux boot_id. Если сервер перезагружался, старая блокировка автоматически признается недействительной, а бесхозные lock-каталоги сбрасываются по тайм-ауту.

Правила и оценка реальных рисков

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

Правила распределены по уровням:

• Глобальный файл AGENTS.md задает общие регламенты для всех проектов;
• Локальный проектный AGENTS.md хранит архитектурные особенности конкретного сайта, структуру базы данных, используемые компоненты и плагины.

Перед изменением элементов CMS система проверяет граф зависимостей через специализированные команды. Оценка риска строится на основе возможных последствий, а не количества измененных строк.

Браузерная проверка через site-check

Успешная запись файла и корректный синтаксис PHP еще не гарантируют, что сайт отображается корректно. На фронтенде легко получить сломанную верстку, ошибки в консоли браузера или битые изображения.

Для контроля качества мы используем утилиту site-check на базе Puppeteer. Она открывает измененную страницу, проверяет HTTP-статусы, ловит JS-ошибки, сетевые сбои сетевых ресурсов (4xx/5xx) и появление нежелательного горизонтального скролла.

Чтобы старые ошибки сторонних виджетов на заброшенных сайтах не блокировали работу, система использует эталонные слепки состояния. Сверяясь с ними, инструмент фиксирует исключительно новые проблемы, появившиеся в результате последних правок.

Итоги и дальнейшие шаги

В итоге вокруг предметного интерфейса CMS выросла целая экосистема безопасности: SSH-транспорт, файловые шлюзы, проектные блокировки, система бэкапов, история изменений и автоматический браузерный тест.

Проект перерос рамки конкретной CMS. Большая часть этой обвязки универсальна и в будущем пригодится для работы с другими платформами вроде WordPress. ИИ избавил меня от ручной рутины между задумкой и готовым результатом, позволив сосредоточиться на архитектуре, а не на механическом переносе кода.