Роли и права доступа в системе: кто что видит

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

1. Основные положения

1.1. Учётная запись создаётся на одного физического человека. Совместное использование учётной записи не допускается.

1.2. Права назначаются роли. Роль назначается учётной записи. Прямое назначение прав человеку не применяется.

1.3. Роль — это набор разрешённых действий, а не должность. Один сотрудник может иметь две роли одновременно.

1.4. По умолчанию действие запрещено. Разрешение выдаётся явно.

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

2. Базовый перечень ролей

2.1. Владелец. Полный доступ ко всем разделам, включая финансовые показатели, настройки платёжных реквизитов и управление учётными записями.

2.2. Администратор системы. Настройки, справочники, интеграции. Доступ к финансовым отчётам не предоставляется, если это не оговорено отдельно.

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

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

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

2.6. Бухгалтерия. Оплаты, возвраты, документы, выгрузки. Изменение состава заказа не разрешено.

2.7. Подрядчик. Временная роль с ограниченным перечнем разделов и обязательной датой окончания.

3. Матрица доступа

3.1. Матрица приводится в сокращённом виде. Обозначения: «П» — просмотр, «И» — просмотр и изменение, «—» — нет доступа.

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

3.3. Матрица подлежит пересмотру при появлении новой роли или нового раздела системы.

4. Порядок выдачи доступа

4.1. Основание — оформленный приём сотрудника или договор с подрядчиком.

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

4.3. Учётная запись создаётся на рабочий адрес электронной почты сотрудника. Личные адреса используются только при отсутствии корпоративных.

4.4. Первичный пароль устанавливается сотрудником при первом входе. Передача пароля через мессенджер не допускается.

4.5. Сотрудник уведомляется о наличии журнала действий до начала работы.

5. Порядок изменения и отзыва

5.1. Изменение роли оформляется до фактического изменения обязанностей.

5.2. Временное расширение доступа выдаётся с указанием даты возврата к прежней роли.

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

5.4. Отключённая учётная запись не удаляется. Записи журнала, связанные с ней, сохраняются.

5.5. Учётные записи, не использовавшиеся более девяноста дней, отключаются автоматически.

6. Требования к журналу действий

6.1. Журнал фиксирует: кто, когда, в каком разделе, какое действие совершил, прежнее и новое значение.

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

6.3. Записи журнала не редактируются и не удаляются из интерфейса.

6.4. Срок хранения записей — не менее двенадцати месяцев.

7. Отдельные случаи

7.1. Совмещение должностей оформляется назначением двух ролей, а не созданием второй учётной записи.

7.2. Стажёр получает операционную роль без доступа к контактам и суммам до окончания испытательного срока.

7.3. Внешний бухгалтер получает роль «Бухгалтерия» без доступа к настройкам платежей.

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

8. Типовая проверка перед приёмкой системы

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

8.2. Попытаться открыть закрытый раздел по прямой ссылке. Ожидаемый результат — отказ, а не пустая страница.

8.3. Отключить тестовую учётную запись и убедиться, что активная сессия прекращается.

8.4. Изменить цену под тестовой учётной записью и найти запись в журнале.

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

9. Ответственность и пересмотр

9.1. Владелец процесса пересматривает матрицу доступа не реже одного раза в шесть месяцев и после каждого изменения состава ролей.

9.2. Перечень активных учётных записей сверяется с фактическим составом сотрудников ежеквартально. Записи, не подтверждённые сверкой, отключаются.

9.3. Передача сотрудником своих учётных данных другому лицу приравнивается к нарушению независимо от последствий.

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

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

Коротко

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