Руководства по безопасности
Не давайте root-ключи средам, которые можно скомпрометировать: наименьшие привилегии SSH-ключа
Регистрируете SSH-ключ в продакшене из эфемерной, компрометируемой среды (под GPU-облака, раннер CI)? Если он утечёт, кто-то получит root в продакшене. Как сделать ключи наименее привилегированными с пользователем не root и ключом с ограничением команды, ограниченным одной операцией.
Для всех, кто дотягивается до продакшена по SSH из эфемерной среды — пода GPU-облака, раннера CI, одноразовой ВМ. Без шагов атаки — только превращение ключей в наименее привилегированные для сужения зоны поражения. Об основах разделения ключей см. базовый чек-лист.
Взгляд этого сайта: относитесь к эфемерным средам как к недоверенным
Одноразовые вычисления часто пропускают укрепление — это место, которое можно скомпрометировать. Положить туда root-ключ продакшена — всё равно что оставить запасной ключ от входной двери на улице. Этот сайт использует отдельный ключ на хост, ограничивает каждый назначением и вытягивает ключи в тот миг, когда они не используются (→ отдельные ключи для минимизации зоны поражения). Относиться к ключу не как к «удобному пропуску», а как к «самому критичному активу, который открывает всё, если утечёт», — в конечном счёте самая безопасная позиция.
✗ root-ключ в эфемерной среде
среда скомпрометирована → root в продакшене с этим ключом → достаёт файлы, секреты и другие службы — всё.
○ ключ не root с ограничением команды
даже если тот же ключ утечёт, он может выполнить только одну указанную команду. Нет оболочки, нет проброса — ущерб локализован до одной операции.
Почему root-ключ в эфемерной среде опасен
Эфемерные среды склонны пропускать укрепление («мы её скоро удалим»), что делает их лёгкой опорой для атакующего. Root-ключ продакшена там максимизирует ущерб разом.
Скажем, вы поднимаете под для вычислений и, чтобы работать с продакшеном из него, регистрируете ключ в authorized_keys пользователя root. Удобно — но если этот под скомпрометирован, атакующий входит в продакшен как root с этим ключом. Будь точкой входа RCE или утечка ключа, конечная форма одна: продакшен забран украденным ключом (связано: ключ украден через RCE, и пошли мошеннические счета).
Три шага к наименее привилегированным ключам
Перейдите от «дать полную власть, потому что удобно» к «ограничить то, что он может делать, до минимума».
Вытяните root-ключ эфемерной среды
~/.ssh/authorized_keys продакшена. Если бездействует, удаление не имеет последствий. Сначала устраните «оставленное валяться».Даже если снова нужно, не возвращайтесь к root
Ограничьте ключ одной операцией
command="..." и restrict к строке ключа в authorized_keys. Даже успешный вход может выполнить только одну указанную команду, с отключёнными пробросом порта и оболочкой. Утечка локализована до этой одной операции.# Register a key restricted to ONE operation in a non-root user's authorized_keys.
# Logging in with it can run only the given command; forwarding and PTY are off.
command="/usr/local/bin/deploy-pull",restrict ssh-ed25519 AAAA...rest-of-public-key deploy@cirestrict разом отключает проброс, проброс агента, PTY, X11 и прочее; command="..." фиксирует исполняемое действие на одной вещи. Базовый ход — ключ, ограниченный одним назначением — только вытянуть развёртывание, только запустить конкретный скрипт — создаваемый под каждый случай использования.
Конфигурация, в которую попадают (опасно)
- зарегистрировать ключ на root продакшена из пода/CI
- оставить завершённые ключи на месте
- переиспользовать один ключ на многих хостах
- разбрасывать ключи, дающие полную оболочку
Наименее привилегированная конфигурация
- дотягиваться до продакшена только как пользователь не root
- ключи ограничены одной операцией (с ограничением команды)
- отдельные ключи по хостам и назначениям
- убирать ключи из authorized_keys в тот миг, когда они не используются
Относитесь к переиспользуемому ключу как к самому критичному активу
Думайте о ключе как об «удобном пропуске» — и вы переиспользуете его и забудете удалить. Переверните: относитесь к нему как к самому критичному активу, который открывает всё, если утечёт. Разделяйте по хостам и назначениям, держите ключи продакшена вне эфемерных сред и всегда убирайте их после использования. Одно это разрывает худшую цепочку — одна утечка, каскадирующая во всё.
Что делает сам этот сайт
Этот сайт использует отдельный ключ на сервер и никогда не переиспользует ключи. Развёртывания приземляются на пользователя не root, созданного под назначение, а продакшен однонаправлен — «он принимает, он не выходит вытягивать» (→ продакшен только принимает). Он не оставляет постоянных ключей из эфемерных вычислений в продакшен; он подключается только при необходимости, с наименьшими привилегиями. Причина ровно та же, что в этой статье: спроектировать охват ключа малым заранее, чтобы одна компрометация не каскадировала во всё.
Читать дальше
FAQ
QПочему опасно класть root-ключ в эфемерную среду?
Эфемерные среды вроде подов GPU-облака или раннеров CI одноразовы, поэтому укрепление часто пропускают, и их можно скомпрометировать. Положите туда root-ключ к продакшену — и в тот миг, когда эта среда скомпрометирована, атакующий получит root в продакшене вместе с ключом. Относитесь к эфемерным средам как к недоверенным и держите root-ключи продакшена вне их.
QЧто, если мне всё же нужно дотянуться до продакшена из эфемерной среды?
Не возвращайтесь к root. Создайте выделенного пользователя не root и зарегистрируйте ключ, ограничивающий то, что он может делать, одной операцией. В authorized_keys ключ с ограничением команды и флагом restrict означает, что даже успешный вход может выполнить только эту одну команду. Утечка тогда локализована до этой одной операции.
QКаков ключевой принцип управления ключами?
Относитесь к переиспользуемому ключу как к своему самому критичному активу и никогда не стройте конфигурацию, где одна утечка раскрывает всё. Разделяйте ключи по хостам и назначениям и убирайте ключи из authorized_keys, когда они больше не нужны. Это не даёт одной утечке каскадировать.