Control de acceso detallado en Amazon Service OpenSearch

El control de acceso detallado ofrece formas adicionales de controlar el acceso a tus datos en Amazon Service. OpenSearch Por ejemplo, puede ser conveniente que, según quién realice la solicitud, una búsqueda devuelva los resultados de un solo índice. Es posible que desee ocultar determinados campos en los documentos o excluir algunos documentos por completo.

El control de acceso detallado ofrece las siguientes características:

• Control de acceso con base en roles

• Seguridad en el nivel de índice, de documento y de campo

• OpenSearch Paneles de mandos: multiusuario

• Autenticación básica HTTP para paneles y paneles OpenSearch OpenSearch

Temas

• Un panorama más amplio: control de acceso detallado y seguridad del servicio OpenSearch
• Conceptos clave
• Acerca del usuario maestro
• Habilitar el control de acceso detallado
• Acceder a los OpenSearch paneles de control como usuario maestro
• Administrar permisos
• Configuraciones recomendadas
• Limitaciones
• Modificar el usuario maestro
• Usuarios maestros adicionales
• Instantáneas manuales
• Integraciones
• Diferencias en la API REST
• Tutorial: Configurar un dominio con un usuario maestro de IAM y la autenticación de Amazon Cognito
• Tutorial: Configurar un dominio con la base de datos de usuarios interna y la autenticación básica de HTTP

Un panorama más amplio: control de acceso detallado y seguridad del servicio OpenSearch

La seguridad OpenSearch de Amazon Service consta de tres capas principales:

Red

La primera capa de seguridad es la red, que determina si las solicitudes llegan a un dominio OpenSearch de servicio. Si elige Acceso público al crear un dominio, las solicitudes procedentes de cualquier cliente conectado a Internet pueden llegar al punto de conexión del dominio. Si elige Acceso a la VPC, los clientes deben conectarse a la VPC (y los grupos de seguridad asociados deben permitirlo) para que una solicitud llegue al punto de conexión. Para obtener más información, consulte Lanzamiento de tus dominios OpenSearch de Amazon Service dentro de una VPC.

Política de acceso al dominio

La segunda capa de seguridad es la política de acceso al dominio. Una vez que una solicitud llega a un punto de conexión del dominio, la política de acceso con base en recursos permite o deniega el acceso de la solicitud a un URI determinado. La política de acceso acepta o rechaza las solicitudes en el «límite» del dominio, antes de que lleguen a OpenSearch propiamente dicho.

Control de acceso detallado

La tercera y última capa de seguridad es el control de acceso detallado. Una vez que una política de acceso con base en recursos ha permitido que una solicitud llegue a un punto de conexión del dominio, el control de acceso detallado evalúa las credenciales del usuario y lo autentica o bien deniega la solicitud. Si el control de acceso detallado autentica al usuario, obtiene todos los roles mapeados a ese usuario y utiliza el conjunto completo de permisos para determinar cómo gestionar la solicitud.

nota

Si una política de acceso basada en recursos contiene funciones o usuarios de IAM, los clientes deben enviar las solicitudes firmadas mediante la versión 4 de AWS Signature. Como tales, las políticas de acceso pueden entrar en conflicto con el control de acceso detallado, sobre todo si se utiliza la base de datos de usuarios interna y la autenticación básica de HTTP. No se puede firmar una solicitud con un nombre de usuario y contraseña y también con credenciales de IAM. En general, si habilita el control de acceso detallado, se recomienda utilizar una política de acceso al dominio que no requiera solicitudes firmadas.

Este primer diagrama ilustra una configuración habitual: un dominio de acceso a la VPC con el control de acceso detallado habilitado, una política de acceso con base en IAM y un usuario maestro de IAM.

Este segundo diagrama ilustra otra configuración habitual: un dominio de acceso público con el control de acceso detallado habilitado, una política de acceso que no utiliza principales de IAM y un usuario maestro en la base de datos de usuarios interna.

Ejemplo

Supongamos que se realiza una solicitud GET a movies/_search?q=thor. ¿El usuario tiene permisos para buscar en el índice movies? En caso afirmativo, ¿el usuario tiene permisos para ver todos los documentos que contiene? ¿La respuesta debería omitir o anonimizar algún campo? Para el usuario maestro, la respuesta podría tener este aspecto:

{
  "hits": {
    "total": 7,
    "max_score": 8.772789,
    "hits": [{
        "_index": "movies",
        "_type": "_doc",
        "_id": "tt0800369",
        "_score": 8.772789,
        "_source": {
          "directors": [
            "Kenneth Branagh",
            "Joss Whedon"
          ],
          "release_date": "2011-04-21T00:00:00Z",
          "genres": [
            "Action",
            "Adventure",
            "Fantasy"
          ],
          "plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.",
          "title": "Thor",
          "actors": [
            "Chris Hemsworth",
            "Anthony Hopkins",
            "Natalie Portman"
          ],
          "year": 2011
        }
      },
      ...
    ]
  }
}

Si un usuario con permisos más limitados emite exactamente la misma solicitud, la respuesta podría tener el siguiente aspecto:

{
  "hits": {
    "total": 2,
    "max_score": 8.772789,
    "hits": [{
        "_index": "movies",
        "_type": "_doc",
        "_id": "tt0800369",
        "_score": 8.772789,
        "_source": {
          "year": 2011,
          "release_date": "3812a72c6dd23eef3c750c2d99e205cbd260389461e19d610406847397ecb357",
          "plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.",
          "title": "Thor"
        }
      },
      ...
    ]
  }
}

La respuesta contiene menos aciertos y menos campos para cada acierto. Además, el campo release_date está anonimizado. Si un usuario sin permisos realiza la misma solicitud, el clúster devuelve un error:

{
  "error": {
    "root_cause": [{
      "type": "security_exception",
      "reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]"
    }],
    "type": "security_exception",
    "reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]"
  },
  "status": 403
}

Si un usuario proporciona credenciales no válidas, el clúster devuelve una excepción Unauthorized.

Conceptos clave

Al comenzar con un control de acceso detallado, tenga en cuenta los siguientes conceptos:

• Funciones: la forma principal de utilizar un control de acceso detallado. En este caso, se trata de roles distintos de los roles de IAM. Los roles contienen cualquier combinación de permisos: para todo el clúster, específicos del índice, en el nivel de documento y en el nivel de campo.

• Mapeo: después de configurar un rol, se asigna a uno o más usuarios. Por ejemplo, puede mapear tres roles a un solo usuario: un rol que proporciona acceso a Dashboards, otro que proporciona acceso de solo lectura a index1 y otro que proporciona acceso de escritura a index2. Si lo prefiere, puede incluir todos esos permisos en un solo rol.

• Usuarios: personas o aplicaciones que realizan solicitudes al OpenSearch clúster. Los usuarios tienen credenciales, ya sean claves de acceso de IAM o un nombre de usuario y una contraseña, que especifican al realizar las solicitudes.

Acerca del usuario maestro

El usuario maestro de OpenSearch Service es una combinación de nombre de usuario y contraseña, o un usuario principal de IAM, que tiene todos los permisos para acceder al OpenSearch clúster subyacente. Se considera que un usuario es un usuario maestro si tiene todos los accesos al OpenSearch clúster y la capacidad de crear usuarios internos, funciones y asignaciones de funciones en los paneles de control. OpenSearch

Un usuario maestro creado en la consola OpenSearch de servicio o mediante la CLI se asigna automáticamente a dos funciones predefinidas:

• all_access— Proporciona acceso total a todas las operaciones del clúster, permiso para escribir en todos los índices del clúster y permiso para escribir para todos los inquilinos.

• security_manager— Proporciona acceso al complemento de seguridad y gestiona los usuarios y los permisos.

Con estas dos funciones, el usuario accede a la pestaña Seguridad de los OpenSearch paneles, donde puede gestionar los usuarios y los permisos. Si crea otro usuario interno y solo lo asigna al all_access rol, el usuario no tendrá acceso a la pestaña Seguridad. Puede crear usuarios maestros adicionales asignándolos de forma explícita a all_access ambos security_manager roles. Para ver instrucciones, consulte Usuarios maestros adicionales.

Al crear un usuario maestro para su dominio, puede especificar un usuario principal de IAM existente o crear un usuario maestro en la base de datos de usuarios interna. Tenga en cuenta lo siguiente a la hora de decidir cuál utilizar:

• Principal de IAM: si elige un principal de IAM para su usuario maestro, todas las solicitudes al clúster deben firmarse con la versión 4 de AWS Signature.

  OpenSearch El servicio no tiene en cuenta ninguno de los permisos del director de IAM. El usuario o rol de IAM sirve únicamente para la autenticación. Las políticas de ese usuario o rol no influyen en la autorización del usuario maestro. La autorización se gestiona a través de los distintos permisos del complemento OpenSearch de seguridad.

  Por ejemplo, no puede asignar ningún permiso de IAM a un responsable de IAM y, siempre que la máquina o la persona puedan autenticarse ante ese usuario o función, tendrán el poder de usuario maestro de Service. OpenSearch

  Recomendamos IAM si quiere usar los mismos usuarios en varios clústeres, si quiere usar Amazon Cognito para acceder a los paneles o si OpenSearch tiene clientes que admiten la firma de Signature Version 4.

• Base de datos de usuarios interna: si crea una base de datos maestra en la base de datos de usuarios interna (con una combinación de nombre de usuario y contraseña), puede utilizar la autenticación básica HTTP (además de las credenciales de IAM) para realizar solicitudes al clúster. La mayoría de los clientes admiten la autenticación básica, incluido curl, que también es compatible con la versión 4 de AWS Signature con la opción --aws-sigv4. La base de datos interna de usuarios se almacena en un OpenSearch índice, por lo que no puede compartirla con otros clústeres.

  Recomendamos la base de datos de usuarios interna si no se requiere reutilizar los usuarios en varios clústeres, si se desea utilizar la autenticación básica de HTTP para obtener acceso a Dashboards (en lugar de Amazon Cognito) o si se tienen clientes que solo admiten la autenticación básica. La base de datos de usuarios interna es la forma más sencilla de empezar a usar OpenSearch Service.

Habilitar el control de acceso detallado

Habilite un control de acceso detallado mediante la consola o la API de AWS CLIconfiguración. Para ver los pasos, consulte Creación y administración de dominios OpenSearch de Amazon Service.

El control de acceso detallado requiere OpenSearch Elasticsearch 6.7 o una versión posterior. También requiere HTTPS para todo el tráfico al dominio, el cifrado de los datos en reposo y el cifrado. node-to-node Según cómo configure las características avanzadas del control de acceso detallado, el procesamiento adicional de sus solicitudes puede requerir recursos de cómputo y memoria en nodos de datos individuales. Después de habilitar el control de acceso detallado, no puede desactivarlo.

Habilitar el control de acceso detallado en los dominios existentes

Puedes habilitar un control de acceso detallado en los dominios existentes que ejecuten Elasticsearch 6.7 OpenSearch o una versión posterior.

Para habilitar el control de acceso detallado en un dominio existente (consola)

1. Seleccione el dominio y elija Acciones y Editar la configuración de seguridad.

2. Seleccione Habilitar el control de acceso detallado,

3. Seleccione cómo crear el usuario maestro:

   • Si desea utilizar IAM para la gestión de usuarios, seleccione Establecer ARN de IAM como usuario maestro y especifique el ARN para un rol de IAM.

   • Si desea utilizar la base de datos de usuarios interna, seleccione Crear usuario maestro y especifique un nombre de usuario y una contraseña.

4. (Opcional) Seleccione Habilitar el período de migración para la política de acceso abierta o basada en IP. Esta configuración permite un período de transición de 30 días durante el cual los usuarios existentes pueden seguir accediendo al dominio sin interrupciones, y las políticas de acceso basadas en IP y abiertas existentes seguirán funcionando con su dominio. Durante este período de migración, recomendamos a los administradores crear los roles necesarios y asignarlos a los usuarios para el dominio. Si utiliza políticas basadas en la identidad en lugar de una política de acceso abierta o basada en la IP, puede desactivar esta configuración.

   También debe actualizar sus clientes para que trabajen con un control de acceso de grano fino durante el periodo de migración. Por ejemplo, si asignas las funciones de IAM a un control de acceso detallado, debes actualizar tus clientes para empezar a firmar las solicitudes con la versión 4 de Signature. AWS Si configura la autenticación básica HTTP con un control de acceso detallado, debe actualizar los clientes para proporcionar las credenciales de autenticación básicas adecuadas en las solicitudes.

   Durante el período de migración, los usuarios que accedan al terminal de OpenSearch Dashboards del dominio accederán directamente a la página Discover en lugar de a la página de inicio de sesión. Los administradores y los usuarios maestros pueden elegir Inicio de sesión para iniciar sesión con credenciales de administrador y configurar asignaciones de roles.

   importante

   OpenSearch El servicio desactiva automáticamente el período de migración después de 30 días. Recomendamos finalizarlo tan pronto como cree los roles necesarios y los asigne a los usuarios. Una vez finalizado el período de migración, no puedes volver a habilitarlo.

5. Seleccione Guardar cambios.

El cambio desencadena una implementación azul-verde durante el cual el estado del clúster se vuelve rojo, pero todas las operaciones de clúster no se ven afectadas.

Para habilitar el control de acceso detallado en un dominio (CLI) existente

Establezca AnonymousAuthEnabled a true para habilitar el período de migración con un control de acceso detallado:

aws opensearch update-domain-config --domain-name test-domain --region us-east-1 \
      --advanced-security-options '{ "Enabled": true, "InternalUserDatabaseEnabled":true, "MasterUserOptions": {"MasterUserName":"master-username","MasterUserPassword":"master-password"},"AnonymousAuthEnabled": true}'

Acerca del default_role

El control de acceso detallado requiere asignación de roles. Si tu dominio usa políticas de acceso basadas en la identidad, OpenSearch Service asigna automáticamente a tus usuarios a un nuevo rol llamado default_role para ayudarte a migrar correctamente a los usuarios existentes. Esta asignación temporal garantiza que los usuarios puedan seguir enviando correctamente solicitudes GET y PUT firmadas por IAM hasta que cree sus propias asignaciones de roles.

La función no añade ninguna vulnerabilidad o fallo de seguridad a tu dominio de servicio. OpenSearch Recomendamos eliminar el rol predeterminado tan pronto como configure sus propios roles y los asigne en consecuencia.

Escenarios de migración

La siguiente tabla describe el comportamiento de cada método de autenticación antes y después de habilitar el control de acceso detallado en un dominio existente, y los pasos que deben seguir los administradores para asignar correctamente sus usuarios a los roles:

Método de autenticación	Antes de habilitar el control de acceso detallado	Después de habilitar el control de acceso detallado	Tareas administrativas
Políticas basadas en identidades	Todos los usuarios que cumplan la política de IAM pueden acceder al dominio.	No es necesario habilitar el período de migración. OpenSearch El servicio asigna automáticamente a todos los usuarios que cumplen la política de IAM al default_role para que puedan seguir accediendo al dominio.	Cree asignaciones de roles personalizadas en el dominio. Elimine las default_role.
Políticas basadas en IP	Todos los usuarios de las direcciones IP permitidas o los bloques de CIDR pueden acceder al dominio.	Durante el período de migración de 30 días, todos los usuarios de las direcciones IP permitidas o los bloques de CIDR pueden seguir accediendo al dominio.	Cree asignaciones de roles personalizadas en el dominio. Actualice sus clientes para proporcionar credenciales de autenticación básicas o credenciales de IAM, según la configuración de asignación de roles. Desactive el período de migración. Los usuarios de las direcciones IP permitidas o los bloques de CIDR que envían solicitudes sin autenticación básica o credenciales de IAM perderán el acceso al dominio.
Políticas de acceso abierto	Todos los usuarios en Internet pueden acceder al dominio.	Durante el período de migración de 30 días, todos los usuarios de Internet pueden seguir accediendo al dominio.	Cree asignaciones de roles en el dominio. Actualice sus clientes para proporcionar credenciales de autenticación básicas o credenciales de IAM, según la configuración de asignación de roles. Desactive el período de migración. Los usuarios que envíen solicitudes sin autenticación básica o credenciales de IAM perderán el acceso al dominio.

Acceder a los OpenSearch paneles de control como usuario maestro

El control de acceso detallado tiene un complemento de OpenSearch paneles de control que simplifica las tareas de administración. Puede utilizar Dashboards para administrar usuarios, roles, mapeos, grupos de acciones e inquilinos. Sin embargo, la página de inicio de sesión de OpenSearch Dashboards y el método de autenticación subyacente varían según la forma en que administre los usuarios y configure su dominio.

• Si desea utilizar IAM para la administración de usuarios, utilice Configuración de la autenticación de Amazon Cognito para OpenSearch Dashboards para acceder a Dashboards. De lo contrario, Dashboards muestra una página de inicio de sesión no funcional. Consulte Limitaciones.

  Con la autenticación de Amazon Cognito, uno de los roles asumidos del grupo de identidades debe coincidir con el rol de IAM especificado para el usuario maestro. Para obtener más información acerca de esta configuración, consulte (Opcional) Configuración de acceso pormenorizado y Tutorial: Configurar un dominio con un usuario maestro de IAM y la autenticación de Amazon Cognito.

  

• Si decide utilizar la base de datos de usuarios interna, puede iniciar sesión en Dashboards con su nombre de usuario maestro y contraseña. Debe obtener acceso a Dashboards a través de HTTPS. La autenticación de Amazon Cognito y SAML para Dashboards reemplazan esta pantalla de inicio de sesión.

  Para obtener más información acerca de esta configuración, consulte Tutorial: Configurar un dominio con la base de datos de usuarios interna y la autenticación básica de HTTP.

  

• Si elige utilizar la autenticación SAML, puede iniciar sesión con credenciales de un proveedor de identidad externo. Para obtener más información, consulte Autenticación SAML para paneles OpenSearch .

Administrar permisos

Tal y como se indica en Conceptos clave, puede administrar los permisos de control de acceso detallado mediante roles, usuarios y mapeos. En esta sección, se describe cómo crear y aplicar esos recursos. Recomendamos que inicie sesión en Dashboards como usuario maestro para realizar estas operaciones.

nota

Los permisos que elige conceder a los usuarios varían ampliamente en función del caso de uso. No podemos cubrir de forma factible todos los escenarios de esta documentación. Al determinar qué permisos conceder a sus usuarios, asegúrese de consultar los permisos de OpenSearch clúster e indexación que se mencionan en las siguientes secciones y siga siempre el principio de privilegios mínimos.

Crear roles

Puede crear nuevas funciones para un control de acceso más detallado mediante los OpenSearch paneles de control o la _plugins/_security operación en la API REST. Para obtener más información, consulte Create roles (Crear roles).

El control de acceso detallado también incluye varios roles predefinidos. Los clientes como OpenSearch Dashboards y Logstash realizan una amplia variedad de solicitudes OpenSearch, lo que puede dificultar la creación manual de roles con el conjunto mínimo de permisos. Por ejemplo, el rol opensearch_dashboards_user incluye los permisos que un usuario necesita para trabajar con patrones de índices, visualizaciones, paneles e inquilinos. Recomendamos mapearlo a cualquier rol de usuario o backend que tenga acceso a Dashboards, junto con los roles adicionales que permitan el acceso a otros índices.

Amazon OpenSearch Service no ofrece las siguientes OpenSearch funciones:

• observability_full_access

• observability_read_access

• reports_read_access

• reports_full_access

Amazon OpenSearch Service ofrece varios roles que no están disponibles en OpenSearch:

• ultrawarm_manager

• ml_full_access

• cold_manager

• notifications_full_access

• notifications_read_access

Seguridad en el nivel del clúster

Los permisos en el nivel del clúster incluyen la capacidad de ejecutar solicitudes generales como _mget, _msearch y _bulk, monitorear el estado o tomar instantáneas, etc. Administre estos permisos mediante la sección Permisos de clúster al crear un rol. Para obtener una lista completa de los permisos de nivel de clúster, consulte Permisos de cluster.

En lugar de permisos individuales, a menudo puede alcanzar la posición de seguridad deseada mediante una combinación de los grupos de acciones predeterminadas. Para obtener una lista de grupos de acciones en el nivel del clúster, consulte Nivel del clúster.

Seguridad en el nivel del índice

Los permisos en el nivel del índice incluyen la capacidad de crear nuevos índices, buscar índices, leer y escribir documentos, eliminar documentos, administrar alias y mucho más. Administre estos permisos con la sección Permisos de índice al crear un rol. Para obtener una lista completa de los permisos de nivel de índice, consulte Permisos de índice.

En lugar de permisos individuales, a menudo puede alcanzar la posición de seguridad deseada mediante una combinación de los grupos de acciones predeterminadas. Para obtener una lista de grupos de acciones en el nivel del índice, consulte Nivel del índice.

Seguridad en el nivel del documento

La seguridad en el nivel del documento permite restringir los documentos de un índice que puede ver un usuario. Al crear un rol, especifique un patrón de índice y una OpenSearch consulta. Cualquier usuario que se mapee a ese rol únicamente podrá ver los documentos que coincidan con la consulta. La seguridad en el nivel del documento afecta al número de aciertos que se reciben al realizar una búsqueda.

Para obtener más información, consulte Seguridad en el nivel del documento.

Seguridad en el nivel del campo

La seguridad en el nivel del campo permite controlar qué campos de documento puede ver un usuario. Al crear un rol, agregue una lista de campos para incluirlos o excluirlos. Si incluye campos, los usuarios que mapee a ese rol solo podrán ver esos campos. Si excluye campos, podrán ver todos los campos excepto los excluidos. La seguridad en el nivel del campo afecta al número de campos que se incluyen en los aciertos al realizar una búsqueda.

Para obtener más información, consulte Seguridad en el nivel del campo.

Enmascarar campos

El enmascaramiento de campos es una alternativa a la seguridad en el nivel del campo que permite anonimizar los datos de un campo en lugar de eliminarlos por completo. Al crear un rol, agregue una lista de campos que se van a enmascarar. El enmascaramiento de campos afecta a si se podrá ver el contenido de un campo al realizar búsquedas.

sugerencia

Si aplica el enmascaramiento estándar a un campo, OpenSearch Service utiliza un hash aleatorio y seguro que puede provocar resultados de agregación imprecisos. Para realizar agregaciones en campos enmascarados, utilice el enmascaramiento con base en patrones en su lugar.

Crear usuarios

Si habilitó la base de datos de usuarios interna, puede crear usuarios mediante OpenSearch paneles o la _plugins/_security operación de la API REST. Para obtener más información, consulte Crear usuarios.

Si elige IAM para el usuario maestro, pase por alto esta parte de Dashboards. En su lugar, cree roles de IAM. Para obtener más información, consulte la Guía del usuario de IAM.

Mapear roles a usuarios

El mapeo de roles es el aspecto más crítico del control de acceso detallado. El control de acceso detallado tiene algunos roles predefinidos para ayudarlo a comenzar, pero a menos que mapee roles a los usuarios, cada solicitud al clúster dará lugar a un error de permisos.

Roles de backend pueden ayudar a simplificar el proceso de asignación de roles. En lugar de asignar el mismo rol a 100 usuarios individuales, puede asignar el rol a un único rol de backend que compartan los 100 usuarios. Los roles de backend pueden ser roles de IAM o cadenas arbitrarias.

• Especifique los usuarios, los ARN de usuario y las cadenas de usuario de Amazon Cognito en la sección Usuarios. Las cadenas de usuario de Cognito toman la forma de Cognito/user-pool-id/username.

• Especifique los roles de backend y los ARN de rol de IAM en la sección Roles de backend.

Puede asignar funciones a los usuarios mediante los OpenSearch paneles de control o la _plugins/_security operación en la API REST. Para obtener más información, consulte Mapear usuarios a roles.

Crear grupos de acciones

Los grupos de acciones son conjuntos de permisos que puede reutilizar en diferentes recursos. Puede crear nuevos grupos de acciones mediante OpenSearch paneles o la _plugins/_security operación de la API REST, aunque los grupos de acciones predeterminados son suficientes para la mayoría de los casos de uso. Para obtener más información acerca de los grupos de acciones predeterminados, consulte Grupos de acciones predeterminados.

OpenSearch Tableros de mandos multiusuario

Los inquilinos son espacios para guardar patrones de índices, visualizaciones, paneles y otros objetos de Dashboards. El uso de varios inquilinos en Dashboards permite compartir el trabajo de forma segura con otros usuarios de Dashboards (o mantenerlo en privado) y configurar inquilinos de forma dinámica. Puede controlar qué roles tienen acceso a un inquilino y si esos roles tienen acceso de lectura o de escritura. El inquilino global es el predeterminado. Para obtener más información, consulte OpenSearch Dashboards sobre tenencia múltiple.

Para ver al inquilino actual o cambiar de inquilino

1. Ve a los OpenSearch paneles de control e inicia sesión.

2. Seleccione el icono de usuario en la parte superior derecha y elija Cambiar inquilinos.

3. Compruebe el inquilino antes de crear visualizaciones o paneles. Si desea compartir su trabajo con todos los demás usuarios de Dashboards, seleccione Global. Para compartir el trabajo con un subconjunto de usuarios de Dashboards, elija otro inquilino compartido. De lo contrario, seleccione Privado.

nota

OpenSearch Dashboards mantiene un índice independiente para cada inquilino y crea una plantilla de índice llamada. tenant_template No elimine ni modifique el tenant_template índice, ya que podría provocar un mal funcionamiento de los OpenSearch paneles si el mapeo del índice de inquilinos está mal configurado.

Configuraciones recomendadas

Debido a la forma en que el control de acceso detallado interactúa con otras características de seguridad, recomendamos varias configuraciones de control de acceso detallado que funcionan bien en la mayoría de los casos de uso.

Descripción	Usuario maestro	Política de acceso al dominio
Utilice las credenciales de IAM para las llamadas a OpenSearch las API y utilice la autenticación SAML para acceder a los paneles. Administre los roles de control de acceso detallado mediante Dashboards o la API REST.	Rol o usuario de IAM	{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }
Utilice las credenciales de IAM o la autenticación básica para las llamadas a las API. OpenSearch Administre los roles de control de acceso detallado mediante Dashboards o la API REST. Esta configuración ofrece mucha flexibilidad, especialmente si tiene OpenSearch clientes que solo admiten la autenticación básica. Si tiene un proveedor de identidad existente, utilice autenticación SAML para acceder a Dashboards. En caso contrario, administre los usuarios de Dashboards en la base de datos de usuarios interna.	Nombre de usuario y contraseña	{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }
Utilice las credenciales de IAM para las llamadas a las OpenSearch API y Amazon Cognito para acceder a los paneles. Administre los roles de control de acceso detallado mediante Dashboards o la API REST.	Rol o usuario de IAM	{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }
Utilice las credenciales de IAM para las llamadas a las OpenSearch API y bloquee la mayoría de los accesos a los paneles. Administre los roles de control de acceso detallado mediante la API REST.	Rol o usuario de IAM	{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" }, { "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/_dashboards*" } ] }

Limitaciones

El control de acceso detallado tiene varias limitaciones importantes:

• El aspecto hosts de los mapeos de roles, que mapea roles a nombres de anfitrión o direcciones IP, no funciona si el dominio está dentro de una VPC. Aun así, puede mapear roles a usuarios y roles de backend.

• Si elige IAM para el usuario maestro y no habilita la autenticación de Amazon Cognito o SAML, Dashboards muestra una página de inicio de sesión no funcional.

• Si elige IAM para el usuario maestro, podrá crear usuarios en la base de datos de usuarios interna. Sin embargo, debido a que la autenticación básica de HTTP no está habilitada en esta configuración, todas las solicitudes firmadas con esas credenciales de usuario se rechazarán.

• Si utiliza SQL para consultar un índice al que no tiene acceso, recibirá un error debido a que no tiene los permisos necesarios. Si el índice no existe, recibirá un error debido a que ese índice no existe. Esta diferencia en los mensajes de error significa que puede confirmar si un índice existe o no, en el caso de que trate de adivinar su nombre.

  Para minimizar el problema, no incluya información confidencial en los nombres de índice. Para denegar por completo el acceso a SQL, agregue el siguiente elemento a la política de acceso al dominio:

  {
    "Effect": "Deny",
    "Principal": {
      "AWS": [
        "*"
      ]
    },
    "Action": [
      "es:*"
    ],
    "Resource": "arn:aws:es:us-east-1:123456789012:domain/my-domain/_plugins/_sql"
  }

• Si la versión de su dominio es 2.3 o superior y tiene activado el control de acceso detallado, configurar max_clause_count en 1 provocará problemas con su dominio. Le recomendamos configurar esta cuenta con un número superior.

• Si está habilitando un control de acceso detallado en un dominio en el que no está configurado un control de acceso detallado, en el caso de las fuentes de datos creadas para consultas directas, tendrá que configurar usted mismo las funciones de control de acceso detalladas. Para obtener más información sobre cómo configurar funciones de acceso detalladas, consulte Creación de integraciones de fuentes de datos de Amazon OpenSearch Service con Amazon S3.

Modificar el usuario maestro

Si olvida los detalles del usuario maestro, puede reconfigurarlo mediante la consola, la AWS CLIo la API de configuración.

Para modificar el usuario maestro (consola)

1. Dirígete a la consola OpenSearch de Amazon Service en https://console.aws.amazon.com/aos/home/.

2. Seleccione el dominio y seleccione Acciones, Editar la configuración de seguridad.

3. Elika Establecer ARN de IAM como usuario maestro o bien Crear usuario maestro.

   • Si ha utilizado anteriormente un usuario maestro de IAM, el control de acceso detallado volverá a mapear el rol all_access al nuevo ARN de IAM que especifique.

   • Si ha utilizado previamente la base de datos de usuarios interna, el control de acceso detallado creará un usuario maestro. Puede utilizar el nuevo usuario maestro para eliminar el anterior.

   • Cambiar la base de datos de usuario interna a un usuario maestro de IAM no elimina ningún usuario de la base de datos de usuarios interna. En su lugar, simplemente desactiva la autenticación básica de HTTP. Elimine manualmente usuarios de la base de datos interna de usuarios o guárdelos en caso de que necesite volver a habilitar la autenticación básica de HTTP.

4. Seleccione Guardar cambios.

Usuarios maestros adicionales

Se designa un usuario maestro al crear un dominio. Sin embargo, si lo desea, puede utilizar este usuario maestro para crear usuarios maestros adicionales. Tienes dos opciones: OpenSearch paneles de control o la API REST.

• En Dashboards, seleccione Seguridad, Roles y, a continuación, mapee el nuevo usuario maestro a los roles all_access y security_manager.

  

• Para utilizar la API REST, envíe las siguientes solicitudes:

  PUT _plugins/_security/api/rolesmapping/all_access
  {
    "backend_roles": [
      "arn:aws:iam::123456789012:role/fourth-master-user"
    ],
    "hosts": [],
    "users": [
      "master-user",
      "second-master-user",
      "arn:aws:iam::123456789012:user/third-master-user"
    ]
  }

  PUT _plugins/_security/api/rolesmapping/security_manager
  {
    "backend_roles": [
      "arn:aws:iam::123456789012:role/fourth-master-user"
    ],
    "hosts": [],
    "users": [
      "master-user",
      "second-master-user",
      "arn:aws:iam::123456789012:user/third-master-user"
    ]
  }

  Estas solicitudes reemplazan los mapeos de roles actuales. Por consiguiente, deber realizar las solicitudes GET primero para que pueda incluir todos los roles actuales en las solicitudes PUT. La API REST resulta especialmente útil si no puede obtener acceso a Dashboards y desea mapear un rol de IAM desde Amazon Cognito al rol all_access.

Instantáneas manuales

El control de acceso detallado presenta algunas complicaciones adicionales con la toma de instantáneas manuales. Para registrar un repositorio de instantáneas, aunque utilice la autenticación básica de HTTP para todos los demás fines, debe mapear el rol manage_snapshots a un rol de IAM que tenga permisos iam:PassRole para asumir TheSnapshotRole, tal como se define en Requisitos previos.

A continuación, utilice ese rol de IAM para enviar una solicitud firmada al dominio, como se describe en Registrar un repositorio de instantáneas manuales.

Integraciones

Si utiliza otros AWS servicios con el OpenSearch Servicio, debe proporcionar las funciones de IAM para esos servicios con los permisos adecuados. Por ejemplo, las transmisiones de entrega de Firehose suelen utilizar una función de IAM llamada. firehose_delivery_role En Dashboards, cree un rol para el control de acceso detallado y mapee el rol de IAM a ese rol. En este caso, el nuevo rol necesita los siguientes permisos:

{
  "cluster_permissions": [
    "cluster_composite_ops",
    "cluster_monitor"
  ],
  "index_permissions": [{
    "index_patterns": [
      "firehose-index*"
    ],
    "allowed_actions": [
      "create_index",
      "manage",
      "crud"
    ]
  }]
}

Los permisos varían en función de las acciones que realice cada servicio. Es probable que una AWS IoT regla o AWS Lambda función que indexe datos necesite permisos similares a los de Firehose, mientras que una función de Lambda que solo realiza búsquedas puede utilizar un conjunto más limitado.

Diferencias en la API REST

La API REST de control de acceso detallada varía ligeramente según la versión de /Elasticsearch. OpenSearch Antes de realizar una solicitud PUT, realice una solicitud GET para saber cómo es el cuerpo de la solicitud esperado. Por ejemplo, una solicitud GET para _plugins/_security/api/user devuelve todos los usuarios, que luego puede modificar y utilizar para realizar solicitudes PUT válidas.

En Elasticsearch 6.x, las solicitudes para crear usuarios tienen este aspecto:

PUT _opendistro/_security/api/user/new-user
{
  "password": "some-password",
  "roles": ["new-backend-role"]
}

En OpenSearch Elasticsearch 7.x, las solicitudes tienen este aspecto (cámbiese a si usa Elasticsearch): _plugins _opendistro

PUT _plugins/_security/api/user/new-user
{
  "password": "some-password",
  "backend_roles": ["new-backend-role"]
}

Además, los inquilinos son propiedades de los roles en Elasticsearch 6.x:

GET _opendistro/_security/api/roles/all_access

{
  "all_access": {
    "cluster": ["UNLIMITED"],
    "tenants": {
      "admin_tenant": "RW"
    },
    "indices": {
      "*": {
        "*": ["UNLIMITED"]
      }
    },
    "readonly": "true"
  }
}

En OpenSearch Elasticsearch 7.x, son objetos con su propio URI (cámbielo si usa Elasticsearch):: _plugins _opendistro

GET _plugins/_security/api/tenants

{
  "global_tenant": {
    "reserved": true,
    "hidden": false,
    "description": "Global tenant",
    "static": false
  }
}

Para obtener documentación sobre la API OpenSearch REST, consulta la referencia sobre la API del complemento de seguridad.

sugerencia

Si utiliza la base de datos de usuarios interna, puede utilizar curl para realizar solicitudes y probar el dominio. Pruebe los siguientes comandos de muestra:

curl -XGET -u 'master-user:master-user-password' 'domain-endpoint/_search'
curl -XGET -u 'master-user:master-user-password' 'domain-endpoint/_plugins/_security/api/user'