Восстановление баз данных на зеркальном сервере

После переноса копий баз данных на зеркальный сервер их необходимо восстановить на этом SQL-сервере. И полную резервную копию, и копию журналов необходимо восстанавливать с параметром NORECOVERY. Иначе создать зеркальную копию будет невозможно. Если восстановление выполняется из графического интерфейса, то выберите вариант RESTORE WITH NORECOVERY (Восстановление с NORECOVERY) на вкладке Options (Параметры) (рис. 17.5) — это обязательно надо сделать при восстановлении и базы данных, и журналов.

-is»

^ — ■1 н*

TOBEVrt* HMSM

Puc. 17.5. Восстановление журналов для создания зеркальной копии с параметром NO RECOVERY

Часть III

Для восстановления баз данных можно также использовать TSQL-сценарий вроде следующего:

408

RESTORE DATABASE WSSCONTENT

FROM DISK = 'C:\Restore\WSS_Content.bak'

WITH NORECOVERY,

REPLACE

GO

BACKUP LOG WSSCONTENT

FROM DISK = 'C:\Restore\WSS_Content_Log.bak'

WITH NORECOVERY

GO

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

Настройка защиты и включение зеркального отображения

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

Щелкните правой кнопкой на исходной базе данных (на основном SQL-сервере), выберите пункт Properties (Свойства), а затем выберите на панели навигации узел Mirroring (Зеркальное отображение). Откроется диалоговое окно, показанное на рис. 17.6. Обратите внимание, что параметры зеркального отображения затенены. Щелкните на кнопке Configure Security (Настройка безопасности), чтобы создать отношение между основным и зеркальным партнерами. В этом же мастере можно указать, нужен ли следящий сервер.

В мастере согласитесь с предложенным по умолчанию портом 5022 (он должен быть открыт в брандмауэре Windows) и с именем конечной точки Mirroring. Проверьте, совпадают ли учетные записи служб на обеих сторонах, или укажите различные учетные записи.

1'Пот»

Cptn

%

| 'Мютр £nncwt

1J —............

409

После завершения работы мастера он должен показать результат успешной настройки конечной точки на обоих серверах, как показано на рис. 17.7.

(JUS

•шиз.

Configuring Endpoints

Cbck Stcpaortemcieiecpewnn

Ena

0 W«r*e

IfCSZL

3 C^iSM*?endjpor*cn{>incc4l«*rvef[ Succ«t ^ Ccnl9ireen4port(iniiwafevtiISE Succen

J B«l»'»{

Puc. 17.7. Настройка безопасности между основным и зеркальным серверами

После этого можно сразу же настроить зеркальное отображение или включить его позже. После включения диалоговое окно свойств базы данных должно иметь примерно такой вид, как на рис. 17.8, а на консоли управления SQL возле имени базы данных должен появиться описатель (Mirror, Synchronized) (Зеркальная, Синхронизированная). Повторите этот процесс для всех остальных баз данных.

WSS Content

PpiEij 1*гь,

* Often

I*

i

&rap«,./S£RVtFU.c«per^<abcC«'

pCf •yterve^cvi|>ar^c.cam4022 1 |

tc tfribmp «с «**502? ---. -i

*»<rgnali Г Highp*iVrMfa*nynchcrout)-

t*eorifemdfafr««*<e0h

Hshirf^mOyi U4KCmrtdHngH4h><N

pircM'vd'W

E

вЛвЫв*

14* brtwdedPioeertw FnntKlnnliigS^m

Strw

SEfiV£R4

Использование прозрачного шифрования данных SOL (TDE)

Прозрачное шифрование данных (Transparent Data Encryption — TDE) SQL представляет собой простое, но исключительно эффективное решение, позволяющее защищать базы данных контента SharePoint. Ниже представлена информация, которую необходимо знать при реализации SQL TDE.

Постановка задачи

По умолчанию данные SharePoint защищаются с помощью списков управления доступом (Access Control List — ACL), однако данные в самой базе никак не шифруются. Если нежелательные лица получат доступ к SQL-серверу или к резервной копии базы данных SQL, они легко смогут перезаписать списки ACL для защиты SharePoint и получить доступ к данным в самой базе.

По соображениям безопасности и совместимости может оказаться желательным выполнять шифрование данных в базах SQL. В SQL Server 2008 и SQL Server 2008 R2 редакции Enterprise имеется новая возможность под названием “прозрачное шифрование данных' (Transparent Data Encryption — TDE), которая и выполняет эту функцию.

Решения шифрования

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

• Шифрование на уровне ячеек. Шифруется каждая ячейка базы данных, а не вся база целиком. Этот вид шифрования не поддерживается в базах данных SharePoint.

• Шифрование на уровне файлов. Это технологии наподобие BitLocker и EFS (Encrypting File System — шифрующая файловая система). Они шифруют весь жесткий диск и пригодны для работы с SQL. Однако они не шифруют копии баз данных SQL, которые хранятся на других томах.

• Служба управления правами Active Directory (Active Directory Rights Management Services — AD RMS). Это решение использует техники шифрования для защиты прав обращения с данными и ограничивает возможные действия пользователя с этими данными (например, запрет на печать или копирование-вставку контента). Служба AD RMS, описанная ниже в данной главе, не шифрует данные “в состоянии покоя”, а задействуется только при просмотре данных клиентом.

■ Прозрачное шифрование данных. TDE является идеальным решением для шифрования баз данных контента SharePoint, т.к. оно шифрует всю базу данных на основном носителе, в базе tempdb и при копировании базы. Кроме того, шифрование выполняет полностью СУБД SQL, и SharePoint даже не знает об этом.

НА 3AMETKV -

Описанные в данной главе решения представляют собой решения шифрования в хранилищах данных. Для шифрования контента SharePoint на транспортном уровне используйте шифрование с помощью сертификатов SSL (при пересылке данных с клиента на сервер) и IPsec (для трафика между членами фермы). Более подробно о настройке и использовании шифрования транспортного уровня написано в главе 15.

Принципы работы TDE

Основные моменты, которые следует знать о TDE:

■Приактивациивбазе данных TDE шифрует содержимое этой базы, а также связанные с ней файл журнала, снимки состояния, резервные копии и зеркальные копии.

■Шифруетсятакжебаза tempdb для SQL-tepBepa. Этоможетповлиятьнадругиебазыданныхнатомжесервере. Поэтомурекомендуется создать выделенный сервер для шифруемых баз данных, для которых создается своя собственная база tempdb.

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

• Издержки, связанные с работой TDE, составляют лишь 3-5% от производительности сервера, т.е. требуются лишь минимальные ресурсы.

Иерархия ключей TDE

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

(	Уровень ОС Windows	чAPI защиты данных (DPAPI)_>
	......................1	DPAPI шифрует SMK i—.
г	Уровень SQL-сервера	j Главный ключ службы	*■ —
*			ч
(	Уровень главной БД	J Главный ключ базы данных
t ""		...........
(	Уровень главной БД	j Сертификат
	1 Сертификат шифрует DFK п бя.чк данных |—---.---- контента —-----
г—
с	Уровень БД контента	J Ключ шифрования базы данных
J DEK используется для шифрования БД L ----контента __.___

В

Рис. 17.9. Иерархия ключей TDE

Вначале API защиты данных (Data Protection API — DPAPI) используется для создания и защиты главного ключа службы (service master key — SMK). Этот ключ уникален для каждого сервера, его не надо копировать или восстанавливать в других системах. Потом SMK используется для создания и защиты главного ключа базы данных (database master key — DMK).

Обеспечение безопасности, защита и оптимизация архитектуры SharePoint Часть III

Затем DMK используется для создания и защиты сертификата TDE, а тот, в свою очередь, используется для создания ключа шифрования базы данных (Database Encryption Key — DEK), который и шифрует непосредственно содержимое базы.

Требования и ограничения TDE

У TDE есть свои требования и ограничения, с которыми следует ознакомиться перед развертыванием:

• Для работы TDE требуется SQL Server редакции Enterprise. Однако эта редакция гораздо дороже редакции Standard.

• TDE не шифрует канал обмена данными. Используйте для этого TPsec.

• TDE не может использовать сжатие копий в SQL 2008 RTM/R2.

• При работе TDE репликация данных FILESTREAM не шифруется.

• База данных tempdb шифруется для всего сервера, даже если TDE применяется лишь для одной базы данных.