Отмена инициализации пользователей в Active Directory

Введение

Текучка есть в каждой компании. Сотрудники приходят и уходят. Наряду с уходом человека из компании необходимо также позаботиться об учетной записи пользователя в Active Directory, связанной с человеком. Задача и процесс управления этими учетными записями пользователей в Active Directory называется отменой инициализации. Деинициализация может варьироваться от ручного управления, которое может занять очень много времени в зависимости от того, сколько сотрудников увольняется из компании, до тщательного управления с помощью сложных сценариев и процедур управления. Я обнаружил, что большинство организаций, у которых нет людских ресурсов, знаний о написании сценариев, денег на дорогостоящие инструменты или времени на создание автоматизированных процедур, вынуждены вручную отменять инициализацию пользователей, когда сотрудник увольняется. Этот процесс, выполняемый вручную или частично по сценарию, может оставить учетные записи пользователей в небезопасном состоянии, что сделает организацию уязвимой для атаки.

Подверженность безопасности неправильно деинициализированных учетных записей пользователей

Во-первых, давайте обсудим, как неправильное управление учетной записью пользователя может сделать Active Directory и, следовательно, сеть и ресурсы уязвимыми для атаки.

1. Учетная запись пользователя не отключена — если учетная запись пользователя не отключена, любой, у кого есть пароль, может войти в эту учетную запись. Обычно, хотя и очень небезопасно, когда «менеджер» или «перекрестно обученный» сотрудник входит в отдельную учетную запись пользователя, чтобы проверить электронную почту и получить доступ к данным, к которым имел доступ бывший сотрудник.
2. Учетная запись пользователя не перемещается в защищенную организационную единицу (OU). Отдельные учетные записи пользователей должны быть перемещены в OU, к которым привязаны объекты групповой политики (GPO), чтобы заблокировать учетную запись пользователя на тот случай, если кто-то войдет в систему под этой учетной записью. Объекты групповой политики могут лишить доступа, функций, параметров меню и многого другого. Это оставило бы вошедшему в систему пользователю только основные задачи, которые можно было бы выполнять на компьютере, на котором они вошли в систему.
3. Учетная запись пользователя не удаляется из групп — доступ к данным и другим сетевым ресурсам обычно предоставляется членством в группе. Когда пользователь не удален из групп, доступ по-прежнему доступен, если кто-то может войти в систему под этой учетной записью. Удаление пользователя из групп немедленно лишает пользователя доступа к данным, к которым группе был предоставлен доступ.

Удаление учетных записей пользователей

Существует множество методов, которые можно использовать для деинициализации пользователей. Самым простым является ручная процедура. Этот метод часто является самым небезопасным, поскольку время имеет решающее значение, и если вся процедура не выполняется для всех отдельных пользователей, перечисленные выше риски безопасности могут остаться нетронутыми. Если используется ручная процедура, требуется специальный администратор, чтобы убедиться, что разделенные пользователи вручную отключены, перемещены в защищенную организационную единицу, а затем удалено все членство в группе. Если выполняется только одна из вышеперечисленных процедур, связанных с безопасностью, это должно быть отключение учетной записи пользователя.

Существуют и другие потенциальные методы деинициализации пользователей, которые могут оказаться подходящими. Есть сценарии, будь то VBScript, пакетный файл, Powershell или другие языки и методы сценариев. Скрипты должны пройти регрессионное тестирование, а затем иметь некоторую возможность узнать, какие учетные записи пользователей следует деинициализировать, когда придет время. В большинстве случаев сценарий запускается вручную, при этом пользователи передаются сценарию, чтобы убедиться, что выбраны правильные пользователи. Есть некоторые системы, которые могут работать как с Active Directory, так и с системой управления персоналом (HR), чтобы знать, какие пользователи разделены, и затем передают разделенных пользователей в Active Directory, чтобы они были должным образом защищены.

Удаление идеальной учетной записи пользователя

Вышеупомянутые ручные и скриптовые варианты являются жизнеспособными решениями для деинициализации пользователей, но им не хватает эффективности, которую я пытаюсь достичь и передать вам. На самом деле есть две разные ситуации, когда в игру вступает отмена инициализации пользователя. Во-первых, когда мы знаем, что сотрудникам нужно будет управлять, скажем, 50 контрактов сотрудников заканчиваются через 90 дней. Во-вторых, когда сотрудники отделяются от компании без какого-либо уведомления, но нам все еще необходимо управлять их учетными записями пользователей, чтобы защитить их от атаки или несанкционированного доступа к данным.

В первом случае в идеале мы хотим иметь некоторую политику, которая будет автоматически запускаться через 90 дней. Мы хотели бы, чтобы эту политику было легко настроить и чтобы она была связана не только с 50 сотрудниками, но и с любым сотрудником, который соответствует критериям, установленным в политике. Политика может использовать определенные атрибуты (или несколько атрибутов) учетных записей пользователей. Например, я мог бы захотеть использовать истечение срока действия учетной записи пользователя, учетные записи пользователей, которые не входили в систему в течение определенного периода времени, или даже просто статический список учетных записей пользователей, которыми, как я знаю, необходимо управлять в течение заданного периода времени. В большинстве организаций эти политики могут выполняться каждую ночь, чтобы учетные записи пользователей отключались и управлялись к тому времени, когда сотрудники приступят к работе.

Второй вариант так же прост, как и первый, с правильным инструментом. Когда есть список сотрудников, которые отделены от компании, этот список можно затем связать с политикой, чтобы эти учетные записи пользователей были отключены, перемещены в защищенное подразделение, а все членство в группах было удалено.

Такой инструмент, как ADManager Plus от ManageEngine, идеально подходит для этих задач, поскольку он предназначен именно для этого (наряду с другими задачами управления). Другие преимущества такого инструмента, как ADManager Plus, на которые стоит обратить внимание, включают:

• Немедленный отчет о том, какие пользователи были изменены и какие атрибуты были изменены, если вы допустили ошибку.
• Взаимодействие с инструментом мониторинга, чтобы иметь документацию о том, какие пользователи были изменены и какие атрибуты были изменены. ADManager Plus взаимодействует с ADAudit Plus, который предоставляет подробные отчеты о любых изменениях, происходящих с любым объектом в Active Directory.
• Совместимость с инструментом восстановления, так что если свойства пользователя изменены неправильно, простой щелчок может вернуть атрибут к исходной настройке, не прерывая доступ пользователя. RecoveryManager Plus работает с ADManager Plus, чтобы обеспечить быстрый и эффективный откат любого удаления или модификации пользователем до предыдущего состояния.

Резюме

Важно, чтобы учетные записи пользователей для уволенных сотрудников были удалены. Без каких-либо средств для обеспечения того, чтобы учетные записи разделенных сотрудников были отключены, защищены и больше не имели доступа к данным, эти учетные записи остаются уязвимыми для атак и потенциально неправомерного доступа к данным. Да, Microsoft обеспечивает некоторый уровень автоматизации с использованием Powershell, но есть и другие вопросы, такие как проверка, создание отчетов, мониторинг и восстановление, которые Powershell не обеспечивает. На самом деле проверка, отчетность и восстановление некорректных изменений либо отсутствуют, либо практически невозможны при использовании технологий Microsoft. Получение инструмента или набора инструментов, которые могут сделать отмену инициализации пользователя эффективной и полной,