Cassandra por VPN: acesso separado para clientes e nós

Uma implantação de Cassandra não tem uma única rede de base de dados universal. As aplicações falam com o serviço de cliente, os membros do cluster falam entre si, e os operadores usam interfaces administrativas, e esses três públicos não devem herdar a acessibilidade uns dos outros. Um caminho privado, como uma VPN, é um bom ponto de partida, mas não é a identidade de utilizador da base de dados e não é a sua política de encriptação. Trate a decisão de conectividade e a decisão de autorização como duas revisões separadas.

Cada um dos três públicos recebe uma resposta própria, e as secções abaixo tratam-nos por ordem de exposição.

Três públicos, três decisões

Identifique o que cada grupo realmente precisa antes de tocar numa regra. Os clientes precisam do listener de cliente e de informação suficiente para alcançar cada nó que lhes possa ser atribuído, os nós pares precisam uns dos outros na porta internode, e os operadores precisam da interface de gestão para o que o runbook realmente pede. Três listas, três públicos, três níveis de confiança.

O erro comum é construir um único segmento privado plano e assumir que a fronteira da VPN faz o resto. Dentro dele, uma aplicação que alcança a porta de cliente geralmente alcança também a porta internode, e as ferramentas administrativas de um operador costumam estar no mesmo jump host que a aplicação. Achatar tudo junto significa que uma identidade de aplicação comprometida já tem mais alcance do que as suas próprias consultas. Desenhe os três públicos como três linhas no documento de projeto, cada uma com a regra que a permite, e as lacunas tornam-se visíveis antes de alguém as construir.

O que os clientes precisam, e nada mais

Permita as origens de aplicação pretendidas para os endpoints de cliente da versão implantada, e mantenha serviços de cluster e de gestão não relacionados fora desse alcance. Depois verifique como o driver descobre os nós. Um ponto de contacto inicial alcançável não prova que cada endereço de nó que o driver seleciona depois seja alcançável a partir desse contexto de cliente, porque o driver pede pares ao cluster e depois liga-se aos endereços que o cluster anuncia.

É por isso que uma incompatibilidade de endereços privados produz o padrão conhecido de uma primeira ligação bem-sucedida seguida de timeouts. Configure endereços anunciados e encaminhamento de cliente de forma deliberada; publicar todo o cluster na internet para corrigir uma incompatibilidade troca um erro de encaminhamento por uma exposição que não pode ser revertida.

Mantenha também a autenticação de base de dados e as permissões de função da aplicação. Um endereço VPN traduzido e partilhado pode representar muitos utilizadores ou serviços, pelo que nunca substitui identidades de base de dados distintas.

Encripte cliente-para-nó e internode em separado

A documentação de segurança da Apache trata a encriptação cliente-para-nó e internode como configurações separadas, e ativar uma não ativa a outra. Essa distinção continua a aplicar-se dentro de uma VPN, porque o túnel protege o seu próprio segmento e não se estende automaticamente do processo da aplicação ao processo da base de dados nem entre cada par de membros do cluster.

Uma configuração que ativa ambos explicitamente, em vez de herdar uma predefinição de modelo, parece mais ou menos assim:

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

Em configurações de servidor que permitem encriptação de cliente opcional, aceitar TLS pode coexistir com aceitar ligações não encriptadas, por isso leia a política efetiva e não a intenção. Planeie nomes de certificados, distribuição de confiança e renovação para os endpoints que cada cliente contacta efetivamente; substituir um nome de host por um endereço IP altera a verificação de identidade do cliente, não apenas a sua rota.

Mantenha a administração num caminho próprio

O tráfego internode precisa do conjunto de pares permitido e da sua própria política de proteção. O acesso administrativo, incluindo JMX onde é usado, precisa de um público separado e da sua própria autenticação. Uma aplicação autorizada a emitir consultas comuns não precisa por isso de todas as capacidades de gestão, e o inverso é pior: um caminho administrativo exposto ao segmento da aplicação é a rota mais curta de um erro a uma reconstrução. Escreva esses dois públicos separadamente e nomeie os seus responsáveis, porque normalmente são equipas diferentes cujas regras foram fundidas por acidente.

Mantenha as regras efetivas de nuvem, as regras de host e a configuração do listener alinhadas. Um listener privado ainda pode ficar exposto através de uma tradução ou proxy não intencional, e uma regra pública ampla pode ficar tranquilamente ao lado de uma regra VPN estreita até alguém auditar ambas ao mesmo tempo.

Onde os operadores realmente precisam de um caminho de gestão, dê-lhe um responsável nomeado e um tempo de vida de credenciais mais curto do que o da aplicação. Isso mantém a delegação visível quando a próxima pessoa herda o cluster.

O que o projeto promete

Valide as três promessas com funções reais em vez de apenas com testes de conectividade. Uma aplicação aprovada deve concluir o trabalho permitido e nada mais, uma origem excluída deve falhar na entrada de cliente, e uma identidade de aplicação deve ser recusada nos caminhos administrativos reservados. Acrescente a reconexão de cliente e a seleção de nós ao mesmo teste de implementação, porque é aí que os erros de descoberta aparecem.

Termine com três frases no documento de projeto: que clientes podem consultar, que nós podem comunicar e que operadores podem administrar. Estar atrás de uma VPN é informação útil de topologia, mas não é resposta a nenhuma dessas três perguntas.