БДУ ФСТЭК и Zimbra: что показывает проверка аттестованной ИС

На производстве в Мытищах, 50 рабочих мест, я разбирал вопрос, который до меня три недели гоняли по кругу между директором, бухгалтерией и приходящим админом. Аттестованная система у клиента была про 1С и склад, а споткнулась проверка о почтовый сервер, про который в документах не было ни строчки. Сентябрь 2025-го. Рассказываю, что именно смотрит проверяющий, какие записи по Zimbra лежат в БДУ ФСТЭК и почему выгрузка из CVE-ленты этот разговор не закрывает.

Знакомая картина: аттестат у компании есть, документы лежат в папке, модель угроз писали внешние люди четыре года назад. В ней перечислены серверы 1С, файловая шара, рабочие места. Почтового сервера нет — потому что тогда почту считали чем-то вроде телефона. А в почте, между тем, ездят анкеты кандидатов, сканы паспортов для пропусков, договоры с физлицами и переписка с медцентром по медосмотрам.

Если это про вас, дальше будет полезно. Проверяющему не нужно ломать ваш сервер. Ему достаточно спросить три вещи: что за продукт, какой версии, и как вы отслеживаете уязвимости по нему. На первом вопросе мой клиент отвечал уверенно. На третьем — замолчал.

Меня позвали в сентябре 2025-го, когда переписка с аттестующей организацией шла уже третью неделю и упёрлась в формулировку «представьте сведения об учёте уязвимостей применяемого ПО». Директор искренне не понимал, чего от него хотят: «сервер работает с 2019 года, ни разу не сломался». Он и правда работал.

Я начал не с бумаг, а с сервера. Разговор про регуляторику без точной версии — это разговор ни о чём.

su - zimbra
zmcontrol -v
# Release 8.8.15.GA.3869.UBUNTU18.64 20190918004220 UBUNTU18_64 FOSS edition, Patch 8.8.15_P30

zmcontrol status | head -20
cat /opt/zimbra/.version 2>/dev/null
lsb_release -d
# Description:  Ubuntu 18.04.6 LTS

Zimbra 8.8.15 Open Source Edition, патч-уровень P30. Общая поддержка этой ветки закончилась 31 декабря 2023 года — то есть на момент проверки сервер жил без единого обновления безопасности от вендора почти два года. Уязвимость в postjournal, наделавшая шума осенью 2024-го, закрывается на этой ветке патчем P46. У клиента стоял P30. Разрыв в шестнадцать патч-уровней.

Дальше я посмотрел, что вообще слушает наружу, и включена ли служба postjournal — она принимает почту по SMTP на порту 10027:

ss -tlnp | grep -E ':(25|80|110|143|443|465|587|993|995|7071|10027)\b'
zmprov gs $(zmhostname) zimbraServiceEnabled | tr ' ' '\n' | grep -i journal
ps -ef | grep -c '[p]ostjournal'

Служба была включена. Веб-админка на 7071 торчала в интернет с белым IP. Это два отдельных факта, и оба придётся объяснять на проверке.

Первое, что я предложил директору, оказалось неверным. Я сказал: обновим Zimbra до актуального патча ветки, приложим скриншот zmcontrol -v — и вопрос снимется. Полтора дня мы готовили окно обновления.

Потом я поговорил с аттестующей организацией напрямую и понял, что промахнулся мимо сути. Их вопрос был не «стоит ли у вас свежая версия». Их вопрос был «покажите процедуру, по которой вы отслеживаете уязвимости и принимаете по ним решения, и покажите, что источником для неё служит банк данных угроз ФСТЭК».

Разница принципиальная. Свежий патч — это состояние на один день. Процедура — это то, что живёт между проверками. Мы бы обновились, получили тот же вопрос через полгода и снова бегали. Я тогда потерял день и признаю это честно: подошёл к регуляторной задаче как к инженерной.

Обновление мы всё равно сделали. Но главной работой стало другое.

Банк данных угроз безопасности информации ФСТЭК России (bdu.fstec.ru) — официальный отечественный источник сведений об уязвимостях. По методикам ФСТЭК он обязателен к использованию при оценке угроз для государственных информационных систем, информационных систем персональных данных и объектов критической информационной инфраструктуры. Не «рекомендован», а именно обязателен как источник.

Практический смысл для вас такой. Ваш админ может подписаться на рассылку вендора, читать ленту CVE, ставить патчи вовремя — и всё равно получить замечание, потому что в модели угроз не окажется ссылок на идентификаторы вида BDU:2024-07171. Проверяющий сверяется со своим справочником, а не с вашим.

Второй момент, который выяснился по ходу. БДУ ведёт карточки по ZCS активно, и формулировки там свои — часто описывается класс уязвимости, а не конкретная сборка. Запись про межсайтовый скриптинг в ZCS проходит как недостаточная защита структуры веб-страницы. Читать это надо не как «у нас другая версия, нас не касается», а как «покажите, что вы проверили применимость к своей сборке и записали вывод».

Третье: Zimbra не входит в реестр отечественного ПО. Для коммерческой компании это само по себе ничего не запрещает. Для организации, у которой в закупках прописан приоритет реестровых продуктов, — отдельная тема разговора, к которой лучше приходить с готовым ответом.

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

Третью строку я намеренно оставил без идентификатора, и это не «не нашёл». Формулировка БДУ по межсайтовому скриптингу в ZCS обезличена по классу — карточка описывает недостаточную защиту структуры веб-страницы вообще, без привязки к конкретной сборке. Комиссии мы так и написали: класс применим, конкретный номер подбирается на дату проверки, потому что записи по XSS в ZCS появляются регулярно. Уточняющих вопросов по этой строке не было.

Ещё одна деталь, на которой спотыкается любой, кто впервые открывает БДУ: год в идентификаторе — это год появления записи в банке, а не год шумихи вокруг уязвимости. Запись BDU:2021-04615 по postjournal лежит там с 2021-го, задолго до того, как в 2024-м об этом векторе заговорили все. Не удивляйтесь и не считайте, что нашли не то.

Обратите внимание на связку: запись про postjournal фигурирует под двумя идентификаторами. Когда я готовил документ, я сначала указал один и получил уточняющий вопрос. Указывайте оба.

Отдельная строчка, которую пришлось написать прямым текстом: версия 8.8.15 OSE находится за границей поддержки с 31 декабря 2023 года, обновлений безопасности по ней не выпускается. Это не мнение и не оценка — это факт жизненного цикла продукта, и он в документах должен быть.

Три команды. Выполнять на почтовом сервере, первые две — из-под пользователя zimbra, третью — от root.

su - zimbra -c 'zmcontrol -v'
su - zimbra -c "zmprov gs $(hostname -f) zimbraServiceEnabled" | tr ' ' '\n' | sort
ss -tlnp | grep -E ':(7071|10027)\b'

Теперь трактовка. Найдите свою строку.

Если ни одной строки из таблицы у вас нет и версия свежая — поздравляю, разговор будет коротким. По моему опыту такое встречается примерно у одного сервера из семи.

Работали в четыре захода, окна согласовывали с производством — цех работает в две смены, полностью тихого времени там нет.

Неделя первая. Собрали инвентаризацию: версия, патч-уровень, ОС, список служб, открытые порты, объём store (у клиента 640 ГБ на 63 ящика), схема сети до сервера. Отдельно выгрузили список ящиков, в которых реально лежат персональные данные, — оказалось 11 из 63, включая общий ящик кадров.

Неделя вторая. Обновили Zimbra в пределах ветки до актуального патч-уровня, ночь субботы, окно 3 часа 40 минут, из них сам апгрейд занял 52 минуты, остальное — бэкап и проверки. Выключили postjournal — служба клиенту была не нужна ни для чего. Убрали 7071 из интернета: доступ к админке остался только из офисной сети и через VPN.

# бэкап перед обновлением, холодная копия
su - zimbra -c 'zmcontrol stop'
tar czf /backup/zimbra-pre-patch-20250920.tgz /opt/zimbra/conf /opt/zimbra/data/ldap
# выключение неиспользуемой службы
su - zimbra -c 'zmprov ms $(zmhostname) -zimbraServiceEnabled postjournal'
su - zimbra -c 'zmcontrol restart'

Неделя третья. Написали регламент: раз в месяц сверять версию и патч-уровень с записями БДУ по ZCS, фиксировать вывод в журнал, при появлении применимой записи — решение в течение 10 рабочих дней. Две страницы, таблица и подпись ответственного. Приложили к нему журнал за сентябрь как образец заполнения.

Деньги. Наши работы — 78 000 ₽ за 26 часов. Что было бы без них: повторный выезд лаборатории и перевыпуск заключения клиенту оценили в 120 000 ₽ и полтора месяца ожидания, а на производстве в этот период было запланировано подключение к контуру нового цеха, которое пришлось бы двигать. Простой почты считали отдельно — на случай, если бы сервер всё-таки поймал что-то через открытый postjournal. Считали так, чтобы цифру нельзя было оспорить на совещании. Средняя отгрузка — 1,4 млн ₽ в день, но почта в этой цепочке не единственный канал: по выгрузке из 1С через неё приходит около 13% заявок, остальное — портал закупок, телефон и постоянные графики поставок. Полдня без почты — это 1 400 000 × 0,5 × 0,13, то есть примерно 91 000 ₽ сдвинутой отгрузки. Слово «сдвинутой» тут важное: деньги не сгорают, они уезжают на следующий день. Но у производства с месячным планом отгрузок сдвиг в конце месяца упирается уже в следующий месяц — и вот там он превращается в настоящую потерю.

Его задали в конце, и он не про безопасность, а про перспективу. Отвечать на него «мы подумаем» плохо: вопрос вернётся.

Реестровых почтовых продуктов на рынке достаточно, и у каждого есть номер, который можно вписать в план: CommuniGate Pro — № 7112 от 12.10.2020, Mailion от МойОфис — № 12707 от 28.01.2022 (плюс сертификат ФСТЭК № 4648), RuPost от Astra Group — № 14647 от 23.08.2022, Tegu — № 9811 от 18.03.2021, МойОфис Почта — № 73 от 20.02.2016.

Самый убедительный аргумент в этом разговоре — не сравнение фич, а чужой прецедент. «Группа Астра», разработчик Astra Linux, сама сидела на Zimbra Collaboration Suite и мигрировала с неё на собственный RuPost: старт в середине августа 2023, к 26 октября 2023 около 80% сотрудников уже работали на новой системе, всего в плане было 1700 пользователей. Два с половиной месяца на основную массу.

Мы записали в план решение о миграции с горизонтом на следующий год и указали, что до неё Zimbra эксплуатируется с компенсирующими мерами и ежемесячным контролем. Комиссию это устроило. Клиента, честно говоря, тоже: он получил не «срочно всё меняем», а понятный график.

Короткий пересказ, если читали по диагонали. Проверяющего интересует не свежесть патча сама по себе, а наличие процедуры и ссылки на БДУ как источник. Zimbra 8.8.15 вне поддержки с 31 декабря 2023 года, и это придётся написать в документах прямо. Записи по ZCS в БДУ есть, минимум по трём классам: выполнение команд через postjournal, SSRF, межсайтовый скриптинг. Выключение неиспользуемой службы и вынос админки из интернета — самые дешёвые меры, которые закрывают самые громкие вопросы.

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

Если хотите понять, где вы стоите, — пришлите мне вывод трёх команд из блока самопроверки: zmcontrol -v, список включённых служб и ss -tlnp по портам 7071 и 10027. За день отвечу, какие записи БДУ к вам применимы, что закрывается настройкой за час, а что требует обновления, и сколько это стоит.

У нас коммерческая компания, не госсектор. БДУ нас вообще касается?

Прямая обязанность использовать БДУ как источник при оценке угроз возникает у государственных информационных систем, информационных систем персональных данных и субъектов КИИ. Если ваша компания под это не подпадает и аттестации нет, формального требования к вам не предъявят. Но проверка — не единственный повод. Записи БДУ по ZCS описывают ровно те же дыры, через которые ломают серверы: выполнение команд через postjournal, SSRF, XSS в веб-клиенте. Мой клиент в Мытищах на 50 рабочих мест — обычное производство, и половину пользы он получил не от бумаг, а от того, что мы выключили ненужную службу и убрали админку из интернета.

Мы обновились до последнего патча. Этого достаточно для проверки?

Нет, и на этом я сам ошибся в первый день. Патч — состояние на конкретную дату, а спрашивают про процедуру: как вы узнаёте о новых записях, кто принимает решение, в какой срок, где это фиксируется. Обновление без регламента даёт хороший скриншот и ноль ответов на второй вопрос. Мы у клиента сделали и то и другое: обновили ветку за окно в 3 часа 40 минут и написали двухстраничный регламент с ежемесячной сверкой и сроком реакции в 10 рабочих дней. Именно вторая часть закрыла переписку.

Как понять, применима ли конкретная запись БДУ к моей сборке?

По трём признакам: ветка и патч-уровень, наличие уязвимого компонента и его доступность. Пример из кейса: запись по postjournal применима, если ветка 8.8.15 ниже Patch 46 или 9.0.0 ниже Patch 41 и служба включена. Проверяется одной командой — смотрите zimbraServiceEnabled и слушает ли порт 10027. Если служба отключена, запись у вас неприменима, но написать об этом надо явно, с указанием команды и её вывода. Формулировка «нас это не касается» без обоснования возвращается вопросом.

Нам сказали, что раз Zimbra не в реестре, надо срочно мигрировать. Это так?

Срочность обычно берётся из воздуха. Zimbra действительно не входит в реестр отечественного ПО, и для организаций с приоритетом реестровых продуктов в закупках это отдельная тема. Но решается она планом, а не паникой. Мы записали миграцию с горизонтом на следующий год и указали, что до неё система эксплуатируется с компенсирующими мерами и ежемесячным контролем версии. Ориентир по срокам есть публичный: «Группа Астра» переводила 1700 пользователей со своей Zimbra на RuPost с середины августа 2023 и к 26 октября имела около 80% на новой системе. Два с половиной месяца при их ресурсах.

Сколько времени занимает подготовка почтового сервера к такой проверке?

У меня получилось три недели календарно и 26 часов работы, причём это производство в две смены, где окна согласовывать тяжело. Разбивка: неделя на инвентаризацию и разбор, где реально лежат персональные данные (у клиента — 11 ящиков из 63), неделя на технические изменения с ночным окном на обновление, неделя на документы и обучение ответственного. Если сервер стоит без документации и админ уволился, добавьте ещё несколько дней на восстановление паролей и схемы — это отдельная работа, и она почти всегда всплывает.