Управление SSH-ключами в современных ИТ-инфраструктурах. Скрытая угроза и пути перехода к эфемерному доступу

Управление SSH-ключами в современных ИТ-инфраструктурах. Скрытая угроза и пути перехода к эфемерному доступу

Введение: анатомия проблемы

Откройте файл «authorized_keys» на любом production-сервере со стажем. Ручаюсь, вы найдёте там десятки, если не сотни, строк. Чей это ключ «ssh-rsaAABBCC…» без комментария? Наследство от сисадмина, уволившегося три года назад? От забытого скрипта резервного копирования? Или от подрядчика, настраивавшего базу? Никто не знает, а удалять страшно — ​как бы чего не вышло.

Или другая ситуация: из компании со скандалом уходит senior-разработчик. Служба ИБ действует по инструкции: блокирует учётную запись в Active Directory, отзывает VPN-сертификат, закрывает доступ к корпоративной почте и Jira. Вопрос закрыт? Нет. На десятке серверов в «authorized_keys» остался его личный SSH-ключ, заботливо проброшенный ansible-скриптом год назад. Для хакеров и обиженных инсайдеров такие неуправляемые ключи — ​идеальный, невидимый для Security Information and Event Management (SIEM)-систем бэкдор. Нет, даже не бэкдор, а БЭКДОРИЩЕ!

В современной инфраструктуре SSH-ключи размножаются быстрее, чем мы успеваем их контролировать, превращаясь из главного инструмента защиты в бомбу с часовым механизмом. В эпоху микросервисов и Continuous Integration/Continuous Delivery (CI/CD) количество ключей растёт экспоненциально, зачастую превышая количество паролей в десятки и сотни раз. Ручной аудит невозможен.

Последние 20 лет в индустрии ИБ царит парадокс: 99% компаний инвестируют десятки миллионов рублей в управление жизненным циклом PKI-сертификатов и строгие парольные политики. Но когда дело доходит до самого критичного уровня — ​доступа к серверам, Kubernetes-кластерам и сетевому оборудованию — ​9 из 10 команд работают в режиме «сделай сам», без централизованной оркестрации. Инфраструктура де-факто держится на статических ключах: они генерируются вручную и живут вечно.

SSH — ​фундамент привилегированного удалённого доступа: основной протокол администрирования серверов, сетевого оборудования, CI/CD-пайплайнов и операций в Kubernetes. Эффективное управление ключами требует централизованной инвентаризации, автоматической ротации, соблюдения принципа наименьших привилегий и ведения сессионных журналов. Стойкость криптоалгоритмов не имеет значения, если скомпрометированы процессы хранения и управления жизненным циклом ключей.

Эпидемия Key Sprawl: невидимая брешь

Одна из самых критичных, но игнорируемых проблем — ​SSH-Key Sprawl: бесконтрольное разрастание криптографических ключей. В Enterprise-среде счёт идёт на сотни тысяч и миллионы. Усугубляет картину отсутствие централизованного реестра: отделы ИБ и ИТ не знают, сколько ключей существует в инфраструктуре, кому они принадлежат и в каких процессах задействованы. Ручное управление, миграции сервисов и запуск тестовых сред ведут к хаотичному генерированию доступов и дублированию ключей между системами, создавая дополнительные векторы атак.

В отличие от паролей, подчинённых политикам регулярной смены, SSH-ключи существуют вне времени. Отсутствие автоматической ротации порождает «вечные» ключи, не меняющиеся годами. Нередки случаи, когда ключ, сгенерированный при первоначальном развёртывании сервера, до сих пор даёт root-доступ к критичным системам. Ситуация обостряется при увольнениях: проблема «мёртвых душ» (Orphaned Keys) в том, что блокировка учётной записи в Active Directory не затрагивает публичные ключи, оседающие в «authorized_keys» на сотнях серверов. При инциденте отсутствие автоматизированного отзыва делает невозможной оперативную блокировку скомпрометированного доступа во всём ИТ-ландшафте.

Отдельный пласт рисков — ​криптографическая гигиена и хранение секретов. Разработчики регулярно зашивают приватные ключи в код (Hardcoded Keys), забывают их в репозиториях GitLab/GitHub, конфигурациях CI/CD, Docker-образах и скриптах автоматизации. По данным GitGuardian, за 2025 год в публичных коммитах GitHub обнаружили почти 29 миллионов секретов (+34% год к году), существенная часть которых — ​SSH-ключи. Утечки не являются короткоживущей проблемой: исследование января 2026 года показало, что почти 65% секретов, найденных в 2022 году, оставались актуальными спустя три года. Ситуация усугубляется тем, что закрытые ключи часто хранятся без passphrase — ​кража такого файла открывает злоумышленнику прямой путь в инфраструктуру.

Наконец, отсутствие контроля криптостандартов означает свободное хождение ключей на устаревших алгоритмах (DSA, короткие RSA), уязвимых к современным методам взлома. В 2023–24 годах уязвимости OpenSSH (CVE‑2024-6387 — ​regreSSHion, CVE‑2023-38408) позволяли атакующему не только перехватывать управление сервером, но и «бесшумно» внедрять SSH-ключи в «authorized_keys» на уровне оперативной памяти, минуя файловую систему.

Ещё одна проблема — ​полная потеря аудируемости (Accountability) и понимания топологии доступов. Организации не знают, какие пользователи и сервисы имеют доступ к конкретным ресурсам и как эти привилегии маршрутизируются. Практика общих (shared) ключей для сервисных аккаунтов разрушает персонализацию ответственности: при инциденте невозможно установить, кто именно выполнил команду. Попытка аннулировать скомпрометированный общий ключ нарушит работу всех связанных пользователей. Отсутствие истории операций по созданию, копированию и удалению ключей лишает службу ИБ возможности выявлять аномалии и предотвращать несанкционированные действия.

От теории к практике: когда угроза становится реальной

Абстрактные риски — ​лишь вершина айсберга. На практике архитектурные просчёты превращают корпоративную сеть в проходной двор. Злоумышленники давно превратили охоту за SSH-секретами в отлаженный конвейер.

Охота на рабочих станциях и рынок даркнета. Взлом инфраструктуры часто начинается не со сложных эксплойтов, а с ноутбука рядового разработчика. Инфостилеры (RedLine, Raccoon) нацелены на массовый сбор содержимого «~/.ssh/». Украденные данные оперативно продаются брокерам первоначального доступа (Initial Access Brokers). Многие ключи хранятся без passphrase, а в отсутствие многофакторной аутентификации (Multi-Factor Authentication, MFA) компрометация одного файла даёт атакующим прямой root-доступ к ключевым узлам сети.

Компрометация через исходный код. Другой неисчерпаемый источник — ​репозитории и CI/CD-пайплайны. Разработчики по невнимательности пушат приватные ключи в открытые проекты на GitHub, где специализированные боты сканируют свежие коммиты круглосуточно: на перехват и применение ключа уходят секунды.

Эпидемия горизонтального перемещения. Закрепившись в сети, злоумышленники используют забытые ключи для скрытого Lateral Movement. Операторы программ-вымогателей (LockBit, Conti) автоматически парсят «id_rsa» и «known_hosts» на заражённых машинах, захватывая соседние серверы по цепной реакции без использования уязвимостей.

От ключей к сертификатам: современные практики SSH-доступа

Пора признать правду: традиционный подход к управлению SSH мёртв. Если корпоративная безопасность строится на вере в то, что инженеры надёжно прячут приватные ключи, а сисадмины регулярно чистят «authorized_keys» за уволенными сотрудниками — ​у вас нет безопасности. У вас есть иллюзия контроля. В эпоху облаков, микросервисов и хакерских конвейеров статический SSH-ключ — ​такой же архаизм, как пароль «12345» на стикере под клавиатурой.

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

Ниже представлены современные практики работы с SSH (Best Practices), превращающие инфраструктуру из решета в крепость:

1. Обнаружение, инвентаризация и аудит. Нельзя защитить то, чего не видишь. Первый шаг — ​масштабная генеральная уборка: автоматизированные сканеры «прочёсывают» серверы, Git-репозитории и CI/CD-пайплайны. Цель — ​составить полную карту доступов, выявить скомпрометированные секреты и удалить все неиспользуемые и осиротевшие ключи.

2. Эфемерные сертификаты (SSHCA). Архитектурный «Святой Грааль». Вместо «вечных» ключей — ​краткосрочные сертификаты. Инженер не имеет постоянного ключа: он аутентифицируется через Single Sign-On (SSO) и MFA, запрашивает доступ к нужному сегменту, и система на лету генерирует подписанный SSH-сертификат, валидный на время сессии (например, час). По истечении заданного времени сертификат становится бесполезным набором байтов. Нет статических ключей — ​нечего красть, нечего забывать при увольнении. Файлы «authorized_keys» больше не нужны.

3. Интеграция с SSO и MFA. Доступ к критической инфраструктуре жёстко связывается с корпоративными Identity Providers. Прежде чем получить доступ к консоли, пользователь обязан пройти MFA-аутентификацию. Украденный ключ без второго фактора бесполезен.

4. Системы класса PAM и Bastion Hosts. Для самых чувствительных сегментов — ​единая точка входа через Jump-сервер. Пользователь не подключается к целевому серверу напрямую, а заходит на Bastion Host, который прозрачно проксирует соединение. Обеспечиваются: полный Session Recording, сетевая изоляция целевых серверов, автоматическая ротация ключей без участия пользователя.

5. Аппаратная защита конечных точек. Если долговременные ключи необходимы (например, для автоматизации), приватные ключи генерируются и навсегда остаются внутри аппаратных токенов, доверенного платформенного модуля (Trusted Platform Module, TPM) или защищённой среды (Secure Enclave). Вредоносное ПО не сможет скопировать такой ключ — ​требуется физическое действие пользователя (например, ввод ПИН-кода) для каждой операции.

6. Zero Trust Network Access (ZTNA). Серверы с открытым 22-м портом не присутствуют в сети в ожидании подключений — ​они скрыты за программно-определяемым периметром. Доступ предоставляется на основе контекста: личность, уровень безопасности устройства (антивирус, шифрование, отсутствие джейлбрейка), геолокация. Подозрительный контекст — ​доступ блокируется до начала криптообмена.

Укрощение хаоса: практическая реализация с Clearway Integration

Понимать современные подходы — ​половина дела. Настоящий вызов — ​внедрение. Переход от стихийного управления к архитектуре Zero Trust часто тормозится отсутствием удобных инструментов. Компания Clearway Integration разрабатывает экосистему продуктов, берущую на себя всю работу по управлению PKI-инфраструктурой. Рассмотрим, как флагманские продукты портфеля — ​Единая Система Автоматизированного Управления Сертификатами (ЕСАУС) и Единое Хранилище Секретов (ЕХС) — ​минимизируют риски использования статических SSH-ключей.

ЕСАУС: прозрачность и диктатура политик безопасности

ЕСАУС — ​фундамент, с которого начинается наведение порядка, ликвидация «слепых зон» и автоматизация рутинных операций с исключением человеческого фактора.

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

Жёсткие политики безопасности. ИБ-отдел централизованно задаёт правила работы: разрешённые алгоритмы, минимальную длину ключа, сложность passphrase, срок действия (TTL). Поддерживается контроль контекста окружения (Compliance Check) — ​фильтр, разрешающий или блокирующий работу с ключевым материалом

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

Визуализация. Интерактивная карта доступов: кто, куда и с какими правами подключается. Скомпрометированный ключ отзывается в один клик. Встроенные классификаторы подсвечивают уязвимые ключи.

ЕХС: отказ от ключей в пользу эфемерного доступа

Если ЕСАУС наводит порядок в мире статических ключей SSH, то Единое Хранилище Секретов (ЕХС) в рамках функционала отдельного модуля предлагает радикальный шаг вперёд — ​полный отказ от них.

Подписанные SSH-сертификаты (Signed SSH Certificates). Золотой стандарт: полное избавление от «authorized_keys» и ручного заведения пользователей — ​достаточно один раз прописать публичный ключ удостоверяющего центра (Certificate Authority, CA) от ЕХС как доверенный. ЕХС генерирует временный сертификат с TTL от нескольких минут до нескольких месяцев. По истечении TTL доступ автоматически аннулируется. Дополнительно возможна привязка к IP-адресу пользователя. Поддерживается интеграция с внутренними и внешними CA, ролевая модель, бесшовная ротация ключей CA. Каждая операция подписи журналируется.

Важное замечание: одномоментный отказ от статических ключей невозможен — ​требуется поддержка на стороне SSH-серверов (Интернет вещей (Internet of Things, IoT) и сетевое оборудование часто её лишены). Поэтому глубокая инвентаризация и управление классическими ключами через ЕСАУС остаются критически важными.

Одноразовые SSH-пароли (One-Time SSH Passwords, OTP). Идеальный инструмент для быстрой миграции без ломки привычных процессов. На удалённый узел устанавливается легковесный модуль; при подключении ЕХС генерирует OTP с коротким сроком жизни. Пользователю не нужны SSH-ключи на компьютере — ​нет ключей, нет риска кражи инфостилерами. Ограничения по IP и подробное логирование гарантируют полный контроль.

Внедряя решения Clearway, бизнес получает выстроенный конвейер безопасности: от автоматической инвентаризации до полного перехода на эфемерные сертификаты. Инфраструктура становится прозрачной для администраторов и непредсказуемой для атакующих.

Заключение: время сжечь свои id_rsa

Хватит делать вид, что Excel-табличка и пара bash-скриптов спасут от взлома. Бережно хранимые годами статические SSH-ключи — ​больше не инструмент администрирования, а красная ковровая дорожка для хакеров в сердце инфраструктуры.

Эпоха вечных «id_rsa» мертва. Попытки «лучше управлять» ими в масштабах Enterprise обречены — ​это всё равно что вычерпывать воду из тонущей лодки чайной ложкой.

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

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

Реклама. ООО «Клируэй Текнолоджис», ИНН: 7710880240, Erid: 2VfnxwxArZ9