Как может системный администратор-параноик уверенно оставаться в курсе последних стабильных версий PHP? (исправления безопасности появляются довольно регулярно).
Это рабочий сервер, так что "взлом" напугал моего парня до смерти. Время простоя для обслуживания - не проблема.
В частности, мы используем последнюю версию Suse Enterprise Linux, но общий или более общий ответ вполне приемлем.
Как вы обрабатываете обновления безопасности для производственных машин? Что мы так игнорируем, что этот парень так боится использовать менеджер пакетов для «обновления»?
Любой совет?
Я обрабатываю PHP так же, как и все остальное: сначала обновляю среду разработки (производственный клон VMWare), чертовски регрессирую, затем продвигаю ее в производственную среду, используя те же шаблоны развертывания, которые мы использовали для хостов VMWare. (Если вы используете менеджеры пакетов для обновления, вы должны использовать те же пакеты).
В качестве дополнительного уровня изоляции наша производственная среда состоит из парных избыточных хостов, и один хост выводится из производственной ротации для его обновления, затем тщательно тестируется, прежде чем мы переключимся на этот хост для обновления его партнера.
Как правило, обновления безопасности применяются по мере возможности, а обновления, не связанные с безопасностью / исправлением критических ошибок, применяются ежеквартально, чтобы минимизировать время простоя.
PHP находится в моем главном списке вещей, которые нужно постоянно обновлять до текущей версии. Я доверяю этому меньше, чем многим вещам.
В конце концов, лучше всего просматривать каждый журнал изменений от текущей версии до последней и ощутимо взвесить риск.
Если вы говорите об обновлении второстепенных версий, таких как 5.3.1 до 5.3.2, я бы не стал особо беспокоиться.
Если вы обновляетесь с 5.2.x до 5.3.x, вы, вероятно, столкнетесь с некоторыми проблемами совместимости.
Если вы используете системные пакеты, обычно в дистрибутивах не будет обновлений, которые снизят производительность. RHEL и CentOS исправляют старые версии исправлений до выхода основного выпуска дистрибутива. Обычно они проводят тестирование за вас, что снижает риск. Я ожидал SuSE предприятие быть похожим.
Что касается путей обновления, лучше всего будет создать тестовый сервер и протестировать приложение с последней версией перед обновлением производственной среды.
Другой, менее ценный ответ - создать белый список разрешенных URL-адресов и функций. В Apache это можно сделать, объединив функции прокси и перезаписи.
По сути, вы выполняете две установки, одна из которых имеет урезанную конфигурацию: прокси, перезапись и отсутствие выполнения кода; и т. д. Любой "разрешенный" URL (с параметрами и т. д.) будет проксирован для второй установки.
Затем добавьте себя в список разработчиков PHP и внимательно следите за примечаниями к выпуску. Каждый раз, когда вы видите что-то, что похоже на уязвимость системы безопасности, вы создаете прокладку при первой установке для обнаружения такого рода сбоя и отправляете пользователю сообщение об ошибке.
В такой настройке вы захотите перенаправить POST на фильтр (если вам вообще нужен POST; некоторые сайты прекрасно обходятся, разрешая POST только с некоторых IP-адресов!), Который может искать разрешенные источники, и предварительно подтвердите все.
Создание такого белого списка занимает очень много времени, но для критически важных приложений, которые должны работать дольше, чем стабильный срок службы PHP (который, кажется, составляет всего несколько лет), это может быть отличным способом использовать большое количество PHP. приложений, не получив и их уязвимостей.
В дополнение к вышесказанному вы можете на всякий случай включить откат пакетов.
Тогда, если что-то сломается в производстве, которое вы абсолютно уверен, что работал нормально над разработкой, вы можете по крайней мере быстро отменить изменение, прежде чем устранять проблему.
Видеть Откатить пакет YUM для примера в Yum. Я уверен, что другие системы управления пакетами имеют аналогичные.
Я знаю, что это пояс и подтяжки, и я согласен с Warner в отношении точечных релизов. Мелкие изменения ничего не должны сломать. Лично у меня не было проблем с обновлением PHP, но всегда лучше перестраховаться.