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

В этом контексте полезно обратить внимание на корпоративные решения для управления правами (ERM), такие как Microsoft Windows Rights Management Services (RMS). Чтобы предотвратить несанкционированный доступ, службы RMS шифруют информацию и предоставляют механизм детального управления доступом, в котором определены правила и способы передачи информации пользователю. Постоянная защита, обеспечиваемая службами RMS, сопровождает данные везде, где бы они ни находились, — в сети компании или в «облаке».

Службы RMS поставляются вместе с Windows Server 2008, Windows 7 и Windows Vista. Это вторая версия службы RMS, официально именуемая Active Directory Rights Management Services (AD RMS). Первая версия RMS предоставлялись как бесплатная надстройка для Windows Server 2003, Windows XP и Windows 2000 Workstation. Защиту RMS можно применять в документах Microsoft Office 2010, 2007 и 2003; сообщениях электронной почты Microsoft Outlook и документах Microsoft PowerPoint, Excel, Word и InfoPath. Кроме того, RMS можно использовать для защиты файлов в формате XPS. Совместимость RMS с другими форматами документов (например, Adobe Acrobat PDF, Microsoft Office 2000, Microsoft Visio) достигается с помощью специальных подключаемых модулей, распространяемых сторонними поставщиками программ, например GigaTrust.

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

Службы управления правами обеспечивают четыре варианта обмена документами, защищенными посредством RMS, между компаниями.

  • Использование одной инфраструктуры RMS и создание внешних учетных записей для партнера в инфраструктуре AD.
  • Создание инфраструктуры RMS на сайте партнера и установление доверительных отношений между двумя инфраструктурами RMS.
  • Применение учетных данных Windows Live ID для проверки подлинности внешних пользователей.
  • Использование федерации удостоверений через службы федерации Active Directory (ADFS) или Microsoft Federation Gateway.

Чтобы настроить службы RMS для внешнего взаимодействия, необходимо задействовать контейнер Trust Policies в оснастке Active Directory Rights Management Services консоли управления Microsoft Management Console (MMC), как показано на экране 1. По умолчанию в этом контейнере имеется два субконтейнера: Trusted User Domains и Trusted Publishing Domains. Если во время установки выбрать службу роли поддержки удостоверений в службе федерации, то в Trust Policies появится третий субконтейнер, Federated Identity Support. Наконец, если сервер RMS функционирует на платформе Windows Server 2008 R2 SP1, в контейнере Trust Policies появится четвертый субконтейнер — Microsoft Federation Gateway Support. Для настройки всех параметров политики доверия также можно использовать команды Windows PowerShell, как описано в статье Microsoft TechNet «Establishing Trust Policies» по адресу technet.microsoft.com/en-us/library/ee221019(WS.10).aspx.

 

Настройка RMS для внешней совместной работы
Экран 1. Настройка RMS для внешней совместной работы

Единственная инфраструктура RMS

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

Чтобы пользователи партнера могли получить доступ и создавать контент, защищенный посредством RMS, ваша компания должна выполнить внешнюю публикацию RMS в Интернете или корпоративной сети. В статье Microsoft TechNet «Internet Access Considerations» (глава в документации по RMS) по адресу technet.microsoft.com/en-us/library/dd996655(WS.10).aspx можно найти хорошие рекомендации по внешней публикации.

Пользователи партнерской компании должны установить клиентское программное обеспечение AD RMS и использовать RMS-совместимые приложения Office. Партнеры, желающие только получить доступ к защищенной информации, но не создавать новую защищенную информацию, могут задействовать надстройку Rights Management Add-On for Internet Explorer (RMA), доступную по адресу www.microsoft.com/download/en/details.aspx?id=4753.

В этом случае партнерам не нужно устанавливать клиент RMS и RMS-совместимые приложения на клиентских компьютерах. Если в компании предполагается развернуть RMA, рекомендую прочитать статью Microsoft «Introducing Rights-Managed HTML» по адресу download.microsoft.com/downloadc/b/0/cb07013e-7630-47c3-9237 cc839ee5fd61/RMH%20Intro.doc.

Доверительные отношения RMS

Доверительное отношение RMS — специфическое доверие, отличное от доверия AD, которое формируется между двумя экземплярами RMS. Главное условие доверия RMS заключается в том, чтобы партнер развернул инфраструктуру RMS. Это сложное требование, которое могут выполнить не все партнеры.

Доверие RMS можно определить из оснастки Active Directory Rights Management Services. В контейнере Trust Policies представлены два варианта для формирования доверия RMS: можно использовать доверенный домен пользователя (TUD) или доверенный домен публикации (TPD).

  • При использовании TUD ваш кластер RMS может выдать лицензии на использование RMS тем, кто прошел проверку подлинности в другом кластере RMS. Можно добавить доверенный домен пользователя, импортировав сертификат лицензиара для сервера Server Licensor Certificate (SLC) кластера RMS другой компании в ваш RMS-кластер.
  • При использовании TPD ваш сервер AD RMS выдает лицензии работы с RMS пользователям, имеющим лицензии публикации, выданные другим сервером RMS. Доверенный домен публикации можно добавить, импортировав сертификат SLC и связанный с ним закрытый ключ сервера RMS другой компании в ваш сервер RMS.

Доверительные отношения на основе как TUD, так и TPD — однонаправленные. Для формирования доверия RMS не требуется прямого соединения между кластерами AD RMS или лесами AD. Это можно сделать иным способом, обменявшись необходимыми сертификатами и/или ключами.

Но если используется TUD, то для получения внешним пользователем лицензии на применение RMS от кластера RMS, ваш сервер RMS должен быть доступен из Интернета или из распределенной корпоративной сети. Ценные указания можно найти в том же материале «Internet Access Considerations» по адресу technet.microsoft.com/en-us/library/dd996655(WS.10).aspx. Внешний доступ не является обязательным условием для доверительных отношений RMS на основе TPD. В этом случае внешние пользователи могут получить лицензию на применение RMS для защищенного контента от серверов RMS их же компании.

В случае доверительных отношений RMS на основе TUD можно отказать определенным поддоменам электронной почты и их пользователям в выдаче лицензий на использование RMS из вашего кластера RMS. Сделать это можно с помощью свойств сертификата TUD, который отображается в средней панели оснастки Active Directory Rights Management Services, как показано на экране 2.

 

Настройка доверенных доменов электронной почты
Экран 2. Настройка доверенных доменов электронной почты

Windows Live ID

Windows Live ID — инфраструктура проверки подлинности на основе Интернета, обслуживаемая компанией Microsoft. Чтобы задействовать учетные данные Windows Live ID для проверки подлинности внешних пользователей на серверах RMS, учетным записям партнера, которым нужно читать защищенную с помощью RMS информацию, требуется зарегистрированная учетная запись Windows Live ID. Некоторые компании неохотно используют учетные данные Windows Live ID для проверки подлинности, когда они применяются для доступа к внутренним (возможно, конфиденциальным) данным. Для пользователя, запросившего учетную запись Windows Live ID, выполняется лишь очень простая проверка (по действительному адресу электронной почты).

Чтобы включить проверку подлинности Windows Live ID в RMS, необходимо установить доверительные отношения с интерактивной RMS-службой Microsoft. Эта та служба, которая может предоставить сертификат проверки подлинности RMS (или сертификат учетной записи службы управления правами, RAC) пользователям, прошедшим проверку подлинности Windows Live ID. В результате установки доверительных отношений получатели Windows Live ID смогут читать защищенную информацию, но не создавать контент, защищенный с помощью RMS.

Чтобы пользователи с сертификатом учетной записи службы управления правами Windows Live ID могли получить лицензии на использование RMS от вашего внутреннего кластера RMS, необходимо назначить доверенный домен пользователя (TUD) для Windows Live ID в конфигурации RMS. Сделать это можно из контейнера Trust Policies\Trusted User Domains в оснастке Active Directory Rights Management Services. На панели Actions выберите Trust Windows Live ID. Если доверительные отношения успешно установлены, сертификат Windows Live ID появится в списке Trusted User Domain на средней панели, как показано на экране 3.

 

Настройка доверенного домена пользователя для Windows Live ID в RMS
Экран 3. Настройка доверенного домена пользователя для Windows Live ID в RMS

Для любого другого доверенного домена пользователя RMS можно запретить определенным доменам Windows Live ID и их пользователям получить лицензии на применение RMS от вашего кластера RMS. Сделать это можно из свойств сертификата Windows Live ID, показанного на средней панели.

Для успешного выполнения проверки подлинности Windows Live ID для RMS необходимо также изменить настройки веб-сервера IIS RMS, чтобы обеспечить внешним пользователям Windows Live ID доступ к веб-службе лицензирования AD RMS. Для этого следует разрешить анонимный доступ в веб-службе лицензирования. По умолчанию служба лицензирования настраивается на использование встроенной проверки подлинности Windows.

Федерация удостоверений

Компания Microsoft предоставляет две технологии на основе федерации удостоверений для взаимного доступа компаний к контенту, защищенному с помощью RMS. Первая основывается на ADFS, а вторая — на Microsoft Federation Gateway. На момент подготовки данной статьи второе решение может использоваться только для обмена защищенными почтовыми сообщениями между пользователями Microsoft Exchange Server и Outlook в различных компаниях.

ADFS — решение федерации удостоверений, появившееся в Windows Server 2003 R2. ADFS предоставляет службы для формирования доверительных отношений между компаниями и удобного взаимного доступа к ресурсам. Например, с помощью ADFS можно предоставить внешним партнерам единую процедуру входа для доступа к документам в веб-портале. Благодаря ADFS партнеры могут пройти проверку подлинности в своей инфраструктуре AD с использованием внутренних учетных записей, а затем открыто обращаться к документам на вашем портале. ADFS может преобразовать маркеры проверки подлинности партнеров в формат, понятный для серверов ADFS вашей компании. В результате партнеры получают прозрачный доступ к ресурсам вашего портала.

Службы RMS также могут использовать ADFS для предоставления внешним пользователям доступа к внутренним данным, защищенным RMS. Интеграция ADFS возможна только с RMS версии 2 (поставляемой в составе Server 2008 и более поздних продуктах); только эта версия является приложением ADFS с распознаванием утверждений. На стороне ADFS интеграция с RMS возможна как для ADFS версии 1, так и для ADFS версии 2.

Благодаря поддержке ADFS в службах RMS компании могут безопасно обмениваться информацией, защищенной с помощью RMS, с другими компаниями, даже не имеющими внутренней инфраструктуры RMS. Однако для этого требуется полная инфраструктура ADFS.

  • Для использования ADFS совместно со службами RMS компания должна располагать внутренней инфраструктурой ADFS, а также иметь доверительные отношения ADFS с каждым из партнеров, с которым предстоит обмениваться данными, защищенными с помощью RMS. Кроме того, необходимо установить и активизировать поддержку удостоверений в службе федерации на серверах, как показано в статье Microsoft TechNet «Configure Federated Identity Support Settings» по адресу technet.microsoft.com/en-us/library/cc732627(WS.10).aspx.
  • Ваши партнеры должны располагать Windows 2003 R2 или более новыми версиями, иметь собственную инфраструктуру ADFS и установить клиент RMS на своих клиентских платформах.

Также следует отметить, что некоторые приложения Microsoft несовместимы с ADFS (пока) и поэтому непригодны для создания и доступа к контенту, защищенному с помощью RMS, с использованием проверки подлинности ADFS. Среди этих приложений — Microsoft Office SharePoint Server, Windows Mobile и программа просмотра XPS. У SharePoint и Windows Mobile — та же проблема с проверкой подлинности Windows Live ID.

Кроме того, ADFS и Windows Live ID не могут использовать группы (только учетные записи отдельных пользователей) для защиты и доступа к информации RMS. Это связано с возможностью выполнить расширение группы, когда используются эти методы проверки подлинности. С выходом Server 2008 R2 в ADFS появились некоторые изменения, в результате которых становится возможным расширение групп RMS. Дополнительные сведения об этих двух проблемах можно найти в статье Microsoft TechNet «Assessing the Alternatives for Sharing Protected Documents Between Organizations» по адресу technet.microsoft.com/en-us/library/dd983942(WS.10).aspx.

Компания Microsoft дает подробные пояснения по интеграции RMS-ADFS. Например, можно прочитать статью TechNet «AD RMS with AD FS Identity Federation Step-by-Step Guide» по адресу technet.microsoft.com/en-us/library/cc771425(WS.10).aspx.

Второе решение на основе федерации удостоверений — Microsoft Federation Gateway, брокер удостоверений, доступный в «облаке». Его преимущество в том, что компании должны управлять только одним доверительным отношением федерации удостоверений (с Microsoft Federation Gateway), чтобы обеспечить доступ их удостоверений ко всем другим службам, объединенным со шлюзом. Охват федерации можно также контролировать из интерфейса управления RMS путем создания белого и черного списков пользователей и доменов для лицензирования, указания доменов, которые могут получить лицензии на публикации.

Для поддержки RMS со стороны Microsoft Federation Gateway на серверах RMS необходимо установить Server 2008 R2 SP1. Помните, что во время подготовки данной статьи Exchange Server 2010 был единственным приложением, способным реализовать преимущества Microsoft Federation Gateway для обмена данными, защищенными с помощью RMS, между компаниями. Дополнительные сведения об установке и настройке поддержки для Microsoft Federation Gateway можно найти в статье Microsoft TechNet «AD RMS Microsoft Federation Gateway Support Installation and Configuration Guide» по адресу technet.microsoft.com/en-us/library/gg636976(WS.10).aspx.

Разные методы для разных компаний

Службы Microsoft RMS обеспечивают различные варианты безопасного обмена документами между компаниями. Важный фактор при выборе оптимального способа коллективной работы с RMS — наличие инфраструктуры RMS и ADFS у обоих партнеров.

Подход к совместной работе с самым полным набором функций — доверие RMS (домен TUD или TPD). Федерация — удачный подход для компаний, готовых примириться с ограниченным кругом совместимых программ. Если число внешних пользователей невелико, то Windows Live ID — самое простое решение. При большом числе внешних пользователей оптимальным выходом может быть создание учетных записей пользователей в локальной Active Directory (AD). Но в этом случае необходимо учитывать накладные расходы на предоставление учетных записей и управление ими.

Жан де Клерк (jan.declercq@hp.com) — сотрудник Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасностью в продуктах Microsoft