Безопасный доступ к данным
Для записи безопасного кода ADO.NET необходимо понять механизмы безопасности, доступные в базовом хранилище данных или базе данных. Кроме того, необходимо учитывать последствия безопасности других функций или компонентов, которые могут содержать ваше приложение.
Проверка подлинности, авторизация и разрешения
При соединении с Microsoft SQL Server можно применить проверку подлинности Windows, также известную как встроенная безопасность, использующую идентификатор текущего активного пользователя Windows, а не передачу идентификатора пользователя и пароль. Для локальных баз данных рекомендуется использовать проверку подлинности Windows, так как учетные данные пользователя не предоставляются в строка подключения. Если вы не можете использовать проверку подлинности Windows для подключения к SQL Server, рассмотрите возможность создания строка подключения во время выполнения.SqlConnectionStringBuilder
Внимание
Корпорация Майкрософт рекомендует использовать самый безопасный поток проверки подлинности. Если вы подключаетесь к SQL Azure, управляемые удостоверения для ресурсов Azure — это рекомендуемый метод проверки подлинности.
Учетные данные, используемые для проверки подлинности, необходимо обрабатывать по-разному в зависимости от типа приложения. Например, в приложении Windows Forms пользователю могут предложить ввести сведения для проверки подлинности либо могут использоваться учетные данные пользователя Windows. Однако веб-приложение часто осуществляет доступ к данным, используя учетные данные, поставляемые самим приложением, а не пользователем.
После проверки подлинности пользователей возможная область их действий зависит от предоставленных им разрешений. Всегда следуйте принципу минимальных прав доступа и предоставляйте только абсолютно необходимые разрешения.
Для получения дополнительных сведений см. следующие ресурсы.
| Ресурс | Description |
|---|---|
| Защита сведений о подключении | Приводятся рекомендации по безопасности и методы защиты данных подключения, например использование для шифрования строк подключения защищенной конфигурации. |
| Построители строк подключения | Описывает способ построения строк соединения по данным, введенным пользователем во время выполнения. |
| Безопасность ядро СУБД SQL Server и База данных SQL Azure | Содержит ссылки для поиска сведений о безопасности и защите в ядро СУБД SQL Server и База данных SQL Azure. |
Параметризованные команды и внедрение кода SQL
Использование параметризованных команд помогает защищаться от атак путем внедрения кода SQL, в которых атакующий «внедряет» в инструкцию SQL команду, нарушающую безопасность сервера. Параметризованные команды обеспечивают защиту против атак путем внедрения кода SQL, гарантируя, что данные, полученные от внешнего источника, передаются только как значения, а не как часть инструкции Transact-SQL. В результате команды Transact-SQL, вставленные в значение, не выполняются в источнике данных. Вместо этого они оцениваются только как значение параметра. В дополнение к повышенной безопасности параметризованные команды предоставляют удобный метод организации значений, передаваемых с инструкцией Transact-SQL или в хранимую процедуру.
Дополнительные сведения об использовании параметризованных команд см. в одном из следующих источников.
| Ресурс | Description |
|---|---|
| Параметры DataAdapter | Описывает способ использования параметров с DataAdapter. |
| Изменение данных с помощью хранимых процедур | Описывает способ задания параметров и получения возвращаемого значения. |
| Хранимые процедуры (ядро СУБД) | Описывает преимущества использования хранимых процедур и различных типов хранимых процедур. |
Атаки зондированием
Для осуществления атаки на систему злоумышленники часто используют сведения из исключения, например имя сервера, базы данных или таблицы. Безусловно, исключения могут содержать конкретные сведения о приложении или источнике данных, поэтому можно сделать защиту приложения и источника данных более надежной, отображая для клиента только самые существенные сведения.
Для получения дополнительных сведений см. следующие ресурсы.
| Ресурс | Description |
|---|---|
| Обработка и создание исключений в .NET | Описывает основные формы таких структурированных средств обработки исключений, как конструкции «try/catch/finally». |
| Рекомендации по обработке исключений | Описывает рекомендации по обработке исключений. |
Защита источников данных Microsoft Access и Excel
Если требования по безопасности являются минимальными или вообще отсутствуют, то Microsoft Access и Microsoft Excel вполне могут выступить в роли хранилища данных для приложения ADO.NET. Предусмотренные в них средства безопасности позволяют эффективно затруднить несанкционированный доступ, но если требуется добиться большего, чем просто воспрепятствовать вторжению со стороны неосведомленных пользователей, то на них не следует полагаться. Физические файлы данных для Access и Excel находятся в файловой системе и должны быть доступными для всех пользователей. В результате они становятся уязвимыми к атакам, что может привести к похищению или потере данных, поскольку эти файлы можно скопировать или изменить. Если требуется надежная система безопасности, следует использовать SQL Server или другую серверную базу данных, в которой физические файлы данных не считываются из файловой системы.
Корпоративные службы
COM+ содержит собственную модель безопасности, которая зависит от учетных записей Windows и олицетворения процессов или потоков. Пространство имен System.EnterpriseServices предоставляет оболочки, позволяющие приложениям .NET встраивать управляемый код со службами безопасности COM+ с помощью класса ServicedComponent.
Взаимодействие с неуправляемыми кодом
платформа .NET Framework обеспечивает взаимодействие с неуправляемыми компонентами, com-компонентами, службами COM+, библиотеками внешних типов и многими службами операционной системы. Работа с неуправляемым кодом связана с выходом за пределы периметра безопасности для управляемого кода. И пользовательский код, и любой другой вызывающий его код должен иметь разрешение для неуправляемого кода (SecurityPermission с заданным флагом UnmanagedCode). Применение неуправляемого кода может привести к непреднамеренному созданию в приложении уязвимых мест системы безопасности. Таким образом, следует допускать возможность взаимодействия с неуправляемым кодом только в случае крайней необходимости.
Дополнительные сведения см. в разделе Взаимодействие с неуправляемым кодом.