Проверка прав доступа

Определение аудита прав доступа, которое часто дают в учебниках, звучит формально: систематическая проверка и анализ прав, выданных пользователям. На практике это проще.

Проверка прав доступа — это ответ на вопрос: «Кто имеет доступ к чему, зачем ему это нужно и правильно ли мы это раздали?»

Вот и всё. Когда сотни пользователей, десятки систем — никто не помнит, кто получил какой доступ и когда. Администраторы выдают права при найме, забывают отозвать при увольнении. Контрактники остаются в системах месяцами. Рядовые пользователи видят данные, не связанные с их ролью. Personal данные клиентов валяются открытыми для случайных сотрудников. Аудит помогает это увидеть и упорядочить.

Три причины, почему это критично

Безопасность и долг перед клиентами

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

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

Аудит прав показывает, где стена пропускает воду.

Соответствие стандартам и требованиям

ISO 27001 не рекомендует, а требует документированного управления доступом и регулярных проверок. SOC 2 — требует. GDPR требует контролировать обработку персональных данных на принципе «кто имеет доступ». HIPAA в здравоохранении, PCI DSS в платежной индустрии — везде одно и то же.

Требования звучат конкретно: вы обязаны знать, кто имеет доступ к конфиденциальной информации, вы обязаны это проверять регулярно, вы обязаны документировать всё, вы обязаны быть готовы показать результаты аудиторам. Если вы не можете ответить на вопрос «покажите, кто имеет доступ к личным данным» — это отказ.

Операционная эффективность и разбор инцидентов

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

Проверка прав доступа — это инвестиция в скорость разбора инцидентов и возможность вообще отследить, что произошло.

Что обычно находят при аудите

Когда администратор или CISO по-настоящему проверяет состояние управления доступом, картина получается неприятной.

Учетные записи уволенных и ушедших на фриланс сотрудников остаются активными по месяцам. Они всё ещё имеют доступ к электронной почте, файловым хранилищам, иногда к критичным системам. Никто не отозвал права своевременно, потому что процесса нет.

Все получают избыточные права. Младший специалист видит финансовые данные всей компании. Техподдержка имеет права администратора. Бухгалтер может удалять записи из базы. Люди даже не подозревают о масштабе своего доступа.

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

Нет единого окна видимости. Active Directory работает с одной логикой, Linux серверы используют sudoers и конфигурационные файлы, облако AWS имеет IAM с собственной моделью, базы данных требуют отдельных прав, веб-приложения имеют собственные роли. Никто не видит большую картину, кто на самом деле может делать что.

История изменения прав не ведётся. Кто дал доступ? Когда? По какой причине? Нет ответов. Невозможно проверить, было ли решение обоснованным, нельзя расследовать подозрительные изменения.

Какие объекты надо аудировать

Управление доступом — это не одна система.

На практике внимания требует контроль доступа в каждой из них. Active Directory и LDAP, где живут учетные записи и группы в корпоративной сети. Linux и Windows серверы, где права определяют, кто может выполнять команды и менять конфигурацию. Облачные платформы — AWS, Azure, Google Cloud, где IAM политики определяют, кто может запускать машины, читать данные, менять настройки.

Базы данных с наборами прав на таблицы и операции. Веб-приложения с их собственными ролевыми моделями. Электронная почта и общие почтовые ящики. Файловые хранилища и облако — SharePoint, Google Drive, S3 — где нужно знать, кто может читать, писать, удалять.

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

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

Три фундаментальные идеи

На что опирается весь аудит прав доступа — три концепции, которые появляются в каждом стандарте.

Принцип наименьших привилегий

Каждый пользователь, каждый сервис должны получить ровно столько прав, сколько нужно. Ни больше. Это снижает риск случайной ошибки и уменьшает поверхность для атак, если учетная запись будет скомпрометирована.

Ролевые модели доступа

Вместо раздачи прав отдельно каждому составляют роли. «Бухгалтер» имеет доступ к финансовым отчётам и счетам. «Разработчик» — к исходному коду и staging. «Support» — к логам и диагностике. Новый человек получает роль — и в системе сразу видно, что входит в его полномочия.

Разделение обязанностей

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

На бумаге все три идеи звучат логично. При внедрении в маленькой команде часто ломаются о нехватку времени и людей.