Отдел обработки заказов

Финансовый отдел

Таблица ORDERS

Привилегии Привилегии SELECT и INSERT, UPDATE SELECT для некоторых столбцов Таблица CUSTOMERS

Привилегия \ SELECT \ для некоторых \:толбцов

Таблица SALESREPS

Ларри Фитч, .менеджер офиса в Лос-Анджелесе

Таблица OFFICES

Доступна всем пользователям

Привилегия SELECT для некоторых строк

Полный доступ ко всем данным

Полный доступ ко всем данным

Привилегия SELECT для некоторых строк

Боб Смит, менеджер офиса в Чикаго

Сэм Кларк, вице-президент по сбыту

Джордж Уоткинс, вице-президент по маркетингу

Рис 15.1. Система безопасности уч&бной базы дойных

В инструкции grant задастся комбинация идентификатора пользователя (sam), объекта (таблица offices) и привилегий (select и insert). Предоставленные привилегии можно позднее аннулировать посредством инструкции revoke:

Отменить привилегии, предоставленные ранее Сэму Кларку.

REVOKE SELECT, INSERT ON OFFICES FROM SAM

Инструкции grant и revoke более подробно описываются далее в настоящей главе.

Идентификаторы пользователей

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

На практике Офаничения на имена идентификаторов зависят от реализации СУБД Сгандарт SQL1 позволяет идентификатору пользователя иметь длину до 18 символов и требует, чтобы он бьш допустимым SQL-именем. В некоторых СУБД для мэйнфреймов длина идентификаторов офаничивалась восемью символами. В Sybase и SQL Server идентификатор пользователя может иметь до 30 символов. Если важна переносимость, то лучше всего, чтобы у идентификатора пользователя было не более восьми символов. На рис. 15.2 изображены различные пользователи, работающие с учебной базой данных, и типичные идешификагоры, присвоенные им Обратите внимание на то, что всем пользователям в отделе обработки заказов можно присвоить один и тот же идентификатор, так как все они имеют идентичные привилегии

Отдел обработки заказов

Идентификатор пользователя OPUSER

Менеджеры офисов

Идентифика-г пользователя

Идентификатор пользова BOB

Финансовый отдел

Идентификатор пользователя ARUSER

Вице-президенты

Сэм Кларк вице-президент по сбыту

Джордж Уоткинс вице-президент по маркетингу

Идентификатор пользователя SAM

Идентификатор пользователя GEORGE

Рис. 15.2. Иде

оры ffCOTfc твлей для учебной базы данных

В стандарте ANSI/ISO вместо термина идентификатор пользователя (user-id) упофебляется термин идентификатор прав доступа (authorization-id), и он встречается иногда в документации по SQL. С технической точки зрения второй термин является более правильнь[м, так как идентификатор определяет права или привилегии Бывают ситуации (см. рис. 15 2), когда имеет смысл присвоить нескольким пользователям одинаковый идентификатор. В других ситуациях один пользователь может пользоваться двумя или тремя различными идентификаторами. В промышленной базе данных идентификатор прав доступа может относиться к профаммам и Футтам программ, а не к отдельным людям В каждой из этих ситуаций термин идентификатор прав дост>тта является более точным и ясным, чем термин идентификатор пользователя . Однако наиболее распространена ситуация, когда каждому пользователю присваивается свой идентификатор, поэтому в документации большинства реляционных СУБД упофебляется термин иденгификатор пользователя .

Аутентификация пользователей

Соптасно стандарту SQL1, безопасность базы данных обеспечивается с помошьЮ идентификаторов пользователей Однако в стандарте ничего не говорится о механизме связи идентификатора пользователя с инсфукциями SQL Например, если вы

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

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

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

В некоторых СУБД реализована своя собственная система безопасности с идентификаторами пользователей и паролями. Например, когда в СУБД Oracle вы работаете с интерактивным SQL-модулем, который называется SQLPLUS, вы вводите имя пользователя и соответствующий пароль в командной строке

SQLPLUS SCOTT/TIGER

Интерактивный SQL-модуль СУБД Sybase, который называется ISQL, также принимает имя пользователя и пароль в формате командной Сфоки:

ISQL /USER=SCOTT /PASSWORD=TIGER

В каждом случае, прежде чем начать интерактивный сеанс связи, СУБД проверяет достоверность идентификатора пользователя (scott) и пароля (tiger)

Во многих других СУБД, включая Ingres и Informix, в качестве идентификаторов пользователей используются имена пользователей, регисфируемые в операционной системе мэйнфрейма. Например, когда вы регисфируетесь в вычислительной системе VAX/VMS, то вводите имя пользователя и пароль Чтобы запустить затем интерактивный модуль в СУБД Ingres, вы просто даете команду:

ISQL Ьаза данныА

Ingres автоматически извлекает имя пользователя из вашей учетной записи в операционной системе и делает его вашим идентификатором пользователя на данный сеанс работы с СУБД. Таким образом, вам не требуется задавать для базы данных отдельный идентификатор пользователя и пароль. Аналогичный прие.м применяется и в интерактивном SQL-модуле СУБД DB2, работающем в операционной системе MVS/TSO.

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