Первая часть статьи посвящена новшествам в управлении доступом к данным и сервисам. Продолжение статьи посвящено минимизации привилегий для исполняемого кода, шифрованию трафика и данных в SQL Server 2005, а также некоторым другим аспектам безопасности этой СУБД. В третьей части статьи представлены некоторые рекомендации для администраторов сетей и разработчиков приложений, а также рассмотрены средства обеспечения безопасности разных редакций SQL Server в сравнении с некоторыми другими СУБД.
Оглавление
Управление доступом. Общие сведения
Авторизация и аутентификация
Аутентификация — это процесс проверки права пользователя на доступ к тому или иному ресурсу. Чаще всего аутентификация осуществляется с помощью ввода имени и пароля.
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 Server 2005.
Применение схем и ролей. Общие принципы
Одним из обязательных этапов проектирования баз данных должно быть детальное определение способов доступа к объектам базы данных. В частности, на этом этапе необходимо определить, каким образом использовать схемы для группировки объектов базы данных с точки зрения доступа к ним, какие роли создать, определить возможные группы пользователей и роли, которые следует им присвоить. Кроме того, на этом же этапе важно принять решение о том, как будут использоваться представления и хранимые процедуры для обеспечения безопасного доступа к данным (например, для ограничения непосредственного доступа к таблицам).
В последнее время настоятельно рекомендуется применять роли во всех решениях (как было сказано выше, это заметно снижает затраты на процесс управления правами доступа и внесение в них изменений), а в случае наличия пользователей, имеющих частично совпадающие наборы прав доступа, рекомендуется применять вложенные роли. Для определения прав доступа и правил вложенности ролей следует разделить пользователей на группы с разными правами доступа и понять, можно ли сформулировать правила вложенности групп, а затем отразить эти сведения в проектируемых ролях.
Нужно также проанализировать требования к правам доступа, предъявляемые клиентскими приложениями, и учесть эти требования при проектировании ролей и создании схем. Не стоит при этом забывать и о том, что списки пользователей и ролей следует не только единожды создать, но и постоянно актуализировать. Помимо вопросов управления доступом в клиентских приложениях, рекомендуется уделить внимание и управлению доступом в различных службах SQL Server.
Управление доступом в службах отчетов
При применении служб отчетов (Reporting Services) необходимо отдельно позаботиться о правилах доступа к объектам базы данных для пользователей, применяющих приложения, обращающиеся к этим службам. Так, указанной категории пользователей должны быть доступны как сами описания отчетов, так и те объекты базы данных, на основании которых эти отчеты генерируются, и в этом случае наиболее уместно создание отдельной роли, обладающей указанными правами. Следует заметить, что по умолчанию службы отчетов используют службы Internet Information Services (IIS) и средства безопасности Windows для аутентификации пользователей на сервере отчетов. Данный режим считается наиболее безопасным, поскольку может позволить запретить анонимный доступ к web-приложениям, выполняющимся под управлением IIS.
Отметим, что сервисы отчетов могут выполняться в режиме Integrated Security. Но в этом случае они выполняют код ряда компонентов с теми же привилегиями, что и у пользователя, сгенерировавшего отчет, а это позволит пользователю, исполняющему отчет, получить более высокие привилегии, нежели ему положены. Поэтому данный режим не рекомендуется применять вместе со службами отчетов.
Управление доступом в службах уведомлений
Службы уведомлений (Notification Services) выполняются от имени собственной учетной записи, которая, с одной стороны, должна обладать определенными правами для обеспечения доставки уведомлений, с другой стороны, указанный набор прав должен быть минимально необходимым (как минимум, такая учетная запись не должна входить в группу Administrators).
Отметим, что для служб уведомлений существуют специальные роли — NSEventProvider, NSGenerator, NSDistributor, которые следует присваивать учетным записям, отвечающим за провайдеры, генераторы и механизмы рассылки, а также роль NSRunService, включающая в себя три перечисленные роли и применяющаяся в том случае, если все составные части служб уведомлений выполняются внутри одного ядра базы данных.
Управление доступом в интеграционных службах
Для управления доступом в интеграционных службах в SQL Server 2005 введены новые роли: db_dt sadmin, db_dt sltuser и db_dtsoperator. Они позволяют осуществлять контроль доступа к пакетам интеграционных служб, хранящихся в базе данных msdb.
Управление доступом в службах репликации
Для управления доступом в службах репликации SQL Server 2005 была создана новая модель безопасности этих служб, позволяющая более гибко управлять учетными записями агента репликации (Replication Agent). Теперь каждый агент репликации может выполняться под собственной учетной записью, что позволяет наделить каждого агента именно теми правами, которые требуются для его функционирования, без присвоения избыточных привилегий. При этом, если серверы, участвующие в процессе репликации, находятся в одном домене, для указанных учетных записей рекомендуется использовать аутентификацию Windows.
Для управления доступом к самим публикациям рекомендуется для каждого агента использовать списки публикаций — Publication Access Lists, включающие учетные записи пользователей. Отдельно отметим необходимость защиты папки файловой системы Snapshot, содержащей реплицированные данные, и предоставлять агентам, не осуществляющим запись в эту папку, таким как Replication Merge Agent и Replication Distribution Agent, доступ только в режиме чтения.
Управление доступом для SQL Server Agent
Агент SQL Server Agent должен выполняться от имени учетной записи Windows, обладающей ролью sysadmin, но не принадлежащей группе Administrators и имеющей разрешение на увеличение квот памяти для процесса. Сам SQL Server Agent должен выполняться как служба операционной системы, протоколироваться как сервис. Кроме того, можно создать специальную прокси-запись и ассоциировать ее с соответствующими правами Windows для доступа к внешним ресурсам.
Для управления службой SQL Server Agent можно использовать утилиту Surface Area Configuration (рис. 3).
Рис. 3. Управление службой SQL Server Agent
Управление доступом для Database Mail
Database Mail — это новый компонент SQL Server 2005, предназначенный для поддержки протокола SMTP (Simple Mail Transport Protocol). Для управления доступом к нему рекомендуется создавать настраиваемые профили, позволяющие указать, каким образом пользователи базы данных msdb имеют доступ к данному профилю (самим пользователям следует присвоить роль DatabaseMailUserRole базы данных msdb). Для управления службой Database Mail можно также использовать утилиту Surface Area Configuration (рис. 4).
Рис. 4. Управление службой Database Mail
Управление доступом к базе данных с помощью протокола HTTP
Поскольку HTTP-доступ является одним из наиболее распространенных способов атак на приложения извне, следует разрешить доступ к HTTP Endpoints только тем пользователям или группам, которым он действительно необходим. Кроме того, на сервере баз данных следует отключить учетную запись Windows Guest, поскольку она позволяет пользователям подключаться к компьютеру без ввода пароля. В очередной раз напомним: доступ к SQL Server через Интернет должен осуществляться только посредством брандмауэра.
Выполнение кода с минимальными привилегиями
Установки по умолчанию
Один из базовых принципов создания безопасных приложений — принцип предоставления минимальных привилегий, необходимых для решения поставленной задачи, — в 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 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 предоставляет немало возможностей обеспечить подобную защиту и упростить работу администраторов и разработчиков приложений, поскольку удовлетворяет всем современным требованиям в указанной области.
Анна Иванова, IT News