При планировании обеспечения безопасности компьютерной системы, базирующейся на MS SQL, Вам необходимо уделить особое внимание нескольким элементам: соответствующей установке с правами доступа, установленным правилам для пользователей MS SQL и механизму регистрации всех действий в базе данных для того, чтобы в случае возникновения каких-либо проблем администратор мог быстро и без особых усилий определить причины их появления. Кроме того, не следует забывать о том, что Вам необходимо задать план выполнения чрезвычайных действий, таких как: восстановление данных и их перенос на другой сервер, а также их последующее тестирование.
Установка
Сервер MS SQL устанавливается в том же порядке, что и любое другое программное обеспечение Windows: программа установки проводит пользователя шаг за шагом через все пункты. Если установку необходимо выполнить более чем на один компьютер, то программа поможет создать файл, который обеспечит автоматическое выполнение всего процесса установки. Все Ваши последующие изменения в файле ISS можно сохранять, выбирая пункт Расширенные опции (Advanced Options) и, затем, файл Record Unattended .ISS, что показано на экране первой установки. Когда подобный файл уже создан, все, что Вам необходимо сделать для обеспечения успешной установки, заключается в следующем:
Setupsql.exe –s –f1 Путь к файлу [-SMS]
Опция SMS определяет, что контроль будет передан в командную строку не ранее, чем по окончании процесса установки. Таким образом, весь процесс будет передан в управление командному файлу с установкой всех сервисов и баз данных в самом конце. Установка патчей также может быть «механизирована» подобным образом.
SQL Server Desktop Engine имеет ту же функция с тем лишь отличием, что вместо написания файла ISS, Вам необходимо задать все соответствующие параметры в командной строке.
Сервер SQL и Сервер агент SQL запускаются в соответствии со своим наименованием в сервисах Windows: MSSQLserver по умолчанию (либо MSSQL$имя в случае наличия заданного имени) и SQLServerAgent. Как и многие другие сервисы, они должны быть запущены при определенной учетной записи Windows. Учетная запись может быть создана как для «обычного» пользователя с интерактивными правами доступа так и для специальных пользователей с ограниченными правами авторизации. Вам следует позаботиться о создании соответствующей учетной записи до установки Сервера SQL, чтобы установочное программное обеспечение дало соответствующие права пользователю на запуск всех сервисов.
Учетная запись, при которой будет запущен Сервер SQL, должна обеспечивать следующие права:
Кроме того, должен быть обеспечен доступ и возможность видоизменения следующих файлов и директорий:
Также необходимо право на написание следующих регистрационных ключей:
После установки учетная запись запуска Сервера SQL должна быть добавлена в роли Системного администратора (sysadmin). Вам следует также подумать о лишении прав администраторов Windows на начало работы и уступки данного права специальной учетной записи Сервера SQL. Для того, чтобы отменить авторизацию, Вам необходимо выполнить следующее:
exec sp_revokelogin [BUILTIN\Administrators]
Если в ходе установки вы выбрали интеграционный режим, то учетная запись sa по умолчанию останется с пустым паролем. Администратору, тем не менее, будет выдан запрос о вводе пароля для данной учетной записи при установке SP3.
При выборе протоколов будет полезно выключить TCP/IP, если они не являются обязательными, и использовать только протоколы Именованных Каналов. Необходимо помнить, что, хотя, многопротокольность допускает зашифровку, при этом используется механизм Windows RPC и это позволяет осуществлять соединение с SQL по умолчанию.
Файлы базы данных SQL могут быть не сжатыми; тем не менее, возможно использование Системы шифровки файлов Windows Encrypted File System (EFS) по отношению к ним. Это даст Вам дополнительную защиту (не считая Список контроля доступа ACL) от неустановленного копирования файлов с сервера. Microsoft утверждает, что единичная зашифровка файлов MDF и LDF не замедляет базу данных более, чем на 5%, так что вам следует хорошенько задуматься об использовании данного средства.
Не забудьте установить все патчи, обновления и дополнительные пакеты HotFix (если последние доступны) по окончании процесса установки Сервера SQL. В момент написания настоящей статьи последним обновлением было SP3.
Права доступа
В Серверах SQL пользователь входит непосредственно на сервер. Затем, пользователь в зависимости от принадлежности к определенной секции базы данных направляется к специальному распределителю ID. Пользователь может иметь права доступа на уровне как сервера, так и определенной секции базы данных.
Сервер имеет набор заранее установленных встроенных ролей, которые соотносятся с базой данных в целом, т.е. ролей, относящихся ко всему серверу и к отдельным его частям.
Установленные роли, о которых необходимо упомянуть, следующие:
Встроенные роли следующие:
Необходимо отметить, что посредством использования последних четырех ролей вы можете обойти все приложения для непосредственного доступа к таблицам с данными и в принудительном порядке заставить систему выполнять все необходимые операции по чтению и написанию данных в обход установленных ограничений.
Пользователь может иметь право на выполнение определенных операций, но может не иметь права на выполнение отдельно взятых частей конкретной операции. Это способ выполнения особых проверок перед написанием баз данных.
Роли сервера являются не чем иным, как трафаретами, определяющими определенные установки авторизации. Вместо использования ролей вы можете составить список соответствующих прав вручную.
Вы должны также учитывать и то, что если пользователь привязан к определенной роли, с определенными правами, и к другой роли, в которой подобные права отсутствуют, то Сервер SQL не сможет выполнить заданную операцию. Подобная ситуация наглядно представлена на Рисунке 1.
Рисунок 1
Параметры авторизации устанавливаются с использованием команд TSQL, как GRANT/REVOKE, либо посредством специальных операций (что указано в документации в секции Операции по безопасности). Можно также использовать интерфейс Enterprise Manager, где у администратора имеется табличка с определенными правами исполнения.
Следует запомнить также и то, что если администратор хочет немедленно удалить пользователя SQL, ему следует перезапустить соответствующий Сервер SQL.
По умолчанию пользователь оказывается не уполномоченным на исполнение операций UPDATE/INSERT, т.е. на непосредственное изменение системных таблиц. Вы должны убедиться в том, что разрешающая опция установлена на 0. Кроме того, необходимо помнить, что в случае установки соответствующей опции на 1 и создании операции сохранения, последняя позволит обновлять системные таблицы даже при блокировке непосредственного доступа к их редактированию.
Внимание: изменение обновление (1) требует незамедлительного выполнения операции Реконфигурации с подменой (RECONFIGURE WITH OVERRIDE).
Вы также хорошо знаете, что администратор иногда для пущей наглядности любит производить все изменения в системных таблицах вручную. В таком случае запуск сервера лучше осуществлять в таком режиме, при котором база данных доступна лишь для единичного пользователя. Для этого Вам необходимо лишь выбрать соответствующую опцию в SQL Server Enterprise Manager, либо же запустить sqlserv.exe –m.
В режиме «единичного пользователя» только первый пользователь получит доступ к Серверу SQL, поэтому перед включением указанного режима Вам следует обеспечить надежную блокировку Агента Сервера SQL для того, чтобы текущие операции не вызвали вторичную блокировку единственно возможного соединения.
Проверка
Даже после безопасной установки Сервера SQL администратор должен знать, что происходит в его базе данных. Для этого может быть использован встроенный сервис «Проверка» (audit), который служит для регистрации событий, связанных с подключением пользователей. Для подключения соответствующего устройства вам необходимо войти в Свойства Сервера SQL и перейти к вкладке Безопасность. Все события по умолчанию будут сохранены в двух местах: в журнале учета Сервера SQL и в журнале учета Приложений Windows. По умолчанию выбирается нулевой уровень сохранения, что значит, что никакая информация в текущий момент регистрации не подлежит. Если Вы выберите опцию «Успешное» (Success), то все успешные подключения будут подлежать регистрации. Если же вы выберите опцию «Неудача» (Failure), то регистрации будут подлежать все ошибки при подключении к серверу. Опция «Все» (All) будет способствовать регистрации всех событий. Для ввода изменений в действие Вам следует перезапустить сервисы.
Во многих случаях регистрация событий, подключений и отключений недостаточна. Администратор часто хочет знать, в каких именно целях используется Сервер SQL; то есть, узнать, какие команды отсылаются в базу данных.
Сервер SQL может быть сконфигурирован так, чтобы отвечать всем требованиям сертификата безопасности C2. Тем не менее, представляется возможным обеспечить проверку C2 независимо от установки сертификата. Подобная проверка позволит администратору узнать детали выполнения всех операций в базе данных.
Для выполнения проверки C2 Вам необходимо активировать следующее (в Query Analyzer либо osql.exe):
EXEC sp_configure ‘дополнительные опции’, ‘1’
go
RECONFIGURE
go
EXEC sp_configure ‘режим проверки c2′,’1’
go
RECONFIGURE
Проверка C2 будет запущена после рестарта сервиса.
Регистрируемые события следующие:
Информация о различных событиях, включая зарегистрированные, разнится друг от друга. Следующая информация подлежит обязательному занесению в регистрационный журнал:
Рисунок 2: Контрольный журнал C2.
Функция копирования SQL поддерживает «прокрутку» файлов при превышении их размера 200 MB. Создается новый файл, имя которого создается по следующей схеме: “MSSQLимя\Data\audittrace_yyyyMMddhhmmss.trc”. В случае ошибки Вы не потеряете более чем 128kB контрольного журнала. Если места недостаточно, то проверка будет остановлена автоматически. При функционировании сервиса последние 200-MB файла блокируются сервером SQL. После его заполнения (либо остановки сервиса) исчезает возможность быстрого просмотра.
Регистрация всех операций в базе данных с помощью C2 довольно дорогостояща. Однако, она дает Вам глубокий взгляд на сущность процессов, происходящих в системе. Еще один способ, которым вы можете воспользоваться—определить приемлемые для Вас установки проверки вместо использования C2. для этого Вам необходимо всего лишь воспользоваться инструментом SQL Server Profiler, который позволит задать параметры для тех событий, которые интересны для Вас, установить соответствующие фильтры для того, чтобы, к примеру, отображать только данные первичной важности. Для повышения Ваших навыков владения этим инструментом Вам необходимо прочитать главу “Контроль категорий событий с SQL Profiler” в документации Сервера. Данная глава содержит сравнительно подробное описание элементов регистрации. Так Вам необходиом взглянуть на процессы, сохраняемые в sp_trace_* , которые позволят осуществить те же процедуры, что и с пользовательского интерфейса (проверка, регистрация). На Сервере SQL вы также можете выбрать опцию конфигурирования определенных операций после подключения сервисов. В SQL 6.x функция, ответственная за это, называется sp_makestartup. В SQL 2000 вы можете использовать sp_procoption:
EXEC sp_procoption ‘Операция’, ‘startup’, ‘true’
После выполнения указанной команды Операция будет запущена автоматически после старта Сервера SQL. Если код операции содержит команду проверки, то проверка будет выполнена совместно с конфигурированием базы данных без необходимости активирования SQL Server Profiler GUI.
Рисунок 3: Список события Сервера SQL
SQL Server Profiler является также инструментом для проведения анализа результатов проверки. Он также позволяет сохранять все соответствующие результаты в табличном формате м одной из секций базы данных Сервера SQL. Вам лишь необходимо выбрать опцию Сохранить Как… во вкладке меню Файл. Вам также можно использовать TSQL для анализа контрольного журнала.
Проверка — довольно мощный инструмент, позволяющий администратору находить значительные неисправности в системе. С другой стороны, проверка C2 содержит всю информацию из базы данных, потеря которой может иметь самые серьезные последствия. Поэтому файлы проверки должны храниться с особой тщательностью.
Резервирование/Восстановление
Следует заострить внимание на таком серьезном моменте, как восстановление данных из резервного файла. Вы не должны позволять пользователям сохранять иные базы данных кроме их собственных. Если лицо, не являющееся владельцем базы данных, открывает ее, то последняя станет недоступной для истинного пользователя. Такие ситуации встречаются в тех случаях, когда A является владельцем базы данных, а B уполномачивается A на создание резервных копий или восстановления всей базы данных. Если B позволено выполнять функцию Создания (CREATE), и он делает резервную копию базы данных и затем восстанавливает ее, то он становится новым владельцем заново созданной базы, хотя все таблицы будут еще принадлежать A.
Если опция WITH DBO_ONLY включена в выражение (Восстановить базу данных) RESTORE DATABASE, то A (владелец таблицы) не сможет получить доступ к таблицам в сохраненной базе данных, пока он не будет зарегистрирован повторно с использованием DAC. При восстановлении баз данных на удаленном сервере необходимо выполнить следующее:
EXEC sp_change_users_login ‘Auto_Fix’
Или
EXEC sp_change_users_login ‘Update_One’, ‘account’, ‘newAccount’
Этим будет обеспечено соединение между паролем входа на сервер и учетной записью пользователя, которая сохранена в базу данных. Другими словами, Вам придется восстановить все учетные записи пользователей. Если вы используете Сервер SQL на Операционной системе Сервер Windows 2003, то в Вашем распоряжении существует механизм Точной копии (Shadow Copy). Это позволит Вам создать копию всей секции, включая блокированные файлы MDF/LDF. Однако это сработает лишь в том случае, если режим восстановления базы данных на является Полным, а установлен на Простой, при котором все входные сообщения автоматически отсекаются. Патч, доступный через PSSS, устраняет это неудобство.
Мультисекции с одновременным исполнением
Иногда в силу выбора использования бизнес-модели (хостинг с «разделенными» серверами) либо из мотивов обеспечения безопасности несколько экземпляров Сервера SQL используются одновременно на одном физическом сервере. При стандартной процедуре установки они совместно разделяют ресурсы общего сервера. Существуют некоторые преимущества данного метода: система самостоятельно обеспечивает доступ каждой составляющей к ресурсам сервера. Тем не менее, некоторые соглашения по хостингу требуют того, чтобы часть ресурсов была закреплена за определенной секцией сервера. В ходе конфигурирования сервисов Сервера SQL Вы можете установить максимальный объем памяти и «привязки» базы данных к рабочим юнитам системы. Для конфигурирования вы должны выполнить следующее:
EXEC sp_configure ‘показать расширенные опции’, ‘1’
go
RECONFIGURE
go
sp_configure ‘максимальный объем памяти сервера’, 256
go
RECONFIGURE
go
EXEC sp_configure ‘маска’, 12
go
RECONFIGURE
Go
Рисунок 4: Мультисекции с одновременным исполнением на Small Business Server 2003
Сервер SQL рассматривает HyperThreading CPU как две процессорные системы. Другими словами, если у Вас есть сервер с технологией 2-CPU HT, то SQL будет видеть четыре CPU. Установка указанных опций не будет ограничивать возможность использования совместных ресурсов. Различные секции используют единые каналы I/O, единые секции операционной системы, единый системный интерфейс и т.д. Ресурсы, способные вызвать конфликт в системе (память, CPU и драйвера) исключаются из совместного пользования, так что вы можете быть уверены в том, что программное обеспечение определенной секции не будет влиять на работу другой.
Надежные и безопасные приложения
Даже самый безопасный сервер должен сохранять полную функциональность и поддерживать приложения к базе данных. Следует позаботиться не только об обеспечении безопасности сервера, но и о его полной работоспособности и надежности. Под словом «надежность» понимается не работа Сервера SQL 24 часа по 7 дней в неделю, а то, что специальные возможности (т.е. приложение, использующее инфраструктуру) доступны всегда или недоступны только в такой короткий промежуток времени, что пользователи не успевают этого заметить. Три фактора имеют самое значительное влияние на установку приложений:
Давайте более детально взглянем на статистику, описывающую различные причины поломок. Корпорация Microsoft утверждает, что 40% ошибок кроется непосредственно в самом приложении (плохое тестирование, ограниченные возможности отчета об ошибках, плохая масштабируемость). Хорошей технологии оказывается недостаточно; Вам необходимо знать, каким образом обеспечить максимальное соответствие приложения Вашим нуждам. Следующие 40% ошибок относятся к ошибкам администратора (недостаток операционных моделей для чрезвычайных ситуаций, отсутствие безопасного восстановления и т.п.). Последние 20% являются базисными, т.е. вызваны операционной системой, маршрутизаторами, сетевыми соединениями и т.д. Пользователя, однако, не волнует, чем именно вызвана ошибка, поскольку любая ошибка означает, что приложение становится недоступным. Если вы заботитесь о высокой надежности работы, то первым делом следует задуматься об использовании Microsoft Cluster Service, который сосредотачивает так называемые «над-ошибочные» кластеры (в случае ошибки MSCS переводит приложение на другой узел). Если смотреть на происходящее глазами пользователя, то никаких изменений в работе не происходит вообще, поскольку имя Сервера и адрес IP остаются неизменными. Тем не менее, сам процесс переключения занимает порядка 30 секунд. Что же представляет собою данное «Переключение»?
«Переключение» обозначает перевод выполняемых операций на другой компьютер; соединения оказываются разорванными, а возможность перехода — отмененной. Данные подлежат пересылке, а все входные сообщения подлежат переработке на новом узле. Объем работы зависит от величины времени, которое прошло, начиная с последнего момента проверки входящих сообщений. Если прерванное сообщение было «долгим», и проверка проводилась довольно давно, то переключение занимает около 30 секунд.
Другой способ — использование механизма LogShipping, который гораздо легче в использовании. Вы можете составить схему посыла журнала транзакций на другой сервер с использованием программы Database Maintenance Plan Wizard. Уточненный график событий составляется по умолчанию каждые 5 минут, но в некоторых случаях Вы можете отсылать его каждую минуту. Следует заметить, что при использовании подобного устройства синхронизации, Вам необходимо позаботиться об оборудовании механизма передачи недостающих данных на Сервер в случае возникновения ошибки. Еще один способ создания «зеркального сервера» — механизм репликации (например, Snap Shot). Однако наиболее удобными в пользовании оказываются механизмы передачи системных журналов.
Вы можете спросить, почему MSCS превосходит Log Shipping? Во-первых, время переключения MSCS довольно коротко и, к тому же, здесь отсутствует необходимость передачи некоторых данных вручную. В других ручных механизмах синхронизации наиболее удобным способом передачи оказывается повторный ввод данных пользователем. Кроем того, приложение должно «предвидеть» изменение адреса и имени сервера. Такие способы обладают своими преимуществами, поскольку существуют серверы, предназначенные только для чтения, информация на которых всегда обновляется и которые могут быть использованы (если процесс работы отлажен хорошо) для аналитических операций.
Вам должно быть известно, что Yukon (другая версия Сервера SQL) будет оснащен механизмом с автоматическим процессом создания сервера для восстановления с использованием Log Shipping. Тем не менее, несмотря на безопасность Вашего Сервера SQL и его базиса, самым пагубным и, в то же время, «легализированным» элементом этой системы является персональный пользователь, вместе с ошибочным приложением и недостатком системы планировки и моделей выполняемых процессов.
Источник www.windowsecurity.com
Tags: analyze, mac, MS SQL, nat, quote, SQL, SQL Server
