Главная » SQL, Базы данных » Защита данных

0

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

■     Под защитой данных подразумевается предотвращение доступа к ним со стороны

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

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

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

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

1    Как  указано  в  главе  9,  в  данном  контексте  термин  достоверность  или,   скорее,

правильность, должен быть в действительности приведен в кавычках.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии