Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 64)

Механизм двухфазной фиксации транзакции имеет ряд недостатков:

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

• велика вероятность отказа от обновления из-за какой-нибудь, пусть единичной, ошибки;

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

• использование в структуре сети координирующего узла связано с дополнительной опасностью, поскольку выход его из строя приве­дет к блокировке данных, затронутых транзакцией, до тех пор, пока он не будет восстановлен;

• сложность обработки транзакции при использовании этого про­токола сама служит источником дополнительного трафика, что уве­личивает время реакции системы.

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

Разные СУБД поддерживают разные технологии обеспечения це­лостности.

10.6.2. Средства защиты данных

Способы защиты данных

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

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

Дешифрование базы данных - это операция, обратная шифрова­нию.

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

Использование параметров запуска. Эти параметры позволяют задать стартовую форму, которая автоматически открывается при от­крытии базы данных. При определении формы можно скрыть окно базы данных, предоставляемое СУБД, и установить собственную кно­почную форму. При этом пользователь может выполнять с базой дан­ных только те действия, которые допускает интерфейс, предоставля­емый данным приложением.

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

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

Для каждого пользователя могут быть определены не только уни­кальный код, но и уровень доступа, и объекты, доступ к которым по­лучает пользователь.

Многие СУБД позволяют кроме единичных пользователей созда­вать еще и их группы.

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

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

Также желательно иметь механизм установки запрета на измене­ние параметров запуска, которые определяют такие свойства, как настраиваемые меню, настраиваемые панели инструментов и старто­вую форму.

Создание и удаление пользователей

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

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

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

Пользователи могут объединяться в группы. Группа пользовате­лей - это пользователи, наделенные одинаковым набором привиле­гий. Один и тот же пользователь в принципе может входить в разные группы. Каждый пользователь имеет специальное идентификацион­ное имя или номер (Authorization ID).

Поскольку большинство промышленно эксплуатируемых корпо­ративных СУБД являются SQL-серверами, рассмотрим вопросы уп­равления пользователями на примере SQL-систем.

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

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

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

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

Определение и отмена привилегий

Распределенные БнД предполагают работу с базой данных мно­гих пользователей. Однако не всем пользователям следует разрешать выполнять любые действия с базой данных. Поэтому пользователям предоставляются привилегии. Привилегия - это право пользователей на выполнение определенных операций над объектами данных неко­торого типа.

Привилегии в разных литературных источниках классифициру­ются по-разному. В [10] привилегии баз данных делятся на две кате­гории: системные привилегии (system privileges) и объектные приви­легии (object privileges). Системные привилегии контролируют общий доступ к базе данных. К ним относятся право создавать таблицы и другие объекты, а также право администрировать базу данных.

Объектные привилегии связаны с конкретным объектом базы дан­ных. Объектная привилегия логически состоит из трех частей:

• объекта, к которому применяется привилегия;

• операции, которые она разрешает;

• пользователя, которому даются эти привилегии.

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

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

Каждый пользователь в среде SQL имеет специальное идентифи­кационное имя (или номер).

Привилегии даются оператором GRANT (ПРЕДОСТАВИТЬ) и отменяются оператором REVOKE (ОТМЕНИТЬ).

Оператор GRANT имеет следующий синтаксис:

GRANT привилегия.,..ON имя объекта

ТО {пользователь, которому предоставляется привилегия.,..}|PUBLIK

[WITH GRANT OPTION];

привилегия:=

{ALL PRIVILEGES}

| {SELECT

| DELETE

| {INSERT [(имя столбца.,..)]}

| {UPDATE [(имя столбца.,..)]}

| {REFERENCES [(имя столбца.,..)]}

| USAGE}.

Когда SQL получает оператор GRANT, он проверяет привилегии пользователя, подавшего эту команду, чтобы определить, допустим ли оператор GRANT

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

• SELECT - разрешение выполнять запросы в таблице.

• INSERT - разрешение выполнять оператор INSERT (вставка но­вой строки) в таблице.

• UPDATE - разрешение выполнять оператор UPDATE (обновле­ние значений полей) в таблице. Можно ограничить эту привилегию для определенных столбцов таблицы.

• DELETE - разрешение выполнять оператор DELETE (удаление записей) в таблице.

• REFERENCES - разрешение определить внешний ключ.

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

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

Предположим, что пользователь Digo является владельцем таб­лицы «Sotrudnik» и хочет позволить пользователю Ivanov выполнять запросы к ней. В этом случае пользователь Digo должен ввести команду

GRANT SELECT ON Sotrudnik TO Ivanov;

Предложение WITH GRANT OPTION позволяет передать пользо­вателю возможность назначать привилегии для этой таблицы. Если, например, команда выглядит следующим образом:

GRANT SELECT ON Sotrudnik

TO Ivanov WITH GRANT OPTION;

то пользователь Ivanov получает возможность, в свою очередь, пере­давать право назначать привилегии другим пользователям, т. е. пользо­ватель Ivanov может задать следующую команду:

GRANT SELECT ON Digo.Sotrudnik

TO Petrov WITH GRANT OPTION;

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

Большинство привилегий объекта использует один и тот же син­таксис. Из перечисленных выше привилегий исключение составляют UPDATE и REFERENCES.

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

GRANT UPDATE (dolgnost, oklad) ON Sotrudnik TO Ivanov;

При задании привилегии REFERENCES также задаются имена столбцов.

Чтобы ограничить возможность просмотра таблицы только отдель­ными столбцами, следует воспользоваться механизмом создания пред­ставлений и назначать привилегии не для реальной таблицы, а для представления. Представления могут использоваться также и для обеспечения возможности ограничить просмотр только определенными строками или даже только, например, итоговыми или иными произ­водными данными, если в операторе CREATE VIEW соответствую­щим образом задан «внутренний» SELECT.

Отмена привилегий осуществляется с помощью оператора REVOKE. Эта команда имеет синтаксис, схожий с синтаксисом оператора GRANT. Например, отмена привилегии на просмотр таблицы «Sotrudnik» для пользователя Ivanov будет выглядеть следующим образом:

Характеристики

Список файлов книги