17.10.11

Метрики для проекта по IdM

К теме измерения IdM-проектов я уже обращался не раз. Тогда (слайды 30-37 второй презентации) я рассматривал эту тему с точки зрения финансовой оценки эффективности проекта по внедрению системы идентификации, аутентификации и авторизации. Недавно я наткнулся на статью, в которой приводятся метрики, по которым можно оценить эффективность работающей системы IdM:
  1. Число сброшенных паролей в месяц. Сброшенных после блокирования учетной записи, например. Или после забытого пароля и использования системы генерации паролей самими пользователями.
  2. Среднее число учетных записей на пользователя. Средним показателем считается 10-12. В любом случае это число демонстрирует необходимость внедрения SSO.
  3. Число учетных записей "без пользователей". Пользователей переводя на новую работу, повышают, увольняют... А что с их учетными записями?..
  4. Число новых учетных записей. Насколько оно отличается от числа новых сотрудников за тот же период времени?
  5. Среднее время на предоставление доступа новой учетной записи к ресурсам, необходимым для работы.
  6. Среднее время на утверждение изменений в учетной записи и ее правах доступа.
  7. Число систем или привилегированных учетных записей без владельца (похоже на п.3, но применительно к привилегированному доступу).
  8. Число исключений при установлении правил доступа. Обычно при создании новых ролей или внедрении новых приложений число таких исключений велико, но постепенно оно должно стремиться к нулю. Если нет, то есть серьезная проблема с качеством идентификационных параметров учетной записи.
  9. Число нарушений разделения полномочий. Например, есть ли у вас в системе пользователи одновременно с правами разработчика и внедренца системы? Или с правами операциониста и контроллера?

8 коммент.:

doom комментирует...

Почему-то всего одна процессная метрика (про исключения ролевой модели).
Меж тем, смысл IdM как раз не в экономии 15 минут времени администратора, а в автоматизации (параллельно с правильным выстраиванием) процесса управления доступом (который, как ни странно, один из сложнейших процессов ИБ).

Алексей Лукацкий комментирует...

А автоматизация зачем нужна? Чтобы экономить время и снижать число ошибок, которые приводят к рискам и затратам.

doom комментирует...

Это да.
Но экономить время уж точно не администратора системы.

Если посмотреть, сколько времени занимает согласование доступа и фактическое его представление - то сразу понятно, что выгоднее автоматизировать :)
А еще отсутствие четких правил в крупных организациях + нехватка ресурсов контролировать исполнение регламента предоставления доступа - вот тут-то и охота, чтоб появилась система, которая не позволит от регламента отклониться, да еще нужный отчет в один клик сформирует - кто, кому, когда, что и на каком основании предоставил.

Алексей Лукацкий комментирует...

Если ты посмотришь презу, на которую я ссылаюсь, то там экономия времени не только админа (это одна из фаз), но и пользователей.

Ну а что касается регламентов... описанные метрики как раз и оценивают их качество и качество процесса - по количеству несанкционированных изменений, отклонений и т.п.

doom комментирует...

Ой. А я не ту презу посмотрел и все думал, что же я такое упустил на этих слайдах 30-37 :)

Void Z7 комментирует...

Скажу коротко PKI + token уничтожает SSO, я не про IdM 8) ...

IdM +
SSO -

doom комментирует...

2 Void Z7

Ну вам повезло, если удалось изжить весь легаси, который ничего не знает про PKI и прочие красивости (ну или хотя бы про интеграцию с системой аутентификации ОС) :)

Void Z7 комментирует...

2 doom

Коллега, не поверите, почти удалось так как все приложения в сап ушли, остались динозавры, но и их час недолог! С ОС есть тоже заморочки, но и то из подвида AIX ;) Windows уже полностью сидит на ключах (даже гостовых)