9 мая 2024 года сообщество PostgreSQL выпустило набор минорных версий для каждой из поддерживаемых "стабильных" основных версий. В тот же день Amazon RDS для PostgreSQL объявила о своем релизе. Это был первый случай, когда мы выпустили минорную версию в тот же день, что и сообщество, что заставило меня задуматься о важности поддержания актуальности PostgreSQL.
Я не имею в виду какую-то новую интересную криптовалюту, основанную на PostgreSQL. И хотя PostgreSQL действительно стоит своего виртуального веса в золоте, я не хочу намекать на привязку к золотому стандарту. Вместо этого я хочу обсудить важность своевременного обновления до последней минорной версии PostgreSQL.
Три лучших причины для быстрого обновления
Интуитивно понятно, что поддержание актуальности в ваших интересах. Но давайте рассмотрим конкретные причины, по которым стоит оставаться максимально обновленным.
- Исправление известных ошибок: В последнем объявлении о выпуске сообщества PostgreSQL говорится: "Этот релиз исправляет одну уязвимость безопасности и более 55 ошибок, обнаруженных за последние несколько месяцев." Даже если вы в настоящее время не сталкиваетесь с одной из этих ошибок, нет никаких гарантий, что одна или несколько из них не проявятся завтра.
- Регрессии редки: Минорные версии PostgreSQL эквивалентны тому, что некоторые системы управления базами данных называют "патчами" и никогда не содержат новых функций — по давней политике они только исправляют ошибки. Официальная политика гласит: "Минорные релизы содержат только исправления часто встречающихся ошибок, низкорисковые исправления, проблемы безопасности и проблемы с повреждением данных. Сообщество считает выполнение минорных обновлений менее рискованным, чем продолжение работы на старой минорной версии." Благодаря этой политике регрессии при обновлениях минорных версий крайне редки. Я могу вспомнить лишь несколько случаев за более чем два десятилетия тесного взаимодействия и участия в разработке PostgreSQL.
- Соответствие требованиям: Многие организации должны соответствовать директивам по соблюдению требований или, по крайней мере, иметь политики, стремящиеся соответствовать лучшим практикам. Некоторые примеры:
- CIS Benchmark: CIS Benchmark для PostgreSQL конкретно говорит: "Один из лучших способов обеспечить безопасность PostgreSQL — внедрять обновления безопасности по мере их выхода, вместе с любыми применимыми патчами ОС, которые не будут мешать работе системы."
- CISA Binding Operational Directives: Согласно "BOD 19-02: Требования к устранению уязвимостей для систем, доступных через Интернет":
- Критические уязвимости должны быть устранены в течение 15 календарных дней с момента их обнаружения.
- Высокие уязвимости должны быть устранены в течение 30 календарных дней с момента их обнаружения.
