Short intro: here're some use cases of integrated solution of OIA & ESSO and news about coming ESSO-OIA integration library.
Просочилась информация о предполагаемой библиотеки интеграции Oracle Enterprise Single Sign-on и Oracle Identity Analytics. Данный ресурс не является официальным, поэтому могу себе позволить описать планируемые use-case'ы предполагаемого интегрированного решения, которые не так уж сложно реализовать самостоятельно, не дожидаясь выхода громких заявлений, официальных руководств и библиотек.
- автоматизированная корреляция аккаунтов в приложении (в репозитории ESSO) с пользователями в OIA;
Сотрудник: PPETROV, учетная запись: PPETR, Petr.Petrov, petr0v
Очевидно, что если ESSO было внедрено до внедрения OIM или OIA, то информация, какие пользователи пользуются какими учетными записями в целевых системах, уже имеется. Ее заводят сами пользователи при заполнении данных шаблонов ESSO для автоматической подстановки. Эту информацию осталось только скоррелировать с полученным из доверенных источников списком сотрудников.
- импорт информации в OIA не только о том, какие пользователи имеют какие учетные записи, но и о фактах их реального использования;
Сотрудник: PPETROV, учетная запись: PPETR, дата последнего входа: 17 апреля 2012
Это должно работать только когда используется модуль Provisioning Gateway (с OIM или в ручную) и конечные пользователи не знают своих паролей, в противном случае нет возможности перехватить использование этого аккаунта. Информация о том, когда ESSO последний раз расшифровал пароль пользователя и подставил его в поле диалога ввода логина и пароля приложения может быть получена из логов аудита и отражена в соответствующих полях аккаунта пользователя в OIA.
Эту информацию можно использовать при проведении сертификации ответственным лицом, которое может судить о необходимости сотруднику учетной записи на основе даты последнего использования, частоты использования и т.д. (Вот бы еще получить информацию в OIA, какими привилегиями в рамках аккаунта пользовались те или иные пользователи! К сожалению, в ближайшем времени для общего случая автоматизированное решение не представляется возможным…).
- распознавать случаи совместного использования аккаунтов в целевых системах через запуск политик SOD;
Сотрудник: PPETROV, учетная запись: PPETR, дата последнего входа: 17 апреля 2012
Сотрудник: AIVANOV, учетная запись: PPETR, дата последнего входа: 16 апреля 2012
Так как ESSO показывает не только то, как должно быть с точки зрения используемого доступа, но и как есть на самом деле (хотя бы с точки зрения используемых аккаунтов), то информацию об использованных учетных записях можно импортировать в OIA и при помощи применения политик Identity Audit (реализация SOD) найти подобных сотрудников, а также назначить соответствующих бизнес-пользователей для разрешения этих "Identity Audit Violations". Хотите снять нагрузку с IT и привлечь бизнес-пользователей к процессам управления доступом? В этом случае это отличный use case.
Конечно, в этом случае предполагается, что "второй сотрудник" (т.е. тот, кто использует чужую запись, как AIVANOV в примере выше) или достаточно аккуратен, чтобы добавить информацию о своем знании учетной записи в ESSO или же эта запись была назначена через Provisioning Gateway администратором или автоматически OIM. Кроме того, как быть, если являются общими мастер-записи, по которым ESSO определяет сотрудника (например, вход в Windows под одной учетной записью Active Directory), в общем случае неясно.
Просочилась информация о предполагаемой библиотеки интеграции Oracle Enterprise Single Sign-on и Oracle Identity Analytics. Данный ресурс не является официальным, поэтому могу себе позволить описать планируемые use-case'ы предполагаемого интегрированного решения, которые не так уж сложно реализовать самостоятельно, не дожидаясь выхода громких заявлений, официальных руководств и библиотек.
- автоматизированная корреляция аккаунтов в приложении (в репозитории ESSO) с пользователями в OIA;
Сотрудник: PPETROV, учетная запись: PPETR, Petr.Petrov, petr0v
Очевидно, что если ESSO было внедрено до внедрения OIM или OIA, то информация, какие пользователи пользуются какими учетными записями в целевых системах, уже имеется. Ее заводят сами пользователи при заполнении данных шаблонов ESSO для автоматической подстановки. Эту информацию осталось только скоррелировать с полученным из доверенных источников списком сотрудников.
- импорт информации в OIA не только о том, какие пользователи имеют какие учетные записи, но и о фактах их реального использования;
Сотрудник: PPETROV, учетная запись: PPETR, дата последнего входа: 17 апреля 2012
Это должно работать только когда используется модуль Provisioning Gateway (с OIM или в ручную) и конечные пользователи не знают своих паролей, в противном случае нет возможности перехватить использование этого аккаунта. Информация о том, когда ESSO последний раз расшифровал пароль пользователя и подставил его в поле диалога ввода логина и пароля приложения может быть получена из логов аудита и отражена в соответствующих полях аккаунта пользователя в OIA.
Эту информацию можно использовать при проведении сертификации ответственным лицом, которое может судить о необходимости сотруднику учетной записи на основе даты последнего использования, частоты использования и т.д. (Вот бы еще получить информацию в OIA, какими привилегиями в рамках аккаунта пользовались те или иные пользователи! К сожалению, в ближайшем времени для общего случая автоматизированное решение не представляется возможным…).
- распознавать случаи совместного использования аккаунтов в целевых системах через запуск политик SOD;
Сотрудник: PPETROV, учетная запись: PPETR, дата последнего входа: 17 апреля 2012
Сотрудник: AIVANOV, учетная запись: PPETR, дата последнего входа: 16 апреля 2012
Так как ESSO показывает не только то, как должно быть с точки зрения используемого доступа, но и как есть на самом деле (хотя бы с точки зрения используемых аккаунтов), то информацию об использованных учетных записях можно импортировать в OIA и при помощи применения политик Identity Audit (реализация SOD) найти подобных сотрудников, а также назначить соответствующих бизнес-пользователей для разрешения этих "Identity Audit Violations". Хотите снять нагрузку с IT и привлечь бизнес-пользователей к процессам управления доступом? В этом случае это отличный use case.
Конечно, в этом случае предполагается, что "второй сотрудник" (т.е. тот, кто использует чужую запись, как AIVANOV в примере выше) или достаточно аккуратен, чтобы добавить информацию о своем знании учетной записи в ESSO или же эта запись была назначена через Provisioning Gateway администратором или автоматически OIM. Кроме того, как быть, если являются общими мастер-записи, по которым ESSO определяет сотрудника (например, вход в Windows под одной учетной записью Active Directory), в общем случае неясно.
No comments:
Post a Comment