Первая часть предлагаемой статьи посвящена новшествам в управлении доступом к данным и сервисам.

Управление доступом. Общие сведения

Авторизация и аутентификация

Аутентификация — это процесс проверки права пользователя на доступ к тому или иному ресурсу. Чаще всего аутентификация осуществляется с помощью ввода имени и пароля.

SQL Server 2005 поддерживает два режима аутентификации: с помощью Windows и с помощью SQL Server. Первый режим позволяет реализовать решение, основанное на однократной регистрации пользователя и едином пароле при доступе к различным приложениям (Single SignOn solution, SSO). Подобное решение упрощает работу пользователей, избавляя их от необходимости запоминания множества паролей и тем самым снижая риск их небезопасного хранения (вспомним стикеры с паролями, наклеенные на мониторы). Кроме того, данный режим позволяет использовать средства безопасности, предоставляемые операционной системой, такие как применение групповых и доменных политик безопасности, правил формирования и смены паролей, блокировка учетных записей, применение защищенных протоколов аутентификации с помощью шифрования паролей (Kerberos или NTLM).

Аутентификация с помощью SQL Server предназначена главным образом для клиентских приложений, функционирующих на платформах, отличных от Windows. Этот способ считается менее безопасным, но в SQL Server 2005 он поддерживает шифрование всех сообщений, которыми обмениваются клиент и сервер, в том числе с помощью сертификатов, сгенерированных сервером. Шифрование также повышает надежность этого способа аутентификации. Для учетной записи SQL Server можно указать такой параметр, как необходимость сменить пароль при первом соединении с сервером. Если SQL Server 2005 работает под управлением Windows Server 2003, можно воспользоваться такими параметрами учетной записи, как проверка срока действия пароля и локальная парольная политика Windows (рис. 1).

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

Схемы, не имеющие отношения к пользователям

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

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

Роли

Для упрощения управления правами доступа в большинстве серверных СУБД применяется механизм ролей — наборов прав доступа к объектам базы данных, присваиваемых некоторой совокупности пользователей. При использовании ролей управление распределением прав доступа к объектам между пользователями, выполняющими одинаковые функции и применяющими одни и те же приложения, существенно упрощается: создание роли и однократное назначение ей соответствующих прав осуществляется намного быстрее, нежели определение прав доступа каждого пользователя к каждому объекту. SQL Server 2005 позволяет создавать так называемые вложенные роли, то есть присваивать одной роли другую со всеми ее правами. Это упрощает управление не только правами пользователей, но и самими ролями, создавая, к примеру, сходные между собой группы ролей.

SQL Server 2005 также поддерживает так называемые роли для приложений (application roles), которые могут использоваться для ограничения доступа к объектам базы данных в тех случаях, когда пользователи обращаются к данным с помощью конкретных приложений. В отличие от обычных ролей, роли для приложений, как правило, неактивны и не могут быть присвоены пользователям. Их применение оказывается удобным в том случае, когда требования безопасности едины для всех пользователей, при этом не требуется аудит или иная регистрация деятельности конкретных пользователей в базе данных.

Рекомендации по управлению доступом

Ниже следует ряд несложных рекомендаций, касающихся применения средств управления доступом при создании и развертывании решений на основе SQL Server 2005.

Применение схем и ролей. Общие принципы

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

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

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

Управление доступом в службах отчетов

При применении служб отчетов (Reporting Services) необходимо отдельно позаботиться о правилах доступа к объектам базы данных для пользователей, применяющих приложения, обращающиеся к этим службам. Так, указанной категории пользователей должны быть доступны как сами описания отчетов, так и те объекты базы данных, на основании которых эти отчеты генерируются, и в этом случае наиболее уместно создание отдельной роли, обладающей указанными правами. Следует заметить, что по умолчанию службы отчетов используют службы Internet Information Services (IIS) и средства безопасности Windows для аутентификации пользователей на сервере отчетов. Данный режим считается наиболее безопасным, поскольку может позволить запретить анонимный доступ к web-приложениям, выполняющимся под управлением IIS.

Отметим, что сервисы отчетов могут выполняться в режиме Integrated Security. Но в этом случае они выполняют код ряда компонентов с теми же привилегиями, что и у пользователя, сгенерировавшего отчет, а это позволит пользователю, исполняющему отчет, получить более высокие привилегии, нежели ему положены. Поэтому данный режим не рекомендуется применять вместе со службами отчетов.

Управление доступом в службах уведомлений

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

Отметим, что для служб уведомлений существуют специальные роли — NSEventProvider, NSGenerator, NSDistributor, которые следует присваивать учетным записям, отвечающим за провайдеры, генераторы и механизмы рассылки, а также роль NSRunService, включающая в себя три перечисленные роли и применяющаяся в том случае, если все составные части служб уведомлений выполняются внутри одного ядра базы данных.

Управление доступом в интеграционных службах

Для управления доступом в интеграционных службах в SQL Server 2005 введены новые роли: db_dt sadmin, db_dt sltuser и db_dtsoperator. Они позволяют осуществлять контроль доступа к пакетам интеграционных служб, хранящихся в базе данных msdb.

Управление доступом в службах репликации

Для управления доступом в службах репликации SQL Server 2005 была создана новая модель безопасности этих служб, позволяющая более гибко управлять учетными записями агента репликации (Replication Agent). Теперь каждый агент репликации может выполняться под собственной учетной записью, что позволяет наделить каждого агента именно теми правами, которые требуются для его функционирования, без присвоения избыточных привилегий. При этом, если серверы, участвующие в процессе репликации, находятся в одном домене, для указанных учетных записей рекомендуется использовать аутентификацию Windows.

Для управления доступом к самим публикациям рекомендуется для каждого агента использовать списки публикаций — Publication Access Lists, включающие учетные записи пользователей. Отдельно отметим необходимость защиты папки файловой системы Snapshot, содержащей реплицированные данные, и предоставлять агентам, не осуществляющим запись в эту папку, таким как Replication Merge Agent и Replication Distribution Agent, доступ только в режиме чтения.

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

Агент SQL Server Agent должен выполняться от имени учетной записи Windows, обладающей ролью sysadmin, но не принадлежащей группе Administrators и имеющей разрешение на увеличение квот памяти для процесса. Сам SQL Server Agent должен выполняться как служба операционной системы, протоколироваться как сервис. Кроме того, можно создать специальную прокси-запись и ассоциировать ее с соответствующими правами Windows для доступа к внешним ресурсам.

Для управления службой SQL Server Agent можно использовать утилиту Surface Area Configuration (рис. 3).

Управление доступом для Database Mail

Database Mail — это новый компонент SQL Server 2005, предназначенный для поддержки протокола SMTP (Simple Mail Transport Protocol). Для управления доступом к нему рекомендуется создавать настраиваемые профили, позволяющие указать, каким образом пользователи базы данных msdb имеют доступ к данному профилю (самим пользователям следует присвоить роль DatabaseMailUserRole базы данных msdb). Для управления службой Database Mail можно также использовать утилиту Surface Area Configuration (рис. 4).

Управление доступом к базе данных с помощью протокола HTTP

Поскольку HTTP-доступ является одним из наиболее распространенных способов атак на приложения извне, следует разрешить доступ к HTTP Endpoints только тем пользователям или группам, которым он действительно необходим. Кроме того, на сервере баз данных следует отключить учетную запись Windows Guest, поскольку она позволяет пользователям подключаться к компьютеру без ввода пароля. В очередной раз напомним: доступ к SQL Server через Интернет должен осуществляться только посредством брандмауэра.

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