Опубликован: 29.07.2008 | Доступ: свободный | Студентов: 1625 / 359 | Оценка: 4.31 / 4.13 | Длительность: 09:00:00
Лекция 3:

Управление доступом к базам данных SQL Server

< Лекция 2 || Лекция 3: 1234 || Лекция 4 >

Управление безопасностью для сборок

SQL Server 2005 предоставляет возможность включать сборки .NET (объекты, которые ссылаются на файлы .dll ) в механизм базы данных и вызывать эти сборки в хранимых процедурах и функциях. Для сборок можно задать те же разрешения, что и для хранимых процедур. Смотрите список разрешений в табл. 3.4.

Определяем набор разрешений

Для создания сборки вам необходимо определить набор разрешений. Этот набор разрешений определяет набор разрешений на доступ к коду, который предоставляется сборке в SQL Server. Существует три различных набора разрешений:

  • SAFE. Код, выполняемый сборкой, не может обращаться к внешним системным ресурсам. SAFE - это самый ограничительный набор разрешений, который установлен по умолчанию..
  • EXTERNAL_ACCESS. Сборка может обращаться к внешним системным ресурсам.
  • UNSAFE. Сборка может выполнять неуправляемый код.

SAFE является рекомендуемым набором разрешений для сборок, которые не нуждаются в доступе к внешним ресурсам.

Дополнительная информация.Дополнительную информацию о безопасности доступа кода можно получить по следующей ссылке: http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/secmod/html/ secmod116.asp.
Выполняем сборку

Когда приложение пытается обратиться к объекту внутри сборки, механизм базы данных проверяет, имеет ли текущий пользователь разрешение EXECUTE. Следующий код используется для предоставления разрешения EXECUTE для сборки пользователю Sara.

  • Изменяем контекст соединения на базу данных AdventureWorks.
    USE AdventureWorks;
    GO
  • Предоставляем пользователю Sara разрешение на выполнение сборки.
    GRANT EXECUTE ON <AssemblyName>
    TO Sara;

    Предоставляя разрешение EXECUTE для сборки, вы предоставляете пользователю разрешение EXECUTE для всех объектов сборки.

Управление цепочками владения

Цепочка владения - это последовательность объектов базы данных, которые обращаются друг к другу. Например, когда вы добавляете в таблицу строку из хранимой процедуры, то хранимая процедура является вызывающим объектом, а таблица - вызываемым объектом. Когда SQL Server обходит цепочку, механизм базы данных оценивает разрешения по-другому, не так, как если бы вы обращались к объектам по отдельности.

При обращении к объекту в цепочке, SQL Server сначала сравнивает владельца вызываемого объекта и владельца вызывающего объекта. Если у объектов один владелец, то разрешения вызываемого объекта не оцениваются. Эта функция очень полезна для управления разрешениями объектов. Предположим, например, что Sara создает таблицу с именем Person.SupplierContacts и хранимую процедуру Person.InsertSupplierContacts, c помощью которой Sara добавляет строки в таблицу PersonSupplierContacts. Поскольку у этих объектов один владелец, Sara, то для того, чтобы предоставить другим пользователям разрешение EXECUTE для таблицы PersonSupplierContacts, достаточно предоставить разрешение EXECUTE на хранимую процедуру Person.InsertSupplierContacts. Нет необходимости предоставлять другим пользователям разрешения для таблицы.

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

Управление контекстом выполнения

Имя входа и пользователь, подключившиеся на время сеанса или выполняющие процедуру, определяют контекст выполнения. Маркеры имени входа и пользователя предоставляют SQL Server информацию, необходимую для оценки разрешений объектов. SQL Server 2005 предоставляет возможность изменить контекст выполнения при помощи инструкции EXECUTE AS. Эта операция называется переключением контекста.

Выполняем инструкцию EXECUTE AS

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

  • Изменяем контекст соединения на базу данных AdventureWorks.
    USE AdventureWorks;
    GO
  • Изменяем контекст выполнения на пользователя Sara.
    EXECUTE AS USER='Sara';
  • Следующая инструкция будет выполнена с учетными данными пользователя Sara.
    TRUNCATE TABLE dbo.ErrorLog;

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

  • Снова изменяем контекст выполнения, возвращая его к исходному состоянию REVERT ;
  • Теперь следующая инструкция будет выполнена в исходном контексте выполнения.
    TRUNCATE TABLE dbo.ErrorLog;
Управляем переключением контекста

Кроме управления контекстом выполнения для пакетов (групп инструкций T-SQL, отправленных серверу на выполнение, как в примере TRUNCATE TABLE, рассмотренном выше), можно управлять контекстом выполнения для хранимых процедур и пользовательских функций. Переключая контекст в этих модулях, вы можете управлять тем, какая учетная запись пользователя будет использоваться для доступа к объекту, на который ссылается хранимая процедура или функция. Для выполнения этой задачи можно использовать инструкцию EXECUTE AS со следующими изменениями:

  • CALLER. Инструкции внутри хранимой процедуры или функции, определяемой пользователем, выполняются в контексте вызывающей программы модуля.
  • SELF. Инструкции выполняются в контексте пользователя, создавшего или изменившего хранимую процедуру или функцию.
  • OWNER. Инструкции выполняются в контексте текущего владельца хранимой процедуры или функции..
  • <User>or< Login >. Инструкции выполняются в контексте определенного пользователя или имени входа.

В следующем примере создается хранимая процедура, которая переключает контекст на пользователя dbo. Затем она предоставляет разрешение EXECUTE для хранимой процедуры и изменение контекста выполнения хранимой процедуры пользователю Sara.

  • Создаем хранимую процедуру для выполнения инструкций -' в контексте dbo.
    CREATE PROCEDURE dbo.usp TruncateErrorLog
    WITH EXECUTE AS "dbo"
    AS
    TRUNCATE TABLE dbo.ErrorLog;
    GO
  • Предоставляем разрешения на выполнение процедуры пользователю Sara.
    GRANT EXECUTE ON dbo.usp_TruncateErrorLog TO Sara
  • Изменяем контекст выполнения этого пакета на пользователя Sara.
    EXECUTE AS [USER=]'Sara'
  • Выполняем хранимую процедуру.
    EXECUTE dbo.usp_TruncateErrorLog

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

Заключение

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

После того, как физический доступ настроен, следует разрешить пользователям устанавливать соединение с экземпляром SQL Server. Эту задачу можно выполнить, создав имена входа для пользователей и групп Windows и имена входа SQL Server. Прежде чем сделать это, выберите метод проверки подлинности, который будет использоваться системой.

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

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

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

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

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

Краткий справочник по 2-3 лекции

Чтобы Выполните следующие действия
Включить удаленные соединения В окне SQL Server Surface Area Connection (Настройка контактной зоны SQL Server) щелкните ссылку Surface Area Configuration For Services And Connection (Настройка контактной зоны для служб и соединений), разверните элемент Database Engine, щелкните элемент Remote Connection (Удаленные соединения), выберите вариант Local And Remote Connection (Локальные и удаленные соединения), а затем выберите протокол.
Настройка режима проверки подлинности В окне SQL Server Management Studio щелкните правой кнопкой на экземпляре SQL Server и выберите команду Properties (Свойства). В панели Select A Page (Выбор страницы) выделите значок Security (Безопасность). В секции Server Authentication (Проверка подлинности сервера) выберите режим проверки подлинности.
Предоставить доступ SQL Server пользователям домена Windows Выполните инструкцию SQL
CREATE LOGIN [<domain>\<user>] FROM WINDOWS;
Создать имя входа SQL Server для определенной базы данных Выполните инструкцию SQL
CREATE LOGIN <user> 
  WITH PASSWORD = "<password>", 
       DEFAULT_DATABASE =<database>;
Получить список имен SQL Server Выполните инструкцию SQL входа SELECT * FROM sys.sql_logins;
Включить строгую политику паролей Выполните инструкцию SQL
CREATE LOGIN <user> 
  WITH PASSWORD = "<password>" MUST_CHANGE, 
  CHECK_EXPIRATION = ON, 
  CHECK_POLICY          = ON;
Предоставить индивидуальные разрешения пользователю Выполните инструкцию SQL
GRANT ALTER <permission> TO <user>;
Удалить пользователя SQL Server Выполните инструкцию SQL
DROP LOGIN <user>;
Вывести отчет обо всех пользователях базы данных, утративших связь с именем входа Выполните инструкцию SQL
EXECUTE sp_change_users_login @Action='Report';
Включить пользователя guest Выполните инструкцию SQL
GRANT CONNECT TO Guest;
< Лекция 2 || Лекция 3: 1234 || Лекция 4 >
Марат Уздемиров
Марат Уздемиров
Ярослав Малащенко
Ярослав Малащенко
Гаральд Егоркин
Гаральд Егоркин
Россия
Иван Суслов
Иван Суслов
Россия, Москва