Sobre TLS/SSL

Você está lendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

O Transport Layer Security (TLS), cujo predecessor é o Secure Sockets Layer (SSL), é a tecnologia de segurança padrão para estabelecer um link criptografado entre um servidor da Web e um cliente da Web, como um navegador ou um app. Um link criptografado garante que todos os dados transmitidos entre o servidor e o cliente permaneçam privados. Para usar o TLS, um cliente faz uma solicitação segura ao servidor usando o protocolo HTTPS criptografado, em vez do protocolo HTTP não criptografado.

O Edge é compatível com TLS unidirecional e bidirecional em uma implantação na nuvem e local. Para ver as versões compatíveis do TLS, consulte Software e versões compatíveis. O TLS unidirecional permite que o cliente TLS verifique a identidade do servidor TLS. Por exemplo, um app em execução em um smartphone Android (cliente) pode verificar a identidade das APIs do Edge (servidor).

A Apigee também oferece suporte a uma forma mais forte de autenticação usando TLS bidirecional ou do cliente. Normalmente, você implementa o TLS bidirecional para aumentar a segurança de ponta a ponta e proteger seus dados contra ataques de clientes, como spoofing de cliente ou ataques man-in-the-middle. No TLS bidirecional, o cliente verifica a identidade do servidor, e o servidor verifica a identidade do cliente.

Terminologia de TLS

Antes de configurar o TLS, familiarize-se com os seguintes termos e conceitos importantes:

Termo	Definição
CA	Autoridade certificadora. Uma entidade confiável, como Symantec ou VeriSign, usada para emitir e validar a autenticidade de um certificado. Um tipo de certificado, chamado de autoassinado, não exige uma AC.
Cadeia de certificados	Muitas vezes, você não terá um certificado assinado pela chave privada raiz da sua CA. Em vez disso, você tem seu certificado e um ou mais certificados intermediários que formam uma cadeia. O último certificado intermediário na cadeia normalmente é assinado pela chave privada raiz da CA.
CSR	Solicitação de assinatura de certificado. Uma CSR é um arquivo gerado no servidor TLS com base na chave privada. A CSR contém a chave pública e outras informações, como o nome, o local e o nome de domínio da organização. A CA assina a CSR para criar um certificado TLS. Normalmente, você gera uma CSR quando tem um certificado expirado e quer renová-lo.
DER	Regras de codificação diferenciadas. O formato DER é uma forma binária de um certificado em vez do formato ASCII PEM. Às vezes, ele tem a extensão .der, mas geralmente é .cer. A única maneira de saber a diferença entre um arquivo .cer DER e um .cer PEM é abrir o arquivo em um editor de texto e procurar as instruções BEGIN e END. Todos os tipos de certificados e chaves privadas podem ser codificados no formato DER. O DER é usado normalmente com plataformas Java.
Alias da chave	Um alias de chave identifica de maneira exclusiva uma entrada de keystore (certificado TLS e chave privada correspondente) no keystore. No Apigee Edge, KeyAlias é chamado de alias quando você faz upload do certificado/chave para os keystores usando a interface ou a API.
Keystore	Um keystore é um repositório que contém um ou mais certificados TLS e uma chave privada correspondente usada para identificar a entidade durante um handshake de TLS entre um cliente e um servidor. Na conexão norte, o roteador atua como o servidor, e o certificado dele é armazenado no keystore do Apigee Edge. Na conexão southbound, o Processador de mensagens atua como cliente e o servidor de back-end atua como servidor. O certificado do cliente e a chave privada dele são armazenados no keystore do Apigee Edge.
P7B	O formato PKCS nº 7 ou P7B geralmente é armazenado em formato ASCII Base64 e tem uma extensão de arquivo .p7b ou .p7c. Os certificados P7B contêm declarações -----BEGIN PKCS7----- e -----END PKCS7-----. Um arquivo P7B contém apenas certificados e certificados de cadeia, não a chave privada.
PEM	O formato Privacy Enhanced Mail (PEM) é um formato ASCII baseado em texto que é uma codificação Base64 do formato binário Distinguished Encoding Rules (DER). Os certificados PEM podem ser abertos em qualquer editor de texto, e o conteúdo real do certificado é delimitado entre as instruções -----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----. Ele está em conformidade com o formato X.509 para armazenar um certificado, uma cadeia de certificados ou uma chave privada. Se o certificado ou a chave privada não estiverem definidos por um arquivo PEM, use utilitários como o OpenSSL para fazer a conversão.
PKCS #12/PFX	O formato PKCS nº 12 ou PFX é um formato binário para armazenar o certificado do servidor, todos os certificados intermediários e a chave privada em um arquivo criptografável. Os arquivos PFX geralmente têm extensões como .pfx e .p12. Os arquivos PFX geralmente são usados em máquinas Windows para importar e exportar certificados e chaves privadas.
Chave privada	Usado no servidor TLS para descriptografar dados. Somente o servidor TLS tem a chave privada, que não é compartilhada com clientes TLS.
Chave pública	Usado para criptografar dados enviados de um cliente TLS para um servidor TLS. A chave pública é incluída no certificado. Todos os clientes TLS têm uma cópia da chave pública do servidor.
References	As referências fornecem um nível de indireção para keystores. Portanto, as mudanças de keystore não exigem uma atualização do host virtual, desde que a mesma referência e o mesmo alias de chave sejam mantidos. Assim, você pode fazer essas mudanças por conta própria e reduzir as dependências com a equipe de suporte da Apigee.
Certificado autoassinado	Um certificado que não é assinado por uma CA confiável. O emissor e o assunto são idênticos e assinados com a chave privada correspondente à chave pública que contêm.
SNI	Indicação de nome do servidor. Permite que vários destinos HTTPS sejam veiculados no mesmo endereço IP e porta sem exigir que eles usem o mesmo certificado.
Certificado TLS	Um arquivo digital que identifica uma entidade em uma transação TLS. Um certificado, ou cert, pode ser usado para identificar o servidor e o cliente TLS, dependendo da configuração do TLS.
Truststore	Contém certificados confiáveis em um cliente TLS usado para validar o certificado de um servidor TLS apresentado ao cliente. Esses certificados normalmente são autoassinados ou não são assinados por uma CA confiável. Na conexão norte, os certificados do aplicativo cliente são armazenados no truststore do Apigee Edge. Isso é necessário apenas se você tiver configurado um TLS bidirecional entre o cliente e a Apigee. Na conexão southbound, os certificados do servidor de back-end são armazenados no truststore do Apigee Edge. Isso é necessário se você quiser verificar o certificado do back-end no Apigee Edge em uma comunicação TLS unidirecional ou bidirecional entre o Apigee Edge e o servidor de back-end. O Apigee Edge não tem um objeto truststore separado. Portanto, os truststores são criados como um objeto keystore, mas referenciados como truststore sempre que são usados (por exemplo, em host virtual, endpoints de destino, servidores de destino etc.).
Host virtual	O host virtual representa o endpoint da API do Apigee para aplicativos cliente. É uma entidade que ajuda a hospedar vários nomes de domínio (com processamento separado de cada nome) em um único servidor (ou pool de servidores). Isso permite que um servidor compartilhe recursos, como memória e ciclos de processador, sem exigir que todos os serviços fornecidos usem o mesmo nome de host. Um host virtual pode veicular tráfego HTTP ou HTTPS (com SSL ativado). Um host virtual habilitado para SSL pode ser configurado no modo TLS unidirecional ou bidirecional. Ele é configurado com o seguinte: Um ou mais hostalias (nome DNS do endpoint da API). Porta Keystore Alias da chave para identificar de forma exclusiva um dos certificados do servidor no keystore. Opcionalmente, um truststore (no TLS bidirecional, em que a autenticação do cliente está ativada).

TLS/SSL unidirecional

A figura a seguir mostra o handshake TLS/SSL para autenticação unidirecional entre um cliente TLS e um servidor TLS:

Em uma configuração de TLS unidirecional, o handshake é feito da seguinte maneira:

• O cliente emite uma solicitação de sessão para o servidor.
• O servidor responde com um certificado que contém a chave pública. Esse certificado vem do keystore do servidor, que também contém a chave privada do servidor. A chave privada nunca é enviada ao cliente.
• Para um certificado assinado, o cliente usa um truststore que contém certificados de servidor e chaves públicas para validar se a cadeia de certificados é assinada por uma autoridade de certificação (CA) confiável.
• O cliente e o servidor trocam várias outras mensagens para validar as chaves.
• O cliente inicia a transferência de dados TLS com o servidor.

A figura a seguir mostra o handshake TLS/SSL usando um truststore opcional no cliente:

Se o servidor TLS usar um certificado autoassinado ou um certificado que não seja assinado por uma CA confiável, crie um truststore no cliente. O cliente preenche o truststore com certificados de servidor e chaves públicas confiáveis. Quando o cliente recebe um certificado, ele é validado em relação aos certificados no truststore.

No TLS unidirecional, o Edge pode ser o servidor ou o cliente da seguinte maneira:

• Edge como servidor TLS

  O Edge é o servidor que hospeda o endpoint TLS, que corresponde a um proxy de API implantado em um host virtual. O cliente é um app que tenta acessar o proxy de API. Nesse cenário, o Edge tem o keystore que contém o certificado e a chave privada.

• Edge como cliente TLS

  O Edge atua como o cliente que acessa um serviço de back-end. Nesse caso, o serviço de back-end corresponde ao servidor que hospeda um endpoint TLS. Portanto, o servidor de back-end tem um keystore que contém o certificado e a chave privada.

TLS bidirecional

A figura a seguir mostra o handshake TLS/SSL para autenticação TLS bidirecional entre um cliente e um servidor:

No TLS bidirecional, o handshake é feito da seguinte forma:

• O cliente e o servidor têm keystores próprios. O keystore do cliente contém o certificado e a chave privada dele, e o keystore do servidor contém o certificado e a chave privada dele.
• O servidor TLS apresenta o certificado ao cliente TLS para que ele faça a própria autenticação. O cliente verifica a identidade do servidor antes de enviar o certificado dele.
• O cliente TLS apresenta o certificado ao servidor TLS para se autenticar no servidor.

A figura a seguir mostra o handshake do TLS usando um truststore opcional:

Neste cenário, o handshake é o seguinte:

• Se o servidor TLS usar um certificado autoassinado ou um certificado que não seja assinado por uma CA confiável, crie um truststore no cliente. O cliente tem uma cópia do certificado do servidor no truststore. Durante o handshake de TLS, o cliente compara o certificado no truststore com o certificado enviado pelo servidor para verificar a identidade do servidor.
• Se o cliente TLS usar um certificado autoassinado ou um certificado que não seja assinado por uma CA confiável, crie um truststore no servidor.O servidor tem uma cópia do certificado do cliente no truststore. Durante o handshake de TLS, o servidor compara o certificado no truststore com o certificado enviado pelo cliente para verificar a identidade do cliente.

O cliente, o servidor ou ambos podem usar um truststore.

No TLS bidirecional, o Edge pode ser o servidor ou o cliente da seguinte maneira:

• Edge como servidor

  O Edge é o servidor que hospeda o endpoint TLS, que corresponde a um proxy de API. O cliente é um app que tenta acessar o proxy de API. Nesse cenário, o Edge tem um keystore que contém o certificado e a chave privada, e exige um truststore com o certificado do cliente e a cadeia de CA.

• Edge como cliente

  O Edge atua como um cliente que acessa um serviço de back-end. Nesse caso, o serviço de back-end corresponde ao servidor que hospeda o endpoint TLS. Portanto, o servidor de back-end tem um keystore que contém o certificado e a chave privada.

  O Edge também precisa definir um keystore que contenha o certificado necessário para se validar no serviço de back-end e, opcionalmente, um truststore com o certificado do servidor de back-end se o servidor usar um certificado autoassinado ou um certificado que não seja assinado por uma CA confiável.

É importante lembrar que o Edge é flexível o suficiente para oferecer suporte ao TLS bidirecional independente de como você decidir configurá-lo.

Suporte a SNI

O Edge oferece suporte ao uso da indicação de nome do servidor (SNI) de proxies de API para o Edge, em que o Edge atua como o servidor TLS, e do Edge para endpoints de destino, em que o Edge atua como o cliente TLS, em instalações na nuvem e na nuvem privada.

Com o SNI, que é uma extensão do TLS/SSL, vários destinos HTTPS podem ser veiculados no mesmo endereço IP e porta sem exigir que esses destinos usem o mesmo certificado.

Para informações sobre como ativar o SNI em uma instalação local, consulte Como usar o SNI com o Edge.

Sentido norte e sul

Na Apigee, o termo "norte" se refere ao endpoint de API usado por aplicativos cliente para invocar o proxy de API. Normalmente, o roteador é o ponto de entrada no Apigee Edge e processa as solicitações recebidas para o Apigee Edge. Portanto, na Apigee, o endpoint usado para comunicação entre o aplicativo cliente e o Apigee Edge (roteador) é chamado de norte.

Na Apigee, o termo "sul" se refere ao endpoint de destino que a Apigee usa para se comunicar com o servidor de back-end. Portanto, na Apigee, o endpoint usado para comunicação entre o Apigee Edge (processador de mensagens) e o servidor de back-end é chamado de sul. O processador de mensagens é um componente do Apigee Edge que encaminha solicitações de API para servidores de destino de back-end.

A figura a seguir ilustra as conexões nos sentidos norte e sul para o Apigee Edge: