Итоги 2014 года в ИТ-инфраструктуре: уязвимости, Docker и импортозамещение

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

Безопасность: год, который переписал патч-менеджмент

До 2014 года у нас было, честно говоря, расслабленное отношение к патч-менеджменту. Обновления ставились, но по расписанию - раз в месяц, по WSUS, по yum-cron ночью. Экстренного процесса не было. Была вера в то, что «критическая уязвимость с немедленной эксплуатацией» - это скорее теоретическая конструкция.

Апрельский Heartbleed эту веру несколько поколебал. Уязвимость в OpenSSL, которая позволяет читать память процесса через TLS-рукопожатие - без аутентификации, без следов в логах. Патч вышел быстро, но сам факт того, что OpenSSL - библиотека, которая стоит буквально везде - мог сливать приватные ключи и сессионные токены на протяжении двух лет, оказался неприятным.

Shellshock в сентябре - уже жёстче. CVE-2014-6271 в bash, которую мы разбирали в деталях, давала удалённое выполнение кода через переменные окружения. На серверах с Apache и CGI это была открытая дверь без аутентификации. Первая ночь после публикации у нас была занята патчингом, а не сном.

POODLE в октябре добавил к этому отключение SSLv3 - протокола, который де-факто считался живым, потому что IE6 без него не работал. Оказалось, что у нескольких клиентов IE6 на продакшн-машинах - не ноль. Это отдельный разговор о совместимости и наследии, который мы вели с клиентами весь октябрь.

Итог по безопасности - мы переписали внутренний процесс патч-менеджмента. Теперь есть явное разделение: плановые обновления по расписанию и экстренный процесс для CVSSv2 >= 9.0. У экстренного - конкретный триггер, конкретный ответственный, конкретное время реакции. То, что было очевидным в теории, стало обязательным на практике после трёх заходов за год. Подробнее об этом - в посте про патч-менеджмент как критический процесс.

Docker: из «интересно попробовать» в рабочий инструмент

В начале года Docker был темой для экспериментов - ставили, щупали, что-то запускали в тестовых средах. К концу года картина другая: несколько внутренних сервисов уже живут в контейнерах, у одного клиента поставили внутренний реестр образов, docker-compose используем для поднятия dev-сред.

Это не значит, что мы перевели всё подряд на Docker - нет. Но Docker перестал быть «вот это надо будет изучить» и стал «вот это мы уже используем». Разница ощутимая.

Что изменилось в подходе за год:

• Образы стали артефактами сборки. Не «на сервере стоит такая-то версия», а образ с конкретным тегом, который можно воспроизвести и откатить.
• Изоляция зависимостей. Несколько сервисов с разными версиями Python или Node на одном хосте - то, что раньше решалось virtualenv с разной степенью боли, теперь решается чище.
• Оркестрации пока нет. docker-compose хватает для небольших задач, но для чего-то серьёзного нужно что-то сверху. CoreOS с fleet смотрим, но это пока эксперимент.

Что нас беспокоит в Docker прямо сейчас: безопасность на уровне изоляции ядра. Контейнеры разделяют ядро хоста - это принципиально иначе, чем VM. Для продакшна с данными клиентов это вопрос, который мы обсуждаем отдельно для каждого случая, а не принимаем по умолчанию.

Импортозамещение: лозунг стал задачей

Летом, когда пошли первые запросы на аудит иностранного ПО, это выглядело как административный рефлекс на санкционный шум. К осени стало понятнее: 242-ФЗ про локализацию персональных данных, аудит зависимостей у клиентов, реальные вопросы «а что будет с VMware, если санкции ужесточатся». Это уже не лозунг - это рабочие задачи.

За год мы провели инвентаризацию иностранного ПО у нескольких госклиентов и пришли к нескольким наблюдениям:

• Операционные системы заменяемы, но не быстро. Astra Linux, Alt Linux - они работают, сертификаты есть, но переход со сложившейся Windows-инфраструктуры - это проект на месяцы, а не недели.
• СУБД - самый реалистичный путь. PostgreSQL в качестве замены MS SQL мы уже прокладывали конкретно, это работает при аккуратном аудите совместимости приложений.
• Виртуализация - самая болезненная точка. KVM технически зрелый, но переход с vSphere на десятках хостов - это отдельный полноценный проект. Быстрых решений нет.

Главный практический вывод по импортозамещению: у большинства клиентов нет актуального реестра лицензий. Прежде чем обсуждать замену - надо понять, что вообще стоит в инфраструктуре. Это скучная работа, но без неё любой разговор про замену - абстракция.

Что из этого следует

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

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