Матрица доступа для сотрудников и подрядчиков: пример и порядок внедрения

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

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

Что должно быть в матрице доступа

Строка «Иванов — пароль от CRM» почти ничего не объясняет. Неясно, почему Иванову разрешили доступ, кто отвечает за CRM и что делать после его перевода в другой отдел. Поэтому матрица должна содержать объект, владельца, роль или группу, допустимые действия, основание выдачи, согласующего и срок. Для чувствительных систем пригодятся класс риска и периодичность пересмотра.

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

Описывайте в матрице рабочие задачи и разрешённые действия — так правила останутся понятными при смене продукта или подрядчика. Сами пароли, токены и коды восстановления в таблицу не вносите. Достаточно названия записи или её идентификатора в защищённом хранилище.

Сначала работа, потом роль

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

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

Пример для компании с филиалами

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

Система или секрет	Кто получает доступ	Что разрешено	Кто согласует	Когда пересматривать
CRM головного офиса	Администраторы CRM центрального ИТ	Поддержка и настройки	Владелец CRM	При смене роли и планово
CRM филиала	Менеджеры филиала	Работа в пределах своей зоны	Руководитель филиала	При переводе и увольнении
Хостинг сайта	Назначенный внешний подрядчик	Только согласованные операции	Владелец сайта и ИТ	В конце работ
Резервные копии	Ограниченная группа инфраструктуры	Восстановление по регламенту	Руководитель ИТ и ИБ	После изменения состава группы
Рекламный кабинет	Маркетинг конкретного бренда	Работа с кампаниями	Владелец бренда	При смене проекта

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

Самая опасная строка — бессрочное исключение

В жизни сотрудники временно подменяют коллег, инженеры дежурят за другую команду, а подрядчику на время релиза нужны дополнительные права. Именно такие исключения позже забывают отозвать. Для временного разрешения укажите причину, ответственного и событие окончания. Временное назначение прав не должно незаметно менять постоянную роль сотрудника.

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

Разделите владельца секрета и администратора хранилища

Администратор хранилища может создать папку и выдать доступ технически. Но он не всегда знает, нужен ли сотруднику доступ к конкретному договору, CRM или платёжному сервису. За смысл разрешения отвечает владелец системы; ИТ исполняет решение, ИБ контролирует ограничения там, где риск достаточно высок.

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

Сверьте согласованные и фактические права

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

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

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

Подробнее: Что такое RBAC и зачем он нужен.

Для подрядчика всегда задавайте окончание доступа

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

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

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

Как связать матрицу с каталогом пользователей

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

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

В BearPass для разделения корпоративного хранилища предусмотрены роли, группы пользователей и «Пространства». О сценариях для холдингов можно прочитать в материале о мультитенантности. Эти механизмы реализуют выбранную модель, но не определяют за компанию, какие группы имеют право на какие секреты.

Увольнение — не единственный повод пересмотреть доступ

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

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

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

Пересмотр прав: не только раз в год

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

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

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

Сервисные аккаунты не увольняются — их забывают

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

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

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

Что показать руководству после внедрения

Руководству необязательно показывать список всех папок и ролей. Гораздо понятнее динамика нескольких показателей: какая доля секретов имеет владельца, сколько временных доступов просрочено, сколько времени проходит от уведомления об увольнении до фактического отзыва и сколько исключений осталось без согласования.

Сначала зафиксируйте исходные значения, затем сравните показатели за сопоставимые периоды. Если сокращается время выдачи прав, но растёт число общих бессрочных доступов, процесс требует корректировки.

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

Что делать, если отчёт выглядит хорошо, а доступы всё ещё лишние

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

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

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

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

• Как безопасно передать пароль подрядчику
• Как защитить аккаунты при увольнении

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