Квартальный аудит учётных записей и прав: выгрузка, сверка, подтверждение владельцами

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

Отдельная часть работы — поиск неактивных записей: Windows и AD, Linux. Роли и их описание: матрица роль-право. Жизненный цикл между аудитами: управление жизненным циклом.

Что и как часто проверять

График записывается в регламент и ставится в календарь на год вперёд. Аудит, который «проведём, когда доберёмся», превращается в ежегодную суету перед проверкой.

Схема работы

Основная идея схемы — отделить сбор фактов от решения. Факты собирает ИБ автоматически, решение принимает человек, который знает, зачем нужен доступ. Если решает только ИБ, она не знает контекста; если только владелец, он склонен оставлять всё как есть.

Шаг 1. Выгрузка фактических прав

Составьте список групп, определяющих доступ к критичным системам и привилегиям (файл privileged_groups.csv: группа, система, владелец), и выгрузите их членов. Для Active Directory:

# export_access.ps1: выгрузка членов групп с признаками для анализа
$groups = Import-Csv privileged_groups.csv      # колонки: group,system,owner

$rows = foreach ($g in $groups) {
  Get-ADGroupMember -Identity $g.group -Recursive | Where-Object objectClass -eq 'user' | ForEach-Object {
    $u = Get-ADUser -Identity $_ -Properties Enabled, LastLogonDate, Manager, PasswordNeverExpires
    [pscustomobject]@{
      system = $g.system; group = $g.group; owner = $g.owner
      user = $u.SamAccountName; enabled = $u.Enabled; last_logon = $u.LastLogonDate
      manager = $u.Manager; pwd_never_expires = $u.PasswordNeverExpires
    }
  }
}
$rows | Export-Csv "access_review_$(Get-Date -Format yyyy-MM).csv" -NoTypeInformation -Encoding UTF8
"$($rows.Count) строк"

Ожидаемо: файл с одной строкой на каждую пару «пользователь — группа» и количество строк в консоли. Для серверов Linux добавьте выгрузку локальных привилегий (getent group sudo wheel, файлы sudoers.d и authorized_keys на каждом узле, удобнее всего через Ansible) либо правила HBAC и sudo из каталога: FreeIPA и SSSD. Для облачных консолей и приложений используйте экспорт ролей из самих систем: у большинства он есть в разделе администрирования. Выгрузку сохраните как есть: это исходные данные аудита.

Шаг 2. Автоматический поиск отклонений

Прежде чем отправлять списки владельцам, уберите очевидное: скрипт отмечает строки, которые почти наверняка требуют решения. Это экономит время владельцев и повышает качество ответов.

#!/usr/bin/env python3
"""Поиск отклонений в выгрузке прав.
Использование: audit_flags.py access_review.csv hr_active.csv
hr_active.csv: колонка login со списком действующих работников."""
import csv
import sys
from collections import defaultdict
from datetime import datetime, timedelta

rows = list(csv.DictReader(open(sys.argv[1], encoding='utf-8-sig')))
hr = {r['login'].lower() for r in csv.DictReader(open(sys.argv[2], encoding='utf-8-sig'))}
limit = datetime.now() - timedelta(days=90)
groups_per_user = defaultdict(set)
flags = []

for r in rows:
    user = r['user'].lower()
    groups_per_user[user].add(r['group'])
    why = []
    if r['enabled'] == 'False':
        why.append('учётная запись отключена, но состоит в группе')
    if user not in hr:
        why.append('нет в кадровом списке')
    if r['last_logon']:
        try:
            if datetime.strptime(r['last_logon'][:10], '%Y-%m-%d') < limit:
                why.append('не заходил более 90 дней')
        except ValueError:
            pass
    else:
        why.append('вход не зарегистрирован')
    if r['pwd_never_expires'] == 'True':
        why.append('пароль без срока действия')
    if not r['owner']:
        why.append('у группы нет владельца')
    if why:
        flags.append((r['system'], r['group'], r['user'], '; '.join(why)))

for u, g in groups_per_user.items():
    if len(g) >= 4:
        flags.append(('несколько групп', ','.join(sorted(g)), u, f'состоит в {len(g)} привилегированных группах'))

for f in sorted(flags):
    print(' | '.join(f))
print(f'\nОтмечено строк: {len(flags)} из {len(rows)}', file=sys.stderr)

Ожидаемо: список с причиной по каждой строке и итоговое число. Формат даты last_logon зависит от региональных настроек, подправьте разбор под вашу выгрузку. Пороги (90 дней, четыре группы) условные, подберите по вашей среде. Отмеченные строки — не приговор, а вопросы: у подрядчика нет записи в кадровом списке нормально, но тогда он должен быть в отдельном списке подрядчиков.

Шаг 3. Подтверждение владельцами

Каждому владельцу системы отправляется его часть выгрузки с просьбой решить по каждой строке: оставить, снять или уточнить. Форма — таблица в файле или в системе заявок:

system,group,user,flags,decision,comment,decided_by,date
Бухгалтерия,G-1C-Admin,ivanov,не заходил более 90 дней,снять,,Козлова К.К.,2026-11-05
Бухгалтерия,G-1C-Admin,sidorova,,оставить,главный бухгалтер,Козлова К.К.,2026-11-05
ERP,G-ERP-Manager,petrov,нет в кадровом списке,уточнить,подрядчик? проверить договор,Иванов И.И.,2026-11-06

Правила, на которых держится процесс:

• Срок ответа короткий (5–10 рабочих дней), назначается заранее и записывается в регламент.
• Молчание не согласие. Привилегированные права без ответа владельца снимаются, остальные берутся на контроль у руководителя владельца. Если молчание означает «оставить», пересмотр теряет смысл.
• Решение принимает человек, который знает контекст. ИБ не решает за владельца, а владелец не подтверждает собственные права: свои строки ему проверяет ИБ или руководитель.
• Решение «уточнить» имеет срок: через неделю оно превращается в «снять».

Шаг 4. Отзыв лишнего и повторная проверка

Каждое решение «снять» превращается в задачу на отзыв, как любое изменение доступа: заявка, исполнитель, дата. После выполнения снова выгрузите права и сверьте: строки, у которых было решение «снять», должны исчезнуть. Расхождения — повод для разбора: либо отзыв не выполнили, либо доступ возвращается через другую группу или наследование.

comm -12 <(awk -F, '$5=="снять"{print $2","$3}' decisions.csv | sort) \
         <(awk -F, 'NR>1{print $2","$3}' access_review_new.csv | sort)

Ожидаемо: пустой вывод. Если вывод непустой, перечисленные пары «группа, пользователь» должны были быть сняты, но остались. Номера колонок зависят от формата ваших файлов.

Шаг 5. Протокол аудита

Итог аудита — документ на страницу. Он показывает, что проверка была, какие нашли отклонения и что с ними сделано:

Протокол аудита привилегированных учётных записей, 4 квартал

Дата: 05.11. Провёл: специалист ИБ. Системы в аудите: Active Directory, 1С, ERP, VPN, гипервизор.
Записей в выборке: 142. Отмечено автоматикой: 23.
Решения владельцев: оставить 118, снять 19, уточнить 5 (из них снять после уточнения 3).
Нарушения процесса: две учётные записи подрядчиков не были в списке подрядчиков (оформлено).
Отзыв выполнен: 22 из 22 (заявки № 801–822), повторная выгрузка 14.11 подтвердила.
Следующий аудит: февраль. Подписи: ИБ, руководитель ИТ.

Ежегодный пересмотр ролевых моделей

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

При проверке ролей учитывайте разделение полномочий: один человек не должен единолично проводить платёж и подтверждать его, выдавать себе права и согласовывать их. Подробнее: конфликт полномочий (SoD).

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

Диагностика

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

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

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

1. За последний квартал есть выгрузка прав и протокол аудита с подписями.
2. Для случайных трёх строк «снять» есть заявка и подтверждение отзыва повторной выгрузкой.
3. Для каждой критичной системы есть подтверждение владельца за квартал.
4. Скрипт поиска отклонений на тестовой выгрузке находит отключённую учётную запись в группе.
5. Документ о пересмотре ролей за последний год существует.

Источники

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