Часть V

Дополнительные аспекты

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

• Защита данных (глава 16)

• Оптимизация (глава 17)

• Отсутствующая информация (глава 18)

• Наследование типов (глава 19)

• Распределенные базы данных (глава 20)

• Поддержка принятия решений (глава 21)

• Хронологические базы данных (глава 22)

• Логические системы управления базами данных (глава 23)

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

Глава

_{Защита данных}

16.1. Введение

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

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

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

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

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

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

Общие соображения

Среди многочисленных аспектов проблемы защиты данных необходимо выделить следующие.

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

• Физические условия (например, запирается ли помещение с компьютерами или терминалами либо же оно охраняется другим способом).

• Организационные вопросы (например, каким образом на предприятии, являю- щемся владельцем системы, принимается решение о том, кому разрешено иметь доступ к тем или иным данным).

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

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

• Возможности операционной системы (например, стирает ли используемая опера- ционная система содержимое оперативной памяти и дисковых файлов после пре- кращения работы с ними).

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

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

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

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

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

Избирательные схемы подробно обсуждаются ниже, в разделе 16,2, а мандатные схе- мы — разделе 16.3.

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

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

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

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

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

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

внимание на работу [16,9], в которой описывается система с вложенными пользователь- скими группами. Вот цитата из этой работы: "Способность классифицировать пользова- телей в виде иерархии групп представляет собой мощный инструмент администрирова- ния больших систем с тысячами пользователей и объектов".