Настройка SSM для безопасного управления серверами без SSH

Безопасное управление серверами через AWS Systems Manager

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

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

AWS Systems Manager убирает саму причину: подключение идёт не к открытому порту, а через управляемую сессию, где права выдаются ролями, отзыв — снятием роли, а каждая команда пишется в журнал с привязкой к конкретному человеку. Управление серверами без SSH перестаёт быть исключением и становится штатным режимом работы.

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

Что меняется после отказа от прямых SSH-подключений

Отказ от прямых SSH-подключений — смена модели доступа, а не привычки: соединение инициирует агент на хосте, а права проверяются на стороне AWS Systems Manager. Вот что именно меняется и по каким признакам это видно уже в первую неделю.

• Закрытые входящие порты. Правило для порта администрирования уходит из периметра: внешнее сканирование больше не находит открытого сервиса, а подбор ключей исчезает из отчётов о попытках входа.
• Единая точка входа. Вместо россыпи адресов и ключей — один интерфейс с ролями: подключение к любому хосту идёт по одной схеме, и новую машину не нужно отдельно «открывать наружу».
• Полный журнал команд. Каждая сессия записывается целиком — кто, когда и что выполнял. Разбор инцидента занимает минуты вместо восстановления событий по памяти.
• Ротация доступов без остановки работ. Сессии живут ограниченное время и продлеваются прозрачно для инженера, поэтому утерянное устройство перестаёт быть проблемой: постоянных ключей на нём нет.
• Никаких долгоживущих секретов на хостах. Ключи и пароли не расползаются по каталогам и средам — доступ выдаётся ролью и отзывается централизованно.
• Сокращение класса инцидентов. Уходят целые категории: подбор пароля, забытый открытый порт после отладки, «теневые» ключи у подрядчиков.

Проверяемая метрика перехода — доля хостов без публично доступного порта администрирования и полнота записи сессий.

Варианты доступа к серверам: сравнение режимов

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

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

Внедрение Systems Manager: от аудита до передачи

Работу ведём так, чтобы ни один сервер не выпал из управления и доступ не стал шире нужного. Сначала фиксируем текущее состояние, потом меняем схему доступа и лишь после проверок отключаем прямой вход по SSH. Ниже — порядок внедрения AWS Systems Manager.

1. Инвентаризация серверов. Собираем перечень узлов с окружениями, тегами и владельцами. Отдельно помечаем то, что живёт вне общего контура: там обычно и остаётся вход по ключам.
2. Роли и политики доступа. Описываем, кому что разрешено: роль сервера, права инженера, журналы, команды. Права привязываем к группам, а не к людям, — при переводе доступ пересобирается сам.
3. Развёртывание служебного компонента. Ставим агент шаблонами и автоматизацией — новые узлы регистрируются сами. Сетевой доступ к служебным адресам идёт по приватным маршрутам.
4. Проверка доступа. Идём по списку проверок: открывается ли сессия, работают ли команды, видны ли журналы и метрики, не осталось ли обходных путей мимо новой схемы.
5. Проверка отказоустойчивости. Смотрим, что будет при недоступности службы и отзыве прав: сессия закрывается, инженер получает понятную ошибку. Отдельно проверяем восстановление доступа к узлу.
6. Передача в эксплуатацию. Отдаём регламенты: как выдать доступ новому инженеру, как подключить сервер, как действовать при сбое, — плюс схемы ролей и контрольные проверки.

Каждый этап заканчивается работающей схемой, поэтому переключение идёт без окна простоя — не бывает парка, где половина узлов уже под контролем, а половина на старых ключах.

Комплект документов и настроек, который вы получаете

Документация по доступу — не приложение к сданной инфраструктуре, а рабочий инструмент: по ней разбирают инцидент в три утра, не поднимая автора последних изменений. Ниже комплект, который остаётся у вас после перевода парка серверов на управление через AWS Systems Manager.

• Схема доступа — кто, из каких сетей и через какие точки входа попадает на серверы, какие маршруты закрыты полностью, где остались единственные разрешённые пути.
• Матрица ролей — соответствие «команда или роль → группа серверов → допустимые действия». Новый инженер получает нужный объём прав в тот же день, а не после переписки в чате.
• Конфигурации и политики — файлы, из которых доступ поднимается на новых инстансах автоматически, без ручного доведения и «забытых» серверов вне контура.
• Регламент реагирования — порядок действий при потере связи с узлом, отзыве доступа у уволившегося сотрудника, подозрении на компрометацию учётных данных и отказе самого канала управления.
• Инструкция для дежурной смены — пошаговый сценарий на одну страницу: как открыть доступ, как завершить чужую зависшую сессию, к кому идти при отказе, что фиксировать в журнале.
• Документация по инфраструктуре — реестр серверов с тегами, окружениями и владельцами: по нему видно, что попадает под политику, а что осталось в стороне.
• Журнал аудита — куда пишутся команды и выгрузки, сколько хранятся, как выгрузить историю по конкретному узлу за нужный период.

Комплект ведём в вашем репозитории рядом с кодом и обновляем вместе с изменениями в инфраструктуре — так, чтобы через полгода документ описывал реальное состояние, а не состояние на день сдачи.

Кейс: отказ от прямых подключений на парке серверов

Парк заказчика — около 180 серверов: часть в облаке, часть на собственной площадке. У каждого из 24 инженеров лежал свой SSH-ключ с бессрочным доступом, копии этих ключей жили на ноутбуках, в образах сборки и в рабочих переписках. Новому человеку доступ выдавали день-два: пока заведут учётную запись, разложат ключ по всем хостам и не забудут ни одного.

Управление перевели на AWS Systems Manager. На каждый инстанс встал агент, права выдали роли инстанса, а подключение идёт не напрямую, а сессией по политике доступа — с записью всех команд в журнал. Прямые подключения закрыли на уровне сетевых групп, а ключи удалили с хостов и из конфигурации развёртывания.

Метрики до и после

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

Что делать, если SSH-ключи уже разошлись по команде

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

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

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

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

Технические сомнения перед отказом от прямого доступа

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

Как обновляется служебный компонент на парке машин?

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

Как разграничить команды и подрядчиков?

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

Остаётся ли аварийный доступ?

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

Обсудим задачу и вернёмся с оценкой и планом

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

• Разбор задачи. Уточняем, что именно закрываем: ручную выдачу ключей, общий доступ под одним пользователем, отсутствие журнала действий на серверах или требования проверок со стороны службы безопасности.
• Исходные данные по инфраструктуре. Перечень серверов и учётных записей, в которых они живут, текущие способы доступа, кто выдаёт и отзывает права, ограничения по сети, есть ли уже агент AWS Systems Manager на машинах.
• Схема решения и состав работ. Показываем, как доступ пойдёт через управляемые сессии, какие роли и политики нужны, где оседают журналы; отдельно фиксируем, что закрываем мы, что остаётся на вашей стороне и в каком виде сдаём результат.
• План внедрения. Разбиваем на этапы с точками проверки: пилот на группе серверов, перенос остальных, отключение прежних способов доступа — с возможностью отката на любом шаге.
• Порядок передачи. Отдаём конфигурации, роли, шаблоны политик и документацию, показываем дежурной смене, как выдать и отозвать доступ, как посмотреть историю сессий.
• Поддержка после внедрения. Остаёмся на связи по инцидентам и изменениям: новые серверы подключаются по готовому шаблону, правила доступа правятся без пересборки схемы.

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