SQL Server 2005
Вопросы обеспечения безопасности
Выбор стратегии безопасности для компонентов SQL Server 2005
Использование Code Access Security
Безопасность в сервисах отчетов
Безопасность в нотификационных сервисах
Безопасность в интеграционных сервисах
Безопасность в сервисах репликации
Безопасность для SQL Server Agent и Database Mail
В предыдущих номерах мы рассмотрели различные сценарии использования SQL Server 2005. Мы рассказали о возможных вариантах применения разных сервисов, входящих в состав SQL Server 2005, — нотификационных сервисов, SQL Server Service Broker и Web-сервисов, а кроме того, о некоторых сценариях использования других компонентов SQL Server 2005 — средств создания отчетов, интеграционных сервисов, SQLXML, средств репликации, а также SQL Server Agent и Database Mail. Мы разобрали практические примеры выбора компонентов SQL Server 2005 для решения задач, связанных с переносом приложений на новую версию системы управления базами данных.
родолжая рассмотрение вопросов, связанных с переходом на Microsoft SQL Server 2005, в этом номере мы обратимся к одной из самых важных тем — к обеспечению безопасности систем, использующих SQL Server 2005 в качестве базы данных, а также расскажем о различных механизмах безопасности, применимые к сервисам, входящим в состав SQL Server 2005.
Выбор стратегии безопасности для компонентов SQL Server 2005
Начнем тему обеспечения безопасности с выбора соответствующей стратегии для различных компонентов SQL Server — управляющего кода; Web-сервисов, реализуемых средствами SQL Server 2005 (HTTP Endpoints); сервисов отчетов; нотификационных сервисов; интеграционных сервисов; сервисов репликации, а также SQL Server Agent и Database Mail. Для каждого компонента мы приведем краткое описание изменений, произошедших в модели безопасности, а также дадим рекомендации по обеспечению безопасности при применении компонента в составе решения, использующего SQL Server в качестве реляционного хранилища данных.
Использование Code Access Security
Основное правило обеспечения безопасности при применении управляемого кода — использование принципов Code Access Security (CAS) для кода, интегрированного в базу данных. Для конфигурации CAS необходимо в меню Start выбрать Administrative Tools (Settings => Control Panel), затем — Microsoft .NET Framework 2.0 Configuration. В консольном приложении .NET Framework 2.0 Configuration нужно выбрать ветвь .NET Framework 2.0 Configuration, а в ней — Runtime Security Policy.
Конфигурация CAS
По умолчанию интеграция с CLR в SQL Server 2005 отключена. Прежде чем включить поддержку CLR, необходимо выработать подходы к обеспечению безопасности работы
управляемого кода, выполняемого внутри базы данных.
Для использования управляемого кода приемлемы следующие способы обеспечения безопасности:
- включение поддержки CLR только при необходимости — для включения и отключения поддержки CLR в SQL Server применяется утилита Surface Area Configuration. Интеграция с CLR должна быть включена только в тех случаях, когда реально планируется использование управляемого кода для создания различных объектов баз данных: хранимых процедур, функций, триггеров и т.п.;
- применение соответствующих настроек CLR:
- пользовательский код не должен нарушать целостности и стабильности работы SQL Server. Присваивайте только тот уровень привилегий, который реально необходим для выполнения той или иной сборки,
- пользовательский код должен выполняться в контексте пользовательской сессии, которая его вызвала, и с привилегиями, необходимыми для данного контекста. Это позволит избежать неавторизованного доступа к базе данных,
- пользовательский код не должен обращаться к ресурсам за пределами сервера — по возможности сделайте так, чтобы код обращался только к данным в локальных базах данных (набор разрешений SAFE — см. далее);
- корректная настройка наборов разрешений SQL Server Host Policy — в SQL Server поддерживаются следующие наборы разрешений:
- SAFE — наименее привилегированный режим. С набором разрешений SAFE вы даете коду право обращаться только к локальным данным и выполнять только внутренние вычисления. Этот набор разрешений рекомендуется использовать в большинстве случаев,
- EXTERNAL-ACCESS — разрешает доступ к внешним ресурсам, например к файлам и сетям,
- UNSAFE — самый привилегированный режим, обеспечивающий неограниченный доступ к ресурсам.
Защита HTTP Endpoints
Основные принципы безопасности, применяемые при создании Web-приложений и Web-сервисов, в полной мере подходят и для реализации Web-сервисов средствами SQL Server 2005 (HTTP Endpoints).
Возможность предоставления HTTP-доступа к ядру базы данных является одним из наиболее интересных нововведений в SQL Server 2005 — с помощью этой технологии сервер становится доступным для большого числа пользователей. Однако это палка о двух концах: у незначительной части пользователей может появится желание атаковать сервер для извлечения хранимых в нем данных. Поэтому доступ к HTTP Endpoints должен быть надежно защищен.
Для защиты HTTP Endpoints применимы следующие способы обеспечения безопасности:
- использование аутентификации Kerberos — в SQL Server 2005 существует возможность задания точки доступа с одним из следующих аутентификационных механизмов: Basic, Digest, NTLM, Kerberos или Integrated (NTLM и Kerberos). Механизм аутентификации Kerberos является наиболее защищенным, так как в нем используются более мощные, по сравнению в другими механизмами, алгоритмы шифрования, и позволяет аутентифицировать и сервер, и клиента. Фактически, для того чтобы использовать механизм аутентификации Kerberos, вы должны ассоциировать имя Server Principal (SPN) с учетной записью, под которой запущен SQL Server;
- ограничение доступа к точкам через Connect Permission — необходимо разрешить доступ к точкам только тем пользователям или группам, которым он реально необходим. Это можно сделать, используя SQL Server 2005 Connect Permission;
- применение Secure Socket Layer (SSL) для шифрования данных при обмене — если планируется использовать точки доступа для обмена конфиденциальной информацией, применяйте SSL, чтобы обеспечить необходимый уровень защиты данных;
- расположение SQL Server за брандмауэром — если необходимо организовать доступ к SQL Server по HTTP через Интернет, то такой доступ должен быть реализован только через брандмауэр — это позволит обеспечить необходимый уровень защиты коммуникаций и самого SQL Server;
- отключение на сервере учетной записи Windows Guest — включенная учетная запись Windows Guest позволяет пользователям подключаться к локальному компьютеру без ввода пароля;
- включение поддержки HTTP Endpoints только при необходимости — поддержка HTTP Endpoints должна быть включена только в тех случаях, когда она реально требуется и используется.
Безопасность в сервисах отчетов
Подготовка к выбору модели безопасности для сервисов отчетов (Reporting Services) должна включать рассмотрение ASP .NET и нестандартной аутентификации (Custom Authentication). Создание безопасного распределенного корпоративного решения на базе сервисов отчетов требует выдачи пользователям разрешений на доступ к самим отчетам, к источникам данных, которые поставляют данные для генерации отчетов, а также решения вопросов, связанных с выбором правильной модели аутентификации и авторизации.
Для защиты сервисов отчетов приемлемы следующие способы обеспечения безопасности:
- применение аутентификации Windows — в состав SQL Server 2005 не входят компоненты аутентификации для сервисов отчетов. По умолчанию сервисы отчетов используют службы Internet Information Services (IIS) и средства безопасности Windows для аутентификации пользователей на сервере отчетов. Из всех доступных в данном случае опций аутентификация Windows является наиболее безопасной; конфигурация IIS для обеспечения анонимного доступа не требуется;
- использование ролевой модели безопасности сервисов отчетов — для эффективного управления безопасностью применяйте конфигурацию безопасности по умолчанию. Задайте минимальный набор ролей для пользователей, а затем следуйте принципу наделения дополнительными правами в виде исключения — изменение или расширение прав должно производиться только в случае реальной необходимости;
- задействование SSL из защиты данных — по мере генерации отчетов сервисы отчетов выполняют запросы к указанным источникам данных. Сервисы отчетов требуют указания учетной записи для доступа к этим источникам данных. Для защиты такой информации должны использоваться механизмы SSL в следующих сценариях:
- применение нестандартной аутентификации (Custom Authentication) — в этом случае пользователи должны указывать учетные данные для доступа к серверу, на котором выполняются сервисы отчетов. Для защиты учетных данных следует использовать SSL,
- подключение к внешним источникам данных — если отчеты обращаются к внешним источникам данных, которые требуют дополнительной аутентификации, необходимо использовать SSL для передачи требуемых данных,
- доступ к сервисам отчетов через Интернет — при доступе к серверу, на котором выполняются сервисы отчетов, через Интернет следует применять SSL для сохранения учетных данных, а также данных самих отчетов;
- отключение поддержки Integrated Security в источниках данных для отчетов — при использовании Integrated Security для источников данных для отчетов сервисы отчетов выполняют код ряда компонентов с теми же привилегиями, которые есть у пользователя, сгенерировавшего отчет. В результате учетная запись пользователя может быть передана внешнему источнику данных. Кроме того, вредоносный код может повредить серверу;
- создание резервных копий ключей шифрования — ключи шифрования применяются для защиты хранимых данных об учетных записях и доступа к отчетам. Такие ключи создаются либо во время инициализации сервера отчетов (как часть процедуры установки), либо во время конфигурации сервера отчетов. Необходимо создать резервную копию симметричных ключей и использовать ее при восстановлении сервера, на котором выполняются сервисы отчетов.
Безопасность в нотификационных сервисах
Безопасность в нотификационных сервисах достигается за счет применения ролей на уровне базы данных и ограниченного пользовательского доступа. Учетные записи, используемые ядром нотификационных сервисов, а также клиентскими приложениями для доступа к SQL Server, могут быть либо Windows Authentication, либо Mixed Mode Authentication. Учетные записи обеспечивают доступ к базе данных через пользовательские учетные записи на уровне базы, а затем применяются для получения необходимых прав через роли, определенные для нотификационных сервисов.
Для защиты нотификационных сервисов применимы следующие способы обеспечения безопасности:
- выполнение ядра нотификационных сервисов под локальной учетной записью или доменом с низкими привилегиями — не используйте учетные записи Local System, Local Service и Network Service, а также учетные записи из группы Administrators. Тем не менее необходимо помнить, что протокол доставки может потребовать наличия дополнительных привилегий для учетной записи, под которой выполняется сервис;
- каждое ядро должно иметь набор привилегий, минимально необходимых для выполнения операций, — при применении нотификационных сервисов в односерверных средах внутри ядра выполняются все события, провайдеры, генераторы и механизмы рассылки. Для обеспечения этой работы к роли базы данных NSRunService должны быть добавлены учетные записи, используемые ядром. При масштабировании событий, провайдеров, генераторов и механизмов рассылки на другие серверы необходимо:
- добавить учетные записи, применяемые обработчиками событий, к роли NSEventProvider,
- добавить учетные записи, используемые генераторами, к роли NSGenerator,
- добавить учетные записи, используемые дистрибьюторами (механизмами рассылки), к роли NSDistributor,
- роль NSRunService является надмножеством ролей NSEventProvider, NSGenerator и NSDistributor;
- обеспечение безопасности файлов и папок — нотификационные сервисы используют ряд файлов и папок для хранения конфигурационной информации, данных приложения и конфигурации экземпляров сервисов. Ядро нотификационных сервисов должно иметь доступ к этим файлам и папкам, но пользователи не должны иметь возможности изменить конфигурацию или повредить событийные данные. Для защиты файлов и папок, применяемых нотификационными сервисами, может использоваться один из следующих методов:
- применение разрешений NTFS для ограничения доступа к папкам и файлам,
- задействование механизмов Encrypted File System (EFS) для шифрования ряда файлов и папок и предотвращения неавторизованного доступа;
- проверка вводимой пользователями информации — если приложение использует поля протокола Subscriber, Subscriber Device или Subscription Information, необходимо реализовать способы проверки вводимой пользователями информации. Это требование связано с тем, что сервисы нотификаций не содержат механизмов проверки содержимого полей заголовков протокола;
- использование рекомендации по защите компонентов приложений и паролей — при создании определенного класса приложений, например приложений, обрабатывающих события, необходимо применять механизмы Data Protection Application Programming Interface (DPAPI) для шифрования информации. Помимо этого рекомендуется использовать минимальный уровень привилегий для выполнения таких приложений и обеспечить соответствующий уровень безопасности бинарных файлов.
Безопасность в интеграционных сервисах
В интеграционных сервисах, реализованных в SQL Server 2005, появился ряд новых механизмов обеспечения безопасности для сохранения конфиденциальных данных — имен пользователей и паролей, хранимых внутри пакетов. Новые механизмы безопасности защищают целостность пакетов, а также среду, в которой они выполняются. В процессе дизайна приложений, использующих интеграционные сервисы, следует иметь в виду такие возможности, как шифрование пакетов и применение новых ролей на уровне базы данных.
Для защиты интеграционных сервисов приемлемы следующие способы обеспечения безопасности:
- цифровая подпись пакетов — в SQL Server 2005 появилась возможность цифровой подписи пакетов SQL Server Integration Services. Используя цифровую подпись, можно идентифицировать измененные пакеты и запрещать их загрузку;
- шифрование пакета целиком — имеется возможность шифрования всего пакета с применением пароля или пользовательского ключа. Пользовательский ключ используется в тех случаях, когда пакет должен выполнить только один конкретный пользователь. Пароль представляет собой более гибкое решение — несколько пользователей могут применять один и тот же пароль для запуска пакета;
- выборочное шифрование конфиденциальных данных — как мы уже говорили, для защиты всех объектов внутри пакета его можно зашифровать целиком. В SQL Server Integration Services также есть возможность выборочного шифрования пакетов — для этого используется свойство ProtectionLevel;
- контроль за доступом к пакетам, хранящимся в msdb, — если вы решили хранить пакеты SQL Server Integration Services в базе данных msdb, то можете контролировать доступ к таким пакетам с применением новых ролей базы данных: db_dtsadmin, db_dtsltuser и db_dtsoperator;
- защита среды выполнения — если вы сохраняете пакеты SQL Server Integration Services в файловой системе в виде XML-файлов (*.dtsx), то необходимо обеспечить защиту папок, в которых сохраняются пакеты, а также самих XML-файлов.
Безопасность в сервисах репликации
В SQL Server 2005 сервисы репликации расширены новыми механизмами, к которым, в частности, относится HTTP-репликация через Web — наиболее требовательный с точки зрения безопасности механизм. Минимальным требованием для обеспечения безопасности при репликации через Интернет является использование Secure Socket Layer (SSL).
Для защиты сервисов репликации применимы следующие способы обеспечения безопасности:
- использование подходящих механизмов аутентификации — как и в случае с ядром базы данных SQL Server, в сервисах репликации доступны два механизма аутентификации — Windows Authentication и Mixed Mode Authentication. Рекомендуется применять Windows Authentication — этот механизм оптимален в тех случаях, когда все серверы, включенные в репликацию, находятся в одной доменной структуре. Когда один или несколько серверов располагаются вне доверительной доменной структуры, следует использовать Mixed Mode Authentication;
- безопасное применение Replication Agent — в SQL Server 2005 реализована новая модель безопасности Replication Agent, которая позволяет более точно управлять учетными записями агента репликации. Имеется возможность ассоциировать каждого агента репликации с определенной учетной записью и таким образом наделить его только теми правами, которые реально необходимы для выполнения тех или иных операций;
- использование списков публикаций Publication Access List (PAL) — для управления доступом к публикациям следует применять списки публикаций, обеспечивающие соответствие между учетными записями пользователей и агентов репликаций. Для управления большой группой пользователей рекомендуется создать Windows-группу, добавить к ней необходимых пользователей, а затем внести эту группу в соответствующий PAL-список;
- защита папки Snapshot — Snapshot-папка содержит реплицированные данные и является внешней по отношению к SQL Server. Находящиеся в ней данные являются такими же конфиденциальными, как и данные внутри базы данных, и должны быть защищены от несанкционированного доступа. Агенты Replication Merge Agent и Replication Distribution Agent должны иметь доступ к этой папке только в режиме чтения, агент Replication Snapshot Agent требует доступа к папке Snapshot в режиме чтения. При смене местоположения папки Snapshot необходимо предоставить соответствующие права агентам SQL Server Replication Services;
- защита данных, реплицируемых через Интернет, — при необходимости репликации данных через Интернет в SQL Server 2005 можно использовать два способа защиты данных — создать виртуальный канал (VPN) между реплицируемыми серверами или применить Web-синхронизацию. При использовании репликации с объединением (Merge Replication) следует отдать предпочтение Web Synchronization, так как в этом случае поддерживается SSL-шифрование через HTTPS. В сценариях транзакционной или snapshot-репликации рекомендуется применять VPN-канал между реплицируемыми серверами.
Безопасность для SQL Server Agent и Database Mail
Для управления SQL Server Agent и для включения или отключения Database Mail используется утилита Surface Area Configuration. Чтобы запустить утилиту, следует выбрать меню Start, а потом — All Programs, SQL Server Surface Area Configuration. В диалоговой панели Surface Area Configuration for Services and Connections выбираем вкладку View By Instance, а затем — SQL Server Agent. После этого можно запустить или остановить соответствующий сервис, а также выбрать наиболее подходящий режим его запуска.
В диалоговой панели SQL Server 2005 Surface Area Configuration выбираем Surface Area Configuration for Features, где нам нужна вкладка View By Instance, потом в ветви Database Engine находим Database Mail. Хранимые процедуры, используемые Database Mail, по умолчанию запрещены к выполнению и должны быть включены.
SQL Server Agent
В SQL Server 2005 реализована новая среда безопасного выполнения для SQL Server Agent. Каждая работа агента может выполняться в различном контексте безопасности с использованием системных или прокси-учетных записей.
Настройка SQL Server Agent
Для защиты SQL Server Agent подходят следующие способы обеспечения безопасности:
- корректная конфигурация сервисных учетных записей SQL Server Agent — учетная запись Windows, от имени которой была запущена служба SQL Server Agent, должна входить в роль sysadmin и иметь разрешение на выполнение ряда операций (таких как увеличение квот памяти для процесса), выполняться как часть операционной системы, игнорировать traverse checking, протоколироваться как пакетная операция и как сервис, замещать токен на уровне процесса. Учетная запись, используемая SQL Server Agent, не должна принадлежать группе Administrators;
- применение прокси-учетных записей и подсистем — каждый шаг работы SQL Server Agent может выполняться в разном контексте безопасности SQL Server 2005. Для этого можно создать прокси-учетную запись и ассоциировать ее с соответствующими правами Windows для доступа к внешним ресурсам.
Database Mail
В SQL Server 2005 появился новый компонент поддержки почты Simple Mail Transport Protocol (SMTP) — Database Mail. Этот компонент требует иных, по сравнению с SQL Mail, настроек безопасности.
Настройка Database Mail
Для защиты Database Mail применимы следующие способы обеспечения безопасности:
- включение поддержки Database Mail (только в случае необходимости использования этого компонента!) — компонент Database Mail по умолчанию отключен. Для его включения применяется утилита SQL Server 2005 Surface Area Configuration;
- использование настраиваемых профилей Database Mail — если задать общий профиль Database Mail, все владельцы базы данных msdb будут иметь доступ к этому профилю. При задании нестандартного профиля имеется возможность указать пользователей, которые будут иметь к нему доступ. Эти пользователи также должны быть членами роли DatabaseMailUserRole в msdb;
- задание ограничения на размер прикрепляемых файлов и поддерживаемые типы файлов.
 |
|
Заключение
В этой статье мы рассмотрели вопросы обеспечения безопасного использования различных сервисов, входящих в состав SQL Server 2005. В следующем номере мы обратимся к вопросам создания объектов, управляющих доступом к базе данных, а также расскажем о различных механизмах аудита.
