Матрица доступа к персональным данным: шаблон и порядок заполнения

Матрица доступа связывает четыре вещи: кто получает доступ, к каким персональным данным, зачем и какие действия может выполнять. Она помогает убрать права «на всякий случай», оформить выдачу и отзыв, а также сопоставить локальные правила с фактическими настройками систем.

Махаева Ольга

Эксперт по кадрам, трудовому законодательству, юрист, член Национального союза кадровиков. Преподаватель курса «Защита персональных данных»

Короткий ответ: что должно быть в матрице

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

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

Почему одной таблицы недостаточно

Доступы зависят от всего контура обработки: целей, состава данных, локальных актов, договоров, информационных систем, угроз, обязанностей оператора и процедур реагирования. Эти вопросы системно разбираются на курсе «Защита персональных данных: минимизируем риски».

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

Принцип: доступ только для рабочей цели

Федеральный закон № 152-ФЗ задаёт обязанности оператора и принципы обработки. Практически это означает: нельзя выдавать доступ только потому, что человеку «может пригодиться». Должны быть цель, функция и соразмерный объём данных.

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

Шаг 1. Соберите объекты доступа

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

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

Шаг 2. Опишите роли, а не конкретных людей

• Рекрутер.
• Специалист по кадровому делопроизводству.
• Расчётчик заработной платы.
• HR-бизнес-партнёр.
• Линейный руководитель.
• Системный администратор.
• Специалист информационной безопасности.
• Юрист или комплаенс.
• Внешний оператор по договору.

Роль — устойчивый набор функций. Конкретный сотрудник получает одну или несколько ролей по оформленному решению. Временное замещение задаётся сроком и автоматически попадает в пересмотр.

Шаг 3. Разделите операции

«Есть доступ» слишком грубо. Просмотр не равен выгрузке, а изменение — удалению. Минимальный набор кодов: V — просмотр; C — создание; E — изменение; X — выгрузка; D — удаление; A — администрирование. Для чувствительных наборов отдельно фиксируют массовую выгрузку и изменение прав.

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

Пример матрицы

Пример синтетический. «Технический A» не означает право использовать содержание в бизнес-целях; административный доступ требует отдельных ограничений и контроля.

Какие поля добавить к каждой строке

Процесс выдачи доступа

1. Руководитель выбирает типовую роль и объясняет задачу.
2. Владелец процесса подтверждает объём данных.
3. Ответственный за безопасность проверяет уровень прав и контроль.
4. Уполномоченный исполнитель создаёт учётную запись или назначает роль.
5. Сотрудник получает инструкцию и подтверждает ознакомление, если это предусмотрено.
6. Факт назначения попадает в реестр с датой и заявкой.
7. После срока или события право пересматривается или отзывается.

Устная просьба в мессенджере не должна становиться единственным доказательством выдачи доступа.

Приём, перевод, замещение и увольнение

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

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

Квартальный пересмотр

1. Выгрузить фактические права из систем.
2. Сопоставить их с матрицей и кадровыми ролями.
3. Найти уволенных, переведённых, временные и неиспользуемые записи.
4. Проверить массовые выгрузки и административные операции.
5. Получить подтверждение владельцев процессов.
6. Отозвать лишнее и сохранить доказательство.
7. Обновить типовую матрицу, если изменился процесс.

Периодичность зависит от риска и систем. Критичные права могут требовать более частого контроля, а событие перевода — немедленного.

Как связать матрицу с документами

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

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

Внешние сервисы и подрядчики

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

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

Что проверить в информационной системе

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

• Именные учётные записи и запрет общих логинов.
• Разделение ролей и административных полномочий.
• Своевременное создание, изменение и удаление записей.
• Журналы доступа и защищённость логов.
• Контроль массовых выгрузок и внешних носителей.
• Регулярный отчёт о фактических правах.

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

Как проверить матрицу выборкой

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

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

Что делать при лишнем доступе

1. Ограничить право без уничтожения доказательств.
2. Зафиксировать учётную запись, объём, период и возможные действия.
3. Передать информацию ответственным за безопасность и персональные данные.
4. Проверить логи, выгрузки и связанные учётные записи.
5. Оценить инцидент по действующей процедуре.
6. Устранить первопричину: роль, заявка, интеграция или ручное исключение.
7. Проверить аналогичные случаи.

Не исправляйте историю задним числом и не ограничивайтесь отзывом права без анализа возможного использования.

Типичные ошибки

• Матрица описывает программы, но не категории данных и цели.
• В ячейке только «да/нет», без операций.
• Права назначаются людям напрямую без типовых ролей.
• Временный доступ не имеет даты окончания.
• Бумажные архивы и почта исключены из периметра.
• Фактические настройки не сверяются с таблицей.
• Администраторский доступ считается обычным бизнес-доступом.
• Пересмотр проводится формально, без отзыва лишних прав.

Шаблон итогового реестра

В рабочем файле добавьте идентификатор заявки и дату последней проверки. Реальные персональные данные в этот шаблон не включайте.

Границы применения

Матрица не является сама по себе доказательством законности обработки и не заменяет организационные и технические меры. Она должна отражать фактические процессы и регулярно сверяться с системами.

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

Несовместимые полномочия

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

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

Аварийный доступ

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

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

Сервисные и интеграционные учётные записи

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

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

Пакет доказательств по доступу

Пакет должен быть соразмерным риску. Не собирайте лишние копии персональных данных ради доказательности самой процедуры.

Доступ на уровне полей и операций

Роль «HR» слишком широка для хорошей матрицы. Один специалист может видеть контактные данные и документы кандидата, другой — начисления, третий — только агрегированную аналитику. Разделяйте чтение, создание, изменение, выгрузку и удаление. Особенно внимательно относитесь к массовому экспорту: просмотр одной карточки и скачивание всей базы имеют разный риск.

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

Карточка заявки на доступ

Формулировка «как у коллеги» недостаточна: у коллеги могут быть исторически лишние права. Копирование допустимо только после сопоставления функций и проверки роли.

Периодическое подтверждение прав

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

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

Как использовать матрицу при инциденте

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

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

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

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

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

Практика вместо теории

Выстройте весь контур работы с персональными данными

На курсе «Защита персональных данных: минимизируем риски» вы разберёте требования 152-ФЗ, локальные документы, распределение ответственности, процессы работников и подготовку к проверкам. Матрица доступа станет частью целостной системы, а не отдельной таблицей.

Смотреть программу

Вопросы и ответы

• Нужно ли указывать фамилии сотрудников в матрице?

  Лучше хранить типовые роли отдельно от реестра назначений. В матрице — полномочия роли, в реестре — кто, когда и на каком основании получил её.

• Достаточно ли доступа «чтение» и «изменение»?

  Часто нет. Отдельно полезно учитывать создание, массовую выгрузку, удаление и администрирование, потому что риски и согласование различаются.

• Как часто пересматривать права?

  По событиям немедленно и периодически по риску. Квартальная сверка — практичный ориентир, но критичные права могут требовать более частого контроля.

• Кто должен согласовывать доступ?

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

• Можно ли вести матрицу в Excel?

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

• Можно ли вести матрицу доступа в обычной электронной таблице?

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

По теме