Создание ролей пользователей

Роли пользователей (и определяемые ими права доступа) являются именно тем инструментом, который определяет:

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

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

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

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

• • R (read, чтение). Возможность видеть элементы страницы и просматривать прикрепленные файлы.
• • W (write, запись). Возможность изменять и редактировать значения полей страницы, добавлять файлы (возможность чтения, разумеется, сохраняется).
• • D (delete, удаление). Возможность удалять страницу вместе с прикрепленными файлами (доступ на чтение/запись при этом сохраняется).
• • A (admin, администрирование). Возможность добавлять/удалять дополнительные поля, менять формат представления, предоставлять и отзывать доступ к элементам (при сохранении возможности чтения, записи и удаления).

Получается логическая связка следующего вида: Учетная запись пользователя — Роль пользователя — Права доступа (комбинация прав и элементов, к которым осуществляется доступ).

Пример

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

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

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