Борьба с привилегиями: как выстроить процесс контроля доступов в компании

Избыточные доступы сотрудников к различным ИТ-системам и сервисам стали бизнес-риском – киберпреступники используют их для проникновения в инфраструктуру компании, что приводит к финансовому и репутационному ущербу. Игорь Еньков, владелец продукта Innostage Cardinal PAM, рассказывает, как выстроить систему управления привилегированными доступами.

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

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

Когда нужно что-то менять

Можно выделить несколько типовых маркеров того, что процесс контроля привилегированных доступов не выстроен – и это может обернуться серьезными последствиями.

Первый «базовый» признак – учетные записи уровня администратора (root) и сервисные учетные записи (УЗ) со стандартными паролями и логинами, например – admin:admin. Сюда же можно отнести установку одинаковых паролей для групп привилегированных учетных записей и выдачу расширенных доступов «по умолчанию, на всякий случай». Также частый сценарий – наличие «суперадминов», когда в одной УЗ совмещены роли администратора, разработчика и специалиста по безопасности. Это прямое нарушение приказа ФСТЭК №117.

Если говорить о более сложных кейсах, то можно обратить внимание на Non-Human Identities – права, выданные «учеткам-роботам». А также на «вечные права» контрагентов, которые не отзываются после проведения работ, и права в облачных средах, используемых компаниями.

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

С чего начать управление привилегиями

Если система управления привилегированными доступами отсутствует или находится в зачаточном состоянии, начинать необходимо с построения базовых процессов. Они описаны в регуляторных требованиях, например в приказе №117 ФСТЭК России.

Однако важно не просто формально соответствовать требованиям регулятора, а сразу закладывать современные принципы безопасности – Just-in-Time (доступ только на время выполнения задачи) и Just-Enough-Access (только минимально необходимый уровень привилегий). Это позволит избежать ситуации, когда система изначально строится по устаревшей модели постоянных административных прав и требует полной перестройки в будущем.

Шаг 1. Инвентаризация привилегированных учетных записей

Невозможно защитить то, о существовании чего неизвестно. Первый шаг – это полная и автоматизированная инвентаризация всех привилегированных учетных записей во всей инфраструктуре.

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

Шаг 2. Персонификация и разделение ролей

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

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

Шаг 3. Принцип минимально необходимых и временных прав

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

Реализация подхода Just-in-Time позволяет автоматически выдавать привилегии на ограниченный срок и отзывать их сразу после завершения работы.

Шаг 4. Автоматизация жизненного цикла учетных записей

Жизненный цикл учетных записей должен быть управляемым и контролируемым. Неиспользуемые УЗ необходимо автоматически блокировать и удалять. Встроенные административные учетные записи – отключать или переименовывать. А все привилегированные доступы должны иметь заранее определенный срок действия.

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

Шаг 5. Обязательная многофакторная аутентификация

Доступ к привилегированным учетным записям должен быть защищен многофакторной аутентификацией. Использование только пароля является недостаточной мерой защиты.

Предпочтительными являются беспарольные методы аутентификации, такие как FIDO2-токены или сертифицированные криптографические средства защиты информации, соответствующие требованиям ГОСТ. Это существенно снижает риск компрометации даже при утечке учетных данных.

Шаг 6. Policy-as-Code и отказ от ручного управления

Политики доступа должны быть формализованы и описаны как код, интегрированный в инфраструктуру и процессы разработки. Подход, известный как Policy-as-Code, позволяет исключить ручное управление доступами, снизить влияние человеческого фактора и обеспечить воспроизводимость и прозрачность политик. Вместо субъективных решений отдельных администраторов организация получает централизованную, проверяемую и управляемую систему контроля привилегий.

Признаки зрелости процесса управления привилегиями

В совокупности эти меры формируют основу зрелой системы управления привилегированными доступами, где контроль строится не вокруг отдельных инструментов, а вокруг процессов, прозрачности и управляемости рисков. Реализовать это можно с помощью решений для управления привилегированным доступом (Privileged Access Management, PAM).

Наконец, когда процессы построены, а базовые принципы реализованы, важно понять, как оценить эффективность внедренных мер.

Рассмотрим несколько разбитых по разным уровням типовых признаков того, что контроль доступом работает:

1. Техническая база. Реализован принцип минимальных привилегий для всех учетных записей, используется сертифицированное регулятором средство PAM. Нет самописных скриптов и таблиц Excel для учета и управления учетными записями.

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

• Контроль действий. Привилегии повышаются только на время сессии (Just-In-Time). Политика доступа адаптивна, сессия может быть прервана автоматически при аномалии.

• Процессы. Выдача и отзыв прав автоматически привязаны к HR-системам. PAM интегрирован с системами управления учетными данными и доступом (IDM), аналитикой угроз и сам выявляет аномалии.

• Бизнес-метрики. Проверки не выявляют забытых и неиспользуемых учеток. ИБ отчитывается перед CEO о скорости получения доступа, а не о количестве выданных прав.

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

Автор: Игорь Еньков, владелец продукта Innostage Cardinal PAM.