Матрица ролей и прав: как описать доступы без сюрпризов

Зачем малому бизнесу матрица доступов

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

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

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

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

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

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

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

Из чего состоит матрица: роли, действия, ресурсы

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

Роль - это «кто» в компании (бухгалтер, менеджер продаж, оператор склада, руководитель). Ресурс - это «что» вы защищаете (сервис, раздел, проект, папка, отчет). Действие - что можно делать с ресурсом. А право - итоговая связка «роль + действие + ресурс» (часто с условиями, например «только свой проект» или «без экспорта»).

Ресурсы: что именно вы защищаете

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

Обычно ресурсом считают:

• сервис целиком (CRM, бухгалтерия, хранилище файлов)
• модуль или раздел внутри сервиса (счета, сделки, склад)
• проект или рабочее пространство (проект клиента А, проект клиента Б)
• папку или документ ("Договоры", конкретный шаблон)
• таблицу или реестр ("База клиентов", "Заявки")

Если вы пишете матрицу для ИИ (например, чтобы потом собрать доступы в приложении через чат), называйте ресурсы так, чтобы их легко найти в интерфейсе: «CRM / Сделки» лучше, чем просто «продажи».

Действия: что человек может делать

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

Чаще всего хватает пяти действий:

• просмотр
• создание
• изменение
• удаление
• экспорт (или выгрузка/скачивание)

Экспорт почти всегда стоит выделять отдельно. Во многих сервисах человек может «смотреть», но экспорт превращает просмотр в перенос данных наружу, и это уже другой уровень риска.

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

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

Инвентаризация: что именно нужно защищать

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

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

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

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

Быстрый способ собрать инвентарь за 1-2 часа

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

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

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

Точки риска, которые стоит пометить отдельно

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

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

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

Шаг за шагом: как составить матрицу в таблице

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

1) Соберите роли из реальных функций

Выпишите роли простыми словами, по задачам. Часто одна должность распадается на две роли, а иногда одна роль покрывает несколько должностей.

Для старта держите себя в рамках:

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

2) Зафиксируйте сценарии работы (3-5 задач на роль)

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

Пример для роли «менеджер продаж»: вести сделку в CRM, готовить коммерческое предложение, выставлять счет, смотреть статус оплаты, передавать клиента в поддержку.

3) Постройте таблицу: роли по строкам, права по столбцам

В таблице строки - роли. Столбцы - не «сервисы», а связка «ресурс + действие». Так проще заметить, где право лишнее.

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

4) Отметьте минимум необходимого

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

Практичный прием: использовать простые метки вроде «Да», «Нет», «Только свои», «Только чтение». Во многих процессах «только свои» важнее, чем просто «можно/нельзя».

5) Отдельно вынесите админские права и условия

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

Рядом запишите условия выдачи: кто утверждает, на какой срок, нужен ли второй согласующий, как фиксируется выдача и отзыв. Даже строка «выдается на 24 часа по запросу руководителя» уже снижает риски.

6) Согласуйте матрицу с владельцами процессов

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

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

Как описывать права понятным языком для ИИ

Чтобы ИИ правильно собрал доступы, ему нужны не общие слова, а точные правила. Самый понятный шаблон: роль + действие + ресурс + условие. Если чего-то нет (например, условий), так и пишите: «без условий».

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

Формула прав: одно правило - одна строка

Описывайте права короткими «атомарными» правилами, где каждое действие проверяемо. Например:

Роль: Менеджер продаж
Действие: редактировать
Ресурс: карточка клиента (CRM)
Условие: только клиенты своего отдела; поле "ИНН" - только чтение
Запрет: нельзя удалять карточки клиентов
Проверка условия: руководитель отдела продаж подтверждает список отделов и сотрудников

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

Границы и запреты лучше писать явно

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

Короткая самопроверка:

• В каждом праве есть действие (читать, создавать, редактировать, удалять, выгружать).
• Ресурс назван конкретно (раздел, сущность, отчет, папка, таблица).
• Условия измеримы (по отделу X, по проекту Y), а не «по необходимости».
• Запреты выделены отдельно (например, «нельзя удалять», «нельзя экспортировать»).
• Понятно, кто и как подтверждает условия (руководитель, владелец процесса, админ).

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

Ограничения и исключения, которые часто забывают

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

Первое, что стоит фиксировать, это временные права. Важно не просто написать «можно на время», а указать срок, кто согласует и как именно доступ отзывается. Если вы просите ИИ собрать доступы (например, в TakProsto, где роли и ограничения можно описать текстом), без этих деталей система будет додумывать. А в доступах любые догадки опасны.

Временный доступ и замены

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

Полезно договориться о простом правиле: любой доступ на замену действует до конкретной даты и привязан к причине. Например: «Менеджер Иван заменяет бухгалтера Ольгу с 10 по 24 января, только для оплаты счетов, без права менять реквизиты контрагентов». Этого достаточно, чтобы не выдать лишнего.

Условия, подтверждения и опасные операции

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

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

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

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

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

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

Важно прописывать не только «можно», но и «нельзя». Например, менеджеру нельзя удалять сделки и менять платежные реквизиты, а поддержке нельзя выгружать всю базу клиентов.

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

Для увольнения и быстрой блокировки заранее отметьте минимальный набор действий (это тоже часть матрицы):

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

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

Частые ошибки и ловушки в матрице

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

Вторая ловушка - слишком крупные роли. Когда роль «Оператор» получает права бухгалтера «потому что иногда надо», смысл разделения обязанностей исчезает. Лучше иметь две роли или отдельное действие с явным условием (например, «выставлять счет только после согласования»).

Роли не должны уметь все

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

Короткая проверка помогает поймать рискованные места:

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

Неясно, кто согласует доступ

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

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

И наконец, матрица не живет сама по себе. Любое изменение процессов, систем или команды требует обновления. Хорошее правило: пересматривать таблицу при онбординге, увольнении, запуске нового продукта и после любого инцидента с данными.

Быстрый чеклист перед внедрением

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

Проверка ролей и операций

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

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

Временные доступы и ответственность

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

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

Если вы ведете матрицу ролей и прав и собираетесь поручить настройку ИИ, добавьте к документу один абзац «как проверяем результат»: кто смотрит список выданных прав, какие 5-10 операций обязательно тестируем, и что считаем ошибкой. Например, перед запуском в TakProsto можно прогнать сценарий: менеджер создает проект, но не видит экспорт; админ видит экспорт, но удаление требует подтверждения.

Следующие шаги: внедрение и поддержка матрицы

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

Хорошее правило звучит как короткая инструкция: «Менеджеру продаж нужен доступ к CRM: чтение сделок, создание контактов, без экспорта базы. Запрос делает руководитель отдела, утверждает владелец процесса, доступ выдается на время работы в отделе». Так матрица перестает быть документом «для галочки».

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

Сведите доступы к одному маршруту, чтобы не было истории «попросил в чате и дали навсегда». Обычно хватает такого мини-процесса:

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

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

Пересмотр, версии и дисциплина изменений

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

Простой пример: бухгалтер временно помогает отделу закупок. Выдайте права на две недели, а потом либо продлите по новому запросу, либо откатите по сроку.

Если вы используете TakProsto, удобно начать с Planning mode: описать роли, правила запросов и ограничения обычным языком, а затем собрать простую админ-панель для заявок и журналирования изменений. Снапшоты и откат помогают безопасно править права и возвращаться к предыдущей версии, если что-то пошло не так. Если нужен ориентир, базовую структуру документа можно хранить рядом с проектом на takprosto.ai, чтобы команда работала по одной версии правил.