Разное

Rms microsoft: Как работает Azure RMS — Azure Information Protection

Содержание

Как работает Azure RMS — Azure Information Protection

  • Статья
  • Чтение занимает 9 мин

Важно понимать, как работает Azure RMS, так как эта служба защиты данных из Azure Information Protection не отображает и не хранит ваши данные в процессе защиты. Сведения, которые вы защищаете, никогда не отправляются в Azure и не хранятся в Azure, если вы явно не сохраните их в Azure или не используете другую облачную службу, которая хранит ее в Azure. Azure RMS просто делает данные в документе нечитаемыми для всех, кроме авторизованных пользователей и служб:

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

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

На высоком уровне вы можете увидеть, как работает этот процесс на следующем рисунке. Документ, содержащий формулу секрета, защищен, а затем успешно открыт авторизованными пользователем или службой. Документ защищен ключом содержимого (зеленым ключом на этом рисунке). Он уникален для каждого документа и помещается в заголовок файла, где он защищен корневым ключом клиента Azure Information Protection (красный ключ на этом рисунке). Ключ клиента может быть создан и управляется корпорацией Майкрософт, а также вы можете создавать собственный ключ клиента и управлять этим ключом.

В процессе защиты, когда Azure RMS шифрует и расшифровывается, авторизует и применяет ограничения, формула секрета никогда не отправляется в Azure.

Подробное описание происходящего см. в пошаговом руководстве по принципу работы Azure RMS: «Первое использование», «Защита содержимого», «Потребление содержимого» в этой статье.

Технические сведения об алгоритмах и длине ключей, используемых Azure RMS, см. в следующем разделе.

Криптографические элементы управления, используемые в Azure RMS: алгоритмы и длина ключа

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

Криптографические элементы управленияИспользование в Azure RMS
Алгоритм: AES

Длина ключа: 128 и 256 бит [1]

Защита содержимого
Алгоритм: RSA

Длина ключа: 2048 бит [2]

Защита ключей
SHA-256Подписывание сертификата
Сноска 1

256 бит используется клиентом Azure Information Protection в следующих сценариях:

  • Универсальная защита (PFILE).

  • Собственная защита pdf-документов, если документ защищен стандартом ISO для шифрования PDF или полученный защищенный документ имеет расширение PPDF-файла.

  • Собственная защита для текстовых файлов или файлов изображений (например, PTXT или PJPG).

Сноска 2

2048 бит — это длина ключа при активации службы Azure Rights Management. 1024 бита поддерживаются для следующих необязательных сценариев:

  • Во время миграции из локальной среды, если кластер AD RMS работает в режиме шифрования 1.

  • Для архивных ключей, созданных локально до миграции, чтобы содержимое, ранее защищенное службой AD RMS, можно было по-прежнему открывать службой Azure Rights Management после миграции.

Хранение и защита криптографических ключей Azure RMS

Для каждого документа или электронной почты, защищенных с помощью Azure RMS, Azure RMS создает один ключ AES (ключ содержимого), который внедряется в документ и сохраняется в выпусках документа.

Ключ содержимого защищен с помощью ключа RSA организации (ключа клиента Azure Information Protection) в рамках политики в документе, а политика также подписана автором документа. Этот ключ клиента является общим для всех документов и сообщений электронной почты, защищенных службой Azure Rights Management для организации, и этот ключ может быть изменен администратором Azure Information Protection только в том случае, если организация использует ключ клиента, управляемый клиентом (или BYOK).

Этот ключ клиента защищен в среде майкрософт веб-службы в среде с высоким уровнем контроля и в режиме близкого мониторинга. При использовании ключа клиента, управляемого клиентом (BYOK), эта безопасность повышается за счет использования массива высокопроизводиемых аппаратных модулей безопасности (HSM) в каждом регионе Azure без возможности извлечения, экспорта или совместного использования ключей ни при каких обстоятельствах. Дополнительные сведения о ключе клиента и BYOK см. в разделе «Планирование и реализация ключа клиента Information Protection Azure».

Лицензии и сертификаты, отправляемые на устройство Windows, защищены с помощью закрытого ключа устройства клиента, который создается при первом запуске пользователя на устройстве с помощью Azure RMS. Этот закрытый ключ, в свою очередь, защищен с помощью DPAPI на клиенте, который защищает эти секреты с помощью ключа, производного от пароля пользователя. На мобильных устройствах ключи используются только один раз, поэтому, так как они не хранятся на клиентах, эти ключи не нужно защищать на устройстве.

Пошаговое руководство по использованию Azure RMS: первое использование, защита содержимого, потребление содержимого

Чтобы более подробно понять, как работает Azure RMS, давайте рассмотрим типичный поток после активации службы Azure Rights Management и когда пользователь впервые использует службу Rights Management на компьютере Windows (процесс, иногда называемый инициализализакой пользовательской среды или начальной загрузкой), защищает содержимое (документ или электронную почту), а затем использует (открывает и использует) содержимое, защищенное другими пользователями.

После инициализации пользовательской среды этот пользователь может защитить документы или использовать защищенные документы на этом компьютере.

Примечание

Если этот пользователь переходит на другой Windows компьютера или другой пользователь использует этот же Windows компьютере, процесс инициализации повторяется.

Инициализация пользовательской среды

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

Что происходит на шаге 1. Клиент RMS на компьютере сначала подключается к службе Azure Rights Management и проверяет подлинность пользователя с помощью своей учетной записи Azure Active Directory.

Если учетная запись пользователя является федеративной с Azure Active Directory, эта проверка подлинности выполняется автоматически и пользователю не предлагается ввести учетные данные.

Что происходит на шаге 2. После проверки подлинности пользователя подключение автоматически перенаправляется в клиент Azure Information Protection организации, который выдает сертификаты, позволяющие пользователю выполнять проверку подлинности в службе Azure Rights Management для использования защищенного содержимого и защиты содержимого в автономном режиме.

Один из этих сертификатов — это сертификат учетной записи управления правами, который часто сокращается до RAC. Этот сертификат выполняет проверку подлинности пользователя Azure Active Directory и действителен в течение 31 дня. Сертификат автоматически обновляется клиентом RMS, если учетная запись пользователя по-прежнему Azure Active Directory и учетная запись включена. Администратор не может настроить этот сертификат.

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

Защита содержимого

Когда пользователь защищает документ, клиент RMS выполняет следующие действия с незащищенным документом:

Что происходит на шаге 1. Клиент RMS создает случайный ключ (ключ содержимого) и шифрует документ с помощью этого ключа с помощью алгоритма симметричного шифрования AES.

Что происходит на шаге 2. Затем клиент RMS создает сертификат, содержащий политику для документа, которая включает права на использование для пользователей или групп, а также другие ограничения, такие как дата окончания срока действия. Эти параметры можно определить в шаблоне, настроенном администратором ранее, или указать во время защиты содержимого (иногда называемую «нерегламентированной политикой»).

Основным атрибутом Azure AD, используемым для идентификации выбранных пользователей и групп, является атрибут Azure AD ProxyAddresses, в котором хранятся все адреса электронной почты пользователя или группы. Однако если у учетной записи пользователя нет значений в атрибуте AD ProxyAddresses, вместо нее используется значение UserPrincipalName пользователя.

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

Что происходит на шаге 3. Наконец, клиент RMS внедряет политику в файл с зашифрованным ранее текстом документа, который вместе состоит из защищенного документа.

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

Потребление содержимого

Когда пользователь хочет использовать защищенный документ, клиент RMS начинает с запроса доступа к службе Azure Rights Management:

Что происходит на шаге 1. Прошедший проверку подлинности пользователь отправляет политику документов и сертификаты пользователя в службу Azure Rights Management. Служба расшифровывается и оценивает политику, а также создает список прав (при наличии) пользователя для документа. Для идентификации пользователя используется атрибут Azure AD ProxyAddresses для учетной записи пользователя и групп, участником которых является пользователь. Из соображений производительности членство в группах кэшируется. Если учетная запись пользователя не имеет значений для атрибута Azure AD ProxyAddresses, вместо этого используется значение в Azure AD UserPrincipalName.

Что происходит на шаге 2. Затем служба извлекает ключ содержимого AES из расшифрованной политики. Затем этот ключ шифруется с помощью открытого ключа RSA пользователя, полученного с помощью запроса.

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

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

Клиент также расшифровывается список прав и передает их приложению, которое применяет эти права в пользовательском интерфейсе приложения.

Примечание

Когда пользователи, не влияемые на вашу организацию, используют защищенное содержимое, поток потребления будет одинаковым. Изменения в этом сценарии — способ проверки подлинности пользователя. Дополнительные сведения см. в статье «Предоставление общего доступа к защищенному документу другому пользователю за пределами моей компании». Как этот пользователь получает проверку подлинности?

Вариации

В предыдущих пошаговых руководствах рассматриваются стандартные сценарии, но существуют некоторые варианты.

  • Защита электронной почты: при Exchange Online и Office 365 сообщений с новыми возможностями используется для защиты сообщений электронной почты, проверка подлинности для использования также может использовать федерацию с поставщиком удостоверений социальных сетей или с помощью однофакторного секретного кода. Затем потоки процесса очень похожи, за исключением того, что потребление содержимого происходит на стороне службы в сеансе веб-браузера через временно кэшированную копию исходящего сообщения электронной почты.

  • Мобильные устройства: когда мобильные устройства защищают или используют файлы с помощью службы Azure Rights Management, процессы гораздо проще. Мобильные устройства сначала не проходит процесс инициализации пользователей, так как каждая транзакция (для защиты или использования содержимого) является независимой. Как и Windows компьютеров, мобильные устройства подключаются к службе Azure Rights Management и аутентификация. Для защиты содержимого мобильные устройства отправляют политику, а служба Azure Rights Management отправляет им лицензию на публикацию и симметричный ключ для защиты документа. Чтобы использовать содержимое, когда мобильные устройства подключаются к службе Azure Rights Management и аутентификация, они отправляют политику документов в службу Azure Rights Management и запрашивают лицензию на использование документа. В ответ служба Azure Rights Management отправляет необходимые ключи и ограничения на мобильные устройства. Оба процесса используют протокол TLS для защиты обмена ключами и других коммуникаций.

  • Соединитель RMS. При использовании службы Azure Rights Management с соединителем RMS потоки процесса остаются неизменными. Единственным отличием является то, что соединитель выступает в качестве ретранслятора между локальными службами (такими как Exchange Server и SharePoint Server) и службой Azure Rights Management. Сам соединитель не выполняет никаких операций, таких как инициализация пользовательской среды, шифрование или расшифровка. Он просто передает обмен данными, которые обычно передаются на сервер AD RMS, обрабатывая преобразование между протоколами, используемыми на каждой стороне. Этот сценарий позволяет использовать службу Azure Rights Management с локальными службами.

  • Универсальная защита (PFILE): когда служба Azure Rights Management универсально защищает файл, поток по сути одинаковый для защиты содержимого, за исключением того, что клиент RMS создает политику, предоставляющую все права. При использовании файла он расшифровывается перед передачей в целевое приложение.

    Этот сценарий позволяет защитить все файлы, даже если они изначально не поддерживают RMS.

  • Учетные записи Майкрософт: Azure Information Protection может авторизовать адреса электронной почты для использования при проверке подлинности с помощью учетной записи Майкрософт. Однако не все приложения могут открывать защищенное содержимое, если для проверки подлинности используется учетная запись Майкрософт. Дополнительные сведения.

Дальнейшие действия

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

Ознакомьтесь с терминологией azure Information Protection, чтобы ознакомиться с терминами, которые могут возникнуть при настройке и использовании службы Azure Rights Management, а также проверьте требования к Azure Information Protection перед началом развертывания. Если вы хотите сразу и попробовать его самостоятельно, воспользуйтесь кратким руководством и руководствами:

  • Краткое руководство. Развертывание клиента унифицированных меток
  • Руководство по установке сканера унифицированных меток Azure Information Protection (AIP)
  • Руководство. Поиск конфиденциального содержимого с помощью сканера Azure Information Protection (AIP)
  • Руководство по Предотвращение переполнения в Outlook с помощью Azure Information Protection (AIP)

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

Совет

Для получения дополнительных сведений и справки используйте ресурсы и ссылки в разделе «Сведения и поддержка azure Information Protection».

Что такое управление правами Azure? . AIP

  • Статья
  • Чтение занимает 6 мин

Azure Rights Management (Azure RMS) — это облачная технология защиты, используемая Azure Information Protection.

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

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

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

  • Azure RMS может официально требоваться для соблюдения соответствия, юридических требований к обнаружению или рекомендаций по управлению информацией.

  • Azure RMS используется с подписками на Microsoft 365 или с подписками на Azure Information Protection.

    Дополнительные сведения см. в руководстве по лицензированию Microsoft 365 для обеспечения соответствия требованиям безопасности&.

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

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

Функции защиты

КомпонентОписание
Защита файлов нескольких типовВ ранних версиях Rights Management можно было защищать только файлы Office при помощи встроенной защиты Rights Management. Azure Information Protection обеспечивает поддержку дополнительных типов файлов. Дополнительные сведения см. в разделе Поддерживаемые типы файлов.
Повсеместная защита файловКогда файл защищен, эта защита остается с файлом, даже если он сохраняется или копируется в хранилище, которое не находится под управлением ИТ-служб, например в службу облачного хранения.

Функции совместной работы

КомпонентОписание
Безопасное предоставление доступа к информацииЗащищенными файлами, например вложением в сообщении электронной почты или ссылкой на сайт SharePoint, можно безопасно делиться с другими пользователями. Если конфиденциальная информация находится в сообщении электронной почты, защитите его или используйте параметр «Не пересылать » из Outlook.
Поддержка совместной работы типа «бизнес-бизнес»Так как Azure Rights Management — это облачная служба, вам не нужно явным образом настраивать доверительные отношения с другими организациями, чтобы совместно использовать защищенное содержимое. Совместная работа с другими организациями, у которых уже есть Каталог Microsoft 365 или Azure AD, автоматически поддерживается. Для организаций без Microsoft 365 или каталога Azure AD пользователи могут зарегистрироваться для получения бесплатной подписки RMS для частных лиц или использовать учетную запись Майкрософт для поддерживаемых приложений.

Совет

Вложение защищенных файлов вместо защиты всего сообщения электронной почты позволяет не шифровать текст сообщения.

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

Возможности поддержки платформ

Azure RMS поддерживает широкий спектр платформ и приложений, в том числе:

КомпонентОписание
Часто используемые устройства не только компьютеры с WindowsК клиентским устройствам относятся: — компьютеры с Windows и телефоны — компьютеры Mac — планшеты iOS и телефоны — планшеты Android и телефоны
Локальные службыПомимо эффективной работы с Office 365, используйте Службу управления правами Azure со следующими локальными службами при развертывании соединителя RMS: — Exchange Server — SharePoint Server — Windows Server под управлением инфраструктуры классификации файлов.
Расширяемость приложенийAzure Rights Management тесно интегрируется с приложениями и службами Microsoft Office, а также поддерживает другие приложения благодаря использованию клиента Azure Information Protection. Пакет SDK Microsoft informācijas aizsardzība предоставляет внутренним разработчикам и поставщикам программного обеспечения API для написания пользовательских приложений, поддерживающих Information Protection Azure. Дополнительные сведения см. в разделе «Другие приложения, поддерживающие API Rights Management».

Функции инфраструктуры

Azure RMS предоставляет следующие возможности для поддержки ИТ-отделов и инфраструктурных организаций:

  • Создание простых и гибких политик
  • Простая активация
  • Аудит и мониторинг служб
  • Возможность масштабирования в пределах организации
  • ИТ-контроль над данными

Примечание

Организации всегда могут прекратить использование службы Azure Rights Management без потери доступа к содержимому, которое ранее было защищено с помощью Azure Rights Management.

Дополнительные сведения см. в статье » Списание и деактивация Службы управления правами Azure».

Создание простых и гибких политик

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

Например, чтобы предоставить общий доступ к корпоративному стратегическому документу для всех сотрудников, примените для всех внутренних сотрудников политику «только для чтения». Применительно к более конфиденциальному документу, например финансовому отчету, предоставьте доступ только руководителям.

Настройте политики маркировки на портале соответствия Требованиям Microsoft Purview. Дополнительные сведения см. в документации по меткам конфиденциальности для Microsoft 365.

Простая активация

Для новых подписок активация проводится автоматически. В существующих подписках для включения службы Rights Management достаточно нескольких щелчков мышью на портале управления или двух команд PowerShell.

Аудит и мониторинг служб

Проводите аудит и контролируйте использование защищенных файлов даже после того, как они покидают пределы организации.

Например, если сотрудник компании Contoso, Ltd участвует в совместном проекте с тремя сотрудниками компании Fabrikam, Inc, он может отправить им документ, на который установлена защита и который разрешено только читать.

Функция аудита системы RMS Azure может предоставлять следующую информацию:

  • открывали ли партнеры из компании Fabrikam этот документ и в какое время;

  • совершали ли другие пользователи, которых вы не указали, неудачные попытки открыть документ. Это может произойти, если сообщение было переслано или сохранено в общем расположении.

Администраторы AIP могут отслеживать использование документов и отзывать доступ к файлам Office. При необходимости пользователи могут отзывать доступ к своим защищенным документам.

Возможность масштабирования в пределах организации

Azure Rights Management функционирует как облачная служба, которой присуща эластичность Azure (возможности вертикального увеличения и уменьшения масштаба), поэтому вам не нужно подготавливать или развертывать дополнительные локальные серверы.

ИТ-контроль над данными

Организации могут использовать возможности ИТ-управления, в том числе следующие:

КомпонентОписание
Управление ключом клиентаИспользуйте решения для управления ключом клиента, такие как создание собственных ключей (BYOK) и двойное шифрование ключей (DKE).

Дополнительные сведения см. в следующих статьях:
— Планирование и реализация ключа клиента AIP
— DKE в документации по Microsoft 365.

Аудит и ведение журнала использованияИспользуйте функции аудита и ведения журнала использования для анализа бизнес-информации, отслеживания нарушений и проведения расследования при утечке информации.
Делегирование доступаДелегированный доступ с использованием функции суперпользователя гарантирует, что ИТ-отдел всегда может получить доступ к защищенному содержимому, даже если документ был защищен сотрудником, который уже не работает в вашей организации. Для сравнения решения однорангового шифрования рискуют потерять доступ к корпоративным данным.
Синхронизация Active DirectoryСинхронизация только тех атрибутов каталога, которые необходимы Azure RMS для поддержки стандартных удостоверений локальных учетных записей Active Directory, с помощью решения для управления гибридными удостоверениями, такого как Azure AD Connect.
Единый входПоддержка единого входа в облако без репликации паролей с помощью AD FS.
Переход с AD RMSЕсли вы развернули службы Active Directory Rights Management (AD RMS), вы можете перейти на использование Azure Rights Management без потери доступа к данным, которые ранее были защищены с помощью AD RMS.

Нормативные требования и требования безопасности

Azure Rights Management поддерживает следующие нормативные требования, а также требования соответствия и безопасности:

  • Использование стандартных отраслевых методов криптографии и поддержка FIPS 140-2. Для получения дополнительных сведений см. раздел Элементы управления шифрования, используемые Azure RMS: алгоритмы и длина ключей.

  • Поддержка аппаратных модулей безопасности (HSM) nCipher nShield для хранения ключа клиента в центрах обработки данных Microsoft Azure.

    Azure Rights Management использует разные механизмы обеспечения безопасности для своих центров обработки данных в Северной Америке, регионах EMEA (Европа, Ближний Восток и Африка), а также в Азии. Это гарантирует, что ваши ключи будут использоваться исключительно в вашем регионе.

  • Сертификация по следующим стандартам:

    • стандарт ISO/IEC 27001:2013 (включает ISO/IEC 27018)
    • Аттестаты SOC 2 SSAE 16/ISAE 3402
    • HIPAA BAA
    • Типовая статья ЕС
    • FedRAMP, являющейся частью Azure Active Directory в сертификации Office 365, выпущенной HHS для FedRAMP Agency Authority to Operate
    • PCI DSS, уровень 1

Дополнительные сведения о внешних сертификациях см. в разделе Центр управления безопасностью Azure.

Дальнейшие действия

Более подробную техническую информацию о работе службы Azure Rights Management см. в разделе Как работает Azure RMS?

Если вы знакомы с локальной версией службы управления правами — службами Active Directory Rights Management (RMS AD), вам может оказаться интересной сравнительная таблица в разделе Сравнение службы управления правами Azure и AD RMS.

Что такое управление правами Azure? — АИП

  • Статья
  • 6 минут на чтение

Управление правами Azure (Azure RMS) — это облачная технология защиты, используемая Azure Information Protection.

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

Например, когда сотрудники отправляют документ компании-партнеру по электронной почте или сохраняют документ на свой облачный диск, постоянная защита Azure RMS помогает защитить данные.

  • Настройки защиты остаются с вашими данными , даже когда они выходят за пределы вашей организации, обеспечивая защиту вашего контента как внутри, так и за пределами вашей организации.

  • Azure RMS может потребоваться по закону для соблюдения требований, юридических требований или рекомендаций по управлению информацией.

  • Используйте Azure RMS с подписками Microsoft 365 или подписками на Azure Information Protection . Дополнительные сведения см. на странице руководства по лицензированию Microsoft 365 для обеспечения безопасности и соответствия требованиям.

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

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

Элементы защиты

Элемент Описание
Защита нескольких типов файлов В ранних реализациях управления правами можно было защитить только файлы Office с помощью встроенной защиты управления правами. Azure Information Protection обеспечивает поддержку дополнительных типов файлов. Дополнительные сведения см. в разделе Поддерживаемые типы файлов.
Защита файлов в любом месте Когда файл защищен, защита остается с файлом, даже если он сохраняется или копируется в хранилище, которое не находится под контролем ИТ, например в облачном хранилище.

Функции совместной работы

Функция Описание
Безопасный обмен информацией Защищенными файлами можно безопасно делиться с другими, например вложением в сообщение электронной почты или ссылкой на сайт SharePoint. Если конфиденциальная информация содержится в сообщении электронной почты, защитите сообщение электронной почты или используйте Не пересылать параметр из Outlook.
Поддержка сотрудничества между компаниями Поскольку Azure Rights Management — это облачная служба, нет необходимости явно настраивать доверительные отношения с другими организациями, прежде чем вы сможете поделиться с ними защищенным содержимым. Совместная работа с другими организациями, у которых уже есть каталог Microsoft 365 или Azure AD, поддерживается автоматически. Для организаций без Microsoft 365 или каталога Azure AD пользователи могут подписаться на бесплатную подписку RMS для отдельных лиц или использовать учетную запись Microsoft для поддерживаемых приложений.

Совет

Прикрепление защищенных файлов вместо защиты всего сообщения электронной почты позволяет сохранить текст электронной почты незашифрованным.

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

Функции поддержки платформы

Azure RMS поддерживает широкий спектр платформ и приложений, включая:

Функция Описание
Обычно используемые устройства не только компьютеры с Windows К клиентским устройствам относятся: — компьютеры и телефоны с Windows — компьютеры Mac — планшеты и телефоны с iOS — планшеты и телефоны с Android
Локальные услуги В дополнение к бесперебойной работе с Office 365 используйте Azure Rights Management со следующими локальными службами при развертывании соединителя RMS: — Exchange Server — SharePoint Server — Windows Server с инфраструктурой классификации файлов
Расширяемость приложений Azure Rights Management имеет тесную интеграцию с приложениями и службами Microsoft Office и расширяет поддержку других приложений с помощью клиента Azure Information Protection. Пакет Microsoft Information Protection SDK предоставляет вашим внутренним разработчикам и поставщикам программного обеспечения API-интерфейсы для написания пользовательских приложений, поддерживающих Azure Information Protection. Дополнительные сведения см. в разделе Другие приложения, поддерживающие API управления правами.

Функции инфраструктуры

Azure RMS предоставляет следующие функции для поддержки ИТ-отделов и инфраструктурных организаций:

  • Создание простых и гибких политик
  • Легкая активация
  • Услуги по аудиту и мониторингу
  • Возможность масштабирования в рамках вашей организации
  • Поддерживать ИТ-контроль над данными

Примечание

У организаций всегда есть возможность прекратить использование службы Azure Rights Management без потери доступа к содержимому, которое ранее было защищено Azure Rights Management.

Дополнительные сведения см. в разделе Списание и деактивация Azure Rights Management.

Создание простых и гибких политик

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

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

Настройте политики маркировки на портале соответствия Microsoft Purview. Дополнительные сведения см. в документации по маркировке конфиденциальности для Microsoft 365.

Простая активация

Для новых подписок активация выполняется автоматически. Для существующих подписок для активации службы управления правами требуется всего пара щелчков мышью на портале управления или две команды PowerShell.

Услуги аудита и мониторинга

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

Например, если сотрудник Contoso, Ltd работает над совместным проектом с тремя людьми из Fabrikam, Inc, они могут отправить своим партнерам по Fabrikam документ, защищенный и ограниченный только для чтения .

Аудит Azure RMS может предоставить следующую информацию:

  • Открыли ли партнеры Fabrikam документ и когда.

  • Были ли другие люди, которые не были указаны, пытались и не смогли открыть документ. Это может произойти, если сообщение электронной почты было переадресовано или сохранено в общей папке.

Администраторы AIP могут отслеживать использование документов и отзывать доступ к файлам Office. Пользователи могут отозвать доступ к своим защищенным документам по мере необходимости.

Возможность масштабирования в рамках вашей организации

Поскольку Azure Rights Management работает как облачная служба с эластичностью Azure для масштабирования, вам не нужно выделять или развертывать дополнительные локальные серверы.

Поддержание ИТ-контроля над данными

Организации могут извлечь выгоду из таких функций ИТ-контроля, как:

Особенность Описание
Управление ключами арендатора Используйте решения по управлению ключами арендатора, такие как использование собственного ключа (BYOK) или шифрование с двойным ключом (DKE).

Дополнительные сведения см. в статье:
— Планирование и реализация ключа клиента AIP
— DKE в документации Microsoft 365.

Аудит и регистрация использования Используйте функции аудита и ведения журнала использования для анализа бизнес-идеи, отслеживания злоупотреблений и проведения криминалистического анализа утечек информации.
Делегирование доступа Делегируйте доступ с помощью функции суперпользователя, чтобы ИТ-специалисты всегда могли получить доступ к защищенному содержимому, даже если документ был защищен сотрудником, который затем покидает организацию. Для сравнения, решения для однорангового шифрования рискуют потерять доступ к данным компании.
Синхронизация Active Directory Синхронизируйте только те атрибуты каталога, которые необходимы Azure RMS для поддержки общего удостоверения для ваших локальных учетных записей Active Directory, с помощью гибридного решения для удостоверений, такого как Azure AD Connect.
Единый вход Включите единый вход без репликации паролей в облако с помощью AD FS.
Миграция с AD RMS Если вы развернули службы управления правами Active Directory (AD RMS), перейдите на службу управления правами Azure без потери доступа к данным, которые ранее были защищены AD RMS.

Безопасность, соответствие и нормативные требования

Управление правами Azure поддерживает следующие требования безопасности, соответствия и нормативные требования:

  • Использование стандартной криптографии и поддерживает FIPS 140-2. Дополнительные сведения см. в разделе Криптографические элементы управления, используемые Azure RMS: сведения об алгоритмах и длинах ключей.

  • Поддержка аппаратного модуля безопасности nCipher nShield (HSM) для хранения ключа клиента в центрах обработки данных Microsoft Azure.

    Управление правами Azure использует отдельные миры безопасности для своих центров обработки данных в Северной Америке, регионе EMEA (Европа, Ближний Восток и Африка) и Азии, поэтому ваши ключи можно использовать только в вашем регионе.

  • Сертификация по следующим стандартам :

    • ИСО/МЭК 27001:2013 (./включает ИСО/МЭК 27018)
    • Сертификаты SOC 2 SSAE 16/ISAE 3402
    • HIPAA БАД
    • Модель ЕС, пункт
    • FedRAMP в рамках сертификации Azure Active Directory в Office 365, выданный FedRAMP Agency Authority to Operation by HHS
    • .
    • PCI DSS Уровень 1

Дополнительные сведения об этих внешних сертификатах см. в Центре управления безопасностью Azure.

Следующие шаги

Дополнительные технические сведения о том, как работает служба управления правами Azure, см. в разделе Как работает Azure RMS?

Если вы знакомы с локальной версией управления правами, службами управления правами Active Directory (AD RMS), вас может заинтересовать сравнительная таблица из статьи Сравнение управления правами Azure и AD RMS.

Как работает Azure RMS — Azure Information Protection

  • Статья
  • 11 минут на чтение

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

  • Данные шифруются на уровне приложений и включают политику, определяющую разрешенное использование этого документа.

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

На высоком уровне вы можете увидеть, как этот процесс работает на следующем рисунке. Документ, содержащий секретную формулу, защищается, а затем успешно открывается авторизованным пользователем или службой. Документ защищен ключом содержимого (зеленый ключ на этом рисунке). Он уникален для каждого документа и помещается в заголовок файла, где он защищен корневым ключом клиента Azure Information Protection (красный ключ на этом рисунке). Ваш ключ клиента может создаваться и управляться корпорацией Майкрософт, или вы можете создавать и управлять своим собственным ключом клиента.

На протяжении всего процесса защиты, когда Azure RMS выполняет шифрование и дешифрование, авторизацию и применение ограничений, секретная формула никогда не отправляется в Azure.

Подробное описание происходящего см. в разделе Пошаговое руководство по работе Azure RMS: первое использование, защита контента, потребление контента в этой статье.

Технические сведения об алгоритмах и длинах ключей, используемых Azure RMS, см. в следующем разделе.

Криптографические элементы управления, используемые Azure RMS: алгоритмы и длины ключей

Даже если вам не нужно подробно знать, как работает эта технология, вас могут спросить о криптографических элементах управления, которые она использует. Например, чтобы подтвердить, что защита соответствует отраслевому стандарту.

Криптографические средства Использование в Azure RMS
Алгоритм: AES

Длина ключа: 128 бит и 256 бит [1]

Защита содержимого
Алгоритм: RSA

Длина ключа: 2048 бит [2]

Защита ключа
ША-256 Подписание сертификата
Сноска 1

256 бит используется клиентом Azure Information Protection в следующих сценариях:

  • Универсальная защита (P-файл).

  • Встроенная защита для PDF-документов, если документ был защищен стандартом ISO для шифрования PDF или получившийся защищенный документ имеет расширение имени файла .ppdf.

  • Встроенная защита текстовых файлов или файлов изображений (например, .ptxt или .pjpg).

Сноска 2

2048 бит — это длина ключа при активации службы Azure Rights Management. 1024 бита поддерживаются для следующих необязательных сценариев:

  • Во время миграции из локальной среды, если кластер AD RMS работает в криптографическом режиме 1.

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

Как хранятся и защищаются криптографические ключи Azure RMS

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

Ключ содержимого защищен с помощью ключа RSA организации («Ключ клиента Azure Information Protection») в рамках политики в документе, и политика также подписана автором документа. Этот ключ клиента является общим для всех документов и сообщений электронной почты, защищенных службой управления правами Azure для организации, и этот ключ может быть изменен только администратором Azure Information Protection, если организация использует ключ клиента, управляемый клиентом (известный как «принеси свой ключ» или BYOK).

Этот ключ клиента защищен в онлайн-сервисах Microsoft, в строго контролируемой среде и под пристальным наблюдением. При использовании ключа клиента, управляемого клиентом (BYOK), эта безопасность усиливается за счет использования массива высокопроизводительных аппаратных модулей безопасности (HSM) в каждом регионе Azure без возможности извлечения, экспорта и или делиться ни при каких обстоятельствах. Дополнительные сведения о ключе клиента и BYOK см. в статье Планирование и реализация ключа клиента Azure Information Protection.

Лицензии и сертификаты, отправляемые на устройство Windows, защищены закрытым ключом клиентского устройства, который создается при первом использовании пользователем на устройстве Azure RMS. Этот закрытый ключ, в свою очередь, защищен с помощью DPAPI на клиенте, который защищает эти секреты с помощью ключа, полученного из пароля пользователя. На мобильных устройствах ключи используются только один раз, поэтому, поскольку они не хранятся на клиентах, эти ключи не нужно защищать на устройстве.

Пошаговое руководство по работе Azure RMS: первое использование, защита контента, потребление контента

Чтобы более подробно понять, как работает Azure RMS, давайте рассмотрим типичный процесс после активации службы управления правами Azure и когда пользователь впервые использует службу управления правами на своем компьютере с Windows (процесс, иногда известный как , инициализирующий пользователя). среда или начальная загрузка), защищает содержимое (документ или электронное письмо), а затем потребляет (открывает и использует) содержимое, которое было защищено кем-то другим.

После инициализации пользовательской среды этот пользователь может защищать документы или использовать защищенные документы на этом компьютере.

Примечание

Если этот пользователь переходит на другой компьютер Windows или другой пользователь использует тот же компьютер Windows, процесс инициализации повторяется.

Инициализация пользовательской среды

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

Что происходит на шаге 1 : Клиент RMS на компьютере сначала подключается к службе управления правами Azure и аутентифицирует пользователя, используя его учетную запись Azure Active Directory.

Если учетная запись пользователя объединена с Azure Active Directory, эта проверка подлинности выполняется автоматически, и у пользователя не запрашиваются учетные данные.

Что происходит на шаге 2 : после аутентификации пользователя подключение автоматически перенаправляется к арендатору Azure Information Protection организации, который выдает сертификаты, позволяющие пользователю пройти аутентификацию в службе управления правами Azure для использования защищенного контента и для защиты контента в автономном режиме.

Одним из таких сертификатов является сертификат учетной записи прав, часто сокращенно RAC. Этот сертификат аутентифицирует пользователя в Azure Active Directory и действителен в течение 31 дня. Сертификат автоматически обновляется клиентом RMS при условии, что учетная запись пользователя все еще находится в Azure Active Directory и учетная запись включена. Этот сертификат не может быть настроен администратором.

Копия этого сертификата хранится в Azure, поэтому при переходе пользователя на другое устройство сертификаты создаются с использованием тех же ключей.

Защита содержимого

Когда пользователь защищает документ, клиент RMS выполняет следующие действия с незащищенным документом:

Что происходит на шаге 1 : Клиент RMS создает случайный ключ (ключ содержимого) и шифрует документ с помощью этого ключа с помощью алгоритма симметричного шифрования AES.

Что происходит на шаге 2 : Затем клиент RMS создает сертификат, включающий политику для документа, включающую права использования для пользователей или групп и другие ограничения, например срок действия. Эти параметры могут быть определены в шаблоне, предварительно настроенном администратором, или указаны во время защиты содержимого (иногда это называется «специальной политикой»).

Основным атрибутом Azure AD, используемым для идентификации выбранных пользователей и групп, является атрибут Azure AD ProxyAddresses, в котором хранятся все адреса электронной почты для пользователя или группы. Однако если учетная запись пользователя не имеет никаких значений в атрибуте AD ProxyAddresses, вместо этого используется значение UserPrincipalName пользователя.

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

Что происходит на шаге 3 : Наконец, клиент RMS встраивает политику в файл с предварительно зашифрованным телом документа, которые вместе составляют защищенный документ.

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

Потребление контента

Когда пользователь хочет использовать защищенный документ, клиент RMS начинает с запроса доступа к службе управления правами Azure:

Что происходит на шаге 1 : Пользователь, прошедший проверку подлинности, отправляет политику документов и сертификаты пользователя в службу управления правами Azure. Служба расшифровывает и оценивает политику, а также создает список прав (если таковые имеются) у пользователя на документ. Для идентификации пользователя атрибут Azure AD ProxyAddresses используется для учетной записи пользователя и групп, членом которых является пользователь. Из соображений производительности членство в группах кэшируется. Если учетная запись пользователя не имеет значений для атрибута Azure AD ProxyAddresses, вместо этого используется значение в Azure AD UserPrincipalName.

Что происходит на шаге 2 : Затем служба извлекает ключ содержимого AES из расшифрованной политики. Затем этот ключ шифруется с помощью открытого ключа RSA пользователя, полученного вместе с запросом.

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

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

Клиент также расшифровывает список прав и передает их приложению, которое реализует эти права в пользовательском интерфейсе приложения.

Примечание

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

Варианты

Предыдущие пошаговые руководства охватывают стандартные сценарии, но есть некоторые варианты:

  • Защита электронной почты : Когда для защиты сообщений электронной почты используется шифрование сообщений Exchange Online и Office 365 с новыми возможностями, аутентификация для потребления также может используйте федерацию с поставщиком социальных удостоверений или с помощью одноразового кода доступа. Затем потоки процессов очень похожи, за исключением того, что потребление контента происходит на стороне службы в сеансе веб-браузера с помощью временно кэшированной копии исходящей электронной почты.

  • Мобильные устройства : когда мобильные устройства защищают или используют файлы с помощью службы управления правами Azure, потоки процессов намного проще. Мобильные устройства не проходят сначала процесс инициализации пользователя, потому что вместо этого каждая транзакция (для защиты или использования контента) независима. Как и в случае с компьютерами Windows, мобильные устройства подключаются к службе управления правами Azure и проходят проверку подлинности. Для защиты содержимого мобильные устройства отправляют политику, а служба управления правами Azure отправляет им лицензию на публикацию и симметричный ключ для защиты документа. Чтобы потреблять контент, когда мобильные устройства подключаются к службе Azure Rights Management и проходят проверку подлинности, они отправляют политику документа в службу Azure Rights Management и запрашивают лицензию на использование документа. В ответ служба управления правами Azure отправляет на мобильные устройства необходимые ключи и ограничения. Оба процесса используют TLS для защиты обмена ключами и других коммуникаций.

  • Коннектор RMS : когда служба управления правами Azure используется с коннектором RMS, потоки процессов остаются прежними. Единственное отличие состоит в том, что соединитель действует как ретранслятор между локальными службами (такими как Exchange Server и SharePoint Server) и службой управления правами Azure. Сам коннектор не выполняет никаких операций, таких как инициализация пользовательской среды, шифрование или дешифрование. Он просто передает данные, которые обычно направляются на сервер AD RMS, обрабатывая перевод между протоколами, которые используются на каждой стороне. Этот сценарий позволяет использовать службу Azure Rights Management с локальными службами.

  • Универсальная защита (.pfile) : когда служба управления правами Azure защищает файл в общем, процесс защиты содержимого в основном такой же, за исключением того, что клиент RMS создает политику, которая предоставляет все права. Когда файл потребляется, он расшифровывается перед передачей целевому приложению. Этот сценарий позволяет защитить все файлы, даже если они изначально не поддерживают RMS.

  • Учетные записи Майкрософт : Azure Information Protection может авторизовать адреса электронной почты для использования, если они аутентифицированы с помощью учетной записи Майкрософт. Однако не все приложения могут открывать защищенное содержимое, если для проверки подлинности используется учетная запись Microsoft. Дополнительная информация.

Дальнейшие действия

Чтобы узнать больше о службе Azure Rights Management, см. другие статьи в разделе Понимание и изучение , например Как приложения поддерживают службу Azure Rights Management, чтобы узнать, как ваши существующие приложения могут интегрироваться с Azure Rights. Управление для предоставления решения по защите информации.

Ознакомьтесь с терминологией для Azure Information Protection, чтобы ознакомиться с терминами, с которыми вы можете столкнуться при настройке и использовании службы управления правами Azure, а также обязательно ознакомьтесь с требованиями для Azure Information Protection, прежде чем приступить к работе.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *