Использование возможностей субд «Ред База данных» 2. 1 для защиты информации в банковской сфере Текст научной статьи по специальности «Компьютерные и информационные науки»

использование возможностей субд «ред база данных» 2.1 для защиты информации в банковской сфере

© СТАРОДУБОВ Дмитрий Николаевич

кандидат технических наук, доцент кафедры «Информационные системы» Муромского института (филиала) Владимирского государственного университета.

@ +7 (920) 624-13-92, И [email protected]

Г

© СИМАКОВ Роман Александрович

кандидат технических наук, доцент кафедры «Информационные системы» Муромского института (филиала) Владимирского государственного университета.

Ш +7 (920) 900-65-02, Ш [email protected]

В статье описаны проблемы защиты от несанкционированного доступа к конфиденциальным данным, возникающие в сфере банковского обслуживания, а также способы их решения на основе механизма безопасности, разработанного в СУБД «Ред База Данных» 2.1.

Ключевые слова: защищённая информационная система, база данных, несанкционированный доступ, безопасность.

Сг

Чпецифика информации, обрабатываемой в банковской сфере, предъявляет повышенные требования к надёжности и безопасности используемых хранилищ данных. Особенно это касается предотвращения нежелательного доступа к персональным данным, что с недавних пор строго регулируется законодательством.

Федеральный закон Российской Федерации от 27 июля 2006 г. № 152-ФЗ «О персональных данных», вступивший в силу 8 августа 2006 г., предусматривает, что информационные системы

персональных данных должны быть приведены в соответствие с требованиями этого закона не позднее 1 января 2010 г. [1].

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

Пример схемы построения банковского хранилища приведен на рис. 1. Накопление и обработка информации начинается с АБС -

Репликатор

Исходные* таблицы

Сегменты

БД источников

Промежуточный этап. Очистка, верификации и объединение дэннык из внешних систем в формат, принятый а Хранилище.

Рис. 1. Схема информационной системы банковского хранилища данных

автоматизированной банковской системы (Way4, RBS, Quorum и т.д). Это OLTP-системы, предназначенные для оперативной обработки данных и автоматизации банковской деятельности. Их данные являются исходными для аналитических отчётов, в том числе обязательных, требуемых ЦБ. Исходные данные из разных филиалов и головного банка от различных АБС объединяются в БД источников, для чего используется специальное приложение - репликатор. При этом происходит очистка данных, верификация и приведение их к формату, принятому в хранилище.

Обработанные таким образом промежуточные данные реплицируются в рабочую БД хранилища, где они преобразуются в избыточное многомерное представление, удобное для работы аналитической системы (OLAP).

Доступ к данным хранилища осуществляется через специальное клиентское ПО, в данном случае - через Web-интерфейс с использованием Red Olap Navigator. С его помощью могут строиться как отчёты и формы ЦБ, обязательные для каждого банка, так и произвольные OLAP-запросы, используемые аналитическим отделом банка для оценки состояния компании.

Информационная безопасность регионов. 2010. № 1 (6)

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

- надежное хранение используемых данных;

- разделение доступа к данным разных филиалов;

- обеспечение безвозвратного удаления уже не используемой информации;

- регистрация любых запросов к базе данных.

Разделение доступа к данным филиалов

Типичной практикой является предоставление доступа сотрудникам банка только к тем данным, которые им необходимы для работы. Многие банки имеют сеть филиалов, данные из которых периодически синхронизируются, образуя единую базу данных. Аналитические отчёты, которые используются в процессе работы, например, «Оборотная ведомость по счетам бухгалтерского учёта кредитной организации» или «Отчёт об операциях с наличной иностранной валютой и чеками в иностранной валюте», строятся в разрезе филиалов их сотрудниками. Для создания подобных отчётов обычным сотрудникам необходимы сведения только из их собственного филиала, что приводит к необходимости фильтрации записей из таблиц БД.

Ограничение доступа пользователей к отдельным строкам таблиц - Row Level Security поддерживается немногими СУБД, поэтому традиционно такая задача решается программированием на стороне сервера БД, например, созданием специальных хранимых процедур или представлений (просмотров, VIEW), которые будут использоваться для получения данных из базы вместо таблиц. Такой способ не совсем удобен и предполагает изменение логики работы приложения и текста запросов к БД, что требует переработки клиентского приложения и не всегда легко осуществимо.

СУБД «Ред База Данных» (основанная на исходном коде открытой СУБД Firebird) начиная с версии 2.1 поддерживает механизм Row Level Security и имеет возможность фильтрации записей системного каталога, работает непосредственно в ядерной составляющей сервера. Это гарантирует, что пользователь, подключившись к базе данных, применяя любые запросы, увидит только те данные, которые позволит получить соответствующим образом настроенный фильтр.

На практике существуют пользователи, имеющие доступ к данным одного, нескольких

и всех филиалов. В таком случае для разграничения прав на данные удобно использовать механизм ролей. В базе данных создается набор ролей, описывающих типичные права доступа. Для связи ролей с правами доступа к данным филиалов в БД создается таблица RIGHTS(ROLE_ NAME, FILIAL_NAME).

Для каждого сотрудника банка создаётся пользователь базы данных, которому затем назначается одна или несколько ролей. После этого в таблицах, содержащих данные, доступ к которым должен быть ограничен, создаётся фильтр записей запросом вида: ALTER TABLE SOME_TABLE SET RECFILTER (

new.FILIAL_NAME in ( select distinct T.FILIAL_NAME from SOME_TABLE T

join RIGHTS R on

R.FILIAL_NAME = T.FILIAL_NAME join RDB$USER_PRIVILEGES P on P.RDB$USER = CURRENT_USER and P.RDB$PRIVILEGE = 'M' and R.ROLE_NAME = P.RDB$RELATION_

NAME

)

)

Поскольку фильтр записей представляет собой автоматически создаваемый триггер, то при его создании используется ключевое слово NEW, с помощью которого осуществляется доступ к полям таблицы.

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

В СУБД «Ред База Данных» 2.1 существует также механизм, позволяющий ограничивать выборку данных по столбцам - COLFILTER. Он позволяет задавать условия, определяющие наличие столбцов в результирующем наборе. Например, следующий фильтр будет отображать поле CLIENT_ID из таблицы ACCOUNTS только для пользователя MANAGER. Остальные пользователи будут видеть все поля, кроме CLIENT_ID.

ALTER TABLE ACCOUNTS SET COLFILTER

TEST_FIELD (CURRENT_USER='TEST_ USER')

Назначение такого фильтра позволяет обрабатывать данные о счетах клиентов независимо от их личных данных, получая таким образом статистические отчёты, при вычислении кото-

рых персональные данные клиентов не важны и могут быть проигнорированы.

Таким образом, использование фильтра записей и фильтра полей позволяет разграничить права доступа к данным на стороне сервера без изменения клиентского приложения, что может быть наилучшим способом доработки уже существующего хранилища данных.

Очистка освобождаемых областей памяти

Фильтры записей и полей позволяют управлять доступом к данным на уровне СУБД, но, кроме того, требуется ограничить возможность доступа на уровне операционной системы, то есть запретить непосредственный доступ к файлу базы данных или данным в оперативной памяти сервера. Такой доступ разграничивается средствами защиты ОС и используемой файловой системы. Например, в ишх-подобных ОС сервер запускается от имени специально созданного пользователя и права на чтение / запись файлов всех создаваемых баз данных есть только у него. Иногда этого недостаточно и доступ к информации из БД может быть получен анализом тех областей оперативной памяти или жёсткого диска, которые использовались СУБД в процессе работы. Как известно, ни данные в оперативной памяти, ни файлы на внешних накопителях не очищаются физически при освобождении памяти/удалении файла.

Поэтому возникает требование обезличивания освобождаемых областей оперативной памяти ЭВМ и внешних накопителей, описанное в руководящем документе «Автоматизированные системы. Защита от несанкционированного доступа к информации» [2, с. 22].

СУБД «Ред База Данных» 2.1 обеспечивает такую очистку при включении параметра конфигурации MemoryWipePasses, который задаёт количество проходов обезличивания. Возможные значения данного параметра:

0 - обезличивания не происходит (по умолчанию);

1 - освобождаемая память заполняется нулями;

>1 - происходит чередование записи 0xFF и 0x00 в память, последний проход при этом обнуляет блок.

При удалении файла базы данных очищается область на жёстком диске, которую он занимал. В данном случае область сначала записывается нулями, затем - единицами и при третьем проходе - случайными данными. Кроме того, файл перед удалением некоторое количество раз переименовывается, чтобы его исходное имя стёрлось из журнала транзакция файловой системы.

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

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

Регистрация доступа к данным

Ведение журнала запросов осуществляется с помощью инструмента FBTrace, который появился в СУБД «Ред База Данных» начиная с версии 2.0 и был портирован в открытую СУБД Firebird версии 2.5. Он позволяет вести лог-файлы активности пользователей в базе данных, задавая различные виды регистрируемых событий в файле fbtrace.conf [3].

При использовании схемы хранилища, приведённой на рис. 1, настраивается аудит рабочей БД, используемой системой OLAP для построения аналитических запросов. При этом регистрируются следующие события:

- подключение к БД: сохраняются имя пользователя, адрес его компьютера, путь к БД, протокол подключения;

- выполнение запроса: сохраняются сведения о подключении, параметры транзакции, текст запроса, время его выполнения;

- выполнение хранимой процедуры: сохраняются сведения о подключении, параметры транзакции, название процедуры, переданные ей параметры, время выполнения.

Регистрация подобного перечня событий позволяет не только выявлять случаи нетипичного доступа сотрудников к данным, но и определять «медленные» запросы, выполняющиеся слишком долго и способные значительно затруднить работу с отчётами. Обычно такие запросы могут быть заметно ускорены с помощью создания индексов в используемых таблицах.

Заключение

Применение СУБД «Ред База Данных 2.1» в совокупности со средствами репликации и Red Olap Navigator для построения отчётов через Web-интерфейс позволяет построить не только информационную систему, удовлетворяющую всем требованиям по обработке данных, но и обеспечить надёжную защиту персональных и других данных от всех видов несанкционированного доступа, детальный учёт событий, происходящих в системе, абсолютное уничтожение уже использованных данных без возможности восстановления. Таким образом, благодаря внедрению средств защиты данных в ключевые звенья их обработки решается комплексная задача обеспечения безопасности

Информационная безопасность регионов. 2010. № 1 (6)

информационной системы, а, следовательно, всего банка в целом.

Библиографический список

1. Российская Федерация. Законы. О персональных данных [Текст] : Федер. закон : [принят Гос. Думой 6 июля 2006 г. : одобр. Советом Федерации 14 июля 2006 г.] // ИПС «КонсультантПлюс» (дата обращения: 22.03.2010).

2. Руководящий документ. Автоматизированные системы. Защита от несанкционирован-

ного доступа к информации. Классификация автоматизированных систем и требования по защите информации : [Текст] : [утв. 30 марта 1992 г]. - М.: ГТК РФ, 1992. 3. Симаков Р. А., Стародубов Д. Н. Аудит изменений в СУБД «Ред База Данных» // Информационная безопасность регионов. -2008. - № 2(3). - ISSN 1995-5731.

* КНИЖНАЯ ПОЛКА

Файл Правка Вид Избранное Сервис Справка fr

^ Назад т J j 1 Поиск Папки Q"]т

Астахов А. Искусство управления информационными рисками. - М.: ДМК Пресс, GlobalTrust, 2010. - ISBN 5-94074-574-1; 978-5-94074-574-7.

Книга генерального директора GlobalTrust А. Астахова «Искусство управления информационными рисками» предоставляет возможность познакомиться с основами управления рисками информационной безопасности.

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

Весьма полезен материал, вынесенный автором в приложения к монографии:

- перечень законодательных и нормативных актов Российской Федерации в области защиты информации;

- термины и определения в области управления информационными рисками;

- взаимосвязь между стандартами ISO/IEC 27001:2005, BS 7799-3:2006 и ISO/IEC 27005:2008;

- русские редакции международных стандартов по информационной безопасности;

- антология кибератак; наихудшие сценарии кибератак; перечень типовых угроз информационной безопасности; перечень типовых уязвимостей информационной безопасности;

- программные продукты для управления рисками информационной безопасности.

Книга ориентирована на специалистов по информационной безопасности, специалистов информационных технологий и риск-менеджеров. Монография будет полезна руководителям компаний, менеджерам всех уровней, имеющим отношение к подготовке и принятию решений по рискам, аудиторам, а также широкому кругу читателей, интересующихся вопросами управления рисками, информационными технологиями и связанными с ними угрозами.

Глубина и обстоятельность изложения материала позволяет использовать книгу в качестве учебного пособия для высших учебных заведений и учреждений послевузовского профессионального образования.

Искусство управления

информационными

рисками

г^я

а»