Свой жизненный цикл есть у всех правил и настроек средств защиты. Их придумывают не просто так, а из каких-то предпосылок, например, по итогам инцидента. Их вводят и распространяют на определённые группы пользователей. Их проверяют и пересматривают в зависимости от эффективности и конфликтов с другими правилами. Наконец, их отменяют или деактивируют до лучших времён. Каждое из этих действий подлежит документированию. Из записей должно быть понятно, кто, когда и почему каждое правило придумал, включил или отключил.
![]() |
Администратор может смениться. Аудитор может проверить адекватность политики безопасности. Начальник может захотеть рассмотреть жалобу пользователя. Наконец сам сотрудник через год должен вспомнить, зачем он вводил какое-то ограничение. Для всего для этого необходимо логирование и документирование настроек.
По своей сложности и развесистости настройки ТСЗИ приближаются к компьютерным программам. А программистов, как известно, усиленно дрючат на предмет документирования и менеджмента версий (Revision control, Version control). Потому что давно установлено: в ряде случаев будет проще написать код с нуля, чем разобрать и модифицировать чужой. Или даже свой собственный, но написанный
Администраторов безопасности, в отличие от кодеров, пока ещё не строят в три шеренги.
Программный код стоит хороших денег, именно поэтому он должен содержаться в порядке, поэтому на уход за ним не жалеют человеко-часов. А настройки безопасности – бесплатные, что ли? Просто их цену ещё не научились убедительно подсчитывать.