SQL Server 2005
Вопросы обеспечения безопасности. Часть 2
Объекты для управления доступом
Использование хранимых процедур
Выбор способов реализации механизмов аудита
В предыдущих номерах мы рассмотрели разные сценарии использования SQL Server 2005. Мы рассказали о возможных вариантах применения различных сервисов, входящих в состав SQL Server 2005, — нотификационных сервисов, SQL Server Service Broker- и Web-сервисов, а также о некоторых сценариях использования других компонентов SQL Server 2005 — средств создания отчетов, интеграционных сервисов, SQLXML, средств репликации, а также SQL Server Agent и Database Mail. Мы остановились на практических примерах выбора компонентов SQL Server 2005 для решения задач, связанных с переносом приложений на новую версию системы управления базами данных, а также (в № 5’2006) начали рассказ об обеспечении безопасности систем, использующих SQL Server 2005 в качестве базы данных, и о различных механизмах безопасности, применимых к сервисам, входящим в состав SQL Server 2005.
этом номере мы рассмотрим вопросы создания объектов, управляющих доступом к базе данных, а также различные механизмы аудита.
Объекты для управления доступом
Одним из обязательных этапов проектирования баз данных является идентификация способов доступа к объектам базы данных. В рамках этого процесса необходимо, например, определить, как применять схемы и роли для группировки объектов базы данных и пользователей в управляемые группы, а также каким образом для обеспечения безопасного доступа к данным будут использоваться представления и хранимые процедуры (это поможет, например, ограничить прямой доступ к объектам базы данных). Ниже мы рассмотрим, как использовать роли, схемы, хранимые процедуры и представления, а также обсудим вопросы, связанные с заданием контекста выполнения кода.
Роли и схемы
В SQL Server 2005 эффективно решать вопросы управления большим числом пользователей позволяют два типа объектов — роли и схемы. Роль — это контейнер для группировки нескольких пользовательских учетных записей. Схема — это набор объектов базы данных, образующих пространство имен. Роли используются для доступа к базам данных SQL Server. При дизайне можно пользоваться следующими простыми правилами:
- применяйте роли для всех типов доступа к базам данных — роли упрощают управление большим числом пользователей, так как группы пользователей можно объединить в одну роль. В этом случае легко установить необходимые права доступа для любого числа пользователей. Например, если все пользователи могут выполнять определенный набор операций, создание одной роли и назначение ей соответствующих прав намного эффективнее индивидуальной раздачи прав каждому пользователю;
- используйте вложенные роли — в SQL Server имеется возможность создания вложенных ролей, то есть роль может быть членом другой роли. Применяя этот механизм, можно создавать подгруппы пользователей, входящих в более крупные группы, и таким образом более детально управлять правами;
Для того чтобы максимально эффективно воспользоваться предоставляемыми SQL Server 2005 механизмами управления доступом, рекомендуется разделить приложения по требованиям к доступу к базам данных, а затем выбрать наиболее подходящий для реализации этих требований механизм:
- схемы — возможно создание схем для каждого приложения. В этом случае роли выступают в виде владельцев схем, а пользователи — членами той или иной роли. Права назначаются на уровне схемы;
- прикладные роли (application roles) — могут применяться для ограничения доступа к определенному набору данных в тех случаях, когда пользователи обращаются к данным через приложение. В отличие от фиксированных ролей на уровне базы данных, прикладные роли не содержат членов и по умолчанию неактивны. Рекомендуется использовать прикладные роли в тех случаях, когда требования по безопасности одинаковы для всех пользователей. Отметим, что прикладные роли нежелательно применять в тех случаях, когда предполагается реализация механизмов аудита, — в случае прикладных ролей вы не сможете аудировать активность конкретных пользователей.
Помимо данных выше рекомендаций имеет смысл классифицировать пользователей с точки зрения требований по доступу. В этом случае можно сгруппировать пользователей в соответствии с требованиями и по возможности определить, какие группы могут быть вложены в более крупные группы. После этого можно создать роли для каждой группы. И последний совет: обязательно создайте и поддерживайте в актуальном состоянии список ролей, определенных для каждой базы данных, и пользователей, относящихся к каждой роли.
Использование хранимых процедур
Для выполнения большинства операций приложения могут использовать либо хранимые процедуры, либо код на языке SQL, встроенный в приложения. С точки зрения безопасности применение хранимых процедур имеет больше преимуществ. Например, хранимые процедуры позволяют исключить возможность атак типа SQL Injection, запретить неавторизованный доступ и обеспечить управление контекстом выполнения (об этом — далее).
Ниже приводятся основные правила использования хранимых процедур:
- приложения не должны применять конструкции SELECT, INSERT, UPDATE и DELETE для запросов к базе данных и прямой манипуляции объектами базы данных. Вместо этого используйте хранимые процедуры, выполняющие требуемые операции;
- применение хранимых процедур облегчает защиту данных в базе данных, что позволяет отказаться от назначения прав доступа непосредственно для таблиц и представлений;
- использование хранимых процедур обеспечивает больший контроль над операциями, выполняемыми на уровне приложения;
- применение хранимых процедур делает приложения не зависящими от схемы базы данных, что позволяет изменять ее без внесения изменений в само приложение — изменению подлежат только хранимые процедуры. Также отметим, что в этом случае отпадает необходимость в развертывании новой версии клиентского приложения на всех компьютерах пользователей;
- использование хранимых процедур позволяет инкапсулировать операции над конфиденциальными данными, которые при применении других механизмов могут стать доступными пользователям или приложению;
- использование хранимых процедур облегчает процесс оптимизации — вместо настройки SQL-кода, встроенного в приложения, вы настраиваете код хранимых процедур;
- применение хранимых процедур позволяет сократить сетевой трафик — в этом случае логика приложения реализуется на сервере, а не в приложении.
Необходимо помнить о том, что любое клиентское приложение, работающее с базой данных на уровне SQL-конструкций, более подвержено атакам типа SQL Injection. Для снижения рисков рекомендуется использовать хранимые процедуры и параметризованные запросы для всех операций доступа к данным. При этом следует также проверять всю вводимую пользователями информацию, перед тем как передать ее хранимым процедурам в виде параметров.
При необходимости можно воспользоваться механизмами шифрования кода хранимых процедур — для этого в конструкциях CREATE PROCEDURE и ALTER PROCEDURE следует применять ключевое слово WITH ENCRYPTION, но не забудьте сохранить исходный код хранимой процедуры в проекте SQL Server как часть процесса управления версиями.
Применение представлений
Представления — это еще один механизм обеспечения безопасного доступа к объектам базы данных, правда не такой гибкий, как уже рассмотренные хранимые процедуры. Использование представлений обычно приводит к тому, что в приложениях появляется больше логики доступа к данным по сравнению с приложениями, применяющими хранимые процедуры. Однако представления обеспечивают более простой по сравнению с хранимыми процедурами механизм фильтрации информации, доступной пользователям. Помимо этого использование представлений предотвращает непосредственное обращение к таблицам, позволяет ограничить доступ к рядам и колонкам, скрыть структуру базы данных и т.п.
Ниже приводятся основные правила применения представлений:
- использование представлений позволяет ограничить доступные пользователям данные. Например, можно указать, что представление поддерживает только конструкцию SELECT и пользователи и приложения не могут обновлять данные. Также можно применять ключевое слово WITH CHECK OPTION для того, чтобы все DML-конструкции, выполняемые относительно представления, соответствовали заданному критерию на уровне конструкции SELECT;
- использование представлений позволяет ограничить число рядов и колонок, возвращаемых приложению как результат запроса. Если различные приложения или пользователи должны получать разные срезы данных, то просто задайте необходимый набор представлений;
- применение представлений позволяет скрыть комплексность базы данных и изолировать приложения от изменений в схемах. Представления можно использовать для объединения таблиц, вычисления суммарных значений и т.п. При необходимости модификации схемы таблиц не требуется внесения изменений в сами приложения при условии, что поставляющие данные представления сохраняют свою структуру;
- имеется возможность шифрования представлений — для этого в конструкции CREATE VIEW или ALTER VIEW следует использовать ключевое слово WITH ENCRYPTION. Как и в случае с шифрованием кода хранимых процедур, не забудьте сохранить исходный код представления в проекте SQL Server как часть процесса управления версиями;
- не создавайте представления на основе других представлений — это может привести к снижению производительности и созданию дополнительного числа временных таблиц. Помимо этого изменения в одном представлении могут потребовать внесения изменений во всех представлениях, созданных на его основе.
Контекст выполнения кода
В SQL Server 2005 реализована возможность управления контекстом выполнения хранимых процедур и пользовательских функций. Для этого используется конструкция EXECUTE AS, указываемая при создании соответствующего объекта базы данных. Эта конструкция задает пользовательскую учетную запись, которую SQL Server будет применять для проверки прав доступа к объектам, используемым в коде хранимой процедуры или пользовательской функции. В результате для пользователей появляется механизм для обеспечения возможности выполнения кода, как если бы они были аутентифицированы под другой учетной записью. Таким образом можно исключить цикличное назначение прав на определенные объекты базы данных и открытие прямого доступа к ряду таких объектов.
Рассмотрим следующий сценарий применения конструкции EXECUTE AS. Предположим, пользователю OrdinalUser требуется обеспечить возможность модификации записей в той или иной таблице. В настоящий момент такого права он не имеет. Чтобы предоставить пользователю возможность модификации, необходимо дать ему право на выполнение конструкции ALTER, однако оно расширяет область возможностей пользователя значительно больше, чем требуется в нашем сценарии. Вместо этого мы должны создать хранимую процедуру, выполняющую необходимые модификации, добавить конструкцию EXECUTE AS и указать учетную запись, которая обладает правами на выполнение конструкции ALTER. После этого мы назначаем права на EXECUTE пользователю OrdinalUser.
Как мы уже отметили, использование конструкции EXECUTE AS позволяет исключить цикличное назначение прав и открытие прямого доступа к ряду объектов базы данных. В SQL Server цикличная проверка прав применяется при выполнении конструкций SELECT, INSERT, UPDATE, DELETE и EXECUTE. При выполнении конструкций CREATE TABLE, TRUNCATE TABLE, BACKUP DATABASE и EXEC (динамический SQL) цикличная проверка не используется и SQL Server применяет контекст выполнения для определения прав, необходимых для выполнения таких конструкций.
Шифрование информации
В SQL Server 2005 реализована возможность защиты данных на уровне колонок за счет шифрования хранимой в них информации. Необходимо помнить о том, что шифрование данных может привести к потери производительности, поэтому перед тем, как распространять финальную версию приложения, необходимо провести дополнительное тестирование.
Ниже приводятся основные правила использования механизмов шифрования на уровне колонок:
- шифруйте только конфиденциальные данные;
- учитывайте следующие ограничения, налагаемые на данные в зашифрованных колонках:
- зашифрованные данные не могут быть отсортированы, отфильтрованы или проиндексированы,
- зашифрованные данные должны храниться как VARBINARY(128);
- перед принятием окончательного решения о шифровании данных изучите, как эти механизмы повлияют на общую производительность приложения.
Ниже приведен пример использования механизмов шифрования:
CREATE DATABASE testdb
GO
USE testdb
GO
CREATE MASTER KEY ENCRPTION BY PASSWORD = ’dbPass’
GO
CREATE CERTIFICATE testcert WITH SUBJECT = ‘ToEncrypt’
GO
CREATE TABLE tcrypt (id NT, name VARCHAR(30), encryptdata VARBINARY(4000))
GO
INSERT INTO tcrypt (id, name, encryptdata)
VALUES (1, ‘testName’, ENCRYPTBYCERT(CERT_ID(‘testcert’), ‘testName’))
GO
SELECT id, name, CONVERT(VARCHAR, DECRYPTCERT(CERT_ID(‘testcert’), encryptdata))
FROM tcrypt
GO
SELECT id, name, CONVERT(VARCHAR, encryptdata)
FROM tcrypt
GO
…
В этом примере создается таблица tcrypt с тремя колонками, третья из которых — encryptdata — содержит данные, шифруемые на основании сертификата. В первой конструкции SELECT данные из таблицы извлекаются с применением сертификата и соответственно возвращаются в корректной форме, во второй — без сертификата, и в этом случае мы получаем зашифрованные данные, которые нельзя использовать.
 |
|
Механизмы аудита
Механизмы аудита помогают организациям снижать риски, связанные с несанкционированным использованием данных. В зависимости от типа организации отчеты, построенные с применением средств аудита, могут использоваться при внутреннем и внешнем аудите, при аудите на соответствие определенным стандартам, а также для выявления несанкционированных операций над данными и для предотвращения утечки информации.
Далее мы рассмотрим вопросы, связанные с реализацией стратегии аудита для данных, которые управляются средствами SQL Server 2005, — способы сбора информации, ее хранения и защиты.
При разработке стратегии аудита необходимо соблюдать баланс между требованиями к безопасности и требованиями к производительности системы. Чем больше информации для обеспечения механизмов аудита собирается в системе, тем больше вероятность обнаружения утечек информации — минусами в этом случае являются дополнительное время, требуемое для генерации и обработки такой информации, и повышенные требования к дисковому пространству для ее хранения.
Также следует понимать, что механизмы аудита не защищают сами данные — они позволяют лишь фиксировать факты утечки информации. Доведение до конечных пользователей информации о том, что проводится мониторинг их деятельности, может послужить хорошим способом предотвращения попыток неавторизованного доступа к данным и тем самым частично предотвратить утечку информации.
Иногда процедуры аудита отключаются с целью повысить производительность баз данных. В этих случаях администраторы утрачивают возможность обнаружения источников утечки информации и соответственно не могут принимать меры по их предотвращению.
Таким образом, механизмы аудита должны быть реализованы ровно настолько, насколько это реально необходимо для принятия соответствующих мер безопасности без существенных потерь в производительности как самих баз данных, так и использующих их приложений.
Далее приводятся некоторые рекомендации по реализации стратегии аудита:
- составьте список типов аудируемых событий. Как мы уже отмечали, сбор излишней информации заметно снижает производительность системы, а ее существенный объем требует дополнительных ресурсов для хранения и анализа. В список должны входить аудируемые события, уровень детализации информации по каждому такому событию, а также аудируемые ресурсы — учетные записи, сервисы, базы данных и т.п. Реализуемые механизмы аудита должны аудировать только эти события и ресурсы. Аудируемые события и ресурсы должны соответствовать бизнес-целям организации и отвечать техническим требованиям приложения;
- определите основные требования к аудиту событий. Ряд стандартов, среди которых международные стандарты типа Health Insurance Portability and Accountability Act (HIPAA) и General Principles for the Assessment of Certification Bodies for Product Certification (C2), задают основные события, подлежащие аудиту. Например, требования по аудиту в рамках C2 предусматривают такие события, как серверные события выключения и перегрузки, а также удачные или неудачные попытки доступа к отдельным объектам базы данных и выполнение всех команд DDL (Data Definition Language), DAC (Data Access Control) и DML (Data Manipulation Language);
- определите бизнес-требования. Некоторые бизнес-процессы могут требовать аудита специфических пользовательских операций. Например, в банке необходимо отслеживать переводы сотрудников, чтобы убедиться в том, что банковские фонды не используются нелегально. Таким образом, это бизнес-требование указывает на информацию, которая должна быть частью стратегии аудита;
- определите требования к безопасности. Помимо вышеописанных требований к аудиту событий, выдвигаемых принятыми в компании стандартами и бизнес-требованиями, некоторые требования к безопасности могут отражаться на информации, собираемой в процессе аудита;
- решения, принятые для реализации стратегии аудита, должны быть задокументированы, причем в документе должны быть отражены описанные выше требования и выбранные для их выполнения решения;
- собираемая механизмами аудита (их мы рассмотрим далее) информация должна анализироваться на периодической основе. При разработке системы аудита необходимо иметь однозначные ответы на ряд вопросов: кто отвечает за управление и анализ данных, как часто предполагается производить анализ данных, как будут информироваться соответствующие менеджеры об обнаруженных утечках в системе безопасности, как планируется сохранять данные, собираемые в процессе аудита?
Выбор способов реализации механизмов аудита
После того как стратегия аудита определена, необходимо выбрать способ хранения собираемой в процессе аудита информации. Способы сбора и хранения такой информации могут влиять на производительность как самой базы данных, так и использующих ее приложений.
Для хранения информации, собираемой в процессе аудита, можно применить один из следующих способов:
- использование аудируемых таблиц — в этом случае можно модифицировать таблицу, добавив колонку для хранения собираемой информации. Применяя такой подход, можно легко отслеживать события, которые происходят для каждой записи в таблице. Например, можно хранить информацию о пользователе или время модификации записи. Тем не менее объем данных, которые можно записать таким способом, довольно ограничен и поддержание полной истории для аудита может быть затруднительно;
- применение отдельных таблиц — в этом случае отдельная таблица или группа таблиц создается специально для хранения собираемой информации. Такой подход позволяет сохранять всю собираемую информацию. Получение информации для отдельной записи в данном случае будет более комплексным (по сравнению с предыдущим подходом). Для записи информации можно применять триггеры, а для ее извлечения — хранимые процедуры;
- использование SQL Profiler — можно также применять события, генерируемые SQL Server и собираемые с помощью SQL Profiler. Без написания кода собираемую информацию можно сохранять в таблице или в файле;
- применение Service Broker — в SQL Server 2005 появилась возможность посылать серверные события в очередь Service Broker, используя механизмы уведомлений. Этот механизм можно применять для асинхронного аудита всех событий на уровне SQL Profiler — большинства DDL-событий и событий SQL Trace. Информация может сохраняться в отдельных таблицах или использоваться для рассылки уведомлений.
Для определения объема хранимой информации необходимо изучить типы событий, которые вы собираетесь сохранять. Например, для хранения информации о последней модификации записи достаточно дополнительной колонки в таблице, а для хранения исторических данных потребуется отдельная таблица или группа таблиц.
Отметим, что перечисленные выше сценарии предполагают модификацию схемы базы данных — создание либо новых колонок, либо одной или более новых таблиц. В тех случаях, когда механизмы аудита реализуются для так называемых legacy-приложений или приложений, в которых в силу лицензионной политики разработчиков вы не можете менять схему базы данных, рекомендуется использовать SQL Profiler или событийные уведомления Service Broker для сбора информации.
Защита информации
Данные, собираемые для обнаружения возможных утечек информации и проблем с безопасностью, должны быть защищены — в противном случае сбор таких данных в рамках механизмов аудита и реализация механизмов аудита будут бесполезными. Способы защиты информации зависят от выбранных способов ее хранения. Также необходимо убедиться в том, что архивная информация хранится в надежном месте и четко определены сроки ее хранения и обновления.
|
|
Заключение
Мы завершили рассказ об основных механизмах обеспечения безопасности в SQL Server 2005. В следующих номерах мы продолжим рассмотрение вопросов, связанных с использованием SQL Server 2005. Следите за нашими публикациями!
