Você está vendo a documentação do Apigee Edge.
Acesse a
documentação da Apigee X. informações
O Transport Layer Security (TLS), que antecedeu 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
app. Um link criptografado garante que todos os dados transmitidos entre o servidor e o cliente permaneçam
particulares. 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 TLS bidirecional em uma implantação na nuvem e no local. Para versões compatíveis do TLS, consulte Software com suporte 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 Edge (servidor).
A Apigee também oferece suporte a uma forma mais forte de autenticação usando TLS bidirecional ou de cliente. Geralmente, o TLS bidirecional é implementado para melhorar a segurança de ponta a ponta e proteger os dados contra ataques de clientes, como spoofing de cliente ou man-in-the-middle. No TLS bidirecional, o cliente verifica a identidade do servidor, seguido pelo servidor que verifica a identidade do cliente.
Terminologia de TLS
Familiarize-se com estes termos e conceitos importantes antes de configurar o TLS:
|
Termo |
Definição |
|---|---|
|
Canadá |
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 certificado autoassinado, não requer uma AC. |
|
Cadeia de certificados |
Muitas vezes, você não terá um certificado assinado pela chave privada raiz da CA. Em vez disso, o certificado está com 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 (em inglês) |
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 AC assina a CSR para criar um certificado TLS. Normalmente, você gera uma CSR quando tem um certificado expirado e quer renová-lo. |
| DER (em alemão) |
Regras de codificação distintas. O formato DER é uma forma binária de um certificado em vez do formato ASCII PEM. Às vezes, ele tem uma extensão de arquivo .der, mas geralmente tem uma
extensão .cer. A única maneira de diferenciar um arquivo .cer do DER de um PEM é abrir o arquivo em um editor de texto e procurar as instruções |
| Alias da chave |
Um alias de chave identifica exclusivamente uma entrada de keystore (certificado TLS e chave privada correspondente) no keystore.
Na Apigee Edge, |
|
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 northbound, o roteador atua como servidor e o certificado dele é armazenado no keystore no 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 (link em inglês) |
O formato PKCS #7 ou P7B geralmente é armazenado no formato ASCII Base64 e tem uma extensão
de arquivo de .p7b ou .p7c. Os certificados P7B contêm as instruções |
|
PEM |
O formato Privacy Enhanced Mail (PEM) é um formato ASCII baseado em texto que é uma codificação Base64 do formato binário Distinguiked Encoding Rules (DER). Os certificados PEM podem ser abertos em qualquer editor de texto, e o conteúdo real do certificado é delimitado entre as declarações 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 estiver definido em um arquivo PEM, você pode convertê-lo 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 são normalmente 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. Ela 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 está 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 alterações de keystore não exigem uma atualização de host virtual, desde que a mesma referência e alias de chave sejam mantidos. Isso permite que você faça o autosserviço dessas alterações 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. Eles são assinados com a chave privada que corresponde à chave pública que eles contêm. |
|
SNI |
Indicação de nome do servidor. Permite que vários destinos HTTPS sejam atendidos a partir do mesmo endereço IP e porta, sem exigir que esses destinos usem o mesmo certificado. |
|
Certificado TLS |
Arquivo digital que identifica uma entidade em uma transação TLS. Um certificado ou cert pode ser usado para identificar o servidor TLS e o cliente TLS, dependendo da configuração do TLS. |
|
Truststore |
Contém certificados confiáveis em um cliente TLS usados para validar o certificado de um servidor TLS apresentado ao cliente. Em geral, esses certificados são autoassinados ou não são assinados por uma AC confiável. Na conexão northbound, 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 no Apigee Edge. Isso é necessário se você quer 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 de keystore, mas referenciados como truststore onde quer que sejam usados (por exemplo, em host virtual, endpoints de destino, servidores de destino etc.). |
| Host virtual |
O host virtual representa o endpoint da API Apigee para aplicativos clientes. É uma entidade que ajuda a hospedar vários nomes de domínio (com gerenciamento separado de cada nome) em um único servidor (ou pool de servidores). Isso permite que um servidor compartilhe os recursos dele, como ciclos de memória e 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 (ativado para SSL). Um host virtual com SSL ativado pode ser configurado no modo TLS unidirecional ou bidirecional. Ele é configurado da seguinte forma:
|
TLS/SSL unidirecional
A figura a seguir mostra o handshake de 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 ao 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 dele. 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, na sigla em inglês) 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 de 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 AC confiável, você criará um truststore no cliente. O cliente preenche o truststore com certificados do servidor e chaves públicas em que ele confia. Quando o cliente recebe um certificado, o certificado recebido é validado em relação aos certificados no truststore dele.
No TLS unidirecional, o Edge pode ser o servidor ou o cliente, da seguinte maneira:
-
Edge como o servidor TLS
A borda é o servidor que hospeda o endpoint TLS, em que o endpoint TLS corresponde a um proxy de API implantado em um host virtual. O cliente é um app que está tentando acessar o proxy de API. Nesse cenário, o Edge tem o keystore que contém o certificado e a chave privada.
-
Edge como o 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 de TLS/SSL para autenticação TLS bidirecional entre um cliente e um servidor:
No TLS bidirecional, o handshake é o seguinte:
- Tanto o cliente quanto o servidor têm seus próprios keystores. 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 o servidor.
- O cliente TLS apresenta o certificado ao servidor TLS para se autenticar no servidor.
A figura a seguir mostra o handshake de 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 AC confiável, você criará um truststore no cliente. O cliente tem uma cópia do certificado do servidor no truststore. Durante o handshake do TLS, o cliente compara o certificado no truststore dele com o envio do certificado do 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 AC confiável, você criará um truststore no servidor.O servidor terá uma cópia do certificado do cliente no truststore dele. Durante o handshake do TLS, o servidor compara o certificado no truststore com o envio do certificado do 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 o servidor
A borda é o servidor que hospeda o endpoint TLS, em que o endpoint TLS corresponde a um proxy de API. O cliente é um app que está tentando acessar o proxy de API. Nesse cenário, o Edge tem um keystore que contém o certificado e a chave privada e requer um truststore que contenha o certificado e a cadeia de AC do cliente.
-
Edge como o 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. O servidor de back-end, portanto, 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 para o serviço de back-end e, opcionalmente, um truststore contendo o certificado do servidor de back-end se o servidor usar um certificado autoassinado ou um certificado que não seja assinado por uma AC confiável.
O importante a lembrar é que o Edge é flexível o suficiente para dar suporte ao TLS bidirecional, independentemente de como você o configure.
Suporte a SNI
O Edge é compatível com o uso de 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 do Edge até os endpoints de destino, onde o Edge atua como o cliente TLS, em instalações na nuvem e na nuvem privada.
Com a SNI, que é uma extensão do TLS/SSL, vários destinos HTTPS podem ser disponibilizados a partir do mesmo endereço IP e porta, sem exigir que esses destinos usem o mesmo certificado.
Para informações sobre como ativar o SNI para uma instalação no local, consulte Como usar o SNI com o Edge.
Sentido norte e sul
Na Apigee, a direção norte se refere ao endpoint da API usado pelos aplicativos clientes para invocar o proxy da 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 a comunicação entre o aplicativo cliente e o Apigee Edge (roteador) é chamado de fronteira norte.
Na Apigee, "sentido 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 southbound. O processador de mensagens é um componente do Apigee Edge que envia solicitações de API por proxy para servidores de destino de back-end.
A figura a seguir ilustra as conexões dos sentidos norte e sul do Apigee Edge:
