Продолжаем тему Информационной Безопасности, и сегодня мы поговорим про первый компонент, на который обычно обращают специалисты по ИБ — наличие ролевой системы доступов.

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

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

1. Деление пользователей на группы В вашей системе должна быть возможность добавлять пользователей в группы пользователей. Причем часто требуется возможность добавлять одного пользователя в разные группы. Вишенка на тортике — группы в вашей системе должны синхронизироваться с группами в Active Directory \ LDAP. То есть как поместили или переместили пользователя на уровне домена, так в вашей системе должно автоматом отобразиться с допустимым временным лагом.

2. Группы доступа к сущностям Иногда группами доступа могут выступать группы пользователей, иногда это могут быть отдельный вид групп, в которые входят пользователи и группы пользователей. Суть этих групп в том, что сущности в системе должны быть доступны не всем подряд, а определенным группам. Классический пример: Документы по найму сотрудников должны быть доступны только HR, Бухгалтерии и Дирекции, а документация по продукту — только отделу разработки. Соответственно ваша система должна обеспечивать возможность сделать такое ограничение.

3. Роли с правами на определенные действия / CRUD Хоть разделения пользователей на группы кажется достаточным, все же нужно еще думать о делении полномочий / возможностей. Например, если мы возьмем разработку, то всякие документы должны иметь право создавать только проверенные бойцы, удалять должен уметь только начальник. Для подобного разграничения возможностей обычно и делают роли, назначая их конкретным лицам. Роли обычно дают возможность настройки правил CRUD* либо на всю систему, либо на конкретные разделы системы.

CRUD - Классика классик. Настройка матрицы прав на: Create - Создание сущностей; Read - Чтение \ Загрузку сущностей; Update - Обновление \ Изменение сущностей_ _Delete* - Удаление сущностей.

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

Подведем итог. Как правило, при разработке MVP и Пилотов мы не закладываем разработку подобных ролевых систем. Самая частая ошибка, которую совершают даже "матерые волки" — не учитывать затраты на реализацию данных систем прав доступа, опираясь на восторги бизнеса и обещания "протащить вас фаст-треком через все проверки". Иногда это правда работает, но не срабатываем в самый неподходящий момент. ИБ может запретить ставить ваше ПО, а иногда поставить жесткий дедлайн, после которого удалят вас из контура. Поэтому не ленитесь и считайте потенциальные затраты на закрытие требований ИБ.

📝 А вы занимались проектированием подобных систем безопасности? Может быть вы хотели бы дополнить перечень своими историями?