:::::: ЧОУ ДПО «Центр предпринимательских рисков» :::::

Проектирование приложений распределенных БД с многоуровневым доступом

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

Уровень безопасности информационных систем зачастую находится в обратной зависимости от эффективности обработки данных и тактико-технических показателей. С учетом усложнения информационных технологий (ИТ), упомянутая дилемма ставит вопрос о пороге сложности, по достижении которого при сохранении существующих принципов проектирования невозможно создание систем с достаточным уровнем гарантий безопасности. В сложившейся ситуации для создания критичных систем важно наметить пути, позволяющие отказаться от предъявления ко всем системообразующим компонентам одинаковых требований по защите информации.

В статье рассматриваются вопросы построения многоуровневых информационных систем на примере СУБД Oracle. СУБД образуют ядро автоматизации большинства процессов обработки данных и обладают наиболее сложными моделями защиты. Использование механизмов защиты СУБД для некоторых критичных систем оказывается затруднительным ввиду проблем обеспечением целостности данных и скрытых каналов утечки информации [1]. Кроме того, сертифицированные многоуровневые СУБД очень дороги и зачастую не обладают достаточной эффективностью для создания современных, технологически совершенных систем. По указанным причинам проработку вопросов применения зарубежных СУБД для критичных систем, разрабатываемых в интересах государственных структур РФ, следует отнести к актуальным и своевременным задачам.

Что такое СУБД с многоуровневым доступом?

Упрощенно можно определить СУБД с многоуровневым доступом как такую СУБД, в которой доступ к информации предоставляется на основе формальных признаков, присущих субъектам (пользователям) и объектам (таблицам, представлениям, исполнимым процедурам). Формальные признаки фиксированы, чем в известной степени обеспечивается защита от прямой утечки информации между уровнями доступа за счет не декларируемых возможностей (НДВ) в приложениях. Данные всех уровней хранятся в единой многоуровневой базе (Multilevel Database), к которой обращаются пользователи, обладающие формальными полномочиями для доступа к информации соответствующего уровня секретности (High и Low User). Примером СУБД, реализующей политику многоуровневого доступа, является Trusted Oracle, сертифицированная NSA¹ на соответствие классу B1 Оранжевой книги (ОК) [2]. Многоуровневые СУБД снимают с приложений заботу о разграничении доступа к разделяемым ресурсам, однако возможности такой защиты могут быть ограничены [3].

Организация доступа к многоуровневой БД в изолированном режиме

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

Рассмотрим один из методов построения многоуровневых систем с помощью недоверенных СУБД², предоставляющих нужные функции по обработке и хранению данных. При использовании недоверенных СУБД возможно разделить данные на изолированные уровни с помощью дополнительных средств, внешних по отношению к СУБД. Данные высокого и низкого уровней секретности локализуются в разных сегментах БД (High Database и Low Database), не взаимодействующих друг с другом напрямую. Пользователи с высоким и низким уровнем доступа (High User и Low User) обращаются к сегментам, используя разные процессы (High DBMS Process и Low DBMS Process). Процесс с низким уровнем доступа может взаимодействовать с сегментом БД низкого уровня секретности, в то время как процесс с высоким уровнем доступа обращается к обоим сегментам БД.

В рассмотренной системе сегменты БД разных уровней функционируют изолированно, чем исключается НСД между уровнями. Однако такую систему правильнее считать не многоуровневой БД, а совокупностью одноуровневых БД. По принятой в [4] классификации такой режим обработки именуется compartment mode.

Распределенные системы с многоуровневым доступом на основе СУБД Oracle

Развитым средством построения распределенных БД на основе СУБД Oracle является репликация, представляющая собой комплекс средств поддержки синхронизированного состояния данных в нескольких территориально разнесенных сегментах распределенной БД. Изменения, производимые в одном сегменте БД, сохраняются локально и затем направляются в другие сегменты БД. Различные объекты (таблицы) БД объединены в группы (Replication Group), каждая из которых находится в некотором сегменте (Master Site) БД. Использование репликации повышает производительность приложений БД. Для обеспечения защищенности подобной системы необходимо контролировать поток данных между сегментами БД с различным уровнем секретности, так чтобы не произошло передачи информации более высокого уровня на более низкий уровень. Подобный контроль предполагает внедрение в процесс взаимодействия посредника (шлюза безопасности), через который осуществляется взаимодействие компонентов приложений различных сегментов БД.

Сетевая архитектура СУБД Oracle включает отдельные стеки протоколов взаимодействия на сторонах клиента и сервера: Client Side Stack и Server Side Stack. Их можно разбить на две части: протоколы удаленной СУБД (RDBMS) и сетевой службы Oracle Net8. СУБД Oracle обладает двумя программными интерфейсами: интерфейсом вызовов OCI (Oracle Call Interface) и интерфейсом программирования OPI (Oracle Program Interface). Они располагаются на вершине стека протоколов и используются непосредственно клиентским и серверным программным обеспечением (Client Application и Oracle Server). Далее в стеке протоколов расположены протоколы Oracle более низкого уровня – протоколы представления (протокол Two Task Common), интерфейсные NI (Network Interface) и сеансовые NS (Network Session). Все сетевое взаимодействие при репликации осуществляется средствами Oracle, и контроль данных между сегментами затруднен. СУБД Oracle не предоставляет возможностей замены реализаций каких-либо из этих протоколов внешними сертифицированными реализациями. Контроль потоков данных между сегментами на уровне сетевых протоколов, используемых Oracle, также представляется затруднительным. Таким образом, обнаружение и предотвращение попыток несанкционированной передачи данных между сегментами БД разного уровня секретности оказывается невозможным, что не позволяет обойтись встроенными механизмами репликации Oracle для построения распределенной СУБД с многоуровневым доступом.

Для организации сетевого взаимодействия в СУБД Oracle можно воспользоваться хранимыми процедурами PL/SQL или Java. Такие процедуры вызываются и выполняются внутри БД и имеют доступ ко всем ее объектам. Хранимые процедуры могут открывать сетевые соединения с другими серверами и обмениваться с ними данными, что позволяет организовать передачу информации из одной БД в другую. Набор и функциональность хранимых процедур для построения распределенного взаимодействия полностью определяются предметной областью, причем такое взаимодействие можно контролировать доверенными приложениями. Однако СУБД, организованную по описанному принципу, при всех достоинствах, связанных с возможностью организации контроля потоков между сегментами, можно назвать распределенной лишь условно. Разработка такой системы сопряжена со значительными затратами на организацию и поддержку собственных протоколов передачи запросов и данных больших объемов.

Альтернатива обеспечения сетевого взаимодействия для распределенных БД с многоуровневым доступом состоит в использовании механизма связей БД (database link). Связь БД – это соединение между двумя серверами БД, которое позволяет обращаться к ним как к единой логической сущности. Связь БД представляет собой указатель, определяющий коммуникационный маршрут от одного сервера БД к другому серверу. Связь базы данных однонаправлена. Для организации обращения пользователей сегмента БД с более высоким уровнем секретности к другому сегменту нужно обеспечить соответствующую сегментную связь. В этом случае данные из сегмента БД с более низким уровнем секретности можно использовать так же, как и данные сегмента высокого уровня секретности. Обращение же к сегменту с более высоким уровнем без создания соответствующей связи останется невозможным.

В случае гомогенной среды, целиком ориентированной на СУБД Oracle, взаимодействие между сегментами БД осуществляется средствами Oracle, при этом, как и в случае с репликацией данных, отсутствуют возможности контроля такого взаимодействия внешними доверенными приложениями. Однако Oracle обладает средствами организации гетерогенных БД с использованием СУБД других производителей (в том числе сертифицированных в РФ³). Эти средства позволяют создать связь базы данных с использованием протоколов взаимодействия, отличных от внутренних протоколов Oracle, что дает возможность контролировать потоки данных с помощью доверенных приложений.

Для построения гетерогенных систем СУБД Oracle предоставляет технологию Transparent Gateway для обращения сервера Oracle к внешней системе. Сервер БД Oracle взаимодействует с агентом, который, в свою очередь, взаимодействует с внешним приложением. Для каждой конкретной СУБД необходим свой тип агента, некоторые из них включены в дистрибутив Oracle. Для разработки собственного агента можно использовать общедоступный интерфейс программирования ODBC (Open Database Connectivity). Таким образом, для взаимодействия с удаленным сегментом данных Oracle будет использовать предоставленный ей шлюз, что позволит полностью контролировать это взаимодействие.

СУБД Oracle обращается к внешней системе (Non-Oracle system) с помощью компонента, отвечающего за ODBC взаимодействие в гетерогенных системах (HS ODBC agent). Этот компонент с помощью драйвера ODBC обращается к клиенту внешнего приложения (NonOracle system client), который может взаимодействовать с сегментом БД, локализованным в другом сервере БД. Для обращения к нелокальному сегменту можно использовать интерфейсы программирования ODBC или JDBC, при этом клиент, являясь доверенным приложением, будет выполнять функции программного шлюза между сегментами распределенной БД и полностью контролировать взаимодействие этих сегментов.

Для организации распределенных систем с многоуровневым доступом на базе СУБД Oracle предлагается воспользоваться принципами, приведенными на рисунке:

размещать данные разных уровней в отдельных сегментах распределенной БД Oracle;
создавать связи базы данных (database links) для обращения к данным более низкого уровня;
контролировать данные с помощью шлюзов между сегментами распределенной БД;
используя Oracle Transparent Gateway, маршрутизировать связи БД на доверенные программные шлюзы через ODBC;
обращаться к сегментам БД из шлюзов с помощью программных вызовов ODBC;
изолировать сегменты БД в ЛВС.

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

Скрытые каналы в СУБД с многоуровневым доступом

Предложенная модель распределенной БД с многоуровневым доступом позволяет исключить явную передачу данных из сегментов более высокого уровня секретности в сегменты более низкого уровня. Данная задача не представляет проблем в реализации. Однако существует возможность организации скрытого канала передачи информации, который позволил бы сегментам БД обмениваться данными неявным образом. Скрытый канал (Covert Channel) – это канал утечки информации, использующий общие технические или информационные ресурсы, к числу которых можно отнести информационные объекты сегментов низкого уровня секретности, а также связи БД. Существует два типа скрытых каналов: каналы, использующие временные механизмы (Covert timing channels), и каналы на основе механизмов хранения данных (Covert storage channels).

Для организации скрытого канала с использованием временных механизмов используется модуляция состояния ресурсов, разделяемых всеми сегментами. В предложенной системе параметрами для создания такого скрытого канала могут являться частота и вид межсегментных запросов (Select, Update, Insert или Delete), количество и наименования таблиц и их атрибутов, участвующих в запросе.

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

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

В заключение хотелось бы отметить, что предложенная методология построения СЗИ распределенных БД с многоуровневым доступом замыкается не на поставщика СУБД, а на разработчика конкретной системы. То есть включение в систему НДВ для несанкционированного доступа к данным может быть выполнено только при условии детального знакомства потенциального нарушителя с предметной областью, что практически невозможно. Предложенный подход в целом обеспечивает относительно высокие гарантии защиты информации для систем, где допускается присутствие нарушителя не выше 4-го уровня согласно классификации Гостехкомиссии РФ [5].

2. Department of Defence Trusted Computer Evaluated Criteria, DoD 5200.28-STD, Washington -1986.

4. National Computer Security Center. NCSCTG11. Trusted network Interpretation environments Guideline. USA P. 40. – 1990.

5. Руководящий документ Гостехкомиссии РФ. Концепция защиты информации от НСД в СВТ и АС.

1 National Security Agency – организация, являющаяся в США органом сертификации информационных технологий по требованиям безопасности информации.

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

3 К таковым относится, например, СУБД ЛИНТЕР-ВС 6.0, разработанная НПО «РЕЛЕКС» и сертфицированная в системе сертификации Гостехкомиссии РФ.