1.7. Языки безопасных баз данных

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

Важно отметить, что, хотя в SQL предусмотрены операторы поддержки безопасности (например, операторы GRANT и REVOKE), но они не обеспечивают многоуровневой защиты (и следовательно, принудительного управления доступом, MAC). Возможность предоставлять (GRANT) привилегии доступа и модификации по отношению к определенным объектам и передавать другим пользователям права на предоставление привилегий (конструкция WITH GRANT OPTION), а также отбирать (REVOKE) права (предоставленные непосредственно или в результате использования опции WITH GRANT OPTION) - все это средства поддержки добровольного управления доступом (DAC). Даже, несмотря на то, что модель безопасности в SQL-92 проработана значительно тщательнее, чем в предыдущих версиях (отметим, впрочем, что многие коммерческие реляционные SQL-ориентированные СУБД имели собственные расширения для поддержки безопасности даже и до выхода SQL-92), но все эти возможности все равно недостаточны для обеспечения безопасности баз данных не только в будущем, но и в настоящем.

В ожидаемых коммерческих версиях СУБД с многоуровневой защитой, вероятно, будут присутствовать определенные языковые расширения. Пример исследовательского прототипа такого расширенного языка - MSQL (multilevel SQL), язык СУБД SeaView. MSQL содержит операторы DDL со средствами спецификации классов безопасности:

create relation roster (

name char (30) [U:S]

primary-key,

rank char (10) [U:S],

job_code char (10)

[U:TS],

duty_location char (20) [U:TS],

...

)

MSQL допускает составные первичные ключи, как в следующем примере:

create relation roater (

group (last_name char (20),

first_name char (10),

middle_initial char (1) )

[U:TS] primary-key,

...

)

Спецификация классов защиты для атрибута может задаваться не только в виде диапазона, как в предыдущих примерах, но и путем перечисления:

create relation missions (

...

task char (30) [S; TS

NUCLEAR; TS INTEL],

...

)

В этом примере столбец TASK может содержать значения класса "секретно", "совершенно секретно/ядерное оружие", "совершенно секретно/разведка".

MSQL допускает задание классификационных ограничений, концептуально подобных ограничениям целостности SQL:

create class-constraint

JOBCodeRules

on roster as

name.class = SECRET,

rank.class = SECRET,

mission.class =

(if roster.mission = "COUNTERINTELLIGENCE" then

TOP SECRET else SECRET)

Отметим, что элемент метаданных класс должен быть обязательно определен для всех атрибутов.

MSQL включает функции типа HIGHEST-CLASS для обработки многозначной классифицированной информации (которая позволяет, например, при помощи оператора SELECT выбрать строки максимальной секретности, соответствующей благонадежности данного пользователя или процесса).

Хотя SQL3 в настоящее время не содержит команд MLS (multilevel security), и эти средства, вероятно, будут предоставляться в виде специфических для конкретных продуктов расширений, мы можем тем не менее высказать некоторые предположения относительно языковых расширений MLS.

SQL, по-видимому, предоставит основу для языковых расширений обеспечения безопасности, хотя нетрадиционные операторы, подобные принятым в MSQL (CREATE RELATION вместо CREATE TABLE), скорее всего, приблизятся к синтаксису стандартных операторов SQL.

Когда реализации многозначности вместе с поддержкой многоуровневой защиты войдут в коммерческие версии СУБД, будут приняты и соответствующие языковые расширения, причем не только в виде конструкций языка определения данных (DDL), но и в виде новых функций типа HIGHEST-CLASS. Примеры - функции HIGHEST-COVER-STORY и LOWEST-COVER-STORY, возвращающие "легенды" агента, соответственно максимального и минимального классов секретности.

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