25
1.3. Выводы по первой главе
В первой главе работы были рассмотрены вопросы, связанные с понятие
информационной безопасности и его корректировкой в процессе развития.
На основании описанной модели реализации угрозы информационной
безопасности, которая определяется истопниками угрозы (внешними и
внутренними), способом реализации, объектом воздействия, которые и содержит
уязвимость и деструктивным действием, выделены существующие угрозы
информационной безопасности и проведена их классификация.
Исследованы ключевые угрозы безопасности баз данных,
сформулированы вопросы и аспекты нарушения конфиденциальности,
доступности и целостности баз данных. Акцентировано внимание на
существующих технологиях построения защиты в рамках СУБД.
26
Глава 2. Встроенные средства безопасности MS SQL SERVER
2.1 Структура обеспечения безопасности для MS SQL Server
В системе безопасности MS SQL Server реализуется ролевой и
дискреционный подходы к управлению доступом и обладает двумя уровнями:
уровнем сервера и уровнем базы данных (рисунок 3).
User ID
Пользователь Windows
Группа Windows
+ пользователь SQL-Server
(смешанный режим)
Экземпляр SQL Server (Служба
Windows)
БД
Master
Фиксированные
роли сервера
Уровень безопасности
сервера
- Фиксированные роли БД
- Пользовательские роли БД
- Явные разрешения на
доступ (GRANT, REVOKE)
БД БД БД
Уровень безопасности БД
Рисунок 3. Схема безопасности СУБД MS SQL Server (обобщенная)
Уровень пользователя дает возможность разрешать или отклонять доступ
пользователей на уровне сервера. На уровне базы данных пользователи, которые
обладают доступом на уровне сервера, получают доступ к объектам базы
данных. Благодаря такому подходу появляется возможность более гибкого
управления доступа пользователей к базам данным.
Система безопасности на уровне сервера выполняет оперирование
следующими понятиями:
учетной записью (login);
27
аутентификацией (authentication);
встроенными ролями (fixed server roles).
На уровне базы данных соответствующие понятия следующие:
фиксированная роль базы данных (fixed database role);
пользователь базы данных (database user);
роль приложения (application role);
пользовательская роль базы данных (users database role).
Таким образом, выделяются две группы ролей:
группа ролей баз данных (database role);
группа ролей сервера (server role).
Далее следует подробнее остановиться на системе безопасности на
уровне сервера.
В SQL Server используется двухэтапная система аутентификации.
Вначале осуществляется аутентификация пользователя со стороны сервера.
Только в случае, если аутентификация прошла успешно, пользователю может
быть предоставлен доступ к одной или нескольким базам данных. Хранение всей
информации о регистрационных записях производится SQL Server в базе данных
master.
SQL Server поддерживает аутентификацию пользователей в двух
режимах:
в режиме аутентификации средствами операционной системы
Windows. Данный режим предполагает полное доверие SQL Server к
операционной системе в процессе аутентификации пользователей;
в смешанном режиме аутентификации (Windows Authentication and
SQL Server Authentication). В данном режиме обеспечивается независимое
существование друг от друга систем аутентификации SQL Server и ОС Windows.
Устанавливая SQL Server, одно из первых решений, которое необходимо
принять, связано с выбором применяемого метода аутентификации. Режим
аутентификации, который был установлен в процессе инсталляции, может быть
изменен в диалоговом окне SQL Server Properties на странице Security утилиты
28
management Studio. Для проверки установленного режима аутентификации в
программном коде можно использовать системную хранимую процедуру
xp_loginconf:
EXEC xp_loginconf ‘login mode’
Результатом исполнения данной процедуры будет следующее:
name config_value
login mode Mixed
В связи с этим, для идентификации пользователя сервером должен быть
использован один из следующих методов:
метод, основанный на членстве в одной из групп пользователей
операционной системы Windows;
с помощью учетной записи пользователя Windows (которая в общем
случае принадлежит определенной рабочей группе или домену);
с помощью отдельной регистрационной записи SQL Server (в случае
использования на сервере смешанной модели безопасности).
Следует различать учетные записи Windows в данном сервере баз данных
и регистрационные записи SQL Server. Два данных типа регистрации являются
абсолютно различными. У пользователей SQL Server отсутствует необходимость
в доступе к папкам, в которых происходит хранение файлов баз данных, а также
к любым другим файлам, поскольку процесс реального доступа к файлам
осуществляется SQL Server, а не самим пользователем. Однако, в правах доступа
к файлам нуждается сам процесс SQL Server, поэтому, ему необходима учетная
запись Windows. Здесь также следует выделить два варианта:
учетная запись локального администратора. Данная учетная запись
может быть использована SQL Server для того, чтобы получить доступ к тому
компьютеру, на котором выполнена его установка. Этот вариант является
идентичным установке на обособленный сервер, поскольку в данном случае
отсутствует возможность поддержки сетевой системы безопасности Windows,
которая требуется для распределенной обработки;
29
учетная запись пользователя домена (является рекомендуемой).
Учетная запись пользователя домена может быть использована SQL Server, так
как она создана специально для него. Также может быть осуществлено
назначение учетной записи пользователя SQL Server административных
привилегий для локального сервера, посредством чего он может получить
возможность доступа к сети для того, чтобы поддержать взаимодействие с
другими серверами.
Следует отметить, что совокупность ролей сервера является строго
ограниченной. Никто, в том числе администратор сервера, не обладает правами
создания новой или удаления существующей роли сервера. Следовательно, их
название – фиксированные роли (fixed server roles). Ниже представлен список
части фиксированных ролей сервера, а также краткое описание каждой из них:
Setupadmin (Setup Administrators). Данная роль обладает правами
управления связанными серверами, она может осуществлять конфигурирование
хранимых процедур, запуск которых происходит автоматически при старте SQL
Server, а также имеет право добавления учетных записей в роли setupadmin;
Securityadmin (Security Administrators). Членам данной роли
выдаются права на создание новых учетных записей, которым они могут
делегировать права на создание баз данных, а также их объектов, и управление
связанными серверами, включение учетных записей в роль securityadmin и
чтение журнала ошибок SQL Server;
Serveradmin (Server Administrators). Обычно в состав членов данной
роли целесообразным является включение пользователей, в круг задач которых
входит администрирование сервера. Они обладают правами на останов сервера
(SHUTDOWN), изменение параметров работы служб (sp_configure), управление
полнотекстовым поиском (sp_fulltext_service), применение изменений
(RECONFIGURE);
Dbcreator (Database Creators). У членов этой роли существуют права
на создание новых баз данных, удаление и переименование имеющихся,
восстановление резервных копий баз данных и журнала транзакций;
30
Sysadmin (System Administrators). Члены этой роли обладают
абсолютными (полными) правами в SQL Server. Никто не обладает большими
правами доступа, нежели члены этой группы.
Чтобы осуществить добавление учетной пользовательской записи в ту
или иную фиксированную роль сервера, используется хранимая процедура
sp_addsrvrolemember, синтаксис которой следующий:
sp_addsrvrolemember [@loginame=] ‘login’, [@rolename=] ‘role’
В качестве примера можно рассмотреть процесс добавления в
фиксированную роль сервера sysadmin учетной записи Windows, имеющей имя
Owner, компьютера HRANIL.
EXEC sp_addsrvrolemember ‘HRANIL\Owner’, ‘sysadmin’
Несмотря на то, что в общем случае необходимо наличие на сервере
учетной записи, которая должна быть включена в одну из фиксированных ролей,
существует одно исключение. Суть заключается в том, что доступ к SQL Server
пользователь Windows может получить в качестве члена группы Windows,
которая обладает доступом к серверу. Существует возможность включения
подобных учетных записей в роли сервера без того, чтобы предварительно
предоставлять доступ непосредственно учетной записи. Чтобы получить
информацию о том, включение какой учетной записи в какую фиксированную
роль выполнено, необходимым является использование следующей системной
хранимой процедуры:
sp_helpsrvolemember [ [@srvrplename = ] ‘role’ ]
В случае вызова процедуры без параметров осуществляется вывод
полного списка учетных записей, которые включены в состав любой из ролей
сервера. При необходимости получения списка учетных записей, которые
включены в определенную роль сервера, необходимо указание имени роли.
Приведенный ниже пример производит вывод информации о членах роли
sysadmin:
EXEC sp_helpsrvolemember ‘sysadmin’
31
Чтобы удалить учетную запись из фиксированной роли сервера,
существует системная хранимая процедура sp_dropsrvrolemember, синтаксис
которой представлен ниже:
sp_dropsrvrolemember [@loginame=] ‘login’, [@rolename] ‘role’
Приведенный выше список ролей уровня сервера позволяет сказать о том,
что включение в эти роли пользователей дает возможность выполнить
определение только администраторов сервера, а не рядовых пользователей баз
данных. Способ добавления обычных пользователей определяется в
соответствии с выбранным режимом аутентификации пользователей.
2.2 Ключевые сценарии безопасности приложений MS SQL Server
Необходимо понимать, что не существует некоторого универсального
решения, которое будет на протяжении долгого времени предоставлять
достаточный уровень защиты базы данных при работе внутри клиент-серверной
архитектуры. Так как сама база данных является не прикладным решением, а
только инструментом более корректного размещения данных и технологий
отбора данных с помощью различных запросов к базе данных.
Развертываемые базы данных существенно могут отличаться по:
числу пользователей, которые одновременно должны получать
доступ в базу данных;
технологиям организации доступа посредством дополнительных
серверов приложений или напрямую через клиента;
размерам самой базы, включая ее метрические характеристики
(число таблиц, атрибутов, глубину дерева связей таблиц и т.п.).
Значительную роль в обеспечении безопасности играет фактор времени,
так как защищенное на момент внедрения решение может стать менее
защищенным из-за:
выявления пробелов в безопасности старых версий программного
обеспечения;
32
увеличения числа пользователей до критического уровня, что может
привести к серьезным сбоям системы при наличии настойчивых попыток
несанкционированного доступа за короткий промежуток времени;
появление новых методик поиска уязвимостей;
проведения некорректной модернизации приложений с
расширением функционала без проверки уровня безопасности этих операций.
Таким образом, можно говорить, что нельзя сформировать постоянную
политику безопасности, такие сценарии требуют постоянного наблюдения и
обновления.
Встроенные системы защиты сервера MS SQL Server ориентированы
разработчиками на устранение следующих основных угроз:
внедрение SQL-кода, передача которого осуществляется без
проверки кода приложениям и выполняется сервером напрямую;
технологии повышения привилегий, ведущие к исполнению
сценариев, которые могут быть реализованы только владельцем базы данных;
проведение зондирования для поиска и анализа ошибок приложения;
внедрение SQL-кода в процессе соединения;
низкая надежность паролей.
Построение политики безопасности нельзя рассматривать как набор
разрозненных мероприятий, которые ориентированы на защиту от конкретной
угрозы. Это должен быть именно комплекс мер, так как прочность защиты
строится на базе взаимосвязи всех технологий.
Разработчик может воспользоваться дополнительными решениями,
которые предлагает компания Microsoft с применением хранимых процедур [19]:
управление разрешениями;
написание безопасного динамического кода SQL в SQL Server;
сертифицирование хранимых процедур в SQL Server;
применение предложения EXECUTE AS с целью олицетворения
другого пользователя (переключение контекста выполнения);
33
реализация разрешения уровня строки для ограничений доступа к
данным.
2.3 Реализация контроля и разграничения доступа
Разграничение доступа предполагает не только использование
аутентификации при получении разрешения на вход в базу данных, но и
разделение возможностей пользователей. Назначение запретов на выполнение
определенных действий.
Благодаря расширенным возможностям владелец базы данных может
предоставить конкретным пользователям не только явные права на
оперирование конкретными объектами базы данных, но и неявные, реализуемые
посредством политики ролей. Предоставление неявных прав доступа
осуществляется через членство в фиксированной роли сервера или базы данных.
Любое право, например, предоставление возможностей для создания
новых баз данных может быть реализовано только путем включения в роль
сервера dbcreator. Однако неявные права могут и обладать автоматическим
наследованием. Например, создание объекта конкретным пользователем
автоматически влечет за собой предоставления прав доступа к этому объекту
этому пользователю.
Значит, уровень базы данных для пользователя реализует два сценария
предоставления привилегий:
прикрепление фиксированной роли базы данных;
назначение привилегий я помощью оператора SQL GRANT.
Системному администратору автоматически предоставляются все права
на оперирование объектами на сервере и лежащим на нем базам данных , ему
отводится роль сервера – sysadmin.
Таблица 3 демонстрирует список фиксированных ролей базы данных для
MS SQL Server [18].
Таблица 3
Список фиксированных ролей базы данных
Название роли
Права роли
db_securityadmin
Разрешение на управление правами пользователей базы
данных: права доступа к объектам, членство в ролях.
34
db_owner
Является владельцем базы данных. Неограниченные
права в рамках базы данных.
db_denydatawriter
Запрет на изменение объектов базы данных вне
зависимости от выданных разрешений.
db_denydatareader
Запрет на просмотр данных базы данных вне
зависимости от выданных разрешений
db_ddladmin
Разрешение на оперирование объектами базы данных:
создание, изменение, удаление.
db_datawriter
Разрешение на изменение данных таблиц и
представлений.
db_datareader
Разрешение на просмотр данных таблиц и
представлений.
db_backupoperator
Разрешение на проведение резервного копирования
базы данных.
db accessadmin
Разрешение на управления пользователями базы
данных, создание, удаление, изменение.
Для организации специализированных групп в базе данных используются
пользовательские роли. Роль определяет права доступа и спектр разрешений, а
конкретному пользователю может быть назначена пользовательская роль.
По умолчанию все пользователи базы данных входят под ролью public,
которая реализует неявное назначение привилегий.
Для явного определения разрешений доступа к объектам используются
инструкции:
SQL GRANT;
REVOKE;
DENY.
При этом разрешения могут быть глубоко детализированы, то есть
определяться для конкретных действий:
отбора данных (SELECT);
добавление данных (INSERT);
изменения данных (UPDATE);
запуск на выполнение (RUN) и т.д.
Назначение запрета привилегии переобределяет предоставленное право
доступа и, наоборот, предоставление привилегии замещает собой ее отзыв.
Разрешения пользователя могут состоять из:
индивидуальных наследований от роли;