Методика экспресс-аудита зарубежного стека для субъектов КИИ
ФСТЭК и Минцифры давят на субъекты КИИ по срокам перехода на отечественное ПО. Разработали методику аудита: что инвентаризировать, как расставить приоритеты, с чего начать.
ФСТЭК и Минцифры усиливают давление на субъекты КИИ по переходу на отечественное ПО
В январе мы собирали матрицу зарубежного стека по клиентам - просто чтобы понять масштаб. В феврале нас начали спрашивать: окей, матрица есть, что с ней делать? Параллельно с этим давление со стороны ФСТЭК и Минцифры на субъекты КИИ заметно усилилось - и у нескольких клиентов вопрос из «надо бы разобраться» перешёл в «надо разобраться до конца квартала».
Пришлось оформить подход в методику, которую можно воспроизвести не только внутри команды.
Почему «экспресс»
Полноценный аудит информационной системы - это долго. Документирование, опросы, сверка с фактической конфигурацией, согласование с владельцами процессов. Для целей импортозамещения нам нужно другое: быстро получить достаточную картину, чтобы расставить приоритеты и сформировать хоть какой-то план. Не идеальный, но реальный.
Экспресс - это две недели, не два месяца. Глубина - достаточная для приоритизации, не достаточная для проектирования замены.
Что инвентаризировать
Мы делим стек на семь слоёв. Порядок важен - он отражает глубину зависимости:
- Операционные системы. Серверные и клиентские отдельно. Версии, количество инстансов, роли (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 позиций, отсортированных по приоритету, с первичной оценкой трудоёмкости замены.
Это не план проекта. Это исходная точка для разговора с руководством клиента о том, что вообще предстоит. Без такой точки разговор обычно идёт в режиме «импортозамещение - это сложно и дорого», что технически верно, но бесполезно.
С точкой - можно говорить предметно.
- Открываем 2022-й: матрица зарубежного стека у клиентов и первый вопрос года · 4 января 2022
- Log4Shell: завершаем январский аудит и считаем хвосты · 7 января 2022