Системы PAM стали обязательным элементом защиты современных КИИ. Но их внедрение часто превращается в формальность: компании покупают дорогостоящее решение, но допускают критические ошибки при его настройке. В результате привилегированные учётные записи остаются главной целью злоумышленников.
- 1. Введение
- 2. Ошибка 1. Использование общих или встроенных учётных записей без контроля
- 3. Ошибка 2. Отсутствие сегрегации обязанностей и принципа минимальных привилегий
- 4. Ошибка 3. Неконтролируемое использование протоколов RDP и SSH без шлюзов
- 5. Ошибка 4. Слабая или нерегулярная ротация паролей привилегированных учёток
- 6. Ошибка 5. Хранение привилегированных паролей в открытом виде или ненадёжных хранилищах
- 7. Ошибка 6. Отсутствие мониторинга и записи сессий привилегированных пользователей
- 8. Ошибка 7. Игнорирование сервисных учётных записей и учёток приложений
- 9. Ошибка 8. Отсутствие автоматического отзыва доступа при увольнении или смене роли сотрудника
- 10. Ошибка 9. Слабая защита самой PAM-системы
- 11. Ошибка 10. Формальное внедрение PAM без изменения процессов и культуры безопасности
- 12. Выводы
Введение
Привилегированные учётные записи — это «золотой ключ» к инфраструктуре любой компании. Получив к ним доступ, злоумышленник может отключить защиту, похитить данные или парализовать бизнес-процессы. Инструменты класса PAM (управление привилегированным доступом, Privileged Access Management) созданы, чтобы этого не допустить: они позволяют контролировать, кто, когда и зачем использует права администратора. Однако практика показывает, что даже после внедрения PAM организации остаются уязвимыми. Причина — в типовых ошибках конфигурации, которые сводят на нет все преимущества технологии.
Ошибка 1. Использование общих или встроенных учётных записей без контроля
Одна из наиболее частых ошибок при внедрении PAM — выдача общих учётных записей с расширенными привилегиями для нескольких сотрудников. Такой подход полностью нивелирует персональную ответственность и делает невозможным точное определение виновного в случае инцидента.
Суть ошибки
Компании создают учётные записи типа administrator, root или backup_admin, которыми пользуются сразу несколько человек. Встроенные учётные записи (например, в СУБД SQL Server или Administrator в Windows) часто остаются активными и с паролями по умолчанию. При этом отсутствует привязка действий к конкретному пользователю: если общей учёткой воспользовались пятеро, определить, кто именно совершил вредоносное действие, невозможно. PAM-система либо не внедрена для таких учёток, либо настроена формально — пароль известен всем, и его ротация не происходит.
Пример ошибки: инцидент в Twitter (2020 год)
В 2020 году злоумышленники через социальную инженерию получили доступ к внутренним административным инструментам Twitter (ныне X), использующим общие учётные записи. Это позволило им взломать аккаунты известных политиков и бизнесменов. Согласно отчёту CrowdStrike, в 40 % атак злоумышленники используют легитимные, но скомпрометированные общие учётные записи, и инцидент Twitter стал ярким подтверждением этой статистики.
Чем опасна эта ошибка
Когда несколько администраторов используют общую учётную запись, установить истинного виновника инцидента становится невозможно — действия каждого конкретного сотрудника неотличимы друг от друга. Это не только парализует расследование, но и делает бессмысленным применение дисциплинарных мер.
Ещё серьёзнее проблема возникает при увольнении: отозвать доступ только у одного сотрудника, не меняя пароль для всех остальных, технически нельзя. Смена пароля каждый раз при кадровых изменениях нарушает операционные процессы, а отсутствие смены оставляет доступ уволенному специалисту.
Усугубляет ситуацию то, что общие учётки, как правило, наделены максимальными привилегиями (Domain Admin, Enterprise Admin), что превращает их в самую желанную цель для злоумышленников. Даже если PAM-система формально внедрена в компании, отсутствие контроля над общими учётными записями оставляет в инфраструктуре «чёрный ход», через который атакующие могут действовать безнаказанно, а любое расследование инцидента будет заведомо провальным, что неизбежно ведёт к росту ущерба и репутационным потерям.
Рисунок 1. Методы проникновения в инфраструктуру компаний. Источник: Solar
Ошибка 2. Отсутствие сегрегации обязанностей и принципа минимальных привилегий
В настройке PAM важно соблюдать принцип сегрегации обязанностей (Segregation of Duties, SoD) — сотрудник получает доступ только к тем системам, которые напрямую связаны с его работой. Когда это правило игнорируется, последствия могут быть катастрофическими.
Суть ошибки
Нередко одной учётной записи предоставляется доступ к системам, никак не связанным с должностными обязанностями сотрудника, например если администратор сети получает права на изменение кода в репозитории. Принцип минимальных привилегий не применяется: права дают «на всякий случай», а не для выполнения конкретных задач. Сегрегация обязанностей полностью отсутствует: один и тот же человек может создавать платёжные поручения и подтверждать их или разрабатывать код и использовать его в «продакшене».
Пример ошибки: атака на SolarWinds (2020 год)
В 2020 году при атаке на SolarWinds злоумышленники скомпрометировали учётную запись, которая имела доступ и к исходному коду, и к процессу сборки, и к механизму подписи обновлений. Это позволило внедрить вредоносную программу в легитимные обновления программного обеспечения, затронув тысячи организаций по всему миру.
Чем опасна эта ошибка
Если одна учётная запись обладает избыточными правами, её компрометация открывает злоумышленнику доступ сразу ко множеству критических систем, позволяя атакующему молниеносно распространить своё влияние по всей инфраструктуре.
Нарушение сегрегации обязанностей резко повышает риск инсайдерских атак: сотрудник получает возможность совершать противоправные действия без дополнительного контроля, например создавать и сразу утверждать фиктивные платежи.
Сама идея PAM подразумевает жёсткое ограничение привилегий, и если права раздаются «на всякий случай», система управления доступом превращается в фикцию — зачем управлять доступом, если у всех и так есть все права? Контролирующие органы, включая Центробанк и ФСТЭК, рассматривают отсутствие сегрегации обязанностей как критическое нарушение, влекущее за собой штрафы и предписания.
Кроме того, при избыточных правах практически невозможно выстроить эффективную защиту от горизонтального перемещения злоумышленника, поскольку скомпрометированная учётная запись уже имеет доступ ко всем необходимым ресурсам.
Ошибка 3. Неконтролируемое использование протоколов RDP и SSH без шлюзов
Прямые подключения к серверам по протоколам удалённого рабочего стола (Remote Desktop Protocol, RDP) или SSH — это как оставить дверь в серверную открытой. Без PAM-шлюза (сессионного менеджера) вы не видите, что делает администратор на сервере, и не можете остановить атаку в реальном времени.
Суть ошибки
Администраторы подключаются к серверам напрямую, минуя PAM-шлюз (сессионный менеджер). Проксирование сессий тоже не используется: все действия пользователя не записываются, не контролируются и не прерываются при подозрительной активности. Открытые порты RDP и SSH доступны как из корпоративной сети, так и из интернета, что расширяет поверхность атаки, позволяя злоумышленникам напрямую заходить в инфраструктуру компании.
Пример ошибки: атака на Colonial Pipeline (2021 год)
В 2021 году оператор топливопроводов Colonial Pipeline стал жертвой программы-вымогателя. Злоумышленники проникли в систему через скомпрометированный VPN-доступ и затем вошли напрямую по RDP в систему управления трубопроводом. После этого инцидента агентство кибербезопасности США (CISA) настоятельно рекомендует закрывать доступ к RDP из интернета или использовать шлюзы (Jump Boxes) для контроля доступа к объектам КИИ.
Чем опасна эта ошибка
Когда администратор подключается к серверу напрямую, минуя PAM-шлюз, злоумышленник, заполучивший его учётные данные, получает полную свободу действий: он может незаметно запускать вредоносные скрипты, копировать конфиденциальные данные или отключать средства защиты.
Отсутствие записи сессии лишает службу безопасности возможности расследовать инцидент и понять, какие системы затронуты, какие данные похищены, оставлены ли бэкдоры. Прямые подключения через открытые порты делают серверы видимыми в сети, что многократно упрощает злоумышленникам разведку и проведение атак типа подбора паролей (brute-force).
В такой конфигурации невозможно применить принципы нулевого доверия (Zero Trust), поскольку доступ к критическим ресурсам не контролируется централизованно. И самое главное: даже если компания потратила миллионы на внедрение PAM, возможность обойти систему через прямое подключение сводит все эти инвестиции к нулю.
Рисунок 2. Рост числа атак на RDP в марте 2020 года. Источник: Xakep.ru
Ошибка 4. Слабая или нерегулярная ротация паролей привилегированных учёток
Автоматизированные средства подбора паролей совершенствуются с каждым годом, поэтому регулярная смена паролей привилегированных учётных записей — критически важный элемент защиты. Если пароли не меняются годами, компания рискует столкнуться с последствиями давних утечек.
Суть ошибки
Пароли привилегированных учётных записей меняются крайне редко — раз в год или реже, а то и вовсе остаются неизменными годами, а автоматическая ротация паролей после каждого использования или по расписанию не настроена в PAM-системе. При этом нередко используются слабые пароли или пароли, уже скомпрометированные в других утечках, но компания об этом просто не знает.
Пример ошибки: утечка данных Uber (2022 год)
В 2022 году злоумышленник получил доступ к внутренним системам Uber, используя учётные данные администратора, которые были украдены ещё в 2016 году и так и не изменены. Это позволило атакующему проникнуть в инфраструктуру и скомпрометировать множество критически важных систем компании.
Чем опасна эта ошибка
Если пароль привилегированной учётной записи однажды был скомпрометирован — через фишинг, утечку базы данных или перехват трафика, — злоумышленник может использовать его годами, оставаясь полностью незамеченным.
Отсутствие регулярной ротации напрямую нарушает требования ключевых регуляторов, включая приказ ФСТЭК № 239 и стандарт PCI DSS v4.0, что создаёт риски не только с точки зрения безопасности, но и влечёт за собой штрафы. При компрометации учётной записи компания оказывается в ловушке: пока инцидент не обнаружен и пароль не сменён вручную, атакующий сохраняет долгосрочный доступ.
Автоматическая ротация — это фундаментальная функция любой PAM-системы, и, если она не настроена, дорогостоящее решение превращается в обычное хранилище паролей, не обеспечивающее реальной защиты. Даже если пароль изначально был очень сложным, со временем он может быть подобран или украден, и отсутствие ротации лишь усугубляет последствия.
Ошибка 5. Хранение привилегированных паролей в открытом виде или ненадёжных хранилищах
Скомпрометировать пароль привилегированной учётной записи — самый простой способ получить доступ к критической инфраструктуре. Однако даже крупные технологические компании допускают элементарные ошибки в хранении столь важной информации.
Суть ошибки
Пароли от привилегированных учёток хранятся в текстовых файлах, Excel-таблицах, переменных окружения, исходном коде или даже на стикерах, приклеенных к монитору. Централизованное защищённое хранилище (PAM-решение) не используется, а доступ к таким файлам имеют многие сотрудники, включая тех, кому эти пароли совершенно не нужны.
Пример ошибки: инцидент с Microsoft (2023 год)
В 2023 году стало известно, что ключи доступа (SAS-токены) к хранилищу Azure Storage оказались в публичном GitHub-репозитории сотрудников Microsoft. Несмотря на то что ключи доступа лежали в GitHub с 2020 года, инцидент не привёл к утечке данных клиентов.
Чем опасна эта ошибка
Как только злоумышленник проникает в корпоративный периметр (веб-уязвимость, фишинговое письмо или действия инсайдера), он в первую очередь начинает искать файлы с паролями. Если привилегированные учётные данные хранятся в открытом виде, атакующий почти гарантированно их найдёт и получит ключи от всех систем без какого-либо взлома.
Отсутствие централизованного контроля над тем, кто и когда обращался к паролям, делает невозможным аудит и расследование инцидентов. Такая практика грубейшим образом нарушает базовые требования стандартов PCI DSS, ISO 27001 и российских регуляторов.
Даже если в компании внедрена PAM-система, но часть паролей продолжает храниться вне её, в безопасности появляются «дыры», которые обязательно будут использованы атакующими.
В конечном счёте хранение критических данных в открытом виде — это маркер крайне низкой зрелости процессов информационной безопасности и отсутствия базовой культуры безопасности среди сотрудников.
Ошибка 6. Отсутствие мониторинга и записи сессий привилегированных пользователей
Без отслеживания действий в сессиях пользователей невозможно вовремя среагировать на угрозу. Даже если злоумышленник уже внутри, запись сессии позволяет понять масштаб бедствия и собрать доказательства.
Суть ошибки
PAM-система настроена только на выдачу паролей, но не на запись и анализ того, что делает пользователь после подключения к целевой системе. Мониторинг команд, запущенных процессов и передаваемых файлов отсутствует, интеграции с SIEM для выявления аномалий в реальном времени также нет.
Пример ошибки: продолжение инцидента в Twitter (2020 год)
В ходе атаки на Twitter (ныне X) в 2020 году злоумышленники, получив доступ к привилегированной учётной записи с помощью телефонного фишинга, несколько часов действовали внутри инфраструктуры, при этом их действия не записывались и не анализировались. Это позволило им беспрепятственно менять настройки аккаунтов и похищать данные. Запись сессий помогла бы выявить аномалии на ранних этапах атаки.
Чем опасна эта ошибка
Без записи сессий вы не можете доказать, что именно делал злоумышленник: какие данные похитил, какие системы затронул, оставил ли бэкдоры. Расследование инцидентов становится гаданием, а оценка ущерба — приблизительной, что мешает взаимодействию с правоохранителями и страховыми компаниями. Отсутствие мониторинга в реальном времени позволяет атакующему действовать незаметно, пока не станет слишком поздно. Регуляторы всё чаще требуют не просто контроля доступа, а записи и анализа действий привилегированных пользователей, что подтверждает необходимость внедрения систем мониторинга сессий для кибербезопасности.
Ошибка 7. Игнорирование сервисных учётных записей и учёток приложений
Сервисные учётные записи — это «молчаливое большинство» в инфраструктуре. У них часто максимальные права, они не привязаны к конкретным людям и редко контролируются. Именно их нередко используют злоумышленники для атак на цепочки поставок.
Суть ошибки
Сервисные учётные записи (для запуска служб, резервного копирования, межсерверного взаимодействия) не включаются в PAM-периметр. Учётные записи приложений, которые используются для доступа к базам данных или API, не управляются централизованно, а их пароли практически не меняются. Такие учётки часто имеют максимальные привилегии, но при этом не ассоциированы с конкретными людьми и не контролируются.
Пример ошибки: атака на Kaseya (2021 год)
В июле 2021 года хакерская группа REvil атаковала разработчика ПО Kaseya, используя уязвимость в его продукте VSA. Скомпрометированная сервисная учётная запись VSA-агента позволила злоумышленникам выполнять команды на тысячах клиентских машин, что привело к массовому заражению программами-вымогателями. По данным исследования Silverfort, до 70 % всех учётных записей в домене — это сервисные учётки, при этом их пароли меняются в 2 раза реже, чем пароли пользователей, что делает вопрос их защиты особенно острым вне зависимости от охватов и ниши компаний.
Чем опасна эта ошибка
Сервисные учётные записи — излюбленная цель злоумышленников, так как они редко меняются и часто имеют широкие права. Компрометация такой учётки может привести к атаке на цепочку поставок, как в случае с Kaseya или SolarWinds. Отсутствие ротации паролей для сервисных учёток делает их уязвимыми даже при базовых атаках типа pass-the-hash. Без управления сервисными учётками PAM-система защищает лишь часть инфраструктуры, оставляя критические уязвимости. Ввиду этого аудиторы сегодня всё чаще проверяют именно сервисные учётки, так как их защита стала маркером реальной зрелости информационной безопасности.
Ошибка 8. Отсутствие автоматического отзыва доступа при увольнении или смене роли сотрудника
Уволенный сотрудник с активным доступом к привилегированным учёткам может стать бомбой замедленного действия, но многие операторы ИБ объектов КИИ об этом даже не задумываются.
Суть ошибки
Когда процесс отзыва доступа не автоматизирован и не интегрирован с HR-системой, при увольнении сотрудника его привилегированные учётные записи могут оставаться активными годами. Регулярная сверка прав доступа с актуальными ролями и должностями не проводится, и в системе накапливаются «мёртвые души» — учётные записи людей, которые давно не работают в компании.
Пример ошибки: инцидент в Uber (2016 год)
В 2016 году бывший сотрудник Uber использовал старые учётные данные для доступа к базам данных миллионов пользователей. Это привело к крупной утечке персональных данных и огромному репутационному ущербу для компании.
Чем опасна эта ошибка
Уволенные сотрудники, особенно если расставание не прошло гладко, представляют собой одну из самых серьёзных угроз. Имея легитимные учётные данные, они могут незаметно вернуться в инфраструктуру и нанести ущерб — от кражи данных до саботажа.
Когда отзыв доступа не автоматизирован, неизбежны человеческие ошибки: кто-то забыл, не успел, переложил ответственность на другого, и в результате доступ остаётся открытым даже на годы. Даже если PAM-система внедрена, но доступ не отзывается своевременно, она бесполезна — учётная запись продолжает считаться легитимной и может быть использована.
Ручной отзыв всегда медленный и фрагментарный: можно отозвать доступ к почте, но забыть про доступ к серверам или сервисным учёткам. В результате компания живёт с открытой дверью, даже не подозревая об этом до тех пор, пока не случается инцидент.
Ошибка 9. Слабая защита самой PAM-системы
Если система, управляющая всеми паролями, защищена хуже, чем обычная учётка пользователя, злоумышленникам даже не нужно взламывать остальную инфраструктуру — достаточно скомпрометировать PAM.
Суть ошибки
Администраторы PAM нередко используют слабую аутентификацию, а многофакторная аутентификация для доступа к консоли управления отсутствует. Сама PAM-система не изолирована от общей сети, не обновляется своевременно и не подвергается регулярному аудиту. Парадоксальным образом учётные записи администраторов PAM защищены хуже, чем те учётки, которыми они управляют.
Пример ошибки: атака на LastPass (2022 год)
В 2022 году злоумышленники скомпрометировали учётную запись разработчика LastPass и получили доступ к хранилищу паролей. Атака стала возможной из-за того, что на домашнем компьютере сотрудника использовалась уязвимая версия медиаплеера Plex, через которую был украден корпоративный пароль. При этом к учётной записи не была применена многофакторная аутентификация.
Чем опасна эта ошибка
PAM-система по определению является самым лакомым куском для злоумышленника — взломав её, он получает доступ ко всем паролям, сертификатам и ключам компании, то есть фактически ко всей инфраструктуре. PAM становится единой точкой отказа, и его компрометация означает тотальную компрометацию бизнеса.
Когда администраторы PAM используют слабую защиту, нарушается фундаментальный принцип «защиты самого защитника»: стражи оказываются самыми уязвимыми. Регуляторы требуют особых, усиленных мер для систем управления доступом, включая обязательную изоляцию и многофакторную аутентификацию, но эти требования часто игнорируются.
Без регулярного аудита и своевременных обновлений PAM-система сама может содержать уязвимости, которые будут использованы атакующими. Возникает чудовищный парадокс: система, призванная защищать самое ценное, сама становится самым слабым звеном.
Рисунок 3. Результаты опроса AM Live относительно приоритетов использования PAM
Ошибка 10. Формальное внедрение PAM без изменения процессов и культуры безопасности
Купить PAM и надеяться, что он сам всё защитит, — наивно и опасно. Если администраторы продолжают использовать локальные пароли в обход системы, деньги на внедрение будут потрачены впустую.
Суть ошибки
Компания приобретает PAM-решение, но не меняет сложившиеся процессы: администраторы по привычке продолжают использовать локальные пароли и подключаться напрямую, потому что «так быстрее» и привычнее. Обучение сотрудников не проводится, важность PAM не объясняется, ответственность за обход системы не вводится. Руководство полагает, что сам факт покупки софта автоматически решает проблему, и не контролирует соблюдение новых регламентов.
Пример ошибки: множество инцидентов в компаниях, внедривших PAM «для галочки»
Во многих организациях, где PAM был внедрён формально, система годами простаивает без дела. Привилегированные учётные записи остаются неуправляемыми, администраторы продолжают хранить пароли в Excel и подключаться по RDP напрямую. Дорогостоящее решение не приносит никакой пользы, а риски остаются на прежнем уровне.
Чем опасна эта ошибка
Технология сама по себе бессильна изменить человеческое поведение. Если люди привыкли обходить PAM, они будут это делать, и никакая, даже самая совершенная, система не сможет их остановить. Защита превращается в фикцию, а миллионные инвестиции — в выброшенные на ветер деньги.
Отсутствие культуры безопасности приводит к тому, что даже изначально правильная настройка PAM со временем деградирует: регламенты забываются, контроль ослабевает, и всё возвращается на круги своя.
Аудиторы легко распознают формальное внедрение: если в логах PAM нет сессий, а администраторы продолжают работать, значит, система не используется. Без реального изменения процессов и отношения сотрудников к безопасности компания не сможет пройти серьёзные проверки регуляторов.
Но главное даже не в аудиторах: без изменения культуры PAM остаётся очередной «галочкой» в отчёте, а инфраструктура — такой же уязвимой, как и до внедрения.
Выводы
Корень всех десяти разобранных ошибок лежит не в технологической плоскости, а в разрыве между приобретённым инструментом и реальными процессами. Компании покупают дорогостоящие PAM-решения, но продолжают использовать общие учётки, давать избыточные права, хранить пароли в Excel и применять прямые RDP-подключения к серверам. Технология оказывается бессильна там, где не меняется культура безопасности и не выстроены жёсткие регламенты.
Управление привилегированным доступом требует системного подхода: каждая учётная запись с повышенными правами должна быть на учёте, каждый вход — только через защищённый шлюз с записью сессии, каждый пароль — автоматически ротироваться, а доступ уволенных сотрудников — отзываться мгновенно. Без этого PAM превращается в очередную «галочку» для аудитора, а инфраструктура остаётся уязвимой для атак, которые сегодня нацелены именно на привилегированные учётки.
Компании, которые закроют эти ошибки и выстроят реальный, а не формальный контроль над привилегированным доступом, получат не только соответствие требованиям регуляторов, но и настоящую устойчивость к киберугрозам. Остальные неизбежно столкнутся с инцидентами, цена которых будет измеряться миллионами рублей, остановкой бизнеса и уголовной ответственностью руководства.
