Роли и доступы к персональным данным: RBAC, матрица доступов и как избавиться от «лишних» прав

Полное руководство для ИБ-специалистов, DPO и руководителей ИТ в условиях новых штрафов и растущих утечек

Почему разграничение доступа к ПДн стало вопросом выживания бизнеса

Представьте: менеджер по продажам, ушедший из компании полгода назад, по-прежнему имеет доступ к CRM с контактами 200 000 клиентов. Никто не заблокировал его учётную запись — просто забыли. Через несколько месяцев эта база появляется в даркнете.

Подобный сценарий — не фантастика. По данным исследования «СёрчИнформ» за 2024 год, с утечками данных столкнулись 48% российских компаний, и в большинстве случаев виновниками стали рядовые сотрудники, имевшие доступ к данным, который они уже не должны были иметь [12].

Ставки резко выросли: с 30 мая 2025 года в России действуют оборотные штрафы за повторные утечки ПДн — до 500 млн рублей или 3% годовой выручки [15]. Уголовная ответственность за незаконное обращение с персональными данными введена ещё раньше — в декабре 2024 года (ст. 272.1 УК РФ) [10].

В этой статье подробно разберём:

• что такое RBAC и почему без него управление доступом к ПДн невозможно;
• как построить матрицу доступов, которая действительно работает;
• почему «лишние» права накапливаются сами по себе и как с этим бороться;
• что требует российское законодательство — 152-ФЗ, приказы ФСТЭК, новый 420-ФЗ;
• какие инструменты и практики помогают сделать контроль непрерывным.

Материал ориентирован на ИБ-специалистов, DPO, руководителей ИТ и всех, кто отвечает за соответствие требованиям в области персональных данных.

Основы: что такое RBAC и как он работает применительно к персональным данным

Четыре элемента классической модели RBAC

Role-Based Access Control (RBAC), или управление доступом на основе ролей — это подход, при котором права доступа субъектов системы к объектам группируются с учётом специфики их применения, образуя роли [1]. Вместо того чтобы назначать права каждому пользователю вручную, организация создаёт набор ролей (например, «оператор ввода данных», «аналитик», «администратор ИСПДн»), а затем просто присваивает сотруднику нужную роль.

Формально модель описывается четырьмя базовыми элементами:

1. Субъекты (S) — пользователи, которым назначаются роли.
2. Роли (R) — логические группы прав, соответствующие функциям в организации.
3. Разрешения (P) — конкретные права на объекты доступа: читать, записывать, изменять, удалять.
4. Сессии — временные соединения субъекта с набором разрешений через активированные роли [1].

Ключевое правило: разрешения назначаются только через роли, но никогда напрямую субъекту. Это исключает неконтролируемые отношения «пользователь — право», которые со временем превращаются в непрозрачную паутину привилегий [1].

Модель была формализована Феррайоло и Куном в 1992 году, а в 2004 году принята Американским национальным институтом стандартов (ANSI/INCITS) как единый стандарт [1]. В России её применение прямо предусмотрено приказами ФСТЭК № 21 и № 17 как один из допустимых методов управления доступом в ИСПДн [5, 6].

RBAC vs ABAC vs MAC: какую модель выбрать для ИСПДн

В практике управления доступом к персональным данным используются три основных модели.

Первая — ролевая (RBAC). Права определяются ролью пользователя. Удобна в большинстве корпоративных сценариев, хорошо масштабируется, проста в администрировании. Основной недостаток: недостаточная гибкость в контекстно-зависимых ситуациях (например, доступ только из офисной сети или только в рабочее время) [8].

Вторая — атрибутная (ABAC). Права определяются набором атрибутов: роль, местоположение, время, устройство, метки данных. Более гибкая, но значительно сложнее в настройке и аудите [8]. Подходит для зрелых организаций с несколькими уровнями конфиденциальности ПДн.

Третья — мандатная (MAC). Уровни допуска жёстко иерархичны. Применяется преимущественно в государственных и оборонных системах. Сложна во внедрении в коммерческих организациях.

На практике российские компании чаще всего начинают с RBAC как фундамента, при необходимости дополняя его элементами ABAC для особо чувствительных категорий ПДн (биометрические, медицинские).

Иерархия ролей и принцип разделения обязанностей

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

Важнейший принцип — Separation of Duties (SoD), разделение обязанностей. Согласно ему, одно и то же лицо не должно одновременно иметь возможность создать учётную запись и авторизоваться под ней, или вносить данные в систему и верифицировать их [1]. Для ИСПДн это означает, что, например, ответственный за ввод ПДн не должен иметь права на их удаление без согласования.

Матрица доступов к ПДн: от теории к практике

Что такое матрица доступов и зачем она нужна

Матрица доступов — это документ или программный артефакт, в котором в явном виде перечислены: какие роли (или субъекты) имеют какие права на какие категории ПДн и в каких системах. По горизонтали — субъекты или роли, по вертикали — объекты доступа (таблицы БД, папки файловой системы, модули CRM, 1С и т.д.), в ячейках — разрешённые операции (чтение, запись, изменение, удаление, экспорт).

Зачем она нужна:

1. Без матрицы аудит прав превращается в выемку данных из десятков систем вручную — это занимает недели и при этом всё равно даёт неполную картину.
2. При проверке Роскомнадзора или внутреннем аудите матрица — первый документ, который запрашивают инспекторы.
3. Только наглядная матрица позволяет увидеть «белые пятна» — системы, где ПДн обрабатываются, но разграничение прав не описано.
4. Матрица — основа для управления изменениями: при переводе сотрудника или подключении нового сервиса сразу видно, что нужно пересмотреть.

Как построить матрицу: пошаговый подход

Шаг 1. Инвентаризация источников ПДн. Составьте перечень всех систем, в которых обрабатываются ПДн: базы данных, файловые хранилища, CRM, ERP (1С), почта, AD/LDAP, API-интеграции, аналитические платформы. Именно неполнота этого списка — главная причина, по которой риски остаются невидимыми.

Шаг 2. Классификация данных по категориям. Разделите ПДн на категории в соответствии с 152-ФЗ: общие, специальные (здоровье, религия, политические взгляды), биометрические. Для каждой категории определите требуемый уровень защищённости по ПП № 1119.

Шаг 3. Определение ролей. Сформируйте список ролей, отражающих реальные бизнес-функции, а не просто должности. Например: «оператор колл-центра», «аналитик данных», «HR-менеджер», «системный администратор ИСПДн», «DPO», «внешний аудитор».

Шаг 4. Заполнение матрицы. Для каждой комбинации «роль — система — категория ПДн» укажите допустимые операции: чтение (R), запись (W), изменение (U), удаление (D), экспорт (E), без доступа (-).

Шаг 5. Согласование с владельцами систем и DPO. Матрица должна быть согласована с бизнесом, а не спущена сверху ИБ-подразделением. Именно здесь часто выявляются ситуации, когда реальные права не соответствуют задокументированным.

Шаг 6. Верификация в системах. Проверьте, что права, указанные в матрице, фактически настроены в каждой системе. Расхождения — это и есть риски.

Шаг 7. Регулярный пересмотр. Матрица — живой документ. Рекомендуется пересматривать её не реже одного раза в 6 месяцев, а также при любых организационных изменениях [20].

Типичные роли в корпоративных ИСПДн и их права

В большинстве организаций, обрабатывающих ПДн, встречаются следующие роли:

1. Оператор ввода ПДн — только запись и чтение данных в пределах своей очереди; без права удаления и экспорта.
2. Аналитик — чтение агрегированных и/или обезличенных данных; без доступа к «сырым» ПДн без обоснования.
3. HR-менеджер — чтение и изменение данных сотрудников; без доступа к данным клиентов.
4. Администратор ИСПДн — управление учётными записями и правами; без права просматривать содержимое ПДн (разделение функций).
5. DPO/ответственный по ПДн — чтение журналов доступа и метаданных; аудит без права изменения.
6. Внешний подрядчик — строго ограниченный временный доступ к конкретной подсистеме; обязательный журнал действий; автоматическая деактивация по истечении срока.
7. Системный интегратор/API — технические учётные записи с минимальным набором операций; ротация ключей.

Проблема «лишних» прав: privilege creep и его последствия

Как накапливаются избыточные права

Privilege creep (дрейф привилегий, накопление лишних прав) — явление, когда пользователь накапливает права доступа, которые ему уже не нужны, но и не были отозваны. Чаще всего это происходит при смене должности или отдела: новые права выдаются, а старые остаются [52].

Классический сценарий: сотрудник начинал в колл-центре и имел доступ к контактной базе клиентов. Год назад перешёл в отдел маркетинга и получил доступ к аналитической платформе. Ещё через полгода стал руководителем — добавили административные права в CRM. При этом ни один из предыдущих доступов не был отозван. В итоге этот человек обладает правами трёх разных ролей одновременно, хотя ни одна из них в полном объёме ему не нужна [60].

Другой типичный вектор — временный доступ, который никто не закрыл. «Дал доступ подрядчику на время проекта — и забыл». По данным ГК «Солар», наибольшую угрозу среди инсайдерских векторов представляют именно незаблокированные аккаунты уволенных сотрудников и взломанные аккаунты подрядчиков [7].

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

Статистика инцидентов, связанных с избыточным доступом

Данные международных исследований подтверждают: избыточные права — не теоретическая проблема.

По данным отчёта Verizon DBIR 2024, 68% утечек включали элемент человеческого фактора — ошибки, социальная инженерия или злоупотребление привилегиями [76]. Отчёт IBM Cost of Data Breach 2024 зафиксировал, что 40% нарушений связаны с данными, хранящимися в нескольких средах, а более трети — с «теневыми данными» в неконтролируемых источниках [59].

По данным ГК «Солар», 40% успешных кибератак в 2024 году начались со взлома корпоративных аккаунтов — в 2023 году доля была вдвое ниже (13%) [7].

Особенности инсайдерских утечек ПДн в России

Российская специфика добавляет отдельное измерение. Более половины всех уголовных дел по ст. 272 УК РФ (неправомерный доступ к компьютерной информации) возбуждены против работников отрасли связи. По данным «СёрчИнформ», собранным в 2024 году и первой половине 2025 года, их доля в уголовных делах о нарушениях ИБ составляет 68% [30].

Ключевая деталь: эксперты отмечают, что «пробивом» занимаются именно действующие сотрудники, поскольку доступ к внутренней инфраструктуре закрывается в день увольнения — но не до него [30]. Это означает, что само наличие легитимного, но избыточного доступа является прямым источником риска.

В 2024 году утечки данных затронули 48% российских компаний по данным «СёрчИнформ». Большинство утечек носило случайный характер — нарушение базовых норм цифровой гигиены; на преднамеренные действия пришлось около трети инцидентов [12].

Регуляторные требования к управлению доступом к ПДн в России

152-ФЗ и принцип минимальной достаточности

Федеральный закон № 152-ФЗ «О персональных данных» устанавливает общий принцип: ПДн должны обрабатываться в объёме, не превышающем необходимого для заявленных целей (ст. 5). Хотя закон прямо не упоминает RBAC, из этого принципа следует требование ограничивать доступ к ПДн кругом лиц, которым они необходимы для выполнения своих функций [3].

С 1 сентября 2025 года вступила в силу новая ст. 13.1 152-ФЗ: персональные данные, преобразованные в обезличенную форму, можно обрабатывать без согласия гражданина, если обезличивание исключает прямую идентификацию [4]. Это открывает возможности для аналитических ролей, которые получают доступ не к «сырым» ПДн, а к агрегированным и обезличенным профилям.

Приказы ФСТЭК № 21 и № 17: что требуют конкретно

Приказ ФСТЭК России № 21 от 18.02.2013 (с изменениями) — основной нормативный документ для коммерческих ИСПДн. Он содержит раздел «Управление доступом» (УПД) с конкретными мерами [5]:

1. УПД.1 — управление учётными записями пользователей (заведение, активация, блокирование, уничтожение). Обязательно для всех уровней защищённости (УЗ1–УЗ4).
2. УПД.2 — реализация методов разграничения доступа, в том числе ролевого. Обязательно для УЗ1–УЗ4.
3. УПД.4 — разделение полномочий (ролей) пользователей, администраторов и лиц, обеспечивающих функционирование системы.
4. УПД.5 — назначение минимально необходимых прав и привилегий (принцип наименьших привилегий).
5. АНЗ.5 (контроль) — контроль правил генерации паролей, реализации правил разграничения доступа, полномочий пользователей. Обязательно для УЗ1 и УЗ2.

Приказ ФСТЭК № 17 применяется к государственным ИС и предъявляет аналогичные, но более жёсткие требования. При проектировании системы защиты оператор обязан явно определить методы управления доступом (дискреционный, мандатный, ролевой) и правила разграничения для всех субъектов и объектов доступа [6].

Таким образом, и RBAC, и принцип наименьших привилегий являются не рекомендацией, а обязательным требованием для любой ИСПДн в России, независимо от её уровня защищённости.

420-ФЗ 2024: новая ответственность и её связь с доступами

Федеральный закон № 420-ФЗ от 30.11.2024, вступивший в силу с 30 мая 2025 года, кардинально изменил экономику нарушений в области ПДн [15].

Ключевые параметры новой ответственности:

1. За первичную утечку ПДн от 1 тыс. до 10 тыс. субъектов — штраф для юрлиц от 3 до 5 млн рублей.
2. За утечку ПДн свыше 100 тыс. субъектов — от 10 до 15 млн рублей [71].
3. За повторную утечку (оборотный штраф) — от 1 до 3% годовой выручки, не менее 25 млн и не более 500 млн рублей [66].
4. Введена уголовная ответственность по ст. 272.1 УК РФ за неправомерное обращение с ПДн (продажа, незаконное распространение).
5. Оператор обязан уведомить Роскомнадзор об утечке в течение 24 часов, провести расследование и представить повторное уведомление в течение 72 часов.

Важная деталь: закон предусматривает смягчение ответственности, если оператор документально подтверждает расходы на ИБ не менее 0,1% выручки ежегодно в течение трёх лет, соблюдение требований к защите ПДн и отсутствие отягчающих обстоятельств [70]. Это прямо стимулирует вкладываться в системы контроля доступа и делать их проверяемыми.

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

Принцип наименьших привилегий (PoLP) как основа безопасной работы с ПДн

Что такое PoLP и почему он критичен именно для ПДн

Принцип наименьших привилегий (Principle of Least Privilege, PoLP) — это практика, при которой каждому субъекту (пользователю, процессу, программе) предоставляются только те права, которые ему необходимы для выполнения конкретной задачи, и ничего сверх того [17].

Применительно к ПДн PoLP означает:

• сотрудник отдела маркетинга имеет доступ к системе CRM, но не к персональным данным клиентов в аналитической платформе [17];
• оператор колл-центра видит только те поля, которые необходимы для обработки обращения;
• технические учётные записи API имеют права только на чтение конкретных таблиц, но не на удаление.

Реализация PoLP включает несколько практических техник [56]:

1. Минимальные права по умолчанию для всех новых аккаунтов — привилегии повышаются только по обоснованному запросу.
2. Разделение привилегий — субъекты разделены на группы минимального размера по принципу «необходимости знать».
3. Just-in-time (JIT) доступ — привилегированный доступ предоставляется только на время выполнения конкретной задачи, затем автоматически отзывается.
4. Регулярный аудит привилегий — существующие права периодически пересматриваются и отзываются, если они больше не нужны.

PoLP и концепция Zero Trust

Принцип наименьших привилегий — одна из составных частей концепции Zero Trust («нулевое доверие»). Zero Trust предполагает, что ни один пользователь или устройство внутри периметра не считаются доверенными по умолчанию. Каждый запрос доступа проверяется заново с учётом контекста: кто запрашивает, откуда, в какое время, с какого устройства [13].

Для ИСПДн это особенно актуально: принцип «внутри сети безопасно» давно устарел. Атаки через скомпрометированных подрядчиков, через заражённые устройства внутри периметра, через украденные учётные данные — всё это реальные векторы, которые нейтрализуются именно сочетанием PoLP и Zero Trust.

Практическая часть: чек-лист по построению RBAC и контролю доступа к ПДн

Ниже — практический чек-лист для организации, которая хочет выстроить контроль доступа к ПДн на уровне, соответствующем требованиям 152-ФЗ, приказов ФСТЭК и лучшим практикам.

Инвентаризация и классификация

1. Составьте полный реестр информационных систем, в которых хранятся или обрабатываются ПДн (включая почту, файловые серверы, облачные хранилища, API-интеграции, 1С, CRM, аналитические системы).
2. Классифицируйте ПДн по категориям: общие, специальные, биометрические.
3. Определите уровень защищённости (УЗ) каждой ИСПДн по ПП № 1119.
4. Зафиксируйте владельцев каждой системы и ответственных за данные.

Проектирование ролевой модели

1. Разработайте каталог ролей, отражающих реальные бизнес-функции. Избегайте ролей «один в один с должностью» — это ведёт к избыточному количеству ролей.
2. Для каждой роли явно определите: к каким системам и категориям ПДн есть доступ, какие операции разрешены.
3. Реализуйте разделение обязанностей (SoD): ввод ПДн и их удаление — разные роли.
4. Задокументируйте роли в матрице доступов; согласуйте с DPO и владельцами систем.

Управление жизненным циклом доступа

1. Внедрите процесс «onboarding»: новый сотрудник получает минимальные права по умолчанию, расширение — только по заявке с обоснованием.
2. Внедрите процесс «offboarding»: блокировка всех учётных записей в день увольнения, без исключений.
3. При переводе сотрудника — немедленный отзыв ненужных старых ролей (не «добавить новую», а «заменить»).
4. Для подрядчиков: временный доступ с автоматической датой истечения и журналом действий.

Аудит и контроль

1. Проводите ревизию матрицы доступов не реже одного раза в 6 месяцев [20].
2. Ежеквартально проверяйте наличие «мёртвых» учётных записей (уволенных, неактивных, тестовых).
3. Ведите журналы доступа к ПДн в разрезе ролей и пользователей; храните не менее 1 года.
4. Разделите права администратора системы и администратора ИБ.
5. Настройте автоматические алерты при появлении новых полей с ПДн или новых интеграций (это зоны роста риска).

Документация для регулятора

1. Зафиксируйте в Политике обработки ПДн порядок разграничения доступа.
2. Подготовьте и актуализируйте Перечень лиц, допущенных к обработке ПДн.
3. Документируйте все случаи изменения прав доступа (кто запросил, кто согласовал, когда вступило в силу).

Типичные ошибки и риски при управлении правами доступа

Анализ инцидентов и регуляторных проверок позволяет выделить наиболее характерные ошибки.

Ошибка 1. «Суперроль» для администраторов. Системный администратор имеет полный доступ ко всем ПДн «для поддержки». На практике это означает, что взлом его учётной записи сразу открывает весь массив данных. Правило: администратор системы управляет инфраструктурой, но не видит содержимого ПДн — это разные роли с разными правами.

Ошибка 2. Массовый импорт прав из AD без проверки. При миграции или интеграции систем права часто импортируются «как есть» — вместе с устаревшими группами, «временными» разрешениями пятилетней давности и правами уволенных сотрудников.

Ошибка 3. Ролевая модель в документах не соответствует реальным настройкам в системах. Это особенно часто встречается в компаниях, где ИБ-документация готовится «под аудит», а реальные права никто не верифицировал.

Ошибка 4. Подрядчик с неограниченным доступом. Компания даёт внешнему разработчику доступ к продакшн-базе данных «для диагностики» — и забывает его закрыть.

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

Ошибка 6. Нет процесса для смены ролей. Когда сотрудник меняет должность, новые права выдаются, а старые остаются — никакого формального процесса «замены роли» не существует.

Ошибка 7. Единственный признак контроля — ежегодный аудит. При динамичном IT-ландшафте (новые сервисы, интеграции, подрядчики) ежегодный аудит устаревает за несколько недель после проведения.

Риски, которые создаёт каждая из этих ошибок:

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

Автоматизация и инструменты: IdM/IAM, PAM, DCAP

Ручное управление правами доступа работает до масштаба примерно 50–100 сотрудников. Дальше — только автоматизация.

IdM/IAM (Identity Management / Identity and Access Management) — системы централизованного управления учётными записями и правами. Обеспечивают автоматическое предоставление и отзыв доступа по событиям HR-системы (приём, увольнение, перевод), ролевую модель, журналирование, аудит. Российский рынок IdM/IAM активно растёт: по оценке аналитиков, мировой объём сегмента в 2024 году составил около $17 млрд, прогноз роста — 8% в год до 2035 года [7]. На российском рынке представлены как отечественные решения (в том числе сертифицированные ФСТЭК), так и доработанные западные.

PAM (Privileged Access Management) — управление привилегированным доступом. Специализируется на контроле административных и сервисных учётных записей: проксирование сессий, запись действий, временный JIT-доступ, ротация паролей. Особенно важен для администраторов ИСПДн и технических интеграций [14].

DCAP (Data-Centric Audit and Protection) / DAG (Data Access Governance) — системы аудита и управления доступом к данным. Анализируют, кто реально обращается к файлам и базам данных, выявляют избыточные права, строят карту доступа к ПДн [19]. Именно DCAP-решения позволяют поддерживать актуальную «матрицу доступа» в автоматическом режиме.

DLP (Data Loss Prevention) — дополнительный слой: контроль передачи данных вовне, блокировка нежелательных операций с ПДн.

SIEM (Security Information and Event Management) — агрегация журналов событий из всех источников, корреляция инцидентов, оповещение об аномалиях.

Эффективная архитектура контроля доступа к ПДн строится на сочетании IdM (жизненный цикл прав) + PAM (привилегированный доступ) + DCAP (фактический контроль данных) + SIEM (мониторинг).

Тренды: куда движется управление доступом в 2025–2026 годах

Несколько тенденций, наблюдаемых в российском и международном контексте.

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

Вторая: переход от периодического аудита к непрерывному мониторингу. Ежегодные и даже ежеквартальные проверки недостаточны при темпе изменений современного IT-ландшафта. Инструменты DCAP и IAM обеспечивают мониторинг в режиме реального времени: появление нового поля с ПДн в базе данных, новая интеграция, новый сервисный аккаунт — всё это сразу попадает в поле зрения.

Третья: обезличивание как инструмент управления доступом. Новая ст. 13.1 152-ФЗ (с 1 сентября 2025 года) создаёт регуляторную основу для архитектур, где аналитические роли работают только с обезличенными данными, а доступ к «сырым» ПДн строго ограничен [4]. Это позволяет одновременно соответствовать требованиям регулятора и снижать риски.

Четвёртая: автоматизация offboarding. По данным ГК «Солар», незаблокированные аккаунты уволенных — один из главных векторов инсайдерских атак [7]. Интеграция HR-системы с IAM и автоматическое блокирование всех доступов в момент фиксации увольнения становится отраслевым стандартом.

Пятая: рост ответственности за контрагентов. Треть нарушений безопасности в 2025 году по данным Verizon DBIR связана с третьими сторонами [80]. Для операторов ПДн это означает необходимость формального управления доступом подрядчиков: договорные ограничения, технические средства контроля, регулярная верификация.

«Пятый фактор»: непрерывный контроль ПДн как процесс

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

Именно эту задачу решает платформа Пятый фактор — on-prem-решение для автоматического обнаружения, инвентаризации и контроля персональных данных в корпоративных системах (БД, хранилища, почта, AD/LDAP, CRM, 1С, API).

Принципиальное отличие от классических подходов: платформа работает только с метаданными, структурой и агрегатами — без передачи и хранения «сырых» ПДн. Это означает, что само решение не становится источником дополнительного риска — соблюдается принцип privacy-by-design.

Что даёт «Пятый фактор» применительно к задачам этой статьи:

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

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

Непрерывный контроль как процесс, а не разовый аудит

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

Ключевые выводы:

1. RBAC — необходимая основа, но недостаточная. Ролевая модель деградирует без регулярного пересмотра и верификации в реальных системах.
2. Матрица доступов — инструмент видимости. Без неё нельзя ни управлять правами на масштабе, ни пройти аудит.
3. Privilege creep — системная проблема, которую нельзя решить разовыми проверками. Нужен процесс управления жизненным циклом доступа.
4. Регуляторные требования в России жёсткие и ужесточаются. Приказы ФСТЭК обязывают реализовать RBAC и PoLP технически; 420-ФЗ делает ценой бездействия до 500 млн рублей.
5. Автоматизация не роскошь, а необходимость. IdM, DCAP, PAM — инструменты, без которых контроль доступа на масштабе от 100 сотрудников неэффективен.
6. Непрерывный мониторинг важнее периодического аудита. Лучший способ не допустить инцидент — узнать о новом риске в момент его появления, а не через полгода.

Что делать прямо сейчас:

• Провести инвентаризацию всех систем с ПДн и убедиться, что список полный.
• Актуализировать матрицу доступов или построить её, если её нет.
• Проверить аккаунты уволенных за последние 12 месяцев.
• Ввести формальный процесс offboarding с блокировкой всех доступов в день увольнения.
• Запланировать ревизию прав не реже чем раз в 6 месяцев.

Источники

[1] Управление доступом на основе ролей — Википедия — https://ru.wikipedia.org/wiki/Управление_доступом_на_основе_ролей

[2] Ролевая модель управления доступом (RBAC) — SpectrumData — https://spectrumdata.ru/blog/proverka-soiskatelya/rolevaya-model-upravleniya-dostupom-rbac-chto-eto-i-zachem-ona-nuzhna/

[3] Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных» — КонсультантПлюс — https://www.consultant.ru/document/cons_doc_LAW_61801/

[4] 152-ФЗ о персональных данных в 2025–2026 годах — Business.ru — https://www.business.ru/article/5705-152-fz-o-personalnyh-dannyh-gg

[5] Приказ ФСТЭК России от 18.02.2013 № 21 — официальный сайт ФСТЭК — https://fstec.ru/dokumenty/vse-dokumenty/prikazy/prikaz-fstek-rossii-ot-18-fevralya-2013-g-n-21

[6] Приказ ФСТЭК России от 11.02.2013 № 17 — официальный сайт ФСТЭК — https://fstec.ru/normotvorcheskaya/akty/53-prikazy/702-prikaz-fstek-rossii-ot-11-fevralya-2013-g-n-17

[7] Обзор рынка IdM/IAM/IGA 2025 — Anti-Malware.ru — https://www.anti-malware.ru/analytics/Market_Analysis/IdM-IAM-IGA-2022

[8] RBAC vs ABAC — подходы к контролю доступа — Гладиаторы ИБ — https://glabit.ru/blog/podhody-k-kontrolyu-dostupa-rbac-vs-abac

[9] Принцип наименьших привилегий — Solar DAG — https://rt-solar.ru/products/solar_dag/blog/4675/

[10] Утечки данных в России — TAdviser — https://www.tadviser.ru/index.php/Статья:Утечки_данных_в_России

[11] Россия: утечки информации ограниченного доступа, 2022–2023 — ICT.Moscow / ГК InfoWatch — https://ict.moscow/research/rossiia-utechki-informatsii-ogranichennogo-dostupa-2022-2023-gody/

[12] 48% российских компаний столкнулись с утечками данных в 2024 году — Anti-Malware.ru / СёрчИнформ — https://www.anti-malware.ru/news/2025-02-20-121598/45326

[13] Принцип наименьших привилегий — Makves — https://makves.ru/blog/polp/

[14] Что такое IAM и PAM — Oberig IT — https://oberig-it.com/ru/stati/chto-takoe-iam-i-pam-ponimanie-razniczy-mezhdu-upravleniem-identifikacziej-i-dostupom-i-upravleniem-privilegirovannym-dostupom/

[15] Новые штрафы за ПДн с 30.05.2025 — КонсультантПлюс — https://www.consultant.ru/legalnews/28492/

[16] Оборотные штрафы за утечку ПДн — Pro Бизнес Новости — https://probusiness.news/probusiness/korporativny/oborotnye-shtrafy-za-utechku-personalnykh-dannykh-s-2025-goda

[17] Принцип минимальных привилегий — Trend Micro — https://www.trendmicro.com/ru_ru/what-is/what-is-zero-trust/principle-of-least-privilege.html

[18] Права доступа: что это такое, как контролировать — Solar InRights — https://rt-solar.ru/products/solar_inrights/blog/4636/

[19] Privilege creep: как обнаружить и предотвратить — MiniOrange — https://www.miniorange.com/blog/privilege-creep-detection-and-prevention/

[20] Аудит доступа к конфиденциальным данным — Falcongaze — https://falcongaze.com/ru/pressroom/publications/informacionnaya-bezopasnost-v-otraslyah/audit-dostupa-i-diskrecionnoe-upravlenie-dostupom.html

[21] Spotting Privilege Creep — AdminByRequest — https://www.adminbyrequest.com/en/blogs/spotting-privilege-creep-how-hidden-access-rights-threaten-security

[22] Verizon 2024 DBIR — Security Magazine — https://www.securitymagazine.com/articles/100629-verizon-2024-data-breach-report-shows-the-risk-of-the-human-element

[23] Verizon DBIR 2025 — Mimecast — https://www.mimecast.com/blog/verizon-60-of-breaches-involve-human-error/

[24] GDPR Access Control Best Practices 2026 — Konfirmity — https://www.konfirmity.com/blog/gdpr-access-control-best-practices

[25] ISO 27001 Annex A.9 Access Control — ISMS.online — https://www.isms.online/iso-27001/annex-a-9-access-control/

[26] InfoWatch: утечки ПДн в России выросли на 30% в 2024 — https://www.infowatch.ru/company/presscenter/news/kolichestvo-slitykh-personalnykh-dannykh-v-dve-tysyachi-dvadtsat-chetvertom-godu-vyroslo-na-tret

[27] Утечки ПДн в России: виновные сотрудники связи — Audit-it.ru — https://www.audit-it.ru/news/soft/1120605.html

[28] Принцип наименьших привилегий — Kaspersky Энциклопедия — https://encyclopedia.kaspersky.ru/glossary/principle-of-least-privilege-polp/