MSSQL и безопасность

Установка

MS SQL Server устанавливается так же, как и любое другое программное обеспечение Windows — установочное программное обеспечение проводит администратора через процедуры установки. Однако, если установка должна выполняться более одного раза на нескольких машинах, было бы полезно создать файл, который сделает все необходимые операции автоматическими. Выбор «Дополнительных параметров» и «Запись файла.ISS без присмотра» на первом экране установки позволит вам сохранить все ваши последующие варианты выбора в файле ISS. Когда такой файл создан, все, что вам нужно сделать для правильной установки, это ввести:

Setupsql.exe -s -f1 путь к файлу [-SMS]

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

SQL Server Desktop Engine аналогичен, и единственное отличие состоит в том, что вместо записи файла ISS вы должны определить все параметры в командной строке.

SQL Server и агент SQL Server запускаются как службы Windows с именами: MSSQLserver в случае экземпляра по умолчанию (или MSSQL$instancename в случае именованного экземпляра) и SQLServerAgent. Как и любые другие службы, они должны запускаться под определенной учетной записью Windows. Эта учетная запись должна быть «обычной» учетной записью пользователя с разрешением на интерактивный вход в систему или даже специальной учетной записью с очень ограниченными полномочиями. Перед установкой SQL Server следует подумать о создании надлежащей учетной записи, чтобы программа установки предоставила пользователю соответствующие права, позволяющие ему запускать службу.

Учетная запись, под которой запускается SQL Server, должна иметь следующие права:

• Для запуска в составе ОС
  
• Для увеличения доли
  
• Чтобы заменить токен уровня процесса
  
• Вход в качестве службы

Кроме того, ему должен быть разрешен доступ и изменение файлов и каталогов, таких как:

• каталог SQL-сервера
  
• файлы базы данных, т.е. .mdf,.ndf и .ldf (обычно обычные файлы mdf, содержащие данные, находятся на другом диске, чем файл .ldf, содержащий журнал базы данных).

Кроме того, необходимы права на запись следующих ключей реестра:

• HKEY_LOCAL_MACHINESoftwareMicrosoftMSSQLServer $имя_установки,
  
• HKEY_LOCAL_MACHINE SystemCurrentControlsetServicesMSSQLServer $instancename,
  
• HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionPerflib.

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

exec sp_revokelogin [ВСТРОЕННЫЕАдминистраторы]

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

При выборе протоколов было бы хорошо отключить TCP/IP, если это не является обязательным, и использовать только протокол Named Pipes. Вы должны помнить, что даже несмотря на то, что Multi Protocol поддерживает шифрование, он использует механизмы Windows RPC и, кроме того, позволяет обмениваться данными только с экземпляром SQL по умолчанию.

Файлы базы данных SQL нельзя сжимать, но к ним можно применить зашифрованную файловую систему Windows (EFS). Это дает вам дополнительную, помимо ACL, защиту от несанкционированного «копирования» файла с сервера. Microsoft утверждает, что обычное шифрование файлов MDF и LDF не замедляет работу базы данных более чем на 5%, поэтому в случае информации, которую вы считаете критической, вам следует рассмотреть возможность использования этого устройства.

Не забудьте установить все исправления, обновления и дополнительные пакеты исправлений (если они доступны) после завершения установки SQL Server. На момент написания SP3 был последним обновлением.

Права доступа

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

Сервер имеет предопределенные встроенные роли, которые применяются ко всему экземпляру базы данных, т. е. к фиксированной роли сервера, а также к тем, которые привязаны к указанной базе данных.

Стоит упомянуть следующие фиксированные роли:

• sysadmin — разрешено выполнять любые операции
  
• dbcreator — разрешено создавать базы данных
  
• bulkinsert — разрешено выполнять так называемые операции вставки (BULK), используемые для добавления больших объемов данных, например, при поставке хранилища данных.

Встроенные роли базы данных:

• public — набор авторизаций по умолчанию
  
• db_owner — разрешено выполнять любые операции с указанной базой данных
  
• db_oddladmin — разрешено создавать или изменять новые объекты базы данных (так называемые операции DDL); вы должны принять к сведению тот факт, что пользователю не нужно иметь авторизацию db_owner для этого
  
• db_datareader — разрешено читать любую таблицу
  
• db_datawriter — разрешена запись в любую таблицу
  
• db_denydatareader — запрещено читать таблицы (явная авторизация на вынос)
  
• dDb_denydatawriter — запрещено писать таблицы

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

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

Роли сервера — это не что иное, как некоторые виды шаблонов, которые определяют определенные наборы авторизаций. Вместо использования ролей вы можете назначить нужные права вручную.

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

фигура 1

Авторизация настраивается с использованием команд TSQL, таких как GRANT/REVOKE, или с помощью дополнительных хранимых процедур (как указано в документации в разделе «Процедуры безопасности»). Можно использовать интерфейс Enterprise Manager, в котором администратор имеет в своем распоряжении «таблицу» с определенными правами.

Еще одна важная вещь, о которой следует помнить, это то, что если администратор хочет немедленно удалить пользователя SQL, ему придется перезапустить соответствующий экземпляр SQL Server.

По умолчанию пользователю не разрешено выполнять операции UPDATE/INSERT, т. е. напрямую изменять системные таблицы. Вы должны убедиться, что параметр разрешения обновлений установлен на 0. Кроме того, помните, что когда параметр разрешения обновлений установлен на 1 и была создана процедура хранения, этой процедуре по-прежнему будет разрешено обновлять системные таблицы, даже если возможность прямого модификации будут заблокированы.

Примечание. Изменение разрешения обновлений на 1 требует последующего выполнения операции RECONFIGURE WITH OVERRIDE. Эта опция начинает работать сразу.

Вы также должны знать, что иногда администратор, знающий, что он делает, может захотеть вручную изменить что-то в системных таблицах. С такой ситуацией лучше всего справиться, запустив сервер в таком режиме, при котором база данных доступна только для одного пользователя. Для этого просто выберите соответствующую опцию в SQL Server Enterprise Manager или запустите sqlserv.exe -m.

В «однопользовательском режиме» только первый пользователь получит доступ к SQL Server, поэтому перед переводом экземпляра в этот режим следует заблокировать Агент SQL Server, чтобы периодическая операция случайно не заблокировала единственное доступное соединение..

Аудит

Событие после наиболее безопасной установки SQL Server администратор должен быть в курсе того, что происходит в его базах данных. Встроенное устройство аудита можно использовать, например, для регистрации событий, связанных с входом пользователей в систему. Чтобы запустить это устройство, вам нужно войти в свойства SQL Server и перейти на вкладку «Безопасность». События по умолчанию будут сохраняться в двух местах: в журнале SQL Server и в журнале приложений Windows. Уровень «Нет» выбран по умолчанию. Это означает, что никакая информация не регистрируется. Если вы выберете вариант «Успех», будут зарегистрированы все успешные входы в систему. Если вы выберете вариант «Сбой», будут сохранены только данные об ошибках входа в систему. Наконец, опция «Все» вызовет сохранение обоих типов событий. Чтобы применить изменения, вам придется перезапустить службу.

Во многих случаях регистрации событий и входов/выходов недостаточно. Администратору часто хотелось бы точно знать, что именно выполняет указанный SQL Server; это означает, что он хотел бы знать, какие команды отправляются в базу данных.

SQL Server может быть настроен таким образом, чтобы он соответствовал требованиям сертификата безопасности C2. Однако можно включить аудит C2 независимо от создания таких установок. Этот вид аудита позволяет администратору отслеживать детали любой операции, выполняемой в базе данных.

Чтобы настроить аудит C2, вам необходимо активировать (в Query Analyzer или osql.exe ) и запустить следующее:

EXEC sp_configure 'показать дополнительные параметры', '1'

идти

РЕКОНФИГУРИРОВАТЬ

идти

EXEC sp_configure 'режим аудита c2', '1'

идти

РЕКОНФИГУРИРОВАТЬ

Аудит C2 будет запущен после перезапуска службы.

Зарегистрированные и зарегистрированные события:

• Все действия пользователя (т.е. все команды SQL и вход/выход из системы)
  
• Операции DDL (т. е. определение новых объектов в базе данных, изменение авторизации, настройка сервера)
  
• События, связанные с безопасностью (информация о том, разрешил или отказался сервер выполнять определенные операции, а также добавление и настройка учетных записей новых пользователей)
  
• Администрирование операций (создание/повторное создание резервной копии, операции вставки BCP или команды DBCC, используемые для устранения неполадок SQL Server)
  
• Операции, выполняемые на службе SQL Server; следует отметить, что остановка службы будет зарегистрирована только в том случае, если она выполнена изнутри SQL Server; когда служба останавливается через ОС, эта информация содержится только в системном журнале.
  
• Начало/прекращение проверки

Информация по отдельным записям, включая регистрируемые операции, отличается друг от друга. Однако эта информация всегда будет регистрироваться:

• Дата и время начала мероприятия
  
• Домен и имя пользователя, вызвавшего событие
  
• SID пользователя
  
• Тип, класс и подкласс события
  
• Операция прошла успешно или нет
  
• Имя SQL-сервера
  
• Имя хоста отправителя запроса
  
• Имя приложения, переданное в цепочке подключения к базе данных
  
• SPID (идентификатор серверного процесса) подключения пользователя к SQL Server.

Рисунок 2: Журнал аудита C2.

Функция трассировки SQL поддерживает «прокрутку» файла после того, как он превысит 200 МБ. Он создает новый файл, имя которого соответствует следующей схеме: « Имя экземпляра MSSQL Dataaudittrace_yyyyMMddhhmmss.trc». В случае сбоя вы не потеряете более 128 КБ журнала аудита. Если у вас заканчивается место на диске, аудит останавливается автоматически. Когда служба работает, последний файл размером 200 МБ постоянно блокируется SQL Server. Не раньше чем после его заполнения (или остановки услуги) возможность его просмотра пропадает.

Аудит C2, регистрирующий каждую из операций, выполняемых в базе данных, вскоре становится дорогим. Это дает вам всесторонний взгляд на то, что выполняется в системе, но замедляет ее. Еще одна вещь, которую нужно сделать, это указать интересующие вас события и определить свои собственные правила аудита вместо использования аудита C2. Все, что вам нужно для этого, — это инструмент SQL Server Profiler. Этот инструмент позволяет вам указать, какие события вас интересуют, и настроить фильтры, например, чтобы отслеживать только самые важные базы данных. Чтобы улучшить свои навыки работы с этим инструментом, вам следует прочитать главу «Мониторинг с помощью категорий событий SQL Profiler» в документации сервера. Эта глава содержит подробное описание элементов, которые могут быть зарегистрированы в журнале. Вам также следует взглянуть на хранимые процедуры sp_trace_*, которые позволяют выполнять те же операции, что и пользовательский интерфейс, такие как аудит и регистрация операций, и которые являются неотъемлемой частью базы данных. В SQL Server вы также можете настроить определенные хранимые процедуры таким образом, чтобы они запускались при запуске службы. В SQL 6.x функция, отвечающая за это, называлась sp_makestartup. В SQL 2000 вы можете использовать sp_procoption:

EXEC sp_procoption ' Процедура ', 'запуск', 'истина'

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

Рисунок 3: Список событий, отслеживаемых SQL Server

SQL Server Profiler также является инструментом анализа результатов аудита. Это также позволяет сохранить результаты аудита, загруженные в виде таблицы в одну из баз данных SQL Server. Все, что вам нужно сделать, это выбрать опцию «Сохранить как» на вкладке меню «Файл». Эти операции позволяют использовать TSQL для анализа журнала аудита.

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

РЕЗЕРВНОЕ ВОССТАНОВЛЕНИЕ

Стоит обратить внимание на два важных момента, касающихся восстановления данных из файла резервной копии. Вы не должны позволять пользователям восстанавливать базы данных, отличные от их собственных. Если кто-то, кто не является владельцем базы данных, откроет ее, она станет недоступной для владельца. Такие ситуации возникают, когда пользователь А является владельцем базы данных, а пользователь А предоставляет пользователю А полномочия на создание резервной копии или восстановление базы данных. Если пользователю B разрешено выполнять операцию CREATE, и он делает резервную копию базы данных, а затем восстанавливает ее как новую базу данных, он станет новым владельцем базы данных, но таблицы по-прежнему будут принадлежать пользователю A.

Если в выражение RESTORE DATABASE включена опция WITH DBO_ONLY, то пользователю A (владельцу таблиц) не будет разрешен доступ к таблицам в восстановленной базе данных, пока он не будет публично авторизован с помощью DAC. Также следует отметить, что при восстановлении базы данных на удаленном сервере удобно выполнить следующую процедуру:

EXEC sp_change_users_login 'Auto_Fix'

Или же

EXEC sp_change_users_login 'Update_One', 'учетная запись', 'новая учетная запись'

Это свяжет пароли входа на сервер с учетными записями, существующими в восстановленной базе данных. Другими словами – вам придется заново создавать все учетные записи пользователей. Если вы используете SQL Server на ОС Windows 2003 Server, то в вашем распоряжении есть механизм теневого копирования. Это позволяет вам создать копию всего диска, включая заблокированные файлы MDF/LDF. Однако он будет работать только в том случае, если режим восстановления базы данных не установлен на «Полный», а установлен на « Простой режим», в котором подтвержденные транзакции автоматически обрезаются. Патч, доступный через PSSS, устраняет это неудобство.

Несколько одновременных экземпляров

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

1. журнал с использованием Query Analyzer или osql.exe для экземпляра по вашему выбору

2. включить дополнительные параметры

EXEC sp_configure 'показать дополнительные параметры', '1'
идти
РЕКОНФИГУРИРОВАТЬ
идти

3. установить максимальный размер памяти, изменив параметр max server memory
(выражается в МБ)

EXEC sp_configure 'максимальная память сервера', 256
идти
РЕКОНФИГУРИРОВАТЬ
идти

4. определить маску сходства

EXEC sp_configure «маска сходства», 12
идти
РЕКОНФИГУРАЦИЯ
Идти

Рис. 4. Несколько одновременных экземпляров на Small Business Server 2003

SQL Server воспринимает процессоры HyperThreading как двухпроцессорные системы. Другими словами, если у вас есть 2-процессорный сервер с технологией HT, SQL видит четыре процессора. Установка этих параметров, безусловно, не устранит все аспекты совместного использования ресурсов. Различные экземпляры совместно используют одни и те же каналы ввода-вывода, одни и те же экземпляры ОС, один и тот же системный интерфейс и т. д., однако наиболее распространенные источники конфликтов, т. е. память, ЦП и диски, устранены, и вы можете быть уверены, что любое программное обеспечение, работающее на одном из экземпляры не повлияют на работу других систем.

Надежное и безопасное приложение

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

• технологии
  
• человеческие ресурсы
  
• процессы (т.е. процедуры производства)

Рассмотрим подробнее статистику, в которой анализируются причины различных сбоев. Корпорация Microsoft утверждает, что 40% ошибок связаны с самим приложением (плохое тестирование, ограниченные отчеты об ошибках, плохая масштабируемость). Хорошей технологии недостаточно; вы должны знать, как его применять и как приспособить к вашим потребностям. Следующие 40% ошибок являются ошибками администратора, так как администратор не безошибочен, ему не хватает шаблонов действий на случай чрезвычайных ситуаций или нет резервных копий безопасности и т. д. Последние 20% приходятся на платформу, т. е. на ОС, маршрутизаторы и сетевые подключения. Однако пользователю все равно, какой из этих элементов выйдет из строя — любой сбой означает, что какое-то приложение становится недоступным. Если вы думаете об обеспечении высокой надежности, первое, о чем вы, вероятно, подумаете, это Microsoft Cluster Service. Это так называемые «отказоустойчивые» кластеры, в которых в случае сбоя MSCS перенесет приложение и нагрузку на другой узел. С точки зрения клиента ничего не меняется — имя сервера и IP-адрес остаются прежними. Однако переключение может длиться до 30 секунд. Давайте выясним, что именно означает «переключение».

«Переключение» — перенос операции на другой компьютер; соединения прерываются, а транзакции отвергаются. Данные должны быть отправлены повторно, а транзакции должны быть повторно выполнены на новом узле; сколько нужно сделать, зависит от времени, прошедшего с последней контрольной точки транзакции. Если прерванная транзакция была «длинной», контрольная точка заняла время давно, поэтому переключение может занять гораздо больше 30 секунд.

Другим решением является механизм LogShipping, который зачастую легче реализовать и применить. Вы можете создать расписание отправки журнала транзакций на другой сервер с помощью Мастера плана обслуживания базы данных. Такие события запланированы каждые пять минут по умолчанию, но в некоторых случаях вы можете установить его на одну. Однако следует подчеркнуть, что если вы используете это синхронизирующее устройство, вам придется изобретать способ передачи недостающих данных на сервер в случае аварии. Другим способом создания зеркального сервера является механизм репликации, например, механизм типа Snap Shot. Однако, если это невозможно, механизмы передачи лог-файлов будут гораздо удобнее.

Вы можете спросить, почему MSCS превосходит Log Shipping? Во-первых, время переключения MSCS относительно невелико и нет необходимости вручную передавать некоторые неотправленные данные. В других механизмах ручной синхронизации всегда может случиться так, что наиболее удобным способом передачи будет повторный ввод данных пользователем. Кроме того, приложение должно «предвидеть», что его адрес и имя сервера изменятся. Такие решения все же имеют некоторые преимущества, поскольку существуют серверы только для чтения, информация на которых всегда актуальна и которые можно использовать (если все работает нормально) в качестве серверов, предназначенных для аналитических операций.

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

Библиография

Технет
Руководство администратора и пользователя SQL 2000 C2
Комплект ресурсов SQL Server 2000

http://www.tssug.org
http://www.databasejournal.com
http://www.sqlmag.com
http://www.sqlpass.org