Проектирование механизма сетевой безопасности для обеспечения безопасности системы базы данных

Проектирование механизма сетевой безопасности для обеспечения безопасности системы базы данных

SQL Server 2005 – первая версия SQL Server, которая была разработана в рамках инициативы Microsoft Trustworthy Computing (Защищенные информационные системы). Один из принципов этой инициативы – Security by Default (Безопасность по умолчанию). Реализуя этот принцип, SQL Server 2005 по умолчанию отключает некоторые сетевые настройки, чтобы сохранить максимально возможный уровень безопасности среды SQL Server.

Разрешение удаленного доступа

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

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

При установке SQL Server с параметрами по умолчанию многие функции отключены, чтобы уменьшить уязвимость системы базы данных против атак. Например, в SQL Server 2005 по умолчанию не разрешаются удаленные подключения (за исключением версии Enterprise), поэтому для того, чтобы задействовать удаленные подключения, мы воспользуемся инструментом SQL Server Surface Area Configuration (Настройка контактной зоны SQL Server), как показано на рис. 2.1.

Для этого выполните перечисленные ниже действия:

Разрешаем удаленные соединения

1. В меню Start (Пуск) выберите All Programs,. Microsoft SQL Server 2005, Configuration Tools, SQL Server Surface Area Configuration. (Все программы, Microsoft SQL Server 2005, Средства настройки, Настройка контактной зоны SQL Server).

увеличить изображение
Рис. 2.1. Инструмент Настройка контактной зоны SQL Server для служб и подключений

2. Под заголовком Configure Surface Area For Localhost (Настроить контактную зону для localhost) в нижней части окна щелкните ссылку Surface Area Configuration For Services And Connections (Настройка контактной зоны для служб и соединений).

3. С левой стороны открывшегося окна отображается список компонентов, которые можно настроить. В этом списке разверните дерево элемента Database Engine и щелкните мышью элемент Remote Connections (Удаленные соединения).

4. Выберите вариант Local And Remote Connections (Локальные и удаленные соединения), а затем выберите нужные протоколы.

Допускается использование удаленных соединений с использованием сетевых протоколов TCP/IP или Named Pipes (именованные каналы). В интересах безопасности и производительности рекомендуется использовать протокол TCP/IP.

Обеспечение безопасности внешнего доступа

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

Дополнительная информация. SQL Server допускает использование соединений с различными типами конечных точек. О конечных точках рассказывается в лекции 5 курса " Оптимизация работы серверов баз данных Microsoft SQL Server 2005".

Управление доступом к экземплярам SQL Server

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

В SQL Server 2005 участники – это лица, группы или процессы, которые запрашивают доступ к ресурсам базы данных. Участники иерархически упорядочены по уровням операционной системы, сервера и базы данных и могут быть индивидуальными (неделимыми) или коллективными.

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

Выбор режима проверки подлинности

SQL Server 2005 для предоставления доступа поддерживает два режима аутентификации: режим проверки подлинности Windows и комбинированный режим проверки подлинности. Режим проверки подлинности можно настроить через SQL Server Management Studio, выполнив следующие действия:

Включаем пользователя guest

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

· Изменяем контекст соединения на базу данных AdventureWorks.

· USE AdventureWorks;

· Предоставляем пользователю Guest доступ к базе данных AdventureWorks.

GRANT CONNECT TO Guest;

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

Создаем роли базы данных

Роли базы данных - это участники уровня базы данных. Роли базы данных можно использовать для назначения разрешений базы данных группе пользователей. В SQL Server 2005 по умолчанию создается набор ролей базы данных. Эти роли по умолчанию перечислены в табл. 3.1.

Таблица 3.1. Роли базы данных по умолчанию
Роль базы данных	" Описание
db_accessadmin	Может управлять доступом к базе данных
db_backupoperator	Может выполнять резервное копирование базы данных
db_datareader	Может читать данные из таблиц всех пользователей
db_datawriter	Может добавлять, удалять и обновлять данные в таблицах всех пользователей
db_ddladmin	Может выполнять любые команды DDL в базе данных
db_denydatareader	Не может читать какие-либо данные в таблицах пользователей
db_denydatawriter	Не может добавлять, удалять и обновлять какие-либо данные в таблицах пользователей
db_owner	Может выполнять все действия по настройке конфигурации и обслуживанию
db_securityadmin	Может изменять членство в ролях базы данных и управлять разрешениями
public	Особая роль базы данных. Все пользователи принадлежат к роли public. Пользователей из группы public нельзя удалить.

Можно добавлять роли базы данных, если нужно сгруппировать пользователей в соответствии с требованиями определенных разрешений. Следующий пример кода создает роль базы данных с именем Auditors и добавляет пользователя Peter в эту новую роль.

· Изменяем контекст соединения на базу данных AdventureWorks.

· USE AdventureWorks;

· Создаем роль Auditors в базе данных AdventureWorks.

· CREATE ROLE Auditors;

· Добавляем пользователя Peter к роли Auditors

EXECUTE sp_addrolemember " Auditors", " Peter";

Создаем роли приложения

Роль приложения можно создать при помощи инструкции CREATE APPLICATION ROLE. Этот код имеется в файле примеров ApplicationRoles.sql.

· Изменяем контекст соединения на базу данных AdventureWorks.

· USE AdventureWorks; GO

· Создаем роль приложения FinancialRole в текущей базе данных

CREATE APPLICATION ROLE FinancialRole WITH PASSWORD = " Pt86Yu$$R3";

Используем роли приложения

Роли приложений перед использованием необходимо активизировать. Это можно сделать, выполнив системную хранимую процедуру sp_setapprole. После того, как роль приложения активизирована в текущем соединении, она остается активной до тех пор, пока не будет закрыто соединение или выполнена системная хранимая процедура sp_unsetapprole. Хотя роли приложения предназначены для использования из клиентских приложений, их можно также использовать из особых пакетов T-SQL. Следующая процедура (ее можно найти в файлах примеров под именем ApplicationRolesUse.sql ) описывает, как активизировать роль Financial Role и отменить эту активизацию.

· Изменяем контекст соединения на базу данных AdventureWorks.

· USE AdventureWorks; GO

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

DECLARE @context varbinary (8000);

· Активируем роль приложения и сохраняем текущий контекст соединения

· EXECUTE sp_setapprole " FinancialRole", " Pt86Yu$$R3", @fCreateCookie = true, @cookie = @context OUTPUT;

· Проверяем, был ли пользовательский контекст заменен контекстом роли приложения.

SELECT CURRENT_USER;

· Деактивируем роль приложения, и восстанавливаем предыдущий контекст соединения.

· EXECUTE sp_unsetapprole @context; GO

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

· SELECT CURRENT_USER; GO

Удаляем роли приложения

Если нужно удалить роль приложения, используйте инструкцию DROP APPLICATION ROLE, как показано в следующем примере (этот код имеется в файле примеров ApplicationRoles.sql ):

· Изменяем контекст соединения на базу данных AdventureWorks.

· USE AdventureWorks; GO

· удаляем роль приложения FinancialRole из текущей базы данных

DROP APPLICATION ROLE FinancialRole;

Введение в схемы

Схемы базы данных можно создавать при помощи инструкции CREATE SCHEMA. Создавая схему, можно создать объекты базы данных и назначить разрешения в пределах одной транзакции, которая вызывается инструкцией CREATE SCHEMA. Следующий пример (он есть в файлах примеров под именем ManagingAccessToSchemas01.sql ) создает схему с именем Accounting, назначает пользователя Peterвладельцем схемы и создает таблицу с именем Invoices. В этом примере также предоставляется разрешение select роли базы данных public.

· Изменяем контекст соединения на базу данных AdventureWorks.

· USE AdventureWorks; GO

· Создаем схему Accounting с владельцем Peter.

· CREATE SCHEMA Accounting· AUTHORIZATION Peter; GO

· Создаем таблицу Invoices в схеме Accounting.

· CREATE TABLE Accounting.Invoices (· InvoiceID int, · InvoiceDate smalldatetime, · ClientID int); GO

· Предоставляем разрешение SELECT на новую таблицу роли public.

· GRANT SELECT ON Accounting.InvoicesTO public; GO

· Добавляем строку данных в новую таблицу.

· Обратите внимание на двухкомпонентное имя, которое мы используем для обращения к таблице в текущей базе данных.

· INSERT INTO Accounting.InvoicesVALUES (101, getdate(), 102);

Удалить схему можно при помощи инструкции DROP SCHEMA. В SQL Server 2005 не допускается удаление схемы, если в схеме есть объекты. Информацию о схемах можно получить, выполнив запрос к представлению каталога sys.schemas. Следующий пример выполняет запрос к представлению каталога sys.schemas, чтобы получить информацию о схеме:

SELECT *FROM sys.schemas;

Следующий код (который можно найти в файлах примеров под именем ManagingAccessToSchemas02.sql ) показывает, как удалить существующую схему, выполнив запрос к объектам, которые содержатся в этой схеме, и удалить сначала эти объекты.

· Изменяем контекст соединения на базу данных AdventureWorks.

· USE AdventureWorks; GO

· Извлекаем информацию о схеме Accounting.

· SELECT s.name AS " Schema", o.name AS " Object" FROM sys.schemas s INNER JOIN sys.objects o ON s.schema_id=o.schema_id WHERE s.name='Accounting'; GO

· Удаляем таблицу Invoices из схемы Accounting.

· DROP TABLE Accounting.Invoices; GO

· Удаляем схему Accounting.

DROP SCHEMA Accounting;

Отзываем доступ к столбцам

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

· Изменяем контекст соединения на базу данных AdventureWorks.

· USE AdventureWorks; GO

· Отзываем ранее предоставленные или запрещенные разрешения на столбец Demographics для пользователя Sara.

· REVOKE UPDATE (Demographics)ON Sales.Individual TO Sara;

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

Для создания сборки вам необходимо определить набор разрешений. Этот набор разрешений определяет набор разрешений на доступ к коду, который предоставляется сборке в 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. Первым шагом будет разрешение SQL Server принимать сетевые соединения, без чего невозможен доступ к системе.

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

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

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

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

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

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

Проектирование механизма сетевой безопасности для обеспечения безопасности системы базы данных

12 3 Следующая ⇒