Проектирование прав доступа RBAC с ограничениями по объектам

Почему одного RBAC часто недостаточно

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

Проблема «чистого» RBAC в том, что он хорошо отвечает на вопрос «что может делать роль», но плохо отвечает на вопрос «с какими именно объектами». В итоге доступ расширяют «на всякий случай», а затем годами поддерживают исключения.

Типовые ситуации, где одного RBAC обычно недостаточно:

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

В таких случаях помогают ограничения по объектам (object-level): правила, которые сужают доступ по атрибутам объекта и пользователя. Самые частые варианты: «только свои записи», «только свой филиал», «только свой проект», «только кейсы с уровнем допуска N». Тогда роль задает общий набор действий (читать, создавать, согласовывать), а ограничения определяют границы.

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

Чтобы отличить требования безопасности от чистого удобства, полезен простой тест: если сотрудник увидит «чужой» объект, это создает риск (нарушение закона, договоров, внутренней политики) или просто будет мешать работе. В первом случае ограничения должны быть строгими и проверяемыми. Во втором чаще достаточно фильтров в интерфейсе и понятных очередей, без расширения прав.

Минимальный словарь: роли, объекты и атрибуты

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

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

Роли, разрешения, действия и объекты

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

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

Атрибуты: что мы сравниваем в правилах

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

У пользователя тоже есть атрибуты: филиал, подразделение, должность, членство в проектных группах. В простом случае сравнивают user.branch == object.branch или user in object.project_team.

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

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

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

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

С чего начать

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

Дальше привяжите операции к объектам: что именно человек просматривает или изменяет (заявка, договор, инцидент, клиентская карточка). Так быстрее видно, где нужны ограничения по объектам, а не новые роли.

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

Владелец данных и особые роли

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

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

Заранее решите, где нужны временные права: замещение на отпуск, дежурства 24/7, разовый доступ для расследования. Лучше иметь понятный механизм временных ролей и сроков, чем «вечные» исключения, которые потом невозможно объяснить.

Примеры политик для филиалов

Когда у компании есть филиалы, RBAC быстро упирается в вопрос: одна и та же роль (например, бухгалтер) должна видеть разные данные в зависимости от филиала. Поэтому к роли почти всегда добавляют ограничения по объектам: «какие именно записи доступны».

Минимальные атрибуты объектов

Удобно договориться, что у каждого бизнес-объекта (договор, заявка, сотрудник, инцидент, счет) есть хотя бы два поля: branch_id (филиал-владелец) и confidentiality (обычный, внутренний, конфиденциальный). Для данных, которые действительно общие, добавляют флаг cross_branch=true или project_scope=cross_branch.

Примеры правил

Ниже примеры правил для филиальной структуры в модели «RBAC + ограничения по объектам»:

• Базовое правило: читать и менять можно только объекты, где branch_id совпадает с филиалом пользователя. Это защищает от «случайных» утечек между городами.
• Руководитель филиала: доступ к данным своего филиала шире (например, видеть все заявки и отчеты филиала), но с ограничением по метке confidentiality=confidential. Такие объекты доступны только узкой группе (например, службе безопасности или HR) даже внутри филиала.
• Кросс-филиальная команда: роль дает доступ не «ко всем филиалам», а только к объектам, которые явно помечены как межфилиальные (cross_branch=true) и привязаны к конкретной инициативе (например, project_id).
• Центральный офис: доступ задается по функции, а не по географии. Финансы видят счета и платежи всех филиалов, но не кадровые документы; HR видит карточки сотрудников, но не коммерческие договоры. Здесь ограничения идут по типу объекта и атрибутам, а не только по branch_id.
• Временные исключения: «пожарный» доступ оформляется заявкой с конечной датой, причиной и обязательным журналированием действий. Лучше задавать его как отдельное разрешение с TTL, а не как временную смену роли.

Небольшой пример: бухгалтер филиала в Алматы видит счета только с branch_id=ALM. Если он включен в межфилиальный проект по обновлению ERP, то дополнительно видит только документы, где cross_branch=true и project_id=ERP2026, но не счета других филиалов вне проекта.

Примеры политик для проектов

В проектах RBAC быстро упирается в границы: одна и та же роль (например, инженер) может работать сразу в трех проектах, но видеть должна только «свое». Поэтому обычно добавляют ограничения по объектам: у каждого документа, задачи, письма или вложения есть project_id, а иногда еще status, owner_id, doc_type.

Ниже примеры политик для папок проекта, задач, актов, переписки и артефактов поставки (например, при внедрении инфраструктуры или интеграции ПО).

Набор понятных правил

• Участник проекта: читает и редактирует только объекты со своим project_id. Если человек добавлен в два проекта, доступ расширяется только на эти два project_id, а не «на все проекты отдела».

• Проектный менеджер: видит проект целиком (задачи, сроки, бюджетные документы, отчеты), но не видит персональные вложения по умолчанию. Например, вложение с флагом personal=true или типом doc_type=personal_note открывается только при отдельном разрешении «просмотр персональных вложений» и только когда это действительно нужно.

• Матрица доступа по статусам: у объекта есть status (черновик, на согласовании, утверждено, закрыто). Практичный вариант: участники проекта могут править «черновик» и «на согласовании», но «утверждено» только читают; «закрыто» читают все участники проекта, но удалять не может никто, кроме администратора хранения.

• Внешний подрядчик: получает доступ не «ко всему проекту», а к выделенному набору объектов. Например, только к задачам и папке «ТЗ и результаты», без финансов, внутренней переписки и персональных заметок. Плюс ограничение по времени: доступ действует до даты contract_end и автоматически прекращается.

• Запрет переноса объектов между проектами: менять project_id у объекта можно только с отдельным правом (например, reassign_project_object). Это защищает от тихой утечки, когда документ случайно «переезжает» в проект с более широким кругом доступа.

Короткий пример сценария

Представьте два параллельных проекта: «Серверная модернизация» и «ПО для бухгалтерии». Инженер участвует в первом, аналитик - во втором. Даже если у обоих роль «сотрудник проекта», фильтр по project_id не даст аналитику увидеть схемы сети, а инженеру - финансовые вложения по ПО. Проектный менеджер увидит общую картину по своему проекту, но если в задаче есть персональное вложение (например, скан паспорта для пропуска), оно останется закрытым без отдельного права.

Такие правила удобно описывать в виде «кто + какое действие + над какими объектами + при каких атрибутах». Тогда спор идет не о названиях ролей, а о проверяемых условиях.

Примеры политик для конфиденциальных кейсов

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

Классификация и базовые правила видимости

Удобно завести 4 уровня: обычный, ограниченный, конфиденциальный, особо конфиденциальный. Классификация хранится в поле, например case.classification, и участвует в правилах.

Пример набора политик (читается как «роль + условие на объект + действие»):

• Обычный: сотрудники поддержки филиала просматривают кейсы своего филиала при условии case.branch == user.branch.
• Ограниченный: просматривать могут только назначенная группа и владелец: user in case.assigned_group OR user == case.owner.
• Конфиденциальный: правило то же, но добавляется запрет на «просмотр по роли» даже для руководителей филиала (кроме явно добавленных в группу кейса).
• Особо конфиденциальный: доступ только у небольшой группы (например, служба безопасности) и владельца, плюс запрет на делегирование доступа без отдельного согласования.

Критичные действия и скрытие данных

Для операций с повышенным риском (закрытие, экспорт, удаление) часто работает «правило двух человек»: один сотрудник инициирует действие, второй подтверждает. Это снижает риск ошибок и злоупотреблений.

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

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

Чтобы не пропустить дыру, проверьте ожидания на тестовых пользователях:

• руководитель филиала без назначения в группу не видит «конфиденциальный» кейс;
• назначенный исполнитель видит кейс, но без PII и вложений, пока не выданы дополнительные права;
• экспорт и печать не работают без отдельного разрешения, даже при разрешенном просмотре;
• закрытие/удаление требует подтверждения вторым пользователем и оставляет понятный след в журнале действий.

Пошагово: как спроектировать политики RBAC + ограничения по объектам

Если начинать проектирование прав доступа RBAC без списка данных и правил по объектам, роли быстро превращаются в «суперправа». Ниже схема, которая помогает удержать модель простой и проверяемой.

Шаги проектирования

1. Опишите, что именно вы защищаете: объекты и их атрибуты. Например, у «Заявки в поддержку» есть филиал, проект, владелец, статус и признак конфиденциальности. У «Проекта» есть код, заказчик, руководитель и набор участников.

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

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

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

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

Исключения и срок действия

Чтобы модель не расползалась, заранее задайте процесс для исключений:

• кто может запросить временный доступ и на какой срок;
• кто утверждает (владелец данных, руководитель, ИБ);
• что считается основанием (инцидент, замещение сотрудника, аудит);
• как фиксируется и когда пересматривается;
• что происходит по истечении срока (автоотзыв).

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

Как тестировать политики: сценарии и проверяемые ожидания

Тестирование прав доступа удобно начинать не с кода, а с таблицы сценариев. По сути это матрица: роль x действие x тип объекта x атрибуты объекта. Атрибуты могут быть простыми (филиал, проект, уровень конфиденциальности, статус: активный или архивный).

Чтобы матрица не разрослась, выберите 5-10 самых частых действий и 3-5 критичных типов объектов. Для компании с филиалами и проектами это обычно «просмотр», «создание», «изменение», «выгрузка», «назначение исполнителя». По объектам: «проект», «задача», «документ», «кейс обращения».

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

• оператор филиала Алматы просматривает кейс своего филиала со статусом «обычный» - разрешено;
• тот же оператор пытается открыть кейс филиала Астана - запрещено (фильтр по филиалу);
• руководитель проекта «ERP-2026» редактирует документы проекта - разрешено, но только внутри своего проекта;
• участник проекта пытается выгрузить список всех кейсов (без фильтра проекта или филиала) - запрещено;
• сотрудник с ролью «поддержка» открывает конфиденциальный кейс уровня «секретно» без доп. допуска - запрещено.

Отдельно проверьте пограничные случаи. Они чаще всего ломают модель: перевод сотрудника между филиалами, смена роли, добавление в проект задним числом, архивирование проекта. Например: сотрудника перевели из Караганды в Алматы - с этого момента он не должен видеть старые объекты Караганды, кроме тех, где он явно назначен исполнителем (если такое правило предусмотрено).

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

Когда правила меняются, нужны регресс-тесты, которые всегда запускаются:

• по одному тесту «разрешено» и «запрещено» для каждого критичного действия;
• проверка доступа при смене филиала и при смене роли;
• проверка архивных проектов: просмотр да, изменение нет (если так задумано);
• проверка массовых операций (выгрузка, отчеты, поиск) с обязательными фильтрами;
• проверка обходов: прямой доступ по ID, через связанные объекты, через историю.

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

Частые ошибки и ловушки в моделях доступа

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

Слишком крупные роли и «дали и забыли»

Когда роль собирают по принципу «пусть человеку будет удобно», она быстро разрастается. В итоге роль подходит 5% пользователей, а остальные получают лишнее. Здоровый признак модели: роли описывают работу (задачи), а не людей (ФИО или отдел целиком), и у каждой роли есть владелец, который отвечает за изменения.

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

Смешивание прав на объект и прав на действие

Часто просмотр и «опасные» действия склеивают: раз видит карточку, значит может экспортировать, печатать, выгружать или смотреть вложения. Но экспорт - это перенос данных за пределы системы. Даже при правильных ограничениях по объектам он может нарушить политику.

Практичный подход: разделяйте права на действия (view, edit, export, print, delete) и проверяйте их отдельно, даже если объект один и тот же.

Ручные списки вместо атрибутов

Когда доступ строится на списках «кому можно», их перестают обновлять. При переводе в другой филиал или проект человек остается в старом списке. Надежнее опираться на атрибуты: филиал пользователя, принадлежность к проекту, уровень допуска, статус занятости. Списки оставляйте только там, где без них нельзя (например, очень узкая группа по согласованию).

Интеграции и сервисные учетные записи, про которые забыли

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

Проверьте минимум: отчеты и конструкторы отчетов (что можно собрать и выгрузить), печать и массовые выгрузки (кто может запускать), API-ключи и сервисные аккаунты (какие у них роли), фоновые задачи и интеграционные очереди (что читают и пишут), доступ администраторов к журналам и вложениям (нет ли «сквозного просмотра»).

Нет понятного процесса отзыва прав

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

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

Короткий чеклист и следующие шаги

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

Чеклист, который обычно спасает от сюрпризов:

• роли: 3-5 базовых ролей с простыми названиями и границами ответственности (кто что делает, а не «кто важнее»);
• объекты и атрибуты: перечень ключевых объектов (документ, заявка, кейс, проект) и 2-3 атрибута, которые реально режут доступ (филиал, проект, уровень конфиденциальности);
• исключения: редкие случаи (замещение на отпуск, временный доступ по заявке, расследования) и срок действия таких прав;
• журналы и аудит: что пишется в лог при доступе и отказе, кто это смотрит и как быстро можно восстановить картину событий;
• тестовые сценарии: проверки с ожидаемым результатом (разрешено/запрещено), включая негативные сценарии и попытки обойти ограничения.

Минимальный комплект артефактов можно держать компактным: таблица правил (роль + действие + объект + условия по атрибутам), словарь атрибутов (как заполняются, откуда берутся, какие значения допустимы) и список владельцев данных (кто отвечает за качество атрибутов и принимает решения по исключениям).

Чтобы начать с малого, выберите один процесс и не пытайтесь сразу описать все. Например, для сервис-деска это может быть только чтение и изменение заявок, где ограничения по объектам строятся по филиалу и проекту, а конфиденциальные кейсы выносятся в отдельные правила с более жесткими условиями.

Практичный план внедрения:

• пилот: один филиал или один процесс (например, обработка заявок) с реальными пользователями;
• настройка атрибутов: кто и когда обновляет «филиал», «проект» и «уровень конфиденциальности», и что делать при пустых значениях;
• прогон тестов: сценарии на каждый тип роли, плюс 2-3 «плохих» сценария (чужой филиал, чужой проект, повышенная конфиденциальность);
• обратная связь: фиксируйте, где правила мешают работе, и уточняйте не роли, а условия по объектам;
• масштабирование: переносите модель на другие филиалы и процессы, сохраняя подход к атрибутам и тестам.

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

Если нужна практическая реализация на уровне инфраструктуры (рабочие места, серверная часть, интеграции, аудит, сопровождение 24/7), это обычно удобнее делать вместе с системным интегратором. В Казахстане такие задачи можно обсудить с GSE.kz (gse.kz): компания занимается системной интеграцией и поддержкой корпоративных ИТ-систем, а также производит компьютеры и серверы в Казахстане, что часто важно для требований по локальному содержанию и прозрачности цепочки поставок.