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 de autenticação tradicionais para conexões mais seguras e sem senha.
Riscos de segurança associados às 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. Quando você cria um Service Bus, o Azure gera essas chaves e cadeias de conexão automaticamente. Muitos desenvolvedores gravitam em torno dessa solução porque ela parece familiar às opções com as quais trabalharam no passado. Se seu aplicativo usa cadeias de conexão atualmente, 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 obtenha acesso à chave é capaz de autenticar. Por exemplo, se uma chave de conta for acidentalmente verificada no controle do código-fonte, enviada por meio de um e-mail não seguro, colada no bate-papo errado ou visualizada por alguém que não deveria ter permissão, há 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 oferecem suporte a conexões sem senha por meio do Microsoft Entra ID e do RBAC (Controle de Acesso Baseado em Função). Essas técnicas fornecem recursos de segurança robustos e podem ser implementadas usando DefaultAzureCredential
as bibliotecas de cliente do Azure Identity.
Importante
Algumas linguagens devem ser implementadas DefaultAzureCredential
explicitamente em seu código, enquanto outras utilizam DefaultAzureCredential
internamente por meio de plugins ou drivers subjacentes.
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 em que DefaultAzureCredential
as pesquisas de credenciais podem ser encontrados na visão geral da Biblioteca de Identidades do Azure e variam entre os idiomas. Por exemplo, ao trabalhar localmente com o .NET, DefaultAzureCredential
geralmente autenticará usando a conta que o desenvolvedor usou para entrar no Visual Studio, CLI do Azure ou Azure PowerShell. Quando o aplicativo é implantado no Azure, DefaultAzureCredential
ele descobre e usa automaticamente a identidade gerenciada do serviço de hospedagem associado, como o Serviço de Aplicativo do Azure. Não são necessárias alterações de código para esta transição.
Nota
Uma identidade gerenciada fornece uma identidade de segurança para representar um aplicativo ou serviço. A identidade é gerida pela plataforma do Azure e não precisa de aprovisionar nem rodar segredos. 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 Service Bus 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 passar uma instância de para o construtor de uma classe de cliente de DefaultAzureCredential
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 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, em seguida, 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 Service Bus tem as permissões corretas. Neste exemplo, você usará a função 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 função de Administrador de Acesso de Usuário ou outra função que inclua a ação Microsoft.Authorization/roleAssignments/write . Você pode atribuir funções do 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 com escopo para um namespace específico do Service Bus, para seguir o Princípio do Menor Privilégio. Essa prática oferece 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 enviar e receber dados.
Importante
Na maioria dos casos, levará um ou dois minutos para que a atribuição de função se propague no Azure, mas, em casos raros, pode levar até oito minutos. Se você receber erros de autenticação quando executar o código pela primeira vez, aguarde alguns momentos e tente novamente.
No portal do Azure, localize seu namespace do Service Bus usando a barra de pesquisa principal ou a navegação à esquerda.
Na página Visão geral do Service Bus, 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, procure Proprietário de Dados do Barramento de Serviço do Azure, selecione o resultado correspondente e escolha Avançar.
Em Atribuir acesso a, selecione Utilizador, grupo ou entidade de serviço e, em seguida, selecione + Selecionar membros.
Na caixa de diálogo, procure seu nome de usuário do Microsoft Entra (geralmente seu endereço de e-mail user@domain ) e escolha Selecionar na parte inferior da caixa de diálogo.
Selecione Rever + atribuir para ir para a página final e, em seguida , Rever + atribuir novamente para concluir o processo.
Inicie sessão e migre o código da aplicação para utilizar ligações sem palavra-passe
Para desenvolvimento local, certifique-se de que está autenticado com a mesma conta do Microsoft Entra à qual atribuiu a função para o espaço de nomes do Service Bus. Você pode autenticar por meio da CLI do Azure, Visual Studio, Azure PowerShell ou outras ferramentas, como IntelliJ.
Para desenvolvimento local, certifique-se de que está autenticado com a mesma conta do Microsoft Entra à qual atribuiu a função. 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 oAzure.Identity
pacote:dotnet add package Azure.Identity
Na parte superior do ficheiro, adicione o seguinte código:
using Azure.Identity;
Identifique o código que cria um
ServiceBusClient
objeto para se conectar ao Barramento de Serviço do Azure. Atualize seu código para corresponder ao exemplo a seguir:var serviceBusNamespace = $"{namespace}.servicebus.windows.net"; ServiceBusClient client = new( serviceBusNamespace, new DefaultAzureCredential());
Executar a aplicação localmente
Depois de fazer essas alterações de código, execute seu aplicativo localmente. A nova configuração deve pegar suas credenciais locais, como a CLI do Azure, Visual Studio ou IntelliJ. As funções que você atribuiu ao seu 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 seu 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 do Serviço de Aplicativo do Azure que tenha uma identidade gerenciada habilitada pode se conectar ao Barramento de Serviço do Azure.
Criar a identidade gerenciada usando o portal do Azure
As etapas a seguir demonstram como criar uma identidade gerenciada atribuída ao 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 de serviço
- Serviço de Aplicações do Azure
- Azure Spring Apps
- Aplicativos de contêiner do Azure
- Máquinas Virtuais do Azure
Alguns ambientes de hospedagem de aplicativos oferecem suporte ao Service Connector, que ajuda você a conectar os serviços de computação do Azure a outros serviços de suporte. O Service Connector define automaticamente as configurações de rede e as informações de conexão. Você pode saber mais sobre o Service Connector e quais cenários são suportados na página de visão geral.
Os seguintes serviços de computação são suportados atualmente:
- Serviço de Aplicações do Azure
- Azure Spring Cloud
- Aplicativos de Contêiner do Azure (visualização)
Para este guia de migração, você usará o Serviço de Aplicativo, mas as etapas são semelhantes nos Aplicativos Azure Spring e nos Aplicativos de Contêiner do Azure.
Nota
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 seu 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. Introduza os seguintes valores:
- Tipo de serviço: Escolha Barramento de serviço.
- Assinatura: selecione a assinatura que você gostaria de 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ê gostaria de usar.
Selecione Next: Authentication.
Verifique se a identidade gerenciada atribuída ao sistema (Recomendado) está selecionada e escolha Avançar: Rede.
Deixe os valores padrão selecionados e escolha Avançar: Revisar + Criar.
Depois que o Azure validar suas configurações, selecione Criar.
O Service Connector criará automaticamente uma identidade gerenciada atribuída ao 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 de serviço
- Serviço de Aplicações do Azure
- Azure Spring Apps
- Aplicativos de contêiner do Azure
- Máquinas Virtuais do Azure
- Azure Kubernetes Service
Você pode usar o Service Connector 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 lida automaticamente com 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 az webapp connection
comando:
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 o Azure Spring Apps, use o az spring connection
comando:
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 az containerapp connection
comando:
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 Service Bus. Você pode fazer isso atribuindo uma função à identidade gerenciada, assim como fez com seu usuário de desenvolvimento local.
Se você conectou seus serviços usando o Service Connector, não precisará 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 ao sistema foi criada para seu aplicativo e atribuída 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 do aplicativo.
Testar a aplicação
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 Service Bus com êxito. Lembre-se de que pode levar vários minutos para que as atribuições de função se propaguem pelo seu ambiente do 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.