Смена СУБД
Январь, 2017
Информационная инфраструктура практически каждого банка содержит базы данных со сведениями, составляющими коммерческую и банковскую тайну, а также персональными данными. Значительное количество хранилищ работает под управлением Oracle — одной из самых распространённых СУБД, зарекомендовавших себя по надёжности, масштабируемости и удобству работы. Предлагаемый в статье подход позволяет минимизировать потери данных, времени и средств при решении одной из главных задач информационного противостояния — предотвращения утечек критически важной для банков информации за рубеж.
Трудности перехода
Тенденция скорейшего перехода с Oracle на платформу неамериканского происхождения набирает обороты, но трудностей столько, что их перечисление заняло бы всё место статьи. Подобрать полноценную замену по функционалу, масштабируемости, надёжности, доступности, отказоустойчивости и поддержке платформ затруднительно; есть недостаток квалифицированных разработчиков и специалистов по сопровождению. К тому же из всех распространённых СУБД именно в Oracle штатно встроен самый полный набор сервисов безопасности — другие, включая отечественные, существенно отстают.
Парк информационных систем банков — это огромное количество информации и кода, написанного поколениями программистов. Перенос данных “в лоб” зачастую невозможен: новая СУБД может не уметь обрабатывать некоторые типы данных, а миграция предполагает полную ревизию и изменение практически всего кода — “автоматизированные процедуры” миграции от производителей не спасают. Например, широко распространённый процессинг OpenWay написан в основном на процедурном языке Oracle PL/SQL: банк, который всё перепишет, получит поддержку ПО как свою “головную боль” без обновлений от производителя, и не каждая организация может содержать штат для столь масштабных работ.
Ищем варианты
Подход “разрушим до основания” себя не оправдывает. Основная идея импортозамещения — не в “освоении бюджетов” на быстрое создание российских ОС и СУБД, а в обеспечении безопасности информационных систем, базирующихся на импортных программах: уместно говорить не только о надёжности компонентов, но и о конфиденциальности циркулирующей в банках информации. Иностранные программы нередко “грешат” закладками, поэтому логично в первую очередь оснастить систему сертифицированными отечественными средствами защиты, в том числе для “введения в заблуждение” возможных закладок методами, неизвестными существующему ПО.
Подход с гарантией
Самый очевидный пример — шифрование по российским криптографическим алгоритмам. Внедрение должно идти поэтапно, с поиском возможных уязвостей: начать с совершенствования или полной замены штатных механизмов аутентификации, затем защитить каналы передачи данных между серверной и клиентской частями СУБД и, наконец, данные в хранилище. Такой подход и грамотная эксплуатация дают гарантию безопасности на значительном временном отрезке — в течение которого можно ожидать появления отечественного инфраструктурного ПО.
Рынок не беден
На рынке много предложений по сертифицированным средствам аутентификации (включая аппаратные, адаптируемые под разные СУБД) и средствам защиты каналов. Из средств защиты баз данных с российской криптографией известно одно — программно-аппаратный комплекс “Крипто БД” компании Аладдин Наложенное средство защиты для существующих систем, комплекс решает широкий спектр задач: прежде всего шифрование данных в столбцах таблиц, надёжную защиту ключей шифрования (в том числе аппаратными носителями), а также формирование и проверку электронной подписи, включая новые ГОСТ 34.10-2012 и 34.11-2012, распределение ключей и собственно шифрование по ГОСТ Р 28147-89 и ГОСТ Р 34.12-2015. Последняя версия поддерживает Oracle, MSSQL, Tibero и PostgreSQL; проведены тематические исследования, экспертиза результатов идёт в ФСБ России.
Коварный фактор
Банки опасаются внедрять средства, связанные с шифрованием, из-за двух рисков: полная потеря данных при утере ключа и деградация производительности. Первый фактор субъективен — строгое следование инструкциям по резервному копированию ключей сводит риск к нулю. Второй коварнее, поэтому каждое внедрение “Крипто БД” предваряется пилотным проектом. Тестирование на процессинге Way4 в крупном столичном банке не выявило заметных задержек при работе оператора с базой (включая поиск по зашифрованным данным); массовые операции (пакетные загрузки/выгрузки, начисления) показали временные потери в пределах 10%, а самая трудоёмкая операция “закрытие операционного дня” — до 40%, что приемлемо для разовых операций.
Предлагаемый подход реализует основную идею импортозамещения — безопасную работу критичных для организации систем; банки, заботящиеся о сохранности данных, приглашаются к пилотированию через широкую сеть партнёров.
Это краткая аннотация статьи, полную версию читайте в первоисточнике.
Первоисточник: “BIS Journal”, № 1(24), январь, 2017
Эксперт: Александр Додохов, Алексей Сабанов, Аладдин