Безопасность и конфиденциальность данных в службе "Поиск Azure"Security and data privacy in Azure Search

Служба "Поиск Azure" содержит встроенные комплексные функции безопасности и элементы управления доступом, которые позволяют сохранить конфиденциальность личного содержимого.Comprehensive security features and access controls are built into Azure Search to ensure private content remains that way. В этой статье перечислены функции безопасности, встроенные в службу "Поиск Azure", и приводятся сведения о соответствии стандартам.This article enumerates the security features and standards compliance built into Azure Search.

Архитектура безопасности службы "Поиск Azure" объединяет физическую безопасность, зашифрованную передачу данных, зашифрованное хранилище и соответствие стандартам на уровне платформы.Azure Search security architecture spans physical security, encrypted transmissions, encrypted storage, and platform-wide standards compliance. С точки зрения операций служба "Поиск Azure" принимает только запросы, прошедшие проверку подлинности.Operationally, Azure Search only accepts authenticated requests. При необходимости можно добавить элементы управления доступом к содержимому для отдельного пользователя с помощью фильтров безопасности.Optionally, you can add per-user access controls on content through security filters. В этой статье описывается безопасность на каждом уровне, но основное внимание уделяется способам защиты данных и операций в службе поиска Azure.This article touches on security at each layer, but is primarily focused on how data and operations are secured in Azure Search.

Соответствие стандартам: ISO 27001, SOC 2, HIPAAStandards compliance: ISO 27001, SOC 2, HIPAA

Как было объявлено в июне 2018 г., служба "Поиск Azure" сертифицирована на соответствие следующим стандартам:Azure Search is certified for the following standards, as announced in June 2018:

Соответствие стандартам относится к общедоступным функциям.Standards compliance applies to generally available features. Функции в предварительной версии будут сертифицированы, когда станут общедоступными. Не следует их использовать в решениях со строгими требованиями к соответствию стандартам.Preview features are certified when they transition to general availability, and must not be used in solutions having strict standards requirements. Сведения о сертификатах соответствия см. в документе Overview of Microsoft Azure compliance (Общие сведения о соответствии требованиям Microsoft Azure) и в центре управления безопасностью.Compliance certification is documented in Overview of Microsoft Azure compliance and the Trust Center.

Зашифрованная передача и хранениеEncrypted transmission and storage

Шифрование действует во всем конвейере индексирования — от соединений, при передачах и до индексированных данных, хранящихся в службе поиска Azure.Encryption extends throughout the entire indexing pipeline: from connections, through transmission, and down to indexed data stored in Azure Search.

Уровень безопасностиSecurity layer ОписаниеDescription
Шифрование при передачеEncryption in transit
(HTTPS, SSL, TLS)(HTTPS/SSL/TLS)
Поиск Azure прослушивает через HTTPS-порт 443.Azure Search listens on HTTPS port 443. Подключения к службам Azure по всей платформе зашифрованы.Across the platform, connections to Azure services are encrypted.

Все взаимодействия между клиентом и службой "Поиск Azure" осуществляются по протоколу SSL/TLS 1.2All client-to-service Azure Search interactions are SSL/TLS 1.2 capable. Обязательно используйте TLS версии 1.2 для SSL-подключений к службе.Be sure to use TLSv1.2 for SSL connections to your service.
Шифрование при храненииEncryption at rest
Ключи, управляемые МайкрософтMicrosoft managed keys
Шифрование происходит внутренне в процессе индексирования и не оказывает заметного влияния на время выполнения индексирования или размер индекса.Encryption is fully internalized in the indexing process, with no measurable impact on indexing time-to-completion or index size. Оно выполняется автоматически во всех процессах индексирования, включая добавочные обновления индекса, который не полностью зашифрован (создан до января 2018 г.).It occurs automatically on all indexing, including on incremental updates to an index that is not fully encrypted (created before January 2018).

На внутреннем уровне шифрование основывается на шифровании службы хранилища Azure с использованием 256-разрядного шифрования AES.Internally, encryption is based on Azure Storage Service Encryption, using 256-bit AES encryption.

Шифрование является внутренним для службы поиска Azure, а сертификаты и ключи шифрования внутренне управляются корпорацией Майкрософт и применяются ко всем компонентам.Encryption is internal to Azure Search, with certificates and encryption keys managed internally by Microsoft, and universally applied. Вы не можете включать или отключать шифрование, подставлять собственные ключи или управлять ими, просматривать параметры шифрования на портале или с помощью программных средств.You cannot turn encryption on or off, manage or substitute your own keys, or view encryption settings in the portal or programmatically.

Шифрование при хранении стало общедоступным 24 января 2018 года и применяется ко всем уровням служб, включая общие (бесплатные) службы во всех регионах.Encryption at rest was announced in January 24, 2018 and applies to all service tiers, including shared (free) services, in all regions. Для полного шифрования индексы, созданные до этой даты, необходимо удалить и создать заново, чтобы шифрование вступило в силу.For full encryption, indexes created prior to that date must be dropped and rebuilt in order for encryption to occur. В противном случае будут зашифрованы только новые данные, добавленные после 24 января.Otherwise, only new data added after January 24 is encrypted.
Шифрование при храненииEncryption at rest
Ключами управляет пользовательCustomer managed keys
Шифрование с помощью управляемых пользователем ключей — это Предварительная версия функции, которая недоступна для бесплатных служб.Encryption with customer managed keys is a preview feature that is not available for free services. Для платных служб он доступен только для служб поиска, созданных за январь 2019, с использованием последней предварительной версии API (API-Version = 2019 – 05 -06-Preview).For paid services, it is only available for search services created on or after January 2019, using the latest preview api-version (api-version=2019-05-06-Preview).

Индексы поиска Azure и карты синонимов теперь могут быть зашифрованы при хранении с помощью ключей клиентов, управляемых ключами в Azure Key Vault.Azure Search indexes and synonym maps can now be encrypted at rest with customer keys managed keys in Azure Key Vault. Дополнительные сведения см. в статье Управление ключами шифрования в службе поиска Azure.To learn more, see Manage encryption keys in Azure Search.
Эта функция не заменяет шифрование неактивных по умолчанию, а применяется в дополнение к нему.This feature is not replacing the default encryption at rest, but rather applied in addition to it.
Включение этой функции увеличит размер индекса и снизит производительность запросов.Enabling this feature will increase index size and degrade query performance. Исходя из наблюдений на дату, можно увидеть увеличение 30%-60% времени выполнения запроса, хотя фактическая производительность зависит от определения индекса и типов запросов.Based on observations to date, you can expect to see an increase of 30%-60% in query times, although actual performance will vary depending on the index definition and types of queries. В связи с этим влиянием на производительность рекомендуется включить эту функцию только для индексов, которые действительно необходимы.Because of this performance impact, we recommend that you only enable this feature on indexes that really require it.

Элементы для управления доступом пользователей в AzureAzure-wide user access controls

В Azure есть несколько механизмов безопасности. Следовательно, они автоматически доступны для созданных вами ресурсов Поиска Azure.Several security mechanisms are available Azure-wide, and thus automatically available to the Azure Search resources you create.

Все службы Azure поддерживают элементы управления доступом на основе ролей (RBAC) для согласованного задания уровней доступа во всех службах.All Azure services support role-based access controls (RBAC) for setting levels of access consistently across all services. Например, просматривать конфиденциальные данные, такие как ключ администратора, могут только пользователи с ролью владельца или участника, а состояние службы доступно для обладателей любой роли.For example, viewing sensitive data, such as the admin key, is restricted to the Owner and Contributor roles, whereas viewing service status is available to members of any role. RBAC предоставляет роли владельца, участника и читателя.RBAC provides Owner, Contributor, and Reader roles. По умолчанию все администраторы службы являются участниками роли владельца.By default, all service administrators are members of the Owner role.

Доступ к службе и проверка подлинностиService access and authentication

Кроме того, что Поиск Azure наследует меры безопасности платформы Azure, он также обеспечивает собственную проверку подлинности на основе ключей.While Azure Search inherits the security safeguards of the Azure platform, it also provides its own key-based authentication. Ключ API является строкой, состоящей из случайно сгенерированных букв и цифр.An api-key is a string composed of randomly generated numbers and letters. Тип ключа (администратор или запрос) определяет уровень доступа.The type of key (admin or query) determines the level of access. Отправка допустимого ключа представляет собой доказательство того, что запрос исходит от доверенной сущности.Submission of a valid key is considered proof the request originates from a trusted entity.

Существует два уровня доступа к службе поиска, включаемые двумя типами ключей.There are two levels of access to your search service, enabled by two types of keys:

  • Доступ администратора (применяется к любым операциям чтения и записи в отношении службы).Admin access (valid for any read-write operation against the service)
  • Доступ к запросам (действует только для операций чтения, например для запросов к коллекции документов индекса).Query access (valid for read-only operations, such as queries, against the documents collection of an index)

Ключи администратора создаются в процессе подготовки службы.Admin keys are created when the service is provisioned. Существует два ключа администратора, обозначенные для упорядочения как первичный и вторичный, хотя в действительности они являются взаимозаменяемыми.There are two admin keys, designated as primary and secondary to keep them straight, but in fact they are interchangeable. У каждой службы есть два ключа администратора, чтобы вы могли сменять их, не теряя доступа к службе.Each service has two admin keys so that you can roll one over without losing access to your service. Вы можете периодически повторно создать ключ администратора в соответствии с рекомендациями по обеспечению безопасности Azure, но нельзя добавить общее число ключей администратора.You can regenerate admin key periodically per Azure security best practices, but you cannot add to the total admin key count. Для одной службы поиска существует не более двух ключей администрирования.There are a maximum of two admin keys per search service.

Ключи запроса создаются по мере необходимости и предназначены для клиентских приложений, которые выдают запросы.Query keys are created as-needed and are designed for client applications that issue queries. Вы можете создать до 50 ключей поисковых запросов.You can create up to 50 query keys. В коде приложения укажите URL-адрес поиска и ключ API запроса, чтобы разрешить доступ только для чтения к коллекции Documents определенного индекса.In application code, you specify the search URL and a query api-key to allow read-only access to the documents collection of a specific index. Используемые вместе конечная точка, ключ API с доступом только для чтения и целевой индекс определяют область применения и уровень доступа для подключения из клиентского приложения.Together, the endpoint, an api-key for read-only access, and a target index define the scope and access level of the connection from your client application.

Проверка подлинности требуется для каждого запроса, который состоит из обязательного ключа, операции и объекта.Authentication is required on each request, where each request is composed of a mandatory key, an operation, and an object. Для обеспечения полной безопасности операций службы достаточно двух уровней разрешений (полные или только для чтения) и контекста (например, для операции запроса к индексу).When chained together, the two permission levels (full or read-only) plus the context (for example, a query operation on an index) are sufficient for providing full-spectrum security on service operations. Дополнительные сведения о ключах см. в статье о создании ключей api и управлении ими.For more information about keys, see Create and manage api-keys.

Доступ к индексуIndex access

В Поиске Azure какой-либо индекс не является защищаемым объектом.In Azure Search, an individual index is not a securable object. Вместо этого доступ к индексу определяется на уровне службы (доступ на чтение или запись), а также контекстом операции.Instead, access to an index is determined at the service layer (read or write access), along with the context of an operation.

В случае с доступом пользователей можно структурировать запросы для подключения с использованием ключа запроса (после чего любой запрос становится доступным только для чтения) и добавить конкретный индекс, используемый приложением.For end-user access, you can structure query requests to connect using a query key, which makes any request read-only, and include the specific index used by your app. В запросе невозможно объединить индексы или получить доступ к нескольким индексам одновременно, поэтому все запросы по определению направляются к одному индексу.In a query request, there is no concept of joining indexes or accessing multiple indexes simultaneously so all requests target a single index by definition. Таким образом, структура самого запроса (ключ и один целевой индекс) определяет границы безопасности.As such, construction of the query request itself (a key plus a single target index) defines the security boundary.

Доступ администратора и разработчика к индексам недифференцированный: для обоих типов доступа необходимо разрешение на запись для создания, удаления и обновления объектов, управляемых службой.Administrator and developer access to indexes is undifferentiated: both need write access to create, delete, and update objects managed by the service. Любой пользователь, имеющий ключ администратора к службе, может прочитать, изменить или удалить любой индекс в той же службе.Anyone with an admin key to your service can read, modify, or delete any index in the same service. Решением для защиты от случайного или злонамеренного удаления индексов являются внутренние средства управления исходным кодом для ресурсов кода, которые позволяют отменить нежелательное удаление или изменение индекса.For protection against accidental or malicious deletion of indexes, your in-house source control for code assets is the remedy for reversing an unwanted index deletion or modification. Служба "Поиск Azure" выполняет отработку отказа в кластере для обеспечения доступности, но она не хранит и не выполняет ваш собственный код, используемый для создания или загрузки индексов.Azure Search has failover within the cluster to ensure availability, but it does not store or execute your proprietary code used to create or load indexes.

Для мультитенантных решений, границы безопасности которых должны находиться на уровне индексов, такие решения, как правило, содержат средний уровень, на котором клиенты обрабатывают изоляцию индекса.For multitenancy solutions requiring security boundaries at the index level, such solutions typically include a middle tier, which customers use to handle index isolation. Дополнительные сведения о вариантах использования мультитенантных решений см. в статье Шаблоны разработки для мультитенантных приложений SaaS и Поиска Azure.For more information about the multitenant use case, see Design patterns for multitenant SaaS applications and Azure Search.

Административный доступAdmin access

Доступ на основе ролей (RBAC) определяет, есть ли у вас доступ к элементам управления в службе и ее содержимом.Role-based access (RBAC) determines whether you have access to controls over the service and its content. Если вы являетесь владельцем или участником службы поиска Azure, вы можете использовать портал или модуль PowerShell AZ. Search для создания, обновления или удаления объектов в службе.If you are an Owner or Contributor on an Azure Search service, you can use the portal or the PowerShell Az.Search module to create, update, or delete objects on the service. Вы также можете использовать REST API управления поиском Azure.You can also use the Azure Search Management REST API.

Доступ пользователяUser access

По умолчанию доступ пользователя к индексу определяется ключом доступа в запросе.By default, user access to an index is determined by the access key on the query request. Большинство разработчиков создают и назначают ключи запросов для поисковых запросов на стороне клиента.Most developers create and assign query keys for client-side search requests. Благодаря ключу запроса можно получить доступ на чтение всего содержимого индекса.A query key grants read access to all content within the index.

Если требуется детальный, индивидуально настраиваемый элемент управления над содержимым, можно компилировать фильтры безопасности в запросах, возвращающих документы, связанные с заданным удостоверением безопасности.If you require granular, per-user control over content, you can build security filters on your queries, returning documents associated with a given security identity. Вместо предопределенных ролей и назначений ролей управление доступом на основе удостоверений реализуется как фильтр, обрезающий результаты поиска документов и содержимого на основе удостоверений.Instead of predefined roles and role assignments, identity-based access control is implemented as a filter that trims search results of documents and content based on identities. В следующей таблице описаны два подхода к обрезке результатов поиска несанкционированного содержимого.The following table describes two approaches for trimming search results of unauthorized content.

ПодходApproach ОписаниеDescription
Security filters for trimming results in Azure Search (Фильтры безопасности для обрезки результатов Поиска Azure)Security trimming based on identity filters Документирует базовый рабочий процесс для реализации управления доступом на основе удостоверений пользователей.Documents the basic workflow for implementing user identity access control. Описывает добавление удостоверений безопасности в индекс, а также объясняет фильтрацию этого поля для усечения результатов запрещенного содержимого.It covers adding security identifiers to an index, and then explains filtering against that field to trim results of prohibited content.
Security filters for trimming Azure Search results using Active Directory identities (Фильтры безопасности для обрезки результатов Поиска Azure с использованием удостоверений Active Directory)Security trimming based on Azure Active Directory identities Эта статья дополняет предыдущую статью, в ней приведены действия для получения удостоверений из Azure Active Directory (AAD), одной из бесплатных служб на облачной платформе Azure.This article expands on the previous article, providing steps for retrieving identities from Azure Active Directory (AAD), one of the free services in the Azure cloud platform.

Таблица. Разрешенные операцииTable: Permissioned operations

В следующей таблице приведены операции, разрешенные в Поиске Azure, и указано, какие ключи используются для разблокировки доступа к конкретной операции.The following table summarizes the operations allowed in Azure Search and which key unlocks access a particular operation.

ОперацияOperation РазрешенияPermissions
Создание службыCreate a service Владелец подписки AzureAzure subscription holder
Масштабирование службыScale a service Ключ администратора, владелец или участник RBAC ресурсаAdmin key, RBAC Owner or Contributor on the resource
удаление службы;Delete a service Ключ администратора, владелец или участник RBAC ресурсаAdmin key, RBAC Owner or Contributor on the resource
Создание, изменение, удаление объектов в службе:Create, modify, delete objects on the service:
индексы и элементы компонентов (включая определения анализатора, профили оценки, параметры CORS), индексаторы, источники данных, синонимы, средства подбора.Indexes and component parts (including analyzer definitions, scoring profiles, CORS options), indexers, data sources, synonyms, suggesters.
Ключ администратора, владелец или участник RBAC ресурсаAdmin key, RBAC Owner or Contributor on the resource
Запрос индексаQuery an index Ключ администратора или запроса (RBAC не применяется)Admin or query key (RBAC not applicable)
Запрос сведений о системе, например возвращение статистики, количества и списков объектов.Query system information, such as returning statistics, counts, and lists of objects. Ключ администратора, RBAC ресурса (владелец, участник или читатель)Admin key, RBAC on the resource (Owner, Contributor, Reader)
Управление ключами администратораManage admin keys Ключ администратора, владелец или участник RBAC ресурсаAdmin key, RBAC Owner or Contributor on the resource.
Управление ключами запросовManage query keys Ключ администратора, владелец или участник RBAC ресурса.Admin key, RBAC Owner or Contributor on the resource.

Физическая безопасностьPhysical security

Центры обработки данных Майкрософт обеспечивают ведущую в отрасли физическую безопасность и соответствуют широкому спектру стандартов и нормативных требований.Microsoft data centers provide industry-leading physical security and are compliant with an extensive portfolio of standards and regulations. Дополнительные сведения см. на странице глобальных центров обработки данных или ознакомьтесь с коротким видеороликом о безопасности центров обработки данных.To learn more, go to the Global data centers page or watch a short video on data center security.

См. такжеSee also