Безопасность самого инструмента защиты
Агент DLP работает с повышенным уровнем доверия на каждой защищённой рабочей станции. Его собственная поверхность атаки и режимы отказа важны не меньше, чем угрозы, которые он призван обнаруживать.
Компилируемое ядро принятия решений
Вся логика, которая принимает решение маскировать или блокировать данные — оценка политик, обнаружение, маскирование и удаление чувствительных данных — выполняется внутри скомпилированного агента на Go. Ни одна интерпретируемая среда выполнения не находится в этом пути принятия решений.
Минимализм зависимостей как способ сокращения поверхности атаки
Репозиторий в целом декларирует пять прямых зависимостей Go-модулей:
creack/pty, jackc/pgx/v5, golang.org/x/crypto, golang.org/x/sys и
golang.org/x/term. Если ограничиться тем, что фактически входит в исполняемый файл
применения политик на рабочей станции, их три: creack/pty (работа с PTY),
golang.org/x/sys (используется для управления доступом через fanotify на Linux) и
golang.org/x/term. Оставшиеся два — jackc/pgx/v5 (драйвер PostgreSQL) и
golang.org/x/crypto (хеширование учётных данных по Argon2id) — используются
только контрольной плоскостью и никогда не компилируются в агент. Для исполняемого
файла, работающего с повышенным уровнем доверия на каждой защищаемой конечной
точке, небольшой, поддающийся аудиту граф зависимостей — это конкретное,
проверяемое свойство безопасности. Добавление зависимости в защитное ядро требует
оформления записи об архитектурном решении.
Административный интерфейс поставляется в виде чистого JavaScript без этапа
сборки, а значит, развёртываемый образ сервера контрольной плоскости не несёт в
составе собственной цепочки поставок инструментарий сборки npm —
это особенно важно для изолированных от внешней сети и регулируемых
развёртываний, где происхождение каждого компонента имеет значение.
Устойчивость политики к подделке
Подробно описано в разделе
Механизм применения политик и цепочка доверия:
каждый снимок политики подписывается по Ed25519, проверяется через упорядоченную
цепочку целостности прежде чем ему будет оказано доверие, защищён от повторного
повторного воспроизведения монотонно возрастающей отметкой максимальной версии,
а любой сбой проверки целостности — неверная подпись, недоверенный ключ,
несоответствие структуры — переводит агент в режим запрета при сбое (strict_fallback),
немедленно останавливая применение политик до восстановления действующей,
проверенной политики.
Целостность обновлений
Подробно описано в разделе Идентификация, доступ и управление парком агентов: пакеты обновлений подписываются и проверяются перед установкой, применяются атомарно и автоматически откатываются при неудачной проверке работоспособности после обновления.