Skip to main content
Протестируйте каждую политику двумя способами: на трафике, который уже произвели ваши агенты, и на законной операции, которую политика должна пропустить. Политика, которая видела только небезопасный сценарий, не протестирована.

​
Протестировать черновик

Редактор политик воспроизводит черновик по вызовам, которые уже сделал ваш флот, прежде чем вы его опубликуете.
  1. Откройте черновик в Admin → policy editor. Редактор подтверждает, что он парсится как JavaScript.
  2. В backtest выберите агентов и временное окно для воспроизведения — по умолчанию every agent и 30d — и оставьте последний фильтр на everything, если вы не хотите его сужать.
  3. Выберите run backtest. Панель backtest под черновиком, который парсится как JavaScript, с тремя фильтрами и действием run backtest, выше publish version.
Результат показывает, что бы черновик сделал с этими вызовами — включая количество работающих вызовов, которые он прервал бы. Это ложные срабатывания, найденные до того, как агенты их встретят: уточните черновик и запустите его снова, пока это число не станет приемлемым.

​
Запустить её на описанном событии

fp policies test запускает файл политики на вашем компьютере на синтетическом событии и проверяет решение. Ничего не публикуется и ничего не достигает облака:
Сформируйте событие с помощью --event, --tool, --command и --file. Фильтр match самой политики по-прежнему применяется, поэтому политика, которая не охватывает описанное вами событие, выдаст skipped вместо решения — обычно признак того, что её match уже, чем вы имели в виду.

​
Запустить её на одной машине

Затем примените её на самом деле на своей машине против собственного агента:
Первая команда проверяет и устанавливает файл; вторая подтверждает, что он загрузился вместе со всем остальным, что здесь применяется. Попросите агента сделать то, что политика блокирует, и смотрите, как это будет отклонено, затем выполните законную версию и смотрите, как она пройдёт. Никто другой не будет затронут. На машине, подключённой к облаку, проверьте оба решения в Observe → policy: отфильтруйте по названию политики, затем откройте каждый связанный сеанс, чтобы подтвердить ввод инструмента, на который она сработала, и причину возвращённого результата.

​
Протестировать то, что может сломаться

Установка отклоняет отсутствующий файл, синтаксическую ошибку, неразрешённый импорт, исключение верхнего уровня или модуль, который замирает при загрузке — поэтому переустановите после каждого изменения файла или всего, что он импортирует. Во время применения тот же сломанный файл логируется и пропускается, поэтому каждая другая политика продолжит работу: рассматривайте предупреждение о загрузке в журналах производства как потерянное применение. Файлы соглашений загружаются без команды install, поэтому сохраняйте явный шаг failproofai policies --install --custom <file> в CI — это то, что вызывает отказ сборки при сломанной политике. Затем скормите ей то, что агенты действительно отправляют, а не только ожидаемый ввод: отсутствующие поля, альтернативные названия инструментов, такие как Write и Edit, пути Windows, неправильно сформированный ввод. Возвращайте намеренный allow, instruct или deny на каждом пути, сохраняйте функцию детерминированной и ограничивайте любой внешний вызов коротким таймаутом.

​
Затем опубликуйте и наблюдайте за ней

Тестирование на истории показывает, что бы политика сделала с трафиком, который у вас был; оно не может показать, что сделает трафик, который вы ещё не видели. Выберите publish version в редакторе (или запустите fp policies publish), затем разверните его сначала в режиме observe — его вердикты записываются и ничего не блокируется — и применяйте, когда его совпадения разделят небезопасные действия от допустимых.