Sobre TLS/SSL

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

O Transport Layer Security (TLS), cujo antecessor é 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 aplicativo. 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 oferece suporte a TLS unidirecional e bidirecional em implantações na nuvem e locais. Para conferir as versões de TLS com suporte, consulte Software e versões com suporte. O TLS unidirecional permite que o cliente TLS verifique a identidade do servidor TLS. Por exemplo, um app executado em um smartphone Android (cliente) pode verificar a identidade das APIs do Edge (servidor).

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

Terminologia de TLS

Antes de configurar o TLS, você precisa conhecer os seguintes termos e conceitos importantes:

Termo	Definição
CA	Autoridade certificadora. Uma entidade confiável, como Symantec ou VeriSign, usada para emitir certificados 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 tem um certificado assinado pela chave privada raiz da AC. Em vez disso, você tem seu certificado com um ou mais certificados intermediários que formam uma cadeia. O último certificado intermediário na cadeia geralmente é assinado pela chave privada raiz da AC.
CSR	Solicitação de assinatura de certificado. Uma CSR é um arquivo gerado no servidor TLS com base na chave privada. O 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 AC 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 distintas. O formato DER é uma forma binária de um certificado, em vez do formato ASCII PEM. Às vezes, tem uma extensão de arquivo .der, mas geralmente tem uma extensão de arquivo .cer. A única maneira de saber a diferença entre um arquivo .cer DER e um arquivo .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 geralmente é usado com plataformas Java.
Alias da chave	Um alias de chave identifica de forma exclusiva uma entrada de keystore (certificado TLS e chave privada correspondente) no keystore. No Apigee Edge, KeyAlias é chamado de alias quando você faz o upload do certificado/chave para as chaves usando a IU ou a API.
Keystore	Um keystore é um repositório que contém um ou mais certificados TLS e uma chave privada correspondente, que é usada para identificar a entidade durante um handshake de TLS entre um cliente e um servidor. Na conexão northbound, o roteador atua como servidor, e o certificado dele é armazenado no keystore no Apigee Edge. Na conexão sul, o processador de mensagens atua como cliente, e o servidor de back-end atua como servidor. O certificado do cliente e a chave privada são armazenados no keystore no Apigee Edge.
P7B	O formato PKCS #7 ou P7B geralmente é armazenado no formato ASCII Base64 e tem uma extensão .p7b ou .p7c. Os certificados P7B contêm instruçõ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 das regras de codificação diferenciadas (DER) binárias. Os certificados PEM podem ser abertos em qualquer editor de texto, e o conteúdo do certificado é delimitado entre as instruções -----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----. Ele obedece ao formato X.509 para armazenar um certificado, uma cadeia de certificados ou uma chave privada. Se o certificado ou a chave privada não forem definidos por um arquivo PEM, você poderá convertê-los em um arquivo PEM usando utilitários como o OpenSSL.
PKCS #12/PFX	O formato PKCS #12 ou PFX é um formato binário para armazenar o certificado do servidor, quaisquer 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 os 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 indirecionamento 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 alias da chave sejam mantidos. Isso permite que você faça essas mudanças por conta própria e reduza as dependências com a equipe de suporte da Apigee.
Certificado autoassinado	Um certificado que não é assinado por uma AC confiável. O emissor e o assunto são idênticos e são assinados com a chave privada correspondente à chave pública que contêm.
SNI	Indicação de nome do servidor. Permite que várias de destino HTTPS sejam veiculadas pelo mesmo endereço IP e porta sem exigir que elas 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 geralmente são autoassinados ou não são assinados por uma AC confiável. Na conexão norte-sul, os certificados do aplicativo cliente são armazenados no repositório de confiança no 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 repositório de confiança no 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 de repositório de confiança separado. Portanto, os truststores são criados como um objeto de keystore, mas são referenciados como truststore sempre que usados (por exemplo, em host virtual, endpoints de destino, servidores de destino etc.).
Host virtual	Host virtual representa o endpoint da API Apigee para aplicativos clientes. É uma entidade que ajuda a hospedar vários nomes de domínio (com tratamento separado de cada nome) em um único servidor ou pool de servidores. Isso permite que um servidor compartilhe seus 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 exibir tráfego HTTP ou HTTPS (com SSL ativado). Um host virtual com SSL ativado 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 de chave para identificar exclusivamente um dos certificados do servidor no keystore. Opcionalmente, um repositório de certificados (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 é o seguinte:

• 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 repositório de confiança contendo certificados do servidor e chaves públicas para validar se a cadeia de certificados foi assinada por uma autoridade de certificação (AC) 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 foi assinado por uma autoridade certificadora confiável, crie um repositório de confiança no cliente. O cliente preenche o keystore com certificados de servidor e chaves públicas confiáveis. Quando o cliente recebe um certificado, o certificado recebido é 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 da API. Nesse cenário, o Edge tem o keystore que contém o certificado e a chave privada.

• O 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 é o seguinte:

• O cliente e o servidor têm chaveiros próprios. O keystore do cliente contém o certificado e a chave privada, e o keystore do servidor contém o certificado e a chave privada.
• 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 para ele.
• O cliente TLS apresenta o certificado ao servidor TLS para que ele faça a própria autenticação.

A figura a seguir mostra o handshake do TLS usando um repositório de confiança opcional:

Nesse cenário, o handshake é o seguinte:

• Se o servidor TLS usar um certificado autoassinado ou um certificado que não foi assinado por uma AC confiável, crie um repositório de confiança 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 foi assinado por uma AC confiável, crie um repositório de confiança no servidor.O servidor tem uma cópia do certificado do cliente no repositório de confiança. Durante o handshake de TLS, o servidor compara o certificado no repositório de confiança com o certificado enviado pelo cliente para verificar a identidade do cliente.

O cliente, o servidor ou ambos podem usar um repositório de confiança.

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, em que o endpoint TLS corresponde a um proxy de API. O cliente é um app que tenta acessar o proxy da API. Nesse cenário, o Edge tem um keystore que contém o certificado e a chave privada e exige um repositório de confiança que contenha o certificado e a cadeia de AC do cliente.

• O 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 keystore que contenha o certificado do servidor de back-end se o servidor usa um certificado autoassinado ou um certificado que não é assinado por uma AC confiável.

O 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, na sigla em inglês) de proxies de API para o Edge, em que o Edge atua como o servidor TLS, e de endpoints de destino para o Edge, em que o Edge atua como cliente TLS, em instalações de nuvem e nuvem privada.

Com o SNI, que é uma extensão do TLS/SSL, várias destinações HTTPS podem ser atendidas pelo mesmo endereço IP e porta sem exigir que elas usem o mesmo certificado.

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

Sentido norte e sul

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

Na Apigee, o tráfego 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 a 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 em back-end.

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