Любой пользователь с правом доступа «только чтение» может делать копии данных и передавать их посторонним. Риск несанкционированного распространения информации заставляет предприятия стремиться к непрерывной защите данных. Идея непрерывной защиты данных проста: данные защищаются, где бы они ни хранились, а также во время передачи; владелец содержимого определяет, какие пользователи могут получать доступ к данным и как они могут их использовать (например, присвоен ли данным статус «только чтение», могут ли пользователи изменять и распечатывать данные и в течение какого времени они имеют доступ к данным). Решение, которое предлагает Microsoft в области непрерывной защиты данных для деловой информации, называется «Служба по управлению правами Windows», Windows Rights Management Services (RMS).

Обзор RMS

RMS обладает механизмами защиты, которые нельзя найти в традиционных технологиях контроля доступа. Например, для ограничения доступа пользователей и групп и для назначения и отмены полномочий на создание, чтение, запись, удаление и доступ к файлам можно воспользоваться такой традиционной технологией, как списки контроля доступа Discretionary Access Control Lists (DACL). Но посредством DACL невозможно предотвратить распечатку документа или его отправку по электронной почте. RMS позволяет автору защищаемых данных, таких как электронное сообщение или документ, созданный в Microsoft Office 2003 (Word, Excel, PowerPoint и т. п.), наделять пользователей и группы специфическими правами, включая разрешение отвечать на электронное сообщение, пересылать его, а также печатать, редактировать и сохранять файлы.

RMS является инфраструктурной технологией, состоящей из серверов RMS, клиентов RMS и поддерживающих RMS приложений, которые взаимодействуют с клиентом RMS. В поддерживающие RMS приложения Microsoft входят приложения Microsoft Office 2003 с дополнительным модулем для управления правами Rights-Management Add-On (RMA) for Internet Explorer (IE). RMA можно использовать для просмотра Web-сайтов с защитой прав, а также документов Office 2003 и электронных сообщений на компьютерах с более ранними версиями Microsoft Office. Поддерживающие RMS приложения также поставляются компаниями — партнерами Microsoft и независимыми производителями. Для того чтобы использовать RMS в своей сети, необходимо установить серверы RMS и развернуть RMS Client и поддерживающие RMS приложения на настольных компьютерах пользователей.

Регистрация сервера сертификатов RMS

Для использования RMS на предприятии требуется обеспечить работу серверной части RMS и зарегистрировать RMS Server, указав Microsoft в качестве Certification Server. RMS Certification Server — это первый RMS Server, который устанавливается в сети предприятия. Основная роль сервера сертификатов — выдавать сертификаты Rights Account Certificates (RAC) пользователям RMS и разрешать серверам лицензирования (Licensing Server) вторичную регистрацию через него (см. рисунок). Одним из элементов обеспечения серверной части RMS является указание сервера базы данных, который будет использоваться RMS для хранения своей конфигурации, ведения журналов, хранения учетных данных, кэша расширенной информации групп, а также указание адреса Intranet Cluster URL, на котором он будет работать. RMS устроен как Web-служба, поэтому RMS-клиенты используют протоколы HTTP или HTTP Secure (HTTPS) для связи с RMS-сервером.

Рисунок. Сценарий работы RMS

В процессе регистрации RMS-сервера RMS Certification Server генерирует пару открытый/закрытый ключ и отправляет открытый ключ вместе с другой информацией в Microsoft в виде запроса сертификата Server Licensor Certificate (SLC). RMS Service Pack 1 (SP1) позволяет делать запрос SLC как напрямую (в оперативном режиме), так и не напрямую (в автономном режиме). Если вы регистрируетесь напрямую, RMS Certification Server отправляет запрос регистрации в Microsoft, Microsoft проверяет информацию и возвращает подписанный SLC, а сервер сертификатов извлекает и устанавливает подписанный SLC.

Если отсутствует выход в Internet (например, при установке RMS в изолированной сети с повышенной безопасностью) или требуется проверить содержание запроса перед его подтверждением, можно экспортировать запрос в XML-файл, затем через USB-память «вручную» перенести его на компьютер, подключенный к Internet, и отправить, используя браузер, на сайт Microsoft, указанный в сервере сертификатов RMS при экспортировании запроса. В ответ вы получите от Microsoft подписанный SLC, который устанавливается на RMS Certification Server. Microsoft не хранит никакой информации ни о запросах SLC, ни о выданных SLC (из соображений конфиденциальности).

Когда действительный сертификат SLC установлен на сервер сертификатов RMS, тот начинает функционировать. Можно добавить еще несколько серверов RMS и создать кластер серверов сертификатов (RMS Certification Cluster) для отказоустойчивости и масштабируемости. Предназначенная для кластеров служба Windows Network Load Balancing (NLB) (или такое устройство, как F5 BIG-IP Load Balancer-http://www.f5.com/products/bigip/) распределяет нагрузку запросов по серверам в RMS Certification Cluster. Необходимо опубликовать адрес Intranet Cluster URL в атрибуте serviceConnectionPoint в AD, чтобы упростить клиентам RMS поиск RMS Certification Cluster на Web-сайте управления RMS. Доступ к сайту управления RMS можно организовать через ссылку в меню Start. Без записи serviceConnectionPoint в AD придется обращаться к записям в реестре систем клиентов RMS, чтобы клиенты могли обнаружить RMS Certification Cluster. Если нужно сделать доступным RMS-сервер через Internet, требуется настроить в AD адрес Extranet Cluster URL.

Настройка и активация клиентов

Прежде чем поддерживающие RMS приложения смогут начать функционировать на клиентах RMS, необходимо установить Windows Rights Management Services (RMS) Client SP1 или более поздние версии на пользовательских рабочих станциях. При первом применении функции RMS приложения Microsoft, поддерживающие RMS, автоматически активируют клиент RMS. В процессе активации клиента RMS создается сертификат Machine Certificate, уникальный для каждого клиента RMS; он хранится в пользовательском профиле локального компьютера вместе с соответствующим закрытым ключом. Подробнее о запросах RAC рассказано во врезке «Шифрование в RMS». Затем RMS-клиент получает для пользователя сертификат RAC от сервера сертификатов RMS и сохраняет его в пользовательском профиле локального компьютера.

Если поддерживающее RMS приложение не находит действительного RAC в момент обращения пользователя к RMS-функции, приложение может запросить RAC для пользователя через клиент RMS, выполняя поиск атрибута serviceConnectionPoint в AD, соответствующего RMS, или записей в реестре системы клиента RMS, и найти адрес Intranet Cluster URL сервера сертификатов RMS. Затем клиент RMS выдает запрос на ввод учетных данных (имя пользователя и пароль) или сертификата аутентификации клиента (Client Authentication) (например, сертификат, хранящийся на смарт-карте и используемый для безопасной регистрации). Однако клиент RMS не запрашивает учетные данные пользователя, если адрес Intranet Cluster URL указывает на корпоративную сеть или на надежные узлы IE, а содержимое зоны IE настроено на автоматическую отправку учетных данных.

Для работы RMS необходимо, чтобы адрес электронной почты пользователя был записан в пользовательскую учетную запись в AD с применением почтовых атрибутов, так как поддерживающие RMS приложения задействуют электронный адрес для уникальной идентификации пользователя. Если у вас установлен Microsoft Exchange 2000 или 2003, почтовые атрибуты заполняются автоматически для каждого пользователя, имеющего почтовый ящик Exchange. Однако RMS не требует наличия у пользователей Exchange ящиков входящих сообщений (Inbox), и вы можете вручную заполнить атрибуты пользователей, не имеющих ящиков входящих сообщений. Если у пользователя меняется электронный адрес или имеется несколько адресов, можно применить многозначный атрибут proxyAddress в AD для записи старого и альтернативных адресов, так чтобы пользователь мог продолжать задействовать RMS для доступа к защищенному контенту.

Сертификат RAC действителен в течение года. В некоторых случаях, например когда пользователь хочет получить доступ к защищенным данным с общедоступного терминала, особый вид сертификата RAC, называемый временным сертификатом (Temporary RAC), может быть выпущен на 15 минут — этот применяемый по умолчанию временной интервал можно изменить, пользуясь сайтом управления RMS на сервере сертификатов RMS.

Авторизация данных с защищаемыми правами

Многие пользователи защищают данные в автономном режиме, но с помощью RMS также можно защищать данные интерактивно. Сервер лицензирования RMS (RMS Licensing Server) защищает данные в оперативном режиме, а авторский сертификат Client Licensor Certificate (CLC) используется для защиты данных в автономном режиме. Защита в автономном режиме важна, когда вы хотите создать данные с защищаемыми правами, но не подключены к корпоративной сети (например, находитесь в самолете или в кафе). Приложения Office 2003 всегда защищают данные в автономном режиме, используя CLC. При первой попытке пользователя защитить данные с помощью RMS поддерживающее RMS приложение запрашивает CLC от сервера лицензирования RMS, сконфигурированного для пользователя, при условии, что приложение не обнаружило действительный сертификат CLC на клиенте RMS. Клиент RMS хранит CLC в пользовательском профиле локального компьютера.

Данным, защищаемым в автономном или оперативном режиме, будет назначена лицензия Publish License (PL), которая содержит права, предоставленные пользователям автором. Для защиты данных RMS использует шифрование. Шифруются сами данные, та часть PL, в которой определены права, связанные с данными, и сведения о том, кто из пользователей имеет права на эти данные. При отсутствии шифрования приложения, не поддерживающие RMS и не применяющие права и разрешения (такие, как Microsoft Notepad), могли бы получать доступ к защищенным данным.

Обращение пользователя к защищенным данным

Прежде чем пользователь сможет получить доступ к защищенным данным, поддерживающее RMS приложение отправляет запрос через RMS-клиента этого пользователя на сервер лицензирования RMS, который изначально защищал содержимое (или выдавал сертификат CLC на данные, защищаемые в автономном режиме, пользователю-автору), чтобы получить лицензию конечного пользователя (End-User License, EUL). RMS-клиент отправляет сертификат RAC пользователя и лицензию PL данных в запросе EUL. Сервер лицензирования RMS проверяет, заявлен ли в PL или в одной из групп, перечисленных в PL, пользователь, указанный в RAC. Если пользователь заявлен самостоятельно или как член группы, сервер выдает ему лицензию EUL, наделяющую его правами доступа.

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

Как привести защиту RMS в действие

Только поддерживающие RMS приложения могут открывать документы, содержимое которых защищено. Поддерживающие RMS приложения отвечают за соблюдение прав, предоставленных авторами пользователям. В результате разработчики должны включать в поддерживающие RMS приложения код, который использует RMS Client API и постоянно защищает данные. Например, если приложение использует временный файл для форматирования документа перед отправкой на принтер, у него должны быть сведения о том, что временный файл шифруется, предотвращая доступ пользователя или хакера, минуя защитные меры RMS. Однако, полагаясь на приложения при соблюдении прав пользователей, мы сталкиваемся с проблемой: можно ли доверять приложениям? Что мешает хакеру написать приложение, которое использует RMS Client API для доступа к защищенным данным, нарушая тем самым права и открывая доступ к данным без ограничения? Ответ — в клиенте RMS.

Перед тем как поддерживающее RMS приложение получает доступ к документу, клиент RMS проверяет декларацию приложения. Каждое поддерживающее RMS приложение выпускается с декларацией (файлом в формате XML), в которой перечислены компоненты приложения, включая каждый DLL-файл и каждый исполняемый (EXE) файл. Разработчики приложения запрашивают сертификат, подтверждающий декларацию у Microsoft. Разработчик приложения использует сертификат для создания цифровой подписи декларации. Клиент RMS проверяет подпись, дабы убедиться, что декларация приложения действительна, а также проверяет процесс исполнения, чтобы удостовериться, что файлы DLL и EXE не были подменены и что вредоносный DLL не был внедрен в программу. Если процесс не соответствует декларации, клиент RMS возвращает ошибку и отказывает в доступе к защищенным данным. Если производитель выпускает приложение, содержащее уязвимость, которую можно использовать для устранения защиты данных, администратор RMS может исключить приложение, записав его название и номер (а) версии на серверах лицензирования RMS. Исключенные приложения записываются в лицензию EUL, которую проверяет клиент RMS. Сами приложения могут исключить собственные более ранние версии, когда они генерируют PL, и эти исключения копируются в EUL. Клиент RMS сравнивает список исключений в EUL с декларацией приложения, и, если обнаруживается совпадение, клиент RMS запрещает доступ поддерживающего RMS приложения к данным. Более подробно о введении в действие централизованной политики управления защитой прав документов рассказано во врезке «Осуществление политики через шаблоны».

Хранение лицензий EUL

По умолчанию лицензии EUL на документы, созданные в приложениях Microsoft Office, действительны в течение 7 лет. Приложения Microsoft Office хранят лицензии EUL внутри защищаемого контента. До тех пор пока у пользователя имеется действительная лицензия EUL, пользователь может непрерывно получать доступ к тем же данным в автономном режиме или в режиме онлайн. Для сохранения EUL в защищенной области автор должен иметь разрешение на запись в двоичном файле на диске. Поскольку права соотносятся с конкретными приложениями, такое разрешение на запись не обязательно дает право записи или редактирования защищенного содержимого, хранящегося в файле. Благодаря особенности RMS, если пользователь не имеет разрешения на запись в файл через NTFS DACL, клиент RMS аннулирует лицензию EUL этого пользователя, и ему придется получать доступ к данным в оперативном режиме и запрашивать новую EUL всякий раз, когда он хочет получить доступ к данным. Однако, если установлен атрибут «только для чтения», клиент RMS хранит лицензию EUL в пользовательском профиле локального компьютера (%USERPROFILE%LocalSettingsApplicationDataMicrosoftDRM), и лицензия EUL может использоваться клиентом RMS повторно. Microsoft Outlook 2003 всегда хранит лицензии EUL для доступа к защищенным почтовым сообщениям в пользовательском профиле локального компьютера. Если несколько пользователей имеют разрешение двоичной записи в файле с защищенным содержимым (например, файл хранится в папке общего доступа) и каждый пользователь обращается к файлу, файл значительно вырастет в размере, так как лицензия EUL каждого пользователя хранится в нем.

RMS в межкорпоративном взаимодействии

Несмотря на то что RMS был задуман как средство защиты документов внутри предприятий, его можно использовать и для взаимодействия между разными предприятиями (business-to-business, B2B) путем установления отношений доверия (Use Trust) между системами RMS. Use Trusts можно установить посредством экспорта сертификата SLC из доверенного сервера RMS и импорта его в доверяющий сервер RMS в другой компании. При этом устанавливать отношения доверия между инфраструктурами AD не требуется. Пользователь в организации с доверяющим сервером RMS может отправлять защищенные электронные сообщения и документы в организацию с доверенным сервером RMS. Получатель документа с защищенным содержимым будет запускать поддерживающие RMS приложения, которые будут делать запрос EUL, но не к RMS-серверу получателя, а к доверяющему RMS-серверу. Запрос EUL содержит сертификат RAC, выданный доверенной структурой RMS, и лицензию PL. Сначала доверяющий сервер RMS использует импортированный сертификат SLC, чтобы удостовериться в действительности RAC, а затем проверяет, имеет ли получатель доступ к данным, после чего выдает EUL.

Компании, желающие взаимодействовать со своими бизнес-партнерами, которые не имеют технологии RMS, могут воспользоваться службой взаимодействия RMS со службами проверки идентичности (Passport-based RMS Certification Service). Эта служба допускает одностороннюю коммуникацию от пользователя RMS к пользователю, применяющему службу проверки. Пользователь, не работающий с RMS, должен получить паспорт Microsoft Passport. Имея сертификат RAC, снабженный паспортом, получатель сможет сделать запрос EUL к серверу RMS отправителя. Если сервер RMS, получивший запрос, был настроен на доверие сертификатам RAC, выпущенным службами проверки идентичности, а на сервере был указан адрес Extranet Cluster URL, лицензия EUL будет выдана.

RMS — это надежно!

RMS имеет несколько преимуществ по сравнению с другими системами защиты информации, такими как PGP и Secure MIME (S/MIME). Во-первых, PGP и S/MIME могут гарантировать конфиденциальность данных только до того момента, когда данные доходят до получателя, который в дальнейшем волен менять и распространять их. Во-вторых, в таких системах, как PGP и S/MIME, необходимо получить открытый ключ адресата или сертификат X.509v3, чтобы защитить данные, которые предстоит отправить. И наконец, защита данных для больших групп пользователей с применением PGP или S/MIME может оказаться непрактичной, поскольку необходимо защищать документы каждого члена группы и отправлять их по отдельности. В RMS все эти проблемы решены благодаря уникальной архитектуре этого решения.

Более подробную информацию об RMS можно получить на сайте Microsoft по адресу http://www.microsoft.com/rms. Здесь можно загрузить RMS Server и RMS Client, найти руководства, облегчающие установку и устранение проблем с RMS, а также ссылки на компании, предоставляющие дополнительные службы и развернувшие собственные поддерживающие RMS приложения.

Джон Хоуи - директор компании World Wide Services и подразделения IT Technical Community for Security в Microsoft. Имеет 15-летний опыт работы в области информационной безопасности и сертификаты CISA, CISM и CISSP. jhowie@microsoft.com

Осуществление политики через шаблоны

Помимо того что с помощью RMS пользователи могут свободно создавать защищенные документы и предоставлять права доступа к их содержимому, многие организации могут установить централизованную политику, которая определяет, как и кто может получать доступ к данным и с какими правами. На сервере лицензирования RMS можно создавать шаблоны, определяющие, кто имеет доступ к данным, а также типы разрешений для пользователей и групп и другие ограничения, например на какое время пользователю предоставляется доступ к документу или период действительности лицензии EUL. Последнее имеет смысл, если нужно заставить пользователей получать новые EUL, когда права, назначаемые для защиты документов через шаблоны, должны меняться. На экране показан пример шаблона RMS. После того как вы создадите шаблон на сервере RMS, необходимо по сети разослать его пользователям в виде файла XrML (XrML, eXtensible rights Markup Language — расширяемый язык разметки полномочий). SQL Server хранит шаблоны в базе данных конфигурации RMS. Приложениям Office 2003 необходимы настройки реестра с указанием расположения шаблонов RMS. Сервер RMS подписывает шаблоны, и, если злоумышленник попытается модифицировать шаблон, стараясь изменить доступ к защищенному документу, клиент RMS не допустит применения этого шаблона. Когда приложение запрашивает у сервера RMS лицензию EUL на документ, содержимое которого защищалось с применением шаблона, права, данные пользователю, — это те права, что указаны в шаблоне, который хранился в базе данных конфигурации в момент создания шаблона, а не те права, которые указаны в файле шаблона, который использовался во время защиты содержимого документа. Пользователи, права и ограничения, содержащиеся в файле шаблона, выводятся на экран, когда автор защищает содержимое документа.

Экран. Примерный вид шаблона RMS

Применение шаблонов предоставляет дополнительную возможность, а именно возможность использования встроенных в RMS функций лишения прав. Создавая шаблон, вы можете дать ссылку на список лишения прав, который имеет определенный срок действия. В момент обращения к защищенному документу пользователь должен иметь как действительную лицензию EUL, так и копию действительного списка лишения прав на клиенте RMS. Если пользователь или документ указаны в списке лишения прав или действительный список лишения прав недоступен, пользователю будет отказано в доступе к документу. Клиент RMS попытается загрузить список лишения прав и будет хранить его в пользовательском профиле локального компьютера.

Шифрование в RMS

Когда пользователь получает или продлевает сертификат RAC, запрос RAC сопровождается сертификатом Machine Certificate. Сертификаты Machine Certificate, присваиваемые пользователям, содержат открытый ключ клиента RMS. Для хранения соответствующего закрытого ключа RMS использует интерфейс Data Protection API (DPAPI). Сертификат RAC содержит пару открытый/закрытый ключ пользователя, которая генерируется на сервере сертификатов RMS и подписывается с использованием закрытого ключа сервера сертификатов RMS. Закрытый ключ пользователя шифруется открытым ключом сертификата Machine Certificate. Поэтому пользователи имеют сертификат RAC на каждой машине, на которой они задействуют RMS. В тот момент когда RMS-сервер выдает пользователю сертификат CLC, CLC содержит исходящий открытый ключ сервера RMS, который совпадает с открытым ключом в его SLC, а также адреса Intranet Cluster URL и Extranet Cluster URL.

Когда документ защищается при помощи CLC, RMS-сервер генерирует случайный симметричный ключ и с его помощью шифрует содержимое документа. Симметричный ключ шифруется открытым ключом сервера RMS из CLC и записывается в лицензию PL вместе с URL-адресами кластеров RMS-сервера (также из CLC). Когда RMS-клиент запрашивает EUL, он отправляет сертификат RAC и лицензию PL пользователя на RMS-сервер, который определен адресами URL в лицензии PL (RMS-клиент сначала пробует Intranet Cluster URL, затем Extranet Cluster URL). Когда сервер лицензирования получает запрос, он проверяет действительность сертификата RAC по подписи и по тому, указан ли в PL или в одной из групп PL тот пользователь, которому выдан данный сертификат RAC. Если у пользователя имеются права на доступ к документу, сервер лицензирования RMS использует свой закрытый ключ для расшифровки симметричного ключа в PL, а затем снова зашифровывает ключ, используя открытый ключ из сертификата RAC, после чего сервер записывает ключ в EUL (вместе с правами, данными пользователю). RMS-сервер возвращает ключ RMS-клиенту. RMS-клиент использует закрытый ключ системы для расшифровки закрытого ключа пользователя из сертификата RAC. Затем RMS-клиент использует закрытый ключ пользователя для расшифровки симметричного ключа лицензии EUL. Теперь RMS-клиент может задействовать симметричный ключ для расшифровки содержимого защищенного документа. Далее содержимое документа доступно поддерживающему RMS приложению, и права, предоставленные пользователю, соблюдаются поддерживающим RMS приложением.