Технологический суверенитет финансового сектора превратился из отвлечённой стратегической установки в практическую задачу с конкретными сроками. После 2022 года ведущие зарубежные поставщики корпоративного программного обеспечения свернули работу в Российской Федерации: о прекращении деятельности заявили Oracle и SAP [1], приостановила продажи Microsoft [2], закрыла бизнес IBM [3]. Для банков это означало не просто смену поставщика, а утрату технической поддержки, прекращение поставки обновлений безопасности и невозможность легального продления лицензий на эксплуатируемые продукты. При этом одним из наиболее уязвимых звеньев оказались системы управления базами данных (СУБД): даже там, где прикладная часть автоматизированной банковской системы (АБС) была отечественной, в её основании нередко работала иностранная СУБД.

Обязательность перехода на отечественное программное обеспечение закреплена последовательным пакетом нормативных актов. Указ Президента Российской Федерации от 30.03.2022 № 166 установил запрет на использование иностранного программного обеспечения на значимых объектах критической информационной инфраструктуры (КИИ) с 1 января 2025 года [4]. Контроль за переходом кредитных организаций отнесён к полномочиям Банка России статьёй 57.5–1 Федерального закона от 10.07.2002 № 86-ФЗ [5]. Положение Банка России от 12.01.2022 № 787-П включило технологическую зависимость от иностранных вендоров в периметр управления операционными рисками [6], а Письмо Банка России от 05.02.2025 № 56–21/949 дополнительно разъяснило необходимость перехода в рамках обеспечения операционной надёжности [7]. Завершил конструкцию Федеральный закон от 07.04.2025 № 58-ФЗ, обязавший субъектов КИИ применять на значимых объектах только программное обеспечение из Единого реестра отечественного ПО [8]. В совокупности эти документы не оставляют банковскому сектору возможности отложить миграцию на неопределённый срок.

Практическая трудоёмкость перехода, однако, определяется не столько нормативными требованиями, сколько архитектурой конкретной АБС. В трёхзвенных системах прикладная логика вынесена на сервер приложений, что ослабляет привязку к конкретной СУБД и упрощает её замену. В двухзвенных системах ситуация принципиально иная: бизнес-логика размещена непосредственно в СУБД (в хранимых процедурах, функциях и триггерах) из-за чего система оказывается жёстко связанной со средой исполнения. Опыт миграции сильно связанных систем такого типа показывает, что перенос данных составляет лишь малую часть работы, тогда как основной объём приходится на переработку серверного кода под иной диалект SQL и иной процедурный язык [9; 10]. Именно поэтому двухзвенные АБС представляют собой наиболее сложный и одновременно показательный случай с точки зрения рисков информационной безопасности, и настоящая работа сосредоточена на этом классе систем.

Часть кредитных организаций в качестве целевой платформы выбрала PostgreSQL и построенные на его основе отечественные продукты. Такой выбор обеспечил быстрый старт, но привнёс собственные риски: применение программного обеспечения с открытым исходным кодом в системах банковского уровня сопряжено с возможностью наследования уязвимостей базового ядра. Цель настоящей статьи — выделить и охарактеризовать угрозы информационной безопасности, специфичные именно для переходного состояния двухзвенной АБС, и показать, что действующий методический инструментарий не охватывает их в полной мере. Методическую основу составили анализ нормативно-правовых актов в области импортозамещения и защиты информации, а также систематизация угроз по источнику их возникновения.

Ключевая особенность рассматриваемой задачи состоит в том, что риски миграции относятся не к стабильно работающей системе, а к процессу её преобразования. На всём протяжении перехода АБС не тождественна ни исходной, ни целевой конфигурации: она пребывает в промежуточном, неустойчивом состоянии, в котором меры защиты реализованы лишь частично, а контуры безопасности старой и новой платформ частично перекрываются. Конфигурация системы при этом меняется по ходу самого проекта, целевая платформа на ранних этапах эксплуатируется в условиях ограниченного опыта, а часть рисков носит временный характер и исчезает по завершении перехода. Эти свойства принципиально отличают переходное состояние от стабильного функционирования и не позволяют описать его однократно построенной моделью угроз.

Действующий инструментарий оценки угроз ориентирован на иную ситуацию. Методический документ ФСТЭК России по оценке угроз безопасности информации регламентирует построение модели угроз для систем с определённой, устойчивой конфигурацией [11] и не предусматривает отдельного порядка анализа угроз, возникающих в самом процессе смены платформы. Между тем импортозамещение не устраняет риски информационной безопасности, а перестраивает их структуру: возникают новые уязвимости, сложности интеграции и ошибки, характерные именно для переходного периода [12]. Масштаб задачи усугубляет дефицит апробированных практик, миграция корпоративных систем такого класса на отечественные СУБД оценивается отраслевыми специалистами как беспрецедентная по сложности, а массовый практический опыт её решения фактически отсутствует [13]. Совокупность этих обстоятельств делает обоснованным рассмотрение переходного состояния как самостоятельного объекта анализа. Ниже специфические угрозы рассмотрены по трём группам — технологические, организационные и операционные, регуляторные.

Технологические угрозы порождаются различиями между исходной и целевой платформами на уровне архитектуры, диалекта SQL и механизмов исполнения кода. В двухзвенной АБС основным их носителем выступает серверный код, в котором реализована бизнес-логика финансовых операций. При переходе на PostgreSQL этот код подлежит конвертации из процедурного языка Oracle в PL/pgSQL, причём автоматизированные средства переноса обеспечивают синтаксическую корректность результата, но не гарантируют его смысловой эквивалентности. Сконвертированная процедура может выполняться без ошибок и при этом возвращать значения, отличные от исходных. Применительно к расчётным операциям банка подобное расхождение означает прямую угрозу искажения финансовых результатов, способную долго оставаться незамеченной.

Конкретные источники смысловых расхождений хорошо известны из практики переноса. Объекты, выполняющиеся с правами владельца схемы, при конвертации требуют явного воспроизведения этого режима и фиксации пути поиска схем. Пропуск любого из этих шагов либо открывает клиентскому коду прямой доступ к таблицам в обход контролируемого интерфейса, либо создаёт условия для подмены схемы. Автономные транзакции, широко используемые в банковских системах для журналирования и фиксации аудит-записей, не имеют прямого аналога в ряде редакций PostgreSQL, и их некорректная замена приводит к откату аудит-записи вместе с основной операцией, нарушая целостность журнала. Переменные уровня пакета, хранящие состояние в пределах сессии, при переносе требуют воспроизведения альтернативными средствами, а ошибка в реализации способна привести к разделению состояния между сессиями разных клиентов. Свой вклад вносят и менее очевидные различия: в арифметике дат, в поведении логического типа, в обработке неопределённых значений при соединениях таблиц, — каждое из которых в финансовых расчётах оборачивается ошибкой результата.

Помимо угроз целостности логики, переход сопряжён с риском снижения производительности. Замена зрелого коммерческого решения на платформу с иными планировщиком запросов и механизмами блокировок может привести к деградации отклика под нагрузкой, прежде всего в пиковые периоды банковских операций, что напрямую угрожает непрерывности обслуживания. Наконец, происхождение целевой платформы от открытого ядра формирует риск унаследованных уязвимостей. Поддержание минимального уровня защиты на протяжении всего перехода, включая контроль подобных уязвимостей, относится к базовым требованиям к защите информации финансовых организаций [14].

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

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

Снизить остроту перечисленных угроз позволяет вынесение предмиграционного аудита и оценки рисков перехода в самостоятельный этап, предшествующий активной фазе. Предварительная инвентаризация критически важных компонентов и оценка операционных, финансовых и регуляторных последствий перехода рассматриваются как необходимое условие управляемости проекта [15], поскольку ошибки планирования, допущенные на этом этапе, проявляются позднее, когда стоимость их устранения существенно возрастает.

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

Вторая регуляторная угроза связана с аттестацией. Смена программно-технической платформы значимого объекта КИИ влечёт необходимость повторной оценки соответствия и аттестации информационной системы [17]. Этот процесс требует времени и ресурсов, а период между завершением технической миграции и получением документального подтверждения соответствия, в течение которого система уже обрабатывает реальные данные, представляет собой самостоятельную зону регуляторного риска.

Управление перечисленными угрозами опирается на отраслевую нормативную базу, прежде всего на стандарты серии ГОСТ Р 57580. ГОСТ Р 57580.1–2017 задаёт базовый состав организационных и технических мер защиты, образующий нижнюю границу требований, которую недопустимо нарушать даже в переходный период [14]. ГОСТ Р 57580.3–2022 формирует методологию управления риском реализации информационных угроз, описывая его как непрерывный цикл из стадий планирования, реализации, контроля и совершенствования [18]; эта цикличность концептуально согласуется с проектным характером миграции и допускает проекцию стадий стандарта на этапы перехода. ГОСТ Р 57580.4–2022 конкретизирует меры обеспечения операционной надёжности и устанавливает требования к повторной аттестации после изменения системы [17].

Теоретическую опору такого подхода составляет ряд исследований. Моделирование угроз рассматривается как основа выбора адекватных мер защиты и минимизации рисков [19], а управление информационной безопасностью обоснованно строится на системной оценке рисков, а не на простом перечислении защитных мероприятий [20]. Применительно к импортозамещению подчёркивается, что переход на отечественные решения следует трактовать не как замену отдельных продуктов, а как изменение всей модели обеспечения безопасности бизнеса [21]; при этом известны и примеры системных моделей информационной безопасности, разработанных для объектов кредитно-финансовой сферы [22]. Эти работы формируют общую методологическую рамку, однако ни одна из них не адаптирована к специфике переходного состояния системы.

В этом и состоит методологический пробел. Все рассмотренные стандарты и подходы ориентированы на защиту стабильно функционирующих систем с устойчивым контуром безопасности. Ни один из них не предлагает специализированной модели управления рисками для динамического переходного состояния — периода, в котором конфигурация защиты нестабильна, контуры старой и новой среды пересекаются, а часть рисков существует лишь временно. Применение положений серии ГОСТ Р 57580 обеспечивает нормативное соответствие и общую основу управления рисками, но требует содержательной адаптации к процессу перехода.

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

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

Литература:

1. SAP и Oracle заявили об уходе с российского рынка. — Текст: электронный // i-IAS: [сайт]. — URL: https://i-ias.ru/press/publikatsii-v-smi/a5rczzo3a1-sap-i-oracle-zayavili-ob-uhode-s-rossiis/ (дата обращения: 19.06.2026).
2. ТАСС Microsoft приостанавливает продажи в России / ТАСС. — Текст: электронный // tass.ru: [сайт]. — URL: https://tass.ru/ekonomika/18874539 (дата обращения: 19.06.2026).
3. IBM уничтожила свой бизнес в России. — Текст: электронный // CNews: [сайт]. — URL: https://www.cnews.ru/news/top/2022–06–07_ibm_unichtozhila_svoj_biznes (дата обращения: 19.06.2026).
4. О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации: Указ Президента Российской Федерации от 30.03.2022 № 166. — Текст: электронный // Гарант: [сайт]. — URL: https://www.garant.ru/products/ipo/prime/doc/404395544/ (дата обращения: 19.06.2026).
5. О Центральном банке Российской Федерации (Банке России): Федеральный закон от 10.07.2002 № 86-ФЗ. — Текст: электронный // КонсультантПлюс: [сайт]. — URL: https://www.consultant.ru/document/cons_doc_LAW_37570/ (дата обращения: 19.06.2026).
6. Об обязательных для кредитных организаций требованиях к операционной надёжности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг: Положение Банка России от 12.01.2022 № 787-П. — Текст: Гарант // garant.ru: [сайт]. — URL: https://www.garant.ru/products/ipo/prime/doc/411381203/ (дата обращения: 19.06.2026).
7. О предоставлении разъяснений требований по переходу на отечественное ПО: Письмо Банка России от 05.02.2025 № 56–21/949. — Текст: электронный // КонсультантПлюс: [сайт]. — URL: https://www.consultant.ru/document/cons_doc_LAW_502581/ (дата обращения: 19.06.2026).
8. Федеральный закон от 07.04.2025 № 58-ФЗ «О внесении изменений в Федеральный закон «О безопасности критической информационной инфраструктуры Российской Федерации»» [Электронный ресурс]. — URL: https://www.consultant.ru/document/cons_doc_LAW_413177/ (дата обращения: 19.06.2026).
9. Малых, В. Л. Миграция с oracle на postgresql сильно связной МИС Интерин / В. Л. Малых, А. Н. Калинин. — Текст: непосредственный // Программные системы: теория и приложения. — 2022. — № 4 (55).
10. Белышев, Д. В. Опыт импортозамещения в медицинской информационной системе «Интерин Promis Alpha» / Д. В. Белышев. — Текст: непосредственный // Программные системы: теория и приложения. — 2022. — № 4 (55).
11. Методика оценки угроз безопасности информации: методический документ от 05.02.2021. — Текст: электронный // fstec.ru: [сайт]. — URL: https://fstec.ru/dokumenty/vse-dokumenty/spetsialnye-normativnye-dokumenty/metodicheskij-dokument-ot-5-fevralya-2021-g (дата обращения: 19.06.2026).
12. Верещагин, И. Ю. Современные угрозы и риски информационной безопасности корпоративных систем в условиях импортозамещения / И. Ю. Верещагин. — Текст: непосредственный // Вестник евразийской науки. — 2024. — № 4S.
13. Как банки готовятся к переходу на отечественные СУБД для хранилищ данных? / Lab Intersoft. — Текст: электронный // iso.ru: [сайт]. — URL: http://iso.ru/ru/press-center/publications/03683-Kak-banki-gotovyatsya-k-perehodu-na-otechestvennye-SUBD-dlya-hra.phtml (дата обращения: 19.06.2026).
14. ГОСТ Р 57580.1–2017. Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. — Текст: электронный // cntd.ru: [сайт]. — URL: https://docs.cntd.ru/document/1200146534 (дата обращения: 19.06.2026).
15. Николашин М. В., Белаш В. Ю. О реализации требований информационной безопасности в условиях импортозамещения. [Электронный ресурс] URL: https://www.dnevniknauki.ru (дата обращения: 19.05.2026).
16. Реестр сертифицированных средств защиты информации. — Текст: электронный // fstec.ru: [сайт]. — URL: https://reestr.fstec.ru/reg3 (дата обращения: 19.06.2026).
17. ГОСТ Р 57580.4–2022. Безопасность финансовых (банковских) операций. Обеспечение операционной надёжности. Базовый состав организационных и технических мер. — Текст: электронный // cntd.ru: [сайт]. — URL: https://docs.cntd.ru/document/1200194765 (дата обращения: 19.06.2026).
18. ГОСТ Р 57580.3–2022. Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надёжности. Общие положения. — Текст: электронный // cntd.ru: [сайт]. — URL: https://docs.cntd.ru/document/1200194766 (дата обращения: 19.06.2026).
19. Баранкова, И. И. Минимизация рисков информационной безопасности на основе моделирования угроз безопасности / И. И. Баранкова, У. В. Михайлова, М. В. Афанасьева. — Текст: непосредственный // ОмГТУ. — 2019. — № 4.
20. Максименко, В. Н. Основные подходы к анализу и оценке рисков информационной безопасности / В. Н. Максименко, Е. В. Ясюк. — Текст: непосредственный // Экономика и качество систем связи. — 2017. — № 2 (4).
21. Витязев Г. Г. Информационная безопасность бизнеса в контексте импортозамещения // Вестник науки и образования. 2018. № 9 (45). URL: https://cyberleninka.ru/article/n/informatsionnaya-bezopasnost-biznesa-v-kontekste-importozamescheniya (дата обращения: 19.06.2026).
22. Козьминых, С. И. Моделирование обеспечения информационной безопасности объекта кредитно-финансовой сферы / С. И. Козьминых. — Текст: непосредственный // Финансы: теория и практика. — 2018. — № 5.