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

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

Формирование защищенной среды

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

Разумеется, следует подумать о физической безопасности системы: типичный пример пренебрежения физической безопасностью — это когда пользователь теряет свой ноутбук в аэропорту. Тем не менее большинство элементов физической безопасности серверной базы данных формируется в то время, когда администратор настраивает соответствующий сервер в запертом помещении серверного зала. Фактически контактная зона для атаки системы определяется параметрами сети; именно поэтому рекомендуется в процессе создания простого Web-узла устанавливать базу данных на отдельном сервере. Если система безопасности Web-сайта взломана, теоретически все файлы, размещенные на этом сервере, могут быть доступны для внешних пользователей. Поэтому, если база данных расположена на том же сервере, что и Web-сайт, файлы базы данных могут оказаться без защиты.

В идеале для обслуживания базы данных следует применять выделенный сервер. Если разработчик может «втискивать» в единую среду максимально возможное число различных ролей и функций, в производственной среде — или даже в тестовой среде — преследуется другая цель: каждый сервер должен быть сосредоточен лишь на одной роли. Пример: контроллер домена (Domain Controller, DC) не следует наделять функциями сервера баз данных, а Microsoft Exchange не нужно устанавливать на том же сервере, где выполняется система SQL Server. На предприятиях малого и среднего бизнеса многие из этих приложений и служб могут размещаться на одной физической системе, однако в больших организациях некоторые из этих индивидуальных серверных ролей могут устанавливаться на нескольких физических машинах. Главная идея данной статьи не в том, что, с учетом потребностей базы данных, вы можете успешно разместить ее в виртуальной среде, а в том, что, выделив «машину» для выполнения роли сервера баз данных, вы можете более надежно защитить свою среду SQL Server.

Предоставление разрешений через учетные записи служб

Первый этап процесса создания защищенной среды состоит в том, чтобы организовать защиту доступа к SQL Server средствами базовой операционной системы. Процесс обеспечения безопасного доступа к базе данных предполагает использование двух компонентов: учетных записей, применяемых сервером, и базовой файловой системы, в которой размещаются эти файлы. Когда вы будете устанавливать SQL Server, система предложит ответить на вопрос, какие учетные записи необходимо использовать для выполнения ядра базы данных (исключая записи, ассоциированные с дополнительными компонентами, такими как SSAS и SSRS). Эти учетные записи определяют разрешения, ассоциированные с выполняемым сервером.

В процессе установки нужно определить, какие службы будут выполняться и какая учетная запись (или учетные записи) будут применяться для указания разрешений (авторизации), предоставляемых данной службе. Можно выбрать одну из трех определяемых системой учетных записей: Local System, Network Service и Local Service. Учетная запись Local System имеет весьма широкие полномочия по доступу к локальной системе и не дает права обращаться к ресурсам, расположенным вне локальной системы; использовать такую учетную запись вряд ли имеет смысл, если необходимо обращаться к данным или службам, размещенным в сети. Учетная запись Network Service обеспечивает доступ к сетевым ресурсам, но в плане работы с локальными ресурсами она предоставляет объем полномочий типичного пользователя. Учетная запись Local Service подобна записи Network Service в том отношении, что применительно к локальной системе она предоставляет тот же объем прав, который имеет типичный пользователь. Однако в отличие от записи Network Service данная учетная запись не дает разрешений на работу с сетевыми ресурсами и ничего не передает внешним сетевым ресурсам.

Итак, вопрос: какие из этих учетных записей нужно использовать? Правильный ответ: не нужно использовать ни одну из них. Если только вы не заняты созданием среды разработки, следует проигнорировать все три потенциальные системные учетные записи и создать пользовательскую учетную запись в домене или в локальной системе. Отметим, что сказанное справедливо для ядра реляционной базы данных и для других подсистем — таких, как SQL Server Analysis Services (SSAS) и SSRS. Создав одну или несколько учетных записей, можно получить именно те разрешения, которые нужны, и откорректировать эти разрешения в соответствии со своими потребностями. Хотя вы можете первоначально создать доменную учетную запись с правом доступа к локальной машине, позднее можно изменить разрешения, если данная учетная запись понадобится для того, чтобы обращаться к файлам на другой системе. Если доступ к таким файлам был нужен только в течение некоторого времени, можно предоставлять и отзывать эти разрешения, а поскольку данная учетная запись будет выполняться только применительно к SQL Server, вы можете быть уверены, что не будете при этом влиять на функционирование других служб. Разумеется, по этой причине у вас будут основания для того, чтобы создать отдельную учетную запись для каждой из служб, задействованных в установленных вами базах данных.

Защита файлов баз данных

После того как вы создадите настраиваемые учетные записи и предоставите им разрешения на доступ к файловой системе, а также к папке, где будут храниться файлы базы данных, перед администратором встанет следующая задача — защитить эти файлы. Часть решения этой задачи состоит в том, чтобы следовать рекомендации — связывать эти файлы с сервером, выделенным для выполнения служб базы данных. При этом нужно учитывать два обстоятельства: во-первых, имеется ряд связанных с производительностью вопросов, относящихся к борьбе за ресурсы сервера со стороны различных служб/приложений, которые тоже следуют передовой практике повышения производительности путем выделения сервера под SQL Server. Во-вторых, упомянутые файлы должны располагаться в сети устройств хранения данных, не являющейся частью данного сервера. В любом случае эти файлы являются ядром объекта, который вы пытаетесь защитить от несанкционированного доступа. Лицо, скопировавшие эти файлы, в сущности, сможет скопировать вашу базу данных и в конечном итоге открыть ее на другом сервере баз данных.

Обеспечение безопасности сети

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

Как показано на рисунке, обращенные к Internet приложения можно располагать в одном (или нескольких) сетевых сегментах, внутреннюю сеть компании — на отдельном сетевом сегменте, и опять-таки на особом сетевом сегменте — сервер или серверы баз данных.

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

Как мы видим, на рисунке отображены две точки подключения к Internet. Первая — это Web-серверы, обеспечивающие анонимный доступ. Но внутренняя сеть, представляющая собой вторую точку подключения, содержит системы корпоративных пользователей, и все они предполагают применение доступа к ресурсам сети, не говоря уже о том, что пользователи могут брать свои ноутбуки домой и подключаться к сети извне по общедоступным сетям. В сущности, это подключение превращается во второй вектор атаки для лиц, пытающихся получить несанкционированный доступ к базе данных.

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

Когда вы определитесь с сетевой структурой, нужно будет открыть некоторое количество портов для обращения к данным на основе выбранной стратегии доступа к данным. Так, если для работы по протоколам http:// и https:// Web-сайты обычно используют порты 80 и 433, SQL Server для осуществления входящих соединений, как правило, применяет порты 1433 и 1434. Поэтому есть все основания надеяться, что тот инструмент, с помощью которого злоумышленники воспользовались брешью в защите IIS для внешнего сетевого экрана, окажется бесполезным для преодоления следующего экрана, который не поддерживает трафик, адресованный IIS. Такое смещение портов и протоколов между внешними Web-серверами и базой данных обеспечивает дополнительный уровень защиты от непрошеных гостей, пытающихся напрямую обращаться к файлам баз данных.

Шифрование данных на диске

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

В системе SQL Server 2008 Enterprise Edition реализована функция прозрачного шифрования данных Transparent Data Encryption (TDE), которая позволяет указывать, что вся база данных должна быть зашифрована на диске. TDE позволяет брать существующую базу данных и направлять системе SQL Server запрос на шифрование данных на диске, не требуя от приложения каких-либо изменений. Затем движок базы данных организует трансляцию между зашифрованными данными на диске и дешифрованными данными, возвращенными приложению. Существует возможность моделировать эту функцию с помощью файловой системы Encrypting Files System (EFS) или средствами шифрования диска BitLocker Drive Encryption. Не забывайте, что, хотя продукт BitLocker, возможно, является наилучшим решением для большинства сценариев работы с использованием системы SQL Server 2005, он шифрует только данные, находящиеся «в состоянии покоя». Данные не шифруются, когда сервер работает в обычном режиме. Описание процесса настройки средств шифрования содержимого баз данных выходит за рамки настоящей статьи. Более подробные данные о TDE можно найти в документе Microsoft «Database Encryption in SQL Server 2008 Enterprise Edition» (http://msdn.microsoft.com/en-us/library/cc278098.aspx).

Защищенная среда баз данных

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

Уильям Шелдон (bsheldon@interknowlogy.com) — ведущий инженер компании InterKnowlogy, имеет сертификаты MCSD и MCP+SiteBuilding

Рисунок. Безопасная сегментация сети