Этап 1. Составить полный план защиты Linux-сервера

Цель этапа

Этот документ — базовый чек-лист для дальнейшей настройки, а не универсальный набор команд: конкретные параметры зависят от дистрибутива, роли сервера, приложений и требований к доступности. Минимизация установленного ПО, своевременные обновления, принцип наименьших привилегий, межсетевой экран и безопасный удалённый доступ входят в базовые рекомендации Ubuntu; для RHEL нужно сверять настройки с руководством и профилем безопасности конкретной версии.[1] [2]

Важно: на этапе 1 только инвентаризируем сервер, определяем требования и фиксируем план. Не отключаем вход по паролю, не меняем SSH, сеть или правила файрвола до проверки запасного доступа, согласования окна работ и подготовки отката. Ошибка конфигурации SSH может заблокировать удалённый доступ.[3]

1. Зафиксировать контекст и границы защиты

Заполнить карточку сервера:

• [ ] Назначение и роль: веб-сервер, база данных, VPN, файловое хранилище, нода, CI/CD, резервное копирование и т. п.
• [ ] Среда: production / staging / тест; физический сервер, виртуальная машина, VPS или облачный экземпляр.
• [ ] Дистрибутив, версия, ядро, архитектура, дата окончания поддержки; установленные роли и приложения.
• [ ] Владелец сервера и сервисов, ответственные за ОС, приложение, сеть, резервные копии и реагирование.
• [ ] Адреса и зоны сети: публичный IP, приватные интерфейсы, IPv4/IPv6, VPN, облачная сеть, балансировщики.
• [ ] Какие данные обрабатываются: публичные, внутренние, персональные, платёжные, ключи/секреты; требования законодательства и договоров.
• [ ] Требования к доступности: допустимое окно обслуживания, RPO (сколько данных допустимо потерять), RTO (за сколько нужно восстановить сервис).
• [ ] Доверенные источники администрирования: VPN, офисные/домашние статические IP, bastion/jump host, облачная консоль.
• [ ] Зависимости: DNS, NTP, почта/уведомления, мониторинг, хранилища, внешние API, контейнерный реестр, система управления учётными записями.
• [ ] Модель угроз: что защищаем, от кого/чего, какие последствия компрометации и какие части намеренно доступны из интернета.

Результат: одна карточка сервера с владельцами и границами ответственности. Не записывать в неё пароли, приватные ключи, токены или содержимое секретов.

2. Учётные записи и административный доступ — приоритет P0

• [ ] Составить список людей, системных пользователей, сервисных аккаунтов, групп sudo/администраторов и SSH-ключей; определить владельца и назначение каждой записи.
• [ ] Для каждого человека — отдельная именная учётная запись; запретить общие административные логины. Сервисам — отдельные непривилегированные аккаунты без интерактивного входа, если он не нужен.