Short intro: here you can find article-feedback, customer's opinion, to the article published few weeks ago about pros & cons of using external access approval systems...
Здесь я бы хотел опубликовать показавшееся мне заслуживающим внимания мнение заказчика, производящего внедрение Oracle Identity Manager'а, по поводу опубликованной мной ранее статьи "Внешние системы документооборота заявок и OIM: за и против". В-основном там описываются подводные камни, которые видит заказчик при использовании внешних систем документооборота по согласованию заявок на доступ.
Я по поводу твоей заметки Внешние системы документооборота заявок и OIM: за и против
Не буду утверждать, что у использования внешней системы документооборота (ДО) в качестве источника заявок на права доступа нет недостатков. Более того, исходя из опыта, могу сказать, что "они есть", и, к сожалению, они довольно критичные, т.к. лежат совсем не в области разработки/интеграции или поддержки, на которые ты, в основном, обратил внимание в своей заметке. Недостатки внешних систем документооборота, для управления учётными записями и их правами доступа, лежат, по большей части, в области идеологии, архитектуры и безопасности. Собственно, это не столько недостатки, сколько то, на что надо обязательно обратить внимание, при реализации проекта. Постараюсь перечислить то, что наиболее важно с моей точки зрения, а в завершении добавлю несколько камешков в огород недостатков OIM в качестве инструмента согласования заявок.
Итак:
1. Прежде всего, при использовании внешних систем ДО необходимо обеспечить, чтобы их "язык" заявок на Роли был единым с OIM, т.е. чтобы OIM смог "понять" что именно заказал и согласовал пользователь во внешней системе ДО (ВСДО). Как минимум, необходимо обеспечить единство перечня Ролей, доступных для заказа пользователю, в обоих системах (в OIM и во ВСДО). Роли разрабатываются и изменяются в OIM и в системе внешнего ДО должен быть актуальный список таких Ролей. Я опускаю вопрос механизма, используемого для этого, но уже сам тот факт, что такой механизм необходим, указывает нам на то, что архитектура решения включает в себя эту дополнительную связь между системами, следовательно, архитектура усложняется, следовательно, снижается общая надёжность решения. Кроме того, связь между системами необходимо не просто реализовывать, её необходимо поддерживать, отслеживать её работоспособность, учитывать при изменениях архитектуры решения и т.д.
Усложнение общей архитектуры решения и снижение надёжности - первый недостаток использования ВСДО.
2. Для возможности заказа и согласования Ролей во внешней системе ДО желательно, чтобы как пользователь, заказывающий Роль, так и согласующие заявку могли ознакомиться с описанием Роли. Не есть правильно для понимания состава Роли ориентироваться только на её наименование. Правильнее - иметь возможность ознакомиться с тем, какие именно полномочия даёт эта Роль, для каких бизнес-процессов она предназначена и т.д. Вся эта информация о Роли есть (точнее, скажем так, должна быть) в OIM. Важно обеспечить возможность получить эту информацию и для тех, кто будет использовать внешнюю систему ДО. В решении этой задачи есть одна сложность: в каком объёме предоставлять информацию о Роли? Полную, вплоть до атомарных прав доступа, или обобщенную? Оптимально, должна быть возможность пользователю самому определять степень подробности получаемой информации о Роли. К сожалению, управление информацией на таком уровне на практике трудно реализуемо, поэтому пользователь и согласующие, как правило, оказываются в состоянии не полной информированности, что является источником возникновения различных неувязок, недопонимания и т.д. и в конечном счёте увеличивает операционные риски.
Использование ВСДО увеличивает операционные риски - это второй недостаток.
3. Ролей в организации, как правило, много и не любая Роль может быть предоставлена любому пользователю. Сотруднику канцелярии, например, вряд ли согласуют Роль кассира. А, по хорошему, сотрудник канцелярии не должен даже иметь возможность заказать такую Роль и направить такую заявку на согласование. Посему одним из неотъемлемых свойств Роли являются "ограничения" на её использование. Ограничения на использование Роли могут касаться самых разных аспектов - от должности пользователя, до количества сотрудников в подразделении пользователя. Важно, что для заказа Ролей желательно предлагать пользователю на выбор не вообще все Роли в организации, а только те, которые ему доступны для заказа, исходя из ограничений на их использование. Делать такую "подрезку" списка доступных для заказа пользователю Ролей надо во внешней системе ДО для того, чтобы не было конфликтов из-за того, что ограничения на использование Роли будут проверяться (и, вероятно, недопускаться) в OIM уже после согласования (конфликтов типа "Я потратил на согласование неделю, а теперь выяснилось, что эта Роль для меня недоступна !").
Сделать такую подрезку списка может далеко не каждая система ВСДО, да и то, если разработчики об этом подумают заранее. Поэтому можно считать, что зачастую использование ВСДО увеличивает количество конфликтов и снижает удовлетворённость пользователя.
4. К вышесказанному добавляется необходимость указать конкретную учётную запись в ресурсе ещё при Заказе прав доступа. Поясню: в одном ресурсе у пользователя может быть несколько активных учётных записей с разными правами доступа, например: учётная запись с правами администратора для выполнения разовых специфических операций и учётная запись с обычными правами для текущей работы, в том числе и для работы с ресурсами сети Интернет. (Кому-то это может показаться странным - две активные учётки в ресурсе! Можно, ведь, одну из них заблокировать, разблокировать тогда, когда это нужно будет. Но поверьте, я сталкивался с ситуациями, когда такой подход не работает и приходится иметь обе УЗ незаблокированными). Так вот, уже на этапе Заказа (и согласования) прав доступа внешняя система ДО должна позволять указать ту УЗ, для которой будут предоставляться заказанные права (для административной УЗ или для обычной?).
Достаточно ли понятно, с какими трудностями столкнутся желающие интегрировать ВСДО с OIM в этом случае? Представьте себе, что пользователь заказывает себе Роль, по которой права доступа предоставляются сразу в несколько ресурсов, а у пользователя в части из этих ресурсов имеется более одной УЗ и какие из них, в текущий момент активны, а какие заблокированы неизвестно. Представили? Добавьте теперь к этой картинке то, что для части ресурсов и части УЗ (тех, которые являются привилегированными) необходимо обеспечить дополнительное согласование с ответственными лицами (которые указаны либо в Ролях, Ресурсах, УЗ).
Ну что, вы всё ещё хотите реализовывать в ВСДО глубокую интеграцию с OIM или хранение кучи специфической информации о Ролях, Ресурсах и Учётных записях и обеспечение актуальности всех этих данных для правильного построения процессов Заказа и согласования?
Получается, что фактически будет либо реализовываться свой ("внешний") пользовательский интерфейс в виде сильно интегрированной надстройки над OIM, либо дублироваться часть функций и структур данных самого OIM в ВСДО. Тут будет не повторное использование сервисов (как в SOA), а повторная оплата сервисов.
Согласитесь, что использование ВСДО может приводить к построению системы с частичным дублированием функций существующих систем, т.е. к финансовым потерям.
5. Следующая тема (наиважнейшая) - обеспечение безопасности, а точнее такой её аспект, как обеспечение совместимости полномочий и отсутствия опасных комбинаций полномочий - Segregation of Duties (SoD). Проверка совместимости полномочий осуществляется OIM на основании правил SoD. Обнаружение конфликтов SoD необходимо производить как на этапе предоставления прав доступа (что уже давно присутствовало в функционале OIM), так и на этапе заказа Ролей (это, наконец-то, появилось в последней версии OIM).
По хорошему, такая проверка должна проводиться ещё и на этапе согласования при создании Ролей. (примечание - Oleg Faynitskiy - этот функционал уже имеется в OIM11gR2PS3) Важно, что при использовании ВСДО проверка конфликтов SoD на этапе заказа Роли - невозможна, либо это потребует ну очень глубокой интеграции с OIM. Сложность здесь в том, что SoD необходимо проверять по "человеку", а не по отдельной "учётной записи", коих у пользователя может быть много даже в рамках одного ресурса. При этом, обнаружение конфликта является основанием для автоматического отказа только при очень жестких Политиках безопасности. А реальная жизнь, практика работы организаций намного более разнообразна, чем теоретические рассуждения о защите информации и операционных рисках. В жизни обнаружение конфликта, как правило, должно вызывать процесс согласования и принятия решения по поводу возникшего конфликта SoD. В том случае, когда "нельзя, но очень хочется", часто может быть принято решение о том, что "можно" и тогда такой заказ Роли должен стать неким исключением, которое OIM не должен будет блокировать при предоставлении именно этому пользователю и именно по этой заявке. Словом, даже не знаю, можно ли такую глубокую интеграцию ВСДО с OIM реализовать нормальным образом, чтобы сохранить возможность обновления ВСДО и OIM на следующие версии.
Поэтому, я считаю, что использование ВСДО делает невозможным (затруднительным) проверку совместимости полномочий на ранней стадии процессов предоставления прав доступа, что при неправильной формулировке Политики безопасности организации может увеличивать операционные риски.
6. А в финале пользователь получит, вероятно, возможность в привычном ему интерфейсе старой корпоративной системы ДокументоОборота, заказывать и согласовывать Роли доступа, видеть статус согласования Заявок и .... видеть сообщение, что его Заявка принята в работу. Возможно, даже сообщение об исполнении получит. А вот увидеть, что именно у него есть, какие права, какие Роли - он не сможет. То есть заказываем в одном месте, а отчётность смотрим в другом. В лучшем случае, в ВСДО можно будет увидеть историю Заявок на Роли. Но никак нельзя будет увидеть актуальный список согласованных Ролей (с учётом отмены или замещения одних Ролей другими) и, тем более, актуальный перечень прав доступа.
Необходимость обращения в систему OIM, всё равно, останется, а вот прозрачность в управлении Ролями и правами доступа при использовании ВСДО явно снизится.
Конечно, всё, что написано - написано для случая, когда новое пытаются подружить со старым и это делается в ограниченном бюджете. Будь у Заказчика неограниченный бюджет, можно было бы сделать дорогую и достаточно полную интеграцию любых систем.
Здесь я бы хотел опубликовать показавшееся мне заслуживающим внимания мнение заказчика, производящего внедрение Oracle Identity Manager'а, по поводу опубликованной мной ранее статьи "Внешние системы документооборота заявок и OIM: за и против". В-основном там описываются подводные камни, которые видит заказчик при использовании внешних систем документооборота по согласованию заявок на доступ.
Я по поводу твоей заметки Внешние системы документооборота заявок и OIM: за и против
Не буду утверждать, что у использования внешней системы документооборота (ДО) в качестве источника заявок на права доступа нет недостатков. Более того, исходя из опыта, могу сказать, что "они есть", и, к сожалению, они довольно критичные, т.к. лежат совсем не в области разработки/интеграции или поддержки, на которые ты, в основном, обратил внимание в своей заметке. Недостатки внешних систем документооборота, для управления учётными записями и их правами доступа, лежат, по большей части, в области идеологии, архитектуры и безопасности. Собственно, это не столько недостатки, сколько то, на что надо обязательно обратить внимание, при реализации проекта. Постараюсь перечислить то, что наиболее важно с моей точки зрения, а в завершении добавлю несколько камешков в огород недостатков OIM в качестве инструмента согласования заявок.
Итак:
1. Прежде всего, при использовании внешних систем ДО необходимо обеспечить, чтобы их "язык" заявок на Роли был единым с OIM, т.е. чтобы OIM смог "понять" что именно заказал и согласовал пользователь во внешней системе ДО (ВСДО). Как минимум, необходимо обеспечить единство перечня Ролей, доступных для заказа пользователю, в обоих системах (в OIM и во ВСДО). Роли разрабатываются и изменяются в OIM и в системе внешнего ДО должен быть актуальный список таких Ролей. Я опускаю вопрос механизма, используемого для этого, но уже сам тот факт, что такой механизм необходим, указывает нам на то, что архитектура решения включает в себя эту дополнительную связь между системами, следовательно, архитектура усложняется, следовательно, снижается общая надёжность решения. Кроме того, связь между системами необходимо не просто реализовывать, её необходимо поддерживать, отслеживать её работоспособность, учитывать при изменениях архитектуры решения и т.д.
Усложнение общей архитектуры решения и снижение надёжности - первый недостаток использования ВСДО.
2. Для возможности заказа и согласования Ролей во внешней системе ДО желательно, чтобы как пользователь, заказывающий Роль, так и согласующие заявку могли ознакомиться с описанием Роли. Не есть правильно для понимания состава Роли ориентироваться только на её наименование. Правильнее - иметь возможность ознакомиться с тем, какие именно полномочия даёт эта Роль, для каких бизнес-процессов она предназначена и т.д. Вся эта информация о Роли есть (точнее, скажем так, должна быть) в OIM. Важно обеспечить возможность получить эту информацию и для тех, кто будет использовать внешнюю систему ДО. В решении этой задачи есть одна сложность: в каком объёме предоставлять информацию о Роли? Полную, вплоть до атомарных прав доступа, или обобщенную? Оптимально, должна быть возможность пользователю самому определять степень подробности получаемой информации о Роли. К сожалению, управление информацией на таком уровне на практике трудно реализуемо, поэтому пользователь и согласующие, как правило, оказываются в состоянии не полной информированности, что является источником возникновения различных неувязок, недопонимания и т.д. и в конечном счёте увеличивает операционные риски.
Использование ВСДО увеличивает операционные риски - это второй недостаток.
3. Ролей в организации, как правило, много и не любая Роль может быть предоставлена любому пользователю. Сотруднику канцелярии, например, вряд ли согласуют Роль кассира. А, по хорошему, сотрудник канцелярии не должен даже иметь возможность заказать такую Роль и направить такую заявку на согласование. Посему одним из неотъемлемых свойств Роли являются "ограничения" на её использование. Ограничения на использование Роли могут касаться самых разных аспектов - от должности пользователя, до количества сотрудников в подразделении пользователя. Важно, что для заказа Ролей желательно предлагать пользователю на выбор не вообще все Роли в организации, а только те, которые ему доступны для заказа, исходя из ограничений на их использование. Делать такую "подрезку" списка доступных для заказа пользователю Ролей надо во внешней системе ДО для того, чтобы не было конфликтов из-за того, что ограничения на использование Роли будут проверяться (и, вероятно, недопускаться) в OIM уже после согласования (конфликтов типа "Я потратил на согласование неделю, а теперь выяснилось, что эта Роль для меня недоступна !").
Сделать такую подрезку списка может далеко не каждая система ВСДО, да и то, если разработчики об этом подумают заранее. Поэтому можно считать, что зачастую использование ВСДО увеличивает количество конфликтов и снижает удовлетворённость пользователя.
4. К вышесказанному добавляется необходимость указать конкретную учётную запись в ресурсе ещё при Заказе прав доступа. Поясню: в одном ресурсе у пользователя может быть несколько активных учётных записей с разными правами доступа, например: учётная запись с правами администратора для выполнения разовых специфических операций и учётная запись с обычными правами для текущей работы, в том числе и для работы с ресурсами сети Интернет. (Кому-то это может показаться странным - две активные учётки в ресурсе! Можно, ведь, одну из них заблокировать, разблокировать тогда, когда это нужно будет. Но поверьте, я сталкивался с ситуациями, когда такой подход не работает и приходится иметь обе УЗ незаблокированными). Так вот, уже на этапе Заказа (и согласования) прав доступа внешняя система ДО должна позволять указать ту УЗ, для которой будут предоставляться заказанные права (для административной УЗ или для обычной?).
Достаточно ли понятно, с какими трудностями столкнутся желающие интегрировать ВСДО с OIM в этом случае? Представьте себе, что пользователь заказывает себе Роль, по которой права доступа предоставляются сразу в несколько ресурсов, а у пользователя в части из этих ресурсов имеется более одной УЗ и какие из них, в текущий момент активны, а какие заблокированы неизвестно. Представили? Добавьте теперь к этой картинке то, что для части ресурсов и части УЗ (тех, которые являются привилегированными) необходимо обеспечить дополнительное согласование с ответственными лицами (которые указаны либо в Ролях, Ресурсах, УЗ).
Ну что, вы всё ещё хотите реализовывать в ВСДО глубокую интеграцию с OIM или хранение кучи специфической информации о Ролях, Ресурсах и Учётных записях и обеспечение актуальности всех этих данных для правильного построения процессов Заказа и согласования?
Получается, что фактически будет либо реализовываться свой ("внешний") пользовательский интерфейс в виде сильно интегрированной надстройки над OIM, либо дублироваться часть функций и структур данных самого OIM в ВСДО. Тут будет не повторное использование сервисов (как в SOA), а повторная оплата сервисов.
Согласитесь, что использование ВСДО может приводить к построению системы с частичным дублированием функций существующих систем, т.е. к финансовым потерям.
5. Следующая тема (наиважнейшая) - обеспечение безопасности, а точнее такой её аспект, как обеспечение совместимости полномочий и отсутствия опасных комбинаций полномочий - Segregation of Duties (SoD). Проверка совместимости полномочий осуществляется OIM на основании правил SoD. Обнаружение конфликтов SoD необходимо производить как на этапе предоставления прав доступа (что уже давно присутствовало в функционале OIM), так и на этапе заказа Ролей (это, наконец-то, появилось в последней версии OIM).
По хорошему, такая проверка должна проводиться ещё и на этапе согласования при создании Ролей. (примечание - Oleg Faynitskiy - этот функционал уже имеется в OIM11gR2PS3) Важно, что при использовании ВСДО проверка конфликтов SoD на этапе заказа Роли - невозможна, либо это потребует ну очень глубокой интеграции с OIM. Сложность здесь в том, что SoD необходимо проверять по "человеку", а не по отдельной "учётной записи", коих у пользователя может быть много даже в рамках одного ресурса. При этом, обнаружение конфликта является основанием для автоматического отказа только при очень жестких Политиках безопасности. А реальная жизнь, практика работы организаций намного более разнообразна, чем теоретические рассуждения о защите информации и операционных рисках. В жизни обнаружение конфликта, как правило, должно вызывать процесс согласования и принятия решения по поводу возникшего конфликта SoD. В том случае, когда "нельзя, но очень хочется", часто может быть принято решение о том, что "можно" и тогда такой заказ Роли должен стать неким исключением, которое OIM не должен будет блокировать при предоставлении именно этому пользователю и именно по этой заявке. Словом, даже не знаю, можно ли такую глубокую интеграцию ВСДО с OIM реализовать нормальным образом, чтобы сохранить возможность обновления ВСДО и OIM на следующие версии.
Поэтому, я считаю, что использование ВСДО делает невозможным (затруднительным) проверку совместимости полномочий на ранней стадии процессов предоставления прав доступа, что при неправильной формулировке Политики безопасности организации может увеличивать операционные риски.
6. А в финале пользователь получит, вероятно, возможность в привычном ему интерфейсе старой корпоративной системы ДокументоОборота, заказывать и согласовывать Роли доступа, видеть статус согласования Заявок и .... видеть сообщение, что его Заявка принята в работу. Возможно, даже сообщение об исполнении получит. А вот увидеть, что именно у него есть, какие права, какие Роли - он не сможет. То есть заказываем в одном месте, а отчётность смотрим в другом. В лучшем случае, в ВСДО можно будет увидеть историю Заявок на Роли. Но никак нельзя будет увидеть актуальный список согласованных Ролей (с учётом отмены или замещения одних Ролей другими) и, тем более, актуальный перечень прав доступа.
Необходимость обращения в систему OIM, всё равно, останется, а вот прозрачность в управлении Ролями и правами доступа при использовании ВСДО явно снизится.
Конечно, всё, что написано - написано для случая, когда новое пытаются подружить со старым и это делается в ограниченном бюджете. Будь у Заказчика неограниченный бюджет, можно было бы сделать дорогую и достаточно полную интеграцию любых систем.
No comments:
Post a Comment