Segurança em domínio do Elasticsearch na AWS – Entendendo as Camadas de Segurança – Parte 1

Por Maria Ane Dias, Arquiteta de Soluções da AWS Brasil

Durante o processo de criação de um domínio do Amazon Elasticsearch Service (Elasticsearch) existem decisões a serem tomadas com relação a segurança, a ideia aqui é explicar como estas opções funcionam e como uma influencia ou depende da outra.
Primeiro, é importante entender que a segurança do Amazon Elasticsearch tem três camadas principais:

Rede

A primeira camada de segurança é a rede, que determina onde estará localizado o endpoint que receberá as solicitações a um domínio do Amazon ES e como estas solicitações serão inspecionadas até chegarem a este endpoint.

 Política de acesso ao domínio

A segunda camada de segurança é a política de acesso ao domínio. Depois que uma solicitação chega a um endpoint do domínio, a política de acesso baseada em recursos permite ou nega o acesso da solicitação a uma determinada URI. A política de acesso aceita ou rejeita solicitações na “borda” do domínio, antes que elas cheguem ao Elasticsearch.

Controle de acesso granular

A terceira e última camada de segurança é o controle de acesso granular. Depois que uma política de acesso baseada em recursos permitir que uma solicitação chegue a um endpoint do domínio, o controle de acesso granular avaliará as credenciais do usuário e autenticará o usuário ou negará a solicitação. Se o controle de acesso granular autenticar o usuário, ele obterá todas as funções mapeadas para esse usuário e usará o conjunto completo de permissões para determinar como lidar com a solicitação.

Cada decisão está relacionada com uma destas camadas e uma tem influência na outra, conforme explicado abaixo:

Rede

 A primeira decisão de redes e segurança a ser tomada é se o acesso será feito pela internet ou por uma Amazon Virtual Private Cloud (VPC), a rede privada virtual na AWS. Conforme a documentação: “Para habilitar o acesso à VPC, usamos endereços IP privados de sua VPC, que fornece uma camada inerente de segurança. Você controla o acesso à rede em seu VPC usando grupos de segurança. Opcionalmente, você pode adicionar uma camada extra de segurança aplicando uma política de acesso restritiva. Os endpoints da Internet são acessíveis ao público. Se você selecionar o acesso público, deverá proteger seu domínio com uma política de acesso que permita apenas a usuários ou endereços IP específicos acessarem o domínio.”

Ou seja, usando a opção de VPC os clientes devem se conectar à VPC (e a segurança da própria VPC deve permitir) para que uma solicitação chegue ao endpoint do Elasticsearch. Por exemplo, usando VPN, Direct Connect ou uma máquina dentro da rede da AWS (uma EC2, por exemplo). Como descrito na documentação, isto já fornece uma camada de segurança.

Controle de acesso granular

 A segunda decisão a ser tomada é referente ao controle de acesso granular “Fine-grained access control”. Ele oferece formas adicionais de controlar o acesso aos seus dados no Amazon Elasticsearch Service. Por exemplo, dependendo de quem faz a solicitação, você pode querer que uma pesquisa retorne resultados de somente um índice, ocultar determinados campos em seus documentos ou excluir determinados documentos completamente da pesquisa. O controle de acesso granular oferece os seguintes recursos:

• Controle de acesso com base em roles
• Segurança nos níveis de índice, documento e campo
• Kibana multi-locatário
• Autenticação básica HTTP para o Elasticsearch e o Kibana

Existem duas opções para usar este acesso de controle granular, a primeira é selecionar um IAM ARN como usuário principal e a outra é criando um usuário principal (master user).

O AWS Identity and Access Management (IAM) permite que você gerencie com segurança o acesso aos serviços e recursos da AWS.

Criando um usuário master o seu domínio terá uma base de dados interna de usuários habilitada com autenticação HTTP básica. Habilitando o uso da autenticação do Kibana usando o Amazon Cognito a autenticação e autorização passa a ser feita por lá. Seja qual for a opção escolhida, o usuário mestre pode acessar todos os índices no cluster e todas as APIs do Elasticsearch.

Na autenticação básica você perde os usuários caso apague seu domínio, no Cognito você tem o custo adicional do Serviço (disponível aqui) mas, está gerenciando os usuários em um serviço separado, o que faz com que você não perca os usuários criados podendo inclusive associar o mesmo pool de usuários para mais de um domínio.

Caso você tenha optado por usar o acesso granular com IAM ARN será obrigatório o uso do Cognito. Isso porque os usuários precisam existir em algum lugar, se eles não estão no banco de dados interno do seu domínio eles precisam estar no Cognito. Caso você tenha optado por usar o acesso granular com Master User, se tentar habilitar o Cognito receberá uma mensagem avisando que você está usando um banco de dados de usuário interno e pede para desabilitar a opção de Cognito OU mudar para IAM ARN.

Mas, caso você NÃO tenha habilitado o controle de acesso granular, ainda assim é possível usar o Amazon Cognito para fazer a autenticação no Kibana. Esta é a terceira decisão a ser tomada. Esse recurso de autenticação com o Cognito é opcional e disponível apenas para domínios que usam o Elasticsearch 5.1 ou posterior. Se você estiver usando uma região onde não tem Cognito disponível, é possível usar um pool configurado em outra região, só se atentando a latência – ideal ser uma região próxima. Se você não configurar nem o acesso granular e nem a autenticação do Amazon Cognito, ainda poderá proteger o Kibana usando uma política de acesso baseada em IP e um servidor de proxy.

No próximo blogpost abordarei como criar e configurar o Cognito para ser utilizado com o Kibana.

Um ponto importante sobre o acesso de controle granular é que ele te oferece opções de Segurança no dashboard do Kibana e gerenciamento dos “locatários”.

O Tenant ou “locatário” é um container/espaço nomeado para armazenar objetos salvos e pode ser atribuído a um ou mais roles do Search Guard, o qual garante que os objetos salvos sejam colocados no Tenant selecionado. O Search Guard roles é o local central para configurar permissões de acesso.

 Acesso Granular ativado – note o menu a esquerda, opções de Segurança e Tenant:

Caso tenha optado pela criação do master user administre os usuários pelo Internal Database user, caso contrário utilize o Cognito. A opção de Segurança só aparecerá se o administrador conceder acesso ao usuário (role de Security Manager), sendo que o administrador é o master user informado no momento da criação do domínio.

Sem acesso granular habilitado as duas últimas opções do menu não aparecem:

Até as telas de login de Internal User e Cognito são diferentes:

 Tela de login Internal User Database:

Tela de Login Cognito – não adianta criar usuários no Kibana Internal User Database e tentar logar aqui, pois ele irá procurar os usuários no Cognito – vai aparecer mensagem de usuário inválido:

Política de acesso ao domínio

A quarta decisão de segurança a ser tomada é a política de acesso ao domínio onde é possível permitir ou negar acesso por ID de conta AWS, ARN de conta, ARN de usuário IAM, ARN de role IAM, endereço IPv4 ou bloco CIDR. As opções são apresentadas abaixo. O Custom acess policy dá alguns combos a serem preenchidos para facilitar a criação da política sendo que você só precisa ter o ARN, ID ou IP em mãos.

Existe, ainda, a opção que diz “Allow open access to the domain”. Para usar esta opção é preciso ativar o controle de acesso granular, caso contrário será solicitado que seja aplicada uma política de acesso restritiva ao seu domínio. Entende-se que com um controle de acesso granular o domínio requer autenticação apesar de estar aberto.

De qualquer maneira, como boa prática de segurança, é recomendado que seja aplicada uma política restritiva. Uma restrição por IP/CIDR pode ser feita independente dos usuários (Principals) que vão acessar o Kibana, por exemplo:

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

Importante, se tiver uma policy assim no seu domínio e ele não estiver em uma VPC nem tiver controle de acesso granular, ele está aberto, então, use as informações acima para restringi-lo!

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

Criptografia

A quinta e última decisão é a parte de criptografia, que dá as opções de que todo tráfego para o domínio seja HTTPS, criptografia de Node para Node e habilitar criptografia dos dados em repouso. Você pode optar por deixar o Elasticsearch criar uma chave no AWS Key Management Service (KMS) ou utilizar uma chave já criada usando seu ARN. Chaves criadas pelos clientes podem ser configuradas para serem rotacionadas de forma automatica anualmente. As chaves gestionadas pela AWS são rotacionadas automaticamente a cada 3 anos.

Optando por controle de acesso granular, estas opções são obrigatórias. Mas, como é fácil usar a criptografia, principalmente integrada com o KMS, não deixe de utilizar. É uma boa prática!

Neste vídeo rápido no YouTube da AWS Latam é possível ver Como AWS KMS ajuda a proteger seu conteúdo

Links Úteis

• Gerenciamento de identidades e acesso no Amazon Elasticsearch Service
• Controle de acesso granular no Amazon Elasticsearch Service
• Limitações Master User Internal Database – checar o tópico Limitations
• Set Access Control for Amazon Elasticsearch Service
• Tenants Definition – Kibana
• Search Guard Roles – Kibana

Sobre a autora

Maria Ane Dias é arquiteta de soluções na AWS e gosta/atua bastante da área de Segurança, Desenvolvimento e IoT além da vertical de Manufatura. Atua auxiliando clientes iniciantes em suas jornadas para a nuvem. Tem 16 anos de experiência em desenvolvimento e arquitetura de software e 2 com arquitetura de soluções.

Agradecimentos: Daniel Garcia, Lucas Lins e Gustavo Rozatti dos times de  segurança e arquitetura pela revisão deste blogpost.