Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Observação
A desativação do TLS 1.1 e TLS 1.0 nos serviços do Azure não afeta aplicativos em execução no Serviço de Aplicativo do Azure, no Azure Functions ou nos Aplicativos Lógicos do Azure (Standard). Aplicativos no Serviço de Aplicativo, no Azure Functions ou nos Aplicativos Lógicos (Standard) configurados para aceitar o TLS 1.1 ou TLS 1.0 para solicitações de entrada continuarão sendo executados sem nenhuma alteração.
O TLS é um protocolo de segurança amplamente adotado que foi desenvolvido para proteger conexões e comunicações entre servidores e clientes. No Serviço de Aplicativo do Azure, você pode usar certificados TLS e SSL para ajudar a proteger solicitações de entrada em seus aplicativos Web.
O Serviço de Aplicativo dá suporte ao TLS para ajudar a garantir:
- Criptografia de dados em trânsito.
- Autenticação de aplicativos Web usando certificados confiáveis.
- Integridade para evitar a adulteração de dados durante a transmissão.
Dica
Você também pode fazer essas perguntas ao Azure Copilot, um assistente alimentado por IA no portal do Azure:
- Quais versões do TLS têm suporte no Serviço de Aplicativo?
- Quais são os benefícios de usar o TLS 1.3, em vez de versões anteriores?
- Como posso alterar a ordem do conjunto de criptografias para meu Ambiente de Serviço de Aplicativo?
No cabeçalho da página no portal do Azure, selecione Copilot.
Suporte à versão do TLS
O Serviço de Aplicativo do Azure dá suporte às seguintes versões do TLS para solicitações de entrada para seu aplicativo Web:
- TLS 1.3: a versão mais recente e mais segura, agora totalmente compatível.
- TLS 1.2: a versão mínima padrão do TLS para novos aplicativos Web.
- TLS 1.1 e TLS 1.0: versões com suporte para compatibilidade com versões anteriores, mas não recomendadas.
Você pode configurar a versão mínima do TLS para solicitações de entrada para seu aplicativo Web e seu site do SCM (Gerenciador de Código-Fonte). Por padrão, a versão mínima é definida como TLS 1.2.
Você pode usar o Azure Policy para ajudar na auditoria dos seus recursos e da versão mínima do TLS. Acesse Aplicativos do Serviço de Aplicativo devem usar a definição de política de versão mais recente do TLS e alterar os valores para a versão mínima do TLS que seus aplicativos Web devem usar. Para definições de política relacionadas a outros recursos do Serviço de Aplicativo, confira Lista de definições de políticas internas – Azure Policy para Serviço de Aplicativo.
TLS 1.3
O TLS 1.3 tem suporte total no Serviço de Aplicativo e apresenta várias melhorias em relação ao TLS 1.2:
- Segurança mais forte, com conjuntos de criptografias simplificados e sigilo de encaminhamento.
- Handshakes mais rápidos para latência reduzida.
- Mensagens de handshake criptografadas para maior privacidade.
Para exigir o TLS 1.3 para todas as solicitações de entrada, defina versão mínima do TLS de entrada como TLS 1.3 no portal do Azure, na CLI do Azure ou no modelo do ARM (Azure Resource Manager).
O TLS 1.3 dá suporte aos seguintes conjuntos de criptografias, que são fixos e não podem ser personalizados:
TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
Esses pacotes fornecem criptografia forte e são usados automaticamente quando o TLS 1.3 é negociado.
TLS 1.2
O TLS 1.2 é a versão padrão do TLS para o Serviço de Aplicativo. Ele fornece criptografia forte e ampla compatibilidade ao atender aos padrões de conformidade, como o PCI DSS (Payment Card Industry Data Security Standard). Novos aplicativos Web e pontos de extremidade SCM por padrão usam o TLS 1.2, a menos que você os altere.
O Serviço de Aplicativo do Azure usa um conjunto seguro de conjuntos de criptografias TLS 1.2 para ajudar a garantir conexões criptografadas e proteger contra vulnerabilidades conhecidas. Embora você possa habilitar o TLS 1.1 e o TLS 1.0 para compatibilidade com versões anteriores, recomendamos que você use uma versão mínima do TLS 1.2.
TLS 1.1 e TLS 1.0
O TLS 1.1 e o TLS 1.0 são considerados protocolos herdados e deixaram de ser considerados seguros. Essas versões têm suporte no Serviço de Aplicativo apenas para compatibilidade com versões anteriores e devem ser evitadas quando possível. A versão mínima padrão do TLS para novos aplicativos é TLS 1.2 e recomendamos que você migre aplicativos que usam TLS 1.1 ou TLS 1.0.
Importante
As solicitações de entrada para os aplicativos Web e as solicitações de entrada para o Azure são tratadas de maneira diferente. O Serviço de Aplicativo continua dando suporte ao TLS 1.1 e TLS 1.0 nas solicitações de entrada para os aplicativos Web.
Para solicitações de entrada feitas diretamente no plano de controle do Azure, por exemplo, por meio do Azure Resource Manager ou chamadas à API, recomendamos que você não use o TLS 1.1 ou o TLS 1.0.
Conjunto mínimo de criptografias TLS
Observação
A configuração do Conjunto mínimo de criptografias TLS tem suporte em SKUs básicas ou superiores no Serviço de Aplicativo multilocatário.
O conjunto mínimo de criptografias TLS inclui uma lista fixa de conjuntos de criptografias com uma ordem de prioridade ideal que não pode ser alterada. Reordenar ou redefinir a prioridade dos conjuntos de criptografias não é recomendado, pois pode expor seus aplicativos Web a uma criptografia mais fraca. Você também não pode adicionar conjuntos de criptografias diferentes ou novos a essa lista. Quando você seleciona um conjunto mínimo de criptografias, o sistema desabilita automaticamente todos os conjuntos de criptografias menos seguros para seu aplicativo Web. Você não pode desabilitar seletivamente apenas alguns conjuntos de criptografias mais fracos.
O que são conjuntos de criptografias e como funcionam no Serviço de Aplicativo?
Um conjunto de criptografias é um conjunto de instruções que contém algoritmos e protocolos para ajudar a proteger conexões de rede entre clientes e servidores. Por padrão, o sistema operacional do front-end escolhe o conjunto de criptografias mais seguro compatível com o Serviço de Aplicativo e o cliente. No entanto, se o cliente oferecer suporte apenas a conjuntos de criptografias fracos, o sistema operacional do front-end vai escolher um conjunto de criptografias fraco. Se sua organização tiver restrições sobre quais conjuntos de criptografias são permitidos, você poderá atualizar a propriedade do conjunto mínimo de criptografias TLS do seu aplicativo Web para garantir que os conjuntos de criptografias fracos sejam desabilitados para seu aplicativo Web.
Ambiente do Serviço de Aplicativo com configuração de cluster FrontEndSSLCipherSuiteOrder
Para Ambientes do Serviço de Aplicativo que têm a configuração de cluster FrontEndSSLCipherSuiteOrder
definida, atualize suas configurações para incluir os dois conjuntos de criptografias TLS 1.3:
TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
Depois de atualizar a configuração do cluster, você deve reiniciar o front-end para que as alterações entrem em vigor. Além disso, você ainda deve incluir os dois conjuntos de criptografias necessários descritos anteriormente, mesmo quando você atualizar para dar suporte ao TLS 1.3. Se você já usar FrontEndSSLCipherSuiteOrder
, recomendamos que você também não habilite o conjunto mínimo de criptografias TLS para seu aplicativo Web. O resultado pode ser configurações conflitantes. Configure apenas uma dessas opções para gerenciar as preferências do conjunto de criptografias.
Criptografia TLS de ponta a ponta
A criptografia TLS de ponta a ponta (E2E) garante que a comunicação de front-end para o trabalho no Serviço de Aplicativo do Azure seja criptografada usando O TLS. Sem esse recurso, enquanto as solicitações HTTPS de entrada são criptografadas para os front-ends, o tráfego de front-ends para os trabalhos que executam as cargas de trabalho do aplicativo percorreria sem criptografia a infraestrutura do Azure.
O TLS de E2E ajuda a garantir a criptografia completa do tráfego entre:
- Front-ends de Clientes e Serviço de Aplicativo
- Front-ends do Serviço de Aplicativo e processos de trabalho que hospedam o aplicativo
Esse recurso está disponível em:
- Planos do Serviço de Aplicativo Premium (recomendados para novas implantações)
- Planos do Serviço de Aplicativo Standard Herdado (usuários existentes)
Importante
Planos Premium são recomendados para novas implantações que exigem criptografia de E2E e outros recursos de segurança avançados.
Habilitar a criptografia TLS de ponta a ponta
Você pode habilitar a criptografia TLS de E2E por meio de:
- Configurações do portal do Azure
- Comandos da CLI do Azure
- Modelos do ARM para automação
Depois de habilitar a criptografia TLS de E2E, todas as comunicações intracluster para seu aplicativo Web são criptografadas usando o TLS, garantindo a proteção de dados de ponta a ponta.
Certificados TLS/SSL no Serviço de Aplicativo
Para atender ao tráfego HTTPS, o Serviço de Aplicativo requer um certificado TLS/SSL associado ao seu domínio personalizado. O Serviço de Aplicativo oferece várias opções de certificado, desde certificados gratuitos totalmente gerenciados até certificados gerenciados pelo cliente.
Tipos de certificados
Certificados gerenciados do Serviço de Aplicativo (Gratuito)
- Fornecido sem custo.
- Totalmente gerenciado pelo Serviço de Aplicativo do Azure, incluindo a renovação automática.
- Os clientes não podem acessar, exportar ou usar esses certificados fora do Serviço de Aplicativo.
- Não dá suporte a caracteres curinga ou CAs raiz personalizadas.
Certificados do Serviço de Aplicativo (ASC)
- Certificados pagos emitidos pelo GoDaddy.
- O cliente possui e gerencia o certificado.
- Armazenado no KV (Cofre de Chaves) do cliente e pode ser exportado e usado fora do Serviço de Aplicativo.
Traga seu próprio certificado (BYOC)
- Carregue e gerencie seus próprios certificados TLS/SSL (formato PFX).
- Totalmente gerenciado pelo cliente.
Cada uma dessas opções fornece flexibilidade com base em suas necessidades de segurança e gerenciamento.
Associar certificados a domínios personalizados
Depois de carregar ou criar um certificado, você o associa a um domínio personalizado em seu aplicativo Web usando:
- Associações SSL SNI (Indicação de Nome de Servidor) para hospedagem multilocatário
- Associações SSL de IP para endereços IP dedicados
Observação
Domínios gerenciados pelo Azure (como *.azurewebsites.net
) são protegidos automaticamente com certificados padrão, portanto, nenhuma configuração adicional é necessária.
Autenticação TLS mútua (mTLS)
O Serviço de Aplicativo do Azure dá suporte a TLS mútuo (mTLS) em planos do Serviço de Aplicativo do Linux e do Windows App, para que os aplicativos possam exigir certificados de cliente para maior segurança.
Como o mTLS funciona
- Os clientes apresentam certificados validados em uma cadeia de autoridade de certificação confiável que você configura.
- Apenas os clientes com certificados válidos podem se conectar.
- Normalmente, ele é usado para proteger APIs e aplicativos internos.
Opções de configuração
- Habilite o mTLS usando o portal do Azure, a CLI do Azure ou os modelos do ARM.
- Carregue certificados de AC confiáveis para validação do cliente.
- Acesse informações de certificado do cliente no código do aplicativo por meio de cabeçalhos de solicitação.
Gerenciamento automático de certificados
O Serviço de Aplicativo do Azure fornece recursos internos para gerenciar certificados automaticamente:
Certificados gerenciados do Serviço de Aplicativo (grátis). Emitido e renovado automaticamente para domínios personalizados. Esses certificados são limitados à validação básica de domínio e não dão suporte a certificados curinga ou exportáveis.
Certificados do Serviço de Aplicativo (pagos). Certificados totalmente gerenciados que dão suporte a cenários avançados, incluindo domínios curinga e certificados exportáveis. Esses certificados são armazenados e gerenciados no Azure Key Vault.
O Serviço de Aplicativo do Azure facilita a proteção dos seus aplicativos Web usando TLS e SSL. Com suporte para versões modernas do TLS, opções de certificado flexíveis e recursos avançados, como TLS mútuo, o Serviço de Aplicativo ajuda você a proteger dados em trânsito e atender aos requisitos de conformidade.