Migrar um aplicativo para usar conexões sem senha com o Barramento de Serviço do Azure
As solicitações de aplicativo para o Barramento de Serviço do Azure devem ser autenticadas usando chaves de acesso de conta ou conexões sem senha. No entanto, você deve priorizar conexões sem senha em seus aplicativos quando possível. Este tutorial explora como migrar de métodos tradicionais de autenticação para conexões mais seguras e sem senha.
Riscos de segurança associados a chaves de acesso
O exemplo de código a seguir demonstra como se conectar ao Barramento de Serviço do Azure usando uma cadeia de conexão que inclui uma chave de acesso. Ao criar um Barramento de Serviço, o Azure gera essas chaves e cadeias de conexão automaticamente. Muitos desenvolvedores gravitam para essa solução porque se sentem confortáveis devido às opções com as quais trabalharam no passado. Se o seu aplicativo usa atualmente as cadeias de conexão, considere migrar para conexões sem senha usando as etapas descritas neste documento.
As cadeias de conexão devem ser usadas com cuidado. Os desenvolvedores devem ser diligentes para nunca expor as chaves em um local não seguro. Qualquer pessoa que tenha acesso à chave poderá se autenticar. Por exemplo, se uma chave de conta for verificada acidentalmente no controle do código-fonte, enviada por um email não seguro, colada no chat errado ou exibida por alguém que não deve ter permissão, há o risco de um usuário mal-intencionado acessar o aplicativo. Em vez disso, considere atualizar seu aplicativo para usar conexões sem senha.
Migrar para conexões sem senha
Muitos serviços do Azure dão suporte a conexões sem senha por meio do Microsoft Entra ID e do controle de acesso baseado em função (RBAC). Essas técnicas fornecem recursos de segurança robustos e podem ser implementadas usando DefaultAzureCredential
das bibliotecas de clientes do Azure Identity.
Importante
Algumas linguagens devem implementar DefaultAzureCredential
explicitamente no código, enquanto outras utilizam DefaultAzureCredential
internamente por meio de plug-ins ou drivers subjacentes.
DefaultAzureCredential
dá suporte a vários métodos de autenticação e determina automaticamente quais devem ser usados no runtime. Essa abordagem permite que seu aplicativo use diferentes métodos de autenticação em ambientes diferentes (desenvolvimento local versus produção) sem implementar código específico do ambiente.
A ordem e os locais nos quais DefaultAzureCredential
pesquisa as credenciais podem ser encontrados na visão geral da biblioteca de Identidades do Azure e variam entre as linguagens. Por exemplo, ao trabalhar localmente com o .NET, DefaultAzureCredential
geralmente será autenticada usando a conta que o desenvolvedor usou para entrar no Visual Studio, CLI do Azure ou Azure PowerShell. Quando o aplicativo for implantado no Azure, DefaultAzureCredential
descobrirá e usará automaticamente a identidade gerenciada do serviço de hospedagem associado, como Serviço de Aplicativo do Azure. Nenhuma alteração de código é necessária para essa transição.
Observação
Uma identidade gerenciada fornece uma identidade de segurança para representar um aplicativo ou serviço. A identidade é gerenciada pela plataforma do Azure e não exige provisionamento ou giro de nenhum segredo. Você pode ler mais sobre identidades gerenciadas na documentação de visão geral.
O exemplo de código a seguir demonstra como se conectar ao Barramento de Serviço usando conexões sem senha. A próxima seção descreve como migrar para essa configuração para um serviço específico com mais detalhes.
Um aplicativo .NET pode aprovar uma instância de DefaultAzureCredential
para o construtor de uma classe de cliente de serviço. DefaultAzureCredential
descobrirá automaticamente as credenciais disponíveis nesse ambiente.
client = new ServiceBusClient(
"<NAMESPACE-NAME>.servicebus.windows.net",
new DefaultAzureCredential());
Etapas para migrar um aplicativo para usar a autenticação 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 chave. Primeiro, você configurará um ambiente de desenvolvimento local e aplicará esses conceitos a um ambiente de hospedagem de aplicativo do Azure. Essas mesmas etapas de migração devem ser aplicadas se você estiver usando chaves de acesso diretamente ou por meio de cadeias de conexão.
Configurar funções e usuários para autenticação de desenvolvimento local
Ao desenvolver localmente, verifique se a conta de usuário que está acessando o Barramento de Serviço tem as permissões corretas. Neste exemplo, você usará a função de Proprietário de Dados do Barramento de Serviço do Azure para enviar e receber dados, embora funções mais granulares também estejam disponíveis. Para atribuir essa função a si mesmo, você precisará receber a atribuição da função Administrador de Acesso do Usuário ou de outra função que inclua a ação Microsoft.Authorization/roleAssignments/write. É possível atribuir funções RBAC do Azure a um usuário usando o portal do Azure, a CLI do Azure ou o Azure PowerShell. Você pode saber mais sobre os escopos disponíveis para atribuições de função na página de visão geral do escopo.
Nesse cenário, você atribuirá permissões à sua conta de usuário, no escopo para um namespace específico do Barramento de Serviço, para seguir o Princípio do Privilégio Mínimo. Essa prática fornece aos usuários apenas as permissões mínimas necessárias e cria ambientes de produção mais seguros.
O exemplo a seguir atribuirá a função de Proprietário de Dados do Barramento de Serviço do Azure à sua conta de usuário, o que permite que você envie e receba dados.
Importante
Na maioria dos casos, levará um ou dois minutos para a atribuição de função se propagar no Azure, mas em casos raros pode levar até oito minutos. Se você receber erros de autenticação ao executar o código pela primeira vez, aguarde alguns instantes e tente novamente.
No portal do Azure, localize o namespace do Barramento de Serviço usando a barra de pesquisa principal ou a navegação à esquerda.
Na página de visão geral do Barramento de Serviço, selecione Controle de acesso (IAM) no menu à esquerda.
Na página Controle de acesso (IAM), selecione a guia Atribuições de função.
Selecione + Adicionar no menu superior e, em seguida, Adicionar atribuição de função no menu suspenso resultante.
Use a caixa de pesquisa para filtrar os resultados para a função desejada. Para este exemplo, pesquise o Proprietário de Dados do Barramento de Serviço do Azure e selecione o resultado correspondente e, em seguida, escolha Avançar.
Em Atribuir acesso a, selecione Usuário, grupo ou entidade de serviço e, em seguida, selecione + Selecionar membros.
No diálogo, pesquise seu nome de usuário do Microsoft Entra (geralmente seu endereço de email user@domain) e escolha Selecionar na parte inferior do diálogo.
Selecione Revisar + atribuir para ir para a página final e, em seguida, Revisar + atribuir novamente para concluir o processo.
Entrar e migrar o código do aplicativo para usar conexões sem senha
Para desenvolvimento local, verifique se você está autenticado com a mesma conta do Microsoft Entra à qual atribuiu a função para o namespace do Barramento de Serviço. Você pode autenticar por meio da CLI do Azure, visual Studio, Azure PowerShell ou outras ferramentas, como o IntelliJ.
Para desenvolvimento local, você deve estar autenticado com a mesma conta do Microsoft Entra à qual a função foi atribuída. Você pode autenticar por meio de ferramentas de desenvolvimento populares, como a CLI do Azure ou o Azure PowerShell. As ferramentas de desenvolvimento com as quais você pode autenticar variam entre os idiomas.
Entre no Azure por meio da CLI do Azure usando o seguinte comando:
az login
Em seguida, atualize seu código para usar conexões sem senha.
Para usar
DefaultAzureCredential
em um aplicativo .NET, instale o pacoteAzure.Identity
:dotnet add package Azure.Identity
Na parte superior do seu arquivo, adicione o código a seguir:
using Azure.Identity;
Identifique o código que cria um objeto
ServiceBusClient
para conexão com o Barramento de Serviço do Azure. Atualize o código para que ele corresponda ao seguinte exemplo:var serviceBusNamespace = $"{namespace}.servicebus.windows.net"; ServiceBusClient client = new( serviceBusNamespace, new DefaultAzureCredential());
Executar o aplicativo localmente
Depois de fazer essas alterações de código, execute seu aplicativo localmente. A nova configuração deve selecionar suas credenciais locais, como a CLI do Azure, o Visual Studio ou o IntelliJ. As funções atribuídas ao usuário de desenvolvimento local no Azure permitirão que seu aplicativo se conecte ao serviço do Azure localmente.
Configurar o ambiente de hospedagem do Azure
Depois que o aplicativo estiver configurado para usar conexões sem senha e for executado localmente, o mesmo código poderá ser autenticado nos serviços do Azure depois de implantado no Azure. Por exemplo, um aplicativo implantado em uma instância de Serviço de Aplicativo do Azure que tenha uma identidade gerenciada habilitada pode se conectar ao Barramento de Serviço do Azure.
Habilitar a identidade gerenciada usando o portal do Azure
As etapas a seguir demonstram como criar uma identidade gerenciada atribuída pelo sistema para vários serviços de hospedagem na Web. A identidade gerenciada pode se conectar com segurança a outros Serviços do Azure usando as configurações de aplicativo que você configurou anteriormente.
- Conector do Serviço
- Serviço de Aplicativo do Azure
- Azure Spring Apps
- Aplicativos de Contêiner do Azure
- Máquinas Virtuais do Azure
Alguns ambientes de hospedagem de aplicativos dão suporte ao Conector de Serviço, o que ajuda a conectar os serviços de computação do Azure a outros serviços de suporte. O Conector de Serviço define automaticamente as configurações de rede e as informações de conexão. Você pode saber mais sobre o Conector de Serviço e quais cenários têm suporte na página de visão geral.
Atualmente, há suporte para os seguintes serviços de computação:
- Serviço de aplicativo do Azure
- Azure Spring Cloud
- Aplicativos de Contêiner do Azure (versão prévia)
Para este guia de migração, você usará o Serviço de Aplicativo, mas as etapas são semelhantes nos Aplicativos Spring do Azure e nos Aplicativos de Contêiner do Azure.
Observação
Atualmente, o Azure Spring Apps dá suporte apenas ao Service Connector usando cadeias de conexão.
Na página de visão geral principal do Serviço de Aplicativo, selecione Conector de serviço na navegação à esquerda.
Selecione + Criar no menu superior e o painel Criar conexão será aberto. Insira os valores a seguir:
- Tipo de serviço: escolha Barramento de serviço.
- Assinatura: selecione a assinatura que você deseja usar.
- Nome da conexão: insira um nome para sua conexão, como connector_appservice_servicebus.
- Tipo de cliente: deixe o valor padrão selecionado ou escolha o cliente específico que você deseja usar.
Selecione Próximo: Autenticação.
Verifique se a identidade gerenciada atribuída pelo sistema (Recomendado) está selecionada e escolha Avançar: Rede.
Deixe os valores padrão selecionados e escolha Avançar: Examinar + Criar.
Depois que o Azure validar suas configurações, selecione Criar.
O Conector de serviço criará automaticamente uma identidade gerenciada atribuída pelo sistema para o serviço de aplicativo. O conector também atribuirá à identidade gerenciada uma função de Proprietário de Dados do Barramento de Serviço do Azure para o barramento de serviço selecionado.
Como alternativa, você também pode habilitar a identidade gerenciada em um ambiente de hospedagem do Azure usando a CLI do Azure.
- Conector do Serviço
- Serviço de Aplicativo do Azure
- Azure Spring Apps
- Aplicativos de Contêiner do Azure
- Máquinas Virtuais do Azure
- Serviço de Kubernetes do Azure
Você pode usar o Conector de Serviço para criar uma conexão entre um ambiente de hospedagem de computação do Azure e um serviço de destino usando a CLI do Azure. A CLI manipula automaticamente a criação de uma identidade gerenciada e atribui a função adequada, conforme explicado nas instruções do portal.
Se você estiver usando um Serviço de Aplicativo do Azure, use o comando az webapp connection
:
az webapp connection create servicebus \
--resource-group <resource-group-name> \
--name <webapp-name> \
--target-resource-group <target-resource-group-name> \
--namespace <target-service-bus-namespace> \
--system-identity
Se você estiver usando os Aplicativos Spring do Azure, use o comando az spring connection
:
az spring connection create servicebus \
--resource-group <resource-group-name> \
--service <service-instance-name> \
--app <app-name> \
--deployment <deployment-name> \
--target-resource-group <target-resource-group> \
--namespace <target-service-bus-namespace> \
--system-identity
Se você estiver usando os Aplicativos de Contêiner do Azure, use o comando az containerapp connection
:
az containerapp connection create servicebus \
--resource-group <resource-group-name> \
--name <webapp-name> \
--target-resource-group <target-resource-group-name> \
--namespace <target-service-bus-namespace> \
--system-identity
Atribuir funções à identidade gerenciada
Em seguida, você precisa conceder permissões à identidade gerenciada criada para acessar o Barramento de Serviço. Você pode fazer isso atribuindo uma função à identidade gerenciada, assim como fez com o usuário de desenvolvimento local.
Se você conectou seus serviços usando o Conector de serviço, não será necessário concluir esta etapa. As configurações necessárias foram tratadas para você:
Se você selecionou uma identidade gerenciada durante a criação da conexão, uma identidade gerenciada atribuída pelo sistema foi criada para seu aplicativo e atribuiu a função de Proprietário de Dados do Barramento de Serviço do Azure, no Barramento de Serviço.
Se você selecionou a cadeia de conexão, a cadeia de conexão foi adicionada como uma variável de ambiente de aplicativo.
Testar o aplicativo
Depois de fazer essas alterações de código, navegue até o aplicativo hospedado no navegador. Seu aplicativo deve ser capaz de se conectar ao Barramento de Serviço com êxito. Lembre-se de que pode levar vários minutos para que as atribuições de função se propaguem pelo ambiente do Azure. Seu aplicativo agora está configurado para ser executado localmente e em um ambiente de produção sem que os desenvolvedores precisem gerenciar segredos no próprio aplicativo.
Próximas etapas
Neste tutorial, você aprendeu a migrar um aplicativo para conexões sem senha.