Защита приложений RDS

В этом разделе содержатся сведения о безопасности для RDS.

Важный

Начиная с Windows 8 и Windows Server 2012, компоненты сервера RDS больше не включены в операционную систему Windows (дополнительные сведения см. в статье Windows 8 и Windows Server 2012 Compatibility Cookbook). Клиентские компоненты RDS будут удалены в будущей версии Windows. Избегайте использования этой функции в новой работе разработки и планируйте изменение приложений, которые в настоящее время используют эту функцию. Приложения, использующие RDS, должны перенестися в службы данных WCF.

Проблемы безопасности Microsoft Internet Explorer

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

Безопасность и веб-сервер

Если вы используете объект RDSServer.DataFactory на веб-сервере Интернета, помните, что это создает потенциальный риск безопасности. Внешние пользователи, получающие допустимое имя источника данных (DSN), идентификатор пользователя и сведения о пароле, могут записывать страницы для отправки любого запроса в этот источник данных. Если требуется более ограниченный доступ к источнику данных, следует отменить регистрацию и удалить объект RDSServer.DataFactory (msadcf.dll), а вместо этого использовать пользовательские бизнес-объекты с жестко закодированными запросами.

Дополнительные сведения о последствиях безопасности использования объекта RDSServer.DataFactory см. на веб-сайте Microsoft Security Bulletin MS99-025.

Олицетворение клиента и безопасность

Если для веб-сервера IIS задано свойство проверки подлинности пароля (для Windows NT 4.0) или встроенной проверки подлинности Windows (для Windows 2000), бизнес-объекты вызываются в контексте безопасности клиента. Это новая функция в RDS 1.5, которая разрешает олицетворение клиента по протоколу HTTP. При работе в этом режиме вход на веб-сервер (IIS) не является анонимным, а используется идентификатор пользователя и пароль, под которыми работает клиентский компьютер. Если доменные сети ODBC настроены для использования доверенного подключения, то доступ к базам данных, таким как SQL Server, также происходит в контексте безопасности клиента. Но это работает только в том случае, если база данных находится на том же компьютере, что и службы IIS; Учетные данные клиента не могут быть перенесены на другой компьютер.

Например, клиент, Джон Доу, с userid="JohnD" и password="<секрет>" выполнил вход на клиентский компьютер. Джон Doe запускает браузерное приложение, которое должно получить доступ к объекту RDSServer.DataFactory, чтобы создать объект Recordset, выполнив SQL-запрос на компьютере "MyServer" под управлением IIS. MyServer, система под управлением Windows NT Server 4.0, настроена для использования проверки подлинности Windows NT Challenge/Response, ее DSN ODBC имеет выбранный параметр "Использовать доверенное подключение", а сервер также содержит источник данных SQL Server. При получении запроса на веб-сервере клиент запрашивает идентификатор пользователя и пароль. Таким образом, запрос регистрируется в MyServer как исходящий от "JohnD"/"<секрет>" вместо IUSER_MyServer (который по умолчанию используется при проверке подлинности анонимного пароля). Аналогичным образом, при входе в SQL Server используется "JohnD"/"<секрет>".

Следовательно, режим проверки подлинности iis Windows NT Challenge/Response позволяет создавать HTML-страницы без явного запроса на ввод идентификатора пользователя и пароля, необходимых для входа в базу данных. Если используется обычная проверка подлинности IIS, это также потребуется.

Проверка подлинности паролей

RDS может взаимодействовать с веб-сервером IIS, работающим в любом из трех режимов проверки подлинности паролей: анонимный, базовый или NT Challenge/Response (называемый встроенной проверкой подлинности Windows в Windows 2000). Эти параметры определяют, как веб-сервер управляет доступом через него, например требование, что клиентский компьютер имеет явные права доступа на веб-сервере NT.