Вопросы безопасности служб Notification Services

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

Модель безопасности служб Notification Services

Службы Notification Services имеют ядро, которое запускает внутрипроцессные поставщики событий, генераторы и распространители. Они также могут иметь клиентские приложения, которые пересылают события или управляют подписками.

Учетные записи для входа, используемые ядром и клиентскими приложениями, используют либо проверку подлинности Windows, либо проверку подлинности SQL Server для получения доступа к SQL Server. Они получают доступ к базам данных посредством учетных записей пользователей баз данных и получают необходимые разрешения в базах данных экземпляра и приложений посредством членства в ролях базы данных служб Notification Services.

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

Разрешения базы данных присваиваются ролям базы данных. Пользователи баз данных получают необходимые разрешения на отдельные компоненты посредством включения в соответствующую роль:

• Учетные записи, используемые поставщиками событий, получают разрешения посредством членства в роли базы данных NSEventProvider. Сервер поставщиков событий запускает внутрипроцессные поставщики событий. Внепроцессные поставщики событий являются независимыми приложениями.
• Учетные записи, используемые генераторами, получают разрешения посредством членства в роли базы данных NSGenerator.
• Учетные записи, используемые распространителями, получают разрешения посредством членства в роли базы данных NSDistributor.
• Учетные записи, используемые интерфейсами управления подписками, получают разрешения посредством членства в роли базы данных NSSubscriberAdmin.

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

Дополнительные сведения о реализации безопасности для служб Notification Services см. в разделе Обеспечение безопасности служб Notification Services.

Дополнительные учетные записи для условных действий

В Microsoft SQL Server 2005 службы Notification Services имеют новую функцию правил подписок. Правила, управляемые событиями, и запланированные правила теперь могут использовать условные действия, которые позволяют подписчикам определять подписки с более широким набором свойств, используя предложения запросов, определенные пользователями.

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

Генератор запускает правила, содержащие условные действия. Однако запросы условных действий далее ограничены учетной записью заданного пользователя базы данных. Этот пользователь базы данных задается при определении приложения служб Notification Services.

Дополнительные сведения об условных действиях см. в разделе Определение условных действий.

Разрешения Windows

В дополнение к разрешениям базы данных для некоторых компонентов также необходимы дополнительные разрешения Windows.

• Учетная запись, используемая для запуска ядра служб Notification Services, должна входить в группу Windows SQLServer2005NotificationServicesUser$ComputerName. При этом будет предоставлен доступ к двоичным файлам служб Notification Services, используемым для запуска службы. Если для запуска ядра используется служба NS$instanceName Windows, Notification Services при регистрации экземпляра добавляют учетную запись службы в группу SQLServer2005NotificationServicesUser$ComputerName.
  Все остальные компоненты, которым необходим доступ к двоичным файлам служб Notification Services, также могут требовать включения в группу SQLServer2005NotificationServicesUser$ComputerName. Сборки и ресурсы служб Notification Services находятся в глобальном кэше сборок (GAC) и доступны без включения в эту группу.
• Для поставщиков событий иногда необходимы разрешения на папки и другие базы данных. Например, поставщик событий наблюдателя файловой системы требует доступ к чтению определения XML-схемы (XSD), в котором описывается схема событий, а также доступ к чтению и изменению папки, куда помещаются файлы событий. Для поставщиков событий служб SQL Server необходим доступ к таблицам или представлениям баз данных, используемым в качестве источников событий.
• Распространителям необходимы разрешения для доставки уведомлений в службу доставки, например сервер простого протокола передачи электронной почты (SMTP), службу доставки коротких сообщений (SMS), веб-сервер или файловую систему. Распространителям, использующим модуль форматирования данных с преобразованием XSL (XSLT), также необходим доступ к файлам XSLT.

Рекомендации по безопасности

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

Ядро служб Notification Services

При развертывании экземпляра служб Notification Services следует принять во внимание следующие рекомендации по безопасности ядра служб Notification Services:

• Настройте ядро на использование проверки подлинности Windows для доступа к базам данных.
• Запускайте ядро под доменной или локальной учетной записью с малым количеством прав. Не используйте учетную запись Local System, Local Service или Network Service или какую-либо учетную запись из группы администраторов.
  Однако для протокола доставки могут потребоваться дополнительные права доступа для учетной записи, под которой запускается служба. Например, при отправке уведомлений с использованием локальной службы SMTP служб IIS, учетная запись, под которой запускается ядро, должна входить в локальную группу администраторов. (Права доступа администратора не являются обязательными при отправке уведомлений посредством службы SMTP на удаленном компьютере.)
• При развертывании экземпляра служб Notification Services убедитесь в том, что у каждого ядра есть только необходимые разрешения.
  Для развертываний с одиночным сервером ядро запускает все внутрипроцессные поставщики событий, генераторы и распространители экземпляра. Учетная запись, используемая ядром, должна получать необходимые разрешения в базах данных посредством членства в роли базы данных NSRunService.
  Для масштабных развертываний ограничьте разрешения отдельных ядер. Например, если ядро запускает только поставщики событий, то ограничьте разрешения базы данных, предоставленные учетной записи ядра, включив эту учетную запись в роль базы данных NSEventProvider и не предоставляя ей никаких других разрешений базы данных или сервера. Не используйте роль NSRunService, если только ядро не запускает все компоненты ядра.

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

• Если компоненты ядра служб Notification Services и ядро СУБД SQL Server расположены на разных серверах, то убедитесь, что для ядра базы данных включен протокол TCP/IP или именованные каналы. Для повышения безопасности ядра СУБД большинство сетевых протоколов по умолчанию отключены.
• Убедитесь в том, что у учетных записей имен входа установлены надежные пароли. Дополнительные сведения об установке надежных паролей см. в разделе «Создание надежных паролей» в документации Microsoft Windows.
• Убедитесь в том, что весь код, запускаемый ядром, например пользовательские поставщики событий, модули форматирования данных и протоколы, получен из надежного источника. Службы Notification Services предполагают, что код, приведенный в списках в конфигурации экземпляра и определении приложения, используемых для создания и обновления экземпляра служб Notification Services, получен из надежного источника. При определении приложений используйте подходящее имя сборки для гарантии загрузки правильной сборки.
• Службы Notification Services не могут проверять поля заголовков протокола. Таким образом, если приложение использует подписчика, устройство подписчика или данные о подписках в поле протокола, либо проверьте данные, вводимые пользователем, либо используйте значения, определяемые приложением (а не пользователем). Примеры данных, вводимых злонамеренными пользователями, см. в разделе атака SQL Injection.
• Обеспечьте безопасность всех папок, содержащих файлы конфигурации или данные приложений. Дополнительные сведения об обеспечении защиты файлов и папок см. в разделе Защита файлов и папок.

Размещение ядра служб Notification Services

Обычно ядро служб Notification Services является службой NS$имя_экземпляра Windows, которая создается при регистрации экземпляра служб Notification Services. Однако ядро можно размещать в приложении, не используя службу Windows.

Ядро входит в ядро СУБД и запускает экземпляр служб Notification Services. При размещении ядра служб Notification Services убедитесь в обеспечении безопасности исходных и двоичных файлов.

Дополнительные сведения о размещении ядра см. в разделе Размещение ядра служб Notification Services.

Интерфейсы управления подписками

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

При разработке интерфейса управления подписками примите во внимание следующие рекомендации по безопасности:

• Перед добавлением, удалением или изменением данных подписчика и подписки проверьте идентификацию подписчика, а затем соответствие этой идентификации идентификатору подписчика.
• Любой пользователь или приложение, имеющее учетную запись с членством в роли базы данных NSSubscriberAdmin (или более широкие действующие разрешения), может изменять данные подписчика и подписки. Не предоставляйте ненужных разрешений и защищайте имя пользователя и пароль, используемые интерфейсами управления подписками.
• Не храните конфиденциальные данные, например имена пользователей и пароли, используемые для подключения приложения к базам данных, в виде простого текста. Используйте интерфейс программирования приложений для защиты данных (DPAPI) для шифрования секретных данных и последующего сохранения этих данных в реестре.
• Если приложение должно для идентификации пользователей использовать секретные данные, например номера социального страхования, то следует предоставить пользователю несекретный идентификатор пользователя, а затем использовать таблицу уточняющих запросов в базе данных для обеспечения соответствия с данными.

Интерфейсы управления подписками часто являются веб-приложениями. Дополнительные сведения об использовании параметров безопасности приложений ASP.NET см. в разделе Развертывание интерфейса управления подписками.

Пользовательские поставщики событий

Поставщики событий пересылают данные событий приложениям служб Notification Services. Для приложений можно разработать как внутрипроцессные, так и внепроцессные поставщики событий. При разработке пользовательского поставщика событий примите во внимание следующие рекомендации по безопасности:

• Убедитесь, что поставщики событий используют роль базы данных NSEventProvider для пересылки событий.
• Любой пользователь или приложение может пересылать события в базу данных приложений при наличии действительного имени поставщика событий и учетной записи посредством членства в роли базы данных NSEventProvider (или в роли с более широкими действующими разрешениями). Не предоставляйте ненужных разрешений и защищайте имя пользователя и пароль, используемые внепроцессными поставщиками событий.
• Не сохраняйте секретные данные, например имена пользователей и пароли, в виде простого текста. Используйте DPAPI для шифрования секретных данных, а затем сохраните эти данные в реестре.
• Обеспечьте безопасность всех исходных и двоичных файлов пользовательских компонентов.

Пользовательские внутрипроцессные поставщики событий пересылают события в контексте сервера поставщиков событий. В коде внутрипроцессного поставщика событий не нужно предоставлять какие-либо учетные данные для пересылки событий. Нижеприведенные рекомендации относятся к внутрипроцессным поставщикам событий:

• При создании приложения в его определение вносится данные о пользовательском внутрипроцессном поставщике событий. Службы Notification Services считают все данные в определении приложения надежными. Используйте подходящее имя сборки для гарантии загрузки правильной сборки.

Внепроцессные поставщики событий запускаются вне контекста приложения служб Notification Services. Нижеприведенные рекомендации относятся к внепроцессным поставщикам событий:

• Службы Notification Services явным образом не считают внепроцессные поставщики событий надежными. В коде внепроцессного поставщика событий необходимо предоставить учетные данные. Заданная учетная запись должна иметь возможность входить в экземпляр Database Engine, а соответствующая учетная запись пользователя баз данных должна быть членом роли базы данных NSEventProvider во всех базах данных экземпляра и приложений.

Пользовательские протоколы доставки

Пользовательские протоколы доставки запускаются в контексте ядра служб Notification Services. Как и в случае всех пользовательских компонентов, необходимо обеспечить безопасность исходных и двоичных файлов с целью защиты секретных данных.

Управляющие объекты служб Notification Services

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

Дополнительные сведения о метаданных экземпляров и приложений, а также других файлах см. в разделе Защита файлов и папок.

См. также

Основные понятия

Обеспечение безопасности служб Notification Services

Другие ресурсы

Вопросы безопасности SQL Server
Развертывание служб Notification Services

Справка и поддержка

Получение помощи по SQL Server 2005