Рекомендации по защите данных
На следующей схеме показано, как службы хранят и извлекают данные объекта Microsoft Entra с помощью уровня авторизации на основе ролей (RBAC). Этот уровень вызывает уровень доступа к данным внутреннего каталога, гарантируя, что запрос данных пользователя разрешен:
Доступ к внутренним интерфейсам Microsoft Entra: обмен данными между службами и другими службы Майкрософт, например Microsoft 365, использует интерфейсы идентификатора Microsoft Entra, которые разрешают вызывающим службам сертификаты клиента.
Доступ к внешним интерфейсам Microsoft Entra: внешний интерфейс Microsoft Entra помогает предотвратить утечку данных с помощью RBAC. Если субъект безопасности, например пользователь, запрашивает доступ к информации через интерфейсы идентификатора Microsoft Entra, маркер безопасности должен сопровождать запрос. Маркер содержит утверждения о субъекте, выполняющего запрос.
Маркеры безопасности выдаются службами проверки подлинности Microsoft Entra. Сведения о существовании пользователя, состоянии включения и роли используются системой авторизации, чтобы решить, разрешен ли запрошенный доступ к целевому клиенту для этого пользователя в этом сеансе.
Доступ к приложениям: поскольку приложения могут получить доступ к интерфейсам программирования приложений (API) без контекста пользователя, доступ проверка включает сведения о приложении пользователя и область запрошенного доступа, например только для чтения, чтения и записи и т. д. Многие приложения используют OpenID Подключение или Open Authorization (OAuth) для получения маркеров для доступа к каталогу от имени пользователя. Эти приложения должны быть явно предоставлены доступ к каталогу или они не получат маркер из службы проверки подлинности Microsoft Entra, и они получают доступ к данным из предоставленного область.
Аудит: выполняется аудит доступа. Например, авторизованные действия, такие как создание пользователя и сброс пароля, создают путь аудита, который может использоваться администратором клиента для управления усилиями по соответствию требованиям или расследованиями. Администраторы клиента могут создавать отчеты аудита с помощью API аудита Microsoft Entra.
Дополнительные сведения: журналы аудита в идентификаторе Microsoft Entra
Изоляция клиента: обеспечение безопасности в мультитенантной среде Microsoft Entra помогает достичь двух основных целей:
- Предотвращение утечки данных и доступа между клиентами: данные, принадлежащие клиенту 1, не могут быть получены пользователями в клиенте 2 без явной авторизации клиентом 1.
- Изоляция доступа к ресурсам между клиентами: операции, выполняемые клиентом 1, не могут повлиять на доступ к ресурсам для клиента 2.
Изоляция арендаторов
В следующих сведениях описывается изоляция клиента.
- Служба защищает клиентов с помощью политики RBAC для обеспечения изоляции данных.
- Чтобы разрешить доступ к клиенту, субъекту, например пользователю или приложению, необходимо иметь возможность пройти проверку подлинности в идентификаторе Microsoft Entra для получения контекста и иметь явные разрешения, определенные в клиенте. Если субъект не авторизован в клиенте, полученный маркер не будет иметь разрешения, а система RBAC отклоняет запросы в этом контексте.
- RBAC гарантирует, что доступ к клиенту выполняется субъектом безопасности, авторизованным в клиенте. Доступ между клиентами возможен, если администратор клиента создает представление субъекта безопасности в том же клиенте (например, подготовка гостевой учетной записи пользователя с помощью совместной работы B2B) или когда администратор клиента создает политику для включения отношения доверия с другим клиентом. Например, политика доступа между клиентами для включения прямого Подключение B2B. Каждый клиент является границей изоляции; существование в одном клиенте не соответствует существованию в другом клиенте, если администратор не разрешает его.
- Данные Microsoft Entra для нескольких клиентов хранятся на одном физическом сервере и диске для заданного раздела. Изоляция обеспечивается, так как доступ к данным защищен системой авторизации RBAC.
- Клиентское приложение не может получить доступ к идентификатору Microsoft Entra без необходимости проверки подлинности. Запрос отклоняется, если он не сопровождается учетными данными в рамках начального процесса согласования подключений. Эта динамика предотвращает несанкционированный доступ к клиенту соседними клиентами. Маркер только учетных данных пользователя или маркер языка разметки утверждений безопасности (SAML) осуществляется через брокер федеративного доверия. Поэтому он проверяется идентификатором Microsoft Entra на основе общих ключей, настроенных владельцем приложения.
- Так как не существует компонента приложения, который может выполняться из Core Store, невозможно принудительно нарушить целостность соседнего клиента.
Безопасность данных
Шифрование при передаче. Чтобы обеспечить безопасность данных, данные каталога в идентификаторе Microsoft Entra подписаны и шифруются во время передачи между центрами обработки данных в единице масштабирования. Данные шифруются и не шифруются на уровне Microsoft Entra Core Store, который находится в защищенных областях размещения серверов связанных центров обработки данных Майкрософт.
Клиентские веб-службы защищены протоколом TLS.
Секрет служба хранилища: серверная часть службы Microsoft Entra использует шифрование для хранения конфиденциальных материалов для использования служб, таких как сертификаты, ключи, учетные данные и хэши с помощью технологии майкрософт. Используемое хранилище зависит от службы, операции, область секрета (на уровне пользователя или на уровне клиента) и других требований.
Эти хранилища управляются группой, ориентированной на безопасность, с помощью установленной автоматизации и рабочих процессов, включая запрос на сертификат, продление, отзыв и уничтожение.
Существует аудит действий, связанных с этими хранилищами, рабочими процессами и процессами, и нет постоянного доступа. Доступ основан на запросе и утверждении, и в течение ограниченного времени.
Дополнительные сведения о неактивных шифрованиях секретов см. в следующей таблице.
Алгоритмы. В следующей таблице перечислены минимальные алгоритмы шифрования, используемые компонентами Microsoft Entra. Как облачная служба, корпорация Майкрософт повторно рассматривает и улучшает криптографию, основываясь на результатах исследований безопасности, внутренних проверках безопасности, ключевых силах в отношении эволюции оборудования и т. д.
Данные и сценарий | Алгоритм шифрования |
---|---|
Пароли облачной учетной записи синхронизации хэша паролей |
Хэш: функция вывода ключа пароля 2 (PBKDF2), используя код проверки подлинности на основе хэша (HMAC)-SHA256 @ 1000 итераций |
Каталог между центрами обработки данных | AES-256-CTS-HMAC-SHA1-96 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |
Поток учетных данных пользователя сквозной проверки подлинности | Пара открытого и закрытого ключа RSA 2048-Public/Private key см. подробнее: Безопасность сквозной проверки подлинности Microsoft Entra |
Обратная запись паролей самостоятельного сброса пароля с помощью Microsoft Entra Подключение: облако для локального обмена данными | Пара закрытых и открытых ключей RSA 2048 AES_GCM (256-разрядный ключ, 96-разрядный размер IV) |
Самостоятельный сброс пароля: ответы на вопросы безопасности | SHA256 |
SSL-сертификаты для опубликованных приложений Microsoft Entra application Proxy |
AES-GCM 256-разрядная версия |
Шифрование на уровне диска | XTS-AES 128 |
Простой единый вход (SSO) программное обеспечение паролей учетной записи службы как услуга (SaaS) учетные данные для подготовки приложений |
AES-CBC 128-разрядная версия |
Управляемые удостоверения для ресурсов Azure | AES-GCM 256-разрядная версия |
Приложение Microsoft Authenticator: вход без пароля в Идентификатор Microsoft Entra | Асимметричный ключ RSA 2048-разрядной версии |
Приложение Microsoft Authenticator: резервное копирование и восстановление метаданных корпоративной учетной записи | AES-256 |
Ресурсы
- Документы доверия служб Майкрософт
- Центр управления безопасностью Microsoft Azure
- Восстановление после удаления в идентификаторе Microsoft Entra