Безопасность в Microsoft SQL Server 2005
Изоляция учетных записей от объектов базы данных
Выполнение кода с минимальными привилегиями
Последующие обновления средств безопасности
Как, возможно, уже известно многим нашим читателям, в начале ноября состоялся официальный выход Microsoft SQL Server 2005. Событие это, на наш взгляд, немаловажное, ибо системы управления базами данных традиционно относятся к категории продуктов, новые версии которых выпускаются не очень часто, поскольку повышенные требования к надежности программного обеспечения подобного класса являются причиной очень тщательного подхода к его проектированию, разработке и тестированию. Выпуск новой версии СУБД через пять лет после предыдущей, как это произошло с SQL Server, — явление вполне обычное. И, поскольку вопросы безопасности за эти пять лет стали едва ли не самыми актуальными во всех областях человеческой деятельности (вспомним ежедневные сообщения о взломах сетей и утечках конфиденциальных и корпоративных данных), представляется логичным выяснить, что нового с этой точки зрения данная СУБД предлагает IT-менеджерам, администраторам и разработчикам приложений. Тем более что по сравнению с SQL Server 2000 (очень хорошим, по нашему мнению, продуктом даже по современным меркам) в модель безопасности SQL Server 2005 внесены существенные улучшения.
Авторизация и аутентификация
Аутентификация — это процесс проверки права пользователя на доступ к тому или иному ресурсу, который чаще всего (хотя и не всегда) осуществляется с помощью ввода имени и пароля.
Как и предыдущие версии, SQL Server 2005 поддерживает два режима аутентификации: аутентификация с помощью Windows и аутентификация с помощью SQL Server.
Первый из режимов является рекомендуемым: именно он позволяет реализовать решение, основанное на однократной регистрации пользователя и на едином пароле доступа к различным приложениям (Single Sign-On solution, SSO), что упрощает работу пользователей, избавляя их от запоминания множества паролей и снижая риск хранения. Кроме того, данный режим позволяет использовать доступные администраторам Windows механизмы формирования групп, применения политик безопасности для доменов, таких как управление сложностью пароля и временем его существования, блокировка учетных записей, а также применение защищенных протоколов аутентификации с помощью шифрования паролей, например Kerberos или NT LAN Manager (NTLM).
Аутентификация с помощью SQL Server предназначена для клиентских приложений, функционирующих на платформах, отличных от Windows. Хотя этот способ и предпочитают многие разработчики приложений, он считается менее безопасным, однако в новой версии SQL Server данный способ аутентификации поддерживает шифрование с помощью сертификатов, сгенерированных сервером. Воспользоваться им можно, если клиентские приложения применяют новую версию MDAC (Microsoft Data Access Components) 2.8. Шифрование всех сообщений, которыми обмениваются клиент и сервер, также повышает надежность этого способа аутентификации.
Для учетной записи SQL Server можно указать такие параметры команды CREATE/ALTER LOGIN, как необходимость сменить пароль при первом соединении с сервером, необходимость проверки срока действия пароля, необходимость применения локальной парольной политики Windows (рис. 1). Последние два параметра можно полноценно использовать, если SQL Server 2005 выполняется под управлением Windows Server 2003.
Рис. 1. Установка правил поведения пароля пользователя
Наконец, теперь обязательно требуется непустой пароль пользователя sa — как ни банальна ошибка, связанная с сохранением пустого пароля, ее слишком часто совершают администраторы баз данных (и, понятно, используют разного рода злоумышленники).
После аутентификации пользователя происходит процесс авторизации, то есть определения, к каким ресурсам данный пользователь имеет право доступа. Контроль доступа к ресурсам с помощью авторизации предполагает хранение подобных сведений в надежном источнике, причем, как правило, в зашифрованном виде.
 |
|
Шифрование трафика и данных
SQL Server 2005 содержит встроенные средства шифрования, цифровой подписи и верификации данных с помощью симметричных ключей (поддерживаются алгоритмы шифрования RC4, RC2, DES, AES) и асимметричных ключей (алгоритм RSA).
Как уже было сказано, весь трафик между клиентом и сервером по умолчанию шифруется с применением протоколов IP Security (IP SEC) и Secure Sockets Layer (SSL), и подобная функциональность доступна во всех редакциях продукта. Протокол SSL поддерживается с помощью интеграции со службами Internet Information Services (IIS) или с помощью сервера сертификатов, поддерживающего стандарт X.509v3 и входящего в состав SQL Server 2005. Сгенерированные сертификаты не только используются для создания SSL-соединений — их применяет и SQL Service Broker.
Отметим, что при необходимости можно определить политику безопасности, полностью запрещающую обмен незашифрованными данными между клиентом и сервером, что снижает риск утечки данных, полученных путем перехвата трафика.
SQL Server 2005 также поддерживает шифрование самих хранимых данных, полностью интегрированное с инфраструктурой управления ключами. Для этого он содержит шесть встроенных функций: EncryptByCert, DecryptByCert, EncryptByKey, DecryptByKey, EncryptByAssym и DecryptByAssym, позволяющих использовать шифрование с помощью сертификата, симметричного и асимметричного ключей в коде Transact-SQL.
|
|
Изоляция учетных записей от объектов базы данных
В большинстве современных серверных СУБД у каждого объекта базы данных имеется пользователь-владелец, который может предоставлять другим пользователям права доступа к объектам базы данных. Набор объектов, принадлежащих одному и тому же пользователю, называется схемой. При этом для серверных СУБД сегодня стандартным является механизм ролей — наборов прав доступа к объектам базы данных, присваиваемых в совокупности тому или иному пользователю. Данный способ владения объектами создавал определенные неудобства администраторам и разработчикам приложений: с одной стороны, после увольнения сотрудника, создавшего объекты, используемые многими пользователями, при удалении соответствующей учетной записи приходилось вносить изменения в серверный код (а нередко и в код клиентского приложения), а с другой — далеко не всем пользователям нужны собственные схемы. Зная о потенциальных проблемах сопровождения схем и учетных записей, многие заказчики решений, использующих базы данных, стали в последнее время настаивать на «наколенных» (не побоимся этого слова!) реализациях способов управления учетными записями пользователей, вплоть до хранения их имен и паролей в обычных таблицах, что резко повышало угрозу несанкционированного доступа к данным и приложениям.
В SQL Server 2005 концепция ролей расширена — эта СУБД позволяет полностью отделить пользователя от схем и объектов базы данных. Теперь объекты базы данных принадлежат не пользователю, а схеме, не имеющей отношения к учетной записи пользователя (рис. 2), тогда как пользователь может быть ассоциирован со схемой. Таким образом, схема становится не более чем механизмом группировки объектов в соответствии с решаемой задачей, упрощающим предоставление пользователям и ролям прав на доступ к объектам. Кроме того, подобный механизм упрощает разрешение имен и позволяет хранить объекты общего пользования в схеме, не имеющей никакого отношения к административным привилегиям.
Рис. 2. Установка прав для схем данных
|
|
Выполнение кода с минимальными привилегиями
Одним из базовых принципов создания безопасных приложений является принцип предоставления минимальных привилегий, необходимых для решения поставленной задачи. Этот принцип реализован в более строгих, по сравнению с предыдущими версиями, настройках по умолчанию. Так, в новой версии SQL Server по умолчанию отключено значительное количество функций, например применение Microsoft .NET Framework в ядре СУБД, функции SQL Service Broker Network Connectivity, доступ к аналитическим службам с помощью протокола HTTP. Такие службы, как SQL Server Agent, Data Transformation Services, средства полнотекстового поиска, после установки сервера находятся в режиме ручного запуска.
Еще одна новация SQL Server 2005, реализующая принцип минимальных привилегий, позволяет выполнять хранимые процедуры и функции, определяемые пользователем, с правами другого пользователя — для этой цели имеется оператор EXECUTE AS. К тому же SQL Server 2005 позволяет указать контекст безопасности, в котором будут выполняться те или иные операторы программного модуля, то есть учетной записи, используемой при проверке разрешений на объекты, на которые ссылается процедура или функция (например, учетной записи пользователя, вызвавшего процедуру, или учетной записи пользователя, создавшего процедуру, или другой учетной записи).
Данная функциональность может применяться в качестве средства обеспечения безопасного управления правами пользователей. Например, решение такой часто встречающейся задачи, как предоставление доступа к процедуре без предоставления доступа к той таблице, которую использует данная процедура, решается с помощью EXECUTE AS без необходимости предоставления пользователям процедуры дополнительных привилегий.
Выполнение .NET-кода в ядре СУБД требует при загрузке сборки указания одного из трех уровней безопасности: SAFE (доступ ко внешним ресурсам не допускается), EXTERNAL_ACCESS (доступ к файлам, сетевым ресурсам, реестру, переменным окружения) или UNSAFE (доступ ко всем ресурсам, в том числе к неуправляемому коду). Если сборка в процессе работы выйдет за указанные при ее загрузке параметры безопасности, то Common Language Runtime сгенерирует исключение и выполнение кода сборки прекратится.
|
|
Аудит
Аудит — довольно распространенный способ выявления некорректных или неавторизованных действий пользователей, особенно тех, кто имеет избыточные привилегии.
SQL Server 2005 поддерживает несколько способов поддержки аудита (рис. 3). В частности, можно использовать Windows Security EventLog (механизм отслеживания обращений к объектам, применения прав, попыток аутентификации) и SQL Profiler (средство осуществления детального аудита попыток доступа к объектам БД).
Рис. 3. Выбор событий базы данных для аудита
Для осуществления аудита полезным может оказаться еще один новый механизм, появившийся в SQL Server 2005, — это триггеры, связанные с изменением метаданных (DDL-триггеры). Создание таких триггеров позволяет отслеживать попытки изменения метаданных пользователями или полностью запрещать их.
|
|
Сокрытие метаданных
В SQL Server 2005 cистемные объекты находятся в скрытой базе mssqlsystemresource, а пользователям доступны представления Catalog Views для обращения к системным таблицам, причем данные из этих представлений фильтруются в зависимости от того, кто делает запрос. Имеется и специальное разрешение VIEW DEFINITION, позволяющее обойти сокрытие метаданных всей БД, схемы или конкретного объекта.
|
|
Последующие обновления средств безопасности
При создании современных СУБД, равно как и многих других продуктов, производители обычно планируют, что с появлением новых угроз средства безопасности продуктов придется обновлять. Обновления безопасности SQL Server найти и установить несложно, а если выбрать соответствующую опцию, то эти обновления будут загружаться с сайта производителя и устанавливаться автоматически.
|
|
Сравнение с другими СУБД
Конечно, SQL Server — не единственная хорошая серверная СУБД на рынке программного обеспечения. Так, СУБД масштаба предприятия выпускают IBM, Oracle, Sybase. Средства обеспечения безопасности в SQL Server 2005 тоже не уникальны, что иллюстрируется таблицей, в которой представлено наличие средств обеспечения безопасности в SQL Server 2005 и в различных редакциях Oracle 10g.
Средства обеспечения безопасности Oracle и SQL Server
Отметим, однако, что перечисленные механизмы безопасности и средства их администрирования доступны во всех редакциях SQL Server 2005, включая бесплатную редакцию Express Edition и относительно недорогие версии Workgroup Edition и Standard Edition, которые вполне под силу приобрести даже небольшим предприятиям, тогда как аналогичные механизмы и утилиты Oracle 10g присутствуют только в наиболее дорогостоящей редакции этой СУБД.
|
|
Немного общих рассуждений
Вопросы безопасности при использовании СУБД (как, впрочем, и вопросы безопасности в целом) не являются чисто технологическими — проблемы с их решением часто возникают из-за недостаточной компетентности и ответственности людей, применяющих технологии (вспомним хотя бы пароли, записанные на прикрепленных к мониторам листочках), равно как и из-за действий сотрудников, сознательно нарушающих правила безопасности с целью получения личной выгоды. Кроме того, обеспечение безопасности, как правило, усложняет самим же сотрудникам выполнение задач, препятствует доступу к нужным им для этого данным и функциям. Нередко разумный компромисс между безопасностью и доступностью функций, приложений и данных оказывается гораздо более сложным, нежели технологическая реализация того или иного способа защиты данных, так что умение администратора баз данных применить возможности сервера играет в этом случае немаловажную роль.
Некомпетентность или неаккуратность разработчиков приложений порой представляет собой значительно более серьезную угрозу безопасности, чем легкомыслие конечных пользователей. Именно поэтому мы сочли уместным напомнить несколько базовых принципов, обеспечивающих безопасность приложений, применяющих СУБД:
- отказ от динамически формируемых запросов в пользу хранимых процедур или параметризованных запросов;
- применение регулярных выражений в клиентских приложениях для проверки пользовательского ввода до того, как он будет отправлен в СУБД;
- применение экранирования специальных символов;
- проверка пользовательского ввода средствами сервера;
- проверка соответствия типов вводимых данных типам в СУБД;
- отказ от генерации команд, выполняемых на сервере, непосредственно из введенных пользователем данных.
Иными словами, несмотря на то, что SQL Server 2005 удовлетворяет всем современным требованиям обеспечения безопасности, не стоит строить иллюзий: само по себе внедрение этого продукта не защитит компанию от всех угроз. Но при грамотном применении этот продукт действительно упростит работу и разработчикам приложений, и администраторам баз данных.
