Управление обновлениями (patch management)
Непрерывный процесс отслеживания, тестирования и установки обновлений, закрывающих известные уязвимости, а не обновление только тогда, когда что то сломалось.
Почему 'обновлять, когда что-то сломается' — это не стратегия
Ожидание видимого сбоя как триггера для обновлений означает, что каждая известная, уже исправленная уязвимость остаётся неустранённой всё это время, а это именно то окно, на использование которого рассчитаны n-day эксплойты.
Как выглядит работающий процесс на практике
Базовый процесс отслеживает, для каких пакетов есть доступные обновления, отличает рутинные обновления от критических исправлений безопасности, требующих более быстрой реакции, и по возможности тестирует изменения перед выходом в продакшн, а не применяет всё подряд сразу после выхода.
Часто задаваемые вопросы
Как часто нужно применять патчи?
Критические патчи безопасности нужно применять максимально быстро; рутинные обновления без отношения к безопасности могут идти по более медленному, запланированному графику, например еженедельному или ежемесячному окну обновлений.
Достаточно ли автоматического обновления само по себе?
Для большинства рутинных обновлений да, через что-то вроде unattended-upgrades. Критические исправления иногда всё же требуют более быстрого, вручную подтверждённого развёртывания, а не ожидания следующего автоматического цикла.
Какой риск слишком агрессивного обновления без тестирования?
Обновление иногда может сломать зависимость или конфигурацию; тестирование критических сервисов после крупных обновлений, особенно ядра или базы данных, снижает риск того, что само обновление вызовет простой.
Хотите увидеть, в каком состоянии ваш сервер?
Запустите бесплатную read-only проверку сервера или откройте Security Lab и посмотрите цикл обнаружение, сдерживание, восстановление, проверка в действии.
Получить бесплатную проверку сервераОткрыть Security Lab