Ночная смена — сервер и системный администратор

DNS — служба, отказ которой выглядит как «отказало всё сразу». Что важно в устройстве. Минимум два сервера, и они не должны стоять на одном гипервизоре и в одной стойке. Клиенты получают оба адреса через DHCP. Зоны. Внутренняя зона не должна совпадать с реальным доменом компании, иначе внешние сервисы начнут резолвиться внутрь и наоборот. Если исторически совпадает — держите в голове, что каждую внешнюю запись придётся дублировать. Пересылка. Внутренние серверы пересылают неизвестные запросы наружу. Проверьте, что резервный путь работает: отключите основной и посмотрите. Кэш и TTL. Перед плановой сменой адреса уменьшайте время жизни записи заранее — за сутки, иначе клиенты будут ходить по старому адресу часами. И мониторинг: проверка должна не пинговать сервер, а спрашивать у него кон…

Одна из тех вещей, которые не замечают, пока не сломается. Как строить. Один-два внутренних сервера синхронизируются с внешними источниками, все остальные машины — с внутренними. Не отправляйте сотню серверов в интернет по отдельности. Что использовать. Chrony предпочтительнее старых демонов: аккуратнее подтягивает время, лучше переживает плохую сеть. Виртуальные машины. Синхронизация с хостом плюс собственный демон. После снапшотов и миграций время любит прыгать. Оборудование. Коммутаторы, камеры, контроллеры доступа — им тоже нужен NTP, иначе журналы событий будут бесполезны при разборе. Что проверять. Расхождение по всем узлам: разница больше пары секунд — уже повод разобраться, больше пяти минут — сломается аутентификация в домене. И часовой пояс: единый на всех серверах. Разнобо…

Когда доступ к серверам раздан напрямую всем, отозвать его при увольнении почти невозможно. Как устроено. Один защищённый сервер, через который идут все административные подключения. Дальше — только с него. Что это даёт. Одна точка контроля доступа: отозвали учётную запись — и человек никуда не попадёт. Централизованный журнал подключений, при желании с записью сессий. Меньше открытых портов наружу: только один хост. Что важно настроить. Двухфакторную аутентификацию на вход. Вход по ключам, пароли отключить. Ограничение по адресам. Отдельные учётные записи, никаких общих. Мониторинг и оповещение о входах в нерабочее время. Что не забыть. Резервный путь на случай отказа самого джамп-хоста: второй экземпляр или задокументированная процедура аварийного доступа. И регулярный пересмотр: кт…

У пользователей второй фактор внедряют, а у админов часто нет — хотя ставки выше. Где нужен в первую очередь. Вход на джамп-хост. Панели управления облаком и провайдером. VPN. Доступ к репозиториям и системам развёртывания. Почта администраторов. Что выбрать. Аппаратные ключи — самый надёжный вариант, устойчивый к фишингу. Приложения-генераторы кодов — разумный минимум. СМС — хуже всего, номер перевыпускают. Что предусмотреть. Резервные коды в общем защищённом хранилище: иначе потеря телефона парализует работу. Второй администратор с полным доступом. Процедура аварийного доступа, описанная и проверенная. Чего избегать. Второго фактора, привязанного к личному телефону единственного сотрудника, без резервов. Это классическая ситуация, когда компания теряет доступ к собственному облаку. …

Не про недоверие, а про возможность понять, что произошло. Что стоит фиксировать. Входы: кто, откуда, когда. Выполненные команды на критичных серверах. Изменения конфигурации. Действия в панелях управления. Как. Централизованный сбор логов с джамп-хоста и серверов. Запись сессий там, где это оправдано. У облачных провайдеров есть свой журнал действий — включите и выгружайте. Что это даёт. При инциденте видно, какое изменение его вызвало, и не надо гадать. При расследовании доступа — доказательная база. При обучении новых сотрудников — реальная история типовых операций. Что важно. Логи должны храниться там, куда сам администратор не может дотянуться для правки. Иначе смысл теряется. И правило: аудит объявляется открыто. Скрытая слежка разрушает доверие и ничего не даёт, а открытый журн…

Пароли и ключи меняют редко, потому что страшно. Схема, при которой не страшно. Инвентаризация. Список всех секретов: где хранится, кто использует, где ещё продублирован. Двойные секреты. Система должна поддерживать одновременно старый и новый ключ хотя бы недолго — тогда смена проходит без простоя. Порядок. Создать новый, добавить его во все места, переключить потребителей, убедиться, что старый больше не используется по логам, удалить старый. График. Сервисные пароли — раз в год. Ключи API — по регламенту сервиса. После увольнений — немедленно и без обсуждений. Автоматизация. Хранилище секретов с динамической выдачей снимает большую часть боли: пароль живёт часы и меняется сам. И самое важное: заранее знать, что сломается. Сервис, о котором забыли, всплывает через неделю после смен…

Передача дел — момент, когда становится видно качество всей предыдущей работы. Что должно уйти вместе с доступом. Карта: какие машины, какие роли, какие адреса, что от чего зависит. Схема на одном листе полезнее двадцати страниц текста. Доступы: где хранятся, как получить, кто владелец у провайдера, регистратора, в облаке. Отдельно — что нужно поменять после передачи. Расписания: что запускается по cron и таймерам, что делает, куда пишет. Копии: где лежат, как восстановить, когда проверялись в последний раз. Известные особенности: почему здесь выключено автообновление, почему этот сервис нельзя перезапускать днём, какой скрипт держит костыль и зачем. Контакты: провайдеры, подрядчики, номера договоров, сроки продления. И живая передача: пусть новый человек при вас развернёт копию, пе…

Базовая настройка, которая экономит недели потом. Список короткий, но его редко выполняют целиком. Учётные записи и доступ: вход по ключам, root без прямого входа, fail2ban. Время: chrony и правильный часовой пояс на всех машинах одинаковый. Логи: постоянный журнал на диске, ротация, отправка на центральный сервер, если он есть. Мониторинг: место, inode, память, нагрузка, доступность сервиса, срок сертификатов. И проверка, что уведомления доходят до живого человека. Резервные копии: настроены, автоматизированы, проверены восстановлением хотя бы раз. Обновления безопасности: автоматические. Фаервол: по умолчанию всё закрыто, открыто только нужное. Документация: адреса, роли, кто владелец, как восстанавливать. И то, что забывают чаще всего: swap или его осознанное отсутствие, лимиты…

Пока всё работает, кажется излишеством. Ситуации, в которых это спасает, выглядят так. Внешний источник исчез. Пакет удалили из репозитория, образ переименовали, версия отозвана. Ваша сборка, которая год работала, перестаёт собираться в самый неподходящий момент. Пропал интернет или его ограничили. Развернуть новый сервер становится невозможно. Скорость. Установка из локального зеркала идёт в разы быстрее и не зависит от чужого канала. Контроль. Вы точно знаете, какие версии используются, и можете проверить их до того, как они попадут в прод. Минимальный вариант, который окупается сразу: локальное кэширующее зеркало пакетов и реестр образов. Ставится за день, работает годами. Отдельно про фиксацию версий: latest в образе означает, что завтра у вас может собраться что-то другое. В про…