Руководства по безопасности
Инвентаризация безопасности — 7 проверок, которые упускают владельцы нескольких серверов
Инвентаризация безопасности из 7 пунктов для одиночек и малых операторов: инциденты чаще из неотслеживаемого состояния, чем из отсутствующих мер. Проверьте ПК с ключами, ранжируйте 2FA, составьте матрицу SSH-ключей и уберите пароли открытым текстом.
Для одиночек или малых операторов, управляющих несколькими серверами, сайтами и доменами. Чем дольше вы откладывали ревизию, потому что «оно работает», тем больше это к вам относится. Здесь нет шагов атаки — только риски, которые можно перечислить и удалить самому.
«Пересчитать и отрезать» прежде «добавить»
Неотслеживаемое состояние само по себе риск. Проведите ревизию — и обычно обнаружите:
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-устройства: отрез с наименьшими усилиями, взвешенный по усилиям vs риску
Ключ на устройстве, чья ОС достигла конца жизни (EOL), — частое дело. Идти на размах — «ротировать каждый ключ и перенастроить каждый сервер» — настолько тяжело, что вы никогда этого не сделаете.
Проверьте на любой признак утечки
Отрез с наименьшими усилиями = удалить ключ с устройства
Поставьте обрыв в календарь
Хитрость: выбирайте отрез, который реально закончите сегодня, вместо идеальной процедуры, которую оставите незавершённой.
5. Уберите пароли открытым текстом из облака
Прежде дебатов о менеджере паролей есть больший реальный вред: список паролей открытым текстом, лежащий в облачном документе. Утечёт — и мгновенная полная потеря.
Список открытым текстом (облачный документ)
- Падение одного аккаунта утекает всё
- Вы вставите в поддельный сайт вручную
- Нет обнаружения утечек, нет автозаполнения
Хранилище с шифрованием на устройстве
- Содержимое зашифровано на вашем устройстве (провайдер не может его прочитать)
- Не заполнит автоматически на поддельном домене = устойчиво к фишингу
- После переноса удалите открытый текст навсегда
«Какой менеджер лучше» значит куда меньше, чем «убрали ли вы открытый текст из облака» (→ как выбрать менеджер паролей / безопасное хранение паролей).
6. Устраняйте «обратимо, по одному»
Когда инвентаризация выявит проблемы, вам захочется исправить их все сразу. В продакшене менять несколько вещей на порыве — самый опасный ход. Трудно отменяемые операции — ротация ключей, изменения конфигурации, продакшен-развёртывания — следует делать по одной, после подготовки полной резервной копии и процедуры восстановления (т. е. сделав это обратимым). Не открывайте новую дыру самим устранением (→ резервное копирование и восстановление).
7. Спроектируйте реестр так, чтобы он не содержал секретов
Реестр ваших результатов становится картой для атаки, если утечёт. Поэтому проведите черту заранее.
Можно писать (не катастрофично при утечке)
- Открытые ключи, отпечатки
- Структура вашей конфигурации, включена ли 2FA
- Результаты «пройдено/не пройдено»
Никогда не писать (одна строка превращает в оружие)
- Содержимое закрытого ключа
- Пароли, API-ключи
- Реальные коды сброса
Отпечатки и открытые ключи лишь идентифицируют «какой ключ» и не могут быть использованы во вред в одиночку. Выражайте своё состояние только информацией, утечка которой не катастрофична — тогда реестр останется безопасным в облаке или при совместном использовании командой.
Взгляд этого сайта: инвентаризация прежде добавления
На этом сайте мы никогда не держим секреты (ключи, пароли, реквизиты подключения) открытым текстом — ни в общих документах, ни в коде — мы разделяем ключи по назначению (одна утечка не каскадирует = минимальная зона поражения) и устраняем обратимо, по одному. Прежде чем добавлять новый инструмент, сначала превратите «неотслеживаемое состояние» в «перечисленное состояние». Это неэффектно, но удаляет больше риска, чем что-либо ещё.
Читать дальше
FAQ
QЧто такое инвентаризация безопасности?
Прежде чем «добавлять» новые меры, вы перечисляете ключи, аккаунты, устройства и регистрации, которые у вас уже есть, находите ненужные или опасные и сокращаете их. Для одиночек/малых операторов инциденты происходят не столько из отсутствующего фаервола или WAF, сколько из неотслеживаемого состояния — «какой ключ на каком ПК открывает какой сервер?», «включена 2FA или нет?». Инвентаризация это удаляет.
QС чего начать?
Порядок ПК → сервер. Как только вы используете SSH по ключу, настоящая граница смещается с сервера на ПК, хранящий ключ. Сначала проверьте здоровье ПК с ключами (особенно, лежит ли .ssh ВНЕ папки облачной синхронизации), затем 2FA и резервные коды вашей почты, затем инвентаризацию SSH-ключей.
QБезопасно ли хранить реестр результатов?
Безопасно, если провести черту по содержимому. Открытые ключи, отпечатки, структуру вашей конфигурации, включена ли 2FA, и результаты «пройдено/не пройдено» писать можно (ничто из этого не секрет). Но никогда не пишите содержимое закрытого ключа, пароль, API-ключ или реальный код сброса — ни строчки. Выражайте своё состояние только информацией, утечка которой не катастрофична, — и реестр никогда не станет картой для атаки.