Жизненный цикл учётных записей: как выстроить IDM без дорогого продукта

Системы класса IDM (управление идентификацией) стоят дорого и внедряются месяцами, поэтому небольшие компании обычно обходятся без них. Это нормально, пока работники приходят и уходят редко. Но если доступ при увольнении закрывается «когда вспомнят», а при переводе на новую должность старые права остаются навсегда, нужен не продукт, а порядок. Ниже как построить управление жизненным циклом учётных записей на кадровом списке, нескольких скриптах и едином входе, как считать охват и какие признаки показывают, что пора переходить к полноценному IDM.

Правила доступа и процесс заявок: заявка на доступ. Чек-лист увольнения: привилегированный доступ и увольнение. Поиск неактивных записей: Windows и AD, Linux.

Три события и источник истины

В любой компании у доступа три момента: человек приходит, меняет должность, уходит. Источник правды о каждом — кадровая служба: именно она первой знает, что человек принят или увольняется. Поэтому первое условие порядка — договорённость, что кадры уведомляют ИТ в день решения (а при плановом увольнении заранее), а ИТ не ищут эту информацию сами.

Шаг 1. Кадровая выгрузка как источник

Договоритесь о файле, который кадровая служба выгружает регулярно (раз в день или при каждом приказе): список действующих работников. Минимальные поля:

login,full_name,position,department,manager,hire_date,termination_date
ivanov,Иванов Иван Иванович,Оператор,Отдел продаж,petrov,2024-03-01,
sidorova,Сидорова Мария Петровна,Бухгалтер,Бухгалтерия,kozlova,2022-09-12,2026-10-31

Поле termination_date позволяет заранее запланировать блокировку. Файл — персональные данные, поэтому храните его с ограниченным доступом и передавайте защищённым способом. Это один источник, а не сотни копий: любое расхождение между ним и учётными системами — находка.

Шаг 2. Роли как шаблоны

Чтобы при приёме не выдавать права «как у соседа», заведите таблицу ролей: должность, подразделение, группы каталога, системы. Это та же матрица ролей, доведённая до технических групп:

role,ou,groups
Оператор,"OU=Sales,OU=Staff,DC=example,DC=com","G-Sales,G-CRM-Operator,G-VPN-Users"
Бухгалтер,"OU=Accounting,OU=Staff,DC=example,DC=com","G-Accounting,G-1C-Accountant"

Шаг 3. Создание учётной записи по роли

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

# new_user.ps1: создание учётной записи по роли
param([Parameter(Mandatory)]$Login, [Parameter(Mandatory)]$First, [Parameter(Mandatory)]$Last, [Parameter(Mandatory)]$Role)

$r = Import-Csv roles.csv | Where-Object { $_.role -eq $Role }
if (-not $r) { throw "Роль '$Role' не найдена в roles.csv" }
$tmpPass = Read-Host -AsSecureString 'Временный пароль'

New-ADUser -Name "$Last $First" -SamAccountName $Login -GivenName $First -Surname $Last `
  -UserPrincipalName "$Login@example.com" -Path $r.ou -AccountPassword $tmpPass `
  -ChangePasswordAtLogon $true -Enabled $true

foreach ($g in $r.groups -split ',') { Add-ADGroupMember -Identity $g -Members $Login }
"$(Get-Date -Format s) создан $Login, роль $Role, группы $($r.groups)" | Add-Content .\lifecycle.log

Ожидаемо: пользователь появился в нужном подразделении и состоит в группах роли; в lifecycle.log есть запись. Журнал — основа для проверок: по нему видно, кому и когда выдавались права. Для серверов Linux с каталогом FreeIPA операции аналогичны: FreeIPA и SSSD.

Шаг 4. Ежемесячная сверка с кадрами

Эта проверка ловит всё, что проскочило мимо процесса: уволенных, которых не отключили, и учётные записи, у которых нет человека. Скрипт сравнивает кадровый список с включёнными учётными записями каталога:

# reconcile.ps1: сверка кадрового списка и каталога
$hr = Import-Csv hr_active.csv | ForEach-Object { $_.login }

Write-Host '== Включены в каталоге, но нет в кадровом списке =='
Get-ADUser -Filter 'Enabled -eq $true' -SearchBase 'OU=Staff,DC=example,DC=com' -Properties LastLogonDate |
  Where-Object { $hr -notcontains $_.SamAccountName } |
  Select-Object SamAccountName, LastLogonDate

Write-Host '== Срок увольнения прошёл, учётная запись включена =='
Import-Csv hr_active.csv | Where-Object { $_.termination_date -and [datetime]$_.termination_date -lt (Get-Date) } |
  ForEach-Object { Get-ADUser -Identity $_.login -ErrorAction SilentlyContinue | Where-Object Enabled }

Ожидаемо: два списка, в идеале пустые. Каждая строка первого — либо подрядчик и служебная запись (их нужно выделить в отдельное подразделение и учитывать отдельно), либо ошибка процесса. Строки второго — уволенные с включённой записью, их блокируют немедленно и разбирают причину. Результат каждого прогона сохраняйте: ежемесячные отчёты «расхождений нет» служат доказательством работы процесса. Для узкого увольнения используйте также чек-лист: привилегированный доступ и увольнение.

Шаг 5. Перевод на другую должность

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

$role = (Import-Csv roles.csv | Where-Object role -eq 'Бухгалтер').groups -split ','
$actual = (Get-ADPrincipalGroupMembership sidorova).SamAccountName
Write-Host 'Лишнее для роли:'; $actual | Where-Object { $role -notcontains $_ }
Write-Host 'Не хватает:';       $role   | Where-Object { $actual -notcontains $_ }

Ожидаемо: список групп, которых нет в шаблоне роли, это кандидаты на отзыв. Некоторые группы выданы по заявкам сверх роли; для них должна быть заявка, иначе их снимают. Раз в квартал делайте ту же проверку для всех, а не только для переведённых: квартальный аудит прав.

Шаг 6. Единый вход как способ расширить охват

Самая трудная часть — приложения, у которых свои учётные записи: CRM, бухгалтерия, трекер. Для каждого придётся блокировать запись отдельно. Единый вход (SSO) решает это: приложение не хранит пароли, а доверяет внешнему провайдеру, и блокировка человека в одном месте закрывает все подключённые системы. Бесплатный вариант — Keycloak с подключением к каталогу как источнику пользователей:

docker run -d --name keycloak -p 127.0.0.1:8081:8080 \
  -e KC_BOOTSTRAP_ADMIN_USERNAME=admin -e KC_BOOTSTRAP_ADMIN_PASSWORD \
  quay.io/keycloak/keycloak:26.0 start-dev

Ожидаемо: интерфейс администратора на 127.0.0.1:8081. Режим start-dev предназначен для проверки; для боевой установки нужны база данных, TLS и режим start. Далее в разделе User federation подключите LDAP или Active Directory, а приложения — как клиентов по протоколам OIDC или SAML. Названия переменных зависят от версии (в старых используются KEYCLOAK_ADMIN и KEYCLOAK_ADMIN_PASSWORD), поэтому сверяйтесь с документацией вашей версии. Не все приложения умеют SSO: для остальных оставьте ручной блок в чек-листе увольнения.

Охват: сколько систем под управлением процесса

Оценка зрелости требует, чтобы централизованное управление жизненным циклом покрывало определённую долю систем: не менее половины на третьем уровне и 90% на четвёртом. Считать нужно системы, а не пользователей. Таблица ведётся рядом с реестром активов:

Охват = число систем «Да» к общему числу систем. Для четырёх из пяти получается 80%. Системы «Нет» включаются в чек-лист увольнения и в квартальный аудит вручную, а в плане появляется строка, как их подключить.

Когда пора переходить к IDM-продукту

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

До этого момента скрипты, кадровая выгрузка и ежемесячная сверка закрывают задачу с меньшими затратами.

Какие артефакты хранить

Диагностика

Где это в модели зрелости

Материал относится к направлению «Управление доступом» (хаб: управление доступом, карта: карта зрелости). На третьем уровне используется централизованная система управления жизненным циклом учётных записей с покрытием не менее половины автоматизированных систем и автоматизированным контролем создания, изменения и блокировки; на четвёртом охват не ниже 90% (например, IDM). Описанная схема — рабочий вариант для небольшой компании; полный продукт нужен при росте.

Как проверить

1. Тестовый приём: учётная запись создаётся скриптом по роли, группы совпадают с шаблоном.
2. Тестовое увольнение: запись блокируется в тот же день, сеансы закрыты, ключи отозваны.
3. Ежемесячная сверка за последние три месяца выполнена, отчёты сохранены.
4. Расчёт охвата показывает долю систем под процессом, исключения объяснены.

Источники

• CIS Control 5, управление учётными записями: cisecurity.org/controls.
• Keycloak, документация: keycloak.org/documentation.
• Microsoft Learn, модуль ActiveDirectory для PowerShell: learn.microsoft.com.
• NIST SP 800-53 Rev. 5, управление учётными записями (AC-2): csrc.nist.gov.