Опираясь на мой предыдущий блог, Сара в понедельник начинает свою новую работу в операционном отделе. Ее руководитель организовал обучение, познакомил ее с командой и запросил доступ для ее новой роли. Все выглядит готовым к работе.
За исключением одной детали: Сара все еще может утверждать платежи поставщикам в финансовом приложении, которое она использовала на своей прежней должности. Как я уже упоминал ранее, мы использовали перевод Сары, чтобы показать, почему для принятия более эффективных решений о доступе требуется надежное выполнение. А теперь давайте перенесем этот сценарий в OpenText™ NetIQ™ Identity Governance. Как обнаружить доступ, который больше не соответствует требованиям, привлечь нужного рецензента и подтвердить, что изменения действительно произошли?
Identity Governance помогает ответить на эти вопросы, связывая информацию о доступе с целенаправленными проверками, политиками на основе ролей и реализацией. Вот как может выглядеть этот процесс по мере перехода Сары из финансового отдела в операционный.
Централизованный пункт администрирования
Прежде чем ее новый руководитель сможет решить, что Сара должна сохранить, кто-то должен увидеть, что у нее все еще есть. Запись в каталоге может отражать ее перевод в операционный отдел, но она необязательно показывает каждое разрешение, которым она обладает в финансовом приложении и других подключенных системах.
Коллекторы Identity Governance объединяют информацию об учетных записях, удостоверениях и разрешениях в каталоге управления. Это дает рецензентам более четкое представление о доступе Сары к подключенным приложениям, избавляя их от необходимости сводить разрозненные электронные таблицы. Ценность зависит от сбора правильных данных и поддержания их в актуальном состоянии.
Детали также должны иметь смысл. Возвращаясь к моему предыдущему примеру, разрешение с именем «FIN_AP_03» мало что говорит руководителю Сары. Такое описание, как «Утверждение платежей поставщикам на сумму до 25 000 долл. США», делает бизнес-последствия понятными. Владельцы приложений могут поддерживать такие описания в актуальном состоянии и определять, кто несет ответственность за проверку доступа.
Теперь вопрос стоит прямо: нужен ли кому-то на новой операционной должности Сары этот доступ к утверждению платежей? Если нет, то зачем ждать следующей ежеквартальной проверки?
Поддержание управления в условиях изменений
Запланированная проверка доступа может не проводиться в течение нескольких недель или месяцев. Перевод Сары дает бизнесу повод заняться этим раньше, пока изменения еще свежи.
Когда обновленная информация об учетных записях собирается и публикуется, политики данных Identity Governance могут определять изменения в таких полях, как отдел, должность или руководитель. Настроенная политика может инициировать — целенаправленную проверку соответствующего доступа — или запустить другое определенное действие.
Для Сары смена отдела может привести к отправке ее финансового доступа нужному рецензенту. Но само по себе обновление в HR не запускает проверку. Сбор, публикация, правила политики, маршрутизация и рабочие процессы проверки — все это должно быть настроено. Это различие имеет значение, когда вам нужен повторяющийся процесс, а не предположение, что программное обеспечение справится со всем само.
Аналогичные политики могут привлечь внимание к другим условиям: учетная запись без назначенного владельца, учетная запись, которая не использовалась дольше согласованного периода при наличии информации о последнем входе в систему, или разрешение, отвечающее определенному условию риска. Цель состоит не в том, чтобы генерировать больше проверок. Цель в том, чтобы предоставить нужную проблему нужному человеку.
Широкие периодические аттестации по-прежнему важны. Целенаправленные проверки дополняют их, устраняя конкретные изменения между кампаниями.
Упрощение контроля за управлением доступом
Удаление старого доступа — это лишь половина перехода Сары. Ей также нужны правильные приложения и разрешения, чтобы начать новую работу без череды разовых запросов.
Бизнес-роли могут определять, кто имеет право на доступ, связанный с определенной работой или функцией. Технические роли объединяют связанные разрешения в управляемые наборы. При наличии настроенных соответствующих политик и процессов реализации эти роли помогают сделать рутинные решения о доступе более последовательными и сократить объем повторяющейся работы.
Переходные периоды все равно могут потребовать исключений. Возможно, Саре нужен ограниченный финансовый доступ на две недели для завершения передачи дел. Это должно быть осознанное решение с ответственным лицом, четкой причиной и согласованной датой окончания, а не старый доступ, который незаметно становится постоянным.
По мере развития вашей модели ролей проверки могут быть сосредоточены на разрешениях за пределами утвержденных ролевых полномочий. Вместо многократного изучения привычных шаблонов доступа рецензенты могут уделить больше внимания тем случаям, когда требуется вынесение суждения.
Убедитесь, что изменения действительно произошли
Рецензент Сары решает отозвать ее полномочия по утверждению платежей поставщикам. Означает ли это, что она потеряла это разрешение? Еще нет.
Identity Governance может создать запрос на изменение и отслеживать его прохождение через настроенный процесс реализации. В зависимости от приложения и интеграции, обработка изменения может выполняться автоматизированной системой реализации, подключенной системой, такой как NetIQ Identity Manager, или лицом, назначенным для его завершения. Путь реализации должен быть настроен для конкретной среды.
После этого другой цикл сбора и публикации может подтвердить, действительно ли разрешение удалено. Если оно все еще есть у Сары, у команды есть конкретная проблема для расследования. Утвержденное удаление и подтвержденное удаление — это две разные вещи.
Это различие также важно для аудиторов. История проверок и записи о реализации помогают объяснить, кто принял решение и какие действия за этим последовали. Обновленные данные приложения помогают установить, вступили ли изменения в силу. Сама по себе завершенная проверка не является доказательством того, что доступ был удален.
Превратите один перевод в повторяемый процесс
Переход Сары дает вам практическую отправную точку. Убедитесь, что каталог актуален, сделайте разрешения понятными, согласуйте триггеры политики и рецензентов, протестируйте реализацию и снова соберите данные о доступе, чтобы подтвердить результат. Затем примените полученные знания к следующему переводу, повышению по службе или увольнению. Сведения о настройке см. в актуальной документации по продукту.
В предыдущем блоге основное внимание уделялось извлечению бизнес-выгоды из решений, принимаемых людьми. Перевод Сары показывает, как возможности продукта и четкое распределение ответственности могут помочь претворить эти решения в жизнь. В техническом документе «Максимальное использование возможностей OpenText NetIQ Identity Governance» более подробно рассматриваются качество каталога, роли, проверки, политики данных, реализация и отчетность. Прочтите этот технический документ, чтобы узнать о практических способах укрепления каждого шага и превращения возможностей управления доступом в результаты, которые можно проверить.
