ЗАМЕНА СУБД В КИИ ЗА 18 МЕСЯЦЕВ — ДОРОЖНАЯ КАРТА ДЛЯ РЕГИОНАЛЬНОГО ИТ

Региональные ИТ-отделы, обслуживающие объекты КИИ, получают предписания ФСТЭК на замену Oracle, Microsoft SQL Server и других зарубежных СУБД. Дедлайн — конец 2026 года. На пилотирование нет ни выделенной команды, ни чёткого плана. Ниже — поэтапная дорожная карта: что делать в первую очередь, сколько ресурсов заложить и где искать кадровый резерв, когда штатных DBA не хватает.

Главное

С 2022 года ФСТЭК России последовательно выдаёт предписания субъектам КИИ о переводе информационных систем на сертифицированное отечественное программное обеспечение. Указ Президента № 166 от 30 марта 2022 года запретил закупку иностранного ПО для объектов КИИ с 1 января 2025 года, а предписания по уже эксплуатируемому зарубежному ПО ставят конкретные даты устранения. Для большинства региональных органов власти, включённых в реестр субъектов КИИ, финальный рубеж приходится на конец 2026 года. При этом средний региональный ИТ-отдел — 5–12 человек, из которых один-два администратора СУБД, и у них уже есть текущие задачи поддержки.

Почему предписание нельзя игнорировать

Статья 14 Федерального закона № 187-ФЗ «О безопасности критической информационной инфраструктуры» предусматривает уголовную ответственность для должностных лиц, не выполнивших требования регулятора, если это повлекло ущерб. Предписание ФСТЭК — не рекомендация: контрольная проверка следует через срок, указанный в документе. Незакрытое предписание фиксируется в акте повторной проверки и передаётся в прокуратуру.

Параллельно действует ППРФ № 1236, по которому государственные органы обязаны применять ПО из реестра Минцифры. Отечественные СУБД, получившие сертификат ФСТЭК по 4-му или более высокому уровню доверия, присутствуют в реестре и могут закупаться по 44-ФЗ через стандартные процедуры.

Дорожная карта: четыре этапа за 18 месяцев

Этап 1. Инвентаризация и анализ зависимостей — 6–8 недель

Перед выбором целевой СУБД нужно понять, что именно мигрирует. Распространённая ошибка — сразу выбирать продукт, не зная ни количества баз, ни специфики диалекта SQL, ни нестандартных хранимых процедур.

Составьте реестр всех баз данных на зарубежных СУБД с указанием ИС, к которой они относятся, категории КИИ и данных, которые обрабатывает система.
Зафиксируйте версию, диалект SQL и использование специфических функций: секционирование, триггеры, CLR-объекты (для MS SQL), пакеты PL/SQL (для Oracle).
Определите внешние интеграции: сторонние сервисы, которые подключаются к СУБД напрямую, без прикладного слоя, — они потребуют отдельной договорённости с поставщиком.
Оцените объём данных и допустимое окно простоя для каждой ИС — это определит, нужна ли зеркальная репликация при переключении.

Ресурс: один аналитик или DBA, 2–3 дня на каждую ИС. При 10–15 системах — около 6 недель с учётом коммуникаций с владельцами систем.

Этап 2. Пилот на некритичной подсистеме — 6–10 недель

Пилот нужен не для подтверждения того, что отечественная СУБД работает. Пилот нужен для измерения объёма доработок прикладного кода под конкретную целевую СУБД и выявления узких мест производительности.

Выберите систему с минимальным числом интеграций и без строгих SLA — например, внутренний документооборот или архивная БД.
Перенесите схему и данные инструментами миграции целевой СУБД. Зафиксируйте все ошибки конвертации — это прямой список доработок для тиражирования.
Проведите нагрузочное тестирование на реальных объёмах. Отечественные СУБД на базе PostgreSQL хорошо справляются с OLTP-нагрузкой, но планировщик запросов может вести себя иначе на сложных JOIN при большом числе разделов.
Получите обратную связь от прикладных разработчиков — они, как правило, выявляют несовместимости, которые DBA не видит.

Ресурс: DBA + один разработчик прикладного уровня. Если своих нет — это первая точка, где привлечение внешнего подрядчика оправдано: объём работы ограничен и хорошо измерим.

Этап 3. Последовательная миграция систем — 8–12 месяцев

После пилота у команды есть типовой сценарий конвертации и список исключений. Дальше миграция идёт волнами — по приоритету, от менее критичных к системам высокой категории КИИ.

Разбейте все ИС на три волны по критичности. Первая волна — системы 3-й категории или без категории КИИ. Вторая — системы 2-й категории. Третья — 1-я категория, наибольшая осторожность и максимальное окно тестирования.
Для каждой ИС фиксируйте план отката: резервная копия в исходной СУБД должна существовать минимум 2 недели после переключения.
Планируйте переключение на период низкой нагрузки и согласовывайте его с пользователями заранее — региональные системы нередко работают в авральном режиме перед квартальной отчётностью.
Ведите журнал закрытых систем — он понадобится для ответа на вопросы ФСТЭК при контрольной проверке.

Ресурс: при 10–15 ИС и двух DBA реалистичный темп — одна-две системы в месяц. Форсировать не стоит: ошибка при переключении системы 1-й категории КИИ обходится дороже, чем задержка на месяц.

Этап 4. Документирование и снятие предписания — 6–8 недель

ФСТЭК при контрольной проверке смотрит не только на то, что зарубежная СУБД удалена, но и на то, что замена проведена по документированному процессу и новая система включена в действующую модель угроз и систему защиты.

Актуализируйте модель угроз и технический паспорт ИС — в них должна быть отражена новая СУБД с указанием версии и реквизитов сертификата ФСТЭК.
Убедитесь, что новая СУБД включена в периметр мониторинга: события аутентификации, DDL-операции и аномалии доступа должны поступать в SIEM или средство мониторинга.
Подготовьте ответ на предписание: перечень закрытых пунктов, подтверждающие документы (акты ввода в эксплуатацию, копии сертификатов, скриншоты инвентаризации).
Направьте уведомление в ФСТЭК об устранении нарушений в установленном порядке.

Где брать людей, когда штат не укомплектован

Кадровый дефицит — главный практический барьер для региональных ИТ-служб. Несколько рабочих вариантов, которые применяют уже сейчас.

Пилот и конвертация — на подрядчика. Компании, специализирующиеся на внедрении отечественных СУБД, накопили типовые сценарии конвертации с Oracle, MS SQL и MySQL. Объём пилота хорошо ограничен по деньгам и срокам — удобно для закупки по 44-ФЗ как ИТ-услуга.
Обучение штатного DBA — параллельно с пилотом. Большинство производителей отечественных СУБД проводят авторизованные курсы длительностью 3–5 дней. Это меньше, чем кажется: PostgreSQL-совместимые СУБД освоить проще, чем переучиться с Oracle на MS SQL.
Вендорская техподдержка — на период волн миграции. Платная поддержка производителя СУБД включает консультации по нестандартным случаям и иногда — прямую помощь с конвертацией хранимых процедур. При мигации систем 1-й категории КИИ это снижает риск ошибки.
Соглашение с соседними регионами. Несколько региональных ИТ-служб формируют рабочую группу и делятся сценариями конвертации типовых региональных систем — ГИС ЖКХ, региональный ЗАГС, портал госуслуг регионального уровня нередко работают на одних и тех же версиях зарубежных СУБД.

Оценка ресурсов: сводная таблица

Ориентировочные трудозатраты при портфеле из 12–15 информационных систем, из которых 3–4 относятся к высокой категории КИИ.

Инвентаризация: 1 DBA или аналитик, 6–8 недель, ~120–160 чел./часов
Пилот: 1 DBA + 1 разработчик, 6–10 недель, ~200–280 чел./часов
Миграция волн 1–2 (менее критичные ИС): 2 DBA, 5–7 месяцев, ~400–600 чел./часов
Миграция волны 3 (высококритичные ИС): 2 DBA + внешний подрядчик, 3–4 месяца, ~250–350 чел./часов
Документирование и снятие предписания: 1 специалист ИБ + 1 DBA, 6–8 недель, ~80–120 чел./часов

Итого: 18 месяцев — реалистичный срок при двух штатных DBA и привлечении подрядчика для пилота и третьей волны. При одном DBA — либо 24 месяца, либо более интенсивное привлечение внешней команды.

Связанные продукты

Для выполнения предписания ФСТЭК потребуется СУБД, включённая в реестр Минцифры и имеющая действующий сертификат ФСТЭК России. На российском рынке присутствует несколько решений: Postgres Pro Enterprise, Tantor SE, Jatoba, ЛИНТЕР — каждое с разным уровнем совместимости с Oracle и MS SQL и разными условиями технической поддержки. Выбор зависит от диалекта исходной СУБД, объёма данных и требований к уровню доверия сертификата.

Специалисты СОФТЗАЩИТА помогают подобрать подходящую СУБД под конкретный профиль систем КИИ, организовать пилот и сопроводить закупку по 44-ФЗ. Проконсультируйтесь — особенно если в портфеле есть системы Oracle с активным PL/SQL: это самый трудоёмкий случай конвертации, и здесь важно правильно оценить объём до начала закупки.

Источник

Официальный сайт ФСТЭК России · fstec.ru · Указ Президента № 166 от 30.03.2022 · Федеральный закон № 187-ФЗ от 26.07.2017

к статьям рубрики «КИИ и 187-ФЗ»