WWW.COMPROG.RU: Базы Данных / Разное / Безопасность в Microsoft SQL Server 2005

Первая часть предлагаемой статьи посвящена новшествам в управлении доступом к данным и сервисам.

Управление доступом. Общие сведения

Авторизация и аутентификация

Аутентификация — это процесс проверки права пользователя на доступ к тому или иному ресурсу. Чаще всего аутентификация осуществляется с помощью ввода имени и пароля.

SQL Server 2005 поддерживает два режима аутентификации: с помощью Windows и с помощью SQL Server. Первый режим позволяет реализовать решение, основанное на однократной регистрации пользователя и едином пароле при доступе к различным приложениям (Single SignOn solution, SSO). Подобное решение упрощает работу пользователей, избавляя их от необходимости запоминания множества паролей и тем самым снижая риск их небезопасного хранения (вспомним стикеры с паролями, наклеенные на мониторы). Кроме того, данный режим позволяет использовать средства безопасности, предоставляемые операционной системой, такие как применение групповых и доменных политик безопасности, правил формирования и смены паролей, блокировка учетных записей, применение защищенных протоколов аутентификации с помощью шифрования паролей (Kerberos или NTLM).

Аутентификация с помощью SQL Server предназначена главным образом для клиентских приложений, функционирующих на платформах, отличных от Windows. Этот способ считается менее безопасным, но в SQL Server 2005 он поддерживает шифрование всех сообщений, которыми обмениваются клиент и сервер, в том числе с помощью сертификатов, сгенерированных сервером. Шифрование также повышает надежность этого способа аутентификации. Для учетной записи SQL Server можно указать такой параметр, как необходимость сменить пароль при первом соединении с сервером. Если SQL Server 2005 работает под управлением Windows Server 2003, можно воспользоваться такими параметрами учетной записи, как проверка срока действия пароля и локальная парольная политика Windows (рис. 1).

Рис. 1. Установка правил для пароля пользователя

Отметим такую мелочь, как обязательное требование непустого пароля пользователя sa — как ни странно, пустой пароль данной учетной записи является весьма распространенным проявлением беспечности администраторов баз данных (и самой любимой лазейкой для похитителей корпоративных данных).

Схемы, не имеющие отношения к пользователям

Вот уже не первый десяток лет принцип распределения прав доступа к объектам баз данных в большинстве серверных СУБД основан на наличии у каждого объекта базы данных пользователя-владельца, который может предоставлять другим пользователям права доступа к объектам базы данных. При этом набор объектов, принадлежащих одному и тому же пользователю, называется схемой. Данный способ владения объектами создавал определенные неудобства при сопровождении приложений, использующих базы данных. Так, при увольнении сотрудника, создавшего объекты, используемые многими пользователями, и удалении соответствующей учетной записи приходилось вносить изменения в серверный код (а нередко и в код клиентского приложения). Понимание возможности возникновения этих проблем привело к распространению небезопасных, но простых в применении способов управления учетными записями пользователей. Вплоть до хранения их имен и паролей в обычных таблицах, что резко повышало угрозу несанкционированного доступа к данным и приложениям.

В SQL Server 2005 концепция ролей расширена: эта СУБД позволяет полностью отделить пользователя от схем и объектов базы данных. Теперь объекты базы данных принадлежат не пользователю, а схеме, не имеющей никакого отношения ни к каким учетным записям и тем более к административным привилегиям. Таким образом, схема становится механизмом группировки объектов, упрощающим предоставление пользователям прав на доступ к объектам.

Рис. 2. Установка прав для схем данных

Роли

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

SQL Server 2005 также поддерживает так называемые роли для приложений (application roles), которые могут использоваться для ограничения доступа к объектам базы данных в тех случаях, когда пользователи обращаются к данным с помощью конкретных приложений. В отличие от обычных ролей, роли для приложений, как правило, неактивны и не могут быть присвоены пользователям. Их применение оказывается удобным в том случае, когда требования безопасности едины для всех пользователей, при этом не требуется аудит или иная регистрация деятельности конкретных пользователей в базе данных.

Выполнение кода с минимальными привилегиями

Установки по умолчанию

Один из базовых принципов создания безопасных приложений — принцип предоставления минимальных привилегий, необходимых для решения поставленной задачи, — в SQL реализован в намного более строгих настройках по умолчанию, нежели в предыдущих версиях. Так, в новой версии SQL Server по умолчанию отключено значительное количество функций, таких как применение Microsoft .NET Framework в ядре СУБД, функции SQL Service Broker Network Connectivity, доступ к аналитическим службам с помощью протокола HTTP. Такие службы, как SQL Server Agent, Data Transformation Services и средства полнотекстового поиска, после установки сервера требуют ручного запуска.

Управление контекстом выполнения кода

SQL Server 2005 позволяет указать контекст безопасности, в котором будут выполняться те или иные операторы программного модуля, а именно учетной записи, использующейся при проверке разрешений на объекты, на которые ссылается процедура или функция. Это может быть, например, учетная запись пользователя, вызвавшего процедуру, или учетная запись пользователя, создавшего процедуру, или же другая учетная запись.

Одно из новшеств SQL Server 2005, реализующее принцип минимальных привилегий, позволяет выполнять хранимые процедуры и функции, определяемые пользователем, с правами другого пользователя. Для этой цели имеется оператор EXECUTE AS. Он позволяет более гибко управлять правами, предоставляемыми исполняемому коду, и не связывать их с правами самого пользователя. Указанная функциональность может применяться для безопасного управления правами пользователей. Так, решение такой часто встречающейся задачи, как предоставление доступа к процедуре без предоставления доступа к таблице, которую использует данная процедура, решается с помощью оператора EXECUTE AS без необходимости предоставления пользователям процедуры дополнительных привилегий. Конструкция EXECUTE AS, указываемая при создании соответствующего объекта базы данных, задает пользовательскую учетную запись, которую SQL Server будет использовать для проверки прав доступа к объектам, используемым в коде хранимой процедуры или пользовательской функции. В результате код, выполнение которого инициировано пользователем, выполняется так, как если бы пользователь зарегистрировался под другой учетной записью. Использование конструкции EXECUTE AS позволяет исключить цикличное назначение и проверку прав доступа при выполнении конструкций SELECT, INSERT, UPDATE, DELETE и EXECUTE, а также открытия непосредственного доступа к ряду объектов базы данных.

Уровни безопасности выполнения кода

Выполнение .NET-кода в ядре СУБД, будучи средством расширения функциональности сервера, представляет собой потенциальную уязвимость. Поэтому при загрузке сборки оно требует указания одного из трех уровней безопасности: SAFE (доступ к внешним ресурсам не допускается), EXTERNAL_ACCESS (допускается доступ к файлам, сетевым ресурсам, реестру, переменным окружения), UNSAFE (доступ ко всем ресурсам, в том числе к неуправляемому коду). Если сборка в процессе работы выйдет за указанные при ее загрузке параметры безопасности, Common Language Runtime сгенерирует исключение, и выполнение кода сборки прекратится.

Некоторые рекомендации

Ниже мы обсудим способы обеспечения безопасности при использовании управляемого кода. В первую очередь, поддержка применения Microsoft .NET Framework в ядре СУБД должна быть включена только в тех случаях, когда использование управляемого кода в приложении действительно необходимо. Кроме того, с целью сохранения стабильности работы самой СУБД управляемому коду следует присваивать минимально необходимый уровень привилегий, а пользовательский код должен выполняться в контексте пользовательской сессии, которая его вызвала, и с привилегиями, необходимыми для данного контекста, — в противном случае из пользовательского кода возможен неавторизованный доступ к данным. Не стоит напоминать, что пользовательский код не должен обращаться к ресурсам за пределами сервера.

Шифрование трафика и данных

Встроенные средства шифрования и поддерживаемые алгоритмы

SQL Server 2005 содержит встроенные средства шифрования, цифровой подписи и верификации данных с помощью симметричных ключей (алгоритмы шифрования RC4, RC2, DES, AES) и асимметричных ключей (алгоритм RSA). Весь трафик между клиентом и сервером по умолчанию шифруется с применением протоколов IP Security (IP SEC) и Secure Sockets Layer (SSL), причем подобная функциональность доступна во всех редакциях продукта. SQL Server 2005 позволяет при необходимости определить политику безопасности, полностью запрещающую обмен незашифрованными данными между клиентом и сервером, что снижает риск утечки данных, полученных путем перехвата трафика.

Протокол SSL поддерживается с помощью интеграции со службами Internet Information Services (IIS) или с помощью сервера сертификатов, поддерживающего стандарт X. 509v3 и входящего в состав SQL Server 2005. Сгенерированные сертификаты не только используются для создания SSL-соединений — их применяет и SQL Service Broker.

Рис. 5. Иерархия методов шифрования в SQL Server

Шифрование данных на уровне колонок

SQL Server 2005 позволяет осуществить защиту данных на уровне колонок за счет шифрования хранимой в них информации. Он поддерживает также шифрование самих хранимых данных, полностью интегрированное с инфраструктурой управления ключами. Для этой цели служат встроенные функции EncryptByCert, DecryptByCert, EncryptByKey, DecryptByKey, EncryptByAssym, DecryptByAssym, позволяющие использовать шифрование с помощью сертификата, симметричного и асимметричного ключей в коде Transact-SQL. Необходимо, тем не менее, помнить о том, что шифрование данных может привести к потере производительности, поэтому при создании решений рекомендуется шифровать только конфиденциальные данные и осуществлять тестирование производительности готового решения.

Осуществляя шифрование на уровне колонок, следует также понимать, что зашифрованные данные нельзя сортировать, фильтровать и индексировать, и независимо от того, каким был тип исходных (незашифрованных) данных, их зашифрованная версия должна храниться как VARBINARY ().

Шифрование данных в интеграционных службах

В интеграционных службах, реализованных в SQL Server 2005, появился ряд новых возможностей, связанных с шифрованием пакетов данных. Так, теперь доступна возможность цифровой подписи пакетов SQL Server Integration Services, что позволяет идентифицировать измененные пакеты и запрещать их загрузку. Имеется также возможность шифрования всего пакета с применением пароля (это позволяет запускать пакет нескольким пользователям) или пользовательского ключа (что позволяет запустить пакет только одному конкретному пользователю).

Для защиты всех объектов внутри пакета его можно зашифровать целиком. Но существует и возможность выборочного шифрования пакетов с помощью применения свойства пакета ProtectionLevel.

Шифрование данных в службах отчетов

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

Рис. 6. Принцип работы служб отчетов

Для защиты данных об учетной записи обычно рекомендуется использовать механизмы SSL, особенно в случае, когда используются механизмы нестандартной аутентификации (custom authentication), либо когда для генерации отчетов используется обращение к внешним источникам данных, требующее дополнительной аутентификации. При доступе к службам отчетов через Internet следует использовать SSL не только для защиты учетных данных, но и данных самих отчетов.

Настоятельно рекомендуется сделать резервные копии ключей шифрования. Поскольку такие ключи создаются во время установки или последующей конфигурации сервера отчетов, в случае его аварии и последующего восстановления они потребуются для доступа к зашифрованным данным. Отметим, что клиентские приложения, обращающиеся к службам отчетов, также в ряде случаев должны обеспечить шифрование данных, для чего может быть использован механизм Data Protection Application Programming Interface (DPAPI). Помимо этого рекомендуется использовать минимальный уровень привилегий для выполнения таких приложений.

Шифрование данных, доступных с помощью протокола HTTP

Предоставление HTTP-доступа к ядру базы данных, позволяющее сделать данные доступными практически неограниченному числу пользователей, является одним из наиболее интересных новшеств в SQL Server 2005 (рис. 7).

Рис. 7. Обеспечение HTTP-доступа к ядру базы данных

Однако это нововведение несет в себе и определенную угрозу безопасности — ведь атаки с применением протокола HTTP являются сегодня одним из самых распространенных видов атак. Поэтому для защиты сервера и данных при реализации web - служб средствами SQL Server 2005 применяются общие принципы обеспечения безопасности в webприложениях и web-службах. Так, если планируется использовать web-службы для обмена конфиденциальной информацией между SQL Server и клиентом, следует использовать механизм SSL для обеспечения необходимого уровня ее защиты.

В SQL Server 2005 существует возможность обращаться к web-службам, созданным средствами SQL Server 2005, с применением следующих аутентификационных механизмов: Basic, Digest, NTLM, Kerberos и Integrated (NTLM и Kerberos). Механизм аутентификации Kerberos является наиболее защищенным, так как в нем используются более мощные по сравнению с другими механизмами алгоритмы шифрования. Кроме того, он способен аутентифицировать и сервер, и клиента, что позволяет избежать фарминга — получения конфиденциальных данных клиента с применением поддельного сервера.

Шифрование кода хранимых процедур и представлений

При необходимости можно воспользоваться механизмами шифрования кода хранимых процедур, для чего в конструкциях CREATE PROCEDURE и ALTER PROCEDURE следует использовать ключевое слово WITH ENCRYPTION. Имеется возможность шифрования кода представлений — для этого в конструкции CREATE VIEW или ALTER VIEW следует использовать ключевое слово WITH ENCRYPTION. Подобный способ ограничения доступа к коду представлений и процедур применяется при внедрении решений на основе SQL Server с целью защиты от несанкционированного внесения в него изменений. При этом исходный код хранимой процедуры или представления обязательно следует сохранить в проекте SQL Server на случай необходимости его модификации в будущем.

Аудит и защита метаданных

Аудит данных и метаданных

Аудит — достаточно распространенный способ выявления некорректных или неавторизованных действий пользователей, особенно пользователей, имеющих избыточные привилегии. SQL Server 2005 поддерживает несколько способов поддержки аудита. Он может использовать Windows Security EventLog (механизм отслеживания обращений к объектам, использования прав, попыток аутентификации), SQL Profiler (средство осуществления детального аудита попыток доступа к объектам БД).

Для осуществления аудита полезным может оказаться еще один новый механизм, появившийся в SQL Server 2005, — триггеры, связанные с изменением метаданных (DDL-триггеры). Создание подобных триггеров может позволить как отслеживать попытки изменения метаданных пользователями, так и полностью их запретить.

Скрытие метаданных

В SQL Server 2005 cистемные объекты находятся в скрытой базе mssqlsystemresource, при этом пользователям доступны представления Catalog Views для обращения к системным таблицам. Данные из этих представлений фильтруются в зависимости от того, кто делает запрос. Имеется и специальное разрешение VIEW DEFINITION, позволяющее обойти сокрытие метаданных всей БД, схемы или конкретного объекта.

В третьей части статьи будут представлены некоторые рекомендации для администраторов сетей и разработчиков приложений, а также рассмотрены средства обеспечения безопасности разных редакций SQL Server в сравнении с некоторыми другими СУБД.

Безопасность в Microsoft SQL Server 2005
Часть 3

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

Некоторые рекомендации для администраторов

Несмотря на то, что SQL Server 2005 удовлетворяет практически всем современным требованиям обеспечения безопасности, само по себе внедрение этого продукта не защитит компанию от угроз. Вопросы безопасности при использовании СУБД не являются чисто технологическими — проблемы с их решением часто возникают изза недостаточной компетентности, а то и недобросовестности людей, применяющих СУБД, создающих решения на их основе или внедряющих эти решения, равно как и из-за действий сотрудников-инсайдеров, сознательно нарушающих правила безопасности с целью получения личной выгоды. Кроме того, обеспечение «жесткого» режима безопасности зачастую усложняет выполнение сотрудниками их задач, затрудняя доступ к необходимым для этого данным и функциям.

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

Отключение ненужных служб

Многие из служб SQL Server отключены по умолчанию, и при отсутствии реальной необходимости их применения рекомендуется оставить их в неактивном состоянии. Так, поддержка применения Microsoft.NET Framework в ядре СУБД должна быть включена только в тех случаях, когда использование управляемого кода в приложении действительно необходимо. Не рекомендуется без необходимости включать такие службы и опции, как Database Mail и SQL Mail, AdHoc Remote Queries, Web Assistant, Remote DAC (Dedicated Administrator Connection), делать доступной хранимую процедуру xp_cmdshell для выполнения команд операционной системы из ядра СУБД и средства применения COM-расширений функциональности сервера (OLE Automation extended stored procedures), создавать точки доступа по протоколу HTTP (HTTP Endpoints, рис. 9).

Рис. 9. Управление доступностью служб SQL Server 2005

Применение брандмауэра при HTTP-доступе к серверу

Поскольку атаки с применением протокола HTTP являются сегодня одним из самых распространенных видов атак, предоставлять доступ к SQL Server по протоколу HTTP через Интернет следует только в случае реальной необходимости. Не стоит напоминать, что такой доступ должен быть реализован только через брандмауэр.

Обеспечение безопасности файлов и папок

Некоторые службы SQL Server (например, службы уведомлений) используют ряд файлов и папок для хранения конфигурационной информации и данных приложения. Ядро служб уведомлений (или иных служб SQL Server) должно иметь доступ к этим файлам и папкам, но пользователи не должны иметь возможности вносить изменения в содержащиеся в них файлы. Для защиты файлов и папок, используемых службами уведомлений, можно использовать разрешения NTFS для ограничения доступа к папкам и файлам либо механизмы Encrypted File System (EFS) для шифрования файлов и папок и предотвращения неавторизованного доступа (рис. 10).

Рис. 10. Управление доступностью служб SQL Server 2005

Защита данных, реплицируемых через Интернет

При необходимости репликации данных через Интернет в SQL Server 2005 можно использовать два способа защиты данных.

Во-первых, можно создать канал виртуальной частной сети (VPN-канал) между реплицируемыми серверами. Этот способ удобен в случае транзакционной или snapshot-репликации.

Во-вторых, можно использовать web-синхронизацию. Данный способ удобен при использовании репликации с объединением (Merge Replication), так как в этом случае поддерживается SSL-шифрование с применением протокола HTTPS.

Обновления средств безопасности

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

Некоторые рекомендации для разработчиков приложений

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

Отказ от динамически формируемых в приложении запросов и генерации команд, выполняемых на сервере, непосредственно из введенных пользователем данных, в пользу представлений, хранимых процедур или параметризованных запросов.
Проверка пользовательского ввода.

Ниже мы обсудим эти принципы более подробно.

Использование представлений

Представления можно использовать в качестве механизма обеспечения безопасного доступа к объектам базы данных. Использование представлений обеспечивает простой механизм фильтрации информации, доступной пользователям, предотвращает непосредственное обращение к таблицам, позволяет ограничить доступ к записям, полям, метаданным в зависимости от задач пользователя или приложения. Кроме того, использование представлений позволяет ограничить доступные пользователям операции. Так, можно указать, что представление поддерживает только конструкцию SELECT — в этом случае пользователи не могут обновлять данные.

Использование представлений позволяет изолировать приложения от внесения изменений в схемы данных, что упрощает сопровождение клиентских приложений, позволяя избежать развертывания их новых версий. Кроме того, представления можно использовать для объединения данных из нескольких таблиц с целью вычисления агрегатных данных без предоставления сведений об их составляющих. Тем не менее не рекомендуется создавать представления на основе других представлений — подобный подход к проектированию баз данных может привести к снижению производительности и созданию дополнительного числа временных таблиц.

Использование хранимых процедур

Для выполнения большинства операций с данными приложения могут использовать либо хранимые процедуры, либо динамически формируемые в приложении запросы. С точки зрения безопасности динамически формируемые в приложении запросы обладают рядом серьезных недостатков. Так, они позволяют выполнять атаки типа SQL Injection (ввод данных, инициирующий выполнение неавторизованного запроса) или осуществить неавторизованный доступ к данным. Применение хранимых процедур и параметризованных запросов с этой точки зрения обладает рядом преимуществ.

Для иллюстрации понятия SQL Injection приведем простой пример, взятый нами из книги Майкла Ховарда и Дэвида Леблана «Защищенный код» (издательство «Русская редакция», 2003). Представим себе следующий код клиентского приложения:
String sql = «select * from customer where name= ‘ «+ name +» ’»
значение переменной name в котором вводится пользователем. Если пользователь ввел в эту переменную значение «Иванов», он получит записи таблицы Customer, содержащие в поле Name значение «Иванов».
Но если он ввел в это поле следующее значение:
Иванов’ or 1=1 —
то такая команда вернет все строки таблицы — записи таблицы Customer, содержащие в поле Name значение «Иванов», плюс записи, удовлетворяющие условию 1=1 (то есть все записи таблицы!). А если злоумышленник ввел в это поле значение
Иванов’ drop table customer
— или, не дай бог, фрагмент кода с вызовом хранимой процедуры xp_cmdshell, которая по недосмотру администратора базы данных оказалась доступной, последствия могут быть самыми плачевными.

С точки зрения безопасности приложения не должны использовать конструкции SELECT, INSERT, UPDATE и DELETE для запросов к базе данных. Вместо этого правильнее обращаться к хранимым процедурам, выполняющим подобные операции. Кроме того, их применение позволяет отказаться от предоставления пользователям прав доступа к таблицам и представлениям. Отметим, что применение хранимых процедур позволяет сделать клиентские приложения независимыми от схемы базы данных, что позволяет изменять ее без необходимости внесения изменений в само приложение. Это упрощает сопровождение таких приложений, позволяя избежать развертывания его новых версий.

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

Впрочем, и хранимые процедуры сами по себе не являются панацеей от всех бед. Рассмотрим еще два примера, приведенных в книге Майкла Ховарда и Дэвида Леблана. Представим себе следующий код клиентского приложения, использующий хранимую процедуру sp_GetName для получения записей о конкретном клиенте:
Sqlstring = @» exec sp_GetName ‘» + name + +» ’»;
SqlCommand cmd = new SqlCommand (sqlstring, sql);
Если пользователь ввел в поле Name
Иванов’ or 1=1 —
он не получит все строки таблицы. Но, введя
Иванов’ drop table customer —
он удалит таблицу, как и в предыдущем случае. И наконец, хранимые процедуры бывают и такими:
CREATE PROCEDURE
sp_MyProc @input varchar(128)
AS exec (@input)
Эта процедура просто выполняет введенный пользователем код и создает серьезную угрозу безопасности. Тем не менее случаи создания столь опасных процедур иногда происходят. Чтобы избежать подобных неприятностей, следует использовать параметризованные запросы и параметризованные вызовы хранимых процедур.

Проверка пользовательского ввода

Как избежать атак на сервер из клиентских приложений? Для этой цели можно воспользоваться уже перечисленными ранее возможностями, доступными в SQL Server 2005, такими как выполнение приложений от имени учетной записи с минимально необходимыми привилегиями, минимизация привилегий для исполняемого кода, отключение всех ненужных служб и опций.

Немаловажным шагом при создании клиентских приложений является и проверка вводимых данных. Такие банальные фрагменты клиентского кода, как проверка соответствия типов вводимых данных типам в СУБД, применение регулярных выражений в клиентских приложениях для проверки пользовательского ввода до того, как он будет отправлен в СУБД, экранирование специальных символов (довольно часто используемых злоумышленниками при атаках на серверы баз данных), могут спасти базу данных от многих неприятностей.

Особо отметим обязательную при применении служб уведомлений необходимость проверки вводимой пользователями информации в поля протокола Subscriber, Subscriber Device и Subscription Information — сами службы уведомлений не содержат механизмов проверки содержимого полей заголовков протокола.

Средства обеспечения безопасности в SQL Server 2005 и других СУБД

Справедливости ради отметим, что SQL Server не единственная хорошая серверная СУБД на рынке программного обеспечения. Надежные и простые в применении СУБД масштаба предприятия выпускают такие компании, как IBM, Oracle, Sybase. Средства обеспечения безопасности в SQL Server 2005 также не уникальны — все перечисленные выше производители СУБД заботятся о безопасности своих продуктов не меньше, чем корпорация Microsoft. Данное утверждение иллюстрируется приведенной выше таблицей, в которой представлено наличие средств обеспечения безопасности в SQL Server 2005 и в различных редакциях Oracle 10g.

Средства обеспечения безопасности Oracle и SQL Server

Отметим, однако, что перечисленные механизмы безопасности и удобные средства их администрирования доступны во всех редакциях SQL Server 2005, включая бесплатную редакцию Express Edition и относительно недорогие версии Workgroup Edition и Standard Edition, вполне доступные небольшим предприятиям. В то же время аналогичные механизмы и утилиты Oracle 10g присутствуют только в наиболее дорогостоящей редакции этой СУБД.

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

Безопасность в Microsoft SQL Server 2005

Безопасность в Microsoft SQL Server 2005 Часть 2

Безопасность в Microsoft SQL Server 2005 Часть 3

Безопасность в Microsoft SQL Server 2005
Часть 2

Безопасность в Microsoft SQL Server 2005
Часть 3