Windows rights management services что это
Как известно, информация нуждается в защите. В основном защита является эшелонированной, то есть мы предотвращаем несанкционированный доступ к конфиденциальным данным на нескольких уровнях: на сетевом, закрывая доступ по различным портам и протоколам, на уровне приложений, запрещая пользователям доступ к определенным ресурсам, или с помощью шифрования. Применяем антивирусные системы, средства обнаружения и предотвращения вторжений.
С недавних пор определенное развитие получили технологии контроля подключаемых к сети устройств (Network Admission Control), которые позволяют контролировать эти устройства на актуальность антивирусных баз, пакетов обновлений и других критически важных компонентов.
Не стоит забывать и об обеспечении безопасности на физическом уровне, ведь во многих учреждениях на проходной не то что ноутбук нельзя внести, но даже флеш-носители и КПК приходиться сдавать.
Разнообразные средства защиты, описанные выше, способны при грамотной настройке свести к минимуму вероятность несанкционированного проникновения и последующей утечки конфиденциальных данных.
Но что делать, если злоумышленнику никуда проникать не нужно по той простой причине, что он сам является сотрудником организации и у него по долгу службы есть доступ ко всем корпоративным данным. Типичным «злоумышленником» является сотрудник, собравшийся сменить работу и решивший забрать с собой конфиденциальные документы. То есть данный сотрудник может без труда скопировать любой документ себе на флешку и передать, например, конкурентам, что может привести к серьезным экономическим последствиям для организации.
Решить проблему с помощью стандартных средств шифрования нельзя, так как сотрудник должен иметь доступ к данным документам. Запрет доступа к USB-порту тоже не является полноценным решением, так как во многих компаниях USB-устройства используются для производственных нужд.
На данный момент существует ряд продуктов, предназначенных для решения проблемы. Однако я предлагаю рассмотреть средство, входящее в состав операционной системы Windows 2003/2008, не требующее каких-либо дополнительных финансовых затрат и позволяющее создавать системы защиты данных различного уровня сложности.
Промышленными решениями, предназначенными для предотвращения утечек данных, получившими распространение, являются Rights Management Services (RMS, cлужба управления правами) от Microsoft и Information Rights Management. Собственно, эти два продукта являются дополнением друг друга.
RMS представляет собой технологию защиты информации, которая используется с такими приложениями, как Microsoft Office 2003. RMS обеспечивает защиту данных от ее неправомочного использования независимо от того, где и как она используется: автономно, в закрытой брандмауэром сети или за пределами этой сети.
Служба управления правами на доступ к данным IRM расширяет возможности использования службы RMS в приложениях Microsoft Office 2003, а также в обозревателе Microsoft Internet Explorer. Служащие, работающие с информацией, теперь могут указывать тех, кому разрешено использовать документ. Также они могут определять действия, которые разрешено производить с документом. Например, они могут предоставить права на открытие, внесение изменений, печать, пересылку документа, а также на выполнение ряда других действий. Подробнее о работе связки RMS и IRM вы можете прочесть в статье [1].
Подробнее об RMS
Теперь мы рассмотрим более детально службу RMS, а затем поговорим о нововведениях в Windows Server 2008.
RMS появилась в 2003 году в качестве службы, позволяющей предотвратить несанкционированное обращение к электронной информации в онлайновом и автономном режиме. Основой технологии RMS является Extensible Rights Markup Language (XrML, расширяемый язык разметки прав доступа) версии 1.2.1. (К слову, в настоящее время доступна версия 2.0.) Разметка XrML позволяет серверному и клиентскому компонентам, которые работают совместно с приложениями RMS, обеспечивать проверку правомочности доступа и защиту документов, электронной почты и даже контента интернет-сайтов.
Служба RMS плотно интегрирована в Active Directory, поэтому перед началом проектирования внедрения необходимо продумать ряд вопросов. В частности, будет ли RMS работать только внутри организации или же будет взаимодействовать с другими компаниями-партнерами.
RMS позволяет указывать для каждого сервера по два URL: один для использования в корпоративной сети предприятия, другой – для предоставления услуг внешним пользователям через Интернет. Адрес URL для корпоративной сети указывается в момент установки, и изменить его потом достаточно сложно. Значение локатора URL для внешней сети, которое определяется после завершения установки, можно изменить в любое время.
Для работы сервера RMS требуется ADO-совместимая база данных, например, Microsoft SQL Server 2000 (желательно с пакетом обновлений SP3 или более новым). База данных служит для хранения конфигурации и журналов, а также для кэширования расширенных списков рассылки DL (distribution list). RMS и сервер баз данных должны принадлежать одному и тому же домену Active Directory.
Клиенты обращаются к серверу сертификации при активации и в момент получения RAC (Rights Management Account Certificate). При аутентификации пользователей сервер сертификации RMS обращается к серверу глобального каталога GC, к службе Microsoft Enrollment Service при развертывании и обновлении собственного сертификата издателя лицензий и к службе активации для клиентов RMS.
Таким образом, сервер RMS должен быть помещен в центральное, физически защищенное от доступа посторонних место и находиться в одном сетевом сегменте с сервером глобального каталога GC и сервером баз данных, имеющих хорошие соединения с клиентами по локальной сети и через Интернет. Специалисты Microsoft рекомендуют размещать службу RMS на отдельном сервере [3].
Посмотрим, что происходит при открытии защищенного RMS документа. При попытке открытия защищенного контента в RMS-приложении производится обращение к серверу RMS, указанному в лицензии публикации, для получения разрешения на использование этих данных. Далее приложение использует полученную лицензию для предоставления конкретному лицу возможности работать с контентом в соответствии с правами, описанными в лицензии на использование. Для ее получения необходимо сначала получить действующий сертификат учетной записи управления доступом XrML RAC (Rights Management Account Certificate). Этот сертификат выдает особый сервер сертификации RMS (RMS certification server) – впрочем, функции лицензирования и сертификации могут быть объединены на одном физическом сервере. Все действия по получению сертификата доступа RAC, если пользователь еще не имеет собственного сертификата, направляются RMS-приложением. Если на компьютере пользователя отсутствуют приложения, поддерживающие технологию RMS, можно установить модуль расширения RMA (Rights Management Add-on) для Internet Explorer. Эта бесплатная надстройка позволяет просматривать защищенный документ без возможности редактирования.
Из приведенного выше описания работы RMS очевидно, что, если организация планирует взять на вооружение RMS, до начала внедрения системы необходимо тщательно спланировать и проработать все аспекты использования технологии.
RMS в Windows Server 2008: подготовка Active Directory
Прежде чем приступить непосредственно к установке Rights Management Service, необходимо подготовить доменную среду Active Directory. Так как в качестве рабочей операционной системы у нас используется Windows Server 2008, то я вкратце опишу развертывание контроллера домена Active Directory и создание необходимой для работы RMS учетной записи. Итак, в целом процесс развертывания Active Directory в Windows Server 2008 похож на аналогичный процесс в Windows Server 2003. Но есть и некоторые изменения.
Для запуска процесса установки можно воспользоваться командой dcpromo.
Далее выбираем создание нового домена в новом лесу. Указываем имя домена (см. рис. 1).
Рисунок 1. Создание домена Active Directory
На следующем шаге нам необходимо указать функциональный уровень леса. Здесь необходимо выбрать уровень Windows 2003. Если в вашем каталоге Active Directory находятся только контроллеры домена под управлением Windows Server 2008, то вы можете указать уровень Windows 2008, однако тогда вы не сможете добавить в домен контроллеры под управлением Windows 2003 (см. рис. 2).
Рисунок 2. Функциональный уровень леса
Далее указываем, где будут храниться файлы хранилища и журналы событий. Для тестового развертывания можно использовать пути по умолчанию. Однако для реальных промышленных систем рекомендуется под хранилище и log-файлы использовать разные диски (см. рис. 3).
Рисунок 3. Пути к файлам Active Directory
Теперь необходимо создать учетную запись для RMS. Для этого в Administrative Tools выбираем Active Directory Users And Computers. После этого Action -> New -> User (см. рис. 4).
Рисунок 4. Создание пользователя RMS
При создании доменного пользователя для RMS необходимо учесть тот факт, что данная учетная запись должна отличаться от используемой для установки данной службы.
Что касается прав, необходимых данной учетной записи, то членства в группе Domain Users будет вполне достаточно.
Теперь все готово для установки службы RMS.
RMS в Windows Server 2008: установка и настройка
В отличие от предыдущих версий Windows Server, в 2008 компонента RMS интегрирована в операционную систему. Поэтому для установки RMS достаточно добавить серверную роль в окне Server Management в разделе Roles Summary (см. рис. 5).
Рисунок 5. Добавление роли RMS
Как видно, при выборе роли RMS автоматически указывается роль веб-сервера IIS. Как уже упоминалось ранее, данный компонент является необходимым для работы RMS. После выбора RMS на экран выводится полный список необходимых компонетов, которые должны быть установлены (см. рис. 6).
Рисунок 6. Компоненты, необходимые для работы RMS
На следующем шаге нам необходимо выбрать, какие дополнительные компоненты RMS требуется установить. Как видно из рис. 7, выбор у нас невелик. Компонент Identity Federation Support необходим для взаимодействия со сторонними организациями. Сейчас он нам не потребуется, так что предлагаю оставить настройки по умолчанию.
Рисунок 7. Компоненты RMS
После этого нужно определиться с хранилищем данных. В случае если вам не нужно разворачивать кластерную систему, будет вполне достаточно использования внутреннего хранилища RMS. Тогда все данные будут храниться на этом сервере. В случае если вам необходимо развернуть кластер RMS, содержащий несколько серверов, лучше использовать внешнее хранилище. Для тестового развертывания RMS нам будет вполне достаточно первого варианта (см. рис. 8).
Рисунок 8. Выбор хранилища
На следующем шаге нам необходимо указать учетную запись, под которой будет работать RMS. Выбираем учетную запись, которую мы создали ранее (см. рис. 9).
Рисунок 9. Выбор учетной записи
После этого нужно указать, как мы хотим хранить ключи, используемые для создания сертификатов. Можно использовать AD RMS-хранилище или же внешний криптографический провайдер (CSP). Будем использовать первый режим (см. рис. 10).
Рисунок 10. Хранилище ключей
Рисунок 11. Настройки WEB для RMS
После этого нам остается только подтвердить правильность указанных настроек для установки RMS и запустить процесс установки.
Теперь проверим работоспособность компонентов RMS и произведем дополнительные настройки. Для этого в консоли Administrative Tools откройте Active Directory Rights Management Services ( см . рис . 12).
Рисунок 12. Интерфейс администрирования RMS
В административном интерфейсе присутствуют шесть основных разделов:
- Trusted Policies;
- Rights Policy Templates;
- Rights Account Certificate Policies;
- Exclusion Policies;
- Security Policies;
- Reports.
В Trusted Policies содержатся Trusted User Domains, в которых находятся списки пользователей из других доменов, которым доверяет данный сервер RMS. Также в этом разделе присутствует Trusted Publishing Domains, в котором приводятся списки доменов в других лесах, которым доверяет данный RMS. Для того чтобы добавить новые данные в каждый из этих разделов, можно воспользоваться средствами экспорта.
Раздел Rights Policy Templates содержит шаблоны, которые определяют Права пользователей для работы с теми или иными документами (Word, Excel). Здесь также можно указать, какое время должны действовать эти правила.
Следующий раздел – Rights Account Certificate Policies – определяет правила для сертификатов. В частности, здесь определяется срок, в течение которого сертификат может использоваться.
Exclusion Policies представляет собой политики для исключений. В частности, здесь можно определить исключения для приложений, к которым применяется RMS, также можно исключить определенных пользователей и версии операционной системы.
Политики Security Policies определяют, какие действия могут производить пользователи. Например, кто является суперпользователем, кто может изменять свой пароль на документы и т.д.
Раздел Reports предназначен для настройки отчетов, в которых содержится информация об учетных записях, использованных сертификатах, а также об использовании федеративных отношений.
Клиентская часть RMS
Теперь поговорим о том, что должно быть установлено на клиентской рабочей станции для функционирования RMS. Клиент службы AD RMS входит в стандартную поставку ОС Windows Vista. Предыдущие версии этого клиента, предназначенные для других операционных систем семейства Windows, можно загрузить из Интернета. После этого для обеспечения доступности шаблонов политик прав необходимо провести дополнительную настройку рабочей станции клиента службы AD RMS. Для этого необходимо скопировать шаблоны политик прав службы AD RMS на клиентский компьютер и создать параметр реестра, указывающий на расположение этих шаблонов.
Клиент службы AD RMS сможет находить шаблоны политик прав службы AD RMS только после создания параметра реестра и локальной копии шаблонов. Для решения этих задач перед организацией защиты документа необходимо выполнить следующие изменения в реестре. Чтобы автоматизировать процесс, можно подготовить reg-файл для внесения изменений в следующий раздел реестра. В ветке HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Common\DRM необходимо добавить параметр AdminTemplatePath. В этом параметре нужно указать значение %UserProfile%\AppData\Microsoft\DRM\Templates, где %UserProfile% является псевдонимом пути C:\Users\< имя _ пользователя >. После этого убедитесь, что все папки, указанные в данном пути, существуют. Затем с сервера \\имя_сервера_RMS\ADRMSTemplates необходимо скопировать в указанную выше папку созданные шаблоны политик.
В качестве примера создадим тестовый шаблон и проверим его работу на тестовой рабочей станции.
В консоли администрирования Active Directory Rights Management Services выберите запись LocalHost. В секции Tasks (задачи) области результатов выберите пункт Manage rights policy templates (управление шаблонами политики прав). Для того чтобы разрешить экспорт шаблонов политик прав службы AD RMS, нажмите кнопку Properties в области Actions (действия). После этого необходимо установить флажок Enable export (разрешить экспорт), введите путь \\имя_сервера_RMS\ADRMSTemplates в поле Specify templates file location (расположение файла шаблонов (UNC)), после чего нажмите кнопку OK.
К сожалению, пока RMS по различным причинам не получил широкого распространения. Но стоит отметить, что проблема утечки информации и ее несанкционированного распространения инсайдерами становится все острее, и поэтому в будущем технологии, аналогичные RMS, получат более широкое распространение.
Microsoft Windows Rights Management Services (RMS) - это дополнительная служба для Windows Server 2003 (R2) в редакциях Standard, Enterprise, Web и Datacenter, помогающая предотвратить несанкционированное обращение к электронной информации в онлайновом и автономном режиме, внутри границ корпоративного брандмауэра и за его рамками.
RMS расширяет стратегию безопасности предприятия, защищая информацию с помощью строгих политик использования, которые сопровождают эти данные, куда бы они не попали. Сотрудники, работающие с информацией, могут четко определить, как адресат может использовать полученную информацию. В частности, можно определить, кто может открывать, редактировать, переадресовывать и/или выполнять иные операции с этой информацией. Организации могут создавать собственные шаблоны политик разграничения доступа, такие как «Конфиденциально-Только для чтения». Эти шаблоны можно непосредственно применять к таким документам, как стратегические бизнес-планы, финансовые отчеты, спецификации продукции, сведения о клиентах и электронные письма.
Ограничение режима просмотра и использования
Шифрование ограничивает аудиторию просмотра данных – это смогут делать только уполномоченные пользователи Используются строгие и постоянные политики разграничения доступа к информации Политики разграничения доступа управляют использованием информации Автор информации сам применяет необходимую политику с помощью приложения, поддерживающего технологию RMS Данные об ограничении прав хранятся в самом документе на уровне файловой системы Вся защита работает в интерактивном и автономном режиме, внутри границ корпоративного брандмауэра и за его рамками
Надежность решения
Используются встроенные возможности и утилиты Windows Server 2003 Промышленные технологии защиты информации — шифрование, сертификаты на базе стандарта XrML, проверка подлинности Гибкая технология с возможностями индивидуальной доработки Набор инструментов разработчика RMS SDK содержит интегрированный SDK для клиентов и серверов RMS Защиту секретной информации обеспечивает любое приложение с поддержкой RMS Позволяет сторонним разработчикам информационных технологий интегрировать средства защиты информации в свои продукты для создания универсальных платформенных решений
Преимущества
Интеграция с другими продуктами Microsoft
Microsoft RMS позволяет защищать информацию не только внутри корпоративной сети, но и данные, отправляемые за ее пределы.
Назначение и отличия динамического контроля доступа от списков ACL
Как я уже отметил в большой вводной части первой статьи, посвященной этой технологии, динамический контроль доступа позволяет вам по-новому взглянуть на механизм предоставления общего доступа к корпоративным ресурсам, расположенным преимущественно на контроллерах домена и файловых серверах, работающих под управлением операционной системы Windows Server 2012. Так почему же мы сможем взглянуть на предоставление доступа по-новому, и чем же тут так не угодили списки контроля доступа?
Прежде всего, давайте вспомним, каким же образом предоставлялся доступ к ресурсам до выхода этой, пока еще загадочной, технологии.
Как раньше назначались разрешения доступа?
- Избирательные таблицы управления доступом (Discretionary access control list, DACL). Как известно из официальных источников, в DACL указаны пользователи и группы, которым явным образом разрешен или запрещен доступ к объекту. По вполне понятной причине, если определенный пользователь или группы, в которые он входит, явно не указаны в DACL, этому пользователю будет запрещен доступ к объекту. По умолчанию DACL управляется владельцем объекта или пользователем, который создал этот объект, и содержит записи управления доступом (ACE — Access control entries), определяющие доступ пользователя к объекту;
- Системные таблицы управления доступом (System access control list, SACL). В свою очередь, в SACL указаны пользователи и группы, для которых требуется выполнять аудит успешных и безуспешных попыток доступа к объекту. Аудит служит для наблюдения за событиями, относящимися к безопасности системы или сети, а также для обнаружения недостатков в системе безопасности и для определения объемов и расположения любых повреждений. По умолчанию, как и в случае с DACL, SACL управляется владельцем объекта или создавшим его пользователем. SACL содержит записи управления доступом, определяющие, требуется ли записывать успешные или безуспешные попытки доступа пользователя к объекту с использованием данного разрешения, например, «Полный доступ» или «Чтение».
А чем же лучше динамический контроль доступа?
Собственно, исходя из того, что собой представляет предоставление доступа на основании списков управления доступом, можно прийти к такому выводу, что при использовании такого метода разрешения предоставляются исключительно основываясь на членстве конечного объекта в определенной группе. Вы не можете ограничивать или, наоборот, разрешать доступ для конкретного устройства пользователя, основываясь на каких-то сторонних характеристиках, а также, само собой, о каких-либо нестандартных сценариях можно сразу забыть.
Динамический контроль доступа, в свою очередь, снимает эти ограничения и позволяет создавать более гранулированные правила, основываясь на которых вы можете предоставлять доступ согласно различным критериям. Другими словами, в первую очередь стоит обратить внимание на то, что эта технология предоставляет возможность управления доступом к файлам и данным посредством создания централизованных политик безопасности, позволяя наиболее подробным образом определять, кто вправе использовать ту или иную информацию. Иначе говоря, вы можете создавать такие политики, которые будут наилучшим образом отражать стратегию вашего бизнеса и полностью соответствовать любым нормативным требованиям. Более того, идентифицировать такую информацию вы можете при использовании классификации файлов, как в ручном, так и в автоматическом режиме. Только эти две возможности практически моментально могут уложить на лопатки управление доступом при использовании списков ACL.
Однако это еще не все. Самые распространенные типы данных, к которым предоставляют доступ, – это офисные документы, то есть файлы, которыми можно управлять при помощи продуктов Microsoft Office. Раньше для того, чтобы задать конкретным пользователям или группам уникальные разрешения с шифрованием документов, для каждого такого документа использовалась служба управления правами Active Directory, то есть AD RMS. Эта технология себя отлично зарекомендовала и сейчас, с появлением динамического контроля доступом, вам предоставляется возможность применения защиты RMS, с использованием автоматического шифрования на основе конкретных критериев.
В наше время одним из самых ценных активов многих компаний является не что иное, как сама информация, которая не должна выходить за пределы организации. Неправомерное использование такой информации может пагубно повлиять на дальнейшую судьбу всей компании. Благодаря централизованным политикам аудита данной технологии, вы можете создавать отчеты для дальнейшего проведения аудита доступа к файлам или же, в случае крайней необходимости, криминалистического анализа. Другими словами, вам не нужно будет прибегать к использованию каких-либо сторонних приложений и программных продуктов.
Что еще можно выделить помимо этого? А можно выделить то, что текущую технологию вы можете использовать, не внося изменений в схему Active Directory, без развертывания дополнительных ролей или же какого-то специфического программного обеспечения, да и, вообще, как говорится, «прямо из коробки». Более того, специально для реализации возможности использования динамического контроля доступа был разработан новый механизм авторизации и аудита для операционных систем Windows, а также для возможностей проверки подлинности Kerberos были реализованы некоторые новшества, о которых я уже писал в третьей части статьи про Kerberos, которая называлась «Сетевой протокол аутентификации Kerberos или зачем нужны утверждения».
А есть ли у него какие-то ограничения?
К сожалению, как и следовало ожидать, у данной технологии также есть некоторый ряд ограничений. Прежде всего, в организации должны быть развернуты доменные службы Active Directory. То есть, если вы захотите воспользоваться динамическим контролем доступа для компьютеров, входящих в состав рабочей группы, у вас ничего из этого не выйдет. Во-вторых, динамический контроль доступа – это не просто отдельная функциональная возможность. Эта технология представляет собой решение для файловых серверов, построенное на основании инфраструктуры Windows Server 2012, включающее поддержку прямых утверждений Kerberos, поддержку Active Directory специально для хранения свойств ресурсов, а также утверждений пользователей и компьютеров, поддержку Active Directory специально для хранения централизованных политик доступа, реализацию распространения таких централизованных политик доступа средствами функциональных возможностей групповой политики, а также многое другое.
Следовательно, согласно всем этим требованиям, можно сделать такой вывод: у вас в организации должен быть развернут как минимум один контроллер домена под управлением операционной системы Windows Server 2012, а также, в том случае, если в вашем лесу развернуто несколько доменов, то в каждом таком домене должно быть развернуто хотя бы по одному контроллеру домена под Windows Server 2012. Это делается специально для возможности использования утверждений между доменами, для которых установлены доверительные отношения. Да и более того, как я уже говорил, в Windows Server 2012 служба KDC была значительно усовершенствована специально для работы с утверждениями в рамках билета Kerberos.
Операционной системой на файловом сервере, естественно, должна быть Windows Sever 2012. Когда пользователь подключается к общей папке, файловый сервер выполняет проверку доступа к ресурсу, используя учетные данные входящего подключения. Это означает, что файловый сервер определяет доступ к общедоступному ресурсу. Это также означает, что различные компоненты на файловом сервере должны поддерживать утверждения, такие как LSA и сервер приложений Kerberos. Получается, файловый сервер, на котором будут располагаться данные, к которым пользователи будут получать доступ, должны быть в состоянии считать утверждения и данные авторизации устройства из билета Kerberos, перевести эти идентификаторы безопасности (SID) и утверждения билета в маркер проверки подлинности и сравнить данные авторизации в маркере с условиями, включенными в дескрипторе безопасности. То есть более старые версии ОС, как следствие, не подойдут.
Ну а в том случае, если у вас будут указаны утверждения для устройств, в качестве клиентов могут использоваться исключительно компьютеры под управлением операционных систем Windows 8 или Windows Server 2012. Другими словами, это ограничение можно назвать веской причиной для миграции клиентов на восьмерку.
Ключевые сценарии использования динамического контроля доступа
Хотите знать больше?
Я сам прекрасно знаю, что порою сугубо теоретическая часть может быть очень унылой, особенно в том случае, если сразу подается уйма материала. Однако, любая практика без теоретической базы – это неправильный подход к изучению материала. В следующих статьях этого цикла, как я уже отметил ранее, вы узнаете о том, что же такое утверждения, как они создаются и какие в течение этого процесса могут встретиться подводные камни; узнаете о том, какие существуют свойства ресурса. Я подробнее остановлюсь на различных нюансах при создании централизованных политик и правил доступа, и, конечно, будет рассказано о том, как именно можно опубликовывать и применять такие централизованные политики доступа. Будут рассмотрены все сценарии, которые мельком были упомянуты несколькими абзацами выше. Кое-что узнаете об аудите и еще мы с вами посмотрим на классификацию различных файлов и папок. Более того, я обязательно посвящу отдельную статью вопросам устранения возможных неполадок, связанных с динамическим контролем доступа.
В целом, я надеюсь, что эта статья не была для вас чересчур утомительной и у вас не пропало желание узнать больше об использовании этой технологии. В свою очередь, следующие статьи, естественно, не будут обладать обильным количеством теоретического материала, а в них будут преимущественно рассматриваться сценарии, различные процедуры и пошаговые примеры использования этой технологии.
Чтобы обеспечить единый и оптимизированный клиентский процесс, классические клиенты Azure Information Protection и управление наклейками на портале Azure не будут готовы к управлению с 31 марта 2021 г. Поддержка классических версий клиента больше не предоставляется, а версии обслуживания больше не выпускаются.
Классические клиенты будут официально отменены и перестанут работать 31 марта 2022 г.
Все клиенты классической службы Azure Information Protection должны перейти на единую платформу Microsoft Information Protection меток и перейти на единый клиент наклеев. Подробнее читайте в блоге о миграции.
Azure Rights Management (Azure RMS) — это облачная технология защиты, используемая Azure Information Protection.
Например, когда сотрудники отправьте документ партнеру по электронной почте или сохраните его на своем облачном диске, постоянная защита Azure RMS помогает защитить данные.
Параметры защиты остаются вместес данными , даже если они выходит за границы организации, и ваш контент остается защищенным как внутри, так и за ее пределами.
Azure RMS может быть юридически требоваться для соблюдения нормативных требований, юридических требований и лучших методик по управлению информацией.
Azure RMS гарантирует, что авторизованные люди и службы, такие как поиск и индексация, смогут продолжать читать и проверять защищенные данные.
Обеспечение постоянного доступа для авторизованного человека и служб, также известного как "причины для данных", является важным элементом при сохранении контроля за данными организации. Это может быть непросто сделать с помощью других решений защиты информации, которые используют одноранговую шифрование.
Функции защиты
| Функция | Описание |
|---|---|
| Защита файлов нескольких типов | На ранних стадиях реализации системы управления правами можно было защищать только Office файлы с помощью встроенной защиты управления правами. Azure Information Protection поддерживает дополнительные типы файлов. Дополнительные сведения см. в сведениях о поддерживаемых типах файлов. |
| Защита файлов отовсюду | Когда файл защищен,защита остается с ним, даже если он сохранен или скопирован в хранилище, которое не находится под управлением ИТ-службы, например в облачное хранилище. |
Функции совместной работы
Функции поддержки платформы
Azure RMS поддерживает широкий спектр платформ и приложений, в том числе:
| Функция | Описание |
|---|---|
| Commonly used devices не только Windows компьютеров | Client devices include: - Windows computers and phones - Mac computers - iOS tablets and phones - Планшеты и телефоны с Android |
| Локальное обслуживание | In addition to working seamlessly with Office 365, use Azure Rights Management with the following on-premises services when you deploy the RMS connector: - Exchange Server - SharePoint Server - Windows Server с инфраструктурой классификации файлов |
| Extensibility (Доступность приложений) | Служба управления правами Azure тесно интегрирована с приложениями и службами Microsoft Office и расширяет поддержку других приложений с помощью клиента Azure Information Protection. Средство Microsoft Information Protection SDK предоставляет внутренним разработчикам и поставщикам программного обеспечения API для написания пользовательских приложений, которые поддерживают Azure Information Protection. Дополнительные сведения см. в других приложениях, поддерживаюх API управления правами. |
Функции инфраструктуры
Azure RMS предоставляет следующие функции для поддержки ИТ-отделов и инфраструктурных организаций:
Организации всегда имеют возможность прекратить использование службы управления правами Azure, не потеряв доступ к содержимому, которое ранее было защищено службой управления правами Azure.
Дополнительные сведения см. в руководстве По эксплуатации и отключению службы управления правами Azure.
Создание простых и гибких политик
Настроенные шаблоны защиты предоставляют администраторам быстрое и простое решение для применения политик, а также для того, чтобы пользователи применяли правильный уровень защиты для каждого документа и ограничив доступ пользователям в организации.
Например, чтобы документ стратегии в масштабе организации был общим для всех сотрудников, применим политику только для чтения для всех внутренних сотрудников. Для более конфиденциального документа, например финансового отчета, ограничить доступ только для руководителей.
Настройте политики меток в Центр соответствия требованиям Microsoft 365.
Единый клиент меток:используйте Центр соответствия требованиям Microsoft 365. Дополнительные сведения см. в документации по меткам конфиденциальности для Microsoft 365.
Классический клиент:используйте портал Azure. Дополнительные сведения см. в сведениях о настройке шаблонови управлении их использованием в Azure Information Protection.
Простая активация
Для новых подписок активация активна автоматически. Для активации службы управления правами требуется всего несколько щелчков на портале управления или две команды PowerShell.
Службы аудита и мониторинга
Проверяйте и отслеживайте использование защищенных файлов даже после того, как эти файлы покидают границы организации.
Аудит Azure RMS может предоставлять следующие сведения:
Открывали ли партнеры Fabrikam документ и когда.
Администраторы AIP могут отслеживать использование документов и отопорять доступ к Office файлам. Пользователи могут при необходимости отоблескить доступ к защищенным документам.
Возможность масштабирования в масштабах организации
Так как служба управления правами Azure выполняется как облачная служба с гибкостью Azure для ее масштабирования и развертывания, вам не нужно будет дополнительно размещать или размещать дополнительные серверы.
Управление ИТ-данными
Организации могут воспользоваться такими функциями ИТ-контроля, как:
Требования к безопасности, соответствии требованиям и нормативным требованиям
Служба управления правами Azure поддерживает следующие требования к безопасности, соответствии требованиям и нормативным требованиям:
Использование отраслевых стандартов шифрования и поддержка FIPS 140–2. Дополнительные сведения см. в элементе управления "Шифрование", используемом службой Azure RMS: алгоритмы и сведения о длине ключа.
Поддержка модуля безопасности оборудования nCipher nShield для хранения ключа клиента в Microsoft Azure центрах обработки данных.
В службе управления правами Azure используются отдельные миры безопасности для центров обработки данных в Северной Америке, EMEA (Европа, Средний Восток и Африка) и Азии, поэтому ключи можно использовать только в вашем регионе.
Сертификация для следующих стандартов:
- ISO/IEC 27001:2013 (./includes ISO/IEC 27018)
- SoC 2 SSAE 16/ISAE 3402 attestations
- HIPAA BAA
- Предложение модели ЕС
- FedRAMP в рамках Azure Active Directory сертификации Office 365, выданной управлением агентства FedRAMP для работы с HHS
- PCI DSS level 1
Дополнительные сведения об этих внешних сертификациях см. в центре управления доверием Azure.
Дальнейшие действия
Дополнительные технические сведения о том, как работает служба управления правами Azure, см. в этом руководстве.
Если вы знакомы с локальной версией службы управления правами службы Active Directory Rights Management (AD RMS), вам может быть интересна таблица сравнения azure Rights Management и AD RMS.
Читайте также: