Различные СУБД могут широко использоваться в ключевых системах информационной инфраструктуры, но при этом необходимо иметь в виду, что требования к программно-технической реализации таких систем отличаются приоритетом надежности информационных процессов и их защищенности от несанкционированного доступа над функциональностью. Понятие критически важного сегмента информационной инфраструктуры определено в утвержденном зам. директора ФСТЭК России 18 мая 2007 г. Руководящем Документе ФСТЭК России «Общие требования по обеспечению безопасности информации в ключевых системах информационной инфраструктуры» (кратко – ОТ в КСИИ). Это составная часть инфраструктуры РФ, в которой имеются информационные и информационно-телекоммуникационные системы отраслей (отрасли) экономики или хозяйства страны, прекращение или нарушение функционирования которых может привести к чрезвычайной ситуации или к значительным негативным последствиям. Критически важный сегмент может содержать кроме критически важных не относящиеся к критически важным системы.
Такие критически важные системы получили специальное название ключевых систем информационной инфраструктуры (КСИИ). Тот же Руководящий Документ определяет их как информационно-управляющие или информационно-телекоммуникационные системы, которые осуществляют управление или информационное обеспечение критическим объектом или процессом, или используются для официального информирования общества и граждан, нарушение или прерывание функционирования которых (в результате деструктивных информационных воздействий, а также сбоев или отказов) может привести к чрезвычайной ситуации со значительными негативными последствиями. Критически важный объект же определен в этом документе как объект, оказывающий существенное влияние на национальную безопасность РФ, прекращение или нарушение функционирования которого приводит к чрезвычайной ситуации или к значительным негативным последствиям для обороны, безопасности, международных отношений, экономики, другой сферы хозяйства или инфраструктуры страны, либо для жизнедеятельности населения, проживающего на соответствующей территории, на длительный период времени. Родственное этому понятию критически важного объекта понятие критического объекта появилось в ГОСТ Р 53114-2008 – Национальный стандарт РФ «Защита информации. Обеспечение информационной безопасности в организации. Основные термины и определения». В нем критический объект означает объект или процесс, нарушение непрерывности функционирования которого может нанести значительный ущерб. А понятие КСИИ в нем представлено в том же виде, как и в Руководящем Документе ОТ в КСИИ.
Одним из концептуальных подходов к построению КСИИ с защитными механизмами, интегрированными в информационные процессы, является концепция эталонной автоматизированной системы обработки данных [2, 5, 7] в смысле эталонной модели защищенной автоматизированной системы (ЭМЗАС) [5, 8]. Преимущество ЭМЗАС применительно к КСИИ заключается в том, что эта модель позволяет соединить на уровне моделей политики безопасности неуязвимость информационных процессов в КСИИ в процессах хранения, передачи и обработки информации с достаточно высокой степенью гибкости защитных механизмов. Механизмом внедрения в критически важные сегменты информационной инфраструктуры РФ концепции автоматизированной системы обработки данных, эталонной в смысле ЭМЗАС, является организация расширяемой библиотеки ЭМЗАС-классов как строительного материала КСИИ. Библиотека ЭМЗАС-классов может создаваться как независимо от существующих программных платформ, так и на базе каких-либо из них.
Вопросы такого внедрения концепции автоматизированной системы обработки данных, эталонной в смысле ЭМЗАС, в плане организации многоуровневой авторизации посредством ролевого механизма управления доступом в КСИИ рассматривались в [6], а в плане организации контроля целостности информации в КСИИ – в [1].
Целью настоящей работы является математическое моделирование функционирования объектно-реляционной системы управления базами данных (СУБД) в КСИИ согласно концепции автоматизированной системы обработки данных, эталонной в смысле ЭМЗАС.
Использование указанной концепции применительно к СУБД приводит к понятию эталонной СУБД, функции которой в эталонной автоматизированной системе обработки данных относятся к трем соседним уровням ЭМЗАС: прикладному (№ 9), менеджерскому (№ 8) и информационному (№ 7). Эталонная СУБД призвана служить эталоном для перспективных СУБД критического применения, которыми можно считать СУБД третьего поколения, призванные преодолевать проблемы, присущие традиционным реляционным и объектным СУБД. Поддерживая произвольные запросы подобно традиционным реляционным, но не объектным СУБД, они должны справляться со всеми проблемными для реляционных СУБД разновидностями данных, поддерживаемыми объектными системами: мультимедийные, биологические, финансовые данные, данные временных рядов, инженерного проектирования, автоматизации делопроизводства и т.д. В настоящее время не существует общепринятого мнения насчет облика таких СУБД, но большинство специалистов и крупных поставщиков приняли в качестве аксиомы необходимость эволюционного развития систем, а именно совершенствования реляционных систем для включения в них положительных средств объектной технологии [3].
Этот подход приводит к трактовке СУБД третьего поколения как объектно-реляционных СУБД. Вопрос об их облике концептуально прояснился после выхода книги [10], называемой третьим Манифестом. Она носит «предписывающий» характер, содержит строгие, формальные и подробные технические предложения для выбора направлений развития СУБД и предлагает абстрактный план проектирования будущих СУБД и их языка на основе реляционной модели. Авторы книги считают, что в объектно-реляционной СУБД необходимо обеспечить просто надлежащую поддержку типов данных. Задаваясь вопросом: «Как включить надлежащую поддержку типов данных в реляционную модель?», они дают глубоко научно обоснованный ответ, замечательный по своей концептуальной простоте и однозначности – эта поддержка уже существует в форме доменов, фактически являющихся типами. Теория типов и реляционная модель в определенной степени независимы. Реляционная модель не предписывает поддержку конкретных типов, кроме логического, а лишь предусматривает поддержку некоторых (неопределенных) типов, требуя, чтобы атрибуты отношений имели некоторый тип. Облик эталонной СУБД можно определить как эталонную объектно-реляционную с архитектурой, удовлетворяющей концепции автоматизированной системы обработки данных, эталонной в смысле ЭМЗАС, и с функциональным наполнением объектно-реляционной СУБД в смысле [10].
Комплекс из пяти фактически известных моделей функционирования объектно-реляционной СУБД представлен в [4] в форме, дающей все предпосылки его использования при построении именно эталонной объектно-реляционной СУБД. Чтобы реализовать эти предпосылки, необходимо придать объектно-реляционной СУБД соответствующую концепции автоматизированной системы обработки данных, эталонной в смысле ЭМЗАС, архитектуру, в рамках которой изолировать программную среду данного функционального наполнения с удовлетворением всей совокупности подходящим образом заданных требований к ее субъектному наполнению.
При моделировании эталонной объектно-реляционной СУБД, применяемой в КСИИ критически важных сегментов информационной инфраструктуры, целесообразно использование реляционной модели данных в своей наиболее подходящей с точки зрения ЭМЗАС версии, основанной на классических фундаментальных понятиях типа, значения, переменной и оператора. Такая реляционная модель данных состоит из следующих пяти компонентов:
– неограниченный набор скалярных типов, включая логический, с возможностью использования как встроенных, так и пользовательских типов;
– генератор типов отношений и соответствующая интерпретация для сгенерированных типов отношений;
– возможность определения переменных отношений для указанных сгенерированных типов отношений;
– операция реляционного присваивания для присваивания реляционных значений указанным переменным отношения;
– неограниченный набор общих реляционных операторов (реляционная алгебра) для получения значений отношений из других значений отношений.
Для моделирования функционального наполнения эталонной объектно-реляционной СУБД недостаточно реляционной модели данных, относящейся к логическому уровню архитектуры ANSI/SPARC. Для реализации реляционной модели необходима модель хранения, относящаяся к физическому уровню, и модель опосредованного отображения между физическим и логическим уровнями [4].
На практике обычно использовалось непосредственное отображение между физическим и логическим уровнями, не позволяющее полностью реализовать потенциал реляционной модели. Но модель TransRelational™ (сокращенно модель TR) [3], разработанная Стивом Тареном, позволяет формально описывать опосредованное отображение между физическим и логическим уровнями, что позволяет ее применять к эталонной объектно-реляционной СУБД в качестве средства реализации реляционной модели данных. Она также является абстрактной моделью данных, но находится на более низком уровне абстракции, ближе к структурам физической памяти. Модель TR совместно с реляционной и объектной моделями легко интегрируется с концепцией автоматизированной системы обработки данных, эталонной в смысле ЭМЗАС, по причине удачной уровневой декомпозиции модели TR, абсолютно совместимой с уровневой декомпозицией ЭМЗАС. Реализованная с использованием модели TR СУБД может рассматриваться на трех уровнях абстракции: верхнем (реляционном или пользовательском), среднем (файловом или разадресации) и нижнем (табличном). На верхнем уровне данные представлены отношениями, составленными из кортежей и атрибутов, на нижнем – таблицами TR, состоящими из строк TR и столбцов TR, пересекающихся в ячейках TR. Средний уровень является перенаправляющим – отношения верхнего уровня отображаются на файлы TR среднего уровня, а те уже на таблицы TR нижнего уровня. Файлы TR состоят из записей TR и полей TR, соответствующих кортежам и атрибутам верхнего уровня. Файлы TR, таблицы TR и переменные отношения абстрагируют физически хранимые данные, но файлы TR ближе переменных отношения к физическому уровню и дальше таблиц TR. В отличие от неупорядоченности кортежей и атрибутов реляционной модели, записи TR и строки TR упорядочены сверху вниз, а поля TR и столбцы TR – слева направо. Выбираемый произвольно конкретный вариант упорядочения файла TR характеризует просто различные его версии, реконструируемые из одних и тех же таблиц TR одинаково легко. Ячейки TR можно адресовать по номерам строки TR и столбца TR как элементы массива. Строки TR не соответствуют взаимно однозначно записям на файловом уровне, а значит, и кортежам на реляционном уровне.
Файловый уровень TR естественным образом соответствует менеджерскому уровню ЭМЗАС, а табличный и реляционный уровни TR – интерфейсам сопряжения менеджерского уровня с информационным и прикладным уровнями ЭМЗАС соответственно. Это простое и естественное соответствие является ключевым фактором успешной реализуемости подхода к построению эталонной объектно-реляционной СУБД на основе комплекса из пяти моделей [4]. Количество моделей есть сумма количества уровней ЭМЗАС и сопряжений между ними для СУБД, т.е. 5 = 3 + 2.
Математическое моделирование использования объектно-реляционных СУБД в критически важных сегментах информационной инфраструктуры удобно осуществлять на основе анализа слоистой структуры [9] ЭМЗАС-сети, моделирующей соответствующую КСИИ. При таком подходе математической моделью эталонного управления объектно-реляционными базами данных является слой СУБД ЭМЗАС-сети – слой S7...9 третьего порядка девятого (прикладного) уровня с седьмым (информационным) нижним уровнем. Модульный состав слоя СУБД включает множества U9, U8, U7 модулей прикладного (девятого), менеджерского (восьмого) и информационного (седьмого) уровней ЭМЗАС. Любой суперблок, вписанный в слой СУБД и имеющий тем самым тот же порядок, уровень и нижний уровень, является суперблоком СУБД B7...9(I), где I – индекс суперблока, I = I(u), u – модуль ЭМЗАС-сети. Единственный средний уровень суперблока СУБД – менеджерский. Мощность множества 
всех суперблоков СУБД (идентифицируются своими индексами) равна количеству 
модулей прикладного уровня. Модульный состав произвольного суперблока СУБД B7...9(I0) с индексом I0 включает один верхний модуль с индексом I0, средние модули с индексами I0.i1, где 
и нижние модули с индексами I0.i1.i2, где 
, 
(здесь и далее K[I] – число нижних модулей в блоке с индексом I). Таким образом, множество U(B) всех модулей данного суперблока можно разложить на подмножества
нижних, средних и верхних модулей:
Верхнему модулю u(I0) соответствует прикладной модуль – программный модуль, из которого инициируется некоторая вычислительная процедура над базами данных. Средним модулям взаимно однозначно соответствуют переменные отношения (как базовые, так и реляционные представления). Каждый средний модуль 
, 
суперблока является верхним модулем блока 
, множество 
нижних модулей этого блока есть подмножество множества U7(B) нижних модулей суперблока, а семейство множеств U7(B7...8(I0.i1))), где 
, дает конечное разложение множества U7(B):
при 
Модулям из 
взаимно однозначно соответствуют различные значения реляционных атрибутов переменной отношения, соответствующей модулю 
. Одинаковым значениям различных реляционных атрибутов соответствует один и тот же модуль. Так как в эталонной объектно-реляционной СУБД различные значения реляционных атрибутов переменных отношения указывают на различные хранимые поля, то в конечном итоге нижний уровень суперблока СУБД моделирует доступ к хранимым полям.
Таким образом, в ключевой системе информационной инфраструктуры, входящей в состав критически важного сегмента этой информационной инфраструктуры, целесообразно использование объектно-реляционных СУБД. Такие СУБД должны моделироваться как суперблоки СУБД ЭМЗАС-сети. Верхнему модулю (относится к девятому, то есть прикладному уровню ЭМЗАС) такого суперблока соответствует прикладной модуль, инициирующий вычислительную процедуру над базами данных, средним модулям (относятся к восьмому, то есть менеджерскому уровню ЭМЗАС) взаимно однозначно соответствуют переменные отношения, а нижним (относятся к седьмому, то есть информационному уровню ЭМЗАС) – различные значения реляционных атрибутов переменных отношения. Математическим основанием построения такой математической модели служит анализ слоистой структуры ЭМЗАС-сети, моделирующей соответствующую КСИИ. А именно, в слоистой структуре ЭМЗАС-сети выделяется слой СУБД, охватывающий три уровня ЭМЗАС от седьмого (информационного) до девятого (прикладного).