Защита привилегированных учетных записей: аудит облачной инфраструктуры в России

Аудит облачной инфраструктуры: защита привилегированных учетных записей — самое слабое звено бизнеса

Аналитики Cloud Advisor изучили обезличенные данные нескольких десятков российских компаний — и пришли к выводу, значимому для каждого руководителя ИБ: защита привилегированных учетных записей в облаке организована куда слабее, чем принято думать. Основой для анализа послужили свыше 40 тысяч виртуальных машин на платформах Cloud.ru и Yandex Cloud, а итоговая картина оказалась тревожной сразу по нескольким направлениям — от открытого периметра до недостаточного контроля над доступом администраторов.

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

Что показало исследование Cloud Advisor

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

Гендиректор Cloud Advisor Михаил Захряпин формулирует итог прямо: уровень защищённости облачных инфраструктур в России остаётся низким, а организации без критических проблем встречаются крайне редко. По его словам, платформы класса CNAPP (Cloud-Native Application Protection Platform) давно стали общепринятым мировым стандартом облачной защиты, тогда как подходы, унаследованные из on-premises-эпохи, с этой задачей уже не справляются.

Что такое привилегированная учетная запись и чем она отличается от обычной

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

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

• Администраторы домена (Domain Admin) — контролируют Active Directory целиком, включая все серверы и рабочие станции домена.
• Локальные администраторы (Local Admin) — располагают правами root или administrator на отдельном сервере либо рабочей станции.
• Сервисные учетные записи — используются приложениями, СУБД и фоновыми процессами для обмена данными между системами; часто наделены широкими правами, а пароль к ним годами остаётся неизменным.
• Учетные записи администраторов баз данных (DBA) — дают возможность читать, изменять и выгружать весь массив данных СУБД.
• Учетные записи сетевого и облачного администрирования — открывают управление маршрутизаторами, межсетевыми экранами и панелью управления облачного провайдера.
• Аварийные учетные записи (break-glass) — применяются в нештатных ситуациях, когда обычные механизмы входа отказывают; обладают максимальными правами, но проверяются реже, чем остальные.
• Учетные записи подрядчиков и внешних специалистов — открывают временный привилегированный доступ ИТ-аутсорсерам, интеграторам и службам поддержки вендоров.

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

Почему открытые пароли и неактивные аккаунты — путь к утечке

У 39% компаний секреты — пароли, токены, ключи доступа — лежат открыто на публично доступных машинах: по сути, это готовый набор для входа в инфраструктуру, не требующий ни единой попытки взлома. Добавим сюда 24% организаций, где внутри периметра уже обнаружено вредоносное ПО, — это не гипотетический риск, а зафиксированный факт проникновения.

Другая слабая точка — учётные записи, простаивающие дольше 90 дней. По данным исследования, их доля достигает 24%, и это типичная слепая зона: такие аккаунты вовремя не блокируют, поэтому воспользоваться ими способен кто угодно, раздобыв пароль или сессионный токен. Риск здесь схож с историей забытых учёток уволенных сотрудников — доступ формально существует, а контроль над ним утрачен.

Авторы исследования упоминают и низкую загрузку мощностей: 55% виртуальных машин используются менее чем на 10%. К безопасности это отношения не имеет напрямую, но косвенно подтверждает общую картину — системного контроля над облачной инфраструктурой не хватает, а значит, доступ администраторов к таким ресурсам, вероятнее всего, тоже никто толком не отслеживает.

MFA для привилегированного доступа: где чаще всего дыра

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

Для бизнеса риск прямой и понятный: заполучи злоумышленник пароль администратора — а при 39% открыто хранящихся секретов это не составляет труда, — одного этого пароля достаточно для полного контроля над системой. Многофакторная аутентификация как раз и служит барьером, который останавливает атаку на этом этапе даже тогда, когда пароль уже скомпрометирован.

Важно разделять защиту рядовых сотрудников и защиту администраторов. MFA для обычного персонала снижает риск компрометации отдельно взятого аккаунта. А контроль над действиями администраторов и другими привилегированными пользователями защищает сразу всю инфраструктуру — ведь именно такие учётные записи открывают путь ко всему остальному.

Риски и угрозы: инсайдеры, компрометация учетки, боковое перемещение

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

Отдельная категория угроз исходит изнутри — от инсайдера. Здесь выделяют три типичных сценария: злонамеренный сотрудник, намеренно использующий свои привилегии во вред компании; работник, допустивший ошибку — например, по неосторожности выдавший избыточный доступ или удаливший важные данные; и бывший сотрудник, чью учётную запись не отключили вовремя. Все три случая объединяет одно: без мониторинга действий пользователей с расширенными правами такие инциденты трудно предотвратить и ещё труднее расследовать постфактум.

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

Что такое PAM и как устроена система защиты привилегированного доступа

PAM (Privileged Access Management) — класс решений, отвечающих за управление и контроль доступа с повышенными правами. Рядом с этой аббревиатурой обычно фигурируют PIM (Privileged Identity Management — управление жизненным циклом административных аккаунтов, от выдачи прав до их отзыва) и PUM (Privileged User Management — управление правами конкретных пользователей). На практике границы между этими понятиями размыты: большинство продуктов на рынке закрывают задачи всех трёх направлений одновременно.

Из чего обычно состоит PAM-система:

• Защищённое хранилище паролей (Enterprise Password Vault) — секреты администраторов, сервисных аккаунтов и приложений держатся централизованно и в зашифрованном виде, а не в текстовых файлах и скриптах, как оказалось у 39% организаций из исследования Cloud Advisor.
• Брокеринг доступа — подключение к целевой системе проходит через PAM-платформу, а сам пользователь реального пароля не видит вовсе, что исключает его утечку или использование вне защищённого контура.
• Автоматическая ротация паролей — пароли административных аккаунтов меняются по расписанию либо сразу по завершении сеанса, из-за чего ценность украденного пароля стремительно падает.
• Запись и разбор сессий (Session Manager) — каждое действие администратора в целевой системе фиксируется и доступно для изучения при разборе инцидента.
• Многофакторная аутентификация — обязательное условие входа под административным аккаунтом независимо от того, насколько сложен сам пароль.
• Согласование доступа (workflow) — временные права предоставляются по запросу и требуют подтверждения ответственного сотрудника, а не действуют «по умолчанию».

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

Принцип наименьших привилегий (least privilege) означает, что пользователь, сервис или приложение получают ровно тот объём прав, который требуется для конкретной задачи, — и ни капли больше. На практике это отказ от логики «выдать администратору доступ ко всему домену, чтобы больше к этому не возвращаться» в пользу точечных прав, ограниченных по времени и охвату.

Воплотить этот принцип без потери удобства работы помогает доступ just-in-time (JIT): права выдаются на ограниченный срок под конкретную задачу и автоматически аннулируются по её завершении — вместо того чтобы оставаться активными постоянно, «на всякий случай».

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

Мониторинг, аудит и запись сессий

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

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

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

Что делать бизнесу: чек-лист по контролю привилегированного доступа

Результаты аудита Cloud Advisor — повод не для паники, а для предметной проверки собственной инфраструктуры прежде всего по нескольким направлениям.

• Включить многофакторную аутентификацию для всех административных и других учётных записей с расширенными правами — в первую очередь там, где есть доступ к серверам, базам данных и панелям управления облаком.
• Провести инвентаризацию всех учётных записей и заблокировать те, что не использовались 90 дней и дольше, — мера несложная, но при этом одна из самых игнорируемых на практике.
• Исключить открытое хранение паролей, ключей и токенов на публичных ресурсах, перенеся все секреты в защищённое хранилище.
• Закрыть критические уязвимости периметра с CVSS выше 9,0 — именно они открывают злоумышленнику кратчайший путь внутрь.
• Внедрить PAM-систему, которая фиксирует, кто, когда и что делал под административным аккаунтом, — это помогает не только предотвращать инциденты, но и разбирать их постфактум.
• Проводить аудит облачной инфраструктуры на регулярной основе, а не ограничиваться разовой проверкой на этапе внедрения.

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

Как выбрать PAM-систему: критерии и уровни защиты

Рынок предлагает решения разного уровня — от простых менеджеров паролей до полноценных PAM-платформ с записью сессий, workflow-согласованием и just-in-time-доступом. При выборе стоит ориентироваться не на маркетинговые формулировки, а на конкретный функционал и совместимость решения с уже действующей инфраструктурой.

Дополнительно стоит выяснить: охватывает ли решение все нужные протоколы и системы — вход в Windows, VPN, RDG, ADFS, ActiveSync, SSH; насколько бесшовно оно встраивается в работу без остановки бизнес-процессов и переобучения персонала «с нуля»; и присутствует ли продукт в реестре отечественного ПО — для компаний с требованиями по импортозамещению это способно стать решающим фактором.

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

Контроль доступа администраторов — вопрос не только практической безопасности, но и требований регуляторов. Организации, обрабатывающие персональные данные, обязаны соблюдать 152-ФЗ «О персональных данных», включая контроль доступа к информационным системам, где эти данные хранятся и обрабатываются. Субъекты критической информационной инфраструктуры (КИИ) — энергетика, транспорт, финансовый сектор, здравоохранение и ряд других отраслей — дополнительно подпадают под 187-ФЗ «О безопасности критической информационной инфраструктуры РФ» и обязаны выстраивать защиту значимых объектов, включая управление доступом с повышенными правами, согласно требованиям ФСТЭК России.

Помимо профильных законов, практику защиты доступа регулируют стандарты серии ГОСТ Р в области информационной безопасности — например, для финансового сектора предусмотрены отдельные требования к защите информации. Для организаций, нацеленных на импортозамещение, важным критерием остаётся наличие продукта в реестре отечественного ПО Минцифры России.

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

Частые вопросы

Почему защита привилегированных учетных записей важнее, чем защита обычных аккаунтов?

Потому что такой аккаунт открывает доступ не к одному ресурсу, а ко всей системе разом — серверам, базам данных, настройкам инфраструктуры. Если он не прикрыт MFA, злоумышленнику достаточно одного узнанного пароля, чтобы получить контроль над всей средой, а не над отдельным сервисом.

Что такое CNAPP и зачем это бизнесу

CNAPP (Cloud-Native Application Protection Platform) — класс платформ для комплексной защиты облачной инфраструктуры, который, по словам руководителя Cloud Advisor, уже стал мировым стандартом. В отличие от классических on-premises-инструментов, такие платформы учитывают специфику динамичной облачной среды.

Как понять, что в компании есть проблема с неактивными учетными записями

По данным Cloud Advisor, у 24% организаций обнаружены аккаунты, не задействованные 90 дней и дольше. Первый шаг к решению проблемы — инвентаризация всех активных учётных записей и её сверка со списком реально работающих сотрудников и сервисов.

Достаточно ли включить MFA только для администраторов

Судя по цифрам исследования, риск сохраняется на обоих уровнях: без MFA остаются 48% рядовых аккаунтов и около половины административных. Внедрять многофакторную аутентификацию нужно для всех пользователей, но логичнее начинать с администраторов и других ролей повышенного уровня — цена их компрометации выше.

Откуда взяты данные исследования

В основе исследования — анализ Cloud Advisor свыше 40 тысяч виртуальных машин в облаках Cloud.ru и Yandex Cloud. Компания изучала обезличенные данные организаций из разных отраслей и разного масштаба бизнеса.

Чем PAM отличается от обычной многофакторной аутентификации?

MFA защищает конкретно момент входа, подтверждая, что за учётной записью стоит её законный владелец. PAM решает более широкую задачу: хранит и обновляет пароли, брокерит доступ так, что реальный пароль пользователю не виден, ведёт запись сессий и определяет, кто и на какой срок получает расширенные права. Обычно MFA входит в PAM-систему как один из её элементов, а не заменяет её целиком.

Зачем нужна запись сессий, если есть журналы событий системы?

Обычные системные журналы охватывают далеко не всё и могут быть удалены или изменены при компрометации аккаунта с высокими правами. Запись сессий ведёт отдельный независимый модуль PAM-платформы, изменить который сам администратор не в состоянии, — это даёт полную и достоверную картину произошедшего при расследовании.

Что такое принцип наименьших привилегий простыми словами?

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

Сколько времени обычно занимает внедрение PAM-решения?

Срок зависит от масштаба инфраструктуры и выбранного продукта: точечное подключение MFA для ключевых администраторов занимает несколько дней, а комплексный проект с полной инвентаризацией административных аккаунтов и настройкой workflow-согласования способен растянуться на месяцы. Разумнее начинать с самых критичных учётных записей, а не пытаться закрыть всю инфраструктуру одним проектом сразу.

Обязательно ли использовать PAM-решение для соответствия 152-ФЗ и 187-ФЗ?

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

Вывод: защита привилегированных учетных записей начинается с контроля доступа

Исследование Cloud Advisor подтверждает то, что специалисты по ИБ давно замечают на практике: главная угроза чаще кроется не во внешнем периметре, а в том, как выстроен доступ внутри компании. Защита привилегированных учетных записей, контроль неактивных аккаунтов и отказ от открытого хранения секретов — это не разовые проекты, а постоянная дисциплина.

Именно эти задачи и призвана решать Контур.Эгида — решение партнёра СКБ Контур в сфере корпоративной информационной безопасности. Многофакторная аутентификация для входа в Windows, VPN, ADFS и другие корпоративные системы, а также инструменты управления доступом с повышенными правами закрывают ровно те пробелы, которые выявило исследование: MFA для администраторов, контроль их действий и своевременный отзыв прав у неактивных аккаунтов — без лишних препятствий для повседневной работы сотрудников.

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