Кто знал пароль администратора? Случился инцидент, ведется

Кто знал пароль администратора?
Случился инцидент, ведется расследование, из централизованного хранилища подняли
журнальные записи, вот только в них фигурирует учетная запись администратора
приложения ("system" в СУБД Oracle, "root" в ОС Unix, "Administrator" в MS Active Directory
т.д.), а не конечного человека. Что делать дальше? Как узнать, кто конкретно из
администраторов в момент инцидента имел возможность использовать эту учетную
запись?
Не секрет, что сейчас многие компании в рамках автоматизации управления
предприятием добились существенного прогресса в области управления жизненным
циклом учетных записей конечного пользователя и жизненным циклом бизнес ролей (и
многие с использованием Oracle Identity Governance Suite, разумеется), вот только захотят
ли они использовать тот же подход при управлении административными учетными
записями, чтобы, например, учетная запись администратора приложения
заблокировалась после увольнения администратора. Ответ очевиден – нет.
А нужно ли вообще управлять доступом к административным учетным записям
приложений, которые, в общем случае, имеют куда более широкие полномочия, чем
конечные пользователи? И тут ответ очевиден – да. Тем не менее, на практике пароли к
таким учетным записям знают многие администраторы (а секрет, известный более, чем
одному человеку, уже не секрет), пароли к ним зачастую не меняются годами, а иногда и
вовсе оставляются по умолчанию, а процессы аттестации (проверки неизбыточности
полномочий на периодической основе) так и вовсе никогда не производятся. Вот и
получается, то, что действительно нуждается в защите, защищено лишь на бумаге и
честным словом администраторов.
Что же делать? К счастью, у Oracle есть решение Oracle Privileged Accounts Manager в
составе Identity Governance Suite, которое позволяет формализовать процесс доступа к
административным и разделяемым учетным записям. Давайте рассмотрим, как оно
работает.
Администратору, которому необходимо выполнить действия из-под административной
учетной записи, заходит на свою страницу портала, находит и запрашивает
соответствующую учетную запись (если есть соответствующие права, разумеется).
Система, используя коннекторы в технологии ICF (те же самые, что используют
современные версии Oracle Identity Manager для доступа к целевым системам),
генерирует для административной учетной записи новый пароль, соответствующий
парольной политике, и показывает его соответствующему администратору, не забыв
сделать запись в журнале, кто из администраторов узнал пароль. Администратору пароль
показывается на экране или передается в репозиторий Oracle Enterprise Single Sign-On в
случае использования последнего. Он выполняет необходимые работы, и учетная запись
остается недоступной для запроса ("check out") другим администраторам. После
выполнения работ администратор возвращает учетную запись ("check in"), система
генерирует неизвестный администратору пароль и гарантирует, что, начиная с данного
момента, никто этот пароль не знает, и, соответственно, доступа к административной
учетной записи не имеет.
Типовая последовательность показана на рисунке ниже. Итак, администратор
запрашивает доступ под пользователем system к БД (1), который может быть ему
предоставлен, если у него есть необходимые полномочия (2). При предоставлении
доступа OPAM генерирует новый пароль в соответствии с парольной политикой (3) и
предоставляет его пользователю (в открытом виде в диалоге или же через Oracle
Enterprise Single Sign-on), после чего пользователь может зайти под этой учетной записью
в БД (4).
Аналогично, администратор просит себе учетную запись root сервера Unix (5),
проверяются права (6), генерируется новый пароль (7) и показывается пользователю (или
же пользователю предоставляется право использовать доступ привилегированного
пользователя через Telnet / SSH прокси под своей учетной записью). Администратор
выполняет действия (8), и, в случае использования Telnet / SSH прокси, команды,
выполненные в сессии, могут быть сохранены в репозиторий. По окончании работы
администратор возвращает пароли к учетным записям (9), а OPAM генерирует новые
значения паролей, не известные администратору (10).
Администратор "забыл" вернуть учетную запись? Нет проблем, пароль может быть
изменен автоматически при применении соответствующих политик. Произошел инцидент
и необходимо узнать. кто из администраторов знал пароль? Очень просто, достаточно
сформировать отчет (лицензия на использование полноценного средства построения
отчетов, Oracle BI Publisher, прилагается). Нужно знать, что конкретно делал
администратор? Oracle Privileged Accounts Manager 11gR2PS2 поддерживает запись
сессий. Нужно, чтобы пароль административной учетной записи знали два
администратора? Вы хорошо подумали? Что ж, это тоже можно настроить.
А теперь давайте посмотрим, что мы получаем. Во-первых, вы всегда можете знать, кто
конкретно из администраторов в определенный момент времени имел доступ к той или
иной административной учетной записи приложения. Во-вторых, доступ
администраторам к использованию административных записей приложения может быть
предоставлен с использованием тех же процессов предоставления доступа, что и всем
другим пользователям (например, через Oracle Identity Manager и Oracle SOA Suite). И,
наконец, важно не забыть вовремя доступ отобрать, что проще всего сделать путем
реализации процессов аттестации доступа (проверки неизбыточности полномочий на
периодической основе).
В итоге, вместо неформализованного подхода, основанного на доверии
администраторам, Oracle Privileged Accounts Manager 11gR2 предлагает формализованное
предоставление доступа к административным и разделяемым учетным записям
приложений с сохранением истории и предоставляет широкие возможности управления с
применением других продуктов линейки Oracle Identity Governance Suite.