Для одиночек или малых операторов, управляющих несколькими серверами, сайтами и доменами. Чем дольше вы откладывали ревизию, потому что «оно работает», тем больше это к вам относится. Здесь нет шагов атаки — только риски, которые можно перечислить и удалить самому.
Пересчитайте и сократите то, что есть, прежде чем добавлять меры
Неотслеживаемое состояние само по себе риск. Проведите ревизию — и обычно обнаружите:
1. Защищайте ПК, на которых хранятся ключи и учётные данные
Как бы сильно вы ни укрепляли сервер, если ПК, хранящий ваш закрытый SSH-ключ, скомпрометирован, под угрозой каждый сервер, к которому даёт доступ этот ключ. Как только вы переходите на аутентификацию по ключу, настоящая граница вашего парка смещается на «ПК, хранящий ключ». Поэтому приоритет — не «сервер → ПК», а «ПК → сервер».
Самая ценная проверка: лежит ли .ssh ВНЕ папки облачной синхронизации (OneDrive/Drive/Dropbox). Если закрытый ключ случайно живёт под синхронизацией, ваш ключ утекает в тот миг, когда облачный аккаунт захватят — даже без касания ПК. Подход наименьших привилегий для ключей — в SSH-ключи и наименьшие привилегии.
2. Включайте 2FA по приоритету: почта, затем домен, затем биллинг
«Добавить 2FA на всё» никогда не закончится, если начать расплывчато. Упорядочьте аккаунты по тому, какие из них могут восстановить остальные (корень доверия), — и приоритет станет ясен.
| Уровень | Цель | Почему высший приоритет |
|---|---|---|
| Уровень 0 | Аккаунт почты | Почти каждый сервис восстанавливается через «ссылку сброса на почту» — захватите почту, и нижние 2FA обойдены |
| Уровень 1 | Контроль домена (регистратор/DNS/хостинг/платформа кода) | Сам сайт можно угнать или подменить |
| Уровень 2 | Биллинговые API (платежи / ИИ-API / отправка почты) | Ведёт к прямым финансовым потерям |
На практике: держите резервные коды на бумаге (помещение их в облако вдвое снижает смысл 2FA) и убедитесь, что ваша почта для восстановления по-прежнему работает и находится под вашим контролем. Шаги — в руководстве по многофакторной аутентификации и базовом чек-листе безопасности.
3. Составьте список, какой SSH-ключ открывает какой сервер
«Это аутентификация по ключу, так что безопасно» — не управление. Что вам действительно нужно — одна таблица «какой ключ на каком ПК открывает какой сервер». Сопоставьте authorized_keys каждого сервера по отпечаткам — и невидимое проявится: дублирующиеся ключи (один ключ под двумя именами), неиспользуемые ключи (нигде не применяются) и забытые регистрации (оставшиеся от исчезнувшей цели). В authorized_keys легко добавлять и легко забыть подчищать. Таблица позволяет спросить, строка за строкой, «для чего это?».
4. Отключите устройства с истёкшей поддержкой за минимум шагов
Ключ на устройстве, чья ОС достигла конца жизни (EOL), — частое дело. Идти на размах — «ротировать каждый ключ и перенастроить каждый сервер» — настолько тяжело, что вы никогда этого не сделаете.
Проверьте на любой признак утечки
Отрез с наименьшими усилиями = удалить ключ с устройства
Внесите срок окончания поддержки в календарь
Хитрость: выбирайте отрез, который реально закончите сегодня, вместо идеальной процедуры, которую оставите незавершённой.
5. Уберите пароли открытым текстом из облака
Прежде дебатов о менеджере паролей есть больший реальный вред: список паролей открытым текстом, лежащий в облачном документе. Утечёт — и под угрозой сразу все аккаунты.
Список открытым текстом (облачный документ)
- Захват одного аккаунта раскрывает всё
- Вы вставите в поддельный сайт вручную
- Нет обнаружения утечек, нет автозаполнения
Хранилище с шифрованием на устройстве
- Содержимое зашифровано на вашем устройстве (провайдер не может его прочитать)
- Не заполнит автоматически на поддельном домене = устойчиво к фишингу
- После переноса удалите открытый текст навсегда
«Какой менеджер лучше» значит куда меньше, чем «убрали ли вы открытый текст из облака» (→ как выбрать менеджер паролей / безопасное хранение паролей).
6. Устраняйте по одному изменению, обратимо
Когда инвентаризация выявит проблемы, вам захочется исправить их все сразу. В продакшене менять несколько вещей на порыве — самый опасный ход. Трудно отменяемые операции — ротация ключей, изменения конфигурации, продакшен-развёртывания — следует делать по одной, после подготовки полной резервной копии и процедуры восстановления (т. е. сделав это обратимым). Не создавайте новую проблему самим устранением (→ резервное копирование и восстановление).
7. Спроектируйте реестр так, чтобы он не содержал секретов
Реестр ваших результатов становится готовым списком целей для атакующих, если утечёт. Поэтому проведите черту заранее.
Можно писать (не катастрофично при утечке)
- Открытые ключи, отпечатки
- Структура вашей конфигурации, включена ли 2FA
- Результаты «пройдено/не пройдено»
Никогда не писать (одной утёкшей строкой могут злоупотребить)
- Содержимое закрытого ключа
- Пароли, API-ключи
- Реальные коды сброса
Отпечатки и открытые ключи лишь идентифицируют «какой ключ» и не могут быть использованы во вред в одиночку. Выражайте своё состояние только информацией, утечка которой не катастрофична — тогда реестр останется безопасным в облаке или при совместном использовании командой.
Взгляд этого сайта: сначала инвентаризация, потом новые инструменты
На этом сайте мы никогда не держим секреты (ключи, пароли, реквизиты подключения) открытым текстом — ни в общих документах, ни в коде — мы разделяем ключи по назначению (чтобы одна утечка не распространялась ни на что другое) и устраняем обратимо, по одному. Прежде чем добавлять новый инструмент, сначала превратите «неотслеживаемое состояние» в «перечисленное состояние». Это неэффектно, но удаляет больше риска, чем что-либо ещё.
Читать дальше
- Ключи: SSH-ключи и наименьшие привилегии
- База: базовый чек-лист безопасности · руководство по многофакторной аутентификации
- Хранение: как выбрать менеджер паролей
- Где что лежит: публичные бакеты (инвентаризация — это не только ваши серверы)
- Что забыли удалить: захват поддомена и висячие записи DNS (выведенное из работы остаётся ресурсом, пока его не удалят)
- Общая картина: частые ошибки — это ошибки допущений (почему инвентаризация работает)