Skip to main content

Featured

Delegar permissões de Administrador no Microsoft Entra ID

Delegar permissões administrativas no Microsoft Entra ID é essencial para distribuir responsabilidades de forma segura e eficiente, sem comprometer a governança da organização. Essa prática evita a concentração de acessos privilegiados em poucas contas e reduz riscos de segurança, ao mesmo tempo em que melhora a rastreabilidade das ações administrativas. Acessando o portal do Microsoft Entra O primeiro passo é acessar o portal de administração do Microsoft Entra em https://entra.microsoft.com com uma conta que possua a função de Global Administrator , pois apenas esse perfil tem autorização para gerenciar funções administrativas. Navegando até as funções administrativas No menu lateral, selecione Identidade e depois clique em Funções e administradores . Nessa área, você encontrará uma lista com todas as funções disponíveis no Entra ID, como: Global Administrator User Administrator Groups Administrator Helpdesk Administrator Security Reader Compliance Administrat...

Bicep para Microsoft Entra ID chega a GA: unificando Azure e identidade no mesmo template


A Microsoft oficializou a disponibilidade geral (GA) de Bicep templates para recursos do Microsoft Entra ID. A novidade leva o modelo declarativo de IaC do Bicep para recursos do Microsoft Graph, começando pelos recursos centrais do Entra ID, e permite descrevê‑los e implantá‑los junto com recursos de Azure no mesmo arquivo. O objetivo é simplificar a definição de infraestrutura, reduzir orquestrações paralelas e tornar as implantações mais previsíveis e reprodutíveis. 

Até então, equipes precisavam coordenar dois mecanismos: ARM/Bicep para serviços de Azure e Microsoft Graph (geralmente via PowerShell) para itens como aplicativos e grupos no Entra. Com o GA, o mesmo template Bicep pode declarar um App Service, uma identidade gerenciada e, no mesmo grafo de dependências, um grupo do Entra e uma credencial de identidade federada para CI/CD — tudo implantado pelo mecanismo de deployments, que respeita as dependências e encaminha as chamadas de “Microsoft.Graph/*” para a nova Microsoft Graph Bicep extension. 

O que muda na prática

O Bicep passa a tratar recursos do Entra ID como recursos extensíveis. Na implantação, o mecanismo envia o que é Azure para os respectivos resource providers (por exemplo, Microsoft.ManagedIdentity) e encaminha o que é “Microsoft.Graph/*” para a extensão do Microsoft Graph, que traduz as declarações do template em chamadas ao Graph. Isso elimina scripts externos apenas para “completar” a configuração de identidade, reduzindo drift e passos manuais. 

Cenário recomendado: CI/CD sem segredos com GitHub Actions

Um dos cenários de referência mostrados combina Workload Identity Federation no Entra com um workflow do GitHub Actions. O template cria o aplicativo que representa o pipeline, declara a federated identity credential (com verificação de issuer/subject do token do GitHub) e pode atribuir permissões em Azure (por exemplo, Contributor) para o runtime do pipeline. Assim, o Actions troca seu token por um token do Entra para acessar Azure, evitando segredos estáticos. 

Benefícios estratégicos

No curto prazo, o ganho é governança unificada: um único PR versiona tanto a camada de Azure quanto os artefatos de identidade do tenant. No médio prazo, isso viabiliza padrões corporativos (módulos internos, revisão de segurança, gated approvals) e melhora a observabilidade de mudanças, já que o histórico de Git passa a refletir também grupos e aplicações críticos do Entra. Esses pontos derivam diretamente do modelo declarativo e do pipeline de deployment único apresentado no anúncio. 

Limites e roadmap imediato

O escopo inicial cobre recursos centrais do Microsoft Entra ID. A equipe sinalizou intenção de ampliar a cobertura de tipos com o tempo. Para Intune, não há planos imediatos no momento da publicação; a recomendação é acompanhar e votar na demanda no repositório de tipos do Graph Bicep. Houve também menção a conversas com o time de Azure Verified Modules (AVM), sem compromissos ou datas neste momento. 

Como adotar em 5 passos
  1. Mapeie o que “está fora do template” hoje: liste grupos, aplicativos, credenciais federadas e atribuições que você ainda cria via script do Graph/PowerShell. O objetivo é trazê‑los para Bicep de forma incremental. 
  2. Padronize o authoring: use o Bicep Extension para VS Code para ter IntelliSense, validações e tipagem na criação dos recursos de Microsoft Graph. Separe módulos por domínio (identidades gerenciadas, apps, grupos). 
  3. Implemente um pipeline “secretless”: crie o aplicativo do pipeline e a federated identity credential no template. Ajuste o workflow (GitHub Actions, por exemplo) para autenticar via federação e remover segredos do repositório. 
  4. Defina dependências explícitas: quando um recurso do Entra depende de outro do Azure (ex.: adicionar uma identidade gerenciada a um grupo), declare as dependências no Bicep para garantir a ordem correta. 
  5. Pilote por domínio: comece por um app crítico e seus grupos/credenciais. Gere um runbook de migração e revisões de segurança (perfis de permissão mínimos, revisões periódicas). 

Boas práticas de governança

  • Versionamento e revisão: trate mudanças de identidade como código, com PRs obrigatórios e aprovação de segurança. 
  • Segregação de ambientes: promova o mesmo template entre dev/test/prod com parâmetros controlados por variáveis do pipeline. 
  • Confiabilidade: use execuções idempotentes e monitore falhas de dependência; o mecanismo de deployments do ARM coordena a ordem, inclusive para recursos do Graph. 

O que observar a seguir
    • Novos tipos de recurso do Graph suportados: a equipe pretende expandir a cobertura; acompanhe para incluir gradualmente mais superfícies do tenant no Bicep. Para Intune, não há suporte imediato anunciado, mas há espaço para priorização conforme feedback. 
    • Módulos AVM: a padronização em módulos verificados facilitaria a adoção em escala; há discussões, porém sem datas confirmadas. 

Com o GA do Bicep para Microsoft Entra ID, a identidade corporativa entra definitivamente no mesmo ciclo de vida declarativo que você já usa para Azure. O resultado é menos script ad‑hoc, menos drift e mais previsibilidade — pilares essenciais para operações de nuvem seguras e auditáveis. 


Comments

Popular Posts