В предыдущей части статьи мы обсудили новшества 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).

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

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

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

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

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

При необходимости репликации данных через Интернет в 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.

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

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