Entendendo o TLS no Couchbase Server
Em Parte 1 e Parte 2 Neste guia, explicamos a história do TLS, os componentes envolvidos e como ele funciona. Nesta terceira parte final do guia, combinamos tudo isso e aprendemos como o TLS funciona no Couchbase Server.
Certificados do cluster do Couchbase
No Couchbase Server, um certificado de cluster vincula tudo a uma ou mais Autoridades de Certificação (CAs) confiáveis; ele não lida diretamente com a criptografia do banco de dados. Em vez disso, ele estabelece uma cadeia de confiança para os certificados por nó dentro do cluster.
Todas as partes confiáveis na implantação do Couchbase Server devem ter o Certificado do Cluster instalado e confiável. Assim como no exemplo anterior, com o navegador da Web tendo CAs raiz confiáveis, em uma implantação do Couchbase, cada nó do Couchbase Server e aplicativo de conexão usando um dos SDKs deve confiar no certificado do cluster. Ele também é importado para clusters adicionais do Couchbase Server que usam o recurso de replicação entre centros de dados (XDCR) para replicar dados entre os clusters de forma segura.
No Couchbase Capella, nossa oferta de banco de dados como serviço (DBaaS), todos os clusters realmente usam a mesma autoridade de certificação e, portanto, todos usam o mesmo certificado de cluster. E, a partir do início de 2022, todos os SDKs oficiais do Couchbase lançados desde então incluíram, por padrão, a confiança automática no Certificado de Cluster do Capella.
Certificados de nó para criptografia de rede
Os Certificados de Nó e as chaves privadas por nó são o principal componente responsável pela criptografia de rede no Couchbase Server. Os certificados de nó são criados por uma autoridade de certificação (CA) confiável e são assinados pela chave privada da CA (também conhecida como a chave privada associada ao certificado/chave pública do cluster).
Este é o processo de criação de um certificado de nó do Couchbase.
-
- Uma solicitação de assinatura de certificado (CSR) é solicitada à autoridade de certificação com a chave pública de um nó incorporado.
- O certificado do nó é criado, incluindo a chave pública do nó incorporada, e é assinado usando a chave privada do cluster no próprio sistema CA.
- O certificado do nó é então fornecido de volta ao solicitante.
Esses certificados facilitam a comunicação segura entre os nós do servidor Couchbase e permitem a conectividade criptografada com nós individuais do servidor Couchbase a partir de SDKs. Os principais pontos relacionados aos certificados de nó incluem:
Criptografia nó a nó: Os certificados de nó protegem os canais de comunicação entre os nós do servidor Couchbase, protegendo os dados à medida que eles trafegam dentro do cluster.
Conectividade do SDK: Quando os SDKs se conectam a nós individuais do servidor Couchbase, os certificados de nó garantem que a comunicação seja criptografada, mantendo a confidencialidade dos dados.
Acesso à GUI do administrador por HTTPS: Ao utilizar o certificado de nó, os administradores podem acessar com segurança a interface gráfica do usuário (GUI) do Couchbase Server por meio de HTTPS.
Se analisarmos um exemplo de como um SDK faz uma conexão criptografada com um nó do Couchbase Server, você verá os vários componentes em ação. Deixei alguns detalhes de fora intencionalmente, para manter a simplicidade.
O SDK executará essas etapas com cada nó do Couchbase Server no cluster com o qual estabelece uma conexão TLS.
Exemplo de configuração de TLS no Couchbase Server
Nesta seção, configuraremos a criptografia de rede TLS em um cluster de 3 nós do Couchbase Server, executando a versão 7.2.0 em hosts Linux. Há também um quarto host Linux usado como autoridade de certificação.
Chave privada do cluster + certificado
Faça login no host da autoridade de certificação, pois é aqui que criaremos o certificado do cluster.
Trata-se apenas de um host Linux que tem uma versão atual do OpenSSL instalada.
Primeiro, criaremos um arquivo de modelo do Couchbase que será usado posteriormente para os certificados por nó.
| Comando (sem saída) | ||
|
A próxima etapa será criar a chave privada criptografada do cluster, denominada cluster_private.key.
Execute o seguinte comando; será solicitada uma frase secreta para criptografar essa chave.
A chave privada estará no formato PKCS8 (PKCS #8) e será criptografada com o muito seguro bit 265 Padrão de criptografia avançado (AES).
| Comando | ||
|
||
| Saída | ||
|
Você pode validar que se trata de uma chave privada criptografada, observando o início do arquivo.
| Comando | ||
|
||
| Saída | ||
|
Agora, criaremos o certificado do cluster no formato PEM x.509. No nosso caso, o certificado deve ser autoassinado, o que significa que não será atestado por nenhuma outra autoridade. Isso significa que ele pode ser criado diretamente, com base na chave privada existente ca.keysem a assistência de terceiros.
Quando criarmos o certificado de cluster, válido por 3650 dias (10 anos), ele terá uma chave pública de cluster incorporada ao certificado, que é o par correspondente da chave cluster_private.key feito anteriormente. Você precisará fornecer a frase secreta que inseriu anteriormente para descriptografar a chave privada desse comando.
| Comando | ||
|
||
| Saída | ||
|
Agora podemos imprimir o conteúdo do novo arquivo de certificado (e também ver a chave pública).
| Comando | ||
|
||
| Saída | ||
|
Agora temos o certificado do cluster (cluster_cert.pem), esse arquivo precisa ser copiado para cada nó do Couchbase Server no cluster. Ele também precisa ser adicionado a todos os aplicativos em que os SDKs operam, bem como a todos os hosts em que os administradores acessam a interface do usuário, como o laptop de um administrador. Não é um arquivo confidencial e contém apenas informações públicas.
Chave privada do nó + CSR
As etapas desta seção precisarão ser repetidas para cada nó do Couchbase Server:
-
- Faça login no nó do servidor Couchbase.
- Execute os seguintes comandos em um diretório temporário, inacessível a outros usuários do sistema.
Primeiro, vamos criar a chave privada do nó node1 em um formato PKCS1 (PKCS #1)
| Comando | ||
|
||
| Saída | ||
|
Em seguida, vamos criar a Solicitação de Assinatura de Certificado (CSR) para o Node1, usando o comando nó1 chave privada. Lembre-se de que uma chave pública será incorporada à CSR.
| Comando (sem saída) | ||
Essa CSR e sua chave pública incorporada agora podem ser visualizadas e verificadas. |
| Comando | ||
|
||
| Saída | ||
|
Agora, copie o arquivo CSR, cbnode1.csrpara o sistema CA. Ele contém apenas informações públicas e não é sensível.
Criar certificados de nó
Faça login no sistema da CA. Agora você deve ter arquivos CSR para cada nó do Couchbase Server no cluster localizado no sistema da CA, cbnode1.csr, cbnode2.csr, etc.
Para cada nó do Couchbase Server, você precisará criar um arquivo de modelo. O arquivo de modelo criado anteriormente, cbserver.extO comando "Couchbase Server", será personalizado para cada nó. Execute esse comando para cada nó do Couchbase Server, substituindo o nome do host DNS do nó do Couchbase Server e o nome do arquivo, conforme necessário. Isso definirá o Nome Alternativo do Assunto (SAN) para corresponder ao nome do nó do Couchbase Server.
Se estiver usando nomes de host para o Couchbase Server, execute este comando:
| Comando (sem saída) | ||
|
Como alternativa, se estiver usando endereços IP sem nomes de host para o Couchbase Server, execute isso:
| Comando (sem saída) | ||
Agora você deve ter arquivos de modelo para cada nó do Couchbase Server no cluster, cbnode1.ext, cbnode2.ext, cbnode3.ext, etc. |
Agora vamos gerar os certificados, válidos por 3 meses, para cada nó do Couchbase Server. Eles estarão em um formato PEM x.509. Execute esse comando para cada nó, alterando os nomes dos arquivos. Cada vez que isso for executado, você será solicitado a fornecer a senha da CA usada para criptografar o cluster_private.key anteriormente.
| Comando | ||
|
||
| Saída | ||
|
Copie cada arquivo de certificado da autoridade de certificação para cada nó do Couchbase Server a que pertencem. Por exemplo, copie node1_cert.pem no Couchbase Server Node 1 e node2_cert.pem no Couchbase Server Node 2.
Carregar os certificados no servidor Couchbase
Essas etapas precisarão ser executadas em cada nó do Couchbase Server
Faça login no nó do servidor Couchbase e você deverá ter uma pasta com três arquivos.
-
- Certificado de cluster, cluster_cert.pem
- Certificado (público) do nó, node1_cert.pem
- Chave privada do nó, cbnode1_private.key
Você não precisa mais do arquivo CSR criado anteriormente.
Agora você precisa mover os arquivos para o local correto, com a convenção de nomenclatura correta para o Couchbase Server. Observe que o mesmo nome de arquivo de destino é usado em cada nó do Couchbase Server, mas cada nó tem arquivos exclusivos para os arquivos chain.pem e pkey.key.
| Comando | ||
|
Agora todos os arquivos corretos estão prontos para serem importados para a configuração do Couchbase Server.
Comece carregando o certificado do cluster:
| Comando | ||
|
||
| Saída | ||
|
Em seguida, carregue o certificado e a chave privada do nó e observe que nenhum aviso é impresso:
| Comando | ||
|
||
| Saída | ||
|
Agora você pode usar conexões TLS com o cluster do Couchbase Server.
Confiança no certificado do cluster
Laptop do administrador
Faça login no laptop de um administrador. Neste caso, estou usando um Mac, mas etapas semelhantes podem ser executadas em máquinas Windows e Linux.
| Comando no MacOS (sem saída) | ||
|
SDK de aplicativos
Usaremos um aplicativo Java para nos conectarmos ao Couchbase Server e, neste exemplo, apontaremos o aplicativo para o certificado do cluster. Outra opção seria usar o armazenamento de confiança cacerts da JVM, pois o SDK confiará automaticamente em todas as CAs definidas lá. Cada linguagem de programação terá sua própria maneira preferida de confiar em um certificado de CA.
|
1 2 3 |
Cordas connectionString = "couchbases://example.com" + "?security.trustCertificate=/path/to/cluster_cert.pem"; Aglomerado agrupamento = Aglomerado.conectar(connectionString, nome de usuário, senha); |
Carregamento do endereço padrão criptografado da interface do usuário para um dos nomes de host do seu nó a partir de um laptop de administrador. Isso deve ser carregado sem nenhum aviso: https://node1.cb.acme.com:18091/
Da mesma forma, você pode fazer conexões criptografadas por TLS do seu aplicativo para o banco de dados.
Lembre-se de criar e implementar novas chaves/certos por nó antes da expiração de 90 dias, seguindo essas etapas novamente.
Tópicos avançados de TLS
Embora as etapas fornecidas até agora sirvam para a maioria dos aplicativos, há alguns recursos adicionais oferecidos no Couchbase Server para requisitos mais complexos. Eles são abordados no blog Chaves privadas criptografadas e multi-CA, aprimoramentos de segurança empresarial no Couchbase Server 7.1
Várias autoridades de certificação no Couchbase Server
Em vez de incluir um único certificado como o certificado de cluster (cluster_cert.pem / ca.pem), vários certificados podem ser concatenados em um arquivo. Essa é uma ótima opção para ter Autoridades de Certificação redundantes ou para realizar a migração de uma Autoridade de Certificação para outra sem nenhum tempo de inatividade.
Chaves privadas de nó criptografadas
Assim como fizemos com a chave privada do cluster, a chave privada (pkey.key) que reside em cada nó do Couchbase Server também pode ser opcionalmente criptografado com uma frase secreta para que só possa ser lido por pessoas e sistemas que tenham a autoridade correta para fazê-lo.
Conclusão
Os certificados TLS e sua configuração adequada são fundamentais para estabelecer comunicações seguras no Couchbase Server. Compreender a função dos certificados de cluster, a importância dos certificados de nó e o envolvimento das Autoridades de Certificação (CAs) permite que os administradores implementem medidas de segurança robustas. Além disso, familiarizar-se com os nomes alternativos de assunto (SAN) aumenta a flexibilidade na implementação de certificados em vários domínios ou subdomínios. Ao seguir as diretrizes apresentadas neste guia, os administradores podem fortalecer a segurança de suas implantações do Couchbase e proteger os dados confidenciais contra acesso não autorizado.
Obrigado por acompanhar esta série, esperamos que tenha gostado da visita guiada.
