Dicas para proteger clusters do Elasticsearch gratuitamente com criptografia, usuários e muito mais

Com o lançamento do Elastic Stack 6.8 e 7.1, disponibilizamos diversos recursos de segurança do Elasticsearch para todos de forma mais ampla, tornando-os gratuitos na distribuição padrão. É com grande satisfação que compartilhamos isso, mas um dos novos desafios agora é atualizar toda a nossa documentação e as orientações sobre como proteger o Elastic Stack. Aqueles dias em que contávamos apenas com um servidor proxy na frente do Stack para protegê-lo fazem parte do passado!

Examinei a maioria de nossos posts populares no blog com foco em segurança e vou atualizar as orientações, desfazer alguns mitos, apontar algumas novas ideias e garantir que você possa proteger o seu Stack melhor do que nunca.

Não vou criar links para nenhum dos artigos antigos; alguns dão conselhos que agora consideramos perigosos devido à forma como o Elastic Stack mudou ao longo dos anos. (Desconfie de conselhos de segurança de blogs antigos: as coisas mudam muito rapidamente.) Encaminharemos todos esses links para esta página, mas se você encontrar outro site que ofereça versões desses artigos armazenadas em cache, encaminhe a eles um link para cá.

Criptografia TLS

A criptografia TLS agora faz parte da nossa segurança gratuita do Elasticsearch e do Kibana na distribuição padrão. A finalidade do TLS é criptografar as comunicações de rede. Criptografamos a comunicação entre os nós do seu cluster, entre os clientes e o cluster, bem como as conexões do Kibana aos usuários.

Também usamos certificados TLS como forma de garantir que um nó possa ingressar em um cluster. Sem o TLS, qualquer um pode adicionar um nó a um cluster. Embora isso possa ser usado por um invasor para vários propósitos nefastos, o caso mais comum é um nó ingressar acidentalmente no cluster errado. O TLS pode ajudar a evitar esses problemas porque, sem o certificado adequado, um nó não pode ingressar no cluster.

Antes das versões 6.8 e 7.1, se você precisasse de TLS para o Elastic Stack ao usar uma licença Basic, teria de contar com algum tipo de proxy, o que adiciona uma quantidade considerável de configuração. O TLS já é bastante difícil de configurar, mesmo sem a necessidade de configurar um proxy entre os nós e os clientes. Ao adicionar um proxy, você teria um problema complexo e o tornaria substancialmente mais difícil. Agora podemos aproveitar o suporte para o TLS diretamente no Elastic Stack.

Temos um volume considerável de documentação sobre como configurar o TLS. Se você já trabalhou com TLS, sabe que nunca é fácil configurar certificados, mas nós dispomos de ferramentas integradas para ajudar a gerar certificados para todo o cluster e autoridades de certificação, o que facilita as coisas.  Acompanhe este espaço, pois publicaremos aqui alguns posts futuramente, detalhando a melhor forma de configurar o TLS em todos os componentes do Elastic Stack. Quais são as duas maneiras mais fáceis de começar hoje? Confira o post Getting started with Elasticsearch security ou dê uma olhada no nosso Operador do Kubernetes oficial.

Autenticação

Com as versões 6.8 e 7.1, a autenticação nativa está disponível para todos. A finalidade da autenticação é permitir que os clientes se identifiquem para o Elastic Stack. Isso costuma ser conhecido como o nome de usuário e a senha que você usa para entrar em um sistema. Geralmente, é uma má ideia deixar um cluster cheio de dados aberto para o mundo inteiro. É especialmente perigoso se o cluster está conectado diretamente à Internet, onde qualquer pessoa pode se conectar sem usar uma senha.

No passado, o conselho era usar um servidor Nginx com autenticação básica habilitada entre o cliente e o cluster. Fazer essa configuração corretamente podia ser extremamente difícil. Como todo nó pode atender a solicitações externas, se você se esquecesse de colocá-lo atrás de um firewall, qualquer pessoa poderia se conectar ao cluster sem autenticação.

Agora permitimos autenticação usando os reinos nativo e de arquivos gratuitamente. O reino de arquivos armazena informações do usuário em um arquivo em cada nó. Você precisa manter os arquivos sincronizados em todos os nós. O reino nativo é uma experiência mais simplificada e faz o que seria de esperar: os dados do usuário são armazenados em um índice no cluster ao qual todos os nós têm acesso. Você adiciona nomes de usuário e senhas por meio de uma REST API e, então, essas contas podem fazer o login. Consulte o blog Getting started with Elasticsearch security para saber mais detalhes.

Se você tiver necessidades de autenticação mais complexas, como LDAP, Active Directory, SAML ou qualquer outra coisa, oferecemos um serviço na nuvem (SaaS) com alguns destes e outros recursos comerciais, ou você pode entrar em contato conosco para discutir possíveis soluções no local. Para ver as diferentes opções de autenticação que oferecemos, confira os documentos de autenticação.

Autorização

Autorização e autenticação tendem a andar de mãos dadas, e o Elastic Stack não é diferente. Temos um sistema muito flexível que pode definir regras de autorização para o cluster e os índices, chegando até os documentos e campos. Temos também algo chamado mecanismo de autorização, no qual você pode criar seu próprio plugin de autorização.

Historicamente, os conselhos têm sido um tanto toscos nessa área. No passado, foram sugeridas algumas maneiras para escrever regras de filtragem bem complexas com um proxy como o Nginx e, em seguida, tentar aproveitar os aliases filtrados para alcançar algo que quase parece uma autorização. Sugerimos enfaticamente que todos evitem usar esses métodos para autorização. Eles não são recursos de segurança, provavelmente não farão o que você quer e são extremamente frágeis de manter. Essas soluções não vão mais atender às suas necessidades porque, com o tempo, o número de APIs do Elasticsearch aumentou substancialmente. Existem muitas maneiras de acessar e consultar índices e os dados que eles contêm. Não há como garantir que você tenha bloqueado ou restringido cada solicitação. O segundo motivo está relacionado ao primeiro, pois há muitos pontos de extremidade a serem protegidos e estamos sempre adicionando novos. Vai dar um trabalho enorme manter esses filtros atualizados.

Felizmente, você não precisa mais se preocupar com isso. Nas versões 6.8 e 7.1, você tem acesso a uma quantidade substancial de recursos de autorização. São tantos que nem dá para descrever aqui neste post, mas os documentos de segurança do Elastic Stack explicam todos os privilégios existentes com muita competência. Reservaremos algum tempo em posts futuros do blog para explicar algumas das soluções que podem ser criadas usando o nosso modelo de permissão.

Como ocorre com a autenticação, temos recursos de autorização mais avançados que podem ser aplicados a documentos e campos individuais. Você pode criar seus próprios plugins de autenticação e autorização e até registrar os eventos de segurança no cluster. Use-os como parte de nosso serviço na nuvem ou entre em contato conosco para discutir suas opções no local.

Coloque o Stack atrás de uma VPN e/ou firewall

Houve uma quantidade razoável de conselhos anteriores sugerindo que você coloque o Elastic Stack atrás de um firewall ou VPN. O motivo por trás de muitas dessas orientações era que, sem TLS e autenticação, poderia ser difícil proteger um cluster usando apenas um proxy; portanto, simplesmente bloquear o acesso para todos era mais fácil do que tentar configurar todos os elementos adequadamente.

Se isso é algo que você ainda quer fazer, mesmo com o TLS e a autenticação habilitados, ainda pode ser uma ótima ideia. A segurança funciona melhor quando há várias camadas. A parte interessante disso agora é que a VPN e o firewall não são a única camada.

Scripts restritos

Muito tempo atrás, tivemos um post no blog sobre a restrição de scripts no Elasticsearch. Com a criação da linguagem de script Painless, é muito mais difícil derrubar um cluster, mesmo com scripts com más intenções. Porém, isso não é impossível e temos algumas práticas recomendadas nos documentos de segurança dos scripts que discutem nossa posição atual sobre esse assunto. Entretanto, reiteramos que você deve sempre avaliar o seu ambiente e tomar as medidas que façam mais sentido para você. A segurança funciona melhor em camadas, portanto, não há uma opção que seja sempre a melhor.

Isolamento

Houve várias vezes em que mencionou-se o isolamento do cluster e dos nós por motivos de segurança. Isso pode englobar tudo, desde containers e firewalls até filtragem de IP.

Esse ainda é um ótimo conselho, e isolar tudo o que você puder é uma ótima dica de segurança. Nos últimos anos, trabalhamos muito para tornar isso mais fácil do que nunca. Você pode usar nossas imagens de container oficiais, publicadas no Docker Hub. Você pode usar o Elasticsearch Service, e nós cuidaremos de todo o trabalho pesado. Além disso, acabamos de anunciar um Operador do Kubernetes oficial que você pode experimentar.

Faça backup dos seus índices (especialmente o .kibana, pois ele pode ser facilmente alterado)

Fazer backup dos seus dados ainda é tão importante quanto sempre foi. O fato de contar com segurança não muda isso de forma alguma, mas conseguimos introduzir algumas coisas novas.

A maior vantagem é que podemos usar o Kibana Spaces para restringir quem pode modificar determinados dashboards. Isso também foi lançado gratuitamente como parte das versões 6.8 e 7.1. No passado, se você conseguisse acessar o Kibana, provavelmente poderia mudar o que quisesse. Não seria incomum alguém bagunçar os dashboards ou, em alguns casos, até excluir todos eles acidentalmente. O conselho era fazer backup regularmente do índice .kibana para que você pudesse se recuperar rapidamente dos erros. Restaurar um índice é muito mais rápido que reconstruir todos os seus dashboards. Fazer backup do .kibana ainda é importante, mas você não deve precisar restaurá-lo regularmente, graças aos espaços e à autorização.

Outra grande vantagem da segurança é a capacidade de controlar quem pode gerar snapshots, criar um índice e modificar os dados. Sem segurança, um usuário que deveria ter apenas permissão de leitura poderia fazer alterações catastróficas nos dados. Com a segurança habilitada, podemos tomar algumas medidas para evitar alterações acidentais em dados importantes.

E agora?

O objetivo deste post foi revisitar alguns dos conselhos anteriores sobre como proteger suas implantações do Elastic Stack. No mundo da segurança, a única constante é a mudança. Até os conselhos deste blog serão considerados obsoletos e errados algum dia. A segurança no Elastic Stack pode ser assustadora devido ao número de opções possíveis. (Esse é um recurso, não um bug.) Não deixe de fazer perguntas nos fóruns e ler nossos blogs e documentação.

Se você preferir um jeito fácil de proteger o seu Elastic Stack, temos algumas opções. Nosso Elasticsearch Service vem com TLS configurado para todos os clusters, autenticação e autorização habilitadas, além dos nossos recursos de segurança Enterprise habilitados por padrão. Se você não gosta muito da ideia de uma solução na nuvem, pode ter muitos dos mesmos recursos do Elasticsearch Service em seu próprio datacenter com o Elastic Cloud Enterprise (ECE). Nós também temos um Operador do Kubernetes que pode se encarregar de parte do trabalho pesado, como habilitar o TLS e configurar a autenticação para você por padrão. E, é claro, se você é um cliente Enterprise executando seu próprio Stack, pode contar com a nossa fantástica equipe de suporte para ajudar a resolver os problemas que possam surgir.

Fique atento a tudo o que estamos preparando para o futuro. Temos muitos tutoriais planejados e até mesmo novos recursos de segurança que você verá no futuro. Estamos vivendo um momento muito empolgante para o uso do Elastic Stack!