Особенности матрицы доступа Oracle IRM

матрица доступа oracle irm
   Обычная матрица доступа выглядит примерно так: субъекты доступа, объекты доступа и соответствие между ними в виде прав доступа. В Oracle IRM матрица доступа выглядит немного сложнее, так как IRM имеет большее количество различных сущностей, определяющих права доступа конечного пользователя. Между пользователями и документами есть ещё контексты, роли, шаблоны и множество различных критериев, связывающих документы с контекстами, а пользователей с ролями. Описать взаимосвязь всех компонент, определяющих права доступа пользователей к защищенным с помощью Oracle IRM документам (или сообщениям электронной почты), проще всего в виде рисунка:
матрица доступа oracle irm
   Пару слов, поясняющих рисунок. Каждому пользователю или группе пользователей могут быть присвоены одна или несколько ролей. Для этого необходимо сформулировать критерии присвоения ролей. Определение и согласование критериев почти всегда является наиболее сложной задачей, требующей детальной проработки. Каждая роль позволяет получить пользователю права доступа в один конкретный контекст. Но между контекстами и ролями, помимо прав доступа, есть ещё одна сущность - шаблоны контекстов. Шаблон контекста содержит перечень предопределенных ролей, которые могут быть использованы в созданных на основе этого шаблона контекстах. Необходимость этого инструмента обусловлена задачами разграничения административных прав. Об этом я расскажу как-нибудь в другой раз, пока что продолжим говорить о контекстах. Контексты позволяют запечатывать (теперь это называется "блокировать") документы и сообщения электронной почты, тем самым обеспечивая их защиту (т.е. шифрование, подпись и привязку к определенному серверу IRM). Решение об отнесении документа к тому или иному контексту принимает обычно сам пользователь (аналогично принятию решения об отнесении информации к открытой или конфиденциальной) на основе определенных критериев, которые классифицируют информацию.
   Проблема заключается в том, что один документ можно блокировать только в один контекст, поэтому критерии отнесения документов к тому или иному контексту должны быть основаны на бизнес-процессах заказчика, а сами контексты должны максимально полно охватывать жизненный цикл защищаемых документов. Если эти бизнес-процессы не описаны, то критерии нужно будет выработать совместно с заказчиком. В частных случаях может даже потребоваться изменить сами бизнес-процессы, но это скорее относится к крайним мерам и требуется довольно редко. Так как коллизии в разграничении прав на документы могут быть весьма болезненны для администраторов IRM, то разработка и согласование критериев создания контекстов становятся не только ответственной задачей, но и весьма трудоемкой, как со стороны заказчика, так и со стороны исполнителя. Поэтому акцентировать внимание заказчика на этой задаче лучше на первых же встречах рабочей группы. Я надеюсь, что иллюстрация из этого поста поможет в пояснении возможных проблем, что в свою очередь упростит задачу разработки качественной матрицы доступа Oracle IRM.

Оставить комментарий