Configurar a segurança de um aplicativo Tomcat, JBoss ou Java SE no Serviço de Aplicativo do Azure

Este artigo mostra como definir as configurações de segurança específicas do Java no Serviço de Aplicativo. Os aplicativos Java em execução no Serviço de Aplicativo têm o mesmo conjunto de práticas recomendadas de segurança que outros aplicativos.

O Serviço de Aplicativo do Azure executa aplicativos Web Java em um serviço totalmente gerenciado em três variantes:

• Java Standard Edition (SE): pode executar um aplicativo implantado como um pacote JAR (Arquivo Java) que contém um servidor inserido (como Spring Boot, Quarkus, Dropwizard ou um aplicativo com um servidor Tomcat ou Jetty inserido).
• Tomcat: O servidor Tomcat interno pode executar um aplicativo implantado como um pacote WAR (Arquivo de Aplicativo Web).
• JBoss Enterprise Application Platform (EAP): o servidor JBoss EAP integrado pode executar um aplicativo implantado como um pacote WAR ou Arquivo Empresarial (EAR). Com suporte para aplicativos Linux em um conjunto de tipos de preços que inclui Gratuito, Premium v3 e Isolado v2.gti

Autenticar usuários (autenticação fácil)

Configure a autenticação de aplicativo no portal do Azure com a opção Autenticação e Autorização . Nele, você pode habilitar a autenticação usando o Microsoft Entra ID ou as credenciais de redes sociais, como o Facebook, o Google ou o GitHub. A configuração do portal do Azure só funciona ao configurar um provedor de autenticação individual. Para obter mais informações, consulte Configurar seu aplicativo do Serviço de Aplicativo para usar o login do Microsoft Entra e os artigos relacionados para outros provedores de identidade. Se você precisar habilitar vários provedores de entrada, siga as instruções em Personalizar entradas e saídas.

Os desenvolvedores do Spring Boot podem usar o início do Microsoft Entra Spring Boot para proteger aplicativos usando anotações e APIs familiares do Spring Security. Certifique-se de aumentar o tamanho máximo do cabeçalho no arquivo application.properties . Sugerimos um valor igual a 16384.

Seu aplicativo Tomcat pode acessar as declarações do usuário diretamente do servlet, convertendo o objeto Principal em um objeto Map. O objeto Map mapeia cada tipo de declaração para uma coleção de declarações para esse tipo. No exemplo de código a seguir, request há uma instância de HttpServletRequest.

Map<String, Collection<String>> map = (Map<String, Collection<String>>) request.getUserPrincipal();

Agora você pode inspecionar o objeto Map para qualquer declaração específica. Por exemplo, o snippet de código a seguir itera todos os tipos de declaração e imprime o conteúdo de cada coleção.

for (Object key : map.keySet()) {
        Object value = map.get(key);
        if (value != null && value instanceof Collection {
            Collection claims = (Collection) value;
            for (Object claim : claims) {
                System.out.println(claims);
            }
        }
    }

Para desconectar os usuários, use o caminho /.auth/ext/logout. Para executar outras ações, consulte a documentação sobre Personalizar entradas e saídas. Também há documentação oficial sobre a interface Tomcat HttpServletRequest e seus métodos. Os seguintes métodos de servlet também são hidratados com base na configuração do Serviço de Aplicativo:

public boolean isSecure()
public String getRemoteAddr()
public String getRemoteHost()
public String getScheme()
public int getServerPort()

Para desabilitar esse recurso, crie uma Configuração de Aplicativo chamada WEBSITE_AUTH_SKIP_PRINCIPAL com um valor de 1. Para desabilitar todos os filtros de servlet adicionados pelo Serviço de Aplicativo, crie uma configuração chamada WEBSITE_SKIP_FILTERS com um valor 1.

Para o JBoss EAP, veja a guia Tomcat.

Configurar o TLS/SSL

Para carregar um certificado TLS/SSL existente e associá-lo ao nome de domínio do aplicativo, siga as instruções em Proteger um nome DNS personalizado com uma associação TLS/SSL no Serviço de Aplicativo do Azure. Também é possível configurar o aplicativo para impor o TLS/SSL.

Usar referências do Key Vault

O Azure KeyVault fornece gerenciamento centralizado de segredos com políticas de acesso e histórico de auditoria. Você pode armazenar segredos (como senhas ou cadeias de conexão) no Key Vault e acessar esses segredos no seu aplicativo por meio de variáveis de ambiente.

Primeiro, siga as instruções para conceder acesso ao aplicativo a um cofre de chaves e fazer uma referência do KeyVault ao seu segredo em uma Configuração de Aplicativo. Você pode validar que a referência seja resolvida no segredo imprimindo a variável de ambiente enquanto acessa remotamente o terminal do Serviço de Aplicativo.

Para arquivos de configuração do Spring, consulte esta documentação sobre configurações externalizadas.

Para injetar esses segredos no arquivo de configuração do Spring, use a sintaxe de injeção de variável de ambiente (${MY_ENV_VAR}).

Para injetar esses segredos em seu arquivo de configuração Tomcat, use a sintaxe de injeção de variável de ambiente (${MY_ENV_VAR}).

Usar o repositório de chaves Java no Linux

Por padrão, todos os certificados públicos ou privados carregados no Serviço de Aplicativo Linux são carregados nos respectivos repositórios de chaves Java à medida que o contêiner é iniciado. Após carregar seu certificado, você precisará reiniciar o Serviço de Aplicativo para que ele seja carregado no repositório de chaves Java. Os certificados públicos são carregados no repositório de chaves em $JRE_HOME/lib/security/cacerts e os certificados privados são armazenados em $JRE_HOME/lib/security/client.jks.

Mais configurações podem ser necessárias para criptografar sua conexão do JDBC com os certificados no repositório de chaves do Java. Veja a documentação para o driver JDBC escolhido.

• PostgreSQL
• SQL Server
• MongoDB
• Cassandra

Inicializar o repositório de chaves Java no Linux

Para inicializar o objeto import java.security.KeyStore, carregue o arquivo do repositório de chaves com a senha. A senha padrão para ambos os repositórios de chaves é changeit.

KeyStore keyStore = KeyStore.getInstance("jks");
keyStore.load(
    new FileInputStream(System.getenv("JRE_HOME")+"/lib/security/cacerts"),
    "changeit".toCharArray());

KeyStore keyStore = KeyStore.getInstance("pkcs12");
keyStore.load(
    new FileInputStream(System.getenv("JRE_HOME")+"/lib/security/client.jks"),
    "changeit".toCharArray());

Carregar manualmente o repositório de chaves no Linux

Você pode carregar certificados manualmente no repositório de chaves. Crie uma configuração de aplicativo, SKIP_JAVA_KEYSTORE_LOAD, com um valor de 1 para desabilitar o Serviço de Aplicativo do carregamento dos certificados no repositório de chaves automaticamente. Todos os certificados públicos carregados no Serviço de Aplicativo por meio do portal do Azure são armazenados em /var/ssl/certs/. Os certificados particulares são armazenados em /var/ssl/private/.

Você pode interagir ou depurar a Ferramenta de Chave Java abrindo uma conexão SSH ao Serviço de Aplicativo e rodando o comando keytool. Consulte a documentação da Ferramenta de Chave para obter uma lista de comandos. Para obter mais informações sobre a API keystore, consulte a documentação oficial.

Próximas etapas

Visite o centro de desenvolvedores do Azure para Java para encontrar guias de início rápido, tutoriais e documentação de referência do Java no Azure.

• Perguntas frequentes sobre o App Service no Linux
• Referência de variáveis de ambiente e configurações de aplicativo