Волк В.К. Базы данных. Практикум по проектированию, программированию и администрированию баз данных, включающий примеры и практические задания для самостоятельного выполнения
 Скачать 3.17 Mb.
|
|
ГЛАВА 16. УПРАВЛЕНИЕ ДОСТУПОМ К ДАННЫМ 16.1. Двухуровневая архитектура управления доступом MS SQL-Server поддерживает двухуровневую архитектуру системы управления доступом к данным (рис. 5.3). Рис. 5.3 Иерархия субъектов и объектов доступа MS SQL-Server На верхнем уровне (уровень сервера) решаются задачи аутентификации пользователей и выдача им глобальных прав выполнения операций с базами данных, управляемыми этим сервером. 21 / 24 212 Объектами доступа на этом уровне являются пользовательские базы дан- ных и типовые операции над ними. В качестве субъектов доступа используются учетные записи пользовате- лей (имена входа, login) и фиксированные роли сервера, за каждой из которых закреплено имя роли и определенный набор разрешений на выполнение опера- ций с базами данных. Учетная запись — это средство идентификации и аутен- тификации пользователя, а роль сервера — средство группировки учетных за- писей для более удобного администрирования. Имеются два способа предо- ставления пользователю разрешений на выполнение глобальных операций с ба- зами данных: индивидуальное назначение требуемых разрешений учетной за- писи пользователя или включение учетной записи в качестве члена в соответ- ствующую серверную роль. На нижнем уровне (уровень базы данных, доступ к которой получили пользователи через соответствующие учетные записи), решаются задачи раз- граничения прав их доступа к логическим объектам этой базы данных, а также задача шифрования данных объектов доступа. Основные субъекты доступа нижнего уровня — это пользователи базы данных и роли базы данных, используемые для группового управления правами доступа пользователей к объектам базы данных. При этом пользователь базы данных всегда связан с определенной учетной записью, «предъявляемой» им на этапе аутентификации. На уровне базы данных поддерживаются три категории ролей: – предопределенный набор фиксированных ролей базы данных, через членство в которых пользователи получают соответствующие права доступа ко всем объектам базы; – формируемые администратором пользовательские роли, члены которых могут получать необходимые права доступа к любым логическим объектам ба- зы данных; – роли приложений, членство пользователей в которых не предусмотрено, а права доступа, назначенные этой ролью, предоставляются клиентскому при- ложению, через которое пользователь подключается к базе данных. Состав, имена и права доступа фиксированных ролей базы данных ко всем ее объектам также фиксированы, у администратора остается право управ- ления членством пользователей в ролях этого типа. Пользовательские роли ба- зы данных администратор вправе создавать, именовать и назначать им права доступа к логическим объектам базы по своему усмотрению (например, в соот- ветствии с организационной структурой предприятия и должностными функ- циями сотрудников). Основные объекты доступа на уровне базы данных — это схемы, таблицы и представления, отдельные столбцы таблиц и представлений, а также про- граммные компоненты базы данных — хранимые процедуры и функции, кото- рые, заметим, одновременно являются и субъектами доступа и могут наделять- ся соответствующими правами. 22 / 24 213 16.2. Управление доступом на уровне сервера баз данных 16.2.1. Режимы аутентификации Аутентификация (проверка подлинности пользователя) — это первый ру- беж, успешное преодоление которого дает право пользователю на соединение с сервером баз данных. MS SQL-Server реализует традиционный способ аутенти- фикации пользователей — путем сравнения введенного пользователем пароля с «правильным» паролем, соответствующим имени учетной записи этого пользо- вателя. При этом поддерживаются два режима аутентификации — «Аутенти- фикация Windows» и «Аутентификация SQL-Server». В процессе установки сервера баз данных по умолчанию назначается пер- вый режим аутентификации, при котором пользователи, успешно прошедшие проверку подлинности при входе в операционную систему, автоматически полу- чают право соединения с сервером. Такое решение позволяет использовать сред- ства безопасности, предоставляемые операционной системой (как правило, более надежные по сравнению с соответствующими средствами, реализуемыми на уровне приложений), и, что также немаловажно, упрощает работу пользователей и снижает риск небезопасного хранения паролей, так как пользователю требует- ся помнить единый пароль доступа к различным приложениям Windows. Второй режим аутентификации (называемый также «смешанным») пред- полагает дополнительную регистрацию пользователей средствами сервера баз данных, выдачу им имен учетных записей и паролей с последующей проверкой подлинности пользователей при их соединении с сервером. Такой режим аутентификации предназначен в основном для клиентских при- ложений, функционирующих на платформах, отличных от Windows. Аутентифика- ция средствами программного приложения считается менее безопасной, однако MS SQL-Server поддерживает шифрование трафика между клиентом и сервером, в том числе с помощью сертификатов, сгенерированных самим сервером. 16.2.2. Учетные записи и разрешения уровня сервера MS SQL-Server использует два типа учетных записей: учетные записи Windows (Windows Domain login и Windows Local login) и учетные записи сер- вера (SQL-Server login), используемые в случае выбора смешанного режима аутентификации. При подключении к серверу от имени учетной записи Windows и при со- здании учетной записи сервера имя и идентификатор учетной записи сохраня- ются в таблице SysLogins базы данных Master (табл. 5.3). Для учетных записей сервера в этой таблице дополнительно сохраняется пароль. Для создания учетной записи сервера можно воспользоваться SQL-ко- мандой CREATE LOGIN, например: CREATE LOGIN NewUser WITH PASSWORD = 'NewP@sssW000rd' Графический интерфейс SQL-Server Management Studio содержит сред- ства создания и удаления учетных записей сервера, а также средства просмотра и редактирования выданных им разрешений, доступные через вкладку «Свой- ства» учетной записи и вкладку «Разрешения» свойств сервера. 23 / 24 214 На рисунках 5.4 и 5.5 приведены примеры соответствующих экранных форм. Рис. 5.4 Средства просмотра свойств учетных записей Рис. 5.5 Средства просмотра и редактирования разрешений 24 / 24 215 На вкладке Logins отображается набор создаваемых автоматически (так называемых встроенных) учетных записей Windows и учетная запись sa (System Administrator) — единственная учетная запись сервера, создаваемая по умолча- нию. Эта учетная запись обладает правами системного администратора сервера, но использовать ее можно только в случае, если выбран режим аутентификации средствами SQL-Server. 16.2.3. Фиксированные роли сервера Для предоставления пользователю фиксированного набора разрешений на выполнение работ по администрированию сервера учетную запись этого поль- зователя следует включить в соответствующую серверную роль. Состав таких ролей, их наименования и связанный с каждой ролью набор административных задач строго фиксированы (табл. 5.2), при этом ни один из администраторов сервера не может ни создавать новые серверные роли, ни удалять существую- щие роли, ни изменять их свойства. Члены любой фиксированной роли сервера могут добавлять в эту роль любую учетную запись. Члены роли sysadmin могут добавлять учетные записи в любую фиксированную роль сервера. Таблица 5.2 Фиксированные роли сервера Имя роли Назначение роли и права членов роли sysadmin Роль для системного администратора сервера баз данных. Полные права на SQL-Server, в том числе и право передачи этих прав другим пользователям serveradmin Роль для оператора, обслуживающего сервер с правами отключения сервера и изменения любых его настроек. Запрещен доступ к данным, отсутствует право изменения разрешений на доступ к объектам dbcreator Члены роли получают право создания баз данных (и автоматически стано- вятся ее владельцами с полными правами в созданной базе данных) securityadmin Роль для администратора безопасности с правами управления «обычными» пользователями: создание учетных записей, изменение паролей, предостав- ление прав доступа к данным. Запрещено любое вмешательство в работу сервера, изменение административных прав и учетных записей администра- торов setupadmin Члены роли получают право подключения внешних (так называемых свя- занных) серверов баз данных processadmin Члены роли получают единственное право: право закрытия пользователь- ских подключений к серверу (например, зависших) diskadmin Члены роли получают право выполнять любые операции с файлами баз дан- ных bulkadmin Роль для сотрудников, которые выполняют специфическую операцию — массовую загрузку данных в таблицы Есть еще однасерверная роль — это роль PUBLIC, членами которой авто- матически становятся все пользователи, подключившиеся к серверу, причем лишить пользователя членства в этой роли нельзя. Роль PUBLIC используется для предоставления разрешений всем пользователям сервера. По умолчанию у этой роли есть только два разрешения: разрешение «CONNECT» на соединение 1 / 24 216 с сервером и разрешение «VIEW ANY DATABASE» на просмотр списка баз дан- ных, управляемых сервером. Роль PUBLIC занимает особое место в составе серверных ролей: – во-первых, отсутствуют средства управления членством учетных запи- сей в этой роли (в этом нет необходимости, так как членами роли автоматиче- ски становятся все учетные записи, получившие доступ к серверу); – во-вторых, эта роль не отображается в списке серверных ролей, возвра- щаемых хранимой процедурой sp_helpsrvrole (табл. 5.2), однако она присут- ствует на вкладке \Безопасность\Роли_сервера обозревателя объектов SQL- Server Management Studio; – в-третьих, роль PUBLIC, строго говоря, не является «фиксированной» — в отличие от других ролей сервера, в окне свойств этой роли можно изменить ее текущие разрешения. Управление фиксированными серверными ролями реализуется соответ- ствующими системными хранимыми процедурами, состав и форматы обраще- ния к которым приведены в таблице 5.3. Таблица 5.3 Средства управления фиксированными серверными ролями Хранимая процедура Входные параметры Результат sp_helpsrvrole - Список серверных ролей sp_helpsrvrolemember ['role'] Список членов роли 'role'. Если входной параметр опущен, процедура возвращает список членов всех серверных ролей sp_addsrvrolemember 'login', 'role' Добавление учетной записи 'login' в роль 'role' sp_dropsrvrolemember Удаление учетной записи 'login' из роли 'role' sp_srvrolepermission ['role'] Список разрешений указанной роли. Если входной параметр опущен, процедура возвращает список раз- решений для всех серверных ролей 16.2.4. Хранение информации об учетных записях Для хранения информации об учетных записях пользователей и их член- стве в фиксированных серверных ролях используется системная таблица SysLogins системной базы данных Master. Каждая строка этой таблицы содер- жит информацию об одной учетной записи (табл. 5.4). Таблица 5.4 Схема системной таблицы SysLogins Имя поля Тип данных Описание sid varbinary(85) Security Identifier — уникальный идентификатор безопас- ности учетной записи createdate datetime Дата добавления учетной записи updatedate datetime Дата обновления учетной записи name sysname Имя учетной записи dbname sysname Имя базы данных по умолчанию для пользователя при установлении соединения 2 / 24 217 Продолжение табл. 5.4 Имя поля Тип данных Описание password nvarchar(128) Хешированное значение пароля (= NULL для учетных за- писей Windows) language sysname Язык по умолчанию для пользователя denylogin int = 1 — учетной записи Windows отказано в доступе к сер- веру hasaccess int = 1 — учетной записи Windows разрешен доступ к серверу isntname int = 1 — для учетных записей Windows; = 0 — для учетных записей SQL-Server isntgroup int =1 — для учетных записей групп Windows isntuser int =1 — для учетных записей пользователей Windows sysadmin int = 1 — если учетная запись является членом одноименной серверной роли securityadmin int serveradmin int setupadmin int processadmin int diskadmin int dbcreator int bulkadmin int 16.3. Управление доступом на уровне базы данных 16.3.1. Объекты доступа: таблицы, представления, команды и схемы Пользователь, прошедший процедуру аутентификации и получивший че- рез свою учетную запись доступ к серверу с соответствующими глобальными разрешениями на выполнение операций с базами данных, должен получить у администратора требуемый ему набор прав доступа к логическим объектам ба- зы данных. Объекты доступа базы данных — это таблицы, представления, храни- мые процедуры и функции, а также SQL-команды, предназначенные для созда- ния логических объектов (CREATE TABLE, CREATE VIEW, CREATE PROCEDURE, CREATE FUNCTION, CREATE RULE, CREATE DEFAULT) и резервных копий (BACKUP DATABASE, BACKUP LOG) базы данных, и схемы, используемые для группировки объектов. Схемы Схема — это именованный объект-контейнер, предназначенный для группировки логических объектов БД с целью упрощения процесса управления правами доступа к ним со стороны пользователей. При создании БД в ней автоматически создаются схемы, владельцами ко- торых являются фиксированные роли и специальные (встроенные) пользовате- ли БД. Этим схемам присваиваются имена их владельцев. Объект БД (таблица или представление) не может одновременно входить в состав нескольких схем, при этом допускается перемещение объектов между схемами одной базы данных (ALTER SCHEMA). 3 / 24 218 Схема может быть удалена (DROP SCHEMA) при условии, что она пуста. Перед удалением схемы все ее объекты должны быть либо удалены, либо пере- мещены в другие схемы базы данных. При создании схемы (CREATE SCHEMA) должен быть задан ее владелец — субъект доступа любого типа, получающий соответствующие права доступа ко всем объектам, включенным в схему. 16.3.2. Субъекты доступа: пользователи и роли базы данных Права на выполнение операций с логическими объектами БД предостав- ляются именованным субъектам доступа — пользователям и ролям базы дан- ных, а также ролям приложений. Пользователи базы данных Основным субъектом доступа на уровне базы данных является пользова- тель, которому могут быть индивидуально разрешены права доступа к объек- там базы данных. При создании пользователя базы данных сервер связывает его с определенной учетной записью (субъектом доступа уровня сервера), и таким образом владелец учетной записи получает соответствующие права доступа к объектам базы данных. При этом учетная запись не может быть связана более чем с одним пользователем одной базы данных. При создании базы данных в ней автоматически создаются два специаль- ных пользователя: dbo и guest. Пользователь dbo (database owner) является владельцем базы данных и имеет в этой базе абсолютные права, в том числе и право наделения других пользователей правами владельца базы данных. С пользователем dbo связана та учетная запись, которой на уровне сервера бы- ло выдано разрешение CREATE DATABASE и владелец которой воспользовался этим разрешением и создал базу данных. Пользователь dbo автоматически ста- новится членом фиксированной роли базы данных db_owner. Если учетной записи явно не предоставлен доступ к базе данных, то она автоматически отображается сервером в пользователя guest, следовательно, права доступа к объектам базы данных, назначенные пользователю guest, авто- матически получают все учетные записи сервера. Для снижения рисков нару- шения безопасности рекомендуется удалять пользователя guest из базы данных. Роли базы данных Для группировки пользователей базы данных используются роли, кото- рые сами являются именованными субъектами доступа, то есть для ролей, как и для пользователей, могут быть определены права доступа к логическим объек- там базы данных. При этом права роли автоматически получают все ее члены. Роль всегда имеет владельца, в качестве которого может выступать пользова- тель или другая роль базы данных, и набор схем, принадлежащих этой роли. Фиксированные роли базы данных В каждой базе данных всегда присутствует предопределенный набор фик- сированных ролей (табл. 5.5), с каждой из которых связано определенное множе- ство глобальных разрешений — прав доступа ко всем объектам базы данных. 4 / 24 219 Таблица 5.5 Фиксированные роли базы данных Роль Права членов роли db_owner Права владельца, выполнение любых действий с базой данных db_securityadmin Управление правами доступа к объектам базы данных других пользо- вателей и членством их в ролях db_accessadmin Управление пользователями базы данных: создание, удаление и изме- нение db_ddladmin Создание, изменение и удаление объектов базы данных db_datawriter Разрешено изменение/просмотр данных любых таблиц или представ- лений базы данных db_datareader db_denydatawriter Запрещено изменение/просмотр данных любых таблиц или представ- лений базы данных независимо от выданных разрешений db_denydatareader db_backupoperator Резервное копирование базы данных public Любой пользователь, созданный в базе данных, автоматически вклю- чается в роль public и не может быть удален из нее. Роль предназна- чена для предоставления прав доступа по умолчанию (default right) всем пользователям базы данных Роли этого типа предназначены в основном для пользователей, выполня- ющих функции администрирования базы данных. Владельцем всех фиксированных ролей базы данных является пользова- тель dbo, а членами фиксированной роли могут быть только пользователи базы данных. Пользовательские роли базы данных В отличие от фиксированных ролей, пользовательские роли формируются администратором и предназначены для группировки пользователей, которым следует назначить одинаковые права доступа к логическим объектам базы дан- ных. Набор объектов, связанных с пользовательской ролью, и права доступа к каждому из них не являются предопределенными и могут быть сформированы индивидуально для каждой такой роли. Другим существенным отличием пользовательских ролей от фиксирован- ных является возможность членства пользовательской роли в другой пользова- тельской роли с соответствующим наследованием дочерними ролями прав до- ступа к объектам, установленным для родительских ролей. Роли приложений Имеется еще одна категория ролей уровня базы данных — это роли при- ложений. Членство пользователей в ролях приложений не предусмотрено — роли этого типа предназначены для предоставления прав доступа клиентским приложениям, через которые пользователи подключаются к базе данных. Отли- чительной особенностью ролей приложений является наличие у каждой из них специального пароля, который должен быть отправлен приложением серверу для получения прав доступа, назначенных соответствующей роли. 5 / 24 220 16.3.3. Хранение информации о субъектах доступа Для хранения информации о пользователях и ролях базы данных всех трех перечисленных выше типов используется системная таблица SysUsers пользовательской базы данных (табл. 5.6). Каждая строка этой таблицы представляет один субъект доступа — поль- зователя, фиксированную или пользовательскую роль базы данных или роль приложения. Таблица 5.6 Схема системной таблицы SysUsers Имя столбца Тип данных Описание uid smallint Идентификатор субъекта доступа (пользователя или ро- ли), уникальный в пределах базы данных. uid = 1 — для пользователя dbo uid = 2 — для пользователя guest 3 ≤ uid < 16384 — для прочих субъектов доступа uid ≥ 16384 — для фиксированных ролей name sysname Имя субъекта доступа sid Varbinary (85) Идентификатор безопасности учетной записи пользовате- ля или владельца роли roles Varbinary (2048) Битовая строка, определяющая членство субъекта досту- па в ролях сервера. Если roles[uid] = 1, то субъект доступа является членом роли, идентификатор которой равен uid (в новых версиях не используется) createdate datetime Дата создания субъекта доступа updatedate datetime Дата последнего изменения субъекта доступа password varbinary (256) Пароль для ролей приложения. = null — для других типов субъектов доступа gid smallint Идентификатор роли (в старых версиях сервера — груп- пы, откуда идет название поля): если gid = uid, то субъект доступа — фиксированная или пользовательская роль базы данных; для других типов субъектов доступа gid = 0 hasdbaccess int Если = 1, то пользователь имеет доступ к базе данных islogin int Если = 1, то субъект доступа соответствует учетной запи- си любого типа isntname int Если = 1, то пользователь является отображением учет- ной записи Windows isntgroup int Если = 1, то пользователь является отображением учет- ной записи группы Windows isntuser int Если = 1, то пользователь является отображением учет- ной записи пользователя Windows issqluser int Если содержит 1, то пользователь является отображением учетной записи пользователя SQL-Server isaliased int Если = 1, то пользователь является псевдонимом другого пользователя issqlrole int Если = 1, то субъект доступа — пользовательская или фиксированная роль базы данных isapprole int Если = 1, то субъект доступа — роль приложения 6 / 24 221 16.3.4. Средства управления пользователями и ролями Команда CREATE USER создает пользователя базы данных, сопоставляя его с учетной записью (сертификатом, ассиметричным ключом) или схемой по умолчанию. CREATE USER user_name [ FOR { LOGIN login_name | CERTIFICATE cert_name | ASYMMETRIC KEY asym_key_name } | WITHOUT LOGIN ] [ WITH DEFAULT_SCHEMA = schema_name ] Листинг 5.1 Формат SQL-команды CREATE USER Параметр WITHOUT LOGIN создает пользователя, который не сопоставля- ется с учетной записью, такой пользователь может подключиться к базе данных как guest. Если параметр DEFAULT_SCHEMA не задан, пользователю в качестве схемы по умолчанию будет назначена схема dbo. Команда ALTER USER позволяет переименовать пользователя базы данных, сопоставить его с новой учетной записью или определить для него новую схему по умолчанию. ALTER USER userName WITH { NAME = newUserName | DEFAULT_SCHEMA = schemaName | LOGIN = loginName } [ ,...n ] Листинг 5.2 Формат SQL-команды ALTER USER Команда DROP USER userName удаляет пользователя базы данных. Команда CREATE ROLE role_name [AUTHORIZATION owner_name] создает роль базы данных role_name, владельцем которой назначается owner_name. Если параметр AUTHORIZATION не задан, владельцем созданной роли назнача- ется субъект, выполнивший команду CREATE ROLE. Команда ALTER ROLE позволяет переименовать роль, включить в нее но- вых членов или удалить членов из роли. 7 / 24 222 ALTER ROLE role_name { [ADD MEMBER database_principal] | [DROP MEMBER database_principal] | WITH NAME = new_role_name } Листинг 5.3 Формат SQL-команды ALTER ROLE 16.3.5. Средства управления правами доступа Перечень типов прав доступа к объектам базы данных приведен в разде- ле 15.3 учебника. Каждый из этих типов может быть отнесен к одной из следу- ющих категорий: – права доступа к данным таблиц и представлений базы данных; – права на выполнение хранимых процедур и функций; – права на выполнение команд Transact-SQL. При создании нового пользователя базы данных он автоматически стано- вится членом роли PUBLIC и наделяется правами доступа, установленными для этой роли. Субъекту доступа (пользователю или пользовательской роли базы дан- ных) можно предоставить (или отнять) права неявно — через членство в фикси- рованных или пользовательских ролях базы данных, или явно, например SQL-операторами Grant, Deny или Revoke. Grant — предоставление доступа Для предоставления субъектам прав доступа к таблицам базы данных, а также к представлениям, процедурам и функциям используется SQL-оператор GRANT, имеющий синтаксис, представленный в листинге 5.4а. GRANT { ALL | permission [,...n] } ON table | view [( column [,...n] )] | ON procedure | ON function TO security_account [,...n] [WITH GRANT OPTION] [AS (role)] а GRANT {ALL | statement[,...n]} TO security_account [, ... .n] б Листинг 5.4 Формат SQL-команды GRANT: а — предоставление прав доступа к объектам; б — предоставление прав выполнения SQL-команд. 8 / 24 223 Параметры команды GRANT: – ALL — позволяет предоставить все права доступа к объекту (актуальные для типа объекта, указанного в разделе ON); – permission [,...n] — вид предоставляемого права доступа (SELECT, INSERT, DELETE, UPDATE, REFERENCES или EXECUTE), при этом одной командой может быть предоставлено несколько видов прав; – ON table | view — имя объекта доступа (таблицы или представления); – [( column [,...n] )] — имена столбцов таблицы или представления, если задан этот необязательный параметр, то права (в этом случае только SELECT или UPDATE) будут предоставлены только указанным столбцам; предоставление прав на уровне таблицы или представления отменяет все права, ранее предо- ставленные на уровне столбцов; – ON procedure — имя стандартной или расширенной хранимой процеду- ры (разрешается выдавать только право EXECUTE); – ON function — имя пользовательской функции (для скалярных функций разрешается выдавать права EXECUTE или REFERENCES, для TVF-функций, воз- вращающих табличные значения, дополнительно разрешается выдавать права SELECT, INSERT и DELETE); – TO security_account [,...n] — список субъектов доступа (пользователей и/или ролей базы данных), которым предоставляются права; – [WITH GRANT OPTION] — при наличии этого параметра субъекты досту- па, получившие указанные в операторе права, получают право предоставления этих прав другим субъектам доступа (за исключением прав доступа к отдель- ным столбцам таблиц и представлений); – [AS (role)] — использование этого необязательного параметра дает воз- можность пользователю, не имеющему явно выданных ему прав на предостав- ление прав другим субъектам доступа, выдавать права доступа от имени своей «родительской» роли, имеющей такие права. Право выполнения SQL-операторов CREATE TABLE, CREATE VIEW, CREATE PROCEDURE, CREATE FUNCTION, CREATE RULE, CREATE DEFAULT, BACKUP DATABASE, BACKUP LOG также предоставляется командой GRANT (ли- стинг 5.4б), в которой параметр statement [,...n] задает список SQL-операторов из приведенного выше перечня. Deny — отклонение (запрет) доступа Получив от администратора набор прав доступа, пользователь сможет выполнять разрешенные ему действия. Но в некоторых случаях бывает необхо- димо наложить запрет на выполнение им определенных операций с определен- ными объектами базы данных. Глобальный запрет доступа субъекта ко всем объектам базы данных мо- жет быть реализован путем включения этого субъекта в фиксированные роли базы данных db_denydatareader (глобальный запрет чтения данных) или db_denydatawriter (глобальный запрет модификации данных). 9 / 24 224 Если же требуется запретить субъекту доступ к отдельным объектам базы данных, сохранив при этом предоставленные ему ранее права доступа к другим объектам, администратор может воспользоваться SQL-оператором DENY, син- таксис которого приведен в листинге 5.5а. DENY { ALL | permission [,…n] } ON table | view [( column [,…n])] | ON procedure | ON function TO security_account [,…n] [CASCADE] DENY {ALL | statement[,...n]} TO security_account [,... .n] а б Листинг 5.5 Формат SQL-команды DENY: а — запрет доступа к объектам базы данных; б — запрет выполнения SQL-команд. Эта же команда позволяет запретить субъекту право выполнения отдельных SQL-операторов, сохранив предоставленные ему ранее права (листинг 5.5б). Параметры команды DENY аналогичны соответствующим параметрам ко- манды GRANT. Необязательный параметр [CASCADE] предписывает каскадиро- вание запрета доступа, указанного в команде DENY:если пользователь, которо- му эта команда запрещает доступ к объекту, ранее предоставлял к нему доступ другим пользователям, то команда запретит доступ к этому объекту и этим пользователям, а также всем их «потомкам» всех уровней. Если запрет доступа требуется распространить на группу из нескольких пользователей, будет целесообразно создать специальную пользовательскую роль, SQL-оператором DENY запретить ей доступ к соответствующим объектам и затем включить в эту роль всю группу пользователей. Согласно базовому правилу функционирования системы ограничения до- ступа, запрет доступа (Deny) имеет более высокий приоритет, чем его предо- ставление (Grant). Если администратор запрещает пользователю (или пользовательской ро- ли) доступ к объекту (явно или через членство в соответствующей роли), а ра- нее такой доступ был ему предоставлен, то система безопасности гарантирует отсутствие прав доступа до момента отмены (Revoke) этого запрета или исклю- чения пользователя из числа членов «запрещающей» роли. REVOKE — отмена явно предоставленных прав и запретов доступа. Если пользователю был предоставлен доступ к объекту через членство в роли базы данных, но при этом ему был явно запрещен (DENY) доступ к этому же объекту, то запрет как более приоритетный по сравнению с разрешением будет действовать и пользователь будет лишен соответствующего доступа. В такой ситуации явный запрет может быть снят оператором REVOKE, после че- го пользователь вновь получит доступ к объекту как член роли. 10 / 24 225 Оператор REVOKE может также отменить явно выданное субъекту право (GRANT) доступа к объекту (листинг 5.6а) или отменить явное предоставление или запрет права выполнения SQL-операторов (листинг 5.6б). REVOKE [GRANT OPTION FOR] { ALL | permission [,...n] } ON table | view [( column [,...n])] | ON procedure | ON function TO security_account [,...n] [CASCADE] [AS (role)] REVOKE {ALL | statement[,...n]} TO security_account [,... .n] а) б) Листинг 5.6 Формат SQL-команды REVOKE: а — отмена явно выданных разрешений доступа; б — отмена разрешений на выполнение SQL-команд. Параметры оператора REVOKE аналогичны соответствующим параметрам команд GRANT и DENY, за исключением необязательного параметра [GRANT OPTION FOR]: если в операторе REVOKE этот параметр присутствует и при этом отменяемое право доступа было предоставлено субъекту оператором GRANT без использования параметра [WITH GRANT OPTION], то само разрешение доступа субъекта отменено не будет, а будет отменено только его право на предостав- ление указанного разрешения другим субъектам; в противном случае будет от- менено само разрешение доступа. Если в операторе REVOKE присутствует параметр [CASCADE], то каскадная отмена разрешений доступа, предоставленных субъекту с помощью параметра [WITH GRANT OPTION], приведет к отмене этих прав, независимо от наличия па- раметра [GRANT OPTION FOR] в операторе REVOKE. Просмотр прав доступа Среда SQL Management Studio содержит средства просмотра прав доступа через вкладку «Свойства» соответствующего объекта, пользователя или роли базы данных. Эту же информацию можно получить средствами Transact-SQL, используя системную хранимую процедуру sp_helprotect. sp_helprotect ['object' | 'statement'] [, 'security_account'] [, 'grantor'][, 'type'] Листинг 5.7 Формат вызова системной процедуры sp_helprotect Параметры процедуры sp_helprotect: – ['object' | 'statement'] — имя объекта, категории объектов базы данных или команды Transact-SQL, о правах доступа к которым предполагается полу- чить информацию, например 'sysusers', 'tables', 'views', 'procedures', 'Create Table', 'Backup Database'; 11 / 24 226 – [ 'security_account' ] — имя субъекта доступа; – ['grantor'] — имя субъекта, который предоставил право; – [ 'type'] — тип прав доступа: • 'o' — только права доступа к объектам; • 's' — только права выполнения команд; • 'os' — оба типа прав (значение по умолчанию). Ни один из параметров не является обязательным: при выполнении про- цедуры без параметров она возвратит список всех прав, выданных всем субъек- там на все объекты базы данных. Указание (позиционно!) любого из парамет- ров накладывает соответствующий фильтр на результирующий список прав до- ступа, например sp_helprotect 'Create Role', sp_helprotect Null,'User1' или sp_helprotect Null, Null, 'User2'. Правом вызова хранимой процедуры sp_helprotect по умолчанию владе- ет фиксированная роль базы данных Public, следовательно, каждый пользова- тель базы данных может получить информацию о правах доступа любого из ее пользователей к любому ее объекту. Системное представление sys.database_permissions и TVF-функция fn_builtin_permissions() позволяют получить более детальную информацию о правах доступа. 12 / 24 |