“RACI часто используют для задач, но про контрольные меры забывают. А ведь именно здесь размытые роли создают самые большие проблемы — от внедрения без владельца до аудита без ответственного. Матрица для контроля выглядит иначе, чем для проекта.”
Почему RACI для контроля, это не просто ещё одна таблица
Методология RACI известна в управлении проектами: она распределяет роли в выполнении задачи. Однако в контексте управления контролями — техническими и организационными мерами безопасности — её применение требует переосмысления. Контроль, это не разовая задача, а непрерывный процесс, существующий на протяжении всего жизненного цикла системы. У него есть этапы: проектирование, внедрение, эксплуатация, мониторинг и аудит. На каждом этапе набор ролей и их ответственность может меняться.
Главная проблема, которую решает RACI для контроля — размытость ответственности. Часто бывает так, что мера прописана в политике, но непонятно, кто отвечает за её работоспособность прямо сейчас. Системный администратор может её настроить, отдел безопасности — требовать отчёты, а при аудите выясняется, что конфигурация давно устарела и ответственность «повисла в воздухе». Матрица фиксирует это формально.
Важное отличие от проектного RACI: здесь редко бывает один исполнитель (R). За контроль обычно отвечает несколько ролей на разных уровнях. Например, за контроль «Резервное копирование» ответственным (R) может быть начальник отдела ИТ, а подотчётным (A) — конкретный инженер, который выполняет операции. Консультантом (C) выступает архитектор безопасности, а информируемым (I) — служба инцидентного реагирования.
Расшифровка ролей в контексте контроля
Классические четыре роли RACI приобретают специфическое значение, когда речь идёт о мерах безопасности.
Responsible (R) – Ответственный исполнитель
Это роль, которая выполняет работу по поддержанию контроля в актуальном и рабочем состоянии. Ответственный, это «владелец» контроля на операционном уровне. Он не обязательно принимает решения, но обеспечивает исполнение. Например, для контроля «Обновление ПО» R, это системный администратор, который устанавливает патчи. Ключевой момент: у одного контроля может быть только один Responsible. Это позволяет точно знать, к кому обращаться за исполнением.
Accountable (A) – Подотчётный (Утверждающий)
Самая важная и часто путаемая роль. A, это человек, который несёт конечную ответственность за результат работы контроля и имеет право его утвердить или отклонить. Обычно это руководитель. В контексте контроля 152-ФЗ, A часто является должностным лицо, ответственное за безопасность информации. Например, за контроль «Разграничение прав доступа» A, это руководитель направления, который утверждает матрицы доступа. Важно: на один контроль также приходится только один Accountable.
Consulted (C) – Консультант
Роль, с которой необходимо согласовывать изменения или чьё мнение нужно учитывать перед принятием решений. Консультант обладает экспертизой. Для технического контроля «Настройка межсетевого экрана» C, это сетевой инженер или архитектор безопасности. Их советуется запрашивать при изменении правил. Обратная связь от C обязательна, но окончательное решение остаётся за A.
Informed (I) – Информируемый
Лица или группы, которых необходимо ставить в известность о результатах выполнения контроля или его изменениях. Они не влияют на процесс, но должны быть в курсе. Например, о результатах аудит-логирования (контроль «Ведение журналов безопасности») информируется служба SOC. Их информирование может быть пассивным (рассылка отчёта) или активным (оповещение о критических событиях).
Этапы построения RACI-матрицы для контроля
Процесс состоит из последовательных шагов, которые превращают список мер безопасности в управляемый инструмент.
Шаг 1: Идентификация контролей
Сначала необходимо составить исчерпывающий список всех контролей, которые действуют в вашей системе. Источниками могут быть:
- Требования регуляторов (152-ФЗ, приказы ФСТЭК, отраслевые стандарты).
- Внутренние политики и стандарты безопасности компании.
- Требования frameworks (например, собственные базовые наборы мер).
- Результаты оценки рисков, где каждой угрозе сопоставлены контрмеры.
Важно формулировать контроль максимально конкретно. Не «Защита от вредоносного ПО», а «Обновление сигнатур антивируса на рабочих станциях», «Централизованное управление политиками EDR», «Анализ поведения на узлах». Это позволит точнее назначить роли.
Шаг 2: Определение ролей и лиц
На этом этапе нужно составить список всех ролей и конкретных людей (или должностей), которые могут быть задействованы. Роли часто соответствуют организационной структуре: «Руководитель отдела ИБ», «Старший инженер SOC», «Администратор Active Directory», «Владелец бизнес-процесса». Для маленьких команд роль и лицо могут совпадать.
Совет: избегайте назначения на роль целых отделов («Отдел ИТ»). Всегда стремитесь к конкретному должностному лицу или, как минимум, к названию позиции. Это исключает перекладывание ответственности.
Шаг 3: Заполнение матрицы
Создаётся таблица, где по вертикали перечислены контроли, а по горизонтали — роли. На пересечении для каждого контроля проставляется одна из букв: R, A, C, I. Основные правила заполнения:
- На каждый контроль ДОЛЖЕН быть ровно один R и ровно один A.
- R и A, это разные люди/роли. Один человек не может быть и исполнителем, и конечным ответственным за утверждение своей же работы (конфликт интересов).
- Колонок C и I может быть несколько, а может не быть вовсе.
- Ни одна клетка не должна оставаться пустой. Если для какой-то роли контроль нерелевантен — ставится прочерк.
Шаг 4: Проверка и валидация
Заполненную матрицу необходимо обсудить со всеми назначенными лицами. Цели валидации:
- Убедиться, что назначенные лица понимают свои обязанности и согласны с ними.
- Проверить, нет ли перегруженных ролей (одна роль является R для десятков контролей, это нереализуемо).
- Выявить «бесхозные» активности, для которых не нашлось R или A.
- Согласовать матрицу с руководством и зафиксировать её как внутренний регламентирующий документ.
Распространённые ошибки и как их избежать
| Ошибка | Последствие | Как исправить |
|---|---|---|
| Назначение одной роли и R, и A для контроля | Отсутствие независимого контроля качества. Исполнитель сам себя проверяет. | Чётко разделить операционное выполнение (R) и управленческую ответственность/утверждение (A). A должен быть на уровень выше в иерархии. |
| Назначение роли «Отдел ИБ» на все C и I | Департамент безопасности превращается в «помойку» всех консультаций, реальный исполнитель не определен. | Детализировать: «Специалист по криптографии» — C для контроля шифрования, «Аналитик SOC» — I для контроля логирования. |
| Отсутствие I для критически важных контролей | Ключевые заинтересованные стороны (например, бизнес-владельцы) остаются в неведении о состоянии безопасности их активов. | Включить в I владельцев бизнес-процессов, службу управления инцидентами для контролей, связанных с детектированием. |
| Матрица составлена, но никогда не пересматривается | Быстро устаревает при изменениях в команде, технологиях или регуляторных требованиях. | Внести проверку и актуализацию RACI-матрицы в регламент пересмотра политик безопасности (например, ежегодно или при существенных изменениях). |
Пример: RACI для контроля из 152-ФЗ
Возьмём конкретное требование: «Обеспечение защиты информации от вредоносного ПО» (условно, соответствует ряду технических мер). Разобьём его на конкретные контроли и построим матрицу.
| Контроль (Мера) | Руководитель отдела ИБ (CISO) | Администратор рабочих станций | Аналитик SOC | Владелец критичного сервиса |
|---|---|---|---|---|
| Развёртывание и настройка EDR-агентов на всех узлах | A | R | C | I |
| Ежедневная проверка отчётов об обнаруженных угрозах | I | R | A | I |
| Обновление сигнатур антивирусного ПО по расписанию | — | R | I | — |
| Расследование инцидента, связанного с вредоносным ПО | A | C | R | C |
Как читать эту матрицу: за развёртывание EDR (контроль 1) отвечает (R) администратор, но утверждает корректность выполнения и несёт конечную ответственность (A) руководитель ИБ. SOC консультирует по выбору агента (C), а владелец сервиса просто информируется (I) о факте внедрения. За расследование инцидента (контроль 4) отвечает уже аналитик SOC (R), а руководитель ИБ снова A. Администратор и владелец сервиса выступают как консультанты (C), предоставляя данные и контекст.
Интеграция RACI-матрицы в процессы управления ИБ
Сама по себе матрица, это статичный документ. Её ценность раскрывается, когда она становится частью рабочих процессов.
- Планирование и отчётность: При планировании работ по ИБ на квартал/год владелец процесса (часто A) знает, кого (R) привлекать для реализации каждого контроля. В отчётах для руководства ссылаются на матрицу, чтобы показать распределение ответственности.
- Аудит и проверки: Аудитор или регулятор запрашивает доказательства работы контроля. RACI-матрица даёт ему точный список контактов: кто реализовал (R), кто может подтвердить (A), у кого запросить документы (C). Это сокращает время проверки и повышает её качество.
- Онбординг новых сотрудников: Новичку в должности «Инженер по безопасности» выдают не только должностную инструкцию, но и выписку из RACI-матрицы, где он указан как R или C. Это сразу встраивает его в систему управления контролями.
- Управление инцидентами: При срабатывании контроля (например, системы обнаружения атак) процесс инцидент-менеджмента использует матрицу, чтобы знать, кого (R и A) необходимо немедленно вовлечь в работу, а кого (I) — проинформировать.
В итоге RACI-матрица для контроля превращает абстрактные требования безопасности в чёткую схему человеческой ответственности. Она не отменяет необходимости в технических решениях и политиках, но делает их исполнение управляемым и прозрачным. В условиях российского регуляторного поля, где часто требуют «назначить ответственных», этот инструмент становится не просто удобным, а необходимым.