Пароль остается главным способом защиты привилегированных учетных записей в крупном бизнесе. Это риск уровня инфраструктуры: такие записи открывают доступ к серверам, базам данных, сетевому оборудованию, облакам, системам резервного копирования и внутренним административным панелям.
Риски для бизнеса — в паролях
BI.ZONE PAM изучила практику управления привилегированным доступом в корпоративном секторе. Результат выглядит тревожно: 73% таких учетных записей защищены паролями. Сертификаты с криптографической защитой используются только для 27%.
Пароль можно подобрать, украсть через фишинг, вытащить из утечки, перехватить на зараженной машине, найти в конфиге, дампе памяти, скрипте автоматизации или старом документе. Сертификатная аутентификация устроена иначе: доступ подтверждается криптографическим ключом, а не строкой символов, которую человек может повторно использовать в десяти системах.
Исследование показывает, что проблема не ограничивается просто фактом использования паролей. В корпоративной инфраструктуре до сих пор встречаются учетные записи, где пароль не меняют годами.
У 19% корпоративных аккаунтов пароли старше одного года. У 2% — старше 10 лет. Для части записей включен атрибут PasswordNeverExpires. В переводе с админского на человеческий: пароль никогда не истекает автоматически. В среднем такой режим включен у 22% учетных записей.
Есть еще один неприятный слой — совпадающие пароли. У 19% учетных записей пароли совпадают с паролями других пользователей внутри той же компании. В одной из организаций показатель доходил до 43%. Причина банальна: сотрудникам выдают стандартные пароли при трудоустройстве, а дальше их никто не меняет. Для атакующего это просто подарок. Один пароль может открыть доступ сразу к нескольким сервисам. Ведь привилегированная учетная запись — это аккаунт с расширенными правами. Через нее можно менять настройки, создавать новых пользователей, читать чувствительные данные, подключаться к серверам, управлять сетевыми устройствами, отключать защиту, смотреть журналы, запускать скрипты и работать с резервными копиями.
В NIST SP 800-63B Rev. 4, опубликованной в 2025 году, подход к паролям заметно изменился: теперь важнее длина и проверка на утечки, а не сложные правила вроде «заглавная буква, цифра и спецсимвол». Для пароля, который используется как единственный фактор входа, рекомендуется минимум 15 символов. Системы также должны поддерживать пароли длиной не менее 64 символов, пробелы, печатные ASCII-символы и Unicode.
В обычной атаке злоумышленнику нужно пройти несколько этапов: попасть внутрь, закрепиться, повысить права, найти ценные системы и вывести данные. Привилегированная запись сокращает маршрут. Иногда она сразу предоставляет доступ туда, куда атакующий и хотел попасть.
BI.ZONE ранее фиксировала, что 39% киберинцидентов за январь–сентябрь 2025 года были связаны с использованием или компрометацией привилегированных учётных записей. В 57% таких случаев использовались действующие учетные данные. Это могут быть украденные пароли, данные из утечек, результаты фишинга или подбора.
Отдельная техника — манипуляции с учетными записями. Злоумышленники создают скрытые администраторские права, закрепляются в системе и повышают уровень доступа. Такие действия встречались в 40% эпизодов, которые анализировали специалисты BI.ZONE.
Долгоживущий пароль опасен по нескольким причинам. Его успевают скопировать в скрипты, записать в инструкции, сохранить в браузере, отправить в чате, положить в файл на сетевом диске, передать подрядчику, использовать в тестовой среде и забыть о нем после увольнения сотрудника. Через год уже сложно понять, где именно пароль всплыл, а спустя 10 лет — почти невозможно. Такой пароль нельзя считать секретом. Это скорее артефакт инфраструктуры, который давно разошелся по внутренним слоям компании.
Добавим к этому тот факт, что в крупных организациях один ИТ-специалист может иметь от трех до семи привилегированных учетных записей. Часть этих записей используется в разных средах: домен, Linux-серверы, базы данных, облако, средства виртуализации, сетевое оборудование, CI/CD, резервное копирование. Без централизованного учета появляется «зоопарк» доступов, где никто не видит полной картины.
Сертификаты повышают безопасность
Сертификатная аутентификация убирает из процесса обычный пароль. Доступ подтверждается криптографией: закрытым ключом и сертификатом. Такой доступ сложнее украсть простым фишинговым письмом. Его проще ограничивать по сроку действия, отзывать, выпускать заново и привязывать к конкретному пользователю, устройству или роли.
Да, сертификаты тоже нужно защищать. Закрытые ключи нельзя хранить где попало. Нужны контроль жизненного цикла, журналирование, отзыв, автоматическая ротация, ограничения по ролям и понятная процедура восстановления доступа.
Но у сертификатов есть важное преимущество: они лучше подходят для автоматизации. В мире TLS это уже стало трендом. CA/Browser Forum утвердил поэтапное сокращение срока жизни публичных TLS-сертификатов: к 2029 году максимальный срок должен снизиться до 47 дней. Сокращение срока действия сертификатов снижает риски, которые возникают из-за долго живущих ключей и устаревших настроек. Если сертификат действует слишком долго, он может оставаться в инфраструктуре даже после компрометации закрытого ключа, смены владельца домена, обновления требований к шифрованию или обнаружения ошибки в алгоритмах. Чем короче срок действия, тем быстрее такие сертификаты выводятся из оборота и заменяются новыми.
Для компаний это означает переход к более частой ротации и автоматизации. Ручное продление сертификатов становится рискованным. Поэтому сокращение срока действия сертификатов подталкивает бизнес к управлению жизненным циклом сертификатов: автоматическому выпуску, продлению, отзыву и контролю за всеми сертификатами в инфраструктуре.Для привилегированного доступа логика похожая. Чем короче срок жизни секрета и чем меньше постоянных прав, тем меньше окно для атаки.
Сокращаем привилегии
PAM — это управление привилегированным доступом. Система отвечает за то, кто, куда, зачем и на сколько получил повышенные права. Хорошая PAM-платформа хранит секреты, выдает временный доступ, записывает административные сессии, меняет пароли, работает с сертификатами, отзывает доступы после увольнения, помогает расследовать действия и не позволяет администраторам блуждать по инфраструктуре с вечным суперпаролем.
Идеальная цель — убрать постоянные привилегии. Администратор не должен всегда иметь доступ ко всему. Он получает нужные права на конкретную задачу и ограниченное время. После завершения работы доступ исчезает, секрет меняется, действия остаются в журнале.
Такой подход часто называют моделью без постоянных привилегий. Смысл в том, что даже если учетную запись скомпрометировали, атакующий не должен получить вечный пропуск во все системы.
Защитные меры для бизнеса
Компаниям стоит регулярно проводить инвентаризацию. Это нужно, чтобы понять, сколько в компании привилегированных учетных записей, кому они принадлежат, где используются, когда менялись пароли, какие записи не истекают автоматически и какие доступы остались после увольнений.
Следующий шаг — поиск совпадающих паролей и общих админских аккаунтов. Общий пароль для нескольких систем — удобство и для ИТ-команды, и для атакующего.
Сервисные записи часто опаснее пользовательских аккаунтов, потому что работают без человека, редко пересматриваются и могут иметь широкие права. Пароль от такой записи иногда лежит в конфиге приложения годами.
Возможное решение — переход к временным доступам. Администратор получает права не навсегда, а под задачу. Доступ выдается через заявку, фиксируется в журнале и автоматически закрывается.
Администраторы, DevOps-инженеры и разработчики с доступом к продакшену должны относиться к своим учетным данным как к ключам от всего бизнеса. Пароль от админки нельзя хранить в личных заметках, пересылать в мессенджере, использовать в тестовой системе, дублировать в нескольких сервисах и оставлять в скриптах.
Отдельная боль — локальные администраторы на рабочих станциях. Такой доступ часто выдают для удобства, а потом забывают убрать. В результате зараженный ноутбук может стать стартовой площадкой для атаки на домен.
Безопасная практика: отдельные аккаунты для обычной работы и администрирования, многофакторная аутентификация, временные права, запрет общих учеток, ротация секретов, контроль сессий, журналирование и регулярный пересмотр доступов.
