К теме измерения IdM-проектов я уже обращался не раз. Тогда (слайды 30-37 второй презентации) я рассматривал эту тему с точки зрения финансовой оценки эффективности проекта по внедрению системы идентификации, аутентификации и авторизации. Недавно я наткнулся на статью, в которой приводятся метрики, по которым можно оценить эффективность работающей системы IdM:
- Число сброшенных паролей в месяц. Сброшенных после блокирования учетной записи, например. Или после забытого пароля и использования системы генерации паролей самими пользователями.
- Среднее число учетных записей на пользователя. Средним показателем считается 10-12. В любом случае это число демонстрирует необходимость внедрения SSO.
- Число учетных записей "без пользователей". Пользователей переводя на новую работу, повышают, увольняют... А что с их учетными записями?..
- Число новых учетных записей. Насколько оно отличается от числа новых сотрудников за тот же период времени?
- Среднее время на предоставление доступа новой учетной записи к ресурсам, необходимым для работы.
- Среднее время на утверждение изменений в учетной записи и ее правах доступа.
- Число систем или привилегированных учетных записей без владельца (похоже на п.3, но применительно к привилегированному доступу).
- Число исключений при установлении правил доступа. Обычно при создании новых ролей или внедрении новых приложений число таких исключений велико, но постепенно оно должно стремиться к нулю. Если нет, то есть серьезная проблема с качеством идентификационных параметров учетной записи.
- Число нарушений разделения полномочий. Например, есть ли у вас в системе пользователи одновременно с правами разработчика и внедренца системы? Или с правами операциониста и контроллера?
Почему-то всего одна процессная метрика (про исключения ролевой модели).
ОтветитьУдалитьМеж тем, смысл IdM как раз не в экономии 15 минут времени администратора, а в автоматизации (параллельно с правильным выстраиванием) процесса управления доступом (который, как ни странно, один из сложнейших процессов ИБ).
А автоматизация зачем нужна? Чтобы экономить время и снижать число ошибок, которые приводят к рискам и затратам.
ОтветитьУдалитьЭто да.
ОтветитьУдалитьНо экономить время уж точно не администратора системы.
Если посмотреть, сколько времени занимает согласование доступа и фактическое его представление - то сразу понятно, что выгоднее автоматизировать :)
А еще отсутствие четких правил в крупных организациях + нехватка ресурсов контролировать исполнение регламента предоставления доступа - вот тут-то и охота, чтоб появилась система, которая не позволит от регламента отклониться, да еще нужный отчет в один клик сформирует - кто, кому, когда, что и на каком основании предоставил.
Если ты посмотришь презу, на которую я ссылаюсь, то там экономия времени не только админа (это одна из фаз), но и пользователей.
ОтветитьУдалитьНу а что касается регламентов... описанные метрики как раз и оценивают их качество и качество процесса - по количеству несанкционированных изменений, отклонений и т.п.
Ой. А я не ту презу посмотрел и все думал, что же я такое упустил на этих слайдах 30-37 :)
ОтветитьУдалитьСкажу коротко PKI + token уничтожает SSO, я не про IdM 8) ...
ОтветитьУдалитьIdM +
SSO -
2 Void Z7
ОтветитьУдалитьНу вам повезло, если удалось изжить весь легаси, который ничего не знает про PKI и прочие красивости (ну или хотя бы про интеграцию с системой аутентификации ОС) :)
2 doom
ОтветитьУдалитьКоллега, не поверите, почти удалось так как все приложения в сап ушли, остались динозавры, но и их час недолог! С ОС есть тоже заморочки, но и то из подвида AIX ;) Windows уже полностью сидит на ключах (даже гостовых)