Información general de seguridad para Azure Cognitive Search

En este artículo se describen las características de seguridad de Azure Cognitive Search que protegen los datos y las operaciones.

Flujo de datos (patrones de tráfico de red)

Un servicio de Cognitive Search se hospeda en Azure y normalmente las aplicaciones cliente acceden a él mediante 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.

Cognitive Search tiene tres patrones de tráfico básicos:

  • Solicitudes entrantes realizadas por un 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 pueden tener los siguientes fines:

  • Crear o administrar índices, indexadores, orígenes de datos, conjuntos de aptitudes y asignaciones de sinónimos
  • Invocar la ejecución de un indexador o un conjunto de aptitudes
  • Cargar y consultar un índice

Puede revisar las API de REST para conocer la gama completa de solicitudes entrantes que un servicio de búsqueda controla.

Como mínimo, todas las solicitudes entrantes deben autenticarse:

  • La autenticación basada en claves es la opción predeterminada. El servicio de búsqueda acepta las solicitudes entrantes que incluyen una clave de API válida procedentes de una entidad de confianza.
  • También puede usar el control de acceso basado en roles y Azure Active Directory para las operaciones del plano de datos (actualmente en versión preliminar).

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

Las solicitudes de un servicio de búsqueda que salen a otras aplicaciones se realizan normalmente con indexadores para la indexación basada en texto y algunos aspectos del enriquecimiento con inteligencia artificial. Las solicitudes salientes incluyen operaciones de lectura y escritura.

En la siguiente lista se incluyen todas las solicitudes salientes que un servicio de búsqueda puede realizar. Una búsqueda realiza solicitudes salientes en su propio nombre y en nombre de un indexador o una aptitud personalizada:

  • Los indexadores leen de orígenes de datos externos.
  • Los indexadores escriben en Azure Storage al crear almacenes de conocimiento, conservar enriquecimientos copiados en caché y conservar sesiones de depuración.
  • Si se usan aptitudes personalizadas, estas se conectan a una aplicación o función externa de Azure para ejecutar código externo hospedado fuera del servicio. La solicitud de procesamiento externo se envía durante la ejecución del conjunto de aptitudes.
  • Si usa claves administradas por el cliente, el servicio se conecta a una instancia de Azure Key Vault externa para obtener una clave administrada por el cliente usada para cifrar y descifrar datos confidenciales.

Las conexiones de salida se pueden realizar mediante una cadena de conexión de acceso completo del recurso que incluye una clave o un inicio de sesión de Azure AD (una identidad administrada) si usa Azure Active Directory.

Si el recurso de Azure está detrás de un firewall, tendrá que crear reglas que admitan solicitudes de servicio de búsqueda. Para los recursos que protege Azure Private Link, puede crear un vínculo privado compartido que un indexador use para realizar su conexión.

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

Si los servicios de búsqueda y almacenamiento están en la misma región, el tráfico de red se enruta a través de una dirección IP privada y transcurre por 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. En su lugar, utilice la excepción de servicio de confianza como alternativa cuando ambos servicios estén en la misma región.

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 Azure Active Directory, el registro de recurso enviado a Azure Monitor y las conexiones de punto de conexión privado que utilizan Azure Private Link.
  • Solicitudes realizadas a Cognitive Services APIs para las aptitudes integradas
  • Solicitudes enviadas a modelos de Machine Learning que admiten búsquedas semánticas.

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. Azure Cognitive Search admite características de red que pueden ser 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á.

Ejemplo de diagrama de arquitectura para el acceso restringido de IP

Puede usar el 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 Cognitive 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. Una red virtual permite establecer una comunicación segura entre recursos, con su red local y con Internet.

Diagrama de la arquitectura de ejemplo para el acceso de punto de conexión privado

Aunque esta solución es la más segura, el uso de servicios adicionales supone un costo adicional, por lo que debe comprender claramente las ventajas antes de profundizar en ella. Para más información sobre los costos, consulte la página de precios. Para obtener más información sobre cómo funcionan conjuntamente estos componentes, vea este vídeo. La opción de punto de conexión privado se trata a partir del 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 Cognitive Search.

Authentication

Una vez admitida una solicitud, todavía debe someterse a un proceso de autenticación y autorización que determine si se permite la solicitud. Cognitive Search admite dos enfoques:

  • 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 autenticación de Azure AD (versión preliminar) establece el autor de la llamada (y no la solicitud) como identidad autenticada. Una asignación de roles de Azure determina la operación permitida.

Las solicitudes salientes realizadas mediante un indexador están sujetas a los protocolos de autenticación admitidos por el servicio externo. Un servicio de búsqueda se puede convertir en un servicio de confianza en Azure, conectándose a otros servicios mediante una identidad administrada por el sistema o por el usuario. Para obtener más información, consulte Configuración de una conexión de indexador a un origen de datos mediante una identidad administrada.

Autorización

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

Autorización para la administración de contenido

Si usa la autenticación basada en claves, la autorización en las operaciones de contenido se otorga mediante el tipo de clave de API en la solicitud:

  • Clave de administración (permite el acceso de lectura y escritura para operaciones de creación, lectura, actualización y eliminación en el servicio de búsqueda) creada al aprovisionar el servicio.

  • Clave de consulta (permite el acceso de solo lectura a la colección de documentos de un índice) creada según la necesidad y diseñada para las aplicaciones cliente que emiten consultas.

En el código de la aplicación, especifique el punto de conexión y una clave de API para permitir el acceso al contenido y las opciones. 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 juntos, el punto de conexión, la operación (por ejemplo, una solicitud de creación o actualización) y el nivel de permiso (derechos completos o de solo lectura basados en la clave) constituyen la fórmula de seguridad que protege el contenido y las operaciones.

Si utiliza la autenticación de Azure AD, use asignaciones de roles en lugar de claves de API para establecer quién y qué puede leer y escribir en el servicio de búsqueda.

Control del acceso a los índices

En Azure Cognitive Search, un índice individual normalmente no es un objeto protegible. Tal como se indicó anteriormente para la autenticación basada en claves, el acceso a un índice incluirá permisos de lectura o escritura en función de la clave de API que proporcione en la solicitud, junto con el contexto de una operación. Las consultas son operaciones de solo lectura. En una solicitud de consulta, no existe el concepto de combinación de índices ni de acceso simultáneo a varios índices para que todas las solicitudes tengan un único índice de destino por definición. Por lo tanto, la construcción de la solicitud de consulta misma (una clave y un índice único de destino) define el límite de seguridad.

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

En el caso de los escenarios de autenticación basados en claves, los accesos de administrador y de desarrollador a los índices no se diferencian: ambos necesitan tener acceso de escritura para crear, eliminar y actualizar los objetos que administra el servicio. 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 Cognitive 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 en el nivel de índice, estas soluciones suelen incluir un nivel intermedio que los clientes utilizan para controlar el aislamiento de índices. Para más información sobre los casos de uso de varios inquilinos, consulte Modelos de diseño de aplicaciones SaaS para varios inquilinos y Azure Cognitive Search.

Control del acceso a los documentos

Si necesita tener un control por usuario pormenorizado de los resultados de la búsqueda, puede crear filtros de seguridad en las consultas, que devuelven documentos asociados con una identidad de seguridad determinada.

Conceptualmente equivalente a "seguridad de nivel de fila", la autorización de contenido en el índice no se admite de forma nativa mediante roles predefinidos o asignaciones de roles que se asignan a entidades en Azure Active Directory. Los permisos de usuario para datos de sistemas externos, como Azure Cosmos DB, no se transfieren con esos datos cuando Cognitive Search los indexa.

Las alternativas para las soluciones que requieren "seguridad de nivel de fila" incluyen la creación de un campo en el origen de datos que representa un grupo de seguridad o una identidad de usuario y, a continuación, el uso de filtros en Cognitive Search para recortar de forma selectiva los resultados de la búsqueda de documentos y contenido en función de las identidades. La tabla siguiente describe dos enfoques para recortar el contenido no autorizado de los resultados de la búsqueda.

Enfoque Descripción
Recorte de seguridad basado en filtros de identidad Documenta el flujo de trabajo básico para implementar el control de acceso de identidades de usuario. Trata la incorporación de identificadores de seguridad a un índice y, a continuación, se explica el filtrado por ese campo para no incluir el contenido prohibido en los resultados.
Recorte de seguridad basado en identidades de Azure Active Directory En este artículo se amplía el artículo anterior y se proporcionan los pasos necesarios para recuperar identidades de Azure Active Directory (Azure AD), uno de los servicios gratuitos de la plataforma de nube de Azure.

Autorización para la administración de servicios

Las operaciones de administración de servicios se autorizan mediante el control de acceso basado en rol de Azure (RBAC de Azure). RBAC de Azure es un sistema de autorización basado en Azure Resource Manager para el aprovisionamiento de recursos de Azure.

En Azure Cognitive Search, Resource Manager se usa para crear o eliminar el servicio, administrar las claves de API y escalar el servicio. 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 han definido tres roles básicos para la administración de servicios de búsqueda. Las asignaciones de roles se pueden realizar con cualquier metodología compatible (portal, PowerShell, etc.) y se respetan en todo el servicio. Los roles Propietario y Colaborador pueden realizar diversas funciones de administración. Puede asignar el rol Lector a los usuarios que solo ven información esencial.

Nota

Mediante el uso de mecanismos de aplicación en todo el sistema de Azure, puede bloquear una suscripción o un recurso para evitar la eliminación accidental o no autorizada del servicio de búsqueda por parte de usuarios con derechos de administrador. Para más información, consulte Bloqueo de recursos para impedir eliminación inesperada.

Residencia de datos

Al configurar un servicio de búsqueda, se elige una ubicación o región que determina dónde se almacenan y procesan los datos del cliente. Azure Cognitive Search no almacenará datos de clientes fuera de la región especificada a menos que configure una característica que tenga una dependencia en otro recurso de Azure y ese recurso se aprovisione en otra región.

Actualmente, el único recurso externo en el que un servicio de búsqueda escribe datos de cliente es Azure Storage. La cuenta de almacenamiento es la que usted proporcione y puede estar en cualquier región. Un servicio de búsqueda escribirá en Azure Storage si se usa cualquiera de las siguientes características: caché de enriquecimiento, sesión de depuración, almacén de conocimiento.

Excepciones a los compromisos de residencia de datos

Los nombres de objeto se almacenarán y procesarán fuera de la región o ubicación seleccionada. Los clientes no deben incluir datos confidenciales en los campos de nombre ni crear aplicaciones diseñadas para almacenar datos confidenciales en dichos campos. Estos datos aparecerán en los registros de telemetría que usa Microsoft con el fin de proporcionar soporte técnico para el servicio. Los nombres de objeto incluyen nombres de índices, indizadores, orígenes de datos, conjuntos de aptitudes, contenedores y almacén de Key Vault.

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 procedimiento de soporte técnico, esta información podría usarse para realizar sugerencias al cliente. Por ejemplo, "En función de su uso del producto, considere la posibilidad de usar <feature name>, ya que obtendría mejores resultados".

  • Microsoft podría exponer un nombre de objeto en paneles visibles para el cliente.

A petición, Microsoft puede acortar el intervalo de retención o quitar referencias a objetos específicos de los registros de telemetría. Recuerde que si solicita la eliminación de datos, Microsoft no tendrá un historial completo del servicio, lo que podría impedir la solución de problemas del objeto en cuestión.

Para quitar referencias a objetos específicos o para cambiar el período de retención de datos, abra una incidencia de soporte técnico para el servicio de búsqueda.

  1. En Detalles del problema, etiquete la solicitud con las siguientes selecciones:

    • Tipo de problema: Técnico
    • Tipo de problema: configuración
    • Subtipo de problema: problema con la configuración de seguridad del servicio
  2. Cuando llegue a Detalles adicionales (la tercera pestaña), describa los nombres de objeto que quiere quitar o especifique el período de retención que necesita.

    Captura de pantalla de la primera página de la incidencia de soporte técnico con los tipos de problema y la incidencia seleccionados.

Protección de 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

En Azure Cognitive Search, el cifrado empieza por las conexiones y las transmisiones. En el caso de los servicios de búsqueda en la red pública de Internet, Azure Cognitive Search escucha en el puerto HTTPS 443. Todas las conexiones de cliente a servicio usan el cifrado TLS 1.2. No se admiten las versiones anteriores (1.0 o 1.1).

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.

Modelo Teclas Requisitos Restricciones Se aplica a
Cifrado del servidor Claves administradas por Microsoft Ninguno (integrados) Ninguna. Disponible en todos los niveles, en todas las regiones, para el contenido creado después del 24 de enero de 2018. Contenido (índices y mapas de sinónimos) y definiciones (indexadores, orígenes de datos, conjuntos de aptitudes) almacenados en discos de datos y discos temporales.
Cifrado del servidor Claves administradas por el cliente Azure Key Vault Disponible en niveles facturables, en regiones específicas, para el contenido creado después del 1 de agosto de 2020. Contenido (índices y mapas de sinónimos) en discos de datos
Cifrado completo del lado servidor Claves administradas por el cliente Azure Key Vault Disponible en niveles facturables, en todas las regiones, en servicios de búsqueda después del 13 de mayo de 2021. Contenido (índices y mapas de sinónimos) en discos de datos y discos temporales

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)

Las claves administradas por el cliente requieren otro servicio facturable (Azure Key Vault), que puede estar en otra región, pero en la misma suscripción que Azure Cognitive 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, después de mayo de 2021, pueden usar el cifrado con 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. Para obtener más información sobre la compatibilidad con las CMK, vea Cifrado doble completo.

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 obtener más información, vea Configuración de claves administradas por el cliente para el cifrado de datos en Azure Cognitive Search.

Administración de seguridad

Administrar claves de API

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.

Registros de actividad y de recursos

Cognitive 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.

Por medio de alertas y de la infraestructura de registro de Azure, puede seleccionar picos de volumen de consultas u otras acciones que se desvían de las cargas de trabajo previstas. 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.

Certificaciones y cumplimiento

Azure Cognitive Search participa en auditorías regulares, y tiene la certificación de muchos estándares globales, regionales y específicos del sector para la nube pública y Azure Government. Para obtener la lista completa, descargue las notas del producto de las ofertas de cumplimiento de Microsoft Azure.

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 Cognitive Search, actualmente hay una definición integrada. Es para el registro de recursos. Con ella integrada, puede asignar una directiva que identifique cualquier servicio de búsqueda que no tenga registro de recurso y lo active. Para obtener más información, vea Controles de Cumplimiento normativo de Azure Policy para Azure Cognitive Search.

Vea este vídeo

Vea este vídeo de resumen para obtener información general sobre la arquitectura de seguridad y cada categoría de características.

Consulte también