Compartilhar via


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 melhores práticas de segurança que outros aplicativos.

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

  • Java SE – pode executar um aplicativo implantado como um pacote JAR que contém um servidor inserido (como Spring Boot, Dropwizard, Quarkus ou um com um servidor Tomcat ou Jetty inserido).
  • Tomcat – O servidor Tomcat interno pode executar um aplicativo implantado como um pacote WAR.
  • JBoss EAP: Suporte apenas para aplicativos Linux nos níveis de preços Gratuito, Premium v3 e Isolado v2. O servidor JBoss EAP interno pode executar um aplicativo implantado como um pacote WAR ou EAR.

Observação

Para aplicativos Spring, é recomendável usar o Aplicativos Spring do Azure. No entanto, você ainda pode usar o Serviço de Aplicativo do Azure como um destino. Consulte Diretrizes de Destino da Carga de Trabalho Java para obter orientação.

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. A partir daí, você pode habilitar a autenticação usando o Microsoft Entra ID ou credenciais de redes sociais, como Facebook, Google ou GitHub. A configuração do portal do Azure só funciona ao configurar um único provedor de autenticação. Para obter mais informações, confira Configurar seu aplicativo do Serviço de Aplicativo para usar a entrada do Microsoft Entra e os artigos relacionados para outros provedores de identidade. Caso precise habilitar vários provedores de entrada, siga as instruções em Personalizar entradas e saídas.

Os desenvolvedores do Spring Boot podem usar o inicializador do Microsoft Entra Spring Boot para proteger aplicativos usando anotações e APIs familiares do Spring Security. Lembre-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 trecho 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 na interface HttpServletRequest do Tomcat e seus métodos. Os seguintes métodos de servlet também são hidratados com base na sua 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 JBoss EAP, confira a guia Tomcat.

Configurar 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 de Key Vault

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

Primeiro, siga as instruções para conceder ao seu aplicativo acesso a um cofre de chaves e fazer uma referência do KeyVault ao seu segredo em uma Configuração do 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, confira esta documentação sobre configurações externas.

Para injetar esses segredos em seu arquivo de configuração 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 do Linux são carregados nos respectivos repositório de chaves do Java quando o contêiner for 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 JDBC com certificados no repositório de chaves do Java. Confira a documentação para o driver JDBC escolhido.

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 Java Key Tool abrindo uma conexão SSH no seu Serviço de Aplicativo e executando o comando keytool. Confira a documentação da Key Tool para obter uma lista de comandos. Para obter mais informações sobre a API KeyStore, confira a documentação oficial.

Próximas etapas

Acesse a central para Desenvolvedores do Azure para Java para conferir inícios rápidos, tutoriais e documentação de referência do Java.