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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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