При рассмотрении расширения языка 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, что может занять несколько лет. Пользователи ООСУБД, заинтересованные в средствах многоуровневой защиты, могут повлиять на поставщиков и на процесс стандартизации в отношении языковых средств безопасных ООСУБД.
