As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Criar um receptor HTTPS para seu Application Load Balancer
Um receptor verifica se há solicitações de conexão. Você define um listener ao criar seu load balancer e você pode adicionar listeners ao seu load balancer a qualquer momento.
Para usar um receptor HTTPS, você deve implantar pelo menos um certificado de servidor SSL em seu balanceador de carga. O load balancer usa um certificado de servidor para encerrar a conexão front-end e descriptografa solicitações dos clientes antes de enviá-las aos destinos. Você também deve especificar uma política de segurança que será usada para negociar conexões protegidas entre os clientes e o balanceador de carga.
Se precisar transmitir tráfego criptografado para destinos sem que o balanceador de carga o decodifique, você poderá criar um Network Load Balancer ou Classic Load Balancer com um receptor TCP na porta 443. Com um receptor TCP, o balanceador de carga transmite o tráfego criptografado para os destinos sem descriptografá-lo.
Os Application Load Balancers não são compatíveis com chaves ED25519.
As informações dessa página ajudam você a criar um listener HTTPS para o load balancer. Para adicionar um listener HTTPS ao seu load balancer, consulte Criar um receptor HTTP para seu Application Load Balancer.
Sumário
Certificados SSL
O load balancer requer certificados X.509 (certificados de servidor SSL/TLS). Os certificados são uma forma digital de identificação emitida por uma autoridade certificadora (CA). Um certificado contém informações de identificação, período de validade, chave pública, número de série e a assinatura digital do emissor.
Quando você cria um certificado para uso com seu load balancer, é necessário especificar um nome de domínio. O nome de domínio no certificado deve corresponder ao registro de nome de domínio personalizado para que possamos verificar a conexão TLS. Se eles não coincidirem, o tráfego não será criptografado.
Você precisa especificar um nome de domínio totalmente qualificado (FQDN) para seu certificado, como www.example.com ou um nome de domínio de apex como example.com. Você também pode usar um asterisco (*) como um caractere curinga para proteger vários nomes de site no mesmo domínio. Quando você solicita um certificado-curinga, o asterisco (*) deve estar na posição mais à esquerda do nome do domínio e só pode proteger um nível de subdomínio. Por exemplo,*.example.com protege corp.example.com e images.example.com, mas não pode proteger test.login.example.com. Note também que *.example.com protege apenas os subdomínios de example.com, mas não protege o domínio vazio ou apex (example.com). O nome-curinga será exibido no campo Assunto e na extensão Nome alternativo do assunto do certificado. Para obter mais informações sobre certificados públicos, consulte Solicitação de um certificado público no Manual do usuário do AWS Certificate Manager .
Recomendamos que você crie certificados para o seu balanceador de carga usando o AWS Certificate Manager (ACM)
Como alternativa, você pode usar ferramentas SSL/TLS para criar uma solicitação de assinatura de certificado (CSR) e, em seguida, obter a CSR assinada por uma CA para produzir um certificado e, em seguida, importar o certificado para o ACM ou fazer o upload do certificado no (IAM). AWS Identity and Access Management Para obter mais informações sobre a importação de certificados para o ACM, consulte Importação de certificados no Guia do usuário do AWS Certificate Manager . Para obter mais informações sobre a upload de certificados no IAM, consulte Trabalhar com certificados de servidor no Manual do usuário do IAM.
Certificado padrão
Quando você cria um listener HTTPS, deve especificar exatamente um certificado. Esse certificado é conhecido como o certificado padrão. É possível substituir o certificado padrão depois de criar o listener HTTPS. Para ter mais informações, consulte Substituir o certificado padrão.
Se você especificar certificados adicionais em uma lista de certificados, o certificado padrão será usado somente se um cliente se conectar sem usar o protocolo Server Name Indication (SNI) para especificar um nome de host ou se não houver certificados correspondentes na lista de certificados.
Se você não especificar certificados adicionais, mas precisar hospedar vários aplicativos seguros por meio de um único load balancer, poderá usar um certificado curinga ou adicionar um Subject Alternative Name (SAN) para cada domínio adicional ao seu certificado.
Lista de certificados
Após criar um listener HTTPS, ele terá um certificado padrão e uma lista de certificados vazia. Você pode adicionar certificados à lista de certificados para o listener. O uso de uma lista de certificados permite que um load balancer ofereça suporte a vários domínios na mesma porta e forneça um certificado diferente para cada domínio. Para ter mais informações, consulte Adicionar certificados à lista de certificados.
O load balancer usa um algoritmo inteligente de seleção de certificado com suporte para SNI. Se o nome de host fornecido por um cliente corresponder a um único certificado na lista, o load balancer selecionará esse certificado. Se um nome de host fornecido por um cliente corresponder a vários certificados na lista, o load balancer selecionará o melhor certificado que o cliente puder comportar. A seleção do certificado se baseia nos critérios a seguir, na seguinte ordem:
-
Algoritmo de chave pública (prefira ECDSA em relação a RSA)
-
Algoritmo hashing (prefira SHA em relação a MD5)
-
Comprimento da chave (prefira o maior)
-
Período de validade
As entradas no log de acesso do load balancer indicam o hostname especificado pelo cliente e o certificado apresentado ao cliente. Para ter mais informações, consulte Entradas do log de acesso.
Renovação de certificado
Cada certificado vem com um período de validade. Você deve garantir que renovou ou substituiu os certificados do load balancer antes do fim do período de validade. Isso inclui o certificado padrão e os certificados em uma lista de certificados. Renovar ou substituir um certificado não afeta as solicitações em andamento recebidas por um nó do load balancer e são pendentes de roteamento para um destino íntegro. Depois de um certificado ser renovado, as novas solicitações usarão o certificado renovado. Depois de o certificado ser substituído, as novas solicitações usarão o novo certificado.
Você pode gerenciar a renovação e a substituição do certificado da seguinte forma:
-
Os certificados fornecidos AWS Certificate Manager e implantados em seu balanceador de carga podem ser renovados automaticamente. O ACM tenta renovar os certificados antes que eles expirem. Para obter mais informações, consulte Renovação gerenciada no Guia do usuário do AWS Certificate Manager .
-
Se você tiver importado um certificado no ACM, deverá monitorar a data de validade do certificado e renová-lo antes que expire. Para obter mais informações, consulte Importar certificados no Manual do usuário do AWS Certificate Manager .
-
Se você tiver importado um certificado para o IAM, precisará criar um novo certificado, importá-lo para o ACM ou IAM, adicionar o novo certificado ao balanceador de carga e remover o certificado expirado do seu balanceador de carga.
Políticas de segurança
O Elastic Load Balancing usa uma configuração de negociação com Secure Sockets Layer (SSL), conhecida como política de segurança, para negociar conexões SSL entre um cliente e o balanceador de carga. Uma política de segurança é uma combinação de cifras e protocolos. O protocolo estabelece uma conexão segura entre um cliente e um servidor, além de garantir que todos os dados passados entre o cliente e o load balancer sejam privados. A cifra é um algoritmo de criptografia que usa chaves de criptografia para criar uma mensagem codificada. Os protocolos usam várias cifras para criptografar dados pela Internet. Durante o processo de negociação de conexão, o cliente e o load balancer apresentam uma lista de cifras e protocolos que cada um suporta, em ordem de preferência. Por padrão, a primeira cifra na lista do servidor que corresponder a qualquer uma das cifras do cliente é selecionada para a conexão segura.
Considerações:
-
Os Application Load Balancers são compatíveis com renegociação de SSL apenas para conexões de destino.
-
Os Application Load Balancers não são compatíveis com políticas de segurança personalizadas.
-
A
ELBSecurityPolicy-TLS13-1-2-2021-06política é a política de segurança padrão para ouvintes HTTPS criados usando o. AWS Management Console -
A
ELBSecurityPolicy-2016-08política é a política de segurança padrão para ouvintes HTTPS criados usando o. AWS CLI -
Quando você cria um ouvinte HTTPS, é necessário selecionar uma política de segurança.
-
Recomendamos a política
ELBSecurityPolicy-TLS13-1-2-2021-06de segurança, que inclui o TLS 1.3 e é compatível com versões anteriores do TLS 1.2.
-
-
Você pode escolher a política de segurança usada para conexões front-end, mas não para conexões back-end.
-
Para conexões de back-end, se seu receptor HTTPS estiver usando uma política de segurança TLS 1.3, a política de segurança
ELBSecurityPolicy-TLS13-1-0-2021-06será usada. Caso contrário, a política de segurançaELBSecurityPolicy-2016-08sempre será usada para as conexões de back-end.
-
-
Para atender aos padrões de conformidade e segurança que exigem a desativação de determinadas versões do protocolo TLS ou para oferecer suporte a clientes antigos que exigem cifras obsoletas, você pode usar uma das políticas de segurança.
ELBSecurityPolicy-TLS-Para visualizar a versão do protocolo TLS para solicitações ao seu Application Load Balancer, ative o registro de acesso para seu balanceador de carga e examine as entradas correspondentes do registro de acesso. Para obter mais informações, consulte Registros de acesso do seu Application Load Balancer. -
Você pode restringir quais políticas de segurança estão disponíveis para os usuários em todo o seu Contas da AWS e AWS Organizations usando as chaves de condição do Elastic Load Balancing em suas políticas de IAM e controle de serviços (SCPs), respectivamente. Para obter mais informações, consulte Políticas de controle de serviços (SCPs) no Guia do AWS Organizations usuário
Políticas de segurança do TLS 1.3
O Elastic Load Balancing fornece as seguintes políticas de segurança TLS 1.3 para Application Load Balancers:
-
ELBSecurityPolicy-TLS13-1-2-2021-06(Recomendado) -
ELBSecurityPolicy-TLS13-1-2-Res-2021-06 -
ELBSecurityPolicy-TLS13-1-2-Ext1-2021-06 -
ELBSecurityPolicy-TLS13-1-2-Ext2-2021-06 -
ELBSecurityPolicy-TLS13-1-1-2021-06 -
ELBSecurityPolicy-TLS13-1-0-2021-06 -
ELBSecurityPolicy-TLS13-1-3-2021-06
Políticas de segurança FIPS
Importante
Todos os ouvintes seguros conectados a um Application Load Balancer devem usar políticas de segurança FIPS ou políticas de segurança não FIPS; elas não podem ser misturadas. Se um Application Load Balancer existente tiver dois ou mais ouvintes usando políticas não FIPS e você quiser que os ouvintes usem políticas de segurança FIPS em vez disso, remova todos os ouvintes até que haja apenas um. Altere a política de segurança do ouvinte para FIPS e, em seguida, crie ouvintes adicionais usando políticas de segurança FIPS. Como alternativa, você pode criar um novo Application Load Balancer com novos ouvintes usando somente políticas de segurança FIPS.
O Federal Information Processing Standard (FIPS) é um padrão do governo dos EUA e do Canadá que especifica os requisitos de segurança para módulos criptográficos que protegem informações confidenciais. Para saber mais, consulte Federal Information Processing Standard (FIPS) 140
Todas as políticas de FIPS utilizam o módulo criptográfico validado pelo AWS-LC FIPS. Para saber mais, consulte a página do Módulo Criptográfico AWS-LC no site do Programa de Validação do Módulo Criptográfico
O Elastic Load Balancing fornece as seguintes políticas de segurança FIPS para Application Load Balancers:
-
ELBSecurityPolicy-TLS13-1-3-FIPS-2023-04 -
ELBSecurityPolicy-TLS13-1-2-Res-FIPS-2023-04 -
ELBSecurityPolicy-TLS13-1-2-FIPS-2023-04(Recomendado) -
ELBSecurityPolicy-TLS13-1-2-Ext0-FIPS-2023-04 -
ELBSecurityPolicy-TLS13-1-2-Ext1-FIPS-2023-04 -
ELBSecurityPolicy-TLS13-1-2-Ext2-FIPS-2023-04 -
ELBSecurityPolicy-TLS13-1-1-FIPS-2023-04 -
ELBSecurityPolicy-TLS13-1-0-FIPS-2023-04
Políticas compatíveis com FS
O Elastic Load Balancing fornece as seguintes políticas de segurança suportadas por FS (Forward Secrecy) para Application Load Balancers:
-
ELBSecurityPolicy-FS-1-2-Res-2020-10 -
ELBSecurityPolicy-FS-1-2-Res-2019-08 -
ELBSecurityPolicy-FS-1-2-2019-08 -
ELBSecurityPolicy-FS-1-1-2019-08 -
ELBSecurityPolicy-FS-2018-06
Políticas de segurança TLS 1.0 - 1.2
O Elastic Load Balancing fornece as seguintes políticas de segurança TLS 1.0 a 1.2 para Application Load Balancers:
-
ELBSecurityPolicy-TLS-1-2-Ext-2018-06 -
ELBSecurityPolicy-TLS-1-2-2017-01 -
ELBSecurityPolicy-TLS-1-1-2017-01 -
ELBSecurityPolicy-2016-08 -
ELBSecurityPolicy-TLS-1-0-2015-04 -
ELBSecurityPolicy-2015-05(idêntico aELBSecurityPolicy-2016-08)
Protocolos e cifras TLS
Adicionar um receptor HTTPS
Você configura um listener com um protocolo e uma porta para as conexões de clientes com o load balancer, e um grupo de destino para a regra do listener padrão. Para ter mais informações, consulte Configuração do receptor.
Pré-requisitos
-
Para criar um listener HTTPS, você deverá especificar um certificado e uma política de segurança. O load balancer usará o certificado para encerrar a conexão e descriptografar solicitações dos clientes antes de roteá-las aos destinos. O load balancer usa a política de segurança ao negociar conexões SSL com os clientes.
-
Para adicionar uma ação de encaminhamento à regra do listener padrão, você deve especificar um grupo de destino disponível. Para ter mais informações, consulte Criar um grupo de destino.
-
Você pode especificar o mesmo grupo de destino em vários receptores, mas esses receptores devem pertencer ao mesmo balanceador de carga. Para usar um grupo de destino com um balanceador de carga, você deve verificar se ele não está sendo usado por um receptor para nenhum outro balanceador de carga.
Adicionar um listener HTTPS usando o console
Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/
. -
No painel de navegação, selecione Balanceador de carga.
-
Selecione o load balancer.
-
Na guia Receptores e regras, escolha Adicionar receptor.
-
Em Protocolo:Porta, escolha HTTPS e mantenha a porta padrão ou insira outra porta.
-
(Opcional) Para habilitar a autenticação, em Autenticação, selecione Usar OpenID ou Amazon Cognito e forneça as informações solicitadas. Para ter mais informações, consulte Autenticar usuários usando um Application Load Balancer.
-
Em Default actions (Ações padrão), siga um destes procedimentos:
-
Encaminhar para grupos de destino: escolha um ou mais grupos de destino para os quais deseja encaminhar o tráfego. Para adicionar grupos de destino, escolha Adicionar grupo de destino. Se estiver usando mais de um grupo de destino, selecione um peso para cada um e revise o percentual associado. Se tiver habilitado a persistência em um ou mais dos grupos de destino, você deverá ativar a persistência no nível de grupo em uma regra.
-
Redirecionar para URL: especifique o URL para o qual as solicitações do cliente serão redirecionadas. É possível fazer isso inserindo cada parte separadamente na guia de Partes do URI ou inserindo o endereço completo na guia URL completo. Em Código de status, você pode configurar redirecionamentos como temporários (HTTP 302) ou permanentes (HTTP 301) com base em suas necessidades.
-
Retornar resposta fixa: especifique o código de resposta que será retornado às solicitações descartadas do cliente. Além disso, você pode especificar o tipo de conteúdo e o corpo da resposta, mas eles não são obrigatórios.
-
-
Em Política de segurança, recomendamos que você sempre use a política de segurança predefinida mais recente.
-
Para Certificado SSL/TLS padrão, as seguintes opções estão disponíveis:
-
Se você criou ou importou um certificado usando AWS Certificate Manager, selecione Do ACM e, em seguida, selecione o certificado em Selecionar um certificado.
-
Se você tiver importado um certificado usando IAM, selecione Do IAM e selecione seu certificado em Selecionar um certificado.
-
Se você tiver um certificado para importar, mas o ACM não estiver disponível na sua região, selecione Importar e selecione Para o IAM. Digite o nome do certificado no campo Nome do certificado. Em Chave privada do certificado, copie e cole o conteúdo do arquivo de chave privada (codificado por PEM). Em Corpo do certificado, copie e cole o conteúdo do arquivo do certificado de chave pública (codificado por PEM). Na Cadeia de certificados, copie e cole o conteúdo do arquivo da cadeia do certificado (codificado por PEM), exceto se estiver usando um certificado autoatribuído e se não for importante que os navegadores aceitem implicitamente o certificado.
-
-
(Opcional) Para habilitar a autenticação mútua, em Tratamento de certificados do cliente, ative a autenticação mútua (mTLS).
Quando ativado, o modo TLS mútuo padrão é de passagem.
Se você selecionar Verificar com o Trust Store:
-
Por padrão, as conexões com certificados de cliente expirados são rejeitadas. Para alterar esse comportamento, expanda Configurações avançadas de mTLS e, em seguida, em Expiração do certificado do cliente, selecione Permitir certificados de cliente expirados.
-
Em Trust Store, escolha um repositório confiável existente ou escolha Novo repositório confiável.
-
Se você escolher Novo repositório confiável, forneça um nome do repositório confiável, a localização da Autoridade de Certificação de URI do S3 e, opcionalmente, um local da lista de revogação do Certificado de URI do S3.
-
-
-
Selecione Save (Salvar).
Para adicionar um ouvinte HTTPS usando o AWS CLI
Use o comando create-listener para criar o listener e a regra padrão, e o comando create-rule para definir as regras de listener adicionais.
