Кто владеет корпоративными секретами: RACI-матрица для ИТ и бизнеса

RACI-матрица для корпоративных секретов определяет, кто согласует доступ, кто исполняет изменение и кто отвечает за результат. В предлагаемой схеме для каждого действия назначают одного владельца результата — A — и исполнителя R; участников консультации и информирования отмечают C и I. Эти роли описывают процесс и не назначают права в приложении автоматически.

Например, бизнес-владелец финансового сервиса разрешает доступ, ИТ настраивает его, а ИБ проверяет соответствие политике. Если это распределение не закреплено, заявка может ходить между командами, пока общий пароль остаётся действующим. Ниже — пример на шесть действий, порядок передачи владения и работа с аккаунтами, у которых ответственный не определён.

Бизнес-владелец не равен техническому администратору

Бизнес-владелец понимает, зачем системе нужен конкретный аккаунт, кто должен с ним работать и что произойдёт при утечке. Технический администратор отвечает за выполнение согласованной операции: создать запись, настроить доступ, поменять пароль или проверить интеграцию. Служба ИБ задаёт требования, контролирует исключения и оценивает риски.

Когда эти обязанности смешиваются, администратор вынужден решать, какие сотрудники вправе работать с финансовыми данными. У него может не быть таких полномочий или нужного контекста. Обратная крайность — когда бизнес-владелец самостоятельно распространяет пароль в чате, чтобы не ждать техническую команду.

Владение не означает, что человек должен знать все пароли: ему нужны полномочия принимать решения о доступе и понимать последствия. Назначьте владельца для каждой группы секретов. У рекламного кабинета им может быть руководитель маркетинга, у резервных копий — руководитель инфраструктуры, у финансового сервиса — ответственное финансовое подразделение. Один человек может быть владельцем нескольких объектов, но это должно быть осознанным решением.

Не путайте бизнес-роль с системной ролью продукта. В менеджере паролей могут существовать администраторы пространств, пользователи и другие уровни разрешений. RACI описывает ответственность людей за процесс, а не автоматически перечисляет права приложения.

Матрица RACI на шесть рабочих действий

В RACI используются четыре обозначения. R — исполнитель действия, A — единственный владелец конечного результата, C — сторона, с которой нужно посоветоваться, I — получатель информации. Схема не предписывает конкретную организационную структуру: компания адаптирует её под свои команды.

Действие	Владелец системы	ИТ	ИБ	Сотрудник
Согласовать новый доступ	A/R	C	C для критичного доступа	I
Настроить разрешения	A	R	C	I
Подтвердить необходимость прав	A/R	C	C	I
Сменить секрет по утверждённому основанию	A	R	C	I
Отозвать право после увольнения	A	R	C	I
Проверить соответствие политике	C	C	A/R	I

Это пример, не универсальная инструкция. Проверяющий соответствие политике должен быть организационно отделён от исполнителя проверяемого изменения. В крупных компаниях ИБ может быть ответственным за отдельные критичные согласования, а техническую выдачу выполняет владелец приложения. Важно, чтобы для каждого решения существовал один понятный A, иначе согласование превращается в круговую переписку.

Как читать матрицу в спорной ситуации. Предположим, руководитель регионального офиса запрашивает доступ нового агентства к рекламному кабинету. Он выступает инициатором, владелец бренда проверяет необходимость и объём прав, ИТ выполняет техническую выдачу, ИБ участвует только в том случае, если разрешения затрагивают чувствительные ресурсы. Такая модель не заставляет специалистов безопасности согласовывать каждую повседневную заявку, но оставляет им контроль над рискованными изменениями.

При этом не стоит делать «A» по умолчанию самым высокопоставленным человеком. Владелец результата должен иметь и полномочия, и информацию для принятия решения. Генеральный директор редко способен оценить технические последствия отдельной интеграции. Лучше делегировать ответственность тому, кто реально управляет соответствующей системой, сохранив порядок эскалации для конфликтных случаев.

Проверка RACI на практике. Возьмите пять недавних заявок: новый сотрудник, подрядчик, аварийное изменение, увольнение и пересмотр прав. Попробуйте для каждой восстановить инициатора, согласующего, исполнителя и подтверждение результата. Если хотя бы одно действие оказывается без ответственного, не пытайтесь замаскировать пробел новой строкой в таблице. Измените маршрут заявки, интерфейс согласования или передачу кадрового события. Матрица должна описывать реальную работу, иначе она остаётся формальным приложением к политике безопасности.

Сервисные аккаунты тоже должны кому-то принадлежать

У технической учётной записи часто нет привычного «пользователя». Её могли создать для интеграции CRM с сайтом, фоновой задачи или резервного копирования. Если автор настройки ушёл, аккаунт может остаться без человека, который подтвердит его назначение и разрешит изменение. Не считайте сотрудника, создавшего интеграцию, бессрочным владельцем бизнес-процесса.

Назначьте сервисному аккаунту бизнес-владельца либо владельца системы-потребителя. Технический специалист отвечает за способ хранения и работоспособность интеграции, но решение об отключении должен принимать человек, понимающий последствия для процесса. В записи реестра укажите назначение, связанные сервисы, правила смены секрета и маршрут восстановления.

Отдельно выделите общие аккаунты подрядчиков. До начала работ необходимо определить, кто со стороны компании владеет системой и кто сообщает об окончании договора. Закрепите источник сигнала об окончании договора, получателя в ИТ и срок проверки. Владелец договора подтверждает завершение работ, а техническая команда фиксирует фактическое прекращение доступа.

Разделение полномочий и конфликты интересов

Есть действия, которые опасно концентрировать в одних руках. Например, сотрудник сам запрашивает себе расширенные права, сам их выдаёт и сам подтверждает корректность. Даже если нет злого умысла, ошибка может остаться незамеченной. Для критичных записей полезен принцип разделения обязанностей.

В простой схеме владелец одобряет выдачу, ИТ её реализует, ИБ может проверить журнал и соответствие политике. Для небольшой команды, где людей мало, предусмотрите компенсирующий контроль: последующий независимый просмотр изменений или ограничение срока расширенного доступа.

Особое внимание уделите администраторам самого хранилища. Возможность управлять сервером, назначать роли и видеть содержимое секретов — разные полномочия. Их конкретное разделение зависит от архитектуры и модели шифрования выбранного продукта, поэтому испытайте реальные права на стенде, а не полагайтесь только на названия ролей.

В протоколе проверки фиксируйте не только успешное открытие разрешённой записи. Попросите администратора и пользователя другого подразделения попытаться увидеть чужой секрет через поиск, папки и доступные действия экспорта. Отрицательная проверка выявляет проблемы лучше, чем демонстрация с максимально широкими правами.

Как передавать владение при переводе и увольнении

Человек может сменить должность, уйти в другой филиал или покинуть компанию. Секрет при этом не должен оставаться бесхозным. Свяжите пересмотр владельцев с кадровыми событиями и изменениями организационной структуры. Для внешних подрядчиков аналогичный сигнал поступает от владельца договора.

Передача включает больше, чем смену фамилии в таблице. Новый владелец принимает перечень систем, подтверждает назначение аккаунтов, проверяет пользователей с действующими правами и знает, где находится аварийная инструкция. Прежний владелец теряет ненужные разрешения, а раскрытые пароли при необходимости меняются в целевых сервисах.

Для критичных общих аккаунтов оформляйте короткий акт передачи: объект, новый владелец, дата, открытые исключения, связанные подрядчики, проверенные разрешения. Это особенно полезно в холдингах, где один ИТ-отдел обслуживает несколько юридических лиц или филиалов.

Не рассчитывайте, что автоматическая блокировка человека в каталоге решит все вопросы. Ранее известный пароль может продолжать работать в стороннем сервисе, а сами сервисные учётные записи не всегда связаны с персональными аккаунтами сотрудников. Нужен отдельный процесс отзыва и смены секретов.

Если прежний владелец недоступен. Назначьте временного исполнителя передачи, определите необходимые доказательства правомерности доступа и установите срок подтверждения новым владельцем. Сама смена фамилии в карточке секретов не должна автоматически расширять полномочия человека в стороннем сервисе. Убедитесь, что прежние личные роли закрыты, а риски ранее раскрытых общих секретов рассмотрены. Достоверно установить отсутствие всех сохранённых копий обычно нельзя; если прежний получатель больше не должен входить по известному ему секрету, предусмотрите его замену в целевой системе.

Для каждой передачи полезно сохранить два независимых подтверждения: бизнес-владелец принял ответственность за систему, техническая команда проверила фактические разрешения. Сохраните оба подтверждения со ссылкой на один объект и датой: при следующей проверке будет видно, кто принял решение, а кто проверил его выполнение.

Что делать с паролями без владельца

Первая реакция на пустую графу «владелец» обычно проста: назначить ответственного из ИТ. Так появляется иллюзия порядка. Но технический администратор не обязан знать, нужна ли компании устаревшая подписка или кто разрешил подрядчику работать с определённым сервисом.

Создайте очередь разбора неопределённых записей. У каждой должны быть временный координатор, срок проверки, предполагаемый бизнес-процесс и уровень риска. Координатор отвечает за расследование, но не становится бизнес-владельцем без подтверждения полномочий.

Источниками сведений могут быть закупочные договоры, карточки сервисов, обращения поддержки, сведения об интеграциях и интервью с подразделениями. Если назначение аккаунта не подтверждено, не удаляйте его автоматически: возможно, на нём работает незаметная ночная задача.

После проверки назначьте владельца либо согласуйте вывод учётной записи из эксплуатации. Для высококритичных объектов временные меры и ограничения доступа следует утвердить отдельно. Для нерешённых записей сохраняйте срок, временный контроль и следующего исполнителя. Пустая графа владельца должна оставаться открытой задачей до подтверждённого решения.

Превратите таблицу ответственности в процесс

Матрица RACI должна жить рядом с реестром систем и заявками. При выдаче доступа заявка автоматически или вручную указывает согласующего владельца, а по завершении работ фиксируется исполнитель отзыва. Если эти сведения лежат в трёх разных документах и не связаны идентификатором системы, процесс быстро теряет целостность.

Раз в установленный внутренней политикой период отправляйте владельцам не весь список паролей, а выборку действующих полномочий и исключений по их ресурсам. Пусть они подтверждают необходимость доступа либо инициируют отзыв. Особенно важно показывать временные разрешения, выданные подрядчикам, и аккаунты без движения длительное время.

Полезные показатели: доля секретов с подтверждённым владельцем, время обработки заявки, количество просроченных временных доступов, длительность переназначения владельца после кадрового события. За каждым показателем закрепите состав выборки, период и критерий выполнения. Например, передачу владельца считайте завершённой после принятия ответственности и проверки прав, а не после изменения фамилии в карточке.

Начните с одного бизнес-процесса и нескольких систем. Утвердите роли, проверьте три реальные заявки и один сценарий увольнения. После этого расширяйте подход. Для технологической части полезны сценарии управления доступами в BearPass и отдельный материал о корпоративной модели IAM и PAM.

Обзор исключений. Для пилота можно назначить еженедельный просмотр временных доступов, просроченных согласований и запросов без владельца. Это предлагаемый рабочий ритм, а не универсальная норма. После пилота выберите период с учётом количества изменений и срока, на который компания готова оставлять такие случаи без решения. Не нужно приглашать на него всех руководителей компании: достаточно исполнителя ИТ, представителя ИБ и владельцев затронутых ресурсов.

Например, если подрядчик завершил проект, его персональная запись в хранилище может быть заблокирована, но выданный ранее общий пароль остаётся действующим. Матрица должна показывать, кто отвечает за решение о ротации, кто исполняет её в целевом сервисе и кто подтверждает, что интеграции после изменения продолжают работать. Без такого разделения у всех участников есть повод считать работу чужой задачей.

Как обновлять RACI при росте компании. Когда появляются новые филиалы, несколько юридических лиц или централизованный ИТ-сервис, не копируйте таблицу механически на каждый отдел. Сначала определите, какие решения можно принимать локально, а какие должны оставаться у владельца корпоративной платформы. Например, регион вправе согласовывать доступ к собственным рабочим записям, но не менять общесетевую административную модель.

Проводите повторную проверку после реорганизаций, крупных миграций и смены аутсорсера. Запишите в карточке системы не только фамилию владельца, но и основание назначения, заместителя, границы полномочий и дату последнего подтверждения. Тогда новая команда сможет продолжить работу даже при внезапном уходе руководителя.

Рекомендуем к прочтению

• Что такое RBAC и зачем он нужен
• Разделение хранилища для холдингов и филиалов

Частые вопросы