.

Уменьшение зоны атаки

Зоной атаки называют пути, через которые можно получить доступ или повысить полномочия в SQL Server. Чтобы сократить зону атаки SQL Server, примите к сведению следующие рекомендации.

Устанавливайте только необходимые компоненты SQL Server. Установку SQL Server часто рассматривают как рутинную задачу, но именно на данном этапе начинают применять меры по укреплению безопасности. При установке SQL Server не следует включать службы SQL Server Analysis Services (SSAS), SQL Server Integration Services (SSIS), а также компонент Full-Text Engine и его средство Filter Daemon Launcher. При необходимости их можно без труда добавить позднее.

Не устанавливайте службы SQL Server Reporting Services (SSRS) на одном сервере с ядром системы управления базой данных. Если установить службы SSRS на одном сервере с ядром базы данных, веб-службы создают пробел в слое безопасности. Исторически в IIS и веб-службах было много уязвимых мест, через которые хакеры проникали в сервер. В результате все объекты, размещенные на сервере, подвергались опасности. Этого можно избежать, если отказаться от установки службы SSRS на сервере базы данных.

Отключите службы SQL Server, в которых нет острой необходимости. В частности, рекомендуется сделать следующее.

  • Отключить службу SQL Server VSS Writer, которая представляет собой службу SQL Writer Service, используемую Volume Shadow Copy Service (VSS). Ее следует активировать, только если она часто используется.
  • Оставить отключенной службу Active Directory Helper. SQL Server включает и отключает ее по мере необходимости.
  • Оставить отключенной службу SQL Server Browser. Эта служба, обычно необязательная, отвечает на запросы к ресурсам SQL Server и перенаправляет вызывающую программу в нужный порт. При отключенной службе Browser эта вспомогательная служба исключается как вектор атаки, что поможет скрыть входы в компоненты SQL Server.

Не используйте порты TCP/IP, выбираемые по умолчанию. После установки следует настроить SQL Server на использование номеров портов, отличных от выбираемых по умолчанию. Порты по умолчанию — известные точки входа в SQL Server; в прошлом они использовались взломщиками. Острота проблемы не столь велика, если сервер недоступен из Интернета, но у вирусов, «троянских коней» и взломщиков есть другие способы использовать эти уязвимые места. Такой подход не устраняет путь атаки, а лишь скрывает его. Поэтому данный способ известен как «защита неизвестностью».

Отключите необязательные сетевые протоколы. Следует отключить (или не включать) сетевые протоколы, в которых нет необходимости. В большинстве случаев для подключения к SQL Server не нужны одновременно Named Pipes и TCP/IP, поэтому выберите оптимальный протокол для подключения к SQL Server и отключите другой. Например, на экране 1 показаны отключенный протокол Named Pipes и включенный TCP/IP, настроенный для прослушивания порта, отличного от выбираемого по умолчанию.

 

Отключение необязательных сетевых протоколов
Экран 1. Отключение необязательных сетевых протоколов

Обратите внимание, на состояние протоколов Shared Memory и Virtual Interface Adapter (VIA) на экране 1. Обычно можно оставить Shared Memory включенным, так как этот протокол используется сервером только для локальных подключений. Но протокол VIA нужно отключить, если только не применяется оборудование VIA.

Убедитесь, что своевременно обновлены и правильно настроены антивирусная программа и брандмауэр. Для надежной защиты на сервере должны быть установлены новейшие версии антивирусной программы и брандмауэра. Кроме того, должны быть закрыты все порты, оставленные открытыми по умолчанию. В частности, обязательно удостоверьтесь, что в брандмауэре не оставлен открытым порт, выбираемый по умолчанию для SQL Server.

Управляйте настройками зоны атаки. После первоначального уменьшения зоны атаки необходимо управлять ее настройками. В SQL Server 2005 появился диспетчер зоны атаки Surface Area Configuration Manager, доступный также из командной строки (sac.exe). Однако с помощью этого инструмента можно выполнять только самые распространенные задачи управления (например, включать удаленные соединения и поддерживаемые протоколы). Для более редких задач (таких, как назначение учетных записей службы и режима проверки подлинности) необходимо задействовать диспетчер SQL Server Configuration Manager, системную хранимую процедуру sp_configure или инструменты Windows (например, Windows Management Instrumentation, WMI).

В SQL Server 2008 диспетчер зоны атаки заменен системой управления на основе политик. С помощью этой системы можно управлять настройками всей зоны атаки.

На экране 2 показаны примеры политик зоны атаки, используемых системой управления. Каждая политика содержит условие и целевой объект, к которому применяется это условие. Система отслеживает целевой объект, проверяя его соответствие условию. Можно даже отменить изменения, нарушающие условие.

 

Использование системы управления на основе политик для управления настройками зоны атаки
Экран 2. Использование системы управления на основе политик для управления настройками зоны атаки

Управление доступом

Управление доступом в SQL Server не ограничивается предоставлением разрешений пользователям. Управление доступом охватывает следующие задачи.

Настройка проверки подлинности. По возможности следует использовать только проверку подлинности Windows.

Настройка административных учетных записей. Требуется удалить учетную запись \BUILTIN\

Administrators и отключить учетную запись с правами системного администратора (sa). Обычно следует строго ограничить круг пользователей, наделенных полномочиями системного администратора, и задействовать серверные роли для привилегированных пользователей, которым нужно решать определенные задачи на уровне сервера, например операторов резервного копирования или администраторов безопасности. Пока невозможно ограничить разрешения пользователей с правами системного администратора, но их можно контролировать с помощью средств аудита SQL Server.

Требуется также ограничить членство в группе локальных администраторов. Локальный администратор может получить доступ к компьютеру SQL Server и предоставить права системного администратора самому себе. Сделать это незаметно трудно, но можно. Для защиты сервера, на котором размещается SQL Server, должны применяться столь же строгие меры, как для безопасности самого экземпляра SQL Server.

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

Если SQL Server запускается на операционной системе, предшествующей Windows Server 2008 или Windows Vista, то оптимальный вариант — задействовать в качестве учетных записей служб не пользовательские учетные записи домена. Такая учетная запись не связана с реальным пользователем. Реальные пользователи часто имеют разрешения на многих компьютерах, и важно сократить полномочия учетных записей служб. Не пользовательская учетная запись домена должна иметь корректный пароль и быть управляемой, но обычно она не связана с почтовым ящиком.

Не следует использовать встроенные системные учетные записи Windows (например, LocalService, LocalSystem) в качестве учетных записей служб SQL Server, так как встроенные системные учетные записи наследуют определенные повышенные полномочия в Active Directory (AD), которые не требуются для SQL Server. Например, учетной записи Network Service разрешено проходить проверку подлинности в сети с использованием учетной записи компьютера, а учетной записи LocalSystem разрешено создавать и удалять собственные имена участника-службы (SPN).

Если SQL Server запускается на Windows Server 2008 или более новой версии либо на Windows Vista или более новой версии, то по умолчанию для доступа к локальным ресурсам используются идентификаторы безопасности, назначаемые каждой службе в отдельности. Этот идентификатор безопасности назначается службе, созданной для управления доступом к объектам для изолированных служб. Он не привязан к отдельным учетным записям и не может использоваться ни одной службой, кроме конкретной службы, для которой был создан. Некоторые компоненты (например, xp_cmdshell, задания SQL, выполняемые с правами системного администратора) вместо идентификатора SID используют для доступа к удаленным ресурсам, таким как другой сервер, учетную запись службы. В результате по-прежнему важно правильно настраивать учетные записи для служб.

При назначении разрешений учетным записям служб SQL Server следует всегда руководствоваться правилом наименьших привилегий. В общем случае следует добавить учетную запись службы к подходящей локальной группе, созданной специально для каждого компонента SQL Server. Это позволяет учетной записи службы наследовать любые необходимые разрешения на уровне Windows. Назначение разрешений группе вместо учетной записи службы гарантирует, что разрешения не будут потеряны при изменении учетной записи службы. Кроме того, у старой учетной записи службы не сохранятся разрешения, которые ей больше не требуются.

Если учетной записи службы необходимы дополнительные разрешения, их нужно назначить соответствующей локальной группе SQL Server, а не непосредственно учетной записи службы. Среди прав, часто назначаемых учетным записям служб, — Lock Pages in Memory, чтобы предотвратить усечение памяти, управляемой SQL Server, и Perform Volume Maintenance Tasks, чтобы включить мгновенную инициализацию файлов. Эти два широко применяемых разрешения можно назначить с использованием редактора групповой политики.

В Windows или NTFS для учетных записей служб SQL Server не требуется никаких дополнительных разрешений, кроме унаследованных через членство в соответствующей группе. Никогда не вводите учетные записи служб в группу локальных администраторов.

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

Создание групп безопасности. Не следует предоставлять доступ к SQL Server отдельным пользователям. Вместо этого создайте в AD группы безопасности для конкретных серверов и наборов разрешений, а затем вводите индивидуальных пользователей в соответствующие группы по мере необходимости. Управлять группами безопасности должны администратор базы данных или группа эксплуатации. Часто в компаниях используется инструмент, с помощью которого члены группы эксплуатации могут вносить изменения (например, добавить пользователя) в группу безопасности, но владелец группы должен одобрить изменение или отменить его. Недопустимо разрешать добавление в одну из групп безопасности объектов, находящихся вне контроля оперативной группы, так как в этом случае теряется возможность увидеть членов группы и управлять добавлением и удалением пользователей.

Назначение схем и владение объектами. Если пользователям без прав системного администратора нужно напрямую управлять определенными частями производственной базы данных, следует отделить соответствующие объекты от всех других объектов. Лучший способ это сделать — поместить управляемые пользователями объекты в специальную схему и предоставить разрешения на уровне схемы. Отдельные пользователи и группы не должны владеть схемой dbo или объектами в ней.

Не следует включать межбазовые цепочки владения. Если они включены, могут возникнуть ситуации, при которых пользователь непреднамеренно получит разрешения для объектов, находящихся в базе данных, отличной от текущей.

Отдельные пользователи не должны владеть базами данных. Пользователь, которому разрешено быть владельцем базы данных, автоматически сопоставляется dbo, что приводит к обходу проверки разрешений в базе данных. Этот уровень полномочий нельзя отозвать или отменить, если не изменить владельца базы данных. Кроме того, если владелец базы данных — нелегитимный пользователь, можно получить неожиданные и трудно поддающиеся диагностике сбои разрешений в базе данных. Если отключить учетную запись системного администратора и межбазовые цепочки владения, учетную запись системного администратора можно назначить владельцем всех баз данных, безо всякого риска.

Один из вариантов — всегда отключать параметр Trustworthy. Этот параметр часто используется, чтобы упростить запуск кода CLR с разрешениями EXTERNAL_ACCESS или UNSAFE в базе данных. Он также разрешает процедуры и функции, в которых используется передача полномочий для выполнения функций серверного уровня. В сущности, параметр Trustworthy сообщает экземпляру сервера, что системный администратор доверяет владельцу базы данных. Этого можно добиться, не включая параметр Trustworthy, если подписать программный код или модуль с использованием сертификата.

Высший приоритет

Первоочередная задача администратора базы данных — защита экземпляров SQL Server и содержащихся в них данных. Укрепление SQL Server путем уменьшения зоны атаки и управления доступом — важный элемент защиты сервера. Приемы, описанные в данной статье, помогут защитить экземпляр SQL Server и ваши данные.

Роберт Дэвис (rodav@microsoft.com) — менеджер программы SQL Server Master Certification в Microsoft. Имеет сертификат SQL Server 2008 Certified Master