В патчах Ubuntu против Windows нет ничего особенного, RHEL, CentOS, SuSE, debian и т. Д.
Основное состояние ума, в котором вы должны быть при разработке процедуры исправления, - предполагать, что что- то сломается.
Вот некоторые из основных рекомендаций, которые я склонен использовать при разработке установки патча:
- Всегда используйте локальную систему для внутренней централизации в вашей сети, где установлены исправления
Это может включать использование WSUS или зеркал <your_os_here>к внутренней машине управления исправлениями. Предпочтительный, который может централизованно запрашивать и сообщать вам о состоянии исправлений, установленных на ваших отдельных машинах.
- Предварительная установка - когда это возможно - на машинах.
Когда это возможно, по мере выхода исправлений центральный сервер копирует их на отдельные машины. Это действительно просто экономит время, так что вам не нужно ждать, пока они загрузятся и установятся, вы просто должны начать установку во время вашего окна патча.
- Получите окно отключения, чтобы установить исправления, возможно, вам придется перезагрузиться, и что-то, вероятно, сломается. Убедитесь, что заинтересованные лица для этих систем знают, что внедряются исправления. Будьте готовы к тому, что «это» не работает звонками.
В соответствии с моей основной теорией, что исправления ломают вещи, убедитесь, что у вас есть окно отключения, чтобы применять исправления достаточно долго для устранения критических проблем и, возможно, откатить исправление обратно. Вам не нужно, чтобы люди сидели там и тестировали патчи. Лично я сильно полагаюсь на свои системы мониторинга, чтобы сообщить мне, что все работает на самом минимальном уровне, с которым мы можем сойти с рук. Но также будьте готовы к тому, что по мере того, как люди добираются до работы, им нужно вызывать небольшие проблемы У вас всегда должен быть кто-то, кто будет готов ответить на телефонный звонок - предпочтительно не тот, кто до 3 часов чинил ящики.
- максимально автоматизировать
Как и все остальное в IT, сценарий, сценарий, а затем сценарий еще немного. Скрипт загрузки пакета, запуска установки, зеркала. По сути, вы хотите превратить патч-окна в задание по присмотру за детьми, которому просто нужен человек в случае поломки.
- Иметь несколько окон каждый месяц
Это дает вам возможность не исправлять некоторые серверы, если по какой-либо причине они не могут быть исправлены в «назначенную ночь». Если вы не можете сделать их в ночь 1, потребуйте, чтобы они были свободными в ночь 2. Также позволяет сохранить количество исправленных серверов в одно и то же время.
Самое главное не отставать от патчей! Если вы этого не сделаете, вы обнаружите, что должны сделать очень большие 10-часовые патч-окна, просто чтобы вернуться к точке, где вы попали в ловушку. Вводит еще больше моментов, когда что-то может пойти не так, и делает поиск патча более сложным.
Другая часть этой проблемы заключается в том, что идти в ногу с исправлениями - это «хорошо», но исправления выпускаются почти ежедневно. Сколько запланированных отключений нужно сделать, если каждый день будет доступно новое исправление безопасности?
Патчирование сервера один раз в месяц или раз в два месяца - ИМХО - очень достижимая и приемлемая цель. Более того, и вы будете постоянно вносить исправления в серверы, гораздо реже, и вы начинаете сталкиваться с ситуациями, когда вам нужно применять сотни исправлений для каждого сервера.
Сколько окон вам нужно в месяц? Это зависит от вашей среды. Сколько у вас серверов? Какое время требуется вашим серверам?
Меньшие среды, которые имеют размер 9x5, вероятно, могут обходиться без одного окна исправления в месяц. Большим магазинам 24х7 может понадобиться два. Для очень больших 24x7x365 еженедельное окно может потребоваться, чтобы каждую неделю обновлялся различный набор серверов.
Найдите частоту, которая работает для вас и вашего окружения.
Нужно иметь в виду, что достижение 100% -го уровня является невозможной целью - не позволяйте вашему отделу безопасности говорить вам иначе. Делай все возможное, не отставать слишком далеко.