Seguridad en Azure AI Search

Azure AI Search proporciona controles de seguridad completos en el acceso a la red, el acceso a los datos y la protección de datos para cumplir los requisitos empresariales. Como arquitecto de soluciones, debe comprender tres dominios de seguridad clave:

• Patrones de tráfico de red y seguridad de red: tráfico entrante, saliente e interno.
• Mecanismos de control de acceso: claves API o Microsoft Entra ID con roles.
• Residencia y protección de datos: cifrado en tránsito, en uso con computación confidencial opcional y en reposo con cifrado doble opcional.

Un servicio de búsqueda admite varias topologías de seguridad de red, desde restricciones de firewall de IP para la protección básica a los puntos de conexión privados para un aislamiento de red completo. Opcionalmente, use un perímetro de seguridad de red para crear un límite lógico alrededor de los recursos paaS de Azure. En escenarios empresariales que requieren permisos pormenorizados, puede implementar controles de acceso de nivel de documento. Todas las características de seguridad se integran con el marco de cumplimiento de Azure y admiten patrones empresariales comunes, como la autenticación multiinquilino y entre servicios mediante identidades administradas.

En este artículo se detallan las opciones de implementación de cada capa de seguridad para ayudarle a diseñar las arquitecturas de seguridad adecuadas para entornos de desarrollo y producción.

Patrones de tráfico de red

Un servicio Azure AI Search se puede hospedar en la nube pública de Azure, una nube privada de Azure o una nube soberana (como Azure Government). De forma predeterminada, para todos los hosts en la nube, normalmente las aplicaciones cliente acceden al servicio de búsqueda a través de conexiones de red pública. Aunque ese patrón es predominante, no es el único patrón de tráfico que debe tener en cuenta. El conocimiento de todos los puntos de tráfico de entrada y salida es un contexto necesario para proteger los entornos de desarrollo y producción.

Azure AI Search tiene tres patrones de tráfico básicos:

• Solicitudes entrantes realizadas por un usuario o cliente al servicio de búsqueda (el patrón predominante)
• Solicitudes salientes emitidas por el servicio de búsqueda a otros servicios en Azure y en otros lugares
• Solicitudes internas de servicio a servicio a través de la red troncal segura de Microsoft

Tráfico entrante

Las solicitudes entrantes que tienen como destino un punto de conexión de servicio de búsqueda incluyen:

• Crear, leer, actualizar o eliminar índices y otros objetos en el servicio de búsqueda
• Carga de un índice con documentos de búsqueda
• Consultar un índice
• Ejecuta trabajos de indexador o conjunto de aptitudes

Las API de REST describen la gama completa de solicitudes entrantes que administra un servicio de búsqueda.

Como mínimo, todas las solicitudes entrantes deben autenticarse mediante cualquiera de estas opciones:

• Autenticación basada en claves (predeterminado). Las solicitudes entrantes proporcionan una clave de API válida.
• Control de acceso basado en rol. La autorización se realiza a través de identidades de Microsoft Entra y asignaciones de roles en el servicio de búsqueda.

También se pueden agregar características de seguridad de red para restringir aún más el acceso al punto de conexión. Se pueden crear reglas de entrada en un firewall de IP, o bien crear puntos de conexión privados que protejan completamente el servicio de búsqueda de la red pública de Internet.

Tráfico saliente

Usted puede proteger y administrar las solicitudes salientes. Las solicitudes salientes se originan desde el servicio de búsqueda hacia otras aplicaciones. Normalmente, estas solicitudes se realizan por indizadores para la indexación basada en texto y la indexación multimodal, el enriquecimiento de inteligencia artificial basado en habilidades personalizadas y vectorizaciones en el momento de la consulta. Las solicitudes salientes incluyen operaciones de lectura y escritura.

La lista siguiente es una enumeración completa de las solicitudes salientes para las que pueda configurar conexiones seguras. Un servicio de búsqueda realiza solicitudes en su nombre y en nombre de un indexador o una habilidad personalizada.

Por lo general, las conexiones salientes se pueden realizar mediante la cadena de conexión de acceso completo de un recurso que incluye una clave o un inicio de sesión de base de datos, o una identidad administrada si usa el identificador de Entra de Microsoft y el acceso basado en roles.

Para llegar a los recursos de Azure detrás de un firewall, cree reglas de entrada en otros recursos de Azure que admitan solicitudes de servicio de búsqueda.

Para llegar a los recursos de Azure que protege Azure Private Link, puede crear un vínculo privado compartido que use un indexador para realizar su conexión.

Excepción para los servicios de búsqueda y almacenamiento de la misma región

Si Azure Storage y Búsqueda de Azure AI están en la misma región, el tráfico de red se enruta a través de una dirección IP privada y se produce a través de la red troncal de Microsoft. Al utilizarse direcciones IP privadas, no puede configurar firewalls de IP ni un punto de conexión privado para la seguridad de red.

Configure las conexiones de la misma región mediante cualquiera de los enfoques siguientes:

• Excepción de servicio de confianza
• Reglas de instancia de recursos

Tráfico interno

Microsoft protege y administra las solicitudes internas. No puede configurar ni controlar estas conexiones. Si está bloqueando el acceso a la red, no se requiere ninguna acción por parte del usuario porque el cliente no puede configurar el tráfico interno.

El tráfico interno consta de:

• Llamadas de servicio a servicio para tareas como la autenticación y autorización mediante Microsoft Entra ID, el registro de recurso enviado a Azure Monitor y las conexiones de punto de conexión privado que utilizan Azure Private Link.
• Solicitudes de procesamiento de aptitudes integradas, con solicitudes de la misma región dirigidas a un recurso de Microsoft Foundry hospedado internamente que se usa exclusivamente para el procesamiento de aptitudes integradas por Azure AI Search.
• Solicitudes realizadas a los distintos modelos que admiten la clasificación semántica.

Seguridad de red

La seguridad de red protege los recursos frente a ataques o accesos no autorizados mediante la aplicación de controles al tráfico de red. Búsqueda de Azure AI admite características de red que pueden constituir la primera línea de defensa contra el acceso no autorizado.

Conexión entrante a través de firewalls de IP

Un servicio de búsqueda se aprovisiona con un punto de conexión público que permite el acceso mediante una dirección IP pública. Para restringir qué tráfico llega a través del punto de conexión público, cree una regla de firewall de entrada que admita las solicitudes de una dirección IP específica o un intervalo de direcciones IP. Todas las conexiones de cliente deben realizarse a través de una dirección IP permitida, o la conexión se denegará.

Puede usar Azure Portal para configurar el acceso al firewall.

Como alternativa, puede usar las API REST de administración. Desde la versión de API 2020-03-13, con el parámetro IpRule, puede restringir el acceso a su servicio mediante la identificación (de forma individual o en un intervalo) de las direcciones IP a las que quiera otorgar acceso a su servicio de búsqueda.

Conexión entrante a un punto de conexión privado (aislamiento de red, sin tráfico de Internet)

Para una seguridad más estricta, puede establecer un punto de conexión privado para Azure AI Search, lo que permite a un cliente de una red virtual obtener acceso de forma segura a los datos de un índice de búsqueda mediante una instancia de Private Link.

El punto de conexión privado usa una dirección IP del espacio de direcciones de la red virtual para las conexiones al servicio de búsqueda. El tráfico de red entre el cliente y el servicio de búsqueda atraviesa la red virtual y un vínculo privado de la red troncal de Microsoft, lo que elimina la exposición a la red pública de Internet. Las redes virtuales permiten establecer una comunicación segura entre recursos, con su red local y con Internet.

Aunque esta solución es la más segura, el uso de más servicios supone un costo adicional, por lo que debe conocer claramente las ventajas antes de continuar con ella. Para obtener más información sobre los costos, vea la página de precios. Para obtener más información sobre cómo funcionan conjuntamente estos componentes, vea este vídeo. La cobertura de la opción de punto de conexión privado comienza en el minuto 5:48 del vídeo. Para obtener instrucciones sobre cómo configurar el punto de conexión, consulte Creación de un punto de conexión privado para una conexión segura a Azure AI Search.

Perímetro de seguridad de red

Un perímetro de seguridad de red es un límite de red lógico alrededor de los recursos de plataforma como servicio (PaaS) que se implementan fuera de una red virtual. Establece un perímetro para controlar el acceso de red pública a recursos como Azure AI Search, Azure Storage y Azure OpenAI. Puede conceder excepciones a través de reglas de acceso explícitas para el tráfico entrante y saliente. Este enfoque ayuda a evitar la filtración de datos al tiempo que mantiene la conectividad necesaria para las aplicaciones.

Las conexiones de cliente entrantes y las conexiones de servicio a servicio se producen dentro del límite, lo que simplifica y refuerza las defensas contra el acceso no autorizado. Es habitual que las soluciones de Azure AI Search usen varios recursos de Azure. Todos los recursos siguientes se pueden unir a un perímetro de seguridad de red existente:

• Azure AI Search
• Azure OpenAI
• Azure Storage
• Azure Monitor

Para obtener una lista completa de los servicios aptos, consulte Recursos de vínculo privado incorporados.

Authentication

Una vez admitida una solicitud al servicio de búsqueda, todavía debe someterse a un proceso de autenticación y autorización que determine si se permite la solicitud. Azure AI Search admite dos enfoques:

• La autenticación de Microsoft Entra establece el autor de la llamada (y no la solicitud) como identidad autenticada. Una asignación de roles de Azure determina la autorización.

• La autenticación basada en claves realiza en la solicitud (no en el usuario o aplicación que realiza la llamada) mediante una clave de API, donde la clave es una cadena formada por números y letras generados aleatoriamente que demuestra que la solicitud proviene de un origen de confianza. Las claves son necesarias en cada solicitud. El envío de una clave válida se considera una prueba de que la solicitud se origina desde una entidad de confianza.

  La dependencia de la autenticación basada en claves de API significa que debe tener un plan para volver a generar la clave de administración a intervalos regulares, según los procedimientos recomendados de seguridad de Azure. Hay un máximo de dos claves de administrador por servicio de búsqueda. Para más información acerca de protección y administración de claves de API, vea Creación y administración de claves de API.

La autenticación basada en claves es el valor predeterminado para las operaciones del plano de datos (creación y uso de objetos en el servicio de búsqueda). Puede usar ambos métodos de autenticación o deshabilitar el enfoque que no quiera usar en el servicio de búsqueda.

Authorization

Azure AI Search proporciona diferentes modelos de autorización para la administración de servicios y de contenido.

Acceso con privilegios

En un nuevo servicio de búsqueda, el servicio de búsqueda hereda las asignaciones de roles existentes en el nivel de suscripción, y solo los propietarios y administradores de acceso de usuario pueden conceder acceso.

Las tareas de operaciones del plano de control (servicio o creación y administración de recursos) se autorizan exclusivamente a través de asignaciones de roles, sin capacidad para usar la autenticación basada en claves para la administración del servicio.

Las operaciones del plano de control incluyen crear, configurar o eliminar el servicio y administrar la seguridad. Como tal, las asignaciones de roles de Azure determinan quién puede realizar esas tareas, independientemente de si se usa el portal, PowerShell o las API REST de administración.

Se aplican tres roles básicos (Propietario, Colaborador, Lector) a la administración del servicio de búsqueda.

Autorización del acceso a contenido

Las operaciones del plano de datos hacen referencia a los objetos creados y usados en un servicio de búsqueda.

• Para la autorización basada en roles, use asignaciones de roles de Azure para establecer el acceso de lectura y escritura a operaciones.

• Para la autorización basada en claves, una clave de API y un punto de conexión completo determinan el acceso. Un punto de conexión puede ser el propio servicio, la colección de índices, un índice específico, una colección de documentos o un documento específico. Cuando se encadenan, el punto de conexión, la operación (por ejemplo, una solicitud de creación) y el tipo de clave (administrador o consulta) autorizan el acceso al contenido y las operaciones.

Restricción del acceso a índices

Si usa roles de Azure, puede establecer permisos en índices individuales siempre que se haga mediante programación.

Si usa claves, cualquier persona con una clave de administración del servicio puede leer, modificar o eliminar cualquier índice en el mismo servicio. Para la protección contra la eliminación accidental o malintencionada de índices, su control de código fuente interno para los recursos de código es la solución a fin de revertir una eliminación o modificación de índices no deseada. Azure AI Search incluye conmutación por error en el clúster para garantizar la disponibilidad, pero no almacena ni ejecuta el código propietario utilizado para crear o cargar los índices.

Para soluciones multiinquilino que requieren límites de seguridad a nivel de índices, es habitual manejar el aislamiento de índices en la capa intermedia del código de la aplicación. Para más información sobre casos de uso para varios inquilinos, consulte Modelos de diseño de aplicaciones SaaS para varios inquilinos y Azure AI Search.

Restricción del acceso a documentos

Los permisos de usuario en el nivel de documento, también conocidos como seguridad de nivel de fila, están disponibles como una característica en versión preliminar y dependen del origen de datos. Si el contenido se origina en Azure Data Lake Storage (ADLS) Gen2 o blobs de Azure, los metadatos de permisos de usuario que se originan en Azure Storage se conservan en los índices generados por el indexador y se aplican en el momento de la consulta para que solo se incluya contenido autorizado en los resultados de búsqueda.

Para otros orígenes de datos, puede insertar una carga de documento que incluya metadatos de permisos de usuario o grupo, y esos permisos se conservan en contenido indexado y también se aplican en el momento de la consulta. Esta funcionalidad también está en versión preliminar.

Si no puede usar características en versión preliminar y necesita acceso con permisos a través del contenido en los resultados de búsqueda, hay una técnica para aplicar filtros que incluyan o excluyan documentos en función de la identidad del usuario. Esta solución agrega un campo de cadena en el origen de datos que representa una identidad de grupo o usuario, que puede filtrar en el índice. Para obtener más información sobre este patrón, consulte Recorte de seguridad en función de los filtros de identidad. Para obtener más información sobre el acceso a documentos, consulte Control de acceso de nivel de documento.

Residencia de datos

Cuando se configura un servicio de búsqueda, se elige una región que determina dónde se almacenan y procesan los datos de los clientes. Cada región existe dentro de una geografía (Geo) que a menudo incluye varias regiones (por ejemplo, Suiza es una Geo que contiene el Norte de Suiza y el Oeste de Suiza). Azure AI Search podría replicar sus datos en otra región dentro del mismo Geo para garantizar la durabilidad y la alta disponibilidad. El servicio no almacenará ni procesará datos de clientes fuera de la región geográfica especificada, a menos que configure una función que dependa de otro recurso de Azure y dicho recurso esté aprovisionado en una región diferente.

Actualmente, el único recurso externo en el que escribe un servicio de búsqueda es Azure Storage. La cuenta de almacenamiento es la que usted proporcione y puede estar en cualquier región. Un servicio de búsqueda escribe en Azure Storage si utiliza alguna de las siguientes características:

• caché de enriquecimiento
• sesión de depuración
• almacén de conocimiento

Para obtener más información sobre la residencia de datos, consulte Residencia de datos en Azure.

Excepciones a los compromisos de residencia de datos

Los nombres de los objetos aparecen en los registros de telemetría utilizados por Microsoft para dar soporte al servicio. Los nombres de los objetos se almacenan y procesan fuera de la región o ubicación seleccionada. Los nombres de objeto incluyen los nombres de índices y campos de índice, alias, indexadores, fuentes de datos, conjuntos de habilidades, mapas de sinónimos, recursos, contenedores y almacén de claves. Los clientes no deben incluir datos confidenciales en los campos de nombre ni crear aplicaciones diseñadas para almacenar datos confidenciales en dichos campos.

Los registros de telemetría se conservan durante un año y medio. Durante ese período, Microsoft podría acceder y hacer referencia a los nombres de objeto en las siguientes circunstancias:

• Diagnosticar un problema, mejorar una característica o corregir un error. En este escenario, el acceso a datos solo es interno, sin acceso de terceros.

• Durante el soporte técnico, esta información se puede usar para proporcionar una resolución rápida de los problemas y escalarlos al equipo de productos si es necesario

Protección de los datos

En la capa de almacenamiento, el cifrado de datos está integrado en todo el contenido administrado por el servicio guardado en el disco, incluidos los índices, los mapas de sinónimos y las definiciones de indizadores, orígenes de datos y conjuntos de aptitudes. El cifrado administrado por el servicio se aplica tanto al almacenamiento de datos a largo plazo como al almacenamiento de datos temporal.

Opcionalmente, puede agregar claves administradas por el cliente (CMK) para lograr un cifrado complementario del contenido indexado y realizar un doble cifrado de los datos en reposo. En los servicios creados después del 1 de agosto de 2020, el cifrado con CMK se amplía a los datos a corto plazo almacenados en discos temporales.

Datos en tránsito

Para las conexiones del servicio de búsqueda a través de Internet público, Búsqueda de Azure AI escucha en el puerto HTTPS 443.

Azure AI Search admite TLS 1.2 y 1.3 para el cifrado del canal cliente-servicio:

• TLS 1.3 es el valor predeterminado en los nuevos sistemas operativos cliente y versiones de .NET.
• TLS 1.2 es el valor predeterminado en los sistemas más antiguos, pero puede establecer explícitamente TLS 1.3 en una solicitud de cliente.

Las versiones anteriores de TLS (1.0 o 1.1) no son compatibles.

Para obtener más información, consulte Compatibilidad con TLS en .NET Framework.

Datos en uso

De forma predeterminada, Azure AI Search implementa el servicio de búsqueda en la infraestructura estándar de Azure. Esta infraestructura cifra los datos en reposo y en tránsito, pero no protege los datos mientras se procesa activamente en la memoria.

Opcionalmente, puede usar Azure Portal o Servicios: crear o actualizar (API REST) para configurar la computación confidencial durante la creación del servicio. La computación confidencial protege los datos en uso del acceso no autorizado, incluido Microsoft, a través de la atestación de hardware y el cifrado. Para más información, consulte Casos de uso de computación confidencial.

En la tabla siguiente se comparan ambos tipos de computación.

¹ Cuando se habilita este tipo de proceso, los indexadores solo se pueden ejecutar en el entorno de ejecución privado, lo que significa que se ejecutan desde los clústeres de búsqueda hospedados en la computación confidencial.

Datos en reposo

En el caso de los datos que administra internamente el servicio de búsqueda, en la tabla siguiente se describen los modelos de cifrado de datos. Algunas características, como el almacén de conocimiento, el enriquecimiento incremental y la indización basada en indizador, leen o escriben en estructuras de datos de otros servicios de Azure. Los servicios que tienen una dependencia en Azure Storage pueden usar las características de cifrado de esa tecnología.

Al poner en marcha el cifrado con una CMK, el contenido se cifra dos veces. En el caso de los objetos y campos mencionados en la sección anterior, el contenido se cifra primero con la CMK y, en segundo lugar, con la clave administrada por Microsoft. El contenido se cifra por doble partida en discos de datos para el almacenamiento a largo plazo y en discos temporales usados para el almacenamiento a corto plazo.

Claves administradas por el servicio

El cifrado administrado por el servicio es una operación interna de Microsoft que usa cifrado AES de 256 bits. Se produce automáticamente en todas las indexaciones, incluidas las actualizaciones incrementales a índices que no están totalmente cifrados (creados antes de enero de 2018).

El cifrado administrado por el servicio se aplica a todo el contenido en almacenamientos tanto a corto como a largo plazo.

Claves administradas por el cliente (CMK)

Los clientes usan CMK por dos motivos: protección adicional y la capacidad de revocar claves, lo que impide el acceso al contenido.

Las claves administradas por el cliente requieren otro servicio facturable, Azure Key Vault, que puede estar en otra región, pero en el mismo inquilino de Azure, que Azure AI Search.

La compatibilidad con CMK se implementó en dos fases. Si el servicio de búsqueda se creó durante la primera fase, el cifrado con CMK estaba restringido al almacenamiento a largo plazo y a regiones específicas. Los servicios creados en la segunda fase pueden usar el cifrado CMK en cualquier región. Como parte de la segunda fase de implementación, el contenido se cifra con CMK en el almacenamiento tanto a corto como a largo plazo.

• El primer lanzamiento fue el 1 de agosto de 2020 e incluyó las cinco regiones siguientes. Los servicios de búsqueda creados en las siguientes regiones admiten el uso de CMK en los discos de datos, pero no en los discos temporales:

  • Oeste de EE. UU. 2
  • East US
  • Centro-sur de EE. UU.
  • Gobierno de EE. UU. de Virginia
  • Gobierno de Estados Unidos Arizona

• La segunda implementación, que tuvo lugar el 13 de mayo de 2021, incorporó cifrado para discos temporales y un cifrado con CMK ampliado a todas las regiones admitidas.

  Si usa CMK desde un servicio creado durante la primera implementación y también quiere disponer de cifrado con CMK en los discos temporales, deberá crear un nuevo servicio de búsqueda en la región de su elección y volver a implementar el contenido. Para determinar la fecha de creación del servicio, consulte Comprobación de la fecha de creación o actualización del servicio.

Al habilitar el cifrado de CMK aumenta el tamaño de los índices y empeora el rendimiento de las consultas. Según las observaciones hechas hasta la fecha, puede esperar un aumento de entre un 30 y un 60 por ciento en los tiempos de consultas, aunque el rendimiento real variará según la definición de los índices y los tipos de consultas. Debido a este impacto adverso en el rendimiento, se recomienda habilitar esta característica solo en los índices que realmente la necesiten. Para más información, consulte Configuración de claves administradas por el cliente para el cifrado de datos en Azure AI Search.

Registro y supervisión

Azure AI Search no registra las identidades de usuario, por lo que no puede hacer referencia a los registros para obtener información sobre un usuario específico. Sin embargo, el servicio registra las operaciones de creación, lectura, actualización y eliminación, que es posible que pueda correlacionar con otros registros para comprender la intervención de acciones específicas.

Usando alertas y la infraestructura de registro de Azure, puede detectar picos en el volumen de consultas u otras acciones que se desvíen de las cargas de trabajo esperadas. Para obtener más información sobre la configuración de registros, vea Recopilación y análisis de datos de registro y Supervisión de solicitudes de consulta.

Cumplimiento y gobernanza

Azure AI Search participa en auditorías regulares y ha sido certificado según muchos estándares globales, regionales y específicos del sector, tanto para la nube pública como para Azure Government. Para obtener la lista completa, descargue el documento técnico de Ofertas de Cumplimiento de Microsoft Azure desde la página oficial de informes de auditoría.

Se recomienda revisar periódicamente las certificaciones y la documentación de cumplimiento de Azure AI Search para garantizar la alineación con los requisitos normativos.

Uso de Azure Policy

En el caso del cumplimiento, puede usar Azure Policy para implementar los procedimientos recomendados de alta seguridad de Microsoft Cloud Security Benchmark. Microsoft Cloud Security Benchmark es una colección de recomendaciones de seguridad codificadas en controles de seguridad que se asignan a acciones clave que se deben realizar para mitigar las amenazas a los servicios y los datos. Actualmente hay 12 controles de seguridad, entre los que se incluyen Seguridad de red, Registro y supervisión y Protección de datos.

Azure Policy es una funcionalidad integrada en Azure que ayuda a administrar el cumplimiento de varios estándares, incluidos los de Azure Security Benchmark. En el caso de los puntos de referencia conocidos, Azure Policy proporciona definiciones integradas que ofrecen tanto criterios como una respuesta procesable que aborda el no cumplimiento.

En Azure AI Search, actualmente hay una definición integrada. Es para el registro de recursos. Puede asignar una directiva que identifique los servicios de búsqueda que no tienen registro de recursos y luego activarlo. Para más información, consulte Controles de Cumplimiento normativo de Azure Policy para Azure AI Search.

Usar etiquetas

Aplique etiquetas de metadatos para clasificar los servicios de búsqueda en función de los requisitos de cumplimiento y confidencialidad de los datos. Esto facilita la gobernanza adecuada y los controles de seguridad. Para más información, consulte Uso de etiquetas para organizar los recursos de Azure e instrucciones generales: organización de los recursos de Azure mediante etiquetas.

Contenido relacionado

• Aspectos básicos de la seguridad de Azure
• Seguridad de Azure
• Microsoft Defender for Cloud

También se recomienda el vídeo siguiente sobre las características de seguridad. Tiene varios años y no cubre características más recientes, pero cubre estas características: CMK, firewalls ip y vínculo privado. Si usa esas características, es posible que este vídeo le resulte útil.