какие учетные записи подлежат блокировке на шаге 6 подготовки к созданию ролевой модели доступа
Ролевая модель данных прав доступа для web-ресурса
Итак, этот способ реализации подойдет вам, если:
1) Вы хотите иметь возможность получать права доступа пользователя для конкретного объекта системы, в том числе, для каждого конкретного пользователя;
2) Вы хотите организовать пользователей таким образом, чтобы каждый из них относился к какому-либо субъекту, внутри которого имел бы определенный набор прав, а также, чтобы пользователь имел возможность относиться сразу к нескольким субъектам;
3) Было бы просто замечательно, чтобы некоторые пользователи внутри субъекта могли бы управлять правами доступа других пользователей внутри этого же субъекта без участия администратора, при этом сами бы такие пользователи не выходили за рамки прав своего субъекта;
4) Вам бы хотелось, чтобы система организации была интуитивно понятна и имела простую организацию на любом из языков программирования, предназначенных для web-разработки, а также, чтобы ее хранение можно было организовать в любой из реляционных баз данных;
5) В дальнейшем перед информационной системой будет стоять задача логирования действий пользователя, и Вы хотели бы иметь непосредственную связь между системой прав доступа и системой логирования.
Перейдем к рассмотрению практического примера:
Рассмотрим модель БД, реализующую хранение системы прав:
Что мы имеем:
1) object – объект доступа;
2) action – действие, производимое над object;
3) permission – разрешение на действие action над объектом object;
4) user – пользователь;
5) project – проект (в других ИС может быть «партнер», «контракт» и т.д.);
6) project_type – тип проекта;
7) user_assigment – привязка пользователя user к конкретному проекту project;
8) role – роль для типа проекта project_type;
9) role_permission – назначение разрешения permission роли role;
10) role_user_assigment – назначение привязки пользователь-проект user_assigment конкретной роли;
11) removed_permission_user_asgmt – удаление разрешения permission конкретной привязки user_assigment.
Далее рассмотрим последовательность наших действий:
1) В соответствии с задачей мы имеем 2 типа проекта: пользовательский проект и система, фиксируем их в project_type.
2) Также у нас есть 2 роли для типа «система» и 6 ролей для типа «пользовательский проект», фиксируем их в role под соответствующим project_type.
3) Далее определяем объекты object, с которыми будут работать пользователи. (например, «профиль пользователя», «задача», «тестирование», «заметка» и т.д.)
4) Определяем действия action, производимые для всех object. Это как классические CRUD, так и специфические для системы: «назначить», «заблокировать», «скачать» и т.д.
5) Из определенных действий и объектов формируем коллекцию разрешений permission, например: «Добавить задачу», «Отредактировать заметку» и т.д.
6) Создаем для конкретных ролей role разрешения permission.
7) Далее остается только создать конкретных пользователей и проекты, связать первых со вторыми в user_assigment и назначить им роли в рамках определенного проекта в таблице role_user_assigment.
В данной системе нет такого понятия как запрет, поэтому если у пользователя есть 2 роли, то его правами доступа будет считаться объединение всех разрешений для этих ролей.
При этом, если необходимы чтобы у пользователя не было какого-то конкретного разрешения из его прав, достаточно просто внести это в таблицу removed_permission_user_asgmt (что будет означать отсутствие таких прав доступа). Например, для тестировщика необходимо выдать разрешение, которое есть только у роли «Менеджер проекта». В таком случае достаточно тестировщику назначить роль «Менеджер проекта» и в removed_permission_user_asgmt внести все разрешения, кроме необходимого.
В рамках этой организации не возникает никаких трудностей, чтобы дать право какой-либо из ролей пользовательского проекта самостоятельно назначать роли пользователям внутри проекта, при этом он не сможет назначить себе или кому-то еще разрешения роли «администратор системы», потому что для выбора ему будет предоставлены только те роли и разрешения, которые связаны с его project_type.
Замечу, что подобная организация отлично взаимодействуют с системой логирования (в данной статье она не приведена, ввиду её простоты), поскольку мы можем узнать, какое действие произвёл конкретный пользователь в определенный момент.
Также подобная система организации прав отлично сочетается с системами уведомлений и системами потока задач.
Система уже 2 года используется в одной из информационных систем для бизнеса (реализация приложения на php, база данных oracle), куда отлично вписывается.
Какие учетные записи подлежат блокировке на шаге 6 подготовки к созданию ролевой модели доступа
Для управления шлюзом безопасности реализована ролевая модель доступа.
В консоли разграничения доступа выделены роли – пользователя и администратора. В свою очередь допустимые действия администратора зависят от установленного уровня привилегий.
Пользователь имеет право на просмотр версии продукта, аппаратной и программной платформ, текущей конфигурации, состояния соединений, информации о текущем пользователе, настройке терминала.
Администратор консоли разграничения доступа с уровнем привилегий 15 имеет право на запуск и останов сервиса безопасности, запуск процедуры инициализации, создание учетных записей пользователей с однофакторной или двухфакторной аутентификацией для консоли разграничения доступа, работу с файлами, запуск утилит для регистрации лицензии, сертификатов, просмотр любой информации, доступ к ОС. Может перейти в cisco-like консоль.
Администратор консоли разграничения доступа с уровнем привилегий 1 имеет право перейти в cisco-like консоль, а также выполнить все действия, доступные пользователю.
В C isco-like консоли может быть две роли – администратор с уровнем привилегий 0-14 и администратор с уровнем привилегий 15.
Администратор с уровнем привилегий 15 имеет право выполнять любые настройки политики безопасности шлюза, создавать учетные записи администраторов для cisco-like консоли, все команды просмотра.
Администратору с уровней привилегий 0-14 доступны только команды просмотра версии продукта и уровня привилегий администратора. Но зная пароль доступа к привилегированному режиму, администратор получает право на управление шлюзом безопасности. В привилегированном режиме текущий уровень привилегий всегда максимальный (15).
В таблице ниже приведена информация о двух консолях, режимах консолей, команды для перехода в режимы и доступность команд для ролей.
Команда для перехода в режим, заводская настройка доступа администратора
Консоль разграничения доступа
Логин – administrator Пароль – s-terra
Команды просмотра, создание пользователей для консоли разграничения доступа, изменение паролей, работа с файлами, терминалом, запуск инициализации, утилит, доступ к ОС.
Просмотр версии продукта, текущей конфигурации, состоянии соединений, о текущем пользователе, выставить тип терминала.
Режим операционной системы
Логин – root
Пароль – пустой
Переход к ОС для начальной настройки и в аварийных ситуациях.
Ролевая модель доступа. Инвентаризация прав доступа
Утечки информации по вине сотрудников являются одной из важнейших угроз, с которыми приходится бороться службам информационной безопасности любой компании. Любые избыточные права доступа сотрудников ведут к увеличению риска утечки информации. В статье рассказывается о ролевой модели прав доступа, процессе инвентаризации выданных прав доступа и выявлении несоответствий на примере системы управления и контроля доступа «КУБ».
Введение
Рост компании = ужесточение контроля
Недопущение утечек информации является одной из важнейших задач службы информационной безопасности любой компании. Если есть конфиденциальная информация (государственная, коммерческая тайна, персональные данные), то существует задача ее защиты. С ростом организации, увеличивается опасность хищения информации, в том числе сотрудниками, возрастают финансовые и репутационные риски, это приводит к ужесточению политик и систем контроля.
Одним из первых этапов по упорядочиванию процесса выдачи прав к информационным системам – ввод системы согласования заявок.
Рисунок 1. Ввод системы согласования заявок
Далее обычно принимаются меры по уменьшению полномочий сотрудников, такие как запрет создания ресурсов и изменения прав доступа к тем ресурсам, где пользователь владелец, блокировка прав локального администратора и так далее.
Следующим этапом, как правило, вводится периодическая инвентаризация и ресертификация существующих прав доступа, то есть пересмотр прав пользователей к информационным ресурсам компании.
Инвентаризация прав доступа
Давайте остановимся подробнее на последних операциях.
Представьте, что нужно узнать, к каким ресурсам имеет доступ сотрудник, работающий в организации пять лет. Сколько это займет времени? 15-20 минут? А если необходимо провести проверку 50 сотрудников?
Информационные системы:
Рисунок 2. Типовой доступ сотрудника к информационным системам предприятия
Для чего же необходимо производить инвентаризацию доступа? Основная задача – обеспечение сотрудникам необходимых и достаточных прав доступа для работы. Это права доступа строго необходимые для выполнения должностных обязанностей на текущий момент. Инвентаризация позволяет выявить привилегии, которые на данный момент исполнения обязанностей сотрудника не являются необходимыми.
Чтобы понять всю сложность инвентаризации, давайте посмотрим как обычно осуществляется предоставление доступа в организации?
Чаще всего запрос и согласование доступа осуществляется в системе электронного документооборота, с помощью корпоративной почты или веб-портала, либо просто по телефону. После того, как запрос согласован, доступ выдан, заявка отправляется в архив, если таковой существует. При этом механизме оперативного отслеживания существующих полномочий сотрудника чаще всего нет. В таких ситуациях единственная возможность выявить текущие права доступа сотрудников – проведение оперативной или плановой инвентаризации.
Рисунок 3. Пример отчета «Инвентаризация прав доступа», предоставляемый системой управления и контроля доступа «КУБ»
Наиболее оптимальным решением проблемы инвентаризации существующих прав доступа – использование ролевой модели и типового доступа. Давайте рассмотрим подробнее эти понятия.
Типовой доступ
Типовой доступ – это использование шаблонных групп, профилей, ролей в информационных системах для предоставления доступа. Например, в 1С 8.2 – использование профиля «Менеджер», который включает в себя определенный набор элементарных ролей и прав доступа к таблицам. Или управление членством группы в Active Directory «Доступ к папке «Текущие проекты» чтение» для предоставления прав доступа к разделяемому каталогу. Использование шаблонов позволяет сократить время на аудит прав пользователя и формализует процедуру их предоставления.
Рисунок 4. Использование шаблонных групп, ролей и профилей
Ролевая модель
Ролевая модель (RBAC) – использование формализованных шаблонов на предприятии, которые содержат необходимые полномочия для осуществления определенной деятельности. Для решения большинства задач организации существуют ролевые полномочия, присваиваемые сотрудникам. Например:
В рамках ролевой модели доступа на основе матрицы доступа в разрезе подразделений и должностей используется такие сущности, как: бизнес-роли, должностной доступ и, в исключительных случаях, индивидуальный доступ
Должностной доступ представляет собой набор базовых прав, которые имеют сотрудники одного отдела на одной должности. Зачастую, это минимально необходимые привилегии для выполнения рабочих обязанностей.
Рисунок 5. Использование шаблонов должностного доступа
Например: создание учетной записи в AD для входа в домен, создание корпоративного почтового ящика, выделения доступа к корпоративной папке отдела на файлообменнике и регистрация в профильной информационной системе с базовыми правами (ERP, CRM, СЭД).
Бизнес-роль
Бизнес-роли включают в себя типовой доступ, который сотрудник запрашивает (либо ему выдается) для выполнения определенных функций – участия в проекте, выполнения поручений руководства, командировка.
Рисунок 6. Использование шаблонов бизнес-ролей
Индивидуальный доступ
Индивидуальный доступ необходим для решения конкретных задач, поставленных руководителем, это дополнительные права, которые сотрудник запрашивает с помощью интерфейса самообслуживания: веб-портала, ITSM-системы и пр.
При применении ролевой модели доступа, количество индивидуальных прав обычно составляет 5-10% от общего количества привилегий.
Данная схема позволяет значительно снизить объем производимой инвентаризации, так как есть права, характерные для должностей, которые априори присутствуют у сотрудника и в большинстве случаев достаточны для работы. Так же есть типовые права, если сотрудник участвует в проекте на определенной роли.
Рисунок 7. Процесс предоставления индивидуальных прав доступа
Сертификация доступа
Для контроля за состоянием индивидуальных прав доступа сотрудников многие организации ввели процедуру сертификации доступа, в процессе которой непосредственные руководители или ответственные лица проводят периодическую переаттестацию индивидуальных привилегий сотрудника.
С помощью IDM-системы, например, «КУБ» эту процедуру можно автоматизировать. Руководитель будет периодически получать уведомления со списком индивидуальных привилегий его подчиненных, которые он может продлить на расчетный период или отобрать.
Есть другой вид переаттестации, когда доступ подтверждается не руководителем, а согласующими лицами, которые утверждали первоначальный доступ.
Рисунок 8. Утверждение индивидуальных прав доступа
Работа с несоответствиями
Как правило, в IDM-решении присутствуют механизмы отслеживания, так называемых, несоответствий. Несоответствие – это изменение прав доступа сотрудников, изменение атрибутов ресурсов и информационных систем в обход процедуры согласования и без уведомления сотрудников службы ИБ.
Рисунок 9. Отслеживание несоответствий в правах доступа
IDM-решения производят мониторинг информационных систем на предмет изменения состояний, после чего соотносят эти изменения с заявками, созданными в IDM.
Рисунок 10. Мониторинг изменений доступа в информационных системах
Если соответствующих запросов на доступ нет, то событие считается нелегитимным. По данному факту оповещается ответственный за информационную систему. По результатам расследования инцидента может приниматься решение об отклонении изменений (тогда IDM автоматически «откатывает» состояние системы) либо об их утверждении.
Рисунок 11. Несоответствие прав доступа фиксируются системой
Заключение
По статистике около 70% утечек конфиденциальной информации происходит по вине сотрудников организации. Любые меры по противодействию утечкам информации делятся на два типа: превентивные меры и защитные.
Защитные меры – использование:
Использование матрицы доступа, ролевой модели и механизмов работы с несоответствиями позволит реализовать политики информационной безопасности, направленные на предотвращение утечек информации в организации.
Строим ролевую модель управления доступом. Часть вторая, «строительная»
Пост, который вы сейчас читаете, – продолжение статьи о том, как правильно выстроить в крупной компании ролевую модель управления доступом пользователей к различным системам. Напомним: построение ролевой модели – это скорее процесс, чем результат, и первую часть нашей дилогии мы посвятили подготовке к «строительству». В ней мы рассказали, как создать функциональную модель каждого подразделения и должности, провести аудит ИТ-систем и расставить их по приоритетам, создать бизнес-ориентированное описание прав пользователей и о других важных подготовительных шагах. Сегодня же поговорим о способах построения ролевой модели, ролевых матрицах, чем здесь поможет внедрение автоматизированных систем управления доступом (IdM/IGA), и что вы получите на выходе.
Для построения ролевой модели в информационной системе есть два способа.
Первый подход
Роли разрабатываются на основании функциональной модели. Этот подход возможен, когда в организации есть специальное подразделение технологов, назовём его «Организационно технологический отдел (ОТО)». У нас в банке такой отдел был в составе ИТ-департамента. Отдел будет переводить потребности бизнеса, описанные в функциональной модели, на язык ИТ: язык прав/опций/полномочий, которые нужно предоставить в системе для выполнения конкретного функционала.
Также этот подход хорош, когда вводится в эксплуатацию новая система и ролевые модели формируются с нуля. Для начала нужно разобраться вместе с ИТ–менеджером системы, каким образом предоставляются права, есть ли какие-то внутренние роли или группы в системе. Затем совместно с руководителями бизнес-подразделений и технологами ОТО нужно разработать роли, включив в них необходимые права. Затем созданные роли необходимо согласовать с владельцем системы от бизнеса, т.к. он отвечает за выполнение бизнес-процессов, с подразделением внутреннего контроля для исключения кросс-системных конфликтов и с подразделением безопасности, чтобы не нарушалась утверждённая политика безопасности компании. После этого систему можно вводить в эксплуатацию и назначать права в соответствии с утверждённой ролевой моделью.
Второй подход
Роли формируются из действующих прав, уже предоставленных сотрудникам. В большинстве случаев требуется сделать именно это, т.к. системы эксплуатируются достаточно давно и нужно разобраться с тем бардаком в правах пользователей, который накопился за много лет эксплуатации. Здесь есть свои особенности.
Если система не очень большая и в ней немного разнообразных прав, то выделить общие совпадающие права у сотрудников одной должности несложно. Из них можно составить роль, а затем направить её на согласование и утверждение руководителю, владельцу ресурса и далее по цепочке, как в первом случае. Если же в системе очень много прав (полномочий), и ее использует большое число сотрудников из разных подразделений, то задача усложняется. В этом случае на помощь приходят специализированные утилиты, именуемые Role mining, которые облегчают задачу. Они собирают совпадающие права для определённой должности в стандартную роль, которая анализируется и утверждается заинтересованными сторонами.
Строим ролевую модель по второму подходу
В нашей крупной финансовой компании мы строили ролевую модель по второму подходу, чтобы навести порядок в уже работающих системах. По тем из них, в которых пользователи имели немного прав, мы взяли очищенную выборку (только активных пользователей). Разработали шаблон заполнения ролевой матрицы для каждой системы: напомним, ролевая матрица – это роли (набор прав) в привязке к подразделениям компании и должностям в них. Шаблон направили владельцам этих систем для заполнения. Те в свою очередь собрали информацию с подразделений, в которых использовалась система, и вернули уже заполненный шаблон для дальнейшего согласования со службами ИБ и внутреннего контроля. Заполненный шаблон, а именно ролевая матрица затем используется в предоставлении доступа на основе ролей, а также включения в будущий проект автоматизации.
К сожалению, не бывает таких матриц и таких систем, где все права могут быть однозначно разбиты по ролям и роли привязаны к должностям. Поскольку в этом случае вы либо получите немного довольно универсальных ролей, где часть прав будет избыточна. Либо, наоборот, слишком много ролей, и это будет уже не ролевой, а персональный доступ на основе дискреционного метода, о котором мы писали в первой части. Часто в крупных организациях роли могут быть необходимы не для должности, а для конкретного функционала. Например, несколько сотрудников могут занимать одну и ту же должность, но выполнять разные функции. Поэтому имеет смысл часть одинакового функционала вносить в базовые роли, которые будут присваиваться по умолчанию. А часть уникальных функций сотрудника оставлять для оформления прав по отдельным запросам, которые направляются на согласование в установленном в компании порядке.
Пример шаблона для заполнения ролевых матриц
Наш шаблон выглядел так. На первом листе слева (по вертикали) были перечислены должности и подразделения, а сверху (по горизонтали) – роли. На пересечении необходимо было установить маркер, указав, для какого подразделения необходима какая роль/роли. Цветной заливкой мы отмечали: зелёным – роли, которые должны быть предоставлены по умолчанию, при назначении на должность; жёлтым – роли, которые могут быть запрошены для конкретной должности или подразделения по отдельной дополнительной заявке. 
На втором листе мы разместили справочник, который показывал наполнение ролей отдельными правами (полномочиями). 
На третьем листе – матрицу SOD-конфликтов (запрета на возможное сочетание ролей). 
Сразу скажу, что к теме SOD-конфликтов мы подошли в первом приближении, т.к. это отдельная большая активность со своим собственным процессом. Запрет на сочетание определенных полномочий может устанавливаться как в рамках отдельной роли, так и между ролями, и в кроссистемных взаимодействиях. Кроме того, важна настройка процесса работы с SOD- конфликтами и разработка сценариев реагирования на них. Это тема для отдельного рассмотрения.
Для тех систем, в которых много пользователей и структура прав довольно разнообразная, составить матрицу в ручном режиме очень непросто. Мы использовали для этих целей специализированные инструменты построения ролевой модели Role mining. Инструменты эти могут сильно отличаться логикой работы, стоимостью, удобством использования и другими характеристиками. Но принцип работы и цели у них общие — это сбор информации о текущих правах сотрудника в информационных системах, анализ повторяемости этих прав для сотрудников с одинаковыми атрибутами, объединение этих прав в роли и, в конечном итоге, построение некой базовой ролевой модели, которая отражает текущее положение дел.
Сейчас, по прошествии времени и работая в компании, которая разрабатывает ПО для управления доступом, я понимаю, что есть и более эффективные методы построения ролевых моделей в крупных системах. Чем раньше организация придет к использованию автоматизированных средств для наведения порядка, тем более гладко и безболезненно пройдёт процесс построения ролевых моделей. В этом случае автоматизированная система будет помощником или подспорьем в построении ролей. Внедрение автоматизированных систем управления доступом (IdM/IGA) нужно начинать с подключения кадровых источников и целевых систем для выгрузки данных и их мапинга и анализа. Используя специализированные инструменты, встроенные в решения по управлению доступом, можно с самого начала достаточно эффективно выстроить нужные процессы на основе автоматизации. Это значительно сократит трудозатраты и исключит шоковую терапию в будущем. Например, гораздо быстрее и эффективнее пройдёт процесс работы с учётными записями, а именно на первом этапе:
А уже на втором этапе использование автоматизированных систем управления доступом позволяет повысить эффективность работы с правами пользователей и построить ролевую модель, в частности:
Претворяем в жизнь новый регламент прав доступа
Мы добрались до того момента, когда в компании можно начинать жить по новому регламенту управления доступом: предоставлять доступ, изменять и аннулировать с учетом его новой структуры. Что должно быть в этом регламенте:
Актуализация ролевой модели
Ролевая модель не может быть статичной. Она, как живой организм, должна адаптироваться под происходящие в организации изменения. Что служит поводом для её корректировки?
Первое – это изменение организационно-штатной структуры. В крупных организациях, в этом я убедилась на собственном опыте, такие изменения могут происходить практически ежедневно. Часто изменения связаны с переименованием подразделений и должностей. При этом функционал остаётся прежним, но, тем не менее, эти изменения должны отражаться в ролевой модели и все корректировки должны вноситься своевременно. Когда же происходит слияние подразделений или, наоборот, деление на отдельные группы/отделы, то изменения более глобальны. Они затрагивают функционал работников, который нужно пересмотреть, актуализировать функциональную модель и на её основе внести изменения в существующие роли. Или же разработать и внедрить новые роли в ролевую модель.
Второе – это изменение бизнес-процессов компании. Бизнес не может быть статичным: внедряются новые процессы и механизмы, которые позволяют совершенствовать работу каждого подразделения. Это улучшает обслуживание клиентов, повышает продажи, помогает достичь стратегических целей. Внедрение каждого нового бизнес-процесса должно учитываться в ролевой модели. Появятся новые роли, или же придется доработать имеющиеся, – и в них нужно будет включить новые опции и права.
Третье – это изменение системной архитектуры. На предприятиях периодически происходит вывод из эксплуатации старых систем и ввод в эксплуатацию новых. Допустим, старая система выводится из эксплуатации и функционал, который в ней выполняли сотрудники, должен быть переведён в новую систему. Для этого придётся провести ревизию всех ролей старой системы и их актуальности, проанализировать созданные роли новой системы и сделать матрицу сопоставления старых и новых ролей. Вполне возможно, что на какой-то переходный период эти роли будут существовать параллельно, пока весь нужный функционал не перенесут в новую систему и ролевая модель не будет доработана. Затем использование ролей старой системы можно будет прекратить, доступ пользователей аннулировать, а данные старой системы отправить в архив.
Все рассмотренные изменения говорят о том, что для поддержания актуальности ролевой модели нужен отдельный процесс. В нем следует учесть все активности организации, связанные с доступом к информационным ресурсам. Он должен включать процедуру обновления ролевой модели, которая планируется заранее, чтобы все необходимые изменения были сделаны вовремя. Это и инициирование заявки на изменение роли/ролей в автоматическом или ручном режиме, и согласование, и утверждение изменений и их ввод в эксплуатацию с актуализацией смежных процессов. Всё это должно быть зафиксировано в регламенте по ведению и обновлению ролевой модели, где также необходимо указать ответственных за каждый шаг процесса.
Помимо изменений в ролевой модели на основании вышеописанных причин нужен систематический плановый пересмотр прав. В частности, для финансовых компаний таких регулярных пересмотров требуют надзорные органы. Пересмотры позволяют выявлять недочёты в существующей модели прав и повышать контроль за полномочиями пользователей. Решение этой задачи значительно упрощают IGA/IdM-системы, которые позволяют автоматизировать процесс пересмотра (ресертификации) с заданной периодичностью.
Подведём итоги
Управление доступом с использованием ролевой модели повышает уровень информационной безопасности компании, т.к. доступ становится более прозрачным, управляемым и контролируемым. А также снижает нагрузку на подразделение ИТ в части его администрирования. Что станет делать проще с помощью ролевого управления доступом?
Автор: Людмила Севастьянова, менеджер по продвижению Solar inRights