Безопасный доступ к данным

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

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

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

Внимание

Корпорация Майкрософт рекомендует использовать самый безопасный поток проверки подлинности. Если вы подключаетесь к Azure SQL, Управляемые удостоверения для ресурсов Azure — это рекомендуемый метод проверки подлинности.

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

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

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

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

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

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

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

Ресурс Описание
Параметры DataAdapter Описывает, как использовать параметры с DataAdapter.
Изменение данных с помощью хранимых процедур Описывает способ задания параметров и получения возвращаемого значения.
Хранимые процедуры (ядро СУБД) Описывает преимущества использования хранимых процедур и различных типов хранимых процедур.

Зондирующие атаки

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

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

Ресурс Описание
Обработка и создание исключений в .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). Применение неуправляемого кода может привести к непреднамеренному созданию в приложении уязвимых мест системы безопасности. Таким образом, следует допускать возможность взаимодействия с неуправляемым кодом только в случае крайней необходимости.

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

См. также

  • Last updated on