Обновление отечественной ОС между релизами: почему это не привычный dist-upgrade

MAATRIX

Если вы привыкли к sudo do-release-upgrade в Ubuntu или apt full-upgrade в Debian с последующим ручным разгребанием пары сломанных зависимостей, первое мажорное обновление Astra Linux, РЕД ОС или другого сертифицированного отечественного дистрибутива способно застать врасплох. Дело не в том, что процесс сложнее технически — дело в том, что вокруг обновления стоит инфраструктура регуляторных требований, которой в обычном Linux-мире просто нет. Разберём, чем это принципиально отличается и как не превратить плановое обновление в разбор инцидента.

Почему интуиция из Ubuntu/Debian здесь работает против вас

В классическом Ubuntu/Debian мажорное обновление — это, по сути, смена репозитория со старого релиза на новый и прогон менеджера пакетов, который сам разрулит зависимости. do-release-upgrade спрашивает пару раз про конфиги, которые вы правили руками, и в целом рассчитан на то, что вы можете запустить его в пятницу вечером на некритичном сервере и к утру получить рабочую систему следующей версии. Автоматизация здесь — цель дистрибутива: чем меньше ручных решений принимает администратор, тем меньше шанс, что он ошибётся.

У сертифицированных enterprise-ориентированных дистрибутивов (не только российских — это общая логика для любой ОС, вокруг которой выстроена формальная сертификация по требованиям защиты информации) цель другая: не удобство обновления, а гарантированная предсказуемость состояния системы. Автоматический прогон обновления «на лету» с автоматическим разрешением конфликтов пакетов — это ровно то поведение, которое подрывает саму идею сертификации: систему проверяли и утверждали в конкретной конфигурации, а не «в любом состоянии, до которого её доведёт apt».

Отсюда и первое практическое следствие: не переносите на такую систему рефлекс «обновление — это рутинная фоновая задача». Здесь это плановое мероприятие с подготовкой, которое стоит закладывать в график заранее, а не втискивать между делом.

Сертификационный статус может быть привязан к конкретной сборке

Это ключевое отличие, из-за которого стоит останавливаться перед каждым мажорным обновлением в защищённом контуре. Если система эксплуатируется как часть аттестованной информационной системы (ИСПДн, ГИС, объект КИИ — где применимо), сертификат соответствия или аттестат обычно выдаётся не абстрактно «на дистрибутив», а на конкретную сборку с определённым набором компонентов и настроек, прошедшую испытания. Смена версии ядра, обновление подсистемы мандатного контроля доступа или замена системных библиотек — это уже другая конфигурация, и формально она может не покрываться действующим сертификатом до отдельной проверки.

Практически это означает: прежде чем катить мажорное обновление на систему в аттестованном контуре, нужно выяснить у ответственного за информационную безопасность (или у службы, которая вела аттестацию), распространяется ли действующий сертификат/аттестат на целевую версию, и не потребует ли обновление повторных мероприятий по подтверждению соответствия. Это не бюрократическая формальность ради формальности — если аттестация действительно требуется для этой системы, необоснованная потеря её статуса создаёт juridических рисков больше, чем любая техническая регрессия от неудачного апгрейда. Разница редакций — например, Special Edition с полным набором сертифицированных механизмов защиты против Common Edition без этой нагрузки — подробно разобрана в статье про выбор редакции Astra Linux для сервера: если у вас именно Special Edition или её аналог у другого вендора, вопрос сертификации не опциональный, а обязательный пункт чек-листа перед обновлением.

Если система не входит в контур с формальной аттестацией — например, это просто отечественная ОС на рабочем или тестовом сервере ради импортонезависимости стека — этот пункт снимается, и обновление становится в первую очередь техническим вопросом. Но важно проверить это допущение явно, а не предполагать по умолчанию: «у нас же просто сервер» иногда оказывается неверным, если сервер де-факто обрабатывает персональные данные или включён в состав аттестованного сегмента сети.

Процесс обновления обычно консервативнее и требует больше ручных шагов

Второе системное отличие — сам механизм перехода между релизами реже сделан как «одна команда и автоматическое разрешение конфликтов», и чаще предполагает осознанные шаги администратора на каждом этапе:

• явное подтверждение перед подключением нового репозитория или установочного образа целевой версии, а не автоматическое переключение;
• построчная сверка того, какие пакеты и подсистемы (в первую очередь механизмы защиты — мандатный контроль доступа, замкнутая программная среда, аудит) требуют отдельной проверки после обновления, а не просто «должны продолжить работать»;
• в ряде случаев — переход не через обновление пакетов поверх текущей установки, а через контролируемую переустановку или миграцию на новый образ с переносом данных и конфигурации, что вендор может считать более надёжным способом гарантировать целевое состояние системы;
• обязательная сверка контрольных сумм установочных и обновляющих образов с тем, что публикует сам вендор — тут выше цена подмены пакета, чем в обычном публичном репозитории Ubuntu/Debian с миллионами пользователей, где аномалия была бы замечена быстро.

Это не значит, что процесс обязательно медленнее в человеко-часах — иногда контролируемая переустановка с восстановлением из бэкапа занимает меньше времени, чем разбор конфликтов автоматического апгрейда. Но он требует другого планирования: закладывайте окно обслуживания не «на всякий случай», а исходя из того, что часть шагов не автоматизирована и требует присутствия администратора на каждом этапе, а не только в начале и в конце.

Что именно ломается при смене базового поведения системы — вопрос не абстрактный: после обновления первым делом стоит перепроверить именно те механизмы, которые отличают такую систему от обычного Linux, а не только «запустился ли nginx». Частый источник грабель на практике — мандатное разграничение доступа: метки конфиденциальности, привязанные к файлам и процессам, ведут себя не так, как обычные права chmod, и после обновления системы стоит явно проверить, что политика меток и правила доступа между зонами не изменились неявно вместе с версией.

Тестовый стенд перед продакшеном — не рекомендация, а обязательное условие

Правило «сначала на некритичном стенде, потом на проде» справедливо для любого софта — этому посвящена отдельная статья о том, почему миф «обновления ломают больше, чем чинят» неверен в общем виде, но для защищённых контуров это правило переходит из категории «хорошая практика» в категорию «обязательное условие», и вот почему.

Во-первых, цена ошибки на проде здесь выше: если система обрабатывает персональные данные или входит в состав ГИС, простой из-за неудачного обновления — это не только техническая, но и организационная проблема, которая может потребовать уведомления регулятора или заказчика в зависимости от характера инцидента и договорных обязательств.

Во-вторых, сама специфика подсистем защиты информации плохо диагностируется постфактум. Если после обновления сломался веб-сервер, вы увидите это сразу по логам и коду ошибки. Если после обновления изменилось поведение подсистемы аудита или мандатного контроля доступа — это может быть незаметно неделями, пока не случится инцидент, для которого не найдётся нужной записи в журнале, или пока пользователь не столкнётся с отказом доступа там, где раньше всё работало.

Практическая схема стенда:

# минимальный стенд — отдельная виртуалка/сервер с тем же дистрибутивом
# и максимально близкой к проду конфигурацией

# 1. зафиксировать текущее состояние прод-системы
dpkg -l > prod-packages-before.txt        # для Debian-подобной базы
rpm -qa > prod-packages-before.txt        # для RPM-подобной базы

# 2. развернуть на стенде такую же версию и те же ключевые настройки
#    (в первую очередь — политики мандатного доступа, если они применяются)

# 3. только после этого выполнять целевое обновление на стенде,
#    строго по процедуре из документации вендора

После обновления на стенде — не просто «сервисы стартуют», а прицельная проверка того, что специфично именно для этой системы: работают ли профили и уровни допуска после апгрейда, не изменились ли дефолтные политики замкнутой программной среды (если она используется — список разрешённых к запуску программ иногда сбрасывается или расширяется обновлением), проходит ли штатная процедура входа и разграничения доступа так же, как до обновления. Только после явного прогона этого чек-листа на стенде и фиксации результата имеет смысл планировать окно на проде — и то с готовым путём отката, а не с расчётом «стенд ведь прошёл нормально». Обкатанный на стенде процесс всё равно может повести себя иначе на проде из-за разницы в реальных данных и нагрузке; разбор реального случая, когда обновление прошло проверку, но всё равно уронило прод, и как из этого выходили за счёт заранее готового плана отката, — в статье обновление положило прод: как откатиться.

Сверка с официальной документацией конкретного дистрибутива — обязательный, а не опциональный шаг

Здесь стоит быть предельно честным: точные названия команд, репозиториев, инструментов обновления и порядок действий различаются не только между разными отечественными дистрибутивами, но и между версиями одного и того же дистрибутива — вендоры меняют инструментарий обновления от релиза к релизу. Любая статья, которая приводит вам конкретную последовательность команд для перехода с одной мажорной версии на другую без привязки к точной версии и без ссылки на официальный источник, рискует устареть или оказаться неточной уже к моменту, когда вы её прочитаете.

Поэтому единственно верный порядок действий такой:

1. Найти официальную документацию вендора именно по обновлению между теми версиями, которые у вас установлена сейчас и на которую вы переходите (не общее руководство по дистрибутиву — отдельный раздел про миграцию/обновление между релизами, если он есть).
2. Уточнить у вендора или в документации, поддерживается ли вообще прямое обновление между этими двумя версиями, или предусмотрен только путь через промежуточную версию, или официально поддерживается только чистая установка с переносом данных.
3. Проверить, есть ли у вас действующая техническая поддержка от вендора — для сертифицированных дистрибутивов это часто не просто «горячая линия», а обязательное условие получения обновлений безопасности и корректных инструкций по миграции.
4. Сверить требования к сертификации/аттестации отдельно с тем, кто отвечает за это в вашей организации — как описано выше, это не техническая, а организационная проверка, и документация дистрибутива сама по себе на неё не отвечает.

Эта статья описывает общие принципы и логику подхода, но намеренно не приводит точных версий и точных команд обновления конкретных дистрибутивов — эта информация меняется быстрее, чем живут статьи, и должна браться из первоисточника на момент, когда вы реально планируете обновление.

Сравнение подходов: обычный dist-upgrade и обновление сертифицированной системы

Таблица описывает общую тенденцию, а не жёсткое правило для каждого конкретного дистрибутива — степень автоматизации и формальные требования у разных вендоров и разных редакций одного дистрибутива могут отличаться заметно, поэтому воспринимайте её как карту для ориентирования, а не как исчерпывающую инструкцию.

Частые вопросы