Blog de Amazon Web Services (AWS)

Seguridad de un dominio Elasticsearch en AWS – Parte 1

Por Maria Ane Dias, Arquitecta de Soluciones, AWS Brasil
Mauricio Muñoz, Gerente de Arquitectos Especialistas, AWS Chile

 

Durante el proceso de creación de un dominio de Amazon Elasticsearch Service (Elasticsearch) hay que tomar decisiones con respecto a la seguridad. En este documento se  explica cómo funcionan estas opciones y cómo influyen o dependen entre sí.
En primer lugar, es importante comprender que la seguridad de Amazon Elasticsearch Service tiene tres capas principales:

Red

La primera capa de seguridad es la red, que determina dónde se ubicará el endpoint que recibe solicitudes a un dominio de Amazon ES y cómo se inspeccionarán estas solicitudes hasta que lleguen a este endpoint.

Política de acceso al dominio

La segunda capa de seguridad es la política de acceso al dominio. Después de que una solicitud llega al endpoint del dominio, la política de acceso basada en recursos permite o niega el acceso de solicitud a un URI determinado. La política de acceso acepta o rechaza solicitudes en el «borde» del dominio antes de que lleguen a Elasticsearch.

Control granular de acceso

La tercera y última capa de seguridad es el control de acceso granular. Después de que una política de acceso basada en recursos permite que una solicitud llegue al endpoint del dominio, el control de acceso granular evalúa las credenciales de usuario y lo autentica o niega la solicitud. Si el control de acceso granular autentica al usuario, a continuación obtiene todos los roles asignados a ese usuario y utiliza el conjunto completo de permisos para determinar cómo manejar la solicitud (autorización).

Ahora, vamos a entrar en el detalle de cada capa, entendiendo las decisiones con cada una de estas capas y su influencia entre ellas, como se explica a continuación:

 

Red

La primera decisión sobre redes y seguridad que se debe tomar es si el acceso se realizará a través de Internet o a través de una red privada virtual de Amazon (VPC) . Según la documentación: « Para habilitar el acceso a VPC, utilizamos direcciones IP privadas de su VPC, lo que proporciona una capa inherente de seguridad. Puede controlar el acceso a la red en su VPC mediante grupos de seguridad. Si lo desea, puede agregar una capa adicional de seguridad aplicando una política de acceso. Los endpoints de Internet son accesibles al público. Si selecciona acceso público, debe proteger su dominio con una política de acceso que permita que sólo usuarios o direcciones IP específicas accedan al dominio».

Es decir, al utilizar la opción VPC, los clientes deben conectarse a la VPC (y la seguridad de la propia VPC debe permitir esta conexión) para que una solicitud llegue al endpoint de Elasticsearch. Por ejemplo, utilizando VPN, Direct Connect o una máquina dentro de la VPC de AWS (una instancia Amazon EC2). Como se describe en la documentación, esto ya proporciona una capa de seguridad.

 

 

Control granular de acceso

 La segunda decisión que debe adoptarse es si quiere habilitar el control granular del acceso “Fine-grained access control”. Esta funcionalidad de Elasticsearch proporciona formas adicionales de controlar el acceso a sus datos en el dominio. Por ejemplo, dependiendo de quién realice la solicitud, es posible que desee que una búsqueda devuelva resultados de un solo índice, oculte ciertos campos en los documentos o elimine determinados documentos completamente de la búsqueda. El control granular de acceso proporciona las siguientes características:

  • Control de acceso basado en roles
  • Seguridad en los niveles de índice, documento y campo
  • Seguridad para usar Kibana “multitenant”
  • Soporta autenticación HTTP básica para Elasticsearch y Kibana

El control granular de acceso require la configuración de un usuario maestro en el dominio de Elasticsearch. Este usuario maestro podrá crear los usuarios, los roles con los permisos requeridos para acceder a la información y los mapeos entre usuarios y roles. En un dominio de Amazon Elasticsearch service hay dos opciones para definir este usuario maestro: la primera es seleccionar un ARN de IAM como usuario maestro (y en ese caso todas las solicitudes al cluster deben ser firmadas usando AWS Signature V4). La otra es crear un usuario maestro que será almacenado en la base de datos interna de Elasticsearch (en este caso las solicitudes al cluster también pueden utilizar HTTP Basic authentication).

Tenga en cuenta que cualquiera que sea la opción que elija, el usuario maestro puede acceder a todos los índices del clúster y a todas las API de Elasticsearch.

Una de las principales ventajas de usar IAM para administración de usuarios es que en caso de que borre el dominio de Elasticsearch, no se pierden los usuarios. Además, puede permitir el acceso de un mismo usuario a diferentes dominios.

 

 

La tercera decisión que hay que tomar es definir si se utiliza Amazon Cognito para autenticar los accesos a Kibana. Esta función de autenticación es opcional y está disponible para dominios que utilicen Elasticsearch versión 5.1 o posterior.

Si escoge utilizar el control granular de acceso con un usuario maestro en IAM, se recomienda el uso de Amazon Cognito para autenticar el acceso a Kibana (ya que si no lo habilita, la página web de autenticación de Kibana no funcionará).  Por otro lado, si escoge utilizar el control granular de acceso con un usuario maestro almacenado internamente en la base de datos de Elasticsearch, debe deshabilitar la opción de utilizar Amazon Cognito para autenticar el acceso a Kibana. Esto se debe a que para autenticación de usuarios,  Amazon Cognito utilizará su propio repositorio de usuarios en lugar de la base de datos interna (y por lo tanto si usa Amazon Cognito, no podría acceder al usuario maestro).

Utilizar Amazon Cognito permite tener la administración de usuarios separada del dominio de Elasticsearch (lo que le hace no perder usuarios creados en caso de borrar el dominio e incluso asociar el mismo grupo de usuarios para más de un dominio).  Tenga en cuenta que Amazon Cognito tiene un costo adicional (más información disponible aquí) .

Si NO ha habilitado el control de acceso granular, también puede utilizar Amazon Cognito para autenticarse en Kibana (en ese caso todo usuario autenticado usa el mismo rol IAM). Si está utilizando una región en la que no tiene Amazon Cognito disponible, puede usar un grupo configurado en otra región (sin embargo, tenga en cuenta minimizar la latencia buscando una región cercana). Si no configura el control granular de acceso o la autenticación de Amazon Cognito, puede proteger Kibana utilizando una política de acceso basada en IP y un servidor proxy.

 

 

En el próximo blog explicaré cómo crear y configurar Cognito para ser utilizado con Kibana.

Un punto importante sobre el acceso de control granular es que le ofrece opciones de seguridad en el panel de control de Kibana y administración de múltiples «tenant».

Un «tenant» es un contenedor/espacio nombrado que almacena objetos grabados y se puede asignar a uno o más roles. Esta funcionalidad es ofrecida por un plugin para Elasticsearch llamado Search Guard.

En la consola de AWS, una vez ha sido creado el dominio de Elasticsearch, podrá encontrar la URL para abrir la consola de Kibana.

Las pantallas de inicio de sesión web en Kibana son diferentes, dependiendo de si está administrando los usuarios en la base de datos interna o si está utilizando Amazon Cognito.

Pantalla de inicio de sesión si utiliza la base de datos interna para administrar los usuarios:

 

Pantalla de inicio de sesión si utiliza Amazon Cognito — recuerde que en este caso no puede utilizar la base de datos interna de usuarios de Elasticsearch, ya que los usuarios están almacenados en Amazon Cognito.

 

 

Una vez ingrese a la consola de Kibana:

Si el control granular de acceso está habilitado notará que en el menú de la izquierda aparecen las opciones de Security y Tenant (son las últimas dos opciones, abajo a la izquierda):

 

 

Para usuarios diferentes al usuario maestro, la opción Security sólo aparece si el administrador (usuario maestro) le concedió acceso (asignándole el rol de  Security Manager).

Si no activa el control granular de acceso, las dos últimas opciones de menú no aparecen:

 

 

Política de acceso al dominio

La cuarta decisión de seguridad que se debe tomar es cuál política de acceso al dominio utilizar.  Una política de acceso al dominio es una política aplicada a un recurso (resource-based policy) puede permitir o negar el acceso de una cuenta AWS (ya sea por ID o por ARN), usuario de IAM, rol de IAM, dirección IPv4 o bloque CIDR. Las opciones se presentan a continuación. La política de acceso personalizada (Custom Access policy) facilita la creación de la política ya que presenta una interfaz donde solo deben llenarse los campos necesarios, solo necesita tener la información del ARN, ID o dirección IP.

 

También existe, la opción que dice «Allow open access to the domain». Esta opción solo es permitida si el dominio tiene habilitado el control granular de acceso (de lo contrario, se le pedirá que aplique una directiva de acceso restrictivo a su dominio). Se entiende que con el control granular de acceso el dominio requiere autenticación aunque esté abierto.

En cualquier caso, como buena práctica de seguridad se recomienda aplicar una política restrictiva. Una restricción de IP/CIDR puede hacerse independiente de los usuarios (Principals) que accedan a Kibana, por ejemplo:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:us-east-1:XXXXXXXXXXXX:domain/nombre-dominio/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "10.XX.XXX.X/24",
            "10.XX.XXX.XX",
            "72.XX.XXX.XX"
          ]
        }
      }
    }
  ]
}

Importante, si su dominio tiene una política como la de abajo y no está en una VPC ni tiene control de acceso granular, significa que está abierto.  ¡Use adecuadamente los rangos de direcciones IP en una política como la anterior para restringir el acceso! 

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:us-east-1:XXXXXXXXXXXX:domain/nombre-dominio/*"
    }
  ]
}

 

Cifrado

La quinta y última decisión es la parte de cifrado. En esta sección se ofrece la posibilidad de habilitar la criptografía en tránsito (obligando que todo tráfico de acceso al dominio use HTTPS y que la comunicación entre nodos del cluster esté cifrada) así como habilitar el cifrado de datos en reposo (incluyendo tanto los índices como los snapshots). Elasticsearch usa una llave de AWS Key Management Service (KMS) para proteger las llaves que encriptan el dominio. Puede optar por usar una llave administrada por AWS, utilizar una llave creada y gestionada por usted en KMS o inclusive utilizar una llave de KMS de otra cuenta. Las llaves creadas por los clientes se pueden configurar para rotar automáticamente anualmente. Las claves administradas por AWS se rotan automáticamente cada 3 años.

Si utiliza control granular de acceso, estas opciones de cifrado son obligatorias. En cualquier caso, con la facilidad de uso del cifrado, especialmente integrado con KMS, asegúrese de usarlo. ¡Es una buena práctica!

En este vídeo rápido de YouTube de AWS Latam puede ver cómo AWS KMS ayuda a proteger su contenido

 

 

Enlaces útiles

 

Este artículo fue traducido del Blog de AWS en Portugués.

 

Sobre los autores

Maria Ane Dias es arquitecta de soluciones de AWS. Apasionada por el área de seguridad, desarrollo e IoT además de la vertical de manufactura. Trabaja ayudando a nuevos clientes en su viaje a la nube. Tiene 16 años de experiencia en desarrollo y arquitectura de software y 2 con arquitectura de soluciones.

 

 

 

 

Mauricio Muñoz es Gerente de arquitectos especialistas en AWS, con más de 20 años de experiencia en áreas de tecnología de información y seguridad.