Как безопасно передавать SSH-ключи и сертификаты в команде

«Скинь SSH-ключ в Slack.» Обычная просьба в любой команде разработки. Доступ к серверу нужен срочно, новый сотрудник настраивает окружение, деплой через час, а ключа нет.

Но эта простая просьба может обернуться серьёзным инцидентом безопасности.

Почему SSH-ключи особенно опасны при утечке

SSH-ключ — это не обычный пароль. Он даёт полный доступ к серверу.

Параметр	Пароль	SSH-ключ
Область доступа	Конкретный аккаунт	Весь сервер
Последствия утечки	Один аккаунт	Все данные на сервере
Сложность замены	Мгновенная смена	Перегенерация + обновление всех серверов
Двухфакторная аутентификация	Поддерживается	Ключ и есть аутентификация

Утечка SSH-ключа означает доступ ко всем файлам, базам данных и коду на сервере.

Когда команде приходится передавать ключи

• Общий доступ к серверам: staging- и production-серверы, к которым нужен доступ всей команде
• Деплой-ключи: ключи для CI/CD-пайплайнов
• SSL-сертификаты: передача при смене ответственного
• API-секреты: интеграция со сторонними сервисами
• Учётные данные БД: экстренное реагирование на сбои

Опасные способы передачи

1. Slack/Telegram личные сообщения

История чатов хранится на серверах бессрочно. Любой может найти ключ, просто набрав «ssh» или «key» в поиске.

2. Электронная почта

Навсегда сохраняется на почтовых серверах. Одна пересылка — и контроль потерян.

3. Общий Google Drive/Notion

Гранулярное управление доступом затруднено. Локальные копии остаются после синхронизации.

4. Коммит в Git-репозиторий

Самый опасный способ. Ключ навсегда остаётся в истории Git, даже после удаления файла.

Безопасные способы передачи

Способ 1: Секретная заметка LOCK.PUB (лучший вариант для одноразовой передачи)

1. Создать секретную заметку на LOCK.PUB
2. Вставить SSH-ключ или сертификат
3. Установить надёжный пароль
4. Задать минимальный срок действия (1-4 часа)
5. Ссылку отправить в Slack, пароль сообщить по телефону
6. После сохранения ключа получателем ссылка истекает

Преимущества:

• Ключ не хранится в открытом виде ни на одном сервере
• После истечения срока доступ невозможен
• В истории чата не остаётся текста ключа

Способ 2: Менеджер секретов (для больших команд)

HashiCorp Vault, AWS Secrets Manager, Google Secret Manager.

Способ 3: SSH Certificate Authority (долгосрочное решение)

Развернуть SSH CA, которая выдаёт индивидуальные сертификаты каждому пользователю.

Способ 4: Индивидуальные ключи (самый рекомендуемый)

Принцип: Общий ключ < Индивидуальные ключи
Утечка общего ключа → Затронута вся команда
Утечка личного ключа → Затронут только один пользователь

Чек-лист при необходимости передачи

Перед передачей

• Область прав ключа минимальна?
• Достаточно ли ключа только для чтения?
• Можно ли установить ограничение по IP?

Во время передачи

• Ключ и пароль отправляются по разным каналам?
• Срок действия максимально короткий?

После передачи

• Подтверждение безопасного сохранения ключа получателем
• Проверка истечения ссылки/заметки
• Мониторинг журналов использования ключа

График ротации ключей

Тип ключа	Рекомендуемая ротация
Ключи production-серверов	90 дней
Деплой-ключи	90 дней
SSL-сертификаты	При каждом продлении
API-секреты	90 дней
Ключи dev/staging	180 дней

Чек-лист безопасности для DevOps-команды

• Все серверы используют индивидуальные SSH-ключи?
• У общих ключей настроены ограничения по IP?
• Ключи уволившихся сотрудников деактивируются сразу?
• Есть график ротации ключей?
• SSH-ключи никогда не коммитились в Git?
• В истории чатов нет ключей в открытом виде?
• Для передачи секретов используется канал с истечением срока?

Итоги

SSH-ключи и сертификаты — основа серверной безопасности. Отправлять их в личных сообщениях или по почте — всё равно что повесить ключ от дома на доску объявлений. Выдавайте индивидуальные ключи везде, где возможно. Когда передача неизбежна, используйте секретную заметку с минимальным сроком действия.

Создайте секретную заметку прямо сейчас для безопасной передачи SSH-ключей.

Создать секретную заметку