ADG Оставить заявку
Блог Регуляторика 5 мин чтения

Методика экспресс-аудита зарубежного стека для субъектов КИИ

ФСТЭК и Минцифры давят на субъекты КИИ по срокам перехода на отечественное ПО. Разработали методику аудита: что инвентаризировать, как расставить приоритеты, с чего начать.

Контекст момента

ФСТЭК и Минцифры усиливают давление на субъекты КИИ по переходу на отечественное ПО

В январе мы собирали матрицу зарубежного стека по клиентам - просто чтобы понять масштаб. В феврале нас начали спрашивать: окей, матрица есть, что с ней делать? Параллельно с этим давление со стороны ФСТЭК и Минцифры на субъекты КИИ заметно усилилось - и у нескольких клиентов вопрос из «надо бы разобраться» перешёл в «надо разобраться до конца квартала».

Пришлось оформить подход в методику, которую можно воспроизвести не только внутри команды.

Почему «экспресс»

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

Экспресс - это две недели, не два месяца. Глубина - достаточная для приоритизации, не достаточная для проектирования замены.

Что инвентаризировать

Мы делим стек на семь слоёв. Порядок важен - он отражает глубину зависимости:

  • Операционные системы. Серверные и клиентские отдельно. Версии, количество инстансов, роли (AD, файловый сервер, СУБД-хост и т.д.).
  • Гипервизоры и платформы виртуализации. VMware vSphere, Hyper-V, что-то другое. Версия, количество хостов, тип лицензии (perpetual или subscription).
  • Базы данных. Продукт, версия, критичность данных (перечень систем, которые на ней сидят).
  • Средства защиты информации. EDR, SIEM, межсетевые экраны, средства криптозащиты. Отдельно - наличие сертификата ФСТЭК / ФСБ на текущий продукт.
  • Сетевое оборудование. Производитель, страна происхождения, тип лицензирования (железо + ПО раздельно или нет).
  • Системы мониторинга и управления. Zabbix, Grafana, Nagios, коммерческие продукты - отдельная строка.
  • Продуктивность и коммуникации. Microsoft 365, Google Workspace, локальные Exchange/Outlook. Важно отметить: облачный сервис или on-premise - это разные истории риска.

По каждому слою фиксируем: продукт, вендор, страна вендора, наличие в реестре отечественного ПО, наличие активного договора поддержки с вендором или его партнёром.

Матрица критичности

После инвентаризации каждой позиции выставляем две оценки:

Регуляторный приоритет - насколько быстро регулятор обратит на это внимание. Высокий у средств защиты (239-й приказ ФСТЭК), у систем, обрабатывающих персональные данные (152-ФЗ), у элементов, задействованных в категорированных объектах КИИ. Низкий - у вспомогательного инструментария, который прямо в ИС не входит.

Операционный риск - что будет, если поддержка прекратится или лицензия не продлится. Для гипервизора, под которым работает 80% ВМ, это катастрофа. Для плагина к Grafana - неприятность.

Получается матрица 3x3. Позиции в правом верхнем углу - высокий регуляторный приоритет, высокий операционный риск - идут в план первыми. Левый нижний угол можно отложить.

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

С чего начинать замену

Самый частый вопрос. Наш ответ: не с того, что хочется заменить, а с того, где есть работающая альтернатива и понятный путь миграции.

На практике это означает:

  • Первое - средства защиты. Здесь есть реестр, есть сертифицированные продукты, есть регуляторная срочность. Замена западного EDR на отечественный болезненна, но путь понятен - вендоры класса «Касперский», «Доктор Веб», PT и ряда других давно на рынке.
  • Второе - базы данных на некритичных системах. PostgreSQL 13 уже хорошо себя показывает на продуктивной нагрузке, Pangolin и ряд других PostgreSQL-дистрибутивов идут в реестр. Начинать с некритичной системы - это получить опыт без катастрофических последствий при неудаче.
  • Третье - операционные системы на новых серверах. Не мигрировать старые, а новые серверы сразу разворачивать на Astra Linux или РЕД ОС. Это медленно, но без операционных рисков.

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

Шаблон матрицы

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

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

Если нужна помощь с проведением такого аудита - аудит инфраструктуры именно про это.

Где мы сейчас

Методику мы прогнали на двух клиентах. Оба раза инвентаризация заняла примерно неделю, матрица критичности - ещё два-три дня. Выход - перечень из 10-15 позиций, отсортированных по приоритету, с первичной оценкой трудоёмкости замены.

Это не план проекта. Это исходная точка для разговора с руководством клиента о том, что вообще предстоит. Без такой точки разговор обычно идёт в режиме «импортозамещение - это сложно и дорого», что технически верно, но бесполезно.

С точкой - можно говорить предметно.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.