Безопасный доступ к данным (ADO.NET)

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

Проверка подлинности, авторизация и разрешения

При соединении с Microsoft SQL Server можно применить проверку подлинности Windows, также известную как встроенная безопасность, использующую идентификатор текущего активного пользователя Windows, а не передачу идентификатора пользователя и пароль. Настоятельно рекомендуется использовать проверку подлинности Windows, поскольку учетные данные пользователя не отображаются в строке соединения. Если при соединении с SQL Server нельзя использовать проверку подлинности Windows, следует рассмотреть создание строк соединений во время выполнения с помощью SqlConnectionStringBuilder.

Учетные данные, используемые для проверки подлинности, необходимо обрабатывать по-разному в зависимости от типа приложения. Например, в приложении Windows Forms пользователю могут предложить ввести сведения для проверки подлинности либо могут использоваться учетные данные пользователя Windows. Однако веб-приложение часто осуществляет доступ к данным, используя учетные данные, поставляемые самим приложением, а не пользователем.

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

Дополнительные сведения см. в следующих ресурсах.

Параметризованные команды и внедрение кода SQL

Использование параметризованных команд помогает защищаться от атак путем внедрения кода SQL, в которых атакующий «внедряет» в инструкцию SQL команду, нарушающую безопасность сервера. Параметризованные команды обеспечивают защиту против атак путем внедрения кода SQL, гарантируя, что данные, полученные от внешнего источника, передаются только как значения, а не как часть инструкции Transact-SQL. В результате команды Transact-SQL, вставленные в значение, не выполняются в источнике данных. Вместо этого они оцениваются только как значение параметра. В дополнение к повышенной безопасности параметризованные команды предоставляют удобный метод организации значений, передаваемых с инструкцией Transact-SQL или в хранимую процедуру.

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

Эксплойты скриптов

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

Дополнительные сведения см. в следующих ресурсах.

Атаки зондированием

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

Дополнительные сведения см. в следующих ресурсах.

Защита источников данных Microsoft Access и Excel

Если требования по безопасности являются минимальными или вообще отсутствуют, то Microsoft Access и Microsoft Excel вполне могут выступить в роли хранилища данных для приложения ADO.NET. Предусмотренные в них средства безопасности позволяют эффективно затруднить несанкционированный доступ, но если требуется добиться большего, чем просто воспрепятствовать вторжению со стороны неосведомленных пользователей, то на них не следует полагаться. Физические файлы данных для Access и Excel находятся в файловой системе и должны быть доступными для всех пользователей. В результате они становятся уязвимыми к атакам, что может привести к похищению или потере данных, поскольку эти файлы можно скопировать или изменить. Если требуется надежная система безопасности, следует использовать SQL Server или другую серверную базу данных, в которой физические файлы данных не считываются из файловой системы.

Дополнительные сведения о защите данных Access и Excel см. в одном из следующих источников.

Корпоративные службы

COM+ содержит собственную модель безопасности, полагающуюся на учетные записи и олицетворение «процесс-поток» Windows NT. Пространство имен System.EnterpriseServices предоставляет оболочки, позволяющие приложениям .NET встраивать управляемый код со службами безопасности COM+ с помощью класса ServicedComponent.

Дополнительные сведения см. в следующих ресурсах.

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

Инфраструктура .NET Framework обеспечивает взаимодействие с неуправляемым кодом, включая компоненты COM, службы COM+, внешние библиотеки типов и многие службы операционной системы. Работа с неуправляемым кодом связана с выходом за пределы периметра безопасности для управляемого кода. И пользовательский код, и любой другой вызывающий его код должен иметь разрешение для неуправляемого кода (SecurityPermission с заданным флагом UnmanagedCode). Применение неуправляемого кода может привести к непреднамеренному созданию в приложении уязвимых мест системы безопасности. Таким образом, следует допускать возможность взаимодействия с неуправляемым кодом только в случае крайней необходимости.

Дополнительные сведения см. в следующих ресурсах.

См. также

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

Рекомендации по стратегиям доступа к данным

Защита сведений о соединении (ADO.NET)

Построители строк соединения (ADO.NET)

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

Защита приложений ADO.NET

Безопасность SQL Server (ADO.NET)