Considerações de 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 diretrizes fornecidas no artigo a seguir ajudarão você a identificar considerações de design e recomendações relacionadas ao gerenciamento de identidade e acesso específicos 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 diretrizes sobre as áreas de design da zona de aterrissagem do Azure também deverão ser incluídas em 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 de ponto de extremidade é 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 sobre o design
Determine os limites de administração de recursos do Azure para os recursos implantados, considerando a separação de funções e a eficiência operacional.
Revise as atividades de administração e gerenciamento do Azure que você exige que suas equipes executem. Considere os recursos AIS que você implantará e como os usará. Determine a melhor distribuição possível de responsabilidades em sua organização.
Recomendações sobre design
Usar identidades gerenciadas para recursos do Integration Services - consulte o artigo Segurança desta série para obter uma descrição detalhada dessa recomendação.
Use a 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 de sua organização e aplique o princípio de privilégio mínimo por função. Essas funções podem incluir proprietários de plataforma, proprietários de carga de trabalho, engenheiros devops e administradores de sistema, por exemplo.
Usando o princípio de privilégio mínimo, considere quais funções você precisará para gerenciar e manter seus aplicativos AIS. Perguntas a fazer a este respeito:
Quem precisará exibir 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 da solicitação original podem ser visualizados (por exemplo, somente da sua rede corporativa)?
Quem pode ver 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 assinatura do Gerenciamento de API?
Quem pode exibir o conteúdo de um Tópico ou Assinatura do Barramento de Serviço 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.
Revise as atividades comuns envolvidas na administração e no gerenciamento do AIS no Azure e atribua permissões RBAC apropriadamente. 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:
| Recursos do Azure | Provedor de Recursos do Azure | Atividades |
|---|---|---|
| Plano do Serviço de Aplicativo | Microsoft.Web/serverfarms | Ler, Ingressar, Reiniciar, Obter conexões VNet |
| Conexão da API | Microsoft.Web/connections | Atualizar, Confirmar |
| Aplicativos e funções lógicas | Microsoft.Web/sites | Ler, Iniciar, Parar, Reiniciar, Trocar, Atualizar Configuração, Ler Diagnóstico, 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 |
| Barramento de Serviço | 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) |
| Gerenciamento da API | Microsoft.ApiManagement | Registrar/excluir um usuário, ler APIs, gerenciar autorizações, gerenciar cache |
| KeyVault | Microsoft.KeyVault/vaults | Criar um cofre, editar políticas de acesso |
Próxima etapa
Revise as áreas críticas de design para fazer considerações e recomendações completas para sua arquitetura.