Considerações sobre gerenciamento de identidade e acesso para o acelerador de zona de aterrissagem do Azure Integration Services
Este artigo baseia-se nas orientações fornecidas no artigo Zona de aterragem do Azure Área de design da zona de aterragem do Azure para gestão de identidade e acesso. As orientações fornecidas no artigo a seguir ajudarão você a identificar considerações e recomendações de design relacionadas ao gerenciamento de identidade e acesso específico para a implantação do Azure Integration Services (AIS). Se o AIS for implantado para dar suporte a plataformas de missão crítica, as orientações sobre as áreas de design da zona de aterrissagem do Azure também deverão ser incluídas no seu design.
Visão geral do gerenciamento de identidade e acesso (IAM)
Para os fins deste artigo, o Gerenciamento de Identidade e Acesso (IAM) refere-se às opções de autenticação e autorização disponíveis para implantar ou manter recursos no Azure. Na prática, isso envolve identificar quais identidades têm permissão para criar, atualizar, excluir e gerenciar recursos por meio do portal do Azure ou da API do Gerenciador de Recursos.
O IAM é uma consideração separada da segurança de endpoint, que define quais identidades podem chamar e acessar seus serviços. A segurança do endpoint é abordada no artigo Segurança separado desta série. Dito isso, às vezes as duas áreas de design se sobrepõem: para alguns serviços no Azure, o acesso ao ponto de extremidade é configurado por meio dos mesmos controles RBAC usados para gerenciar o acesso aos recursos.
Considerações de design
Determine os limites de administração de recursos do Azure para os recursos que você implanta, considerando a separação de funções e a eficiência operacional.
Analise as atividades de administração e gerenciamento do Azure que você precisa que suas equipes executem. Considere os recursos AIS que você implantará e como os usará. Determine a melhor distribuição possível de responsabilidades dentro da sua organização.
Recomendações de design
Usar identidades gerenciadas para recursos do Integration Services - consulte o artigo Segurança desta série para obter uma descrição detalhada desta recomendação.
Use o ID do Microsoft Entra para autenticação em recursos de serviços de integração.
Considere o nível de acesso necessário para as funções dentro da sua organização e aplique o princípio de menor privilégio por função. Essas funções podem incluir proprietários de plataforma, proprietários de carga de trabalho, engenheiros de devops e administradores de sistema, por exemplo.
Usando o princípio de menor privilégio, considere quais funções você precisará para gerenciar e manter seus aplicativos AIS. Perguntas a fazer a este respeito:
Quem precisará visualizar arquivos de log de fontes como Application Insights, Log Analytics e Contas de Armazenamento?
Alguém precisa visualizar os dados originais da solicitação (incluindo dados confidenciais)?
De onde os dados de solicitação originais podem ser visualizados (por exemplo, apenas da sua rede corporativa)?
Quem pode visualizar o histórico de execução de um fluxo de trabalho?
Quem pode reenviar uma execução com falha?
Quem precisa de acesso às chaves de subscrição do API Management?
Quem pode exibir o conteúdo de um Tópico ou Assinatura do Service Bus ou ver métricas de fila/tópico?
Quem precisa ser capaz de administrar o Cofre de Chaves?
Quem precisa ser capaz de adicionar, editar ou excluir chaves, segredos e certificados no Cofre de Chaves?
Quem precisa ser capaz de visualizar e ler chaves, segredos ou certificados no Cofre de Chaves?
As funções e grupos internos existentes do Microsoft Entra cobrirão os requisitos que você identificou?
Crie funções personalizadas para limitar o acesso ou para fornecer mais granularidade sobre as permissões quando as funções internas não bloquearem suficientemente o acesso. Por exemplo, o acesso à URL de retorno de chamada de um Aplicativo Lógico requer uma única permissão, mas não há nenhuma função interna para esse tipo de acesso além de "Colaborador" ou "Proprietário", que são muito amplos.
Veja como usar a Política do Azure para restringir o acesso a determinados recursos ou para impor a conformidade com a política da empresa. Por exemplo, você pode criar uma política que permita apenas a implantação de APIs de Gerenciamento de API que usam protocolos criptografados.
Analise as atividades comuns envolvidas na administração e no gerenciamento do AIS no Azure e atribua permissões RBAC adequadamente. Para obter mais detalhes sobre as permissões disponíveis, consulte Operações do provedor de recursos.
Alguns exemplos de atividades comuns de administração do Azure incluem:
| Recurso do Azure | Azure Resource Provider | Atividades |
|---|---|---|
| Plano do Serviço de Aplicações | Microsoft.Web/serverfarms | Ler, Juntar, Reiniciar, Obter Conexões VNet |
| Ligação de API | Microsoft.Web/conexões | Atualizar, Confirmar |
| Aplicativos e funções lógicas | Microsoft.Web/sites | Ler, Iniciar, Parar, Reiniciar, Trocar, Atualizar Configuração, Ler Diagnósticos, Obter Conexões VNet |
| Conta de Integração | Microsoft.Logic/integrationAccounts | Ler/Adicionar/Atualizar/Excluir Assemblies, Ler/Adicionar/Atualizar/Excluir Mapas, Ler/Adicionar/Atualizar/Excluir Esquemas, Ler/Adicionar/Atualizar/Excluir Contratos, Ler/Adicionar/Atualizar/Excluir Parceiros |
| Service Bus | Microsoft.ServiceBus | Ler, Obter Cadeia de Conexão, Atualizar Configuração de DR, Ler Filas, Ler Tópicos, Ler Assinaturas |
| Conta de Armazenamento | Microsoft.Storage/storageAccounts | Ler, Alterar (por exemplo, histórico de execução do fluxo de trabalho) |
| Gestão de API | Microsoft.ApiManagement | Registrar/excluir um usuário, ler APIs, gerenciar autorizações, gerenciar cache |
| KeyVault | Microsoft.KeyVault/cofres | Criar um cofre, editar políticas de acesso |
Próximo passo
Analise as áreas críticas de design para fazer considerações e recomendações completas para sua arquitetura.