Autenticação e autorização no Elasticsearch desmistificadas

By
Gabriel Moskovicz

Trabalho na Elastic há mais de quatro anos, sendo três anos e meio em suporte e consultoria e o último semestre em vendas. Independentemente do departamento onde eu esteja, as perguntas mais comuns que recebo dos usuários são sobre a segurança do Elasticsearch. Que tipo de autenticação é compatível com o Elasticsearch? Como faço para configurá-lo? Como posso garantir que os usuários não vejam dados que não devem ver? Meu objetivo neste blog é responder a essas perguntas, bem como fornecer algumas orientações para resolver alguns problemas comuns na configuração da segurança.

Primeiro, um pouco de história. Se você usa o Elasticsearch há algum tempo, sabe que houve um tempo em que a segurança era fornecida por um plugin chamado Shield, oferecido por meio do X-Pack. Atualmente, essa funcionalidade de segurança foi movida para o Elastic Stack (junto com o restante do X-Pack), com os recursos mais usados disponíveis gratuitamente com a distribuição padrão. A segurança inclui comunicação criptografada (TLS/SSL), autenticação (nativa, LDAP, SSO etc.), autorização (RBAC, ABAC etc.), filtragem de IP, logging de auditoria e muito mais. Neste blog, vamos nos concentrar na autenticação e na autorização.

Autenticação no Elasticsearch

Basicamente, se um usuário ou API quer acessar o Elasticsearch, ele(a) precisa passar por uma autenticação.

O Elasticsearch dá suporte a vários métodos de segurança nativamente, como:

Você pode até criar sua própria integração se nenhuma dessas opções se aplica a você. No entanto, geralmente recomendamos que você use uma das integrações existentes, pois elas são validadas e continuamos trabalhando no desenvolvimento delas para garantir o suporte adequado.

O componente mais básico de segurança no Elasticsearch é um reino, que é o que resolve e autentica os usuários. Cada um dos métodos de autenticação listados acima seria considerado um reino. E, para funcionar, o Elasticsearch trabalha com uma cadeia de reinos. Uma cadeia de reinos é uma lista priorizada de reinos configurados (de um a N reinos) em ordem crescente de preferência. Quando um usuário tentar acessar o Elasticsearch, a solicitação percorrerá a lista sequencialmente até que a autenticação seja bem-sucedida ou que se esgotem os reinos.

Essencialmente, o processo tentará o primeiro reino configurado na lista e, se falhar, irá para o próximo até ter sucesso com um dos itens de reino ou executar exaustivamente a lista inteira. A primeira etapa para acessar o Elasticsearch é chamada de autenticação.

Depois que um usuário for autenticado, o Elasticsearch tentará atribuir uma ou mais funções a ele. As funções podem ser atribuídas aos usuários de maneira estática ou dinâmica durante a autenticação, com base em algumas das propriedades do usuário. Dependendo do tipo de reino que autenticou o usuário, a propriedade do usuário usada para atribuir uma função poderá ser a associação ao grupo que o usuário tiver em um sistema externo, o sufixo de seu nome de usuário no Elasticsearch e outras. Além disso, o Elasticsearch também apresenta a funcionalidade run as, que permite aos usuários enviar solicitações em nome de outros usuários sem exigir nova autenticação.

Com a fase de autenticação concluída, a próxima etapa é a autorização. Confira todo o fluxo de trabalho neste gráfico:

Encadeamento de reinos no Elasticsearch

Autorização no Elasticsearch

Quando a autenticação for bem-sucedida, o usuário passará para o segundo ponto de verificação de segurança: autorização. A autorização é o processo para determinar se o usuário tem permissão para executar uma solicitação, e isso é feito por meio do mapeamento dos usuários para funções predefinidas e/ou definidas pelo usuário. Existem funções que vêm por padrão com o Elasticsearch, mas você também pode criar funções específicas para o seu caso de uso.

Uma função é composta por:

  • Uma lista de usuários que têm acesso
  • Privilégios de cluster
  • Privilégios globais
  • Privilégios de índices
  • Privilégios de aplicação

Nesta segunda fase, o Elasticsearch usará um dos seguintes:

  • A API role_mapping, que é o método preferido porque você pode gerenciar o mapeamento de cada função de maneira centralizada e orientada pela API. Essa é a única maneira de configurar mapeamentos de função no Elasticsearch Service no Elastic Cloud.
  • O arquivo de mapeamento de função (role_mapping.yml) que existe em cada nó dentro da pasta de configuração

A API role_mapping precisa ser invocada por um usuário com direitos apropriados para gerenciar funções. A função superuser que o usuário da Elastic tem é um exemplo disso; no entanto, você também pode criar uma função específica para isso.

Reinos e funções são completamente diferentes por definição. Reinos e cadeias de reinos são o que usamos para nos autenticarmos e, após a fase de autenticação, acabamos usando funções para mapear para os usuários. Enquanto um usuário será apenas autenticado usando um único reino da cadeia de reinos, na segunda fase, o usuário poderá ser mapeado de uma para várias funções. Isso também é conhecido como controle de acesso por função.

Etapas para solução de problemas de autenticação e autorização

Agora que vimos aspectos básicos da autenticação e da autorização, vamos dar uma olhada em algumas das etapas de solução de problemas que você poderá executar.

401 Unauthorized

Se não conseguir se autenticar usando qualquer um dos reinos, você receberá uma resposta com o código de status 401 Unauthorized. A maneira mais fácil de testar suas credenciais com a lista de reinos configurados é usar cURL com um sinalizador que permita inspeção (por exemplo,-v). Você poderá obter uma resposta como a seguinte: 

curl https://xxxxxx:9200 -u test:test -v 
> User-Agent: curl/7.54.0 
> Accept: */* 
> 
< HTTP/1.1 401 Unauthorized 
< Content-Type: application/json; charset=UTF-8 
< Date: Tue, 10 Sep 2019 15:59:33 GMT 
< Www-Authenticate: Bearer realm="security" 
< Www-Authenticate: ApiKey 
< Www-Authenticate: Basic realm="security" charset="UTF-8" 
< Content-Length: 455 
< Connection: keep-alive 
< 
* Connection #0 to host 06618318cff64c829af1cd5a2beb91a5.us-east-1.aws.found.io left intact 
{"error":{"root_cause":[{"type":"security_exception","reason":"unable to authenticate user [test] for REST request [/]","header":{"WWW-Authenticate":["Bearer realm=\"security\"","ApiKey","Basic realm=\"security\" charset=\"UTF-8\""]}}],"type":"security_exception","reason":"unable to authenticate user [test] for REST request [/]","header":{"WWW-Authenticate":["Bearer realm=\"security\"","ApiKey","Basic realm=\"security\" charset=\"UTF-8\""]}},"status":401}%

Essa mensagem de erro pode ajudar você a chegar à causa raiz do problema. Por exemplo, existem reinos específicos, como o SAML, que exigem que o Kibana ou uma aplicação Web personalizada faça a interação com o Elasticsearch e o provedor de identidade.

Habilitar o logging de erros

Depois de configurar os reinos, a cadeia de reinos, as funções e o mapeamento de funções, se você ainda tiver problemas, poderá configurar facilmente mais algum logging para obter mais informações sobre o processo de autenticação e autorização que abordamos anteriormente.

Usando a configuração de logging na API settings do cluster, é possível definir qualquer nível de logging para qualquer reino.

Vamos dar uma olhada em um exemplo com o reino LDAP. Se a autenticação ou autorização do usuário estiver falhando, você poderá configurar o seguinte nível de logging para obter mais informações: 

PUT /_cluster/settings 
{ 
  "transient": { 
     "logger.org.elasticsearch.xpack.security.authc.ldap":"DEBUG", 
     "logger.org.elasticsearch.xpack.security.authz":"DEBUG" 
   } 
}

Isso aumentará de padrão para DEBUG o nível de logging do pacote LDAP. Também é possível habilitar o logging TRACE para obter ainda mais informações, como todas as chamadas LDAP feitas ao servidor e a resposta delas. Você pode encontrar o nome do pacote para habilitar em cada REALM específico usando nosso repositório do GitHub. Por exemplo, este é o código para o reino LDAP. Usando a primeira linha de código, você pode ver o pacote a ser usado para o nível de logging: 

package org.elasticsearch.xpack.security.authc.ldap;

Quando isso estiver habilitado, você obterá muitas linhas de log, como o exemplo a seguir: 

[2019-09-12T08:41:20,628][DEBUG][o.e.x.s.a.l.LdapRealm   ] [xxxxxxx] user not found in cache, proceeding with normal authentication
[2019-09-12T08:41:21,180][TRACE][o.e.x.s.a.l.s.LdapUtils ] LDAP Search SearchRequest(baseDN='dc=xxx,dc=xxxx,dc=domain,dc=com', scope=SUB, deref=NEVER, sizeLimit=0, timeLimit=5, filter='(cn=vchatzig)', attrs={1.1}) => SearchResult(resultCode=0 (success), messageID=2, entriesReturned=1, referencesReturned=0) ([SearchResultEntry(dn='cn=xxxxxxx,ou=xxxxx,dc=intc,dc=xxxx,dc=domain,dc=com', messageID=2, attributes={}, controls={})])

Aqui podemos ver o reino LDAP tentando obter o usuário do cache (que pode estar desatualizado) e, em seguida, fazendo a solicitação LDAP Search ao servidor usando as configurações específicas que fornecemos. Esse é apenas um exemplo das muitas linhas de log que você receberá.

Observação: habilitar o logging é ótimo para diagnósticos, mas não para desempenho. Recomendamos voltar o nível de logging ao valor padrão assim que você souber que tudo está funcionando. Para isso, use o seguinte: 

PUT /_cluster/settings 
{ 
  "transient": { 
     "logger.org.elasticsearch.xpack.security.authc.ldap": null, 
     "logger.org.elasticsearch.xpack.security.authz": null 
   } 
}

Observe que alguns desses pacotes podem mudar de uma versão para outra; portanto, recomendamos verificar novamente os links de documentação da versão específica do Elasticsearch que você estiver usando, juntamente com os links das aulas do GitHub para essa versão específica.

Problemas comuns do SAML

O reino SAML requer um provedor de identidade (como Okta ou Auth0) e uma aplicação Web (Kibana é o padrão) que, junto com o Elasticsearch, atue como provedor de serviços. Alguns dos problemas que costumamos ver:

  • Configuração da URL do serviço consumidor de afirmação incorreta na configuração do provedor de identidade (IdP). O endpoint que você geralmente precisa configurar no provedor de identidade é https://kibana.xxxx.com/api/security/v1/saml
  • Os metadados do provedor de identidade não são acessíveis pela Internet. O valor da configuração idp.metadata.path no Elasticsearch no local ou no Elastic Cloud deve ser acessível pela rede na qual o Elasticsearch/Kibana estão sendo executados. Se não for esse o caso, você precisará baixar os metadados de um host que possa acessá-los ou solicitar ao administrador do IdP os metadados, adicioná-los como um arquivo local no Elasticsearch e referenciá-los. O erro mostrado será semelhante a este: 
    Caused by: net.shibboleth.utilities.java.support.resolver.ResolverException: net.shibboleth.utilities.java.support.resolver.ResolverException: Non-ok status code 404 returned from remote metadata source https://xxxx.xxxx/xxx/yyyyyyyy/sso/saml/metadata
  • Você pode se autenticar, mas o usuário não consegue abrir o Kibana. Para isso, geralmente recomendamos verificar novamente os mapeamentos de função para os usuários, a fim de verificar se pelo menos uma de suas funções tem acesso ao Kibana.

A configuração do provedor de identidade é tão importante quanto a configuração do Elasticsearch/Kibana, e devemos sempre verificar se há erros de digitação e incompatibilidade entre as configurações esperadas e as definidas. Embora cada IdP específico tenha suas próprias configurações, recomendamos ler com atenção a documentação para saber cada configuração específica necessária.

Para obter mais informações sobre problemas comuns e etapas de solução de problemas relacionados ao SAML, acesse a nossa documentação de solução de problemas, que é mantida a cada versão lançada.

Resumo

A autenticação no Elasticsearch é muito fácil de configurar uma vez compreendidos todos os conceitos por trás dela. Além disso, às vezes pode ser difícil entender o que está funcionando, o que não está e por que, mas neste post, abordamos muitas opções para obter uma visão mais detalhada. Você pode usar nossa documentação para começar a trabalhar com a segurança no Elasticsearch ou usar o nosso guia de solução de problemas de segurança na nossa documentação. Não deixe de ver nosso gerente sênior de produto do Elastic Security explicar como começar de forma detalhada.

Também recomendamos que você confira novamente a nossa página de assinaturas para saber mais sobre os recursos incluídos em cada nível. Por fim, se tiver alguma dúvida específica, entre em contato com o seu representante de suporte ou use os nossos fóruns de discussão.

Trabalhe com segurança!