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

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

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

В целях защиты информации в базах данных важнейшими являются следующие аспекты информационной безопасности (европейские критерии):

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

целостность (непротиворечивость информации, ее защищенность от разрушения и несанкционированного изменения);

конфиденциальность (защита от несанкционированного прочтения).

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

К основным программно-техническим мерам, применение которых позволит решить некоторые из вышеперечисленных проблем, относятся:

аутентификация пользователя и установление его идентичности;

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

поддержание целостности данных;

протоколирован ие и ау дит;

защита коммуникаций между клиентом и сервером;

отражение угроз, специфичных для СУБД.

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

Управление доступом к базам данных базируется на реализации следующего минимального набора действий:

произвольное управление доступом;

обеспечение безопасности повторного использования объектов;

использование меток безопасности;

принудительное управление доступом.

Произвольное управление доступом - метод ограничения доступа к объектам, основанный на учете личности субъекта или групп, в которую субъект входит. Эта технология обеспечивает владельцу объекта (представления, сервера базы данных, процедуры, таблице) передачу по своему усмотрению привилегий другому лицу. Этим лицом в данной ситуации может выступать субъект-пользователь, группа пользователей.

Главное достоинство произвольного управления доступом - гибкость. Однако такие сопутствующие характеристики, как рассредоточенность управления и сложность централизованного контроля, создают немало проблем для обеспечения безопасности данных.

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

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

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

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

Протоколирован ие и ау дит состоят в следующем:

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

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

оказание помощи;

организация пассивной защиты информации от нелегальных действий пользователя.

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

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

5.1. Методы обеспечения безопасности

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

1. В случае избирательного управления некий пользователь обладает различными правами (привилегиями или полномочиями) при работе с разными объектами. Более того, разные пользователи обычно обладают и разными правами доступа к одному и тому же объекту. Поэтому избирательные схемы характеризуются значительной гибкостью.

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

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

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

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

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

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

Перечисленные выше методы управления доступом на самом деле являются частью более общей классификации уровней безопасности. Прежде всего в этих документах определяется четыре класса безопасности (security classes) – D, С, В и А. Среди них класс D наименее безопасный, класс С – более безопасный, чем класс D, и т.д. Класс D обеспечивает минимальную защиту, класс С – избирательную, класс В – обязательную, а класс А – проверенную защиту.

Избирательная защита. Класс С делится на два подкласса – С1 и С2 (где подкласс С1 менее безопасен, чем подкласс С2), которые поддерживают избирательное управление доступом в том смысле, что управление доступом осуществляется по усмотрению владельца данных.

Согласно требованиям класса С1 необходимо разделение данных и пользователя, т.е. наряду с поддержкой концепции взаимного доступа к данным здесь возможно также организовать раздельное использование данных пользователями.

Согласно требованиям класса С2 необходимо дополнительно организовать учет на основе процедур входа в систему, аудита и изоляции ресурсов.

Обязательная защита. Класс В содержит требования к методам обязательного управления доступом и делится на три подкласса – В1, В2 и В3 (где В1 является наименее, а В3 – наиболее безопасным подклассом).

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

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

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

Проверенная защита. Класс А является наиболее безопасным и согласно его требованиям необходимо математическое доказательство того, что данный метод обеспечения безопасности совместимый и адекватен заданной стратегии безопасности.

Хотя некоторые коммерческие СУБД обеспечивают обязательную защиту на уровне класса В1, обычно они обеспечивают избирательное управление на уровне класса С2.

5.2. Избирательное управление доступом

Избирательное управление доступом поддерживается многими СУБД. Избирательное управление доступом поддерживается в языке SQL.

В общем случае система безопасности таких СУБД базируется на трех компонентах:

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

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

3. Привилегии. Привилегии показывают набор действий, которые возможно производить над тем или иным объектом. Например пользователь имеет привилегию для просмотра таблицы.

5.3. Обязательное управление доступом

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

1. пользователь имеет доступ к объекту, только если его уровень допуска больше или равен уровню классификации объекта.

2. пользователь может модифицировать объекту, только если его уровень допуска равен уровню классификации объекта.

Правило 1 достаточно очевидно, а правило 2 требует дополнительных разъяснений. Прежде всего следует отметить, что по-другому второе правило можно сформулировать так: любая информация, записанная некоторым пользователем, автоматически приобретает уровень, равный уровню классификации этого пользователя. Такое правило необходимо, например, для того, чтобы предотвратить запись секретных данных, выполняемую пользователем с уровнем допуска "секретно", в файл с меньшим уровнем классификации, что нарушает всю систему секретности.

В последнее время методы обязательного управления доступом получили широкое распространение. Требования к такому управлению доступом изложены в двух документах, которые неформально называются "оранжевой" книгой (Orange Book) и "розовой" книгой (Lavender Book). В "оранжевой" книге перечислен набор требований к безопасности для некой "надежной вычислительной базы" (Trusted Computing Base), а в "розовой" книге дается интерпретация этих требований для систем управления базами данных.

5.4. Шифрование данных

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

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

5.5. Контрольный след выполняемых операций

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

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

2. терминал, с которого была вызвана операция;

3. пользователь, задавший операцию;

4. дата и время запуска операции;

5. вовлеченные в процесс исполнения операции базовые отношения, кортежи и атрибуты;

6. старые значения;

7. новые значения.

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

5.6. Поддержка мер обеспечения безопасности в языке SQL

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

5.7. Директивы GRANT и REVOKE

Механизм представлений языка SQL позволяет различными способами разделить базу данных на части таким образом, чтобы некоторая информация была скрыта от пользователей, которые не имеют прав для доступа к ней. Однако этот режим задается не с помощью параметров операций, на основе которых санкционированные пользователи выполняют те или иные действия с заданной частью данных. Эта функция (как было показано выше) выполняется с помощью директивы GRANT.

Обратите внимание, что создателю любого объекта автоматически предоставляются все привилегии в отношении этого объекта.

Стандарт SQL1 определяет следующие привилегии для таблиц:

1. SELECT – позволяет считывать данные из таблицы или представления;

INSERT – позволяет вставлять новые записи в таблицу или представление;

UPDATE – позволяет модифицировать записи из таблицы или представления;

DELETE – позволяет удалять записи из таблицы или представления.

Стандарт SQL2 расширил список привилегий для таблиц и представлений:

1. INSERT для отдельных столбцов, подобно привилегии UPDATE;

2. REFERENCES – для поддержки внешнего ключа.

Помимо перечисленных выше добавлена привилегия USAGE – для других объектов базы данных.

Кроме того, большинство коммерческих СУБД поддерживает дополнительные привилегии, например:

1. ALTER – позволяет модифицировать структуру таблиц (DB2, Oracle);

2. EXECUTE – позволяет выполнять хранимые процедуры.

Создатель объекта также получает право предоставить привилегии доступа какому-нибудь другому пользователю с помощью оператора GRANT. Ниже приводится синтаксис утверждения GRANT:

GRANT {SELECT|INSERT|DELETE|(UPDATE столбец, …)}, …

ON таблица ТО {пользователь | PUBLIC}

Привилегии вставки (INSERT) и обновления (UPDATE) (но не привилегии выбора SELECT, что весьма странно) могут задаваться для специально заданных столбцов.

Если задана директива WITH GRANT OPTION, это значит, что указанные пользователи наделены особыми полномочиями для заданного объекта – правом предоставления полномочий. Это, в свою очередь, означает, что для работы с данным объектом они могут наделять полномочиями других пользователей

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

GRANT SELECT, UPDATE StName

ON Students ТО Ivanov WITH GRANT OPTION

Если пользователь А наделяет некоторыми полномочиями другого пользователя В, то впоследствии он может отменить эти полномочия для пользователя В. Отмена полномочий выполняется с помощью директивы REVOKE с приведенным ниже синтаксисом.

REVOKE {{SELECT | INSERT | DELETE | UPDATE},…|ALL PRIVILEGES}

ON таблица,… FROM {пользователь | PUBLIC},… {CASCADE | RESTRICT}

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

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

ON Students FROM Ivanov CASCADE

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

5.8. Представления и безопасность

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

Заключение

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

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

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

• * похищение и фальсификация данных;
• * утрата конфиденциальности (нарушение тайны);
• * нарушение неприкосновенности личных данных;
• * утрата целостности;
• * потеря доступности.

Вопросы защиты данных часто рассматриваются вместе с вопросами

поддержки целостности данных (по крайней мере, в неформальном контексте),

хотя на самом деле это совершенно разные понятия. Термин защита

относится к защищенности данных от несанкционированного доступа, изменения или умышленного разрушения, а целостность к точности или достоверности данных. Эти термины можно определить, как показано ниже.

• · Под защитой данных подразумевается предотвращение доступа к ним со стороны несанкционированных пользователей.
• · Под поддержкой целостности данных подразумевается предотвращение

их разрушения при доступе со стороны санкционированных пользователей.

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

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

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

Ниже описаны многочисленные аспекты проблемы защиты данных.

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

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

В случае избирательного контроля каждому пользователю обычно предоставляются различные права доступа (иначе называемые привилегиями, или полномочиями) к разным объектам. Более того, разные пользователи, как правило, обладают разными правами доступа к одному и тому же объекту. (Например, пользователю U1 может быть разрешен доступ к объекту А, но запрещен доступ к объекту B, тогда как пользователю U2 может быть разрешен доступ к объекту B, но запрещен доступ к объекту А.) Поэтому избирательные схемы характеризуются значительной гибкостью.

В случае мандатного контроля, наоборот, каждому объекту данных назначается некоторый классификационный уровень, а каждому пользователю присваивается некоторый уровень допуска. В результате право доступа к объекту данных получают только те пользователи, которые имеют соответствующий уровень допуска. Мандатные схемы обычно имеют иерархическую структуру и поэтому являются более жесткими. (Если пользователь U1 имеет доступ к объекту А, но не имеет доступа к объекту B, то в схеме защиты объект B должен будет располагаться на более высоком уровне, чем объект А, а значит, не может существовать никакого пользователя U2, который будет иметь доступ к объекту B, но не будет иметь доступа к объекту А.)

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

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

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

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

Избирательная схема управления доступом

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

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

GRANT RETRIEVE { S#, SNAME, CITY }, DELETE

TO Jim, Fred, Mary ;

Этот пример иллюстрирует тот факт, что в общем случае полномочия доступа включают четыре описанных ниже компонента.

• 1. Имя (в данном примере SA3, "suppliers authority three" -- полномочия поставщика с номером 3). Устанавливаемые полномочия будут зарегистрированы в системном каталоге под этим именем.
• 2. Одна или несколько привилегий, задаваемых в конструкции GRANT.
• 3. Задаваемое в конструкции ON имя переменной отношения, к которой применяются полномочия.
• 4. Множество пользователей (точнее, идентификаторов пользователей), которым предоставляются указанные привилегии применительно к указанной переменной отношения, задаваемой с помощью фразы ТО.

Ниже приводится общий синтаксис оператора определения полномочий.

AUTHORITY

GRANT

ON