active directory rights management services что это

Обзор службы управления правами Active Directory

Служба управления правами – это технология защиты информации Microsoft Windows, предназначенная для защиты с помощью криптографии корпоративной почты, документов и, конечно же, веб-страниц. Все действия над вышеперечисленными объектами возможны только при наличии соответствующих прав пользователя.

Защита информации

Впервые служба управления правами появилась в качестве отдельного сервера под названием Rights Management Server (версия 1.0). На дистрибутивном диске поставлялся сам сервер и клиент для Windows 2000 и Windows XP.

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

С выходом Microsoft Windows 2008, служба управления правами стала ролью серверной операционной системы (версия 2.0), изменилось и название – служба управления правами Active Directory (Active Directory Rights Management Services – сокращенно AD RMS). Начиная с Windows Vista, клиент службы управления правами поставляется также вместе с операционной системой. Также клиент AD RMS поставляется с Windows Mobile 6.0 и выше.

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

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

Политики использования указывают, какие сущности ( пользователи, или группы пользователей, компьютеры или приложения) являются доверенными. На любую сущность могут быть наложены права использования.

Состав службы управления правами

Здесь все достаточно просто. Есть два ключевых компонента:

Служба управления правами использует формат сертификатов XrML (eXtensible rights Markup Language), отличный от распространенного стандарта X509v3. Стандарт XrML является расширением языка XML. Дополнительные сведения можно найти на сайте http://www.xrml.org/. Используется несколько видов сертификатов.

Таблица 1. Типы сертификатов AD RMS

Сертификат

Префикс

учетной записи службы управления правами

лицензии на использование

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

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

Каждый пользователь должен иметь заполненное поле электронной почты в домене Active Directory.

Рисунок 1. Рабочий процесс использования AD RMS.

Рассмотрим на примере, как работает AD RMS:

Приложения, поддерживающие AD RMS

Как можно заметить из описания работы службы управления правами, сама по себе она не используется. Использование может быть произведено с помощью приложения, которое поддерживает взаимодействие с клиентом службы управления правами.

На момент написания этой статьи существует целый ряд приложений, которые поддерживают службу управления правами [1]:

Пример использования AD RMS совместно c Microsoft Word 2010

Например, пользователь Егор Егоров должен переслать пользователю Сергею Сергееву секретный документ с использованием Microsoft Word 2010. Информация не должна быть никому раскрыта. Что делать Егору Егорову? Но тут он узнает, что в организации есть такая возможность! Эта возможность предоставлена службой управления правами! Итак, начнем.

Рисунок 2. Включение ограничения доступа

При первом обращению к кластеру службы управления правами на компьютер Егора Егорова, будут получены все необходимые для работы сертификаты. Но сначала нужно пройти аутентификацию. В поле «Учетная запись», нужно ввести адрес электронной почты пользователя Егора Егорова. Нужно заметить, что службе управления правами не требуется, хотя и желательно, присутствие в домене сервера Exchange, адрес электронной почты заполняется в учетной записи пользователя домена Active Directory. В качестве пароля нужно использовать пароль для входа в домен. Итак, пользователь Егор Егоров вводит свои учетные данные (egorov@prod.local и пароль) и получает возможность использования службы управления правами на доступ к данным.

Рисунок 3. Основное окно разрешения ограничений доступа

Рисунок 4. Дополнительное окно разрешения ограничений доступа

В окне «Разрешения» можно:

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

Теперь пользователь Его Егоров может быть уверенным, что никто кроме Сергея Сергеева не откроет документ с помощью приложения Microsoft Word 2010.

Вывод

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

Статья опубликована в N7-8 журнала «Системный администратор».

Источник

Active Directory Rights Management Services Overview

Applies To: Windows Server 2012 R2, Windows Server 2012

Did you know that Microsoft Azure provides similar functionality in the cloud? Learn more about Microsoft Azure identity solutions. Create a hybrid identity solution in Microsoft Azure: — Learn about Azure Rights Management. — Deploy the Azure Rights Management Connector.

This document provides an overview of Active Directory Rights Management Services (AD RMS) in Windows Server® 2012. AD RMS is the server role that provides you with management and development tools that work with industry security technologies—including encryption, certificates, and authentication—to help organizations create reliable information protection solutions.

Did you mean…

Role description

AD RMS can be used to augment the security strategy for your organization by protecting documents using information rights management (IRM).

AD RMS allows individuals and administrators through IRM policies to specify access permissions to documents, workbooks, and presentations. This helps prevent sensitive information from being printed, forwarded, or copied by unauthorized people. After permission for a file has been restricted by using IRM, the access and usage restrictions are enforced no matter where the information is, because the permission to a file is stored in the document file itself.

AD RMS and IRM help individuals enforce their personal preferences concerning the transmission of personal or private information. They also help organizations enforce corporate policy governing the control and dissemination of confidential or proprietary information.

AD RMS running on Windows Server 2012 R2 or Windows Server 2012 meets the requirements of FIPS 140-2 when this server role is deployed as described in FIPS Compliance Issues for RMS.

Practical applications

IRM solutions that AD RMS enables are used to help provide the following:

Persistent usage policies, which remain with the information, no matter where it is moved, sent or forwarded.

An additional layer of privacy to protect sensitive information —such as financial reports, product specifications, customer data, and confidential e-mail messages—from intentionally or accidentally getting into the wrong hands.

Prevent an authorized recipient of restricted content from forwarding, copying, modifying, printing, faxing, or pasting the content for unauthorized use

Prevent restricted content from being copied by using the Print Screen feature in Microsoft Windows

Support file expiration so that content in documents can no longer be viewed after a specified period of time

Enforce corporate policies that govern the use and dissemination of content within the company

IRM-based solutions that AD RMS supports cannot prevent all types of threats to the security of sensitive documents or prevent disclosure of screen readable information under all circumstances. For example, the following are some types of document security threats that AD RMS does not address or mitigate:

Content from being erased, stolen, or captured and transmitted by malicious programs such as Trojan horses, keystroke loggers, and certain types of spyware

Content from being lost or corrupted because of the actions of computer viruses

Restricted content from being hand-copied or retyped from a display on a recipient’s screen

A recipient from taking a digital photograph of the restricted content displayed on a screen

Restricted content from being copied by using third-party screen-capture programs

For more information about how AD RMS can be used to design secure document collaboration, see AD RMS Architecture Design and Secure Collaboration Scenarios.

For information about how AD RMS can secure all file types, see How RMS protects all file types – by using the RMS sharing app.

New and changed functionality

Several improvements have been made to the Windows Server 2012 version of AD RMS. These enhancements are covered online in the article What’s New in AD RMS?

Server Manager information

The installation of AD RMS role services can be performed through the Server Manager. The following role services can be installed:

Upgrading or migrating

If you are running a version of Rights Management that you want to upgrade or migrate to the latest version, use the following resources:

To upgrade or migrate to Active Directory Rights Management (AD RMS): RMS to AD RMS Migration and Upgrade Guide

To migrate to Azure Rights Management (Azure RMS): Migrating from AD RMS to Azure Rights Management

See also

The following table provides additional resources for evaluating AD RMS.

Источник

Установка и настройка ADRMS на Windows Server 2012 R2

В этой статье мы покажем как развернуть и задействовать для защиты контента службу Active Directory Right Management Services (ADRMS) на базе Windows Server 2012 R2 в организация масштаба small и middle-size.

В первую очередь кратко напомним о том, что такое служба AD RMS и зачем она нужна. Служба Active Directory Right Management Services – одна из стандартных ролей Windows Server, позволяющая организовать защиту пользовательских данных от несанкционированного использования. Защита информации реализуется за счет шифрования и подписывания документов, причем владелец документа или файла может сам определить, каким пользователям можно открывать, редактировать, распечатывать, пересылать и выполнять другие операции с защищенной информацией. Нужно понимать, что защита документов с помощью ADRMS возможно только в приложениях, разработанных с учетом этой службы (AD RMS-enabled applications). Благодаря AD RMS можно обеспечить защиту конфиденциальных данных как внутри, так и за пределами корпоративной сети.

Несколько важных требования, которые нужно учесть при планировании и развертывании решения AD RMS:

Прежде чем приступить непосредственно к развертыванию ADRMS, нужно выполнить ряд подготовительных шагов. В первую очередь необходимо создать в Active Directory отдельную сервисную запись для ADRMS с бессрочным паролем, например с именем svc-adrms (для службы ADRMS можно создать и особую управляемую учетную запись AD — типа gMSA).

В DNS-зоне создадим отдельную ресурсную запись, указывающую на AD RMS сервер. Допустим его имя будет – adrms.

Приступим к установке роли ADRMS на сервере с Windows Server 2012 R2. Откройте консоль Serve Manager и установите роль Active Directory Rights Management Service (здесь все просто – просто соглашайтесь с настройками и зависимостями по-умолчанию).

После того, как установка роли ADRMS и сопутствующих ей ролей и функций закончится, чтобы перейти в режим настройки роли ADRMS, щелкните по ссылке Perform additional configuration.

В мастере настройки выберем, что мы создаем новый корневой кластер AD RMS (Create a new AD RMS root cluster).

В качестве базы данных RMS будем использовать внутреннюю базу данных Windows (Use Windows Internal Database on this server).

Затем укажем созданную ранее сервисную учетную запись (svc-adrms), используемый криптографический алгоритм, метод хранения ключа кластера RMS и его пароль.

Осталось задать веб-адрес кластера AD RMS, к которому будут обращаться RMS-клиенты (рекомендуется использовать защищенное SSL соединение).

Не закрывайте мастер настройки AD RMS!

Следующий этап – установка SSL-сертификата на сайт IIS. Сертификат может быть самоподписаным (в дальнейшем его нужно будет добавить в доверенные на всех клиентах), или выданным корпоративным/внешним центром сертификации (CA). Сформируем сертификат с помощью уже имеющегося корпоративного CA. Для этого откройте консоль IIS Manager (inetmgr) и перейдите в раздел Server Certificates. В правом столбце щелкните по ссылке Create Domain Certificate (создать сертификат домена).

Сгенерируйте новый сертификат с помощью мастера и привяжите его к серверу IIS.

Вернитесь в окно настройки роли AD RMS и выберите сертификат, который планируется использовать для шифрования трафика AD RMS.

Отметьте, что точку SCP нужно зарегистрировать в AD немедленно (Register the SCP now).

На этом процесс установки роли AD RMS закончен. Завершите текущий сеанс (logoff), и перезалогиньтесь на сервер.

Запустите консоль ADRMS.

Для примера создадим новый шаблон политики RMS. Предположим мы хотим создать шаблон RMS, позволяющий владельцу документа разрешить всем просмотр защищенных этим шаблоном писем без прав редактирования/пересылки. Для этого перейдем в раздел Rights Policy Templates и щелкнем по кнопке Create Distributed Rights Policy Template.

Нажав кнопку Add, добавим языки, поддерживаемые этим шаблоном и имя политики для каждого из языков.

Далее укажем, что все (Anyone) могут просматривать (View) содержимое защищенного автором документа.

Далее укажем, что срок окончания действия политики защиты не ограничен (Never expires).

На следующем шаге укажем, что защищенное содержимое можно просматривать в браузере с помощью расширений IE (Enable users to view protected content using a browser add-on).

Протестируем созданный шаблон RMS в Outlook Web App, для чего создадим новое пустое письмо, в свойствах которого нужно щелкнуть по кнопке Set Permissions. В выпадающем меню выберите имя шаблона (Email-View-Onl-For-Anyone).

Отправим письмо, защищенное RMS, другому пользователю.

Теперь посмотрим как выглядит защищенное письмо в ящике получателя.

Как мы видим, кнопки Ответить и Переслать недоступны, а в информационной панели указан используемый шаблон защиты документа и его владелец.

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

Источник

Службы управления правами в Active Directory

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

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

В этом контексте полезно обратить внимание на корпоративные решения для управления правами (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 для внешнего взаимодействия, необходимо задействовать контейнер 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.

Экран 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, так и 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.

Экран 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.

Также следует отметить, что некоторые приложения 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

Поделитесь материалом с коллегами и друзьями

Источник