четверг, 1 ноября 2012 г.

Польза или вред собственной аутентификации

Представьте себе любую систему, в которой вам нужно регулярно пересматривать учетные записи и права доступа. Для чего их нужно пересматривать? Отвечаю:

• сотрудники могут быть уволены;

• сотрудникам может быть уже не нужна данная система;

• сотрудники могут переместиться в другое подразделение (возможен как вертикальный, так и горизонтальный рост);

• сотрудники могут иметь лишние права в системе.

Как регулярно это нужно делать? Есть разные взгляды на этот процесс. Перечислю четыре:

• раз в год как регулярный процесс;

• перед приходом любых аудиторов;

• после замечаний любых аудиторов;

• по требованию.

Как это можно делать? Часто вначале учетки пробивают по Active Directory. При «живых» сотрудниках можно организовать рассылку их непосредственным руководителям с вопросами типа «нужно?» и «что нужно?».

А дальше самое интересное. Если система имеет только AD-аутентификацию, то для удаления доступа достаточно перенести учетку в соответствующую OU. А вот если система использует собственную аутентификацию, то нужно удалять или блокировать доступы в ней.

Чаще всего используется последовательно три уровня аутентификации:

• уровень домена Active Directory;

• уровень приложения;

• уровень базы данных.



В этом случае понятно, что чаще блокировать нужно на втором и третьем.

Какие могут быть сложности еще? А вот такие:

• в AD учетка создана как Ivanov_AB;

• в приложении учетка создана как Alex_I;

• в СУБД учетка создана как Ivanov_Alexey.

А теперь представьте, что таких учеток у вас тысячи. Что будем делать? Во-первых, всегда приветствуется ручной труд. Во-вторых, есть супер-пупер средство автоматизации Excel с его магическими макросами. А в-третьих, учеными давно разработаны системы классов Identity Management или Identity and Access Management (IDM и IAM соответственно), которые все это делают сразу и автоматически.



А когда и как поступаете в своих организациях Вы?

5 комментариев:

  1. Ну раз уж пошла популяризация этого класса продуктов, то добавлю, что уже и сертифицированные появились. Oracle Identity & Access Management (IDM + разграничение доступа на к веб-русурсам) и Avanpost (отечественная разработка, функционала поменьше, но подешевле)

    ОтветитьУдалить
  2. Это ещё хорошо, когда все приложения внутри корпоративной сети находятся. А как быть со страницей компании в Facebook или учётной записью в Twitter?

    ОтветитьУдалить
    Ответы
    1. у Oracle на этот счет есть модуль Identity Federation, правда это не сертифицировано

      Удалить
  3. Сами по себе эти классы продуктов используются, скажем так, нечасто. А сертифицированные уж тем более никому не нужны!

    ОтветитьУдалить
    Ответы
    1. ну я бы так не сказал, мне встречались проекты, в которых упоминались требования по применению IDM в контексте ИБ, и это был госзаказчик, соответственно решения надо было применять сертифицированные (хотя не исключаю вариант лобби).

      Удалить