В ходе этого урока мы с вами поговорим об управлении доступом к базе данных, что в реляционных базах данных является одной из важнейших задач. Вы узнаете о том, как в рамках SQL создаются учетные записи пользователей, о безопасности пользователей, о пользовательских профилях и атрибутах, а также доступных пользователю соответствующих средствах.
Основными на этом уроке будут следующие темы.
• Типы пользователей
• Управление пользователями
• Место пользователя в базе данных
• Имена пользователей и имена схем
• Сеансы доступа пользователей к базе данных
• Изменение атрибутов пользователя
• Пользовательские профили
• Удаление учетной записи пользователя из базы данных
• Средства, доступные пользователю
Стандарт SQL предлагает идентифицировать пользователей базы данных с помощью идентификаторов разрешения доступа (Authorization Identifier — authio). В большинстве реализаций языка идентификаторы разрешения доступа называются просто пользователями. В этой книге для обозначения идентификаторов разрешения доступа мы применяем слова "пользователь", "пользователь базы данных", "имя пользователя", а также "учетная запись пользователя". В соответствии со стандартом SQL, идентификатор разрешения доступа является именем, по которому система распознает пользователя базы данных.
Пользователь превыше всего с точки зрения дизайна, структуры, реализации и управления любой базы данных. Потребности пользователя обязательно учитываются при разработке базы данных, и конечной целью разработки всегда должно быть создание такой базы данных, с которой удобно работать пользователю.
Что касается пользователей, то если бы их не было вообще, то с базой данных никогда не происходило бы ничего плохого. И хотя это утверждение похоже на правду, базы данных все равно создаются для того, чтобы с ними работали пользователи и работали каждый день.
Чаще всего контроль за работой пользователей относится к компетенции администратора базы данных, но иногда в этом процессе участвуют и обычные пользователи. Управление пользователями играет важнейшую роль в обеспечении надежной работы базы данных и осуществляется исключительно средствами SQL, хотя следует отметить, что последние зависят от конкретной реализации языка.
Различают следующие типы пользователей базы данных.
• Клерки, осуществляющие ввод данных
• Программисты
• Системные инженеры
• Администраторы баз данных
• Системные аналитики
• Разработчики
• Специалисты по тестированию
• Управляющий персонал
• Конечные пользователи
Пользователи каждого из указанных типов решают при работе с базой данных свои задачи (и при этом имеют свои проблемы), и поэтому занимают разные места в иерархии базы данных, имея различные уровни доступа к ней.
За управление пользователями вообшето отвечает управленческое звено компании, но управление пользователями в рамках базы данных относится к компетенции администратора базы данных и его подчиненных.
Администратор базы данных создает учетные записи пользователей, наделяет пользователей привилегиями, создает пользовательские профили и при необходимости удаляет учетные записи. Поскольку при большой активности пользователей такая работа может оказаться для одного человека непосильной, в некоторых компаниях имеется специальная служба безопасности, призванная помочь администратору базы данных в деле управления пользователями.
Служба безопасности или защиты данных (если она в компании предусмотрена) обычно занимается документированием заявок пользователей и передает соответствующую информацию администратору базы данных. В ее обязанности входит также своевременное информирование администратора базы данных о том, что какому-либо из пользователей доступ к базе данных уже не требуется.
Системный аналитик или системный администратор обычно отвечает за безопасность вычислительной системы в целом, для чего и создаются учетные записи пользователей и разрабатывается система привилегий доступа. Точно так же, как администратору базы данных, служба безопасности может помогать и системному аналитику.
Место пользователя в базе данных
Пользователю обычно отводится роль, соответствующая выполняемой им работе. Соответствующими оказываются и предоставленные пользователю привилегии. Ни один из пользователей не должен иметь привилегий доступа, выходящих за рамки необходимого. Главной и единственной причиной использования учетных записей пользователей и привилегий является необходимость защиты данных. Если не тот пользователь получит доступ не к тем данным, данные могут быть повреждены или уничтожены, пусть даже и непреднамеренно. После того, как доступ к данным пользователю уже не нужен, его учетную запись необходимо либо удалить из базы данных, либо сделать недействительной.
Каждый из пользователей занимает в базе данных свое место, и поэтому одни пользователи имеют больше привилегий, чем другие. Пользователей базы данных можно сравнить с органами человеческого тела — все части работают вместе в унисон (по крайней мере, это предполагается) с целью выполнения определенной задачи.
Объекты базы данных связываются с именами пользователей, и это называется схемой. Схема — это набор объектов базы данных, принадлежащих одному пользователю базы данных. Этот пользователь называется владельцем схемы. Разница между обычным пользователем базы данных и владельцем схемы состоит в том, что владелец схемы имеет свои объекты в базе данных, в то время как большинство пользователей никакими объектами в базе данных не владеют. Большинство пользователей получают доступ к базе данных для того, чтобы использовать данные, предоставляемые объектами имеющихся в ней схем.
Без стабильной системы управления пользователями базы данных невозможно обеспечить надежное хранение данных. Система управления пользователями начинается с непосредственных руководителей пользователей, через которых подается запрос на доступ к данным, затем по цепочке разрешающих (или запрещающих) структур он попадает к администратору базы данных, который выполняет конкретные действия по созданию учетной записи пользователя в базе данных. Здесь должна быть продумана хорошая система извещения: руководитель пользователя и сам пользователь должны быть извещены о создании в базе данных учетной записи пользователя и получении доступа к данным. Пользовательский пароль должен быть предоставлен только самому пользователю, а последний при первом же входе в базу данных должен немедленно изменить этот пароль.
По поводу создания учетных записей пользователей обратитесь к документации используемой вами реализации языка. Очевидно также, что при создании учетных записей пользователей и управлении ими следует придерживаться правил, принятых в той компании, где вы работаете. В следующих разделах сравниваются процедуры создания учетной записи пользователя в Oracle, Sybase и Microsoft SQL Server.
Создание учетных записей пользователей
Создание учетных записей пользователей осуществляется с помощью определенных команд SQL в рамках базы данных. Стандартных команд для создания пользователей нет — каждая реализация языка предлагает свои методы. В некоторых реализациях SQL команды создания учетных записей пользователей похожи, в других — нет. Но независимо от реализации, базовый подход остается одним и тем же.
При получении администратором базы данных или уполномоченным по безопасности заявки на разрешение доступа к данным, эта заявка должна быть тщательно изучена на предмет ншшчия всей необходимой для создания учетной записи пользователя информации в соответствии с требованиями, принятыми в вашей конкретной компании.
Обычно в данном случае считается необходимым указать идентификационный номер, полное имя, адрес, телефон, название отдела, имя базы данных, к которой требуется доступ, а иногда и желательное имя пользователя.
Конкретный вид операторов, используемых для создания учетных записей пользователей, будет показан в следующих разделах.
Создание учетной записи пользователя в Oracle
Процесс создания учетной записи пользователя в Oracle состоит из двух шагов.
1. Создание учетной записи пользователя базы данных с параметрами по умолчанию
2. Наделение пользователя необходимыми привилегиями доступа
Синтаксис оператора для создания учетной записи пользователя имеет следующий вид.
CREATE USER ИМЯ_ПОЛЬЗОВАТЕЛЯ
IDENTIFIED BY [ ПАРОЛЬ | EXTERNALLY ]
[ DEFAULT TABLESPACE №1Я_ОБЛАСТИ ]
[ TEMPORARY TABLESPACE ИМЯ_ОБЛАСТИ ]
[ QUOTA (ЦЕЛОЕ_ЗНАЧЕНИЕ (К | М) | UNLIMITED) ON ИМЯ_ОБЛАСТИ ]
[ PROFILE ТИП_ПРОФИЛЯ ]
[PASSWORD EXPIRE | ACCOUNT [LOCK UNLOCK]]
Такого вида оператор может быть использован для добавления пользователя в базу данных Oracle, а также в реляционные базы данных некоторых других реализаций.
Если вы не используете Oracle, не следует слишком вникать в смысл некоторых из предлагаемых данным синтаксисом опций. TABLESPACE означает логическую область, в которой размещаются объекты базы данных, в частности, таблицы и индексы. DEFAULT TABLESPACE задает область, используемую для объектов, создаваемых данным пользователем. TEMPORARY TABLESPACE задает область хранения данных для операций сортировки, осуществляемых в ходе выполнения запросов пользователя. QUOTA ограничивает сверху доступный пользователю объем конкретной логической области. PROFILE определяет профиль базы данных, предлагаемый пользователю.
Для наделения пользователя необходимыми привилегиями доступа используется оператор следующего вида.
GRANT PRIV1 [ , PRIV2, ... ] TO USERNAME | ROLE [, USERNAME ]
С помощью одного оператора GRANT можно наделить одной или несколькими привилегиями одного или нескольких пользователей одновременно.
Создание учетных записей пользователей в Sybase и Microsoft SQL Server
Последовательность шагов, которые необходимо выполнить при создании учетной записи пользователя в базе данных Sybase или Microsoft SQL Server, должна быть следующей.
1. Создание имени пользователя базы данных SQL Server с указанием пароля и базы данных для доступа.
2. Добавление пользователя в соответствующую базу данных.
3. Наделение пользователя необходимыми привилегиями доступа.
Учетная запись пользователя создается оператором следующего вида.
SP_ADDLOGIN ИМЯ_ПОЛЬЗОВАТЕЛЯ, ПАРОЛЬ, [, БАЗА_ДАННЫХ ]
В базу данных пользователь добавляется с помощью оператора следующего вида.
SP_ADDUSER ИМЯ_ПОЛЬЗОВАТЕЛЯ [, ИМЯ_В_БД [, ИМЯ_ГРУППЫ } ]
Наделение пользователя необходимыми привилегиями доступа осуществляется с помощью оператора следующего вида.
GRANT PRIV1 [ , PRIV2, ... ] ТО ИМЯ_ПОЛЬЗОВАТЕЛЯ
Схемы создаются с помощью оператора CREATE SCHEMA. Синтаксис этого оператора следующий.
CREATE SCHEMA [ ИМЯ_СХЕМЫ ] ( ИМЯ_ПОЛЬЗОВАТЕЛЯ ]
[ DEFAULT CHARACTER SET НАБОР_СИМВОЛОВ ]
[ PATH ИМЯ_СХЕМЫ [ , ИМЯ_СХЕМЫ ] ]
[ СПИСОК_ЭЛЕМЕНТОВ_СХЕМЫ ]
Вот пример:
CREATE SCHEMA USER1 CREATE TABLE TBL1
(Столбец1 ТИП_ДАННЫХ [NOT NULL],
Столбец2 ТИП_ДАННЫХ [NOT NULL]...)
CREATE TABLE TBL2
(Столбец1 ТИП_ДАННЫХ [NOT NULL],
Столбец2 ТИП_ДАННЫХ [NOT NULL]...)
GRANT SELECT ON TBLl TO USER2
GRANT SELECT ON TBL2 TO USER2
[ Другие команды DDL ... ]
В реальности оператор CREATE SCHEMA может быть применен, например, следующим образом.
CREATE SCHEMA AUTHORIZATION USER1
CREATE TABLE EMP
(ID NUMBER NOT NULL,
NAME VARCHAR2(10) NOT NULL)
CREATE TABLE CUST
(ID NUMBER NOT NULL,
NAME VARCHAR2(10) NOT NULL)
GRANT SELECT ON TBLl TO USER2
GRANT SELECT ON TBL2 TO USER2
Схема создана.
Здесь к команде CREATE SCHEMA добавлено ключевое слово AUTHORIZATION. Пример взят из базы данных Oracle. Пример приводится для того, чтобы вы лишний раз убедились в том, что как и во многих обсуждавшихся выше случаях синтаксис команд часто зависит от конкретной реализации языка
Некоторые реализации SQL не поддерживают команду CREATE SCHEMA. В таком случае схема может создаваться автоматически при создании пользователем объектов базы данных Команда CREATE SCHEMA просто позволяет выполнить такую задачу за один шаг После создания пользователем объектов, этот пользователь может наделить других пользователей привилегиями, разрешающими доступ к созданным объектам
Схема может быть удалена из базы данных с помощью оператора DROP SCHEMA. Этот оператор имеет две опции. Применение первой из них, опции RESTRICT, заставит сервер базы данных при удалении схемы выдать сообщение об ошибке, если эта схема содержит какие-нибудь объекты. Чтобы такое сообщение не появлялось, следует применить другую опцию, а именно опцию CASCADE. Помните о том, что при удалении схемы из базы данных удаляются все связанные с этой схемой объекты.
Синтаксис соответствующего оператора следующий.
DROP SCHEMA ИМЯ__СХЕМЫ { RESTRICT | CASCADE }
В схеме может не оказаться никаких объектов потому, что объекты (например, таблицы) могут быть удалены с помощью соответствующих команд SQL (например, DROP TABLE). В некоторых реализациях языка предлагается процедура или команда для удаления пользователя, которую можно использовать также и для удаления схемы. Если в используемой вами реализации SQL команда DROP SCHEMA не поддерживается, вы можете удалить схему, удалив из базы данных пользователя, являющегося владельцем схемы
Изменение атрибутов пользователей
Очень важной составляющей процесса управления пользователями является возможность менять атрибуты пользователей уже после создания в базе данных их учетных записей Жизнь администратора базы данных, наверное, сильно упростилась, если бы служащие компании со своими учетными записями в базе данных никогда не продвигались по служебной лестнице, никогда не увольнялись и не принимались на работу. Но в реальности наблюдается высокая текучесть кадров и постоянное изменение обязанностей и, как следствие, потребностей пользователей, что выливается в необходимость постоянного изменения пользовательских привилегий доступа
Вот пример изменения текущего состояния атрибутов пользователя в рамках одной из реализаций SQL (Oracle).
ALTER USER ИМЯ_ПОЛЬЗОВАТЕЛЯ [ IDENTIFIED BY ПАРОЛЬ | EXTERNALLY | GLOBALLY AS 'CN=USER' ]
[ DEFAULT TABLESPACE ИМЯ_ОБЛАСТИ ]
[ TEMPORARY TABLESPACE ИМЯ_ОБЛАСТИ ]
[ QUOTA ЦЕЛОЕ_ЗНАЧЕНИЕ К|М [UNLIMITED ON ИМЯ_ОБЛАСТИ }
[ PROFILE ТИП_ПРОФИЛЯ }
[PASSWORD EXPIRE]
[ACCOUNT [LOCK | UNLOCK]]
[ DEFAULT ROLE РОЛЫ [ , РОЛЬ2 } | ALL
[ EXCEPT РОЛЫ [, РОЛЬ2 | NONE ] ]
В рамках этого оператора можно изменить целый ряд атрибутов пользователя К сожалению, не все реализации SQL предлагают подобную простую команду, позволяющую манипулировать пользователями базы данных Однако некоторые реализации языка для выполнения этой задачи могуг даже предложить средства графического пользовательского интерфейса
Точный синтаксис оператора для изменения атрибутов пользователя вы можете узнать из документации той реализации языка, которую используете Здесь представлен синтаксис оператора ALTER USER Oracle. В большинстве реализаций SQL имеются свои средства для изменения пользовательских ролей, привилегий, атрибутов и паролей
Пользователь может изменить имеющийся у него пароль Точный синтаксис оператора для изменения пароля можно узнать из документации той реализации языка, которую вы используете. В Oracle для этого обычно используется оператор ALTER USER.
Сеанс доступа пользователя к базе данных начинается с момента его подключения к ней и заканчивается после отключения от базы данных. В течение времени, когда пользователь остается подключенным к базе данных (т. е. в ходе сеанса доступа), он имеет возможность осуществлять с данными базы данных рахчичные действия, например выполнение запросов и транзакций.
Сеанс SQL инициируется пользователем при подключении его машины-клиента к серверу с помощью оператора CONNECT С момента начала сеанса SQL пользователь имеет возможность выполнить любое число транзакций вплоть до момента его отключения от базы данных, когда сеанс доступа прекращается.
Пользователь имеет возможность явным образом подключаться к базе данных и отключаться от нее (тем самым соответственно начиная и заканчивая сеанс доступа к данным) с помощью следующих команд.
CONNECT TO DEFAULT | CTPOKA1 [ AS CTPOKA2 ] [ USER CTPOKA3 ]
DISCONNECT DEFAULT | CURRENT | ALL | СТРОКА
SET CONNECTION DEFAULT | СТРОКА
He забывайте о том, что синтаксис операторов зависит от реализации языка. Кроме того, в большинстве реализаций пользователю не приходится вводить команды начала и окончания сеанса доступа вручную В большинстве случаев пользователю приходится иметь дело с поставляемыми производителем базы данных или третьей стороной программами, запрашивающими имя пользователя и пароль и осуществляющими подключение к базе данных и отключение от нее
Сеансы доступа к данным могут автоматически отслеживаться — и часто действительно отслеживаются — администраторами базы данных или другими уполномоченными представителями управленческого звена, заинтересованными в получении информации об активности пользователей базы данных. При наблюдении за пользовательской активностью сеансы доступа пользователей ассоциируются с их учетными записями При этом сеанс доступа представляется как отдельный процесс главного компьютера
Удаление учетных записей пользователей базы данных
Удаление учетной записи потьзователя из базы данных или ликвидация возможности его доступа к данным осуществляется парой простых команд Здесь, однако, опять следует отметить, что ввиду отсутствия для этих команд стандартов, необходимо обратиться к документации той реализации SQL, которую вы используете.
К методам ликвидации возможности доступа пользователя к данным можно отнести следующие
• Изменение пароля пользователя
• Удаление учетной записи пользователя из базы данных
• Отмена ранее разрешенных пользователю привилегий доступа к данным
В некоторых реализациях SQL для удаления учетной записи пользователя из базы данных может использоваться команда DROP.
DROP USER ИМЯ_ПОЛЬЗОВАТЕЛЯ [ CASCADE ]
Во многих реализациях языка имеется команда REVOKE, являющаяся противоположностью команды GRANT и позволяющая отменить ранее назначенные пользователю привилегии. В некоторых реализациях SQL команда отмены привилегий имеет следующий синтаксис.
REVOKE PRIV1 [, PRIV2, ... ] FROM ИМЯ_ПОЛЬЗОВАТЕЛЯ
Средства, доступные пользователю
Некоторые утверждают, что для того, чтобы составлять запросы к базе данных, совсем не обязательно знать SQL. В некотором отношении с таким утверждением можно согласиться, но знание SQL определенно не окажется лишним при составлении запроса, даже при наличии средств графического интерфейса пользователя. Хотя при наличии графического интерфейса пользователя его непременно следует использовать, всегда полезно знать, что происходит за кулисами.
Графический интерфейс пользователя обычно имеет своей целью автоматическое создание программного кода SQL на основе информации, получаемой от пользователя посредством диалоговых окон, ответов на запросы и выбора опций. Существуют подобные средства и для создания отчетов, могут существовать формы для построения запросов, выполнения операций ввода, обновления и удаления данных, а также средства для представления данных в виде диаграмм и графиков. Существуют средства, призванные помочь администратору базы данных осуществлять мониторинг производительности базы данных, а также средства, позволяющие удаленный доступ к базе данных. Некоторые из этих средств поставляются производителями баз данных, другие же — независимыми производителями.
Любая база данных имеет своих пользователей, и не важно сколько их — один или тысячи. Именно для пользователей и создаются базы данных. Процесс управления пользователями можно разбить на три главных этапа. Сначала необходимо создать учетную запись пользователя в базе данных. После этого пользователя необходимо наделить привилегиями сообразно тем задачам, которые пользователь предположительно будет решать в рамках базы данных. Наконец, после того, как доступ к данным пользователю будет уже не нужен, необходимо либо удалить из базы данных его учетную запись, либо отменить ранее предоставленные ему привилегии.
Выше были рассмотрены некоторые из наиболее часто возникающих задач управления пользователями базы данных. При этом мы сознательно не вдавались в детали, поскольку в рамках различных баз данных конкретные формы процесса управления пользователями могут сильно отличаться друг от друга. Тем не менее, хотя многие из используемых для управления пользователями команд не обсуждаются и не определяются стандартом ANSI SQL в деталях, стандартными оказываются заложенные в основу этих команд концепции.
Имеются ли стандартные команды SQL для добавления пользователей в базу данных?
Некоторые команды и концепции определены стандартом ANSI, хотя в каждой реализации языка предлагаются свои команды, средства и правила добавления в базу данных пользователей.
Можно ли временно лишить пользователя права доступа к базе данных, не удаляя его учетную запись из базы данных?
Да. Право доступа пользователя к базе данных можно временно запретить простым изменением его пароля или отменой привилегий доступа к данным. Восстановить право доступа после этого можно, сообщив пользователю новый пароль или вернув ему отмененные ранее привилегии.
Может ли пользователь изменить предложенный ему пароль?
Да, в рамках многих из наиболее популярных реализаций языка. При создании или добавлении в базу данных учетной записи пользователя последнему сообщается некоторый, обычно временный пароль, который пользователь должен изменить как можно скорее на новый по своему усмотрению. После этого нового пароля не будет знать даже администратор базы данных.
Задания практических занятий разделены на тесты и упражнения. Тесты предназначены для проверки общего уровня понимания рассмотренного материала. Упражнения дают возможность применить на практике идеи, обсуждавшиеся в ходе текущего урока, в комбинации с идеями из предыдущих уроков. Мы рекомендуем ответить на тестовые вопросы и выполнить упражнения прежде, чем продолжать дальнейшее чтение книги. Ответы можно проверить по Приложению Б, "Ответы".
1. С помощью какой команды инициируется сеанс доступа к данным базы данных?
2. С помощью какой команды можно удалить схему, все еще содержащую объекты?
3. С помощью какого оператора можно отменить назначенные пользователю привилегии?
4. Какая команда создает группу таблиц, представлений и привилегий?
1. Опишите по шагам процесс предоставления доступа к базе данных новому пользователю.