Итоги 2021: Log4Shell перестроил приоритеты, Rocky созрел, WS2022 требует нового железа

В январе у нас был нормальный план на год. CentOS-миграции по расписанию, Windows Server 2022 изучить и подготовить клиентов, PostgreSQL 14 дождаться и накатить в нескольких местах. Часть этого случилась. Но где-то в начале декабря год переписал себя заново - и теперь, с высоты конца декабря, H2 2021 выглядит принципиально иначе, чем мы ожидали в июле.

Log4Shell: до и после

Если честно, про Log4j мы думали в ноябре с академическим интересом - делали аудит Java-компонентов без конкретного повода, просто потому что инвентаризация зависимостей выглядела разумной практикой. 9 декабря выяснилось, что повод появился.

CVE-2021-44228 - это не очередная CVE в ряду других. Это ситуация, когда уязвимость находится в библиотеке, которая буквально везде. Log4j 2 пришёл транзитивно через Spring, Elasticsearch, VMware vCenter, Jenkins, ещё десятки продуктов. Эксплойт - строчка в curl. Работает без аутентификации. CVSS 10.0, и это не завышенная оценка.

Что Log4Shell изменил в нашей работе не на уровне «починить конкретную CVE», а системно:

Инвентарь компонентов стал приоритетом, а не хорошей идеей. Разница между «есть SBOM» и «нет SBOM» оказалась конкретной: два часа против трёх дней на вопрос «где у нас Log4j». Это не метафора - именно столько заняло у разных клиентов выяснение периметра поиска.

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

Три итерации патча за две недели - норма в такой ситуации. 2.15.0 оказался неполным, 2.16.0 принёс новую CVE, 2.17.0 - финал. Процесс патч-менеджмента, рассчитанный на цикл «раз в месяц», здесь не работает.

К концу декабря большинство открытых сред закрыто. Вендорский хвост остаётся - и это честное завершение года: не всё под нашим контролем.

Rocky Linux и Alma: быстрее, чем казалось

В начале года, когда Red Hat объявил судьбу CentOS 8, оба проекта существовали как анонсы и энтузиазм. AlmaLinux и Rocky Linux казались правильными идеями с неясным сроком созревания.

К сентябрю Rocky 8.4 прошёл полный цикл совместимости с RHEL - мы прогнали первую волну миграции у одного из клиентов. Порядка тридцати серверов. Скрипт migrate2rocky.sh работает - большинство серверов проходят чисто, меньшинство требует ручного разбора со сторонними репозиториями и SELinux-политиками. Ничего неожиданного, ничего катастрофического.

Что оказалось верным по итогам: Rocky созрел именно тогда, когда нужно. EOL CentOS 8 - 31 декабря 2021. Мы укладываемся. AlmaLinux шёл параллельно и тоже дошёл до стабильного состояния примерно в том же темпе. По технике они практически неотличимы - выбор между ними у клиентов чаще политический, чем технический.

Важный практический момент: у нас накопился приличный объём Ansible-ролей под CentOS/RHEL. Всё это работает на Rocky без правок. Это было не очевидно в начале года - RHEL-совместимость на уровне пакетов декларировалась, но на уровне автоматизации надо было проверять. Проверили - работает.

Windows Server 2022: хорошо, но железо

Мы смотрели на RC ещё в июле - тогда стало понятно, что Secured-Core ломает старые RAID-драйверы. GA вышел в августе и это не поменял. Secured-Core с HVCI требует, чтобы драйверы ядра были подписаны через современный процесс Microsoft. Контроллеры поколения пятилетней давности от менее крупных производителей - группа риска.

Практический вывод по итогам нескольких клиентских проектов: Windows Server 2022 - нормальный релиз с реальными улучшениями в безопасности. Но планировать переход нужно с инвентаризации железа, а не с даты. Серверы, которые пойдут под 2022, должны иметь актуальные firmware и WHQL-совместимые драйверы - иначе Secured-Core придётся либо выключать (что теряет большую часть смысла 2022), либо разбираться с неработающими контроллерами уже после апгрейда.

SMB over QUIC и встроенный TLS 1.3 по умолчанию - это приятно. Но это не то, ради чего срочно мигрировать. Secured-Core - вот что важно, и именно он создаёт железные требования.

Windows 11 в enterprise - отдельная история. TPM 2.0, Secure Boot, поддерживаемые процессоры - всё это отрезало значительную часть корпоративного парка от официального апгрейда. Несколько клиентов провели инвентаризацию и обнаружили, что 30-40% машин не проходят по аппаратным требованиям. Для них это не «апгрейд в конце года», а разговор о замене железа.

SBOM: из идеи в практику

В сентябре мы писали про SBOM как практику - Syft, Grype, интеграция в CI. Тогда это был разговор про инструменты и зачем они нужны в принципе. Сейчас, в конце декабря, после Log4Shell, вопрос «зачем» закрыт.

Разумный минимум, к которому мы пришли: SBOM генерируется при каждой сборке образа, Grype запускает там же, критические fixable CVE блокируют деплой. Не раз в квартал, не по событию - в каждом пайплайне. Это не сложная инфраструктура, это один шаг в GitLab CI.

Вне Docker сложнее - legacy Java-сервисы, bare-metal, вендорские компоненты без образов. Там инвентарь ведётся руками. Но хотя бы ведётся.

Где мы в конце 2021-го

Год был насыщен инцидентами с инфраструктурой безопасности - Kaseya VSA в июле, PrintNightmare, Apache path traversal в октябре, Log4Shell в декабре. Это не случайная цепочка - supply chain и встроенные компоненты стали очевидным вектором, и 2021-й это показал несколько раз подряд.

Rocky и Alma зрели быстро и оказались готовы тогда, когда нужно. Windows Server 2022 - крепкий релиз с реальными требованиями к железу. SBOM из теоретической практики превратился в инструмент, который конкретно влияет на скорость реакции при инциденте.

Что не сделали: zero trust дальше разговоров и одного пилота не продвинулся. KII-проекты съели время, которое должно было пойти туда. Это честная констатация, не катастрофа.

В конце декабря у нас уже есть черновик плана на первое полугодие 2022. Но после этого декабря мы, кажется, научились планировать с поправкой на то, что повестка в любой момент может переписать приоритеты.