авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 5 | 6 || 8 | 9 |   ...   | 33 |

«Е.Мамаев MS SQL SERVER 2000 Книга посвящена одной из самых мощных и популярных современных систем управления базами данных - Microsoft SQL Server 2000. ...»

-- [ Страница 7 ] --

Рассмотрим работу с последней вкладкой (Database Access) окна создания но вого пользователя. Эта вкладка (рис. 9.8) разделена на две части. В верхней час ти приводится список всех баз данных, созданных на локальном SQL Server 2000. Если установить флажок в столбце Permit, то создаваемой учетной записи будет разрешен доступ к соответствующей базе данных. Имя базы дан ных указывается в столбце Database. Отображение учетных записей в пользова телей базы данных рассмотрено далее в этой главе. Сейчас же скажем, что, пре Глава 9. Система безопасности SQL Server доставляя учетной записи доступ к базе данных, необходимо указать имя поль зователя, в которого будет отображаться учетная запись. Имя этого пользователя указывается в столбце User. Если в столбце Permit для базы данных установлен флажок, то нужно обязательно определить имя пользователя базы данных. По умолчанию это имя устанавливается идентичным имени учетной записи. В принципе, для каждой базы данных можно выбрать произвольное имя пользова теля базы данных.

Рис. 9.7. Вкладка Permissions окна Server Role Properties - sysadmin В нижней части окна отображается список ролей базы данных. Он будет пус тым, если учетной записи не предоставлен доступ к базе данных, выбранной к верхней части окна. Используя список ролей базы данных, отображаемый в нижней части окна, можно включить пользователя в ту или иную роль.

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

Для включения пользователя в ту или иную роль базы данных достаточно уста новить флажок слева от имени нужной роли. Нажав кнопку Properties, можно открыть окно свойств роли Database Role Properties (рис. 9.9), в котором приво дится список всех пользователей, уже включенных в выбранную роль базы дан ных: В данном окне также можно добавить новых или удалить уже включенных в роль пользователей. Кроме того, в окне имеется кнопка Permissions, нажав которую, можно открыть окно управления правами доступа роли к объектам базы данных.

Часть III. Админис Рис. 9.8. Вкладка Database Access окна создания нового пользователя Рис. 9.9. Окно Database Role Properties для роли db owner Глава 9. Система безопасности SQL Server 2000 Специальные учетные записи Мы закончили рассмотрение процесса создания учетной записи для предостав ления или отклонения доступа к SQL Server 2000. Обратим внимание, что в процессе инсталляции SQL Server 2000 мастер установки создает две специаль ные учетные записи:

• sa (system administrator). Эта учетная запись оставлена для сохранения обрат ной совместимости с предыдущими версиями SQL Server. Ранее учетная за пись была обязательной, имела абсолютные права по управлению сервером и не могла быть удалена. В SQL Server 2000 можно более гибко управлять пра вами учетных записей, используя роли сервера. В принципе, учетная запись sa может быть удалена. Программа установки включает ее в роль сервера sysadmin, предоставляя ей тем самым абсолютные права управления SQL Server 2000, и устанавливает для нее пустой пароль. Поэтому первое, что необ ходимо сделать по завершении инсталляции — это сменить пароль sa. Для по вышения безопасности системы следует ограничить использование учетной за писи sa, оставив ее на крайний случай. Для управления сервером лучше создать новые учетные записи и предоставить им ограниченный набор прав.

О BUILTIN\Administrators. С помощью данной учетной записи члены группы Windows NT Administrators домена, в котором установлен локальный SQL Server 2000, получают права доступа к серверу. Учетная запись BUILTIN\Administrators по умолчанию включена в фиксированную роль сер вера, т. е. администраторы сети по умолчанию имеют права на управление сервером. Если обязанности администратора сети и администратора SQL Server 2000 выполняет один и тот же человек, то ничего страшного в этом нет. В противном случае лучше исключить учетную запись BUILTIN\ Administrators из роли sysadmin.

Роли сервера В SQL Server 7.0 был добавлен новый механизм — роли (roles), которые пришли на смену группам SQL Server 6.x. В SQL Server 2000 доступны как роли, так и группы.

Роли — это не просто средство объединения учетных записей в группы с целью упрощения администрирования. Включив учетную запись в ту или иную роль сервера, можно предоставить ей определенный набор прав по администрирова нию сервера. Никаким другим способом выдать права на выполнение этих опе раций невозможно. В SQL Server 2000 имеются две группы ролей:

О роли сервера (server role);

О роли базы данных (database role).

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

Часть III. Администрирование Набор ролей сервера строго ограничен. Никто, включая администратора серве ра, не может создать новую или удалить существующую роль сервера. Поэтому они называются фиксированными ролями (fixed server roles). В табл. 91 приведен список фиксированных ролей сервера с кратким описанием каждой из них.

Таблица 9.1. Фиксированные роли сервера Встроенная роль сервера Описание Члены этой роли имеют абсолютные права в SQL sysadroin Server 2000. Никто не имеет больших прав доступа, чем (System Administrators) члены данной роли Этой роли предоставлены права управления связанными setupadmin серверами, конфигурирования хранимых процедур, запус (Setup Administrators) каемых автоматически при старте SQL Server 2000, а так же право добавлять учетные записи в роль setupadmin Обычно в эту роль включаются пользователи, которые serveradmin должны выполнять администрирование сервера. Имеют (Server Administrators) право на останов сервера (SHUTDOWN), изменять парамет ры работы служб (sp_conf igure), применять изменения (RECONFIGURE), управлять полнотекстовым поиском (sp_fulltext_service) securityadmin Члены данной роли имеют возможность создавать новые (Security Administrators) учетные записи, которым они могут предоставлять права на создание баз данных и ее объектов, а также управлять связанными серверами, включать учетные записи в роль securityadmin и читать журнал ошибок SQL Server processadmin Могут управлять процессами, которые реализует SQL (Process Administrators) Server2000, т.е. выполнять команду K I L L. Также имеют право включать учетные записи в роль processadmin diskadmin Данная роль в основном используется для обеспечения (Disk Administrators) совместимости с SQL Server до версии 7.0. В этих версиях базы данных располагались на устройствах (device). Члены роли diskadmin имеют права управления устройствами, которые, однако, в SQL Server 2000 не используются, а вызовы устаревших процедур транслируются в вызовы современных процедур dbcreator Члены этой роли могут создавать новые базы данных, уда (Database Creators) лять и переименовывать имеющиеся, восстанавливать резервные копии базы данных и журнала транзакций Эта роль не существовала в SQL Server 7.0. Члены роли bulkadmin (Bulk Insert administrators) bulkadmin могут вставлять данными с помощью средств массивной закачки, не имея непосредственного доступа к таблицам В SQL Server 6.x управление сервером было возможно только с правами адми нистратора. Отсутствовала возможность, например, предоставить пользователю только права на создание баз данных и ее объектов. Можно было предоставить Глава 9. Система безопасности SQL Server 2000 пользователю либо полный доступ по управлению сервером, либо не предостав лять его вовсе.

В SQL Server 2000 администратор может более гибко контролировать сервер.

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

Для добавления учетной записи пользователя в ту или иную фиксированную роль сервера можно воспользоваться вкладкой Server Roles окна создания нового поль зователя (см. рис. 9.5) И И хранимой процедурой sp_addsrvrolemember, имеющей Л следующий синтаксис:

sp_addsrvrolemember [@loginame =] 'login', [Srolename =] ' r o l e ' ( Замечание ^ Члены роли sysadmin могут добавлять учетные записи в любую фиксированную роль сервера. Кроме того, учетная запись может быть добавлена в фиксированную роль сервера любым пользователем, являющимся членом этой роли.

Параметр @ioginame определяет имя учетной записи, которую предполагается до бавить в одну из фиксированных ролей сервера. Имя роли, в которую необходимо добавить учетную запись, указывается с помощью параметра @roiename. Как вид но из синтаксиса, для работы процедуры требуется указание обоих параметров. В качестве примера рассмотрим добавление учетной записи Windows NT с именем Admin компьютера STORAGE в фиксированную роль сервера sysadmin:

EXEC sp_addsrvrolemember 'STORAGE\Admin', 'sysadmin' ( Замечание ^ Хотя в общем случае требуется, чтобы на сервере существовала учетная запись, которую предполагается включить в одну из фиксированных ролей, для учетных за писей Windows NT существует исключение. Дело в том, что пользователь Windows NT может получить доступ к SQL Server 2000 как член группы Windows NT, которой предоставлен доступ к серверу. Такие учетные записи данной ОС можно включать в роли сервера без предварительного предоставления доступа непосред ственно учетной записи.

Для получения информации о том, какая учетная запись в какую фиксированную роль сервера включена, используется следующая системная хранимая процедура:

sp_helpsrvrolemember [ [@srvrplename =] 'role'] Если процедура вызывается без параметров, то выводится полный список учет ных записей, включенных в любую из ролей сервера. Когда же необходимо по лучить список учетных записей, включенных в конкретную роль сервера, требу ется указать имя роли с помощью параметра Osrvroiename. В приведенном ниже примере выводится информация о членах роли sysadmin:

EXEC sp_helpsrvrolemember •sysadmin' 224 Часть III. Администрирование Список фиксированных ролей сервера был приведен в табл. 9.1. Его также можно получить с помощью команды:

E E sp_helpsrvrole XC Будет возвращен результат:

ServerRole Description sysadmin System Administrators securityadmin Security Administrators serveradmin Server Administrators setupadmin Setup Administrators processadmin Process Administrators diskadmin Disk Administrators dbcreator Database Creators bulkadmin Bulk Insert administrators (8 row(s) affected) ( Замечание ^ Список фиксированных ролей сервера хранится в недокументированной системной таблице spt_vaiues, которая также служит для хранения множества другой сис темной информации.

Для удаления учетной записи из фиксированной роли сервера предназначена системная хранимая процедура sp_dropsrvroiemember, имеющая синтаксис:

sp_dropsrvrolemember [@loginame =] 'login', [@rolename =] 'role' Назначение параметров этой хранимой процедуры аналогично назначению па раметров процедуры sp_addsrvroiemember, рассмотренной ранее в этом разделе.

Система безопасности базы данных В этом разделе будет подробно рассмотрено управление системой безопасности базы данных. В ранее обсуждалось предоставление прав доступа к самому SQL Server 2000. Но этого недостаточно, чтобы работать с информацией в базах дан ных. Исключением являются пользователи, учетные записи которых включены в фиксированную роль сервера sysadmin. Члены данной роли имеют неограни ченные права в пределах сервера, и, как следствие, полный доступ к любой базе данных, имеющейся на сервере.

Пользователи Пользователь базы данных (user) — это административная единица системы безопасности, через которую предоставляется доступ учетной записи к объектам базы данных. Через права, выданные пользователю базы данных, администратор может контролировать действия, которые станет выполнять владелец учетной Глава 9. Система безопасности SQL Server 2000 записи в той или иной базе данных. Отметим, что единственная учетная запись способна отображаться во множество пользователей различных баз данных.

Система безопасности SQL Server 2000 построена таким образом, что пользователь должен только однажды идентифицировать себя при подключении к серверу. По сле этого учетной записи присваивается специальный идентификатор, через кото рый она получает доступ ко всем объектам SQL Server 2000. Как мы уже сказали.

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

Создание пользователя Связывание учетной записи с пользователем базы данных можно выполнить несколькими способами. Первый из них мы уже рассмотрели (см. разд. "Ис пользование Enterprise Manager" ранее в этой главе). Это можно сделать из окна свойств учетной записи, перейдя на вкладку Database Access.

Второй способ связывания учетной записи с пользователем базы данных также предполагает применение интерфейса Enterprise Manager. Откройте в левой час ти окна Enterprise Manager базу данных, к которой необходимо предоставить доступ учетной записи, и выберите папку Users. В правой части окна (рис. 9.10) будет выведен список всех пользователей, созданных ранее в базе данных, а ин формация о них представлена в столбцах:

О Name. Имя пользователя базы данных. Максимальная длина — 128 символов.

Допускается указание символов национальных алфавитов.

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

• Database Access. В этом столбце указано, предоставляется пользователю дос туп к базе данных (Permit), или, наоборот, запрещается (Deny).

Для создания нового пользователя и связывания его с учетной записью средст вами Enterprise Manager необходимо в контекстном меню папки User (или непо средственно в контекстном меню любого пользователя) выбрать команду New Database User. В ответ откроется диалоговое окно Database User Properties - New User (рис. 9.11), в котором можно выполнить все необходимые действия.

В раскрывающемся списке Login name необходимо выбрать учетную запись, кото рой требуется предоставить доступ к базе данных. Список содержит все учетные записи, созданные на сервере, за исключением тех, которым уже предоставлен доступ к текущей базе данных. В поле User name указывается имя пользователя базы данных, под которым будет работать учетная запись. По умолчанию предла гается имя, аналогичное имени учетной записи, но разрешается использование любого имени. Единственным условием является его уникальность в пределах те кущей базы данных. Будьте внимательны при выборе имени, т. к. изменить его средствами Enterprise Manager невозможно.

Часть III. Администрирование Рис. 9.10. Папка Users В нижней части окна приведен список ролей базы данных, в которые можно включить создаваемого пользователя. Для этого достаточно установить флажок слева от имени нужной роли. Нажав кнопку Properties, можно открыть диалоговое окно, в котором приведен список пользователей, включенных в ту или иную роль.

При необходимости в этом же окне можно добавить новых или исключить имею щихся пользователей из роли базы данных.

В окне Database User Properties - New User имеется кнопка Permissions, недос тупная во время создания нового пользователя. В дальнейшем, если открыть окно свойств пользователя, с помощью данной кнопки можно вызвать диалого вое окно, в котором возможно управлять разрешениями на доступ пользователя к любым объектам базы данных.

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

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

Глава 9. Система безопасности SQL Server Рис. 9. 1 1. Диалоговое окно Database User Properties - New User Специальные пользователи В любой базе данных автоматически создаются два пользователя:

П dbo (database owner). Это специальный пользователь базы данных, являю щийся ее владельцем. Владелец базы данных имеет абсолютные права по управлению ею. Пользователя dbo нельзя удалить. По умолчанию в пользова теля dbo отображается учетная запись sa, которой тем самым предоставляют ся максимальные права в базе данных. Кроме того, все члены роли базы данных dbowner также считаются владельцами базы данных. Пользователь dbo включен в роль db_owner и не может быть удален из нее;

• guest. Если учетной записи явно не предоставлен доступ к базе данных, то она автоматически отображается сервером в пользователя guest. С помощью этого пользователя можно предоставлять разрешения на доступ к объектам базы данных, необходимые любому пользователю. Разрешив доступ пользо вателю guest, вы, тем самым, даете аналогичные права доступа всем учетным записям, сконфигурированным на SQL Server 2000. Для повышения безопас ности хранящейся информации рекомендуется удалять пользователя guest из базы данных.

Управление пользователями средствами Transact-SQL В предыдущих разделах текущей главы была дана некоторая информация о созда нии и управлении пользователями базы данных с помощью средств Enterprise Manager. Этой информации вполне достаточно для выполнения административ Часть III. Администрирование ных задач. Однако, как и большую часть всех административных задач, управле ние пользователями можно осуществлять и средствами Transact-SQL. Хотя подоб ные действия требуют высокой квалификации, они открывают перед администра тором широкие возможности по управлению пользователями и устранению некоторых проблем, бороться с которыми средствами Enterprise Manager просто невозможно. Следующие несколько разделов будут посвящены рассмотрению средств Transact-SQL, с помощью которых можно конфигурировать свойства о пользователях, а также рассмотрению принципов хранения информации о них.

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

с Замечание В таблице sysusers помимо информации о пользователях базы данных также хра нятся сведения о фиксированных и пользовательских ролях базы данных и ролях при ложения. Более подробно роли базы данных будут рассмотрены далее в этой главе.

Таблица 9.2. Список столбцов таблицы sysusen Имя столбца Тип данных Краткое описание uid Указывается идентификатор пользователя (роли), smallint уникальный в пределах базы данных. Пользователю dbo при создании БД присваивается идентификатор 1.

а пользователю guest — идентификатор 2. Иденти фикаторы фиксированных ролей начинаются с номе ра 16 384, а пользовательских — с 16 status smallint Битовое поле, определяющее статус пользователя (роли). Не документировано. Предназначено для внутреннего применения Имя, присвоенное пользователю (роли) при создании.

sysname Можно легко изменять имена пользователей, ис правляя значение в этом столбце sid varbinary(85) Идентификатор безопасности учетной записи, свя занной с рассматриваемым пользователем. Для учетных записей SQL Server идентификатор обяза тельно должен иметься в столбце s i d системной таблицы s y s l o g i n s системной БД Master. Для учетных записей Windows NT идентификатор соот ветствует доменному идентификатору безопасности и не обязательно присутствует в таблице syslogins {для пользователей, получающих доступ к серверу через членство в группе Windows NT) Глава 9. Система безопасности SQL Server 2000 Таблица 9.2 (продолжение) Краткое описание Имя столбца Тип данных varbinary(2048) Двоичное поле, определяющее членство пользовате roles ля в ролях сервера. Если пользователь является чле ном той или иной роли, то соответствующий бит уста навливается в 1. Таким образом, максимальное количество ролей SQL Server 2000 ограничено коли чеством 16 createdate datetime Дата создания пользователя (роли) updatedate datetime Дата последнего изменения свойств пользователя (роли) altuid smallint Альтернативный идентификатор пользователя. Не документировано. Предназначено для внутреннего использования password varbinary(256) В этом столбце хранится пароль для ролей приложе ния. Для пользователей, фиксированных и пользова тельских ролей базы данных в этом столбце содер жится значение NULL gid smallint Идентификатор группы, членом которой является пользователь. Если значение в этом столбце равно значению в столбце s i d, то текущая строка описыва ет пользовательскую роль БД environ varchar(255) В настоящее время данный столбец не используется и содержит значение NULL hasdbaccess int Если содержит 1, то пользователь имеет доступ к базе данных islogin int Если содержит 1, то текущая строка соответствует учетной записи (SQL Server, пользователя или группы Windows NT) isntname int Если содержит 1, то пользователь является отобра жением учетной записи пользователя или группы Windows NT isntgroup int Если содержит 1, то пользователь является отобра жением учетной записи группы Windows NT Если содержит 1, то пользователь является отобра isntuser int жением учетной записи пользователя Windows NT issqluser int Если содержит 1, то пользователь является отобра жением учетной записи пользователя SQL Server isaliased int Если содержит 1, то пользователь является псевдо нимом другого пользователя. Актуально для учетных записей SQL Server 6.x Часть ///. Администрирование Таблица 9.2 (окончание) Краткое описание Тип данных Имя столбца issqlrole int Если содержит 1, то текущая строка соответствует пользовательской или фиксированной роли базы данных isapprole int Если содержит 1, то текущая строка соответствует роли приложения Как видно, структура таблицы sysusers довольно сложна. Тем не менее, вы полнение некоторых задач требует прямого доступа к этой таблице и невозмож но иными способами. Например, если вы присоединяете (attach) базу данных с другого сервера, то соответствия между учетными записями и пользователями базы данных будут наверняка нарушены. То есть, хотя в базе данных и будут существовать пользователи, они не могут быть связаны с реальными учетными записями. Это произойдет даже в том случае, когда на сервере имеются учетные записи с теми же именами, что и на исходном сервере.

( Замечание^ ^ Описанная проблема не касается учетных записей Windows NT, т. к. их идентифика торы безопасности постоянны в пределах домена. Однако, если вы переставляете домен (или отдельный компьютер), то создаваемые пользователи (даже с теми же именами, что и ранее) будут иметь новые идентификаторы безопасности и не смо гут получить доступ к старым базам данных.

Описанную проблему можно легко решить, всего-навсего изменив значение в столбце sid для соответствующего пользователя. В SQL Server 2000 имеется функция S U S E R _ S I D O, с помощью которой можно получить идентификатор безопасности как учетной записи SQL Server, так и учетной записи пользователя или группы Windows NT. Значение, возвращаемое функцией SUSER_SIDO, мо жет быть непосредственно сохранено в столбце s i d таблицы sysusers.

Например, если мы присоединили базу данных с помощью хранимой процеду ры sp_attach_db, но для пользователя базы данных L i i i y a нарушена связь с учетной записью Windows NT с именем L i i i y a домена matrix, то можно легко восстановить эту связь с помощью следующей команды:

USE pubs UPDATE sysusers SET sid = SUSER_SID('matrix\Liliya') WHERE name = 'Liiiya Замечание Напомним, что для изменения системных таблиц на уровне сервера должен быть разрешен прямой доступ к системным таблицам и базам данных. Для разрешения подобного доступа можно использовать команду EXEC spconfigure ' a l l o w update', 1.

Глава 9. Система безопасности SQL Server 2000 Просмотр информации о пользователях Одним из способов получения информации о пользователях базы данных явля ется применение команды SELECT ДЛЯ выборки необходимых данных непосред ственно из системных таблиц. Однако получение информации о пользователях путем просмотра таблицы sysusers представляется довольно затруднительным.

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

Более удобным механизмом получения информации о пользователях текущей базы данных является системная хранимая процедура spheipuser:

USE pubs EXEC sp_helpuser Будет получен примерно следующий результат:

UserName GroupName LoginName DefDBName UserlD SID Admin public NULL NULL 6 0x0542A973F Casper public Casper pubs 5 0x04456EC db owner dbo sa master 1 0x guest db datareader NULL NULL 2 0x ( Замечание ^ Для первых двух пользователей указана только часть идентификатора безопасности пользователей Windows NT, т. к. размер страницы не позволил вместить его весь.

Как видно, для пользователя Admin не указано ни имя учетной записи, ни база данных по умолчанию. Дело в том, что этот пользователь получает доступ к серверу на основе учетной записи Windows NT, как член группы Windows NT.

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

• sp_adduser. Данная процедура оставлена для обеспечения совместимости с предыдущими версиями SQL Server и оперирует устаревшими понятиями.

• sp_grantdbaccess. Эта хранимая процедура полностью соответствует поня тиям системы безопасности SQL Server 2000 и пришла на смену предыдущей процедуре, начиная с версии SQL Server 7.0.

Мы не будем рассматривать spadduser, ограничившись рассмотрением сис темной хранимой процедуры sp_grantdbaccess, имеющей следующий синтак сис:

sp_grantdbaccess [Ologiname =] ' l o g i n [,[@name_in_db =] 'name_in_db' [OUTPUT]] 232 Часть III. Администрирование ( Замечание } Правом вызова указанной хранимой процедуры обладают члены фиксированной роли сервера sysadmin и члены фиксированных ролей базы данных dbowner и db_accessadmin.

Параметр gioginame определяет имя учетной записи, которой предполагается предоставить доступ к текущей базе данных. Указанная учетная запись должна существовать на сервере. С помощью параметра @name_in_db указывается имя, которое будет присвоено создаваемому пользователю. Это имя должно быть уникальным в пределах базы данных.

Приведенный далее пример иллюстрирует использование хранимой процедуры s p g r a n t d b a c c e s s. В базе данных pubs создается новый пользователь с именем Admin, который связывается с учетной записью STORAGE\Admin:

USE pubs EXEC sp_grantdbaccess 'STORAGE\Admin', 'Admin' Замечание Хотя и было сказано, что с помощью параметра @loginame должно указываться только имя учетной записи, созданной на сервере, можно нарушать это правило при предоставлении доступа учетным записям Windows NT, получающим доступ к SQL Server 2000 через членство в группе Windows NT.

Удаление пользователя Удаление пользователя выполняется с помощью системной хранимой процеду ры sp_revokedbaccess, имеющей синтаксис:

sp_revokedbaccess [@name_in_db =] 'name' (~ Замечание ( Правом вызова указанной хранимой процедуры обладают члены фиксированной роли сервера sysadmin и члены фиксированных ролей базы данных db_owner и db_accessadmin.

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

Например, для удаления пользователя Admin достаточно будет выполнить команду:

EXEC sp_revokedbaccess 'Admin' Глава 9. Система безопасности SQL Server 2000 233_ Кроме хранимой процедуры sprevokedbaccess для удаления пользователя можно применять процедуру s p d r o p u s e r, которая используется подобно про цедуре sp_revokedbaccess и имеет схожий синтаксис:

sp_dropuser [@name_in_db =] ' u s e r ' Указанная хранимая процедура, как и процедура s p a d d u s e r, является устарев шей и оставлена в SQL Server 2000 для обеспечения совместимости с предыду щими версиями.

Роли базы данных В разд. "Роли сервера"ранее в этой главе было дано объяснение понятию "роли" и их назначению. В SQL Server 2000, как мы уже говорили, существуют роли двух уровней: уровня сервера и уровня базы данных. В разд. "Роли сервера"'были рассмотрены фиксированные роли сервера, и дано краткое их описание. Теку щий раздел посвящен ролям базы данных, их типам и назначению.

В базе данных SQL Server 2000 имеются три следующих типа ролей:

• фиксированные роли базы данных (fixed database role);

П пользовательские роли базы данных (user database role);

О роли приложений (application role).

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

Рассмотрим более подробно роли каждого типа.

Фиксированные роли базы данных Фиксированные роли делают возможным предоставление пользователям набора прав, которые нельзя организовать никаким другим способом. Количество и назначение фиксированных ролей стандартно и не может быть изменено. Кроме того, нельзя управлять правами доступа фиксированных ролей к объектам базы данных.

SQL Server 2000 позволяет включать пользователей базы данных, учетные запи си SQL Server и Windows NT, а также фиксированные роли сервера и группы Windows NT в фиксированные роли базы данных.

) ( Замечание Отметим, что средствами Enterprise Manager можно включить в роль только пользо вателя базы данных. Тем не менее, в SQL Server 2000 существует набор системных хранимых процедур, позволяющих более гибко управлять членством пользователей в ролях базы данных.

Часть III. Администрирование В табл. 9.3 приведен список фиксированных ролей базы данных с кратким опи санием каждой из них.

Таблица 9.3. Фиксированные роли базы данных Краткое описание Название роли db_securityadmin Члены роли могут управлять правами доступа к объектам базы данных других пользователей и членством их в ролях db_owner Члены роли имеют права владельца, т.

е. могут выполнять любые действия db_denydatawriter Членам этой роли запрещено изменение данных независимо от выданных им разрешений db_denydatareader Членам данной роли запрещен просмотр данных независимо от выданных им разрешений db_ddladmin Члены роли могут создавать, изменять и удалять объекты базы данных db_datawriter Пользователи, включенные в эту роль, могут изменять данные в любой таблице или представлении базы данных db_datareader Пользователи, включенные в эту роль, могут читать данные из любых таблиц и представлений базы данных db_backupoperator Члены роли выполняют резервное копирование базы данных db accessadmin Члены роли имеют право управлять пользователями базы данных: создавать, удалять и изменять Как видно, фиксированные роли базы данных являются весьма полезным сред ством, с помощью которого можно заметно упростить администрирование безо пасности БД. В табл. 9.3 не была рассмотрена еще одна фиксированная роль, имеющая специальные функции — public. В эту роль нельзя включать пользо вателей. Любой пользователь, созданный в базе данных, автоматически включа ется в роль public, и нет никакой возможности исключить его из этой роли.

Единственная допустимая операция сводится к управлению членством пользо вательских ролей в роли public. Но особого смысла в этом нет, т. к. Любой член пользовательской роли уже является членом роли public.

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

Глава 9. Система безопасности SQL Server 2000 Управление фиксированными ролями средствами Transact-SQL В одном из предыдущих разделов было сказано, что набор фиксированных ро лей базы данных, как и фиксированных ролей сервера, постоянен и не может изменяться. Однако это утверждение касается лишь встроенных средств управ ления фиксированными ролями базы данных. Владелец базы данных может ис пользовать команды UPDATE, INSERT и DELETE для внесения изменений в сис темную таблицу sysusers, в которой и хранится информация о фиксированных ролях базы данных.

Другими средствами (например, с помощью системных хранимых процедур или средствами Enterprise Manager) внесение изменений в свойства фиксированных ролей базы данных невозможно. В частности, при попытке удаления фиксиро ванной роли с помощью хранимой процедуры s p d r o p r o l e, успешно исполь зуемой для удаления пользовательских ролей, будет выдано сообщение о невоз можности удаления соответствующей роли. Например, попытаемся удалить фиксированную роль db_ddiadmin:

USE pubs EXEC sp_droprole 'db_ddladmin' Будет выдано следующее сообщение об ошибке:

Server: Msg 15142, Level 16, State 1, Procedure sp_droprole, Line Cannot drop the role 'db_ddladmin'.

Однако ничто не мешает удалить роль с помощью команды DELETE:

USE pubs DELETE F O s y s u s e r s W E E name = 'db_ddladmin' RM HR Подобным способом можно вносить и другие изменения в свойства фиксиро ванных ролей базы данных. Однако не следует злоупотреблять подобными воз можностями. Тем не менее, приведем запрос, с помощью которого можно соз дать новую фиксированную роль базы данных с именем NewFixedRoie:

USE pubs INSERT INTO sysusers (uid, s t a t u s, [name], s i d, createdate, updatedate, a l t u i d, [password], r o l e s ) SELECT 16395, 0, 'NewFixedRoie1, NULL, GETDATEO, GETDATEf), 1, NULL, 0x Изюминкой, позволившей создать новую фиксированную роль базы данных, является то, что сервер воспринимает все строки таблицы sysusers, имеющие в столбце uid значения от 16 384 до 16 399 включительно, в качестве фиксиро ванных ролей. Приведенный запрос можно применять для создания более од ной роли, подставляя вместо значения 16 395 соответствующее значение с со блюдением его уникальности.

( Замечание } Если создать новую фиксированную роль в базе данных M o d e l, то каждая новая ор ганизуемая база данных будет содержать дополнительную фиксированную роль.

236 Часть III. Администрирование Дополнительно можно предоставить этой роли определенные права, внеся соответ ствующие изменения в системную таблицу syspermissions.

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

Замечание Редко кто на практике станет создавать новые фиксированные роли базы данных.

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

Для получения информации о ролях базы данных можно применять системную хранимую процедуру sp_helprole:

USE pubs EXEC sp_helprole Будет возвращен примерно следующий результат:

RoleName Roleld IsAppRole public 0 О dbowner 16384 О db_accessadmin 16385 О db_securityadmin 16386 О db_ddladmin ' 16387 О db_backupoperator 16389 О db_datareader 16390 db_datawriter 16391 db_denydatareader 16392 db_denydatawriter 16393 NewFixedRole 16395 (11 row(s) affected) Как видно, процедура выводит сведения об имени роли, ее идентификаторе и флаг, говорящий о том, является ли соответствующая роль ролью приложения.

Добавление членов в фиксированную роль Чтобы включить нового члена в фиксированную роль базы данных, необходимо вызвать системную хранимую процедуру sp_addrolemember, имеющую синтаксис:

sp_addrolemember [grolename =] ' r o l e 1, [gmembername =] 'security_account' С помощью параметра Sroiename указывается имя роли, в которую требуется добавить нового члена. Указанная роль должна существовать в текущей базе Глава 9. Система безопасности SQL Server 2000 данных. При работе с фиксированными ролями их список постоянен. Однако хранимая процедура spaddroiemember может использоваться и для включения членов в пользовательскую роль базы данных.

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

В качестве примера рассмотрим включение пользовательской роли AccessedUser В фиксированную роль базы данных dbaccessadmin:

EXEC sp addrolemember 'db_accessadmin', 'AccessedUser' Просмотр списка членов фиксированной роли При работе с большими базами данных, имеющими множество пользователей, администратор вряд ли будет точно помнить порядок размещения пользователей по фиксированным ролям. Для получения подобной информации можно при менить следующую хранимую процедуру:

sp_helprolemember [[Srolename =] 'role'] Если процедура вызывается без указания параметра, то будет выведена инфор мация о членах всех ролей базы данных. Если необходимо получить список членов конкретной роли, то можно воспользоваться параметром grolename, ука зав с его помощью имя интересующей роли.

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

USE pubs EXEC sp_helprolemember Будет получен примерно такой результат:

DbRole MemberName MemberSID AccessedUser Access NULL db accessadmin AccessedUser NULL db datareader guest 0x db owner Access NULL db owner AccessedUser NULL dbo db owner 0x NewFixedRole Casper 0x43940DBCA5C63C4D9F407BFCCCB34CD NewFixedRole Mayor NULL (8 row(s) affected) Исключение члена из фиксированной роли Когда необходимо исключить из фиксированной роли одного из членов, то для этого можно обратиться к хранимой процедуре sp_droprolemember, имеющей следующий синтаксис:

sp_droprolemember [Qrolename =] ' r o l e, [Smembername =] ' s e c u r i t y account Часть III. Администрирование С помощью первого параметра указывается имя роли, из которой предполагается исключить члена. Имя самого члена указывается с помощью второго параметра.

Например, для исключения из фиксированной роли dbaccessadmin пользова тельской роли AccessedUser необходимо выполнить следующую команду:

USE pubs EXEC sp_droprolemember 'db accessadmin', 'AccessedUser' Пользовательские роли базы данных Если фиксированные роли предназначены для наделения пользователей специ альными правами в базе данных, то пользовательские роли служат лишь для группировки пользователей с целью облегчения управления их правами доступа к объектам.

Если в базе данных существуют пользователи, которым необходимы одинаковые права доступа, то лучше объединить их в единую административную единицу, чем управлять каждым из них по отдельности. Если сотрудник переходит в другой отдел, то достаточно исключить его из одной роли и добавить в другую, а не просматривать все объекты базы данных и корректировать права доступа пользователя к ним. Пользовательские роли в SQL Server 2000 можно сравнить с группами SQL Server 6.x и группами Windows NT.

Рис. 9.12. Папка Rotes Глава 9. Система безопасности SQL Server Список ролей базы данных можно просмотреть в папке Roles (рис. 9.12) базы данных средствами Enterprise Manager. Информация о ролях базы данных ото бражается в двух столбцах:

• Name — имя роли;

П Role Type — тип роли. Допускаются типы Standard (стандартная роль) и Application (роль приложения).

Для создания новой пользовательской роли средствами Enterprise Manager нуж но в контекстном меню папки Roles выбрать команду New Database Role. В от крывшемся диалоговом окне Database Role Properties - New Role (рис. 9.13) в поле Name необходимо указать имя роли, уникальное в пределах базы данных.

С помощью переключателей группы Database role type необходимо выбрать тип создаваемой роли. Если установлен переключатель Standard role, с помощью кнопки Add можно сразу же добавить нужных пользователей в создаваемую роль. Выбрав переключатель Application role, необходимо указать пароль, с по мощью которого будет инициализироваться роль. Более подробно работа с ро лями приложения рассмотрена в следующем разделе.

Рис. 9.13. Окно создания новой роли Управление пользовательскими ролями средствами Transact-SQL Как было сказано при рассмотрении управления пользователями средствами Transact-SQL, сведения о ролях базы данных, в т. ч. и о пользовательских, хра 9 Змс. 240 Часть III. Администрирование нятся в системной таблице sysusers, которая имеется в каждой базе данных.

Таким образом, таблица sysusers содержит множество информации о пользова телях, фиксированных и пользовательских ролях базы данных, а также о ролях приложения. Выделить среди прочей информации только строки, описывающие пользовательские и фиксированные роли базы данных, можно с помощью столбца i s s q i r o i e. Если данный столбец содержит значение 1, то соответст вующая строка содержит описание роли приложения. Однако это не все. Необ ходимо отделить пользовательские роли от фиксированных. Это можно сделать с помощью столбца gid. Если в указанном столбце содержится значение, равное значению в столбце sid, то соответствующая строка описывает пользователь скую роль. Помимо этого, идентификаторы пользовательских ролей (значение в столбце sid) начинаются с 16 400.

С С Замечание ^ Напомним, что идентификатор фиксированной роли p u b l i c равен 0.

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

USE pubs SELECT * FROM sysusers WHERE issqiroie = 1 AND sid = gid SELECT * FKOM sysusers WHERE gid. = ' SELECT * FROM sysusers WHERE sid = Для получения информации о пользовательских ролях приложения также можно применять хранимую процедуру s p h e l p r o l e, которая была рассмотрена в преды дущем разделе. Для выделения среди прочей информации только пользователь ских ролей можно использовать столбец Role id — идентификаторы пользователь ских ролей начинаются с 16 400.

Создание пользовательской роли Создание пользовательской роли выполняется с помощью системной хранимой процедуры s p a d d r o l e, которая имеет синтаксис:

sp_addrole [Srolename =] 'role' [, [@ownername =] 'owner'] Л ( Замечание Правом выполнения указанной хранимой процедуры обладают члены фиксирован ной роли сервера sysadmin и фиксированных ролей базы данных db owner и db_securityadmin.

Имя роли, которое необходимо ей присвоить, указывается с помощью парамет ра Oroiename. При выборе имени необходимо придерживаться общих правил именования объектов. Кроме того, требуется соблюдать уникальность имен, ис пользуемых системой безопасности базы данных. То есть нельзя создать пользо вательскую роль с именем, присвоенным ранее пользователю или другой роли любого типа (пользовательской, фиксированной или приложения). Если указы Глава 9. Система безопасности SQL Server 2000 вается имя роли, нарушающее требование уникальности, то будет выдано сле дующее сообщение об ошибке:

Server: Msg 15023, Level 16, State 1, Procedure spaddrole, Line User or role 'ИмяРоли' already exists in the current database.

По умолчанию владельцем роли становится владелец базы данных (пользователь dbo). Таким образом, пользователь dbo приобретает полный контроль над ро лью. Если необходимо присвоить права владения ролью другому пользователю, то имя этого пользователя должно быть указано с помощью параметра Sownername. Указываемый пользователь должен иметься в базе данных. Вла дельцем пользовательской роли может также являться и роль приложения.

В качестве примера рассмотрим создание пользовательской роли Accesseduser, владельцем которой будет являться пользователь guest:

USE pubs EXEC sp_addrole 'Accesseduser, 'guest' Напомним, что до SQL Server 7.0 понятия роли не существовало. Взамен пред лагалось работать с группами. Для обеспечения совместимости с SQL Server 6.x в SQL Server 2000 оставлены хранимые процедуры, которые оперируют поняти ем группа. Однако работа этих процедур сводится к вызову процедур, работаю щих на современном уровне системы безопасности. Например, для добавления новой группы можно применить системную хранимую процедуру spaddgroup.

имеющую синтаксис:

sp_addgroup [@grpname =] ' g r o u p ' Единственный параметр данной процедуры определяет имя группы, которую необходимо создать. Однако выясним, как работает на самом деле эта процеду ра. Для просмотра кода процедуры следует выполнить следующий пакет команд:

USE master EXEC s p _ h e l p t e x t 'sp_addgroup' В ответ будет выведен результат:

Text create procedure sp_addgroup Sgrpname sysname — name of new role as declare Sret int execute @ret = sp_addrole @grpname return @ret Как видно, процедура spaddgroup всего-навсего вызывает хранимую процедуру sp_addroie, что приводит к созданию новой роли, а не группы. Таким образом, видно, что группы в SQL Server 2000 полностью заменены ролями.

у Замечание ) Добавление и удаление пользователей из имеющихся пользовательских ролей, а также получение информации о членстве пользователей в той или иной роли базы 9* 242 Часть III. Администрирование данных, осуществляется точно также, как и при работе с фиксированными ролями базы данных. Напомним, что для добавления нового пользователя в роль предна значена хранимая процедура spaddrolemember, а для удаления — sp_droprolemember.

Удаление пользовательской роли Удаление пользовательской роли осуществляется с помощью хранимой проце дуры sp_droproie, имеющей следующий синтаксис:

sp_droprole [Orolename =] ' r o l e ' С помощью единственного параметра процедуры указывается имя пользователь ской роли, которую необходимо удалить из текущей базы данных. Однако перед подобной операцией нужно удалить из нее всех членов, для чего можно исполь зовать хранимую процедуру spdroproiemember. Если роль владеет одним или более объектами базы данных, то уничтожить такую роль будет невозможно.

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

Т С помощью приведенного ниже примера можно удалить пользовательскую роль AccessesUser:

USE pubs EXEC sp_droprole 'AccessesUser' Роли приложения Если с базой данных работают сотни и тысячи пользователей, то управление их правами доступа к объектам БД становится большой проблемой. Стандартные роли базы не всегда могут снять проблему. В этом случае SQL Server 2000 пред лагает обратиться к роли приложения (application role).

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

( Замечание ^) С точки зрения сервера роль приложения рассматривается как обычный пользова тель. Таким образом, роль приложения может являться владельцем объектов базы данных.

Глава 9. Система безопасности SQL Server 2000 243_ Создание роли приложения с помощью Enterprise Manager было описано в пре дыдущем разделе. Роль приложения не содержит членов. Пользователь, рабо тающий с приложением, не является членом роли приложения. Он лишь ис пользует возможности приложения. При конфигурировании роли приложения следует указать только ее имя и пароль, необходимые приложению при установ лении соединения. Данный пароль приложение может вводить само, но может и требовать его ввода у пользователя. Конкретная реализация зависит от разработ чика приложения. Безопасность при отправке пароля роли приложения по сети можно обеспечить шифрованием.


Сначала пользователь должен установить соединение с сервером. Для этого не обходимо предварительно создать для него учетную запись SQL Server или пре доставить учетной записи пользователя в домене Windows NT доступ к SQL Server 2000. Учетная запись пользователя может отображаться в пользователя базы данных, имеющего определенные права доступа (или запрещение доступа).

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

Если введены верные данные, то SQL Server 2000 предоставляет приложению соответствующие права. Права доступа, полученные через роль приложения, могут конфликтовать с правами доступа пользователя, работающего с приложе нием. Чтобы этого не происходило, система безопасности SQL Server 2000 анну лирует все права в текущем сеансе соединения, выданные учетной записи, поль зователю базы данных или любой из ролей. Происходит как бы потеря информации о личности пользователя. Такой подход позволяет со стопроцент ной гарантией избежать конфликтов доступа и обеспечить приложение правами доступа, независимыми от пользователя, работающего с приложением. После завершения работы приложения права доступа пользователя восстанавливаются.

Если пользователь одновременно открыл несколько сеансов, то права доступа будут потеряны только в соединении, из которого была инициализирована роль.

В других сеансах он будет иметь обычные права доступа.

Поскольку в соединении, в котором была инициирована роль приложения, те ряется вся информация о личности пользователя, то пропадает и возможность установления соединения с серверами и базами данных с правами, выданными работающему с приложением пользователю. Если во внешней базе данных уда лен пользователь guest, то получение доступа к данным невозможно. Чтобы предоставить приложению возможность работы с данными во внешних базах данных, необходимо создать в этих базах пользователя guest. Приложение будет иметь права доступа, выданные пользователю guest непосредственно или как члену роли public.

Чтобы приложение имело различные права доступа к базе данных, требуется создать отдельную роль для каждой задачи и наделить ее необходимыми права ми. Кроме того, если приложению нужен доступ к различным базам данных, и администратор не желает прибегать к созданию пользователя guest, то также следует создать отдельную роль приложения для каждой базы данных. Прило жение само должно заботиться о переключении ролей.

244 Часть III. Администрирование Управление ролями приложения средствами Transact-SQL Как было сказано при рассмотрении управления пользователями средствами Transact-SQL, данные о роли приложения хранятся в системной таблице sysus ers, которая имеется в каждой базе данных. Эта таблица содержит также сведения о пользователях и фиксированных и пользовательских ролях базы данных. Выде лить среди прочей информации только строки, описывающие роли приложения, можно с помощью столбца isapprole. Если данный столбец содержит значение 1, то соответствующая строка хранит описание роли приложения. Кроме этого, для роли приложения столбец password содержит пароль, который необходимо ука зать для активации роли. Для пользователей и других ролей (пользовательских и фиксированных) столбец password имеет значение NULL.

Например, для получения информации о ролях приложения можно выполнить запрос:

OSE pubs SELECT * F O s y s u s e r s W E E i s a p p r o l e = RM HR Для получения информации о ролях приложения также можно вызывать храни мую процедуру s p h e i p r o i e, которая была рассмотрена в одном из предыдущих разделов этой главы. Для ролей приложения в столбце isapprole будет выведено значение !, тогда как для фиксированных и пользовательских ролей будет выве дено значение 0.

Создание роли приложения Создание новой роли приложения в текущей базе данных выполняется с помо щью системной хранимой процедуры s p a d d a p p r o i e, имеющей синтаксис:

sp_addapprole [Srolename =] 'role', [Spassword =] 'password' ( Замечание Правом выполнения указанной хранимой процедуры обладают члены фиксирован ной роли сервера sysadmin и фиксированных ролей базы данных db_owner и db_securityadmin.

Первый параметр процедуры определяет имя, которое должна иметь роль при ложения. При выборе имени роли следует следовать стандартным правилам именования. Кроме того, необходимо соблюдать уникальность имени. То есть ранее в текущей базе данных не должно быть создано роли любого типа с ана логичным именем. С помощью параметра gpassword указывается пароль, кото рый будет использован для активизации роли приложения. Пароль хранится в шифрованном виде в столбце password таблицы sysusers.

В качестве примера рассмотрим создание роли приложения Mayor с паролем marshal:

USE pubs EXEC sp_addapprole 'Mayor', 'marshal' Глава 9. Система безопасности SQL Server 2000 Активизация роли приложения Активизация роли приложения выполняется с помощью следующей системной хранимой процедуры:

sp_setapprole [Srolename =] ' r o l e ', [gpassword =] {Encrypt N 'password'} | 'password' [,[@encrypt =] ' e n c r y p t _ s t y l e ' ] Замечание Правом выполнения указанной хранимой процедуры обладает любой пользователь.

Для активизации роли приложения достаточно знать ее имя и пароль.

Необходимо отметить, что возможна активизация только роли приложения те кущей базы данных. Если необходимо то же самое сделать не для текущей базы данных, то следует установить нужную базу данных в качестве текущей с помо щью КОМаНДЫ USE ИмяБД.

Рассмотрим назначение и использование параметров хранимой процедуры.

П [grolename =] ' r o l e ' С помощью этого параметра указывается имя роли приложения, которую не обходимо активизировать. Указанная роль должна существовать в текущей базе данных. Если же вводится имя несуществующей роли приложения, то будет выдано следующее сообщение об ошибке:

Server: Msg 2763, Level 16, State 1, Procedure sp_setapprole, Line Could not find application role 'ИмяРоли'.

Аналогичное сообщение об ошибке будет отображено и при указании имени фиксированной или пользовательской роли.

О [Spassword =] (Encrypt N 'password'} I 'password' Данный параметр определяет пароль, который будет использован для акти визации роли приложения. Пароль должен быть тем же, что и при создании роли приложения. Если указывается неверный пароль, то будет выдано сле дующее сообщение об ошибке:

Server: Msg 2764, Level 16, State 1, Procedure sp_setapprole, Line Incorrect password supplied for application role 'ИмяРоли'.

Для обеспечения безопасности пароля при передаче его по сети можно приме нить функцию ODBC Encrypt, используя формат параметра [gpassword =] Encrypt N 'password'. Функция Encrypt работает со строками в формате Unicode, поэтому перед паролем необходимо указать символ N, что приведет к преобразованию указанной строки в формат Unicode.

О [Sencrypt =] 'encryptstyle' С помощью этого параметра можно управлять шифрованием пароля при от правке его по сети. Параметр может принимать следующие значения:

• ' попе' — шифрование использоваться не будет;

246 Часть III. Администрирование • • odbc' — для обеспечения безопасности пароля при передаче его по сети будет использоваться функция ODBC Encrypt.

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

В качестве примера рассмотрим активизацию созданной в предыдущем разделе роли Приложения Mayor:

USE pubs EXEC sp_setapprole 'Mayor', 'marshal' В указанном примере пароль по сети передавался в открытом виде. Для иллюст рации применения возможности шифрования пароля продемонстрируем два примера, приводящих к аналогичным результатам:

USE pubs EXEC sp_setapprole 'Mayor', Encrypt N ' m a r s h a l ' EXEC sp_setapprole 'Mayor', ' m a r s h a l ', 'odbc' Замечание Роль приложения автоматически деактивизируется при переключении текущей базы данных с помощью команды USE. Однако допускается выполнение распределенных и удаленных запросов, обращающихся как к различным базам данных текущего сер вера, так и к распределенным гетерогенным источникам данных.

Удаление роли приложения Для удаления роли приложения используется хранимая процедура s p d r o p a p p r o l e, имеющая синтаксис:

sp_dropapprole [@rolename =] ' r o l e ' Г Замечание ^ Правом выполнения указанной хранимой процедуры обладают члены фиксирован ной роли сервера sysadmin и фиксированных ролей базы данных dbowner и db_securityadmin.

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

Server: Msg 15014, Level 16, State 1, Procedure sp_dropapprole, Line The role 'ИмяРоли' does not exist in the current database.

Глава 9. Система безопасности SQL Server 2000 В качестве примера рассмотрим удаление роли приложения Mayor, созданной в одном из предыдущих разделов:

USE pubs EXEC sp dropapprole 'Mayor' ( Замечание ) Перед удалением роли приложения следует убедиться, что она не является вла дельцем каких-либо объектов базы данных. Иначе избавиться от роли не удастся.

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


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

• права доступа к данным;

О права на выполнение хранимых процедур;

• права на выполнение команд Transact-SQL.

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

Другим примером работы неявных прав доступа является получение владельцем объекта абсолютных прав на управление объектом владения. Если пользователь создал объект в базе данных, то ему автоматически предоставляются максималь ные права по управлению этим объектом. Никто, включая администратора, не должен предоставлять пользователю специально эти права. Только факт владе ния объектом обеспечивает пользователю полный контроль. Владелец объекта может передать права владения другому пользователю, предоставляя ему тем самым полный контроль над объектом. Владелец объекта может устанавливать права доступа к объекту для других пользователей базы данных.

Права доступа к данным Доступ к данным можно разделить на несколько категорий:

О INSERT. Это право позволяет вставлять в таблицу или представление новые строки. Как следствие, право INSERT может быть выдано только на уровне таблицы или представления и не может быть выдано на уровне столбца.

248 Часть III. Администрирование П UPDATE. Данное право выдается либо на уровне таблицы, что позволяет изме нять все данные в таблице, либо на уровне отдельного столбца, что разреша ет изменять данные только в пределах конкретного столбца.

П DELETE. Право позволяет удалять строки из таблицы или представления. Как и право INSERT, право DELETE может быть выдано только на уровне таблицы или представления и не может быть выдано на уровне столбца.

• SELECT. Разрешает выборку данных. Может выдаваться как на уровне табли цы, так и на уровне отдельного столбца.

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

Замечание Право REFERENCES не существовало в предыдущих версиях SQL Server.

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

Предоставить или отклонить доступ пользователю базы данных ко всем объек там базы данных можно при помощи особенностей встроенных ролей базы дан ных. Например, для разрешения чтения данных из всех таблиц и представлений базы данных достаточно включить пользователя в фиксированную роль d b d a t a r e a d e r, а не изменять права доступа пользователя к каждой таблице и представлению в отдельности.

Права на выполнение хранимых процедур и функций Единственное право доступа, которое может быть предоставлено для хранимой процедуры — это право на ее выполнение (EXECUTE). ПОМИМО ЭТОГО владелец хранимой процедуры может просматривать и изменять ее код. Для функции кроме права на выполнение также можно выдать право REFERENCES, ЧТО ПОЗВО ЛИТ выполнять связывание функции с объектами, на которые она ссылается.

Такое связывание позволяет запретить внесение изменений в структуру объек тов, которые бы привели к нарушению работы функции.

Право на выполнение хранимой процедуры может быть предоставлено пользо вателям несколькими способами. Например, при помощи Enterprise Manager.

Глава 9. Система безопасности SQL Server Для этого выберите в левой панели Enterprise Manager нужную базу данных и откройте в ней папку Stored Procedures. В правой части Enterprise Manager будет отображен список хранимых процедур, уже созданных в базе данных. Управле ние правами доступа можно осуществлять в окне Object Properties (рис. 9.14), вызвать которое можно либо с помощью кнопки Permissions в окне свойств хранимой процедуры, либо выбрав в контекстном меню хранимой процедуры команду All Tasks, а затем команду Manage Permissions.

Рис. 9.14. Окно Object Properties для домена matrix Чтобы разрешить пользователю выполнять хранимую процедуру, нужно устано вить напротив его имени флажок в столбце EXEC. Чтобы запретить доступ, нужно зачеркнуть флажок. Пустой флажок подразумевает неявное отклонение доступа. Более подробно о правах доступа будет рассказано далее в этой главе.

Управление правами доступа к функциям осуществляется аналогично. При ис пользовании Enterprise Manager необходимо сначала выбрать в левой панели Enterprise Manager нужную базу данных и открыть в ней папку User Defined Functions. В правой части Enterprise Manager будет отображен список пользова тельских функций, имеющихся в базе данных. Управление правами доступа можно осуществлять в окне Object Properties (подобное приведенному на рис. 9.14), вызвать которое можно либо с помощью кнопки Permissions в окне свойств пользовательской функции, либо выбрав в контекстном меню функции команду All Tasks, а затем команду Manage Permissions.

250 Часть III. Администрирование ( Замечание } Другой способ управления правами доступа заключается в предоставлении прав конкретному пользователю с помощью специального окна, вызвать которое можно с помощью кнопки Permissions окна свойств пользователя.

Права на выполнение команд Transact-SQL Мы рассмотрели классы прав доступа, регламентирующих действия пользовате лей в отношении работы с существующими объектами базы данных. Третий класс доступа — права на выполнение команд Transact-SQL — предназначены для управления возможностями пользователя по созданию новых объектов базы данных.

Приведем список прав доступа на выполнение команд Transact-SQL:

• CREATE DATABASE. Право создания базы данных. Выдается учетной записи.

О CREATE TABLE. Право на создание таблицы.

• CREATE VIEW. Право на создание представления.

О CREATE PROCEDURE. Право на создание хранимой процедуры.

О CREATE FUNCTION. Право на создание пользовательской функции.

П CREATE RULE. Право на создание правила.

• CREATE DEFAULT. Право на создание умолчания.

• BACKUP DATABASE. Право на создание резервной копии базы данных.

О BACKUP LOG. Право на создание резервной копии журнала транзакций.

О ALL. С помощью этого права предоставляются все вышеперечисленные права.

Члены фиксированной роли сервера sysadmin и фиксированной роли базы дан ных dbowner автоматически имеют право ALL. Члены других фиксированных ролей имеют набор прав, соответствующих функциям роли.

Управление правами доступа В предыдущих разделах мы рассмотрели, какие классы прав доступа существуют в базах данных SQL Server 2000. В этом разделе описывается предоставление и запрещение пользователям доступа к объектам базы данных.

Когда в базе данных создается новый пользователь, то для него не установлены явно никакие права доступа. Но поскольку новый пользователь автоматически является членом фиксированной роли базы данных p u b l i c, то он автоматически получает набор прав, выданный для этой роли. Если же такого набора прав не достаточно, то необходимо явно предоставить доступ (allow access) к тому или иному объекту базы данных. До тех пор пока администратор не предоставит пользователю необходимые права доступа, тот не сможет выполнять никаких действий с объектами базы данных.

Глава 9. Система безопасности SQL Server 2000 251_ Права доступа могут быть выданы пользователю непосредственно или как члену роли базы данных. Необходимо быть внимательным, планируй права доступа пользователей к объектам базы данных и выдавая им разрешения на выполне ние команд Transact-SQL. Включив по неосторожности пользователя в ту или иную группу Windows NT или роль базы данных, можно предоставить ему лиш ние права.

При управлении правами доступа нужно помнить, что аутентификация Win dows NT имеет приоритет над аутентификацией SQL Server. Рассмотрим сле дующую ситуацию. Администратор планирует доступ пользователю Reader базы данных, в которого отображается учетная запись (login) SQL Server с именем Liiiya. Но пользователь домена, регистрирующийся на сервере под учетной записью L i i i y a, состоит в группе Windows NT, для которой сконфигурирована учетная запись NTGroup3. Эта учетная запись отображается в пользователя Editor, которому предоставлены права доступа, существенно отличающиеся от прав доступа пользователя Reader. В итоге пользователь домена получит набор прав, который ему не положен.

Замечание Чтобы разрешить пользователю изменять данные во всех таблицах и представле ниях, можно включить его в фиксированную роль базы данных d b _ d a t a w n t e r. Для разрешения чтения данных из любой таблицы или представления можно включить пользователя в роль d b _ d a t a r e a d e r.

Для более гибкого управления правами доступа пользователей к данным, хра нящимся в таблицах базы данных, можно устанавливать эти права на уровне отдельного столбца. Также необходимо грамотно предоставлять пользователям права на выполнение команд Transact-SQL. Тщательное планирование прав дос тупа позволит в будущем избежать многих проблем.

( Замечание } В SQL Server 7.0 управление разрешениями на уровне столбцов поддерживалось только средствами Transact-SQL. SQL Server 2000 позволяет управлять правами доступа на уровне столбцов и с помощью Enterprise Manager.

Управление правами доступа пользователей с помощью Enterprise Manager воз можно двумя способами:

О Со стороны объекта. В панели Enterprise Manager необходимо выбрать объ ект, разрешениями к которому предполагается управлять, и открыть окно его свойств, для чего можно дважды щелкнуть левой кнопкой мыши на объекте или в его контекстном меню выбрать команду Properties. Для управления собственно разрешениями в появившемся диалоговом окне необходимо на жать кнопку Permissions, что приведет к открытию окна Object Properties (рис. 9.15). Центральную часть окна занимает список, в котором перечисля ются все имеющиеся в базе данных пользователи (за исключением пользова теля dbo), роли приложения, пользовательские роли базы данных, а также фиксированная роль базы данных public. Имена пользователей приводятся в Часть III. Администрирование самом левом столбце. Следующие столбцы содержат флажки, в которых ука зывается выданное разрешение для каждой из возможных категорий доступа.

Пустой флажок соответствует неявному отклонению доступа, с галочкой — предоставлению доступа, а перечеркнутый крест-накрест — запрещению дос тупа. Раскрывающийся список Object содержит набор всех объектов, имею щихся в базе данных. Для просмотра и управления правами другого объекта достаточно выбрать его в списке Object.

с Замечание Хотя в окне имеются столбцы для всех типов разрешений, они используются не все гда. Список доступных разрешений зависит от типа объекта. Например, разрешение SELECT не применимо к пользовательской функции или хранимой процедуре. С дру гой стороны, разрешение EXECUTE не применимо к таблице или представлению.

Рис. 9.15. Окно Object Properties для домена matrix • Co стороны пользователя. В панели Enterprise Manager нужно выбрать пользо вателя, правами которого предполагается управлять. Список пользователей можно найти в папке Users, имеющейся в каждой базе данных. Управление разрешениями пользователя осуществляется с помощью окна Database User Properties (рис. 9.16), открыть которое можно с помощью кнопки Permissions в окне свойств пользователя. Окно содержит список всех объектов, имеющихся в базе данных, включая и системные. Управление типом разрешения для каждой из категорий доступа осуществляется с помощью флажков. Раскрывающийся Глава 9. Система безопасности SQL Server список Database user содержит перечень всех пользователей, созданных в базе данных. Для конфигурирования прав доступа другого пользователя достаточно выбрать его имя в списке Database user. Данный список содержит также и пользователя dbo. Если выбрать его в списке, можно увидеть, что ему предос тавлены возможные категории доступа ко всем объектам базы данных. Однако изменять права доступа пользователя dbo нельзя. Управление разрешениями со стороны пользователя также включает предоставление прав на уровне пользо вательских ролей базы данных. Конфигурирование прав доступа ролей выпол няется аналогично управлению правами доступа пользователей. Единственно, необходимо нажать кнопку Permissions не в окне свойств пользователя, а в ок не свойств роли. Список ролей с указанием их типа (фиксированная или поль зовательская) можно найти в папке Roles, имеющейся в каждой базе данных.

Допускается управление разрешениями для любой из пользовательских баз данных и фиксированной роли public. Управление правами доступа других фиксированных ролей не разрешено. Отметим, что при работе с Enterprise Manager, поставляемым в составе SQL Server 2000, существует возможность управлять правами доступа не только к таблице целиком, но и к конкретному столбцу в отдельности. Для этого достаточно выбрать в окне Database User Properties нужную таблицу или представление и нажать кнопку Columns. В от вет откроется окно Column Permissions (рис. 9.17), с помощью которого и вы полняется управление правами доступа к столбцу.

Рис. 9.16. Окно Database User Properties базы данных pubs Часть III. Администрирование Рис. 9.17. Окно Column Permissions Предоставление доступа Для предоставления пользователю доступа к объектам базы данных использует ся команда GRANT, имеющая синтаксис:

GRANT { ALL [PRIVILEGES] | permission [,...n] } { [( column [,...n] )] ON {table I view) I ON {table I view} [( column [,...n] )] I ON {stored_procedure I extended_procedure} I ON {user_defined_function} } TO security_account [,...n] [WITH GRANT OPTION] [AS (group I role}] Рассмотрим назначение и использование аргументов команды:

• ALL Указание этого параметра позволяет предоставить пользователю или группе все допустимые права. Однако этот параметр может использоваться только при предоставлении, прав членам фиксированных ролей sysadmin или db owner.

Глава 9. Система безопасности SQL Server 2000 • PRIVILEGES Ключевое слово PRIVILEGES особой роли не играет и может быть с успехом опущено. Оно предназначено только для обеспечения совместимости со стандартом ANSI SQL-92.

П permission [,...n] Этот параметр используется для указания категорий доступа, которые будут выданы пользователю для указанного объекта. Допускается указание сле дующих категорий:

• SELECT — выборка из таблиц, представлений или отдельных столбцов;

• INSERT — вставка строк в таблицу или представление;

• DELETE — удаление строк из таблицы или представления;

• UPDATE — изменение данных в таблице, представлении или отдельном столбце;

• REFERENCES — разрешение ссылаться на таблицу, представление или поль зовательскую функцию;

• EXECUTE — выполнение хранимой процедуры или пользовательской функции.

) ( Замечание При управлении правами доступа с помощью Enterprise Manager категория доступа REFERENCES указывается как DRI (declarative referential integrity, декларативная ссылочная целостность).

[,...п] Параметр указывает на то, что за один раз с помощью команды GRANT поль зователю может быть выдано множество прав.

(column [,... п ] ) Параметр предназначен для указания прав доступа пользователя к одному или более столбцов таблицы или представления. В одной команде GRANT могут быть выданы разрешения более чем для одного столбца. Имя таблицы или представления указывается с помощью следующего параметра. Для столбцов допускается выдача разрешений категорий доступа SELECT И UPDATE.

ON (table I view} Назначает имя таблицы или представления, для которых предоставляется доступ. Если задается параметр (column [,... п ] ), то указанные права будут определены для конкретных столбцов таблицы. В противном случае разре шения будут выданы для всей таблицы или представления. Для таблиц и представлений допускается выдача разрешений категорий доступа SELECT, UPDATE, DELETE, INSERT И REFERENCES.

( Замечание } Выдача разрешений на уровне таблицы или представления отменяет все ранее вы данные разрешения на уровне столбцов.

256 Часть III. Администрирование О ON { t a b l e | view} [( column [,... n ] )] Конструкция является вторым способом указания объекта, разрешениями которого предполагается управлять. Параметр {table | view} определяет имя таблицы или представления, тогда как дополнительный параметр (column [,...п]) задает список столбцов, доступом к которым будет осуще ствляться управление.

П ON {stored_procedure I extended_procedure} Конструкция используется для управления правами доступа к стандартной или расширенной хранимой процедуре. Стандартная хранимая процедура должна принадлежать текущей базе данных. Хотя указание имени базы дан ных дополнительно к имени процедуры и допускается, тем не менее, управ ление правами доступа к процедуре внешней базы данных не поддерживает ся. Исключением является управление правами доступа к расширенным хранимым процедурам, которые располагаются в системной базе данных Master. Указание имени базы данных для процедур этого типа не требуется.

Для хранимых процедур разрешается выдавать только разрешение EXECUTE.

d ON {user_defined_function} Параметр позволяет управлять правами доступа к пользовательской функции.

Для пользовательских функций разрешается выдавать разрешения категорий EXECUTE И REFERENCES.

О security_account [,...n] Данный параметр определяет список пользователей и ролей базы данных, ко торым будут выданы указанные разрешения. Выполнив одну команду GRANT, можно изменить права доступа множества пользователей и ролей базы данных.

• WITH GRANT OPTION При вводе этого параметра пользователям, указанным с помощью предыду щего параметра, будет предоставлено право выдавать другим пользователям разрешения доступа, аналогичные выданным им самим. Однако параметр WITH GRANT OPTION может использоваться только при управлении разреше ниями на уровне объектов. То есть нельзя предоставить пользователям воз можность управлять разрешениями доступа только к конкретному столбцу.

• AS {group I role} Указание этого параметра требуется, когда право на выдачу разрешения вы дано роли- или группе базы данных. Хотя группа или роль может обладать правом предоставления разрешений, тем не менее, выдавать их может только конкретный пользователь, которому непосредственно может быть и не пре доставлено такого права. Использование параметра AS предоставляет воз можность пользователю выдавать разрешения от имени группы или роли, имеющей необходимые права и членом которой является пользователь.



Pages:     | 1 |   ...   | 5 | 6 || 8 | 9 |   ...   | 33 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.