{"id":9325,"date":"2020-09-10T08:38:59","date_gmt":"2020-09-10T15:38:59","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=9325"},"modified":"2021-01-31T13:04:38","modified_gmt":"2021-01-31T21:04:38","slug":"authentication-using-server-side-x-509-certificates-with-n1ql","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/pt\/authentication-using-server-side-x-509-certificates-with-n1ql\/","title":{"rendered":"Autentica\u00e7\u00e3o usando certificados X.509 do lado do servidor e N1QL"},"content":{"rendered":"

A autentica\u00e7\u00e3o e a autoriza\u00e7\u00e3o do servi\u00e7o de consulta N1QL no Couchbase funcionam de v\u00e1rias maneiras\u00a0<\/span><\/p>\n

    \n
  1. Passagem de credenciais por meio de uma solicita\u00e7\u00e3o rest - curl https:\/\/localhost:8093\/query\/service?pretty=true -d \"statement=select * from system:keyspaces\" -u Admin:pwd<\/span><\/li>\n
  2. Passagem de credenciais usando o par\u00e2metro nomeado creds e\/ou o par\u00e2metro de consulta -\u00a0<\/span>curl https:\/\/localhost:8093\/query\/service?pretty=true -d \"statement=select * from system:keyspaces&creds=[{user: \"Administrator\", \"password\": \"pass\"}]\"<\/li>\n
  3. Usando a autentica\u00e7\u00e3o b\u00e1sica na solicita\u00e7\u00e3o\u00a0<\/span><\/li>\n
  4. Solicita\u00e7\u00e3o do cbq (semelhante a 1,2) usando as op\u00e7\u00f5es -u -p -creds e o comando \\SET.\u00a0<\/span><\/li>\n
  5. Certificados X.509 para TLS<\/span><\/li>\n
  6. Criptografia de n\u00f3 para n\u00f3<\/li>\n<\/ol>\n

    Com a adi\u00e7\u00e3o do RBAC, o par\u00e2metro de consulta creds se tornou redundante, mas ainda \u00e9 suportado para compatibilidade com vers\u00f5es anteriores.<\/p>\n

    O objetivo de adicionar suporte a certificados X509 \u00e9 aprimorar a criptografia cliente-servidor usando um certificado confi\u00e1vel pela autoridade de certifica\u00e7\u00e3o.<\/p>\n

    Os certificados X.509 permitem a autentica\u00e7\u00e3o e a criptografia do servidor para comunica\u00e7\u00f5es cliente-servidor. O Couchbase oferece suporte \u00e0 autentica\u00e7\u00e3o de servidor e cliente usando certificados X509 e voc\u00ea precisa ser um administrador completo ou administrador de seguran\u00e7a para gerenciar certificados. Este artigo fala sobre o suporte a certificados X.509 no lado do servidor para autoriza\u00e7\u00e3o no Couchbase. Os clientes tamb\u00e9m podem verificar a identidade do Couchbase Server, mas isso ser\u00e1 discutido em outro artigo.\u00a0<\/span><\/p>\n

    Os cen\u00e1rios mais comuns para os quais os certificados X509 s\u00e3o usados s\u00e3o quando os clientes precisam passar pela Internet, <\/span>ao transferir dados confidenciais entre o aplicativo e o Couchbase Server, ou entre data centers (XDCR) ou quando exigido por normas de conformidade.\u00a0<\/span><\/p>\n

    O que \u00e9 um certificado X.509? <\/span><\/h2>\n

    \u00c9 um certificado de chave p\u00fablica usado para distribuir uma chave p\u00fablica, assinada por uma autoridade de certifica\u00e7\u00e3o confi\u00e1vel que verifica a identidade do servidor. Com ele, o cliente tem a garantia de que a solicita\u00e7\u00e3o n\u00e3o est\u00e1 sendo enviada a um servidor desconhecido. Esses certificados s\u00e3o assinados por um terceiro, tamb\u00e9m conhecido como autoridade de certifica\u00e7\u00e3o. <\/span>As ACs s\u00e3o entidades que emitem certificados digitais. Na verdade, uma AC \u00e9 composta por uma s\u00e9rie de ACs denominada hierarquia de ACs. Essa hierarquia de CAs constr\u00f3i uma cadeia de confian\u00e7a na qual todos os certificados de n\u00f3s ou de entidades finais se baseiam. A cadeia n\u00e3o cont\u00e9m a chave p\u00fablica da CA raiz.\u00a0<\/span><\/p>\n

    Em uma infraestrutura de chave p\u00fablica (PKI) hier\u00e1rquica, normalmente h\u00e1 tr\u00eas tipos de hierarquia. Uma camada, duas camadas e N camadas. A CA no topo dessa hierarquia \u00e9 conhecida como CA-raiz. Todas as CAs subsequentes s\u00e3o as CAs intermedi\u00e1rias, e a en\u00e9sima (\u00faltima) CA \u00e9 conhecida como CA de n\u00f3.\u00a0<\/span><\/p>\n

    Um ponto importante a ser observado \u00e9 <\/span>que, para confiar em um certificado usado para estabelecer uma conex\u00e3o segura, ele deve ter sido emitido por uma CA inclu\u00edda no reposit\u00f3rio confi\u00e1vel do dispositivo que est\u00e1 se conectando.<\/span><\/p>\n

    Autoridade de CA de uma ou \u00fanica camada <\/b><\/h3>\n

    Essa \u00e9 a forma mais simples de hierarquia de ACs, mas geralmente n\u00e3o \u00e9 usada na produ\u00e7\u00e3o como uma hierarquia de ACs.<\/span> O comprometimento dessa CA raiz resulta em um comprometimento de toda a PKI. <\/span>Aqui, a CA raiz tamb\u00e9m \u00e9 a CA emissora e <\/span>todos os certificados imediatamente abaixo do certificado raiz herdam sua confiabilidade.<\/span><\/p>\n

    \"\"<\/p>\n

    Autoridade de CA de dois n\u00edveis<\/b>\u00a0<\/span><\/h3>\n

    Consiste em uma CA raiz que emitiu um certificado para uma subordinada conhecida como CA intermedi\u00e1ria. A diferen\u00e7a aqui \u00e9 que os certificados emitidos s\u00e3o confi\u00e1veis, pois v\u00eam de uma autoridade confi\u00e1vel por meio da AC intermedi\u00e1ria.\u00a0<\/span><\/p>\n

    \"\"<\/p>\n

    Sinais de CA raiz-><\/span> Sinais de CA intermedi\u00e1rios<\/span> -> CA emissora \/ CA de cluster<\/span><\/p>\n

    Autoridade de CA de N camadas <\/b><\/h3>\n

    \u00a0Na maioria das implementa\u00e7\u00f5es de produ\u00e7\u00e3o, uma hierarquia tem v\u00e1rias CAs.<\/span> A AC raiz emite certificados para as ACs intermedi\u00e1rias, que, por sua vez, geram <\/span>certificados intermedi\u00e1rios<\/span><\/i>: s\u00e3o usados para assinar certificados de clientes, como um certificado de cluster:<\/span><\/p>\n