Migrar um aplicativo para usar conexões sem senha com o Banco de Dados do Azure para PostgreSQL

Este artigo explica como migrar de métodos de autenticação tradicionais para conexões mais seguras e sem senha com o Banco de Dados do Azure para PostgreSQL.

As solicitações de aplicativo para o Banco de Dados do Azure para PostgreSQL devem ser autenticadas. O Banco de Dados do Azure para PostgreSQL fornece várias maneiras diferentes para os aplicativos se conectarem com segurança. Uma das maneiras é usar senhas. No entanto, você deve priorizar conexões sem senha em seus aplicativos quando possível.

Comparar opções de autenticação

Quando o aplicativo se autentica com o Banco de Dados do Azure para PostgreSQL, ele fornece um par de nome de usuário e senha para conectar o banco de dados. Dependendo de onde as identidades são armazenadas, existem dois tipos de autenticação: autenticação Microsoft Entra e autenticação PostgreSQL.

Autenticação do Microsoft Entra

A autenticação do Microsoft Entra é um mecanismo para se conectar ao Banco de Dados do Azure para PostgreSQL usando identidades definidas na ID do Microsoft Entra. Ao utilizar a autenticação Microsoft Entra, pode gerir as identidades dos utilizadores da base de dados e outros serviços serviços Microsoft numa localização central, o que simplifica a gestão de permissões.

Usar o Microsoft Entra ID para autenticação oferece os seguintes benefícios:

  • Autenticação de usuários nos Serviços do Azure de maneira uniforme.
  • Gerenciamento de políticas de senhas e rotação de senhas em um único lugar.
  • Várias formas de autenticação suportadas pelo Microsoft Entra ID, que podem eliminar a necessidade de armazenar senhas.
  • Os clientes podem gerir permissões de base de dados utilizando grupos externos (Microsoft Entra ID).
  • Utilize utilizadores da base de dados PostgreSQL através da autenticação Microsoft Entra para autenticar identidades ao nível da base de dados.
  • Suporta autenticação baseada em tokens para aplicações que se ligam ao Base de Dados do Azure para PostgreSQL.

Autenticação PostgreSQL

Você pode criar contas em PostgreSQL. Se optar por usar palavras-passe como credenciais para as contas, armazene essas credenciais na user tabela. Como o PostgreSQL armazena estas palavras-passe, tens de gerir tu próprio a rotação das palavras-passe.

Embora possa ligar-se ao Base de Dados do Azure para PostgreSQL com palavras-passe, use-as com cautela. Nunca exponha as palavras-passe num local inseguro. Qualquer pessoa que tenha acesso às palavras-passe pode autenticar-se. Por exemplo, um utilizador malicioso pode aceder à aplicação se verificar acidentalmente uma cadeia de ligação no controlo de versão, enviá-la por um email inseguro, colá-la no chat errado, ou se alguém sem permissão a visualizar. Em vez disso, considere atualizar seu aplicativo para usar conexões sem senha.

Introdução a ligações sem palavra-passe

Com uma conexão sem senha, você pode se conectar aos serviços do Azure sem armazenar credenciais no código do aplicativo, em seus arquivos de configuração ou em variáveis de ambiente.

Muitos serviços do Azure suportam ligações sem palavra-passe, por exemplo, através da Identidade Gerida do Azure. Essas técnicas fornecem recursos de segurança robustos que você pode implementar usando DefaultAzureCredential das bibliotecas de cliente do Azure Identity. Neste tutorial, você aprenderá como atualizar um aplicativo existente para usar DefaultAzureCredential em vez de alternativas, como cadeias de conexão.

DefaultAzureCredential suporta vários métodos de autenticação e determina automaticamente quais devem ser usados em tempo de execução. Essa abordagem permite que seu aplicativo use métodos de autenticação diferentes em ambientes diferentes (desenvolvimento local versus produção) sem implementar código específico do ambiente.

A ordem e os locais onde DefaultAzureCredential pesquisa credenciais podem ser consultados na visão geral da biblioteca de identidade do Azure. Por exemplo, ao trabalhar localmente, DefaultAzureCredential geralmente autenticará usando a conta que o desenvolvedor usou para entrar no Visual Studio. Quando o aplicativo for implantado no Azure, DefaultAzureCredential alternará automaticamente para usar uma identidade gerenciada. Não são necessárias alterações de código para esta transição.

Para garantir que as conexões não tenham senha, você deve levar em consideração o desenvolvimento local e o ambiente de produção. Se uma cadeia de conexão for necessária em qualquer lugar, o aplicativo não será sem senha.

Em seu ambiente de desenvolvimento local, você pode autenticar com a CLI do Azure, Azure PowerShell, Visual Studio ou plug-ins do Azure para Visual Studio Code ou IntelliJ. Nesse caso, você pode usar essa credencial em seu aplicativo em vez de configurar propriedades.

Ao implantar aplicativos em um ambiente de hospedagem do Azure, como uma máquina virtual, você pode atribuir identidade gerenciada nesse ambiente. Em seguida, você não precisará fornecer credenciais para se conectar aos serviços do Azure.

Observação

Uma identidade gerenciada fornece uma identidade de segurança para representar um aplicativo ou serviço. A identidade é gerenciada pela plataforma Azure e não exige que você provisione ou alterne nenhum segredo. Você pode ler mais sobre identidades gerenciadas na documentação de visão geral .

Migrar um aplicativo existente para usar conexões sem senha

As etapas a seguir explicam como migrar um aplicativo existente para usar conexões sem senha em vez de uma solução baseada em senha.

0) Preparar o ambiente de trabalho

Primeiro, use o seguinte comando para configurar algumas variáveis de ambiente.

export AZ_RESOURCE_GROUP=<YOUR_RESOURCE_GROUP>
export AZ_DATABASE_SERVER_NAME=<YOUR_DATABASE_SERVER_NAME>
export AZ_DATABASE_NAME=demo
export AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME=<YOUR_AZURE_AD_NON_ADMIN_USER_DISPLAY_NAME>
export AZ_LOCAL_IP_ADDRESS=<YOUR_LOCAL_IP_ADDRESS>
export CURRENT_USERNAME=$(az ad signed-in-user show --query userPrincipalName --output tsv)

Substitua os marcadores de posição pelos seguintes valores, que são utilizados ao longo deste artigo.

  • <YOUR_RESOURCE_GROUP>: O nome do grupo de recursos para os teus recursos.
  • <YOUR_DATABASE_SERVER_NAME>: O nome do seu servidor PostgreSQL. Deve ser único em todo o Azure.
  • <YOUR_AZURE_AD_NON_ADMIN_USER_DISPLAY_NAME>: O nome para exibição do seu utilizador não administrador do Microsoft Entra. Certifique-se de que o nome corresponde a um utilizador válido no seu inquilino Microsoft Entra.
  • <YOUR_LOCAL_IP_ADDRESS>: O endereço IP do seu computador local, a partir do qual executa a sua aplicação Spring Boot. Uma maneira conveniente de encontrá-lo é abrir whatismyip.akamai.com.

1) Configurar o Banco de Dados do Azure para PostgreSQL

1.1) Ativar a autenticação baseada em ID do Microsoft Entra

Para usar o acesso ao Microsoft Entra ID com o Base de Dados do Azure para PostgreSQL, defina primeiro o utilizador administrador do Microsoft Entra. Só um utilizador administrador da Microsoft Entra pode criar ou habilitar utilizadores para autenticação baseada no Microsoft Entra ID.

Para configurar um administrador do Microsoft Entra depois de criar o servidor, siga as etapas em Gerenciar funções do Microsoft Entra no Banco de Dados do Azure para PostgreSQL - Servidor Flexível.

Observação

O PostgreSQL Flexible Server pode criar vários administradores do Microsoft Entra.

2) Configurar o Banco de Dados do Azure para PostgreSQL para desenvolvimento local

2.1) Configurar uma regra de firewall para IP local

As instâncias do Banco de Dados do Azure para PostgreSQL são protegidas por padrão. Eles têm um firewall que não permite nenhuma conexão de entrada. Para usar a tua base de dados, precisas de adicionar uma regra de firewall que permita ao teu endereço IP local aceder ao servidor de base de dados.

Como você configurou seu endereço IP local no início deste artigo, você pode abrir o firewall do servidor executando o seguinte comando:

az postgres flexible-server firewall-rule create \
    --resource-group $AZ_RESOURCE_GROUP \
    --name $AZ_DATABASE_SERVER_NAME \
    --rule-name $AZ_DATABASE_SERVER_NAME-database-allow-local-ip \
    --start-ip-address $AZ_LOCAL_IP_ADDRESS \
    --end-ip-address $AZ_LOCAL_IP_ADDRESS \
    --output tsv

Se você estiver se conectando ao seu servidor PostgreSQL a partir do Subsistema Windows para Linux (WSL) em um computador Windows, precisará adicionar o ID do host WSL ao firewall.

Obtenha o endereço IP da sua máquina anfitriã executando o seguinte comando em WSL:

cat /etc/resolv.conf

Copie o endereço IP após o termo nameserver, e depois use o seguinte comando para definir uma variável de ambiente para o Endereço IP WSL:

export AZ_WSL_IP_ADDRESS=<the-copied-IP-address>

Em seguida, use o seguinte comando para abrir o firewall do servidor para seu aplicativo baseado em WSL:

az postgres flexible-server firewall-rule create \
    --resource-group $AZ_RESOURCE_GROUP \
    --name $AZ_DATABASE_SERVER_NAME \
    --rule-name $AZ_DATABASE_SERVER_NAME-database-allow-local-ip \
    --start-ip-address $AZ_WSL_IP_ADDRESS \
    --end-ip-address $AZ_WSL_IP_ADDRESS \
    --output tsv

2.2) Criar um usuário não-administrador do PostgreSQL e conceder permissão

Em seguida, crie um usuário não administrador do Microsoft Entra e conceda todas as permissões no $AZ_DATABASE_NAME banco de dados a ele. Você pode alterar o nome $AZ_DATABASE_NAME do banco de dados para atender às suas necessidades.

Crie um script SQL chamado create_ad_user_local.sql para criar um usuário não administrador. Adicione o seguinte conteúdo e salve-o localmente:

cat << EOF > create_ad_user_local.sql
select * from pgaadauth_create_principal('$AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME', false, false);
EOF

Depois, use o seguinte comando para executar o script SQL e criar o utilizador não administrador da Microsoft Entra:

psql "host=$AZ_DATABASE_SERVER_NAME.postgres.database.azure.com user=$CURRENT_USERNAME dbname=postgres port=5432 password=$(az account get-access-token --resource-type oss-rdbms --output tsv --query accessToken) sslmode=require" < create_ad_user_local.sql

Agora, use o seguinte comando para remover o ficheiro de script SQL temporário:

rm create_ad_user_local.sql

Observação

Para mais informações sobre como criar utilizadores PostgreSQL, consulte Criar utilizadores no Base de Dados do Azure para PostgreSQL.

3) Entre e migre o código do aplicativo para usar conexões sem senha

Para desenvolvimento local, certifique-se de que está autenticado com a mesma conta Microsoft Entra a que atribuiu a função no seu PostgreSQL. Autentique através do CLI do Azure, Visual Studio, Azure PowerShell ou outras ferramentas como o IntelliJ.

Entre no Azure por meio da CLI do Azure usando o seguinte comando:

az login

Em seguida, use as etapas a seguir para atualizar seu código para usar conexões sem senha. Embora conceitualmente semelhante, cada linguagem usa detalhes de implementação diferentes.

  1. Dentro do seu projeto, adicione a seguinte referência ao azure-identity-extensions pacote. Esta biblioteca contém todas as entidades necessárias para implementar conexões sem senha.

    <dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-identity-extensions</artifactId>
    <version>1.0.0</version>
</dependency>

  2. Habilite o plug-in de autenticação do Azure PostgreSQL na URL JDBC. Identifique os locais em seu código que atualmente criam um java.sql.Connection para se conectar ao Banco de Dados do Azure para PostgreSQL. Atualize url e user no arquivo application.properties para corresponder aos seguintes valores:

    url=jdbc:postgresql://$AZ_DATABASE_SERVER_NAME.postgres.database.azure.com:5432/$AZ_DATABASE_NAME?sslmode=require&authenticationPluginClassName=com.azure.identity.extensions.jdbc.postgresql.AzurePostgresqlAuthenticationPlugin
user=$AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME

  3. Substitua as $AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME e as duas $AZ_DATABASE_SERVER_NAME variáveis pelo valor que você configurou no início deste artigo.

Execute o aplicativo localmente

Depois de fazer essas alterações de código, execute seu aplicativo localmente. A nova configuração recolhe as suas credenciais locais se tiver sessão iniciada num IDE compatível ou numa ferramenta de linha de comandos compatível, como o CLI do Azure, o Visual Studio ou o IntelliJ. Os papéis que atribuíste ao teu utilizador local de desenvolvimento no Azure permitem que a tua aplicação se ligue ao serviço Azure localmente.

4) Configurar o ambiente de hospedagem do Azure

Depois de configurar a sua aplicação para usar ligações sem palavra-passe e executá-la localmente, o mesmo código pode autenticar-se nos serviços do Azure depois de o implementar no Azure. Por exemplo, um aplicativo implantado em uma instância do Serviço de Aplicativo do Azure que tenha uma identidade gerenciada atribuída pode se conectar ao Armazenamento do Azure.

Nesta secção, executa dois passos para permitir que a sua aplicação corra num ambiente de alojamento Azure de forma sem palavra-passe:

  • Atribua a identidade gerenciada para seu ambiente de hospedagem do Azure.
  • Atribua funções à identidade gerenciada.

Observação

O Azure também fornece o Service Connector, que pode ajudá-lo a conectar seu serviço de hospedagem ao PostgreSQL. Ao usar o Service Connector para configurar o seu ambiente de alojamento, pode omitir o passo de atribuir funções à sua identidade gerida porque o Service Connector os atribui por si. A seção a seguir descreve como configurar seu ambiente de hospedagem do Azure de duas maneiras: uma por meio do Service Connector e outra configurando cada ambiente de hospedagem diretamente.

Importante

Os comandos do Service Connector exigem a CLI do Azure 2.41.0 ou superior.

Atribuir a identidade gerenciada usando o portal do Azure

As etapas a seguir mostram como atribuir uma identidade gerenciada atribuída ao sistema para vários serviços de hospedagem na Web. A identidade gerida pode ligar-se de forma segura a outros serviços do Azure usando as configurações da aplicação que configurou anteriormente.

  1. Na página de visão geral principal da sua instância do Serviço de Aplicativo do Azure, selecione Identidade no painel de navegação.

  2. Na guia Sistema atribuído , certifique-se de definir o campo Status como ativado. Uma identidade atribuída ao sistema é gerenciada pelo Azure internamente e lida com tarefas administrativas para você. Os detalhes e IDs da identidade nunca são expostos no seu código.

Também pode atribuir uma identidade gerida num ambiente de alojamento Azure usando a CLI do Azure.

Você pode atribuir uma identidade gerenciada a uma instância do Serviço de Aplicativo do Azure com o comando az webapp identity assign , conforme mostrado no exemplo a seguir:

export AZ_MI_OBJECT_ID=$(az webapp identity assign \
    --resource-group $AZ_RESOURCE_GROUP \
    --name <service-instance-name> \
    --query principalId \
    --output tsv)

Atribuir funções à identidade gerenciada

Em seguida, conceda permissões à identidade gerenciada que você atribuiu para acessar sua instância do PostgreSQL.

Se ligaste os teus serviços usando o Service Connector, os comandos do passo anterior já atribuíram o papel, por isso podes saltar este passo.

Testar a aplicação

Antes de implementar a aplicação no ambiente de alojamento, precisa de fazer mais uma alteração no código porque a aplicação liga-se ao PostgreSQL usando o utilizador que criou para a identidade gerida.

Atualize seu código para usar o usuário criado para a identidade gerenciada:

Observação

Se você usou o comando Service Connector, ignore esta etapa.

properties.put("user", "$AZ_POSTGRESQL_AD_MI_USERNAME");

Depois de fazer essas alterações de código, você pode criar e reimplantar o aplicativo. Em seguida, navegue até o aplicativo hospedado no navegador. Seu aplicativo deve ser capaz de se conectar ao banco de dados PostgreSQL com êxito. Pode demorar vários minutos até que as atribuições de funções se propaguem pelo teu ambiente Azure. Seu aplicativo agora está configurado para ser executado localmente e em um ambiente de produção sem que os desenvolvedores tenham que gerenciar segredos no próprio aplicativo.

Próximos passos

Neste tutorial, você aprendeu como migrar um aplicativo para conexões sem senha.

Para explorar os conceitos discutidos neste artigo com mais profundidade, consulte os seguintes recursos:

  • Last updated on