“RACI, это не просто табличка для отчёта. Это способ увидеть, кто на самом деле принимает решения, кто отвечает за результат, а кто лишь ставит галочку. В российском ИТ, где требования регуляторов накладываются на внутренние процессы, эта матрица превращается из управленческого инструмента в инструмент выживания. Она показывает разрыв между формальной ответственностью и реальной работой, и помогает этот разрыв закрыть.”
Что такое RACI-матрица и зачем она нужна в ИТ-безопасности
RACI, это аббревиатура, описывающая четыре ключевые роли в любом процессе или проекте. Каждая буква соответствует английскому термину, который давно устоялся в российской управленческой практике.
- R (Responsible) — Исполнитель. Тот, кто непосредственно выполняет работу. Их может быть несколько на одну задачу.
- A (Accountable) — Ответственный. Тот, кто несёт конечную ответственность за результат, утверждает работу и обладает правом вето. На одну задачу должен быть только один «А».
- C (Consulted) — Консультант. Эксперт, чьё мнение запрашивается до принятия решения. Обратная связь от «С» обязательна.
- I (Informed) — Информируемый. Лицо, которое ставят в известность о результатах или решениях, но чьё согласие не требуется.
В контексте российских требований по информационной безопасности, таких как 152-ФЗ и приказы ФСТЭК, процессы часто формализуются «на бумаге». Прописываются политики, регламенты, но чёткого распределения ролей по конкретным контрольным мероприятиям часто нет. В результате возникает ситуация, когда за проведение оценки уязвимостей (скажем, контроль А.12.6.1 из стандарта) формально отвечает отдел ИБ, а фактически сканирует сисадмин, отчитывается руководитель отдела, а о результатах никто не информирует ответственного за систему. RACI-матрица визуализирует эти связи и устраняет неопределённость.
Её основная ценность в ИБ — не в создании ещё одного документа, а в прояснении зон ответственности. Это инструмент для ответа на вопросы: «Кто делает?», «Кто в ответе?», «С кем согласовываем?» и «Кого просто ставим в курс?» для каждого требования регулятора или внутреннего контроля.
От требований регулятора к конкретным задачам: построение матрицы
Невозможно построить работающую матрицу, просто взяв приказ ФСТЭК и вписав в столбцы должности. Первый шаг — декомпозиция требований на конкретные, измеримые задачи или контрольные мероприятия.
Возьмём, к примеру, распространённое требование по управлению инцидентами. В документации оно может звучать как «должна быть обеспечена регистрация и обработка инцидентов». В матрице это бесполезная формулировка. Её нужно разбить:
- Регистрация входящего обращения об инциденте в системе учёта.
- Первичная классификация и назначение приоритета инциденту.
- Расследование причин инцидента.
- Устранение последствий инцидента.
- Закрытие инцидента и фиксация результатов.
- Ежеквартальный анализ статистики инцидентов.
Только после такой декомпозиции можно приступать к распределению ролей. Задачи становятся понятными и исполнимыми для конкретных специалистов.
Далее формируется таблица. По вертикали — список этих задач. По горизонтали — роли или конкретные должности, задействованные в процессе (например, «Специалист службы ИБ», «Руководитель отдела эксплуатации», «Системный администратор», «CISO»). На пересечении для каждой задачи проставляются буквы R, A, C, I.
Критические правила заполнения
Чтобы матрица работала, а не создавала хаос, нужно жёстко соблюдать несколько правил.
- На одну задачу — один «А» (Accountable). Это главное правило. Если «А» несколько, ответственность размывается, и решение не может быть принято. В российских реалиях «А» часто оказывается не тот, кто делает, а тот, кто подписывает отчёт или несёт ответственность перед руководством.
- «R» (Responsible) должно быть достаточно для выполнения задачи. Исполнителей может быть несколько, но их состав должен позволять реально закрыть задачу. Если на сложную техническую задачу назначен только один «R» без «C», это сигнал о риске.
- «C» (Consulted) — не просто «можно спросить». Это обязательный этап согласования. Если мнение консультанта проигнорировано, процесс считается нарушенным. Важно отличать «C» от «I»: консультант влияет на решение, информируемый — только получает информацию постфактум.
- Избегайте пустых клеток и клеток с несколькими ролями. Пустая клетка, это неопределённость. Клетка с отметками «R» и «A» нарушает принцип разделения ответственности и исполнения. Если такая комбинация кажется необходимой, нужно пересмотреть декомпозицию задачи.
RACI в действии: пример для контроля доступа
Рассмотрим практический пример на основе типичного требования — управление учётными записями пользователей (соответствует множеству требований ФСТЭК и 152-ФЗ).
| Контрольная задача / Роль | Администратор ИС | Руководитель подразделения | Сотрудник службы ИБ | CISO |
|---|---|---|---|---|
| Создание заявки на предоставление доступа | I | R | ||
| Согласование заявки на доступ | A | C | I | |
| Техническое создание учётной записи | R | I | C | |
| Ежеквартальная выверка списков доступа | R | C | A | I |
| Блокировка учётной записи при увольнении | R | A | I | I |
Что видно из этой матрицы? Ответственность за согласование доступа («А») лежит на руководителе подразделения, а не на ИБ. Служба ИБ выступает здесь в роли консультанта («С»), оценивая риски. Техническое исполнение («R») — на администраторе. CISO информируется о ключевых событиях. Такое распределение отражает реальный процесс, где бизнес-подразделение отвечает за необходимость доступа, а ИБ обеспечивает его безопасность.
Без матрицы этот процесс часто выглядит иначе: заявку создаёт сам сотрудник, согласует ИБ, а руководитель лишь ставит подпись, не вникая. Это создаёт риски избыточных привилегий.
Типичные ошибки и как их избежать
При внедрении RACI в практику ИБ-контролей часто возникают одни и те же проблемы.
- Матрица становится «идеальной картинкой», а не отражением реальности. В неё вписывают должности «как должно быть», игнорируя текущее положение дел. В результате документ ложится на полку. Правильный путь — описать сначала текущий процесс «как есть», выявить его слабые места (например, отсутствие «А» или слишком много «С»), а затем спроектировать и согласовать целевую матрицу «как должно быть».
- Назначение роли «А» техническому специалисту. Системный администратор, отвечающий за настройку межсетевого экрана, не должен быть «А» для этого контроля. «А», это его руководитель или CISO, кто несёт ответственность перед аудиторами и регулятором. Администратор — «R». Это разделение критически важно для управления рисками.
- Превращение матрицы в инструмент микроменеджмента. RACI, это framework для ясности, а не пошаговая инструкция. Не нужно дробить процесс до абсурда (например, выделять «нажатие кнопки ‘Сохранить’ в тикете» отдельной задачей). Задачи должны быть на уровне осмысленного действия.
- Игнорирование роли «I» (Informed). Кажется, что это второстепенная роль. Но в ИБ многие процессы требуют информирования смежных отделов. Непроинформированный руководитель другого отдела о новых правилах доступа может стать источником конфликта и обхода процедур.
Интеграция RACI с системой управления ИБ и регуляторными требованиями
Сама по себе матрица — статичный документ. Её сила раскрывается при интеграции в живые процессы.
Во-первых, RACI должна быть привязана к реестру рисков и контролей. Для каждого контроля в реестре должна быть ссылка на соответствующую задачу в RACI-матрице или, что лучше, прямое указание ролей R, A, C, I. Это позволяет при аудите или проверке ФСТЭК сразу видеть, кто и за что отвечает.
Во-вторых, распределение ролей должно быть отражено в системах управления процессами. Если в Service Desk или SIEM-системе настроены маршруты согласования, они должны соответствовать матрице: задача автоматически направляется «R», решение утверждает «А», перед этим запрашивается мнение «С», а уведомления уходят «I».
В-третьих, RACI — основа для должностных инструкций и KPI. Если сотрудник значится как «R» для десяти ключевых контролей по обеспечению доступности, это должно быть в его зоне ответственности и влиять на оценку эффективности. Ответственность «А» у руководителя означает, что его KPI включают выполнение этих контролей его командой.
Такой подход превращает разрозненные требования регуляторов в понятную систему распределённой ответственности, где каждый знает свою роль не только в проекте, но и в ежедневном обеспечении безопасности.