Информационная инфраструктура практически каждого банка имеет в своём составе базы данных, содержащих сведения, составляющие коммерческую и банковскую тайну, а также персональные данные. Значительное количество хранилищ данных функционирует под управлением СУБД Oracle, как одной из самых распространённых и зарекомендовавших себя с наилучшей стороны. Как по надёжности и масштабируемости, так и по удобству работы. Использование подхода, предлагаемого в статье, позволит минимизировать потери данных, времени и финансовых средств при решении одной из главных задач информационного противостояния – предотвращения утечек критически важной для банков информации за рубеж.
ТРУДНОСТИ ПЕРЕХОДА
Тенденция на скорейший переход с широко применяющейся СУБД Oracle на платформу неамериканского происхождения продолжает набирать обороты. Трудностей перехода настолько много, что их перечисление займёт всё отведённое на статью место. Приведём только некоторые из наиболее существенных.
Во-первых, подобрать полноценную замену по базовому функционалу, масштабируемости, надёжности, доступности, отказоустойчивости, поддержке определённого набора аппаратных платформ и программного обеспечения достаточно затруднительно. Во-вторых, существует недостаток квалифицированных разработчиков и специалистов по сопровождению. Как правило, СУБД используется в виде ключевого компонента в прикладных системах. Эти и некоторые другие проблемы выбора для миграции целевых СУБД достаточно полно были рассмотрены ранее [1]. Кроме того, как показано в исследовании [2], из всех наиболее распространённых СУБД в Oracle штатным образом встроен самый полный набор сервисов безопасности. Другие СУБД, в том числе и отечественного производства, существенно отстают. Но проблема замещения программного обеспечения зарубежного производства состоит не только в отсутствии встроенных в СУБД и одобренных отечественными регуляторами механизмов защиты информации.
Эксплуатируемый в настоящее время парк информационных систем банков – это огромное количество хранящейся информации и кода, написанного за долгие годы поколениями программистов. Перенос данных в иную СУБД "в лоб" зачастую просто невозможен, так как СУБД может попросту не иметь возможности обрабатывать некоторые типы данных из другой [1]. Как правило, миграция данных на новую программную платформу предполагает полную ревизию и изменение практически всего объёма кода. От подобной работы не спасают даже декларируемые многими производителями СУБД "автоматизированные процедуры" миграции. Но и это только "вершина айсберга".
Например, широко распространённое программное обеспечение процессинга от компании OpenWay написано, в основном, на PL/SQL – процедурном языке Oracle. Предположим, нашёлся банк, который всё это переписал и стал работать в другой программной среде. Понятно, что теперь поддержка программного обеспечения является "головной болью" самого банка, и рассчитывать на обновления и поддержку от производителя в данном случае глупо. Кроме того, не каждая организация может позволить себе содержать штат сотрудников для столь масштабных работ.
ИЩЕМ ВАРИАНТЫ
Вместе с тем необходимо отметить, что подход "разрушим до основания, а затем…" себя не оправдывает и нужно попытаться найти иные, более приемлемые варианты снижения зависимости от иностранных производителей. Ведь основная идея импортозамещения заключается не в "освоении бюджетов" на быстрое создание российских ОС, СУБД и других программных продуктов, а в обеспечении безопасности информационных систем, базирующихся на импортных программах. В данном случае уместно говорить не только о надёжности программного и аппаратного компонентов информационной инфраструктуры, но и об обеспечении информационной безопасности, прежде всего конфиденциальности циркулирующей в информационных системах банковской информации.
Важность обеспечения безопасности информации в государственных информационных системах, в том числе в финансовом секторе, не вызывает сомнений. И не секрет, что программы иностранного производства зачастую "грешат" закладками и прочими неприятными особенностями. Логично было бы в первую очередь обеспечить оснащение информационной системы набором средств защиты информации отечественного производства, прошедших соответствующую проверку. Применение данных "наложенных" средств должно быть направлено, в том числе, и на "введение в заблуждение" возможных закладок путём применения методов, неизвестных для существующего программного обеспечения.
ПОДХОД С ГАРАНТИЕЙ
Самый очевидный пример – применение шифрования с использованием российских криптографических алгоритмов. Внедрение средств защиты должно проходить поэтапно, с обязательным поиском в них возможных уязвимостей. И начинать следует с совершенствования или даже полной замены в СУБД штатных механизмов аутентификации. Далее необходимо обеспечить защиту каналов передачи данных между серверной и клиентской частью СУБД – потребителями и поставщиками информации. И, наконец, защитить данные в хранилище. Такой подход к построению защиты информационной системы и её "грамотная" эксплуатация могут дать гарантию безопасности обрабатываемой информации на значительном временном отрезке, в течение которого можно будет ожидать появления отечественного инфраструктурного программного обеспечения.
РЫНОК НЕ БЕДЕН
В настоящее время на рынке имеется много предложений от производителей по сертифицированным средствам аутентификации, в том числе аппаратным, которые могут быть адаптированы для работы с различными СУБД. Достаточно широко представлены средства защиты каналов передачи данных. Вместе с тем, из средств защиты баз данных, использующих российские криптографические алгоритмы, известно только одно – программно-аппаратный комплекс "Крипто БД" компании "Аладдин Р.Д.". Являясь наложенным средством защиты информации, предназначенным для внедрения в существующие информационные системы, комплекс "Крипто БД" решает широкий спектр задач. Прежде всего – шифрование данных, содержащихся в столбцах таблиц баз данных. Кроме того, комплекс обеспечивает надёжную защиту ключей шифрования, в том числе с помощью аппаратных ключевых носителей.
Первая версия комплекса "Крипто БД" была сертифицирована по требованиям ФСБ РФ в 2010 году, а затем срок действия сертификата был продлён в соответствии с правилами системы сертификации. Впоследствии, в рамках развития комплекса в соответствии с пожеланиями заказчиков появлялись новые функциональные возможности. Последняя версия комплекса "Крипто БД" поддерживает шифрование в таких СУБД, как Oracle, MSSQL, Tibero и PostgreSQL. В комплексе реализовано формирование и проверка электронной подписи, в том числе по недавно введённым ГОСТ 34.10-2012, ГОСТ 34.11-2012 для распределения ключей шифрования, а также собственно шифрование данных с помощью симметричных алгоритмов по ГОСТ Р 28147-89 и ГОСТ Р 34.12-2015. Кроме того, при создании комплекса были учтены все известные рекомендации профильных комитетов по стандартизации. В настоящее время выполнены тематические исследования комплекса "Крипто БД" и проводится экспертиза их результатов в ФСБ России.
КОВАРНЫЙ ФАКТОР
Необходимо отметить, что организации, прежде всего финансовые структуры, банки, опасаются внедрять средства защиты, связанные с шифрованием данных. Опасения связаны главным образом с двумя факторами: риском полной потери данных при утере ключа шифрования и риском значительной деградации производительности информационной системы в целом. Первый фактор достаточно субъективный: строго выполняя приложенные к продукту инструкции по резервному копированию ключей шифрования, риск потери данных сводится к нулю. Второй фактор более коварный: пока владелец информации лично не убедится в том, что производительность его самой важной информационной системы не пострадает, он будет относиться к любым заверениям настороженно. Именно поэтому каждое внедрение комплекса "Крипто БД" предваряется пилотным проектом, в течение которого отрабатывается функционирование информационной системы с использованием шифрования зашифрованных данных и оценивается её производительность. Например, тестирование комплекса "Крипто БД" на процессинге Way4 в одном из крупных столичных банков не выявило заметных задержек при работе оператора с базой данных, в том числе при выполнении поиска по зашифрованным данным. Тестирование массовых операций класса пакетных загрузок/выгрузок, массовых начислений и пр. показало временные потери в пределах 10%. В самой трудоёмкой операции "закрытие операционного дня" максимальная временная задержка составляла до 40%. Безусловно, последняя цифра весьма приличная, но и она является приемлемой для разовых операций. Приглашаем банки, заботящиеся о сохранности своих данных, к пилотированию и внедрению с помощью широкой сети партнёров.
Подводя краткий итог, можно сказать, что предлагаемый подход к внедрению отечественных средств защиты информации в СУБД иностранного производства реализует основную идею импортозамещения – обеспечение безопасной работы информационных систем, критичных для деятельности организации. Ну и, конечно, будем ждать от наших разработчиков достойных аналогов известных СУБД.
Литература
Муравьев С., Дворянкин С., Насенков И. СУБД: проблема выбора // http://www.osp.ru/os/2015/01/13045322
Додохов А.Л., Сабанов А.Г. Исследование применения СУБД Oracle для защиты персональных данных // Доклады Томского государственного университета систем управления и радиоэлектроники. 2011. №2(24). С.267-270.
- Стоимость медиауслуг (открыть PDF) -
