Основные цели защиты приложений баз данных SQL Server
Основной целью Регламента является повышение приоритета задач обеспечения информационной безопасности приложений баз данных, эксплуатируемых в _____________________________________ (далее, Заказчик). Регламент и Политика должны стать основой нормативной и технической документации используемых и унаследованных Приложений, а также технических заданий на разработку новых и доработку существующих Приложений.
Основной целью регламентируемых задач является устранение угроз информационной безопасности Приложений. Полный список возможных рисков и угроз, а также способов их предотвращения можно найти в документе Майкрософт: Таблица угроз и уязвимостей (компонент Database Engine).
Задача 1. Бизнес-требования к безопасности баз данных
Перед развертыванием SQL Server необходимо спланировать политику безопасности баз данных. Базовым принципом такого планирования должно быть обеспечение полной безопасности данных на уровне сервера, а затем смягчение этих требований к безопасности в отдельных областях в соответствии с потребностями бизнеса. Кроме того, перед развертыванием следует также выбрать способы снижения рисков, связанных с сетевыми атаками на сервер.
Реализация Политики должна обеспечивать исполнение следующих требований:
- Гарантия согласованность мероприятий по безопасности по всей IT-инфраструктуре.
- Отражать потребности бизнеса в информационной безопасности.
- Снижать юридическую ответственность за счет реализации адекватных мер безопасности для клиентов и деловых партнеров.
- Определять для каждого работника меру ответственности за безопасность, а также давать определения нарушениям безопасности.
- Предлагать набора правил, на основе которых создаются упрощенные инструкции по безопасности.
Реализация Политики в Приложении должна обеспечивать безопасность по умолчанию, т.е. необходимо реализовать в Приложении максимально строгие требования Политики, прежде чем начать разработку специальных требований и отступлений для нужд Приложения. Только после реализации этой строгой политики следует приступать к разработке адаптированной (менее жесткой) политики, соответствующей потребностям Приложения.
Перед настройкой Политики в Приложении необходимо собрать требования к безопасности баз данных заинтересованных в работе Приложения подразделений Заказчика. Затем нужно оценить риски, связанные с безопасностью. Далее следует выработать общие требования Политики, указав все допустимые исключения из нее.
Сбор требований
До формирования Политики Приложения необходимо собрать требования к безопасности, руководствуясь следующими рекомендациями:
- Проведите интервью с руководством заинтересованных подразделений Заказчика.
Обсуждение с руководством и другими заинтересованными лицами потребности пользователей в доступе к данным и требований организации по защите конфиденциальных данных. Требования фиксируются в формальном документе о политике безопасности.
- Учёт требования законодательства.
В зависимости от характера данных, их расположения и действующего законодательства выработка специальных мер по защите данных организации. Консультации с юристом по поводу правовых актов, которые могут повлиять на политику безопасности.
- Фиксация всех необходимых отклонения от базовой Политики.
При сборе требований к безопасности необходимо выявить все отклонения от Политики (когда привилегии некоторых пользователей или групп отличаются от привилегий большинства пользователей).
- Упрощайте бизнес-требования к безопасности.
Принятие мер к тому, чтобы список сформулированных бизнес-требований к безопасности был как можно более простым. Слишком большое количество бизнес-требований потребует более длинного списка исключений и сделает политику безопасности трудно управляемой.
Оценка требований
Собрав все требования к безопасности, необходимо выполнить их оценку, рассмотрев различные способы их реализации. Для реализации избирается такой метод, который бы удовлетворял этим требованиям и в то же время не отнимал слишком много административных ресурсов. Затем необходимо оценить риски, связанные с не исполнением требований безопасности.
Базовая Политика и исключения
После сбора и оценки требований к безопасности следует определить базовую Политику безопасности и зафиксировать её в документе по безопасности. Эта Политика может включать список серверов баз данных, для которых необходимо шифрование, или список прав доступа к базе данных, предоставляемых через встроенную роль базы данных public.
В документе по безопасности необходимо также указать все исключения из базовой Политики. При этом следует придерживаться следующих рекомендаций:
- Количество исключений должно быть минимальным.
Исключения усложняют политику безопасности и, как следствие, затрудняют ее внедрение и управление. Поэтому количество исключений следует минимизировать.
- Необходимо учитывать последствия исключений из политики безопасности.
Исключения могут повлиять на безопасность систем непредсказуемым образом. Следует убедиться в том, что учтены все потенциальные последствия предоставления пользователям повышенных привилегии.
- Документация по всем исключениям из политики безопасности.
Каждое исключение следует документировать вместе с тем бизнес-процессом, которым оно вызвано. Следует наладить процесс периодического мониторинга каждого исключения с целью выяснение, есть ли еще в нем необходимость.
Задача 2. Защита SQL Server от сетевых атак
Для разработки эффективной Политики необходимо получить информацию о наиболее распространенных угрозах для Приложения. Базовая Политика должна включать три основные угрозы Приложений, а также меры по снижению рисков и ущерба от атак на Приложения. Ниже представлены рекомендации по трём основным угрозам.
Атаки вирусов и червей
Необходимо разработать и предусмотреть комплекс организационных, технических и программных мер по снижению риска заражения Приложения компьютерными «вирусами» (далее, вирусами), а систем Приложения компьютерными червями (далее, червями). Под компьютерным червём понимается такой тип вируса, который может заразить компьютер без участия пользователя и без проникновения в какой-либо файл, а под вирусом понимается вредоносная программа, которая может изменить или стереть данные, хранящиеся в базе данных, повредить исполняемые файлы SQL Server, вывести из строя сервер, нарушить сетевые соединения и т. п.
Для снижения риска заражения вирусами и червями, следует придерживаться следующих рекомендаций:
- В технических заданиях на разработку новых Приложений должна закладываться необходимость реализации адекватных мер по препятствию заражения файлов приложения вирусами.
- В технических заданиях на разработку новых Приложений должна закладываться необходимость реализации адекватных мер предотвращению заражения систем Приложения червями, через интерфейсы Приложения.
- Новое Приложение должно допускать установку на серверах баз данных антивирусного ПО.
- Новое Приложение должно адекватно реагировать на установку в системах свежих сервисных пакетов и обновлений SQL Server и Microsoft Windows.
- Приложение не должно использовать и предоставлять клиентский доступ к компонентам DatabaseMail и SQL Mail.
- Приложение не должно работать напрямую с Интернетом. Должны использоваться межсетевые экраны, в настройках которых нужно разрешать входящий трафик только на необходимые порты.
- У всех учетных записей пользователей и групп, создаваемых для доступа к данным Приложения, должны быть надежные пароли.
Атаки типа «отказ в обслуживании»
Необходимо принять меры, предотвращающие использование разрабатываемого Приложений для организации или в качестве вспомогательного средства атаки типа «отказ в обслуживании» (Denial of Service, DoS).
Атаки с внедрением SQL-кода
Приложение должно препятствовать организацию атак с внедрением SQL-кода (SQL Injection). Входные данные должны проходить проверку правильности входных запросов Приложения. Запросы, не прошедшие проверку, должны отвергаться.
Наиболее эффективный способ гарантировать, что к базе данных SQL Server выполняются только корректные запросы, - использовать в Приложениях для доступа к данным только хранимые процедуры.
Не желательно использование динамических SQL-запросов. Динамические запросы очень часто являются причиной атак с внедрением SQL-кода. Если необходим динамический код, предпочтительно использовать параметрические запросы или хранимые процедуры, поскольку они гораздо безопаснее, чем нерегламентированные динамические запросы.
Задача 3. Обеспечение безопасности SQL Server
Модель безопасности Приложения должна включать участников безопасности и защищаемые объекты на различных уровнях. Участники безопасности должны проходить аутентификацию в Active Directory, либо встроенную аутентификацию SQL Server. В качестве основного документа, помогающего наметить конкретные направления работ по обеспечению безопасности обслуживаемых SQL Server данных, следует использовать следующий публичный документ Майкрософт: Рекомендации по безопасности SQL Server 2005 – задачи эксплуатации и администрирования. В качестве средства проверки и контроля безопасности SQL Server необходимо на регулярной основе использовать специализированное средство Майкрософт, программу: Microsoft Baseline Security Analyzer 2.1 (for IT Professionals)
Участники системы безопасности
Под участниками безопасности Приложения - это такие сущности, как пользователи, учетные записи, группы и роли, которые могут обращаться к базе данных, серверу или к схеме. Группы и роли известны также как коллекции, поскольку могут включать в себя других участников безопасности.
В модели безопасности Приложения существование участников безопасности допускается на трех уровнях: уровне Windows (Active Directory), уровне SQL Server и уровне базы данных.
Уровень Windows
Участники безопасности на уровне Windows - это доменные имена входа Windows и локальные группы Windows. Для простоты управления и лучшей безопасности желательно везде, где только возможно, использовать в Приложении участников безопасности Windows.
Уровень SQL Server
На уровне SQL Server участниками безопасности являются имена входа SQL Server и серверные роли. Имена входа SQL Server использовать в Приложениях не рекомендуется, они допустимы только после предоставления Заказчику подробного обоснования этой необходимости, которое в обязательном порядке согласуется со службой безопасности Заказчика.
Имена входа SQL Server обычно используются для внешних пользователей компании, например для тех, кто подключается к базе данных через веб-сайт. Кроме того, у каждого экземпляра SQL Server есть встроенное имя входа «sa» и могут также быть имена входа NETWORK SERVICE и SYSTEM (в зависимости от конфигурации экземпляра), которые не должны использоваться Приложением.
Уровень базы данных
На уровне базы данных участниками безопасности являются пользователи базы данных, роли приложения и роли базы данных.
Пользователи базы данных - это сущности, связанные с именами входа Windows или SQL Server, которым назначен определенный набор разрешений и привилегий к отдельным объектам (например, к таблицам) базы данных. Стандартные (встроенные) пользователи баз данных SQL Server: guest, dbo, INFORMATION_SCHEMA и sys не должны использоваться Приложением. Guest - это специальный пользователь, который добавляется к базе данных, чтобы дать возможность любому обладателю имени входа SQL Server получить доступ к базе данных, и, как правило, он заблокирован. Владелец базы данных (или dbo) - это специальный тип пользователя базы данных (обычно создатель базы данных), которому предоставлены все разрешения и привилегии доступа к базе данных, включая право назначать разрешения другим пользователям. Владельца БД могут олицетворять другие пользователи, если это предусматривается логикой работы Приложения. Желательно не предоставлять набор прав dbo подключающимся через Приложение пользователям, оставив подобные задачи администратору баз данных. Пользователи INFORMATION_SCHEMA и sys предназначены только для внутрисистемного использования (для обращения к представлениям метаданных).
Выбор пользователей владельцев схем должен исключать возможность их дальнейшего изменений. Предоставление пользовательским ролям баз данных доступа к объектам базы данных желательно осуществлять через соответствующие схемы.
Посредством роли Приложения допускается создавать защищенные паролем роли для конкретных приложений. Например, пользователь может подключиться к базе данных через веб-приложение, которое может активировать соответствующую роль, обеспечив пользователя разрешениями и привилегиями этой роли.
Роли базы данных можно использовать для назначения разрешений на уровне базы данных. Например, вы можете создать роль Users, которая позволяет пользователям применять операторы EXECUTE, SELECT, INSERT и UPDATE к определенным таблицам базы данных. Затем можно назначить эту роль некоторым пользователям, вместо того чтобы назначать разрешения каждому из них по отдельности.
Ниже приведен список предопределенных ролей SQL Server, которые есть в каждой базе данных:
• public
Роль по умолчанию, назначается всем пользователям базы данных. Если необходимо предоставить всем пользователям базы данных определенный набор разрешений, назначьте эти разрешения роли public. Не допускается предоставлять этой роли весь набор прав, ограничивая доступ пользователей на уровне Приложения. Права на объекты базы данных пользователя не должны зависеть от места подключения.
• db_accessadmin
Предназначена для пользователей, которым необходимо добавлять или удалять имена входа в базе данных.
• db_backupoperator
Предназначена для пользователей, которым необходимо выполнять резервное копирование базы данных.
• db_datareader
Предназначена для пользователей, которым необходимо просматривать данные в базе данных. Члены этой роли могут выбирать все данные из любой пользовательской таблицы базы данных. Для пользователей Приложения предоставление прав через эту роль нежелательно.
• db_datawriter
Предназначена для пользователей, которым необходимо добавлять или изменять любые данные в любой пользовательской таблице базы данных. Члены этой роли могут выполнять следующие задачи: DELETE, INSERT и UPDATE. Для пользователей Приложения предоставление прав через эту роль нежелательно.
• db_ddladmin
Предназначена для пользователей, которым необходимо выполнять задачи, связанные с языком определения данных (DDL) SQL Server. Члены этой роли могут выполнять любые операторы DDL, за исключением GRANT, REVOKE и DENY
• db_dеnуdаtаrеаdеr
Предназначена для ограничения доступа к данным в базе данных. Члены этой роли не могут читать никакие данные пользовательских таблиц базы данных.
• db_denydatawriter
Предназначена для ограничения прав на модификацию базы данных. Члены этой роли не могут добавлять, изменять или удалять данные пользовательских таблиц базы данных.
• db_owner
Предназначена для пользователей, которым необходим полный контроль над всей базой данных. Для пользователей Приложения предоставление прав через эту роль нежелательно.
• db_sесuritуаdmin
Предназначена для пользователей, которым необходимо управлять разрешениями, принадлежностью объектов и ролями.
Для упрощения администрирования SQL Server в производственной среде рекомендуется поместить учетные записи Windows всех доменных пользователей, которым нужны одинаковые привилегии SQL Server, в одну группу учетных записей Windows. Затем нужно назначить этой группе подходящую серверную роль. В общем случае следует избегать назначения ролей напрямую индивидуальным учетным записям Windows.
Защищаемые объекты SQL Server
Защищаемые объекты - это сущности SQL Server, к которым назначаются разрешения. Есть три защищаемых объекта верхнего уровня: сервер, база данных и схема. Каждый из этих объектов содержит другие защищаемые объекты, которые, в свою очередь, также могут содержать другие защищаемые объекты. Эти вложенные иерархии называются областями действия. Область действия сервера включает такие защищаемые объекты, как экземпляры сервера, базы данных, конечные точки, имена входа и серверные роли. Примерами защищаемых объектов области действия базы данных являются роли приложения, роли базы данных, схемы и пользователи. Защищаемые объекты области действия схемы - функции, процедуры, таблицы и представления.
Проверка разрешений и привилегий участников безопасности
Для проверки разрешений и привилегий защищаемых объектов в SQL Server 2005 в Приложениях допускается использование функций Transact-SQL: IS_SRVROLEMEMBER и HAS_PERMS_BY_NAME.
Функция IS_SRVROLEMEMBER возвращает значение 1, если текущее имя входа является членом указанной фиксированной серверной роли.
Функция HAS_PERMS_BY_NAME определяет действующие разрешения текущего пользователя на доступ к защищаемому объекту.
Режимы аутентификации SQL Server 2005
SQL Server 2005 можно настроить на использование одного из двух режимов аутентификации. В режиме аутентификации Windows вы назначаете пользователям разрешения и привилегии доступа к ресурсам SQL Server только через учетные записи Windows (или группы Windows). В режиме аутентификации SQL Server и Windows (известен и как смешанный режим защиты) пользователи могут также подключаться к SQL Server с помощью отдельного имени входа SQL Server и получать через него разрешения и привилегии.
Режим аутентификации Windows
В режиме аутентификации Windows для подключения к SQL Server используются существующие учетные записи пользователей и групп Windows. Этот режим позволяет локальным и доменным пользователям Windows получить доступ к базам данных, не используя имя входа и пароль SQL Server. Режим аутентификации Windows удобен для пользователей, поскольку не требует от них запоминать разные пароли для аутентификации в Windows и в SQL Server. Кроме того, режим аутентификации Windows безопаснее. К тому же, пользователи в этом случае подчиняются правилам модели безопасности Windows, поэтому возможна блокировка учетных записей, ведение аудита входа в систему и принуждение пользователей к периодической смене своих паролей.
SQL Server в режиме аутентификации Windows аутентифицирует пользователей на основе их учетных записей Windows и членства в группах Windows. Администратор баз данных может назначать разрешения баз данных любой учетной записи пользователя или группы Windows. Доменные учетные записи являются лучшим способом управления пользователями, которые обращаются к базе данных из внутренней сети организации. Объединение пользователей в доменные группы с последующей настройкой прав доступа для этих групп в SQL Server существенно сокращает накладные расходы на администрирование.
Если для SQL Server выбрана аутентификация Windows в домене Active Directory, то в сети обязательно должен быть контроллер домена. Если контроллер домена недоступен, то любые попытки регистрации пользователей потерпят неудачу. Поэтому при использовании в SQL Server режима аутентификации Windows в домене Active Directory должны быть приняты дополнительные меры по обеспечению высокой готовности контроллера домена.
Смешанный режим аутентификации SQL Server и Windows
При смешанном режиме аутентификации (режим аутентификации SQL Server и Windows) пользователь соединяется с SQL Server, используя имя входа SQL Server или учетную запись Windows. Одно из преимуществ аутентификации SQL Server (в отличие от аутентификации Windows) в том, что аутентификация SQL Server не зависит от работоспособности каких-либо внешних служб. Использование смешанного режима аутентификации нежелательно и допускается в Приложении только с предоставлением подробного обоснования невозможности аутентификации Windows. Решение о приемлемости использования смешанного режима аутентификации принимает служба безопасности Заказчика.
Задача 4. Защита SQL Server от внутренних угроз
Защита приложений баз данных от внутренних угроз является наиболее трудоёмкой, затратной и сложной задачей информационной безопасности. Информация, по отношению к которой существуют внутренние угрозы, может носить конфиденциальный характер, быть предназначенной ограниченному числу сотрудников и/или составлять секрет технического, коммерческого либо иного рода. Классификация такой информации осуществляется на основе действующих бизнес – правил и является предметом регулирования подразделений безопасности Заказчика. Наиболее действенным способом защиты от внутренних угроз является обеспечение лояльности технического персонала, разработчиков и пользователей Приложений.
Защита приложений баз данных от внутренних угроз не заменяет прочие способы защиты информации, она является дополнительной мерой, способной усилить уже принятый комплекс мер.
Размещение серверов баз данных
К сервера баз данных, которые обслуживают защищаемые от внутренних угроз Приложения, должны предъявляться особые требования к их физическому размещению. Это могут быть отдельные серверные комнаты или зоны в общих серверных комнатах, доступ к которым осуществляется по собственным правилам и открыт для отдельного списка сотрудников. Например, в общей серверной комнате это может быть отдельная, запираемая стойка, ключи от которой выдаются только тем сотрудникам, которые включены в список доступа, составленный и актуализируемый сотрудниками безопасности Заказчика.
Сервера, содержащие защищаемую от внутренних угроз информацию не должны располагаться в зонах DMZ. Подключения к портам служб таких серверов должны осуществляться через межсетевые экраны, и кроме мер аутентификации и авторизации домена, предусматривать листы доступа. Операционная система сервера баз данных должна обеспечиваться встроенным брандмауэром, который должен обеспечивать разграничение доступа к портам служб для подключений из ближайшего сетевого окружения сервера. Политики разграничения такого доступа регламентируются сотрудниками безопасности и реализуются системными администраторами Заказчика. Разработчики Приложения обязаны предоставить Заказчику полное и подробное описание «Контактной Зоны» Приложения и сервера баз данных.
Подключения пользователей к серверам должны шифроваться. Все обращения к защищаемой от внутренних угроз информацией должны подлежать аудиту. Запрещается доступ к защищаемой от внутренних угроз информации обезличенных пользователей.
Требования к аудиту приложения баз данных
Требования к аудиту приложения баз данных, оперирующего защищаемой от внутренних угроз информацией, должны соответствовать рекомендациям Майкрософт, изложенным в электронной документации BOL: Соответствие стандартам безопасности (Common Criteria и/или FIPS 140-2).
Включение подробного аудита действий пользователей Приложения может существенно повысить нагрузку на сервер, сети и персональные компьютеры. При разработке технических заданий на создание программно – аппаратных комплексов Приложения необходимо учитывать технические требования для обеспечения необходимого уровня производительности с включённым аудитом. Включение аудита не должно существенно влиять на работу пользователей Приложения и других, задействованных в программно – аппаратном комплексе систем.
Детализация каждого из возможных уровней аудита Приложения должна отражать бизнес – требования и текущий уровень внешних и внутренних угроз. Конкретный состав уровней аудита предлагается разработчиком Приложения и утверждается в подразделении безопасности Заказчика.
Шифрация защищаемой от внешних угроз информации
Шифрование представляет собой способ скрытия данных с помощью ключа или пароля. Это делает данные бесполезными без соответствующего ключа или пароля для дешифрования. Шифрование не решает проблемы управления доступом. Однако оно повышает защиту за счет ограничения потери данных даже при обходе системы управления доступом. Например, если злоумышленник смог получить конфиденциальные данные, то украденная информация будет бесполезна, если она была предварительно зашифрована.
Несмотря на то, что шифрование является полезным средством обеспечения безопасности, его не обязательно применять ко всем данным или соединениям. Для вновь разрабатываемых Приложений необходимо согласовать со специалистами по информационной безопасности Заказчика конкретные наборы данных, подлежащие шифрованию. Также, в зависимости от уровня защиты, определяются способы и алгоритмы шифрования и планируется иерархия средств шифрования. Использование шифрования подчиняется принятым у Заказчика политикам управления паролями, ключами и сертификатами. Допускается разработка индивидуальных политик для отдельных Приложений.
Основным руководством при планировании шифрования защищаемых от внутренних угроз данных является документ Майкрософт: Шифрование SQL Server.
