Безопасность с Microsoft

Security, Identity and Access Management

BHOLD. Реализация ролевой модели контроля доступа

BHOLD. Реализация ролевой модели контроля доступа

  • Comments 2
  • Likes

Как вы уже знаете в состав FIM 2010 R2 вошёл таинственный компонент BHOLD, сегодня я подробней расскажу о нём. Одноимённая голландская компания была основана в 1997 году и всю свою историю занималась вопросами управления доступом и соответствия нормативным требованиям. Осенью 2011 года команда разработчиков влилась в компанию Microsoft.

BHOLD позволяет эффективно управлять правами доступа и создан в соответствии с требованиями стандартов, о которых мы рассказывали ранее. Функции ролевого управления доступом реализуются средствами модуля BHOLD Core, о котором сегодня и пойдёт речь.

Основы

BHOLD Core оперирует следующими логическими сущностями:

  • Пользователь (user)
  • Роль (role)
  • Полномочие (permission)
  • Организационная единица (organizational unit)
  • Прикладная система (application)
  • Учётная запись (alias)

У каждого сотрудника компании (user) есть одна или несколько учётных записей (alias) в подключенных прикладных системах (applications). Базовой сущностью является permission – полномочие в одной из прикладных систем. С помощью FIM полномочие может быть транслировано во всё что угодно – членство в группе AD, роль SAP, доступ к разделу портала на чтение или запись, пользовательский или администраторский уровень доступа и т.п.

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

role-model_2

Назначать роли пользователям вручную крайне неблагодарное занятие и существует несколько способов автоматизации этого процесса

Автоматическое назначение ролей на основании оргструктуры

BHOLD позволяет смоделировать организационную структуру предприятия вручную или на основе выгрузки из кадровой системы. Организационная структура может включать в себя несколько деревьев и отражать не только подразделения компании, но и проектную, функциональную и другие структуры. Узлами деревьев являются организационные единицы (OU). Рассмотрим на примере той же абстрактной организации:

image

 

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

В интерфейсе BHOLD организационная структура отображается в виде иерархического списка:

OU-struc

Автоматическое назначение ролей на основании атрибутов пользователя

С помощью механизма Attribute-based authorization (ABA) возможно автоматическое назначение ролей если пользователь удовлетворяет заданных критериям. В качестве критерия может использоваться любой атрибут пользователя. Примером политики ABA может являться наличие в должности слова «аналитик» или уровень допуска «коммерческая тайна».

Кроме автоматизации назначения ролей возможно автоматизировать и создание новых ролей. Например:

  • Роли типа “Membership role” (MR) – создаются для каждого нового OU, например MR-Бухгалтерия
  • Роли типа “JobTitle” (JT) – создаются для каждой новой должности, например JT-Аналитик

Прочие возможности

Даже в самых стройных матрицах доступа должно быть место для исключений. В BHOLD каждому сотруднику присваивается автоматически создаваемая персональная роль (PR), через которую в виде исключения можно назначать полномочия напрямую пользователю.

При управлении ролями доступно большинство возможностей, доступных при управлении традиционными группами FIM:

  • Портал самообслуживания с помощью которого пользователь самостоятельно выбирает роли из перечня доступных и отправляет запрос на их получение
  • Обязательное согласование перед назначением определённых ролей c одним или несколькими согласующими, например с начальником сотрудника, владельцем роли/системы, офицером безопасности
  • Назначение роли на определённый интервал времени, например на время отпуска другого сотрудника, и её отзыв по окончанию интервала
  • Разграничивать права на создание и изменение ролей, например только начальникам департаментов и только для ролей в их департаменте
  • Разделение полномочий (segregation of duties, SoD) – запрет на накопление взаимоисключающих полномочий у одного сотрудника, например “создавать платежи” и “подтверждать платежи”

Остальные не менее интересные компоненты и возможности BHOLD Suite будут освещены в дальнейших постах.

Stay tuned ;)

Comments
  • Андрей, я правильно понимаю, что персональные роли PR не только автоматически создаются, но и автоматически назначаются каждому новому пользователю?

  • Абсолютно верно, подправил в тексте

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment