A autenticação e a autorização do serviço de consulta N1QL no Couchbase funcionam de várias maneiras
- Passagem de credenciais por meio de uma solicitação rest - curl http://localhost:8093/query/service?pretty=true -d "statement=select * from system:keyspaces" -u Admin:pwd
- Passagem de credenciais usando o parâmetro nomeado creds e/ou o parâmetro de consulta - curl http://localhost:8093/query/service?pretty=true -d "statement=select * from system:keyspaces&creds=[{user: "Administrator", "password": "pass"}]"
- Usando a autenticação básica na solicitação
- Solicitação do cbq (semelhante a 1,2) usando as opções -u -p -creds e o comando \SET.
- Certificados X.509 para TLS
- Criptografia de nó para nó
Com a adição do RBAC, o parâmetro de consulta creds se tornou redundante, mas ainda é suportado para compatibilidade com versões anteriores.
O objetivo de adicionar suporte a certificados X509 é aprimorar a criptografia cliente-servidor usando um certificado confiável pela autoridade de certificação.
Os certificados X.509 permitem a autenticação e a criptografia do servidor para comunicações cliente-servidor. O Couchbase oferece suporte à autenticação de servidor e cliente usando certificados X509 e você precisa ser um administrador completo ou administrador de segurança para gerenciar certificados. Este artigo fala sobre o suporte a certificados X.509 no lado do servidor para autorização no Couchbase. Os clientes também podem verificar a identidade do Couchbase Server, mas isso será discutido em outro artigo.
Os cenários mais comuns para os quais os certificados X509 são usados são quando os clientes precisam passar pela Internet, ao transferir dados confidenciais entre o aplicativo e o Couchbase Server, ou entre data centers (XDCR) ou quando exigido por normas de conformidade.
O que é um certificado X.509?
É um certificado de chave pública usado para distribuir uma chave pública, assinada por uma autoridade de certificação confiável que verifica a identidade do servidor. Com ele, o cliente tem a garantia de que a solicitação não está sendo enviada a um servidor desconhecido. Esses certificados são assinados por um terceiro, também conhecido como autoridade de certificação. As ACs são entidades que emitem certificados digitais. Na verdade, uma AC é composta por uma série de ACs denominada hierarquia de ACs. Essa hierarquia de CAs constrói uma cadeia de confiança na qual todos os certificados de nós ou de entidades finais se baseiam. A cadeia não contém a chave pública da CA raiz.
Em uma infraestrutura de chave pública (PKI) hierárquica, normalmente há três tipos de hierarquia. Uma camada, duas camadas e N camadas. A CA no topo dessa hierarquia é conhecida como CA-raiz. Todas as CAs subsequentes são as CAs intermediárias, e a enésima (última) CA é conhecida como CA de nó.
Um ponto importante a ser observado é que, para confiar em um certificado usado para estabelecer uma conexão segura, ele deve ter sido emitido por uma CA incluída no repositório confiável do dispositivo que está se conectando.
Autoridade de CA de uma ou única camada
Essa é a forma mais simples de hierarquia de ACs, mas geralmente não é usada na produção como uma hierarquia de ACs. O comprometimento dessa CA raiz resulta em um comprometimento de toda a PKI. Aqui, a CA raiz também é a CA emissora e todos os certificados imediatamente abaixo do certificado raiz herdam sua confiabilidade.
Autoridade de CA de dois níveis
Consiste em uma CA raiz que emitiu um certificado para uma subordinada conhecida como CA intermediária. A diferença aqui é que os certificados emitidos são confiáveis, pois vêm de uma autoridade confiável por meio da AC intermediária.
Sinais de CA raiz-> Sinais de CA intermediários -> CA emissora / CA de cluster
Autoridade de CA de N camadas
Na maioria das implementações de produção, uma hierarquia tem várias CAs. A AC raiz emite certificados para as ACs intermediárias, que, por sua vez, geram certificados intermediários: são usados para assinar certificados de clientes, como um certificado de cluster:
- CA raiz confiável > CA intermediária > Certificado de cluster
- CA raiz confiável > CA intermediária 1 > CA intermediária 2.... > CA intermediária n > Certificado de cluster
A hierarquia de duas camadas é um subtipo da hierarquia de N camadas.
Em todos os casos acima, a cadeia de certificados precisa ser verificada até a CA raiz. A cadeia de confiança contém seu certificado, concatenado com todos os certificados intermediários.
Observe aqui - Todos os certificados intermediários devem ser instalados em seu servidor: caso contrário, alguns clientes presumirão que a conexão não é segura. Isso resulta em avisos de "não confiável".
Configuração do X.509 em um cluster do couchbase
Alguns pré-requisitos antes de configurar os certificados
- O certificado deve ser um certificado de chave RSA em um formato .pem válido
- O certificado não deve ser inválido - A hora atual deve estar entre válido a partir de e válido para conforme estabelecido no certificado.
- Use um comprimento de chave RSA de 2048 bits ou mais. (À medida que os recursos de computação aumentam, as chaves RSA mais longas proporcionam maior segurança).
- Em um cluster de nó único, você terá um diretório correspondente aos certificados dos nós. Em um cluster de vários nós, crie vários diretórios correspondentes a cada nó do cluster - node1, node2 etc.
- Se você tiver várias ACs intermediárias, certifique-se de empilhá-las na ordem correta na cadeia de certificados.
- A chave privada do nó e a cadeia precisam ser colocadas em ../var/lib/couchbase/inbox relativo ao diretório bin do sistema operacional de onde os exes de serviço/cluster são implantados.
Convenções de nomenclatura
ca.pem - Chave pública da CA raiz
int1.pem - Chave pública da AC intermediária (no 1. Se você tiver várias CAs intermediárias, nomeie-as adequadamente para adicioná-las à cadeia na ordem correta. Isso mostra qual CA intermediária está mais próxima do nó)
node1.pem - Chave pública da CA do nó 1 ( node2.pem - chave pública da CA do nó 2 e assim por diante )
node1.key - Chave privada da CA do nó 1
chain.pem - Cadeia de certificados que contém a chave pública dos nós e as chaves públicas intermediárias que assinaram a chave pública do nó.
Usamos a ferramenta openssl para criar nossos certificados. Consulte sua documentação para obter mais detalhes sobre os comandos em si.
Etapas para configurar certificados X.509
Etapa 1 - Criar a chave privada raiz
openssl genrsa -out ca.key 2048 2>/dev/null
Gerar uma chave privada RSA chamada ca.key (-out nome de arquivo) que são os 2048 bits.
Ao gerar a chave, o símbolo . ou + será exibido. Isso indica o progresso na geração da chave. O . representa cada número que passa no teste e + significa que um número passou em uma única rodada do teste de primalidade Miller-Rabin. Quando a nova linha é vista, significa que a chave foi gerada com sucesso e que o número (2 números primos) passou em todos os testes de primos. Consulte a documentação do openssl-genrsa para obter mais detalhes.
Etapa 2 - Gerar a chave pública raiz usada como a CA do cluster
openssl req -new -x509 -days 365 -sha256 -key ca.key -out ca.pem -subj '/C=US/O=Couchbase/CN=Couchbase Root CA' 2>/dev/null
Gerar uma nova solicitação de certificado raiz autoassinado (opção -x509) com uma assinatura sha256 (-sha256. Isso significa maior segurança) válida por 1 ano (-days 365 em dias). A chave pública ca.pem (-out) é derivada da chave privada usando a opção -key para especificar a chave privada.
Os certificados X.509 têm um campo DN (Subject Distinguished Name) e também podem ter vários nomes na extensão Subject Alternative Name. Ele é composto de DNs relativos.
CN = COmmon Name, O = Organization, C = Country Name
O emissor do certificado é especificado para ter o CN (Common Name) de Couchbase Root CA: como esse nome indica, o certificado será o certificado raiz para o Couchbase
Etapa 3 - Gerar chave privada intermediária (ou chaves, se estiver usando uma hierarquia de N níveis, conforme descrito acima)
openssl genrsa -out int1.key 2048 2>/dev/null
Etapa 4 - Gerar a solicitação de assinatura de certificado intermediário
openssl req -new -key int1.key -out int1.csr -subj '/C=US/O=Couchbase/CN=Couchbase Intermediate CA' 2>/dev/null
Uma CSR ou solicitação de assinatura de certificado é uma solicitação enviada por um solicitante a uma CA para solicitar um certificado. Você pode personalizar: adicionar ou limitar os recursos do certificado X.509 usando um arquivo de extensão. Essas informações serão usadas em todos os nós do cluster. Por exemplo
cat > v3.ext <<EOF
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
EOF
Para obter uma lista abrangente de todas as extensões padrão, consulte a seção 4.2 da RFC 5280 sobre o perfil X509 PKI e CRL. - https://tools.ietf.org/html/rfc5280
Etapa 5 - Criar o certificado intermediário
openssl x509 -req -in int1.csr -CA ca.pem -CAkey ca.key -CAcreateserial -CAserial rootCA.srl -extfile v3.ext -out int1.pem -days 365 2>/dev/null
Leia o arquivo csr e passe as chaves da CA raiz para estabelecer a autoridade do certificado raiz. A chave criptografada da CA raiz é usada para assinar o CSR intermediário. Antes de assinarmos qualquer coisa, um arquivo de número de série precisa ser configurado para a CA raiz. Isso serve para que cada certificado possa ter um número de série exclusivo. Isso é feito usando as opções -CAcreateserial -CAserial . O rootCA.srl é o arquivo de número de série. É um arquivo de texto simples com números ASCII. O certificado é personalizado usando as extensões que definimos anteriormente e é válido por um ano. Quando são exibidos avisos solicitando uma senha para o certificado. Digite uma frase apropriada em resposta aos prompts. Lembre-se desta frase.
Finalmente, temos os certificados da CA raiz e intermediária. Agora é hora de configurar o certificado do nó e assiná-lo com a CA raiz e a chave intermediária.
Etapa 6 - Configurar chave de nó e CSR
openssl genrsa -out node1.key 2048 2>/dev/null
Depois que a chave criptografada para o nó for gerada, configure o csr do nó.
openssl req -new -key node1.key -out node1.csr -subj "/C=US/O=Couchbase/CN=server1_linux" 2>/dev/null
Aqui, o nome comum definido no assunto do certificado é o nome do nó, conforme definido e mapeado em /etc/hosts.
Ao configurar o csr do nó, use o nodename (preferível), o endereço IP ou o URI com um certificado SAN (nome alternativo do assunto).
A maneira usual de especificar a identidade do certificado é por meio do nome comum (CN) no DN do assunto do certificado. Se você implantar um certificado em um host multi-homed, será necessário definir um certificado com identidades alternativas usando a opção subjectAltName extensão do certificado.
"subjectAltName = IP:172.23.99.49"
Etapa 7 - Gerar o certificado de nó usando as extensões apropriadas
openssl x509 -req -in node1.csr -CA int1.pem -CAkey int1.key -CAcreateserial \
-CAserial intermediateCA.srl -out node1.pem -days 365
Isso é semelhante às etapas acima para gerar o certificado intermediário.
Etapa 8 – Gerar a cadeia de certificados
cat node1.pem int1.pem > chain.pem
Concatene todos os certificados intermediários e de nó na ordem correta. O certificado raiz nunca é incluído na cadeia. Essa cadeia permitirá que o cliente verifique o certificado intermediário em relação ao certificado raiz.
Etapa 9 - Implementar os certificados
- Copie o certificado criptografado do nó e o certificado de cadeia para a pasta da caixa de entrada em ../var/lib/couchbase/inbox em relação ao local onde os binários são executados em seu sistema operacional e dê a eles as permissões apropriadas usando chmod a+x
- node1.key e chain.pem são copiados para ../inbox
- chmod a+x node1.key
- chmod a+x chain.pem
- Carregue-os no servidor
- curl -X POST -data-binary ca.pem http://Administrator:password@172.23.99.49:8091/controller/uploadClusterCA
- curl -X POST http://Administrator:password@172.23.99.49:8091/node/controller/reloadCertificate
Quando você carrega o certificado do cluster no Couchbase, ele é verificado primeiro para garantir que seja um certificado X.509 válido. Em seguida, se os certificados por nó não forem assinados pelo certificado do cluster, será exibido um aviso para cada nó durante a configuração. À medida que os certificados por nó são atualizados, de modo que sejam assinados pelo certificado do cluster, o aviso para cada nó desaparece.
Uso de certificados em sua consulta N1QL CURL() ou no shell cbq
Para verificar os certificados que foram assinados por terceiros, a biblioteca usa os certificados armazenados no computador local. Para cada nó de consulta em um cluster do Couchbase, a pasta ..//var/lib/couchbase/n1qlcerts contém os certificados necessários para CURL(). Se os certificados não forem encontrados nessa pasta, será gerado um erro. A opção cacert é usada para passar um nome de certificado para a função. A passagem de um caminho causará um erro.
select CURL("https://127.0.0.1:18091/pools",{"request": "GET", "user": "Bucketuser:password", "cacert": "ca.pem"})
Para se conectar usando o shell, use as opções cacert, cert e key.
./cbq -cacert ca.pem -cert chain.pem -key node1.key -engine https://172.23.99.49:18091
Com este artigo, agora sabemos como configurar certificados X509 em nosso servidor e usá-los com a consulta N1QL e o shell CBQ. No próximo artigo, vamos nos aprofundar nos certificados do lado do cliente.
