Сценарии защиты приложений в SQL Server (ADO.NET)
Обновлен: November 2007
Не существует одного правильного способа создания безопасного клиентского приложения SQL Server. Каждое приложение уникально своими требованиями, средой развертывания и количеством пользователей. Приложение, довольно хорошо защищенное при начальном развертывании, с течением времени может стать менее защищенным. Невозможно точно предсказать, какие угрозы могут возникнуть в будущем.
SQL Server как продукт имел много версий, включающих новейшие средства безопасности, которые позволяют разработчикам создавать безопасные приложения баз данных. Однако безопасность не является встроенным элементом; для нее требуется постоянное наблюдение и постоянные обновления.
Наиболее распространенные угрозы
Разработчикам надо понимать угрозы безопасности, средства, предоставляемые для отражения этих угроз, и методы предотвращения внутренних брешей в безопасности. Безопасность можно рассматривать как цепь, в которой разрыв одного звена нарушает прочность всей цепи. В следующем списке приводятся наиболее распространенные угрозы безопасности, более подробно рассматриваемые в соответствующих разделах этой темы.
Атака путем внедрения кода SQL
Внедрение кода SQL — это процесс, посредством которого пользователь-злоумышленник вводит инструкции языка Transact-SQL вместо допустимых входных данных. Если входные данные передаются непосредственно на сервер без оценки и если приложение случайно выполнит инфицированный код, атака сможет повредить или уничтожить данные. Атака путем внедрения кода SQL Server можно предотвратить, используя хранимые процедуры и параметризованные команды, отказавшись от динамического SQL и ограничив разрешения для всех пользователей.
Повышение прав доступа
Атаки повышения прав доступа возникают, если пользователь может принимать права доступа доверенной учетной записи, например учетной записи владельца или администратора. Всегда следует выполнять код под учетными записями с наименьшими правами доступа и назначать только необходимые разрешения. Избегайте использования учетных записей администратора или владельца для выполнения кода. Это ограничивает ущерб, который может быть нанесен при успешной атаке. При выполнении задач, для которых нужны дополнительные разрешения, используйте подписание процедуры или олицетворение только на время выполнения задачи. Начиная с SQL Server 2005, можно подписывать хранимые процедуры при помощи сертификатов или использовать олицетворение для временного назначения разрешений.
Зондирование и интеллектуальное наблюдение
Атака зондирования может использовать сообщения об ошибках, формируемые приложением, для поиска уязвимости системы безопасности. Для предотвращения возврата конечному пользователю сведений об ошибках SQL Server следует реализовать обработку ошибок в любом процедурном коде.
Проверка подлинности
Если строка соединения, основанная на именах входа SQL Server, конструируется во время выполнения, может возникнуть атака путем внедрения кода в строку соединения. Если строка соединения не проверяется на допустимые пары ключевых слов, атакующая сторона может вставить дополнительные символы и, возможно, получить доступ к конфиденциальным данным или другим ресурсам на сервере. По возможности используйте проверку подлинности Windows. Если необходимо использовать имена входа SQL Server, используйте SqlConnectionStringBuilder для создания и проверки строк соединения во время выполнения.
Пароли
Многие атаки выполняются успешно из-за того, что лицо, не имеющее санкционированного доступа, смогло получить или угадать пароль для пользователя с правами доступа. При попытке взлома пароли выступают в качестве первой линии обороны, поэтому убедитесь, что введены надежные пароли, так как это необходимо для защиты системы. Начиная с SQL Server 2005, имеется возможность создания и включение политики паролей для смешанной проверки подлинности.
Всегда задавайте надежный пароль учетной записи sa, даже если используется проверка подлинности Windows.
В этом разделе
Управление разрешениями с помощью хранимых процедур в SQL Server (ADO.NET)
Описывает, как использовать хранимые процедуры для управления разрешениями и контроля доступа к данным. Использование хранимых процедур является эффективным способом ответа на многие угрозы системе безопасности.Написание защищенного динамического SQL-кода в SQL Server (ADO.NET)
Описывает технику написания защищенного динамического SQL-кода с использованием хранимых процедур.Подписывание хранимых процедур в SQL Server (ADO.NET)
Описывает, как подписать хранимую процедуру при помощи сертификата, чтобы дать возможность пользователям работать с данными, к которым у них нет непосредственного доступа. Это позволяет хранимым процедурам выполнять операции, для непосредственного выполнения которых у вызывающей стороны нет разрешений.Настройка разрешений с олицетворением в SQL Server (ADO.NET)
Описывает, как использовать предложение EXECUTE AS для олицетворения другого пользователя. Олицетворение переключает контекст выполнения с вызывающей стороны на указанного пользователя.Предоставление разрешений уровня строки в SQL Server (ADO.NET)
Описывает, как реализовать разрешения уровня строки для ограничения доступа к данным.Создание ролей приложения в SQL Server (ADO.NET)
Описывает возможности и функции ролей приложения.Включение перекрестного доступа между базами данных в SQL Server (ADO.NET)
Описывает, как включить перекрестный доступ между базами данных, не ухудшая безопасность.
См. также
Другие ресурсы
Безопасность SQL Server (ADO.NET)