Partilhar via

Para identidade e não só — O ponto de vista de um arquiteto

  • Artigo

Neste artigo, Alex Shteynberg, Arquiteto Técnico Principal da Microsoft, aborda as principais estratégias de design para organizações empresariais que adotam o Microsoft 365 e outros serviços cloud da Microsoft.

Acerca do autor

Foto de Alex Shteynberg.

Sou Arquiteto Técnico Principal no Centro de Tecnologia da Microsoft de Nova Iorque. Trabalho principalmente com grandes clientes e requisitos complexos. O meu ponto de vista e opiniões baseiam-se nestas interações e podem não se aplicar a todas as situações. No entanto, na minha experiência, se pudermos ajudar os clientes com os desafios mais complexos, podemos ajudar todos os clientes.

Normalmente trabalho com mais de 100 clientes por ano. Embora cada organização tenha características únicas, é interessante ver tendências e semelhanças. Por exemplo, uma tendência é o interesse entre indústrias para muitos clientes. Afinal, uma sucursal bancária também pode ser um café e um centro comunitário.

Na minha função, foco-me em ajudar os clientes a chegar à melhor solução técnica para abordar o seu conjunto único de objetivos empresariais. Oficialmente, foco-me na Identidade, Segurança, Privacidade e Conformidade. Adoro o facto de estes tocarem em tudo o que fazemos. Dá-me a oportunidade de me envolver com a maioria dos projectos. Esta atividade mantém-me ocupado e a desfrutar deste papel.

Vivo em Nova Iorque (o melhor!) e gosto muito da diversidade da sua cultura, comida e pessoas (não do tráfego). Adoro viajar quando posso e espero ver a maior parte do mundo na minha vida. Estou a pesquisar uma viagem a África para aprender sobre a vida selvagem.

Princípios de orientação

  • O simples é muitas vezes melhor: pode fazer (quase) qualquer coisa com tecnologia, mas não significa que deva fazê-lo. Especialmente no espaço de segurança, muitas soluções de sobreengenharia de clientes. Gosto deste vídeo da conferência do Google Stripe para sublinhar este ponto.
  • Pessoas, processo, tecnologia: design para as pessoas melhorarem o processo e não a tecnologia em primeiro lugar. Não existem soluções "perfeitas". Temos de equilibrar vários fatores de risco e decisões que podem ser diferentes para cada empresa. Demasiados clientes criam uma abordagem que os seus utilizadores evitam mais tarde.
  • Concentre-se em "porquê" primeiro e "como" mais tarde: Seja o irritante miúdo de 7 anos com um milhão de perguntas. Não podemos chegar à resposta certa se não soubermos as perguntas certas a fazer. Muitos clientes fazem suposições sobre como as coisas precisam de funcionar em vez de definir o problema empresarial. Existem sempre vários caminhos que podem ser seguidos.
  • Cauda longa das melhores práticas anteriores: reconhecer que as melhores práticas estão a mudar à velocidade da luz. Se olhaste para Microsoft Entra há mais de três meses, é provável que estejas desatualizado. Tudo o que está sujeito a alterações após a publicação. A opção "Melhor" de hoje pode não ser a mesma daqui a seis meses.

Conceitos de linha de base

Não ignore esta secção. Muitas vezes, acho que tenho de voltar a estes artigos, mesmo para clientes que utilizam serviços cloud há anos. Infelizmente, a linguagem não é uma ferramenta precisa. Muitas vezes, utilizamos a mesma palavra para significar conceitos diferentes ou palavras diferentes para significar o mesmo conceito. Utilizo frequentemente o seguinte diagrama para estabelecer alguma terminologia de linha de base e "modelo de hierarquia".

Ilustração de inquilino, subscrição, serviço e dados.

Quando aprende a nadar, é melhor começar na piscina e não no meio do oceano. Não estou a tentar ser tecnicamente preciso com este diagrama. É um modelo para discutir alguns conceitos básicos.

No diagrama:

  • Inquilino = uma instância de Microsoft Entra ID. Está no "topo" de uma hierarquia ou nível 1 no diagrama. Podemos considerar este nível como o "limite" em que tudo o resto ocorre (Microsoft Entra B2B à parte). Todos os serviços cloud empresariais da Microsoft fazem parte de um destes inquilinos. Os serviços de consumidor são separados. "Inquilino" aparece na documentação como inquilino do Microsoft 365, inquilino do Azure, inquilino WVD, etc. Muitas vezes, estas variações causam confusão aos clientes.
  • Os serviços/subscrições, Nível 2 no diagrama, pertencem a um e apenas um inquilino. A maioria dos serviços SaaS são 1:1 e não podem ser movidos sem migração. O Azure é diferente, pode mover a faturação e/ou uma subscrição para outro inquilino. Existem muitos clientes que precisam de mover subscrições do Azure. Este cenário tem várias implicações. Os objetos que existem fora da subscrição não são movidos. Por exemplo, o controlo de acesso baseado em funções (RBAC do Azure), Microsoft Entra objetos (grupos, aplicações, políticas, etc.) e alguns serviços (Azure Key Vault, Tijolos de Dados, etc.). Não migre serviços sem uma boa necessidade empresarial. Alguns scripts que podem ser úteis para a migração são partilhados no GitHub.
  • Normalmente, um determinado serviço tem algum tipo de limite de "subnível" ou Nível 3 (L3). Este limite é útil para compreender a segregação de segurança, políticas, governação, etc. Infelizmente, não há nenhum nome uniforme que eu conheça. Alguns exemplos de nomes para L3 são: Subscrição do Azure = recurso; Dynamics 365 CE = instância; Power BI = área de trabalho; Power Apps = ambiente; e assim sucessivamente.
  • O nível 4 é onde residem os dados reais. Este "plano de dados" é um artigo complexo. Alguns serviços estão a utilizar Microsoft Entra ID para RBAC, outros não. Vou falar um pouco sobre isso quando chegarmos aos artigos de delegação.

Alguns outros conceitos que acho que muitos clientes (e funcionários da Microsoft) estão confusos ou têm dúvidas sobre incluem os seguintes problemas:

  • Qualquer pessoa pode criar muitos inquilinos sem custos. Não precisa de um serviço aprovisionado no mesmo. Tenho dezenas. Cada Nome de inquilino é exclusivo no serviço cloud mundial da Microsoft (por outras palavras, nenhum inquilino pode ter o mesmo nome). Estão todos no formato de TenantName.onmicrosoft.com. Também existem processos que criam Inquilinos automaticamente (inquilinos não geridos). Por exemplo, este resultado pode ocorrer quando um utilizador se inscreve num serviço empresarial com um domínio de e-mail que não existe em nenhum outro inquilino.
  • Num inquilino gerido, muitos domínios DNS podem ser registados no mesmo. Este resultado não altera o nome do inquilino original. Atualmente, não existe uma forma fácil de mudar o nome de um inquilino (além da migração). Embora o nome do inquilino não seja tecnicamente crítico hoje em dia, algumas pessoas podem sentir-se limitadas por esta realidade.
  • Deve reservar um nome de inquilino para a sua organização, mesmo que ainda não esteja a planear implementar quaisquer serviços. Caso contrário, alguém pode retirá-lo de si e não há um processo simples para o recuperar (o mesmo problema que os nomes DNS). Ouço isto demasiadas vezes por parte dos clientes. O nome do seu inquilino também deve ser um artigo de debate.
  • Se for o proprietário do espaço de nomes DNS, deve adicionar todos estes espaços de nomes aos seus inquilinos. Caso contrário, pode-se criar um inquilino não gerido com este nome, o que, em seguida, causa perturbações para o tornar gerido.
  • Um espaço de nomes DNS (por exemplo, contoso.com) pode pertencer a um e apenas a um Inquilino. Este requisito tem implicações em vários cenários (por exemplo, partilhar um domínio de e-mail durante uma fusão ou aquisição, etc.). Existe uma forma de registar uma subscrição DNS (por exemplo, div.contoso.com) num inquilino diferente, mas que deve ser evitada. Ao registar um nome de domínio de nível superior, presume-se que todos os subdomínios pertencem ao mesmo inquilino. Em cenários multi-inquilinos (conforme explicado a seguir), normalmente recomendaria a utilização de outro nome de domínio de nível superior (como contoso.ch ou ch-contoso.com).
  • Quem deve "possuir" um inquilino? Vejo frequentemente clientes que não sabem quem é atualmente o proprietário do seu inquilino. Esta falta de conhecimento é uma bandeira vermelha significativa. Contacte o suporte da Microsoft o mais rápido possível. Igualmente problemático é quando um proprietário de serviço (muitas vezes um administrador do Exchange) é designado para gerir um inquilino. O inquilino contém todos os serviços que poderá querer no futuro. O proprietário do inquilino deve ser um grupo que pode tomar decisões para a ativação de todos os serviços cloud numa organização. Outro problema é quando é pedido a um grupo de proprietários de inquilinos que faça a gestão de todos os serviços. Este método não é dimensionado para grandes organizações.
  • Não existe nenhum conceito de um sub/super inquilino. Por alguma razão, este mito continua a repetir-se. Este conceito também se aplica aos inquilinos do Azure Active Directory B2C . Ouço demasiadas vezes "O meu ambiente B2C está no meu Inquilino XYZ" ou "Como devo proceder para mover o meu inquilino do Azure para o meu inquilino do Microsoft 365?"
  • Este documento concentra-se principalmente na cloud comercial em todo o mundo, porque é isso que a maioria dos clientes está a utilizar. Por vezes, é útil saber mais sobre clouds soberanas. As clouds soberanas têm outras implicações para discutir que estão fora do âmbito deste debate.

Artigos de identidade da linha de base

Existe muita documentação sobre a plataforma de identidade da Microsoft – Microsoft Entra ID. Para as pessoas que estão apenas a começar, muitas vezes parece esmagador. Mesmo depois de saber mais, acompanhar a inovação e a mudança constantes pode ser um desafio. Nas interações dos meus clientes, vejo-me muitas vezes a servir de "tradutor" entre objetivos empresariais e abordagens "Bom, Melhor, Melhor" para abordar estas preocupações (e "notas de penhasco" humanas para estes artigos). Raramente há uma resposta perfeita e a decisão "certa" é um equilíbrio de vários fatores de risco. Seguem-se algumas das questões comuns e áreas de confusão que costumo discutir com os clientes.

Aprovisionamento

Microsoft Entra ID não resolve por falta de governação no seu mundo de identidade! A governação de identidades deve ser um elemento crítico, independentemente das decisões da cloud. Os requisitos de governação mudam ao longo do tempo, razão pela qual é um programa e não uma ferramenta.

Microsoft Entra Ligar vs. Microsoft Identity Manager (MIM) vs. outra coisa (terceiros ou personalizado)? Guarde os seus problemas agora e no futuro e siga Microsoft Entra Connect. Existem todos os tipos de smarts nesta ferramenta para lidar com configurações peculiares de clientes e inovações contínuas.

Alguns casos periféricos que podem conduzir a uma arquitetura mais complexa:

  • Tenho várias florestas do AD sem conectividade de rede entre elas. Existe uma nova opção denominada Aprovisionamento na Cloud.
  • Não tenho o Active Directory, nem quero instalá-lo. Microsoft Entra o Connect pode ser configurado para sincronizar a partir de LDAP (o parceiro pode ser necessário).
  • Preciso de aprovisionar os mesmos objetos para vários inquilinos. Este cenário não é tecnicamente suportado, mas depende da definição de "mesmo".

Devo personalizar as regras de sincronização predefinidas (filtrar objetos, alterar atributos, ID de início de sessão alternativo, etc.)? Evite! Uma plataforma de identidade é tão valiosa quanto os serviços que a utilizam. Embora possa efetuar todo o tipo de configurações, para responder a esta pergunta, tem de analisar o efeito nas aplicações. Se filtrar objetos com capacidade de correio, a GAL para serviços online está incompleta; se a aplicação depender de atributos específicos, a filtragem nestes atributos tem efeitos imprevisíveis, etc. Não é uma decisão da equipa de identidade.

O SaaS do XYZ suporta o aprovisionamento Just-in-Time (JIT), por que motivo está a exigir que eu sincronize? Veja o parágrafo anterior. Muitas aplicações precisam de informações de "perfil" para a funcionalidade. Não pode ter uma GAL se todos os objetos com capacidade de correio não estiverem disponíveis. O mesmo se aplica ao aprovisionamento de utilizadores em aplicações integradas com Microsoft Entra ID.

Autenticação

Sincronização do hash de palavras-passe (PHS) vs. autenticação pass-through (PTA) vs. federação.

Normalmente, há um debate apaixonado em torno da federação. Normalmente, é mais simples e, portanto, utilizar PHS, a menos que tenha uma boa razão para não o fazer. Também é possível configurar diferentes métodos de autenticação para diferentes domínios DNS no mesmo inquilino.

Alguns clientes ativam a federação + PHS principalmente para:

Muitas vezes guio os clientes através do fluxo de autenticação de cliente para esclarecer alguns equívocos. O resultado é semelhante à imagem seguinte, que não é tão boa como o processo interativo de chegar lá.

Exemplo de conversação no quadro.

Este tipo de desenho de quadro ilustra onde as políticas de segurança são aplicadas no fluxo de um pedido de autenticação. Neste exemplo, as políticas impostas através do Serviço de Federação do Active Directory (AD FS) são aplicadas ao primeiro pedido de serviço, mas não aos pedidos de serviço subsequentes. Este comportamento é, pelo menos, um motivo para mover os controlos de segurança para a cloud o máximo possível.

Temos perseguido o sonho do início de sessão único (SSO) desde que me lembro. Alguns clientes acreditam que podem alcançar o início de sessão único ao escolher o fornecedor de federação (STS) "correto". Microsoft Entra ID pode ajudar a ativar significativamente as capacidades de SSO, mas nenhum STS é mágico. Existem demasiados métodos de autenticação "legados" que ainda são utilizados para aplicações críticas. Expandir Microsoft Entra ID com soluções de parceiros pode abordar muitos destes cenários. O SSO é uma estratégia e um percurso. Não é possível aceder lá sem avançar para as normas das aplicações. Relacionado com este artigo está um percurso para a autenticação sem palavra-passe , que também não tem uma resposta mágica.

A autenticação multifator (MFA) é essencial hoje em dia (aqui para obter mais). Adicione-lhe a análise de comportamento do utilizador e tem uma solução que impede os ciberataques mais comuns. Até os serviços de consumidor estão a ser movidos para exigir a MFA. No entanto, ainda me encontro com muitos clientes que não querem mudar para abordagens de autenticação modernas . O maior argumento que ouço é que afeta os utilizadores e as aplicações legadas. Por vezes, um bom pontapé pode ajudar os clientes a avançar - Exchange Online alterações anunciadas. Muitos Microsoft Entra relatórios estão agora disponíveis para ajudar os clientes com esta transição.

Autorização

De acordo com a Wikipédia, "autorizar" é definir uma política de acesso. Muitas pessoas veem-no como a capacidade de definir controlos de acesso para um objeto (ficheiro, serviço, etc.). No mundo atual das ameaças cibernéticas, este conceito está a evoluir rapidamente para uma política dinâmica que pode reagir a vários vetores de ameaças e ajustar rapidamente os controlos de acesso em resposta aos mesmos. Por exemplo, se aceder à minha conta bancária a partir de uma localização invulgar, recebo passos de confirmação adicionais. Para abordar esta realidade, temos de considerar não só a própria política, mas também o ecossistema das metodologias de deteção de ameaças e correlação de sinais.

O motor de política do Microsoft Entra ID é implementado com políticas de Acesso Condicional. Este sistema depende de informações de outros sistemas de deteção de ameaças para tomar decisões dinâmicas. Uma vista simples seria semelhante à seguinte ilustração:

Motor de política no Microsoft Entra ID.

Combinar todos estes sinais em conjunto permite políticas dinâmicas como estas:

  • Se for detetada uma ameaça no seu dispositivo, o acesso aos dados será reduzido apenas para a Web sem a capacidade de transferência.
  • Se estiver a transferir um volume de dados invulgarmente elevado, tudo o que transferir é encriptado e restrito.
  • Se aceder a um serviço a partir de um dispositivo não gerido, será bloqueado a partir de dados altamente confidenciais, mas poderá aceder a dados não limitados sem a capacidade de copiá-lo para outra localização.

Se concordar com esta definição expandida de autorização, terá de implementar soluções adicionais. As soluções que implementar dependem da dinâmica que pretende que a política seja e das ameaças que pretende priorizar. Alguns exemplos desses sistemas são:

Além de Microsoft Entra ID, vários serviços e aplicações têm os seus próprios modelos de autorização específicos. Alguns destes modelos são abordados posteriormente na secção de delegação.

Auditoria

Microsoft Entra ID tem capacidades detalhadas de auditoria e relatórios. No entanto, normalmente, estes relatórios não são a única origem de informações necessárias para tomar decisões de segurança. Veja mais debates sobre este assunto na secção de delegação.

Não existe nenhum Exchange

Não entre em pânico! O Exchange não está a ser preterido (ou o SharePoint, etc.). Continua a ser um serviço principal. O que quero dizer é que, há já algum tempo, os fornecedores de tecnologia têm vindo a fazer a transição de experiências de utilizador (UX) para abranger componentes de vários serviços. No Microsoft 365, um exemplo simples é "anexos modernos" onde os anexos ao e-mail são armazenados no SharePoint Online ou no OneDrive.

Anexar um ficheiro a um e-mail.

Olhando para o cliente do Outlook, pode ver muitos serviços que estão "ligados" como parte desta experiência e não apenas o Exchange. Os exemplos incluem Microsoft Entra ID, Microsoft Search, Aplicações, Perfil, conformidade e grupos do Microsoft 365.

Interface do Outlook com notas de aviso.

Leia mais sobre Microsoft Fluid Framework para pré-visualizar as capacidades futuras. Agora, em pré-visualização, posso ler e responder a conversações do Teams diretamente no Outlook. Na verdade, o cliente do Teams é um dos exemplos mais proeminentes desta estratégia.

No geral, é cada vez mais difícil desenhar uma linha clara entre o Microsoft 365 e outros serviços nas clouds da Microsoft. Vejo-o como um grande benefício para os clientes, uma vez que podem beneficiar da inovação total em tudo o que fazemos, mesmo que utilizem um componente. Muito legal e tem implicações de longo alcance para muitos clientes.

Atualmente, acho que muitos grupos de TI de clientes estão estruturados em torno de "produtos". É lógico para um mundo no local, uma vez que precisa de um especialista para cada produto específico. No entanto, estou feliz por não ter de depurar novamente uma base de dados do Active Directory ou do Exchange, uma vez que estes serviços mudaram para a cloud. A automatização (que a cloud basicamente é) remove determinados trabalhos manuais repetitivos (veja o que aconteceu às fábricas). No entanto, estas tarefas são substituídas por requisitos mais complexos para compreender a interação entre serviços, o efeito, as necessidades empresariais, etc. Se estiver disposto a aprender, existem grandes oportunidades ativadas pela transformação da cloud. Antes de passar para a tecnologia, falo frequentemente com os clientes sobre a gestão da mudança nas competências de TI e nas estruturas de equipa.

Para todos os fãs e programadores do SharePoint, pare de perguntar "Como posso fazer XYZ no SharePoint Online?" Utilize o Power Automate (ou Flow) para o fluxo de trabalho, é uma plataforma muito mais avançada. Utilize o Azure Bot Framework para criar um UX melhor para a sua lista de 500 K itens. Comece a utilizar o Microsoft Graph em vez do CSOM. O Microsoft Teams inclui o SharePoint, mas também um mundo mais. Existem muitos outros exemplos que posso listar. Há um vasto e maravilhoso universo lá fora. Abra a porta e comece a explorar.

O outro efeito comum está na área de conformidade. Esta abordagem entre serviços parece confundir completamente muitas políticas de conformidade. Continuo a ver organizações que afirmam: "Preciso de fazer um diário de todas as comunicações de e-mail para um sistema de Deteção de Dados Eletrónicos." O que significa realmente esta afirmação quando o e-mail já não é apenas e-mail, mas uma janela para outros serviços? O Microsoft 365 tem uma abordagem abrangente de conformidade, mas a mudança de pessoas e processos é muitas vezes muito mais difícil do que a tecnologia.

Há muitas outras pessoas e implicações no processo. Na minha opinião, este factor é uma área crítica e pouco discutida. Talvez mais noutro artigo.

Opções de estrutura de inquilinos

Inquilino único vs. multi-inquilino

Em geral, a maioria dos clientes deve ter apenas um inquilino de produção. Existem muitas razões pelas quais vários inquilinos são desafiantes (dar-lhe uma pesquisa do Bing) ou ler este documento técnico. Ao mesmo tempo, muitos clientes empresariais com quem trabalho têm outro (pequeno) inquilino para aprendizagem, teste e experimentação de TI. O acesso entre inquilinos do Azure é facilitado com o Azure Lighthouse. O Microsoft 365 e muitos outros serviços SaaS têm limites para cenários entre inquilinos. Há muito a considerar em Microsoft Entra cenários B2B.

Muitos clientes acabam com vários inquilinos de produção após uma fusão e aquisição (M&A) e querem consolidar. Hoje em dia, isso não é simples e exigiria serviços de consultoria da Microsoft (MCS) ou um parceiro mais software de terceiros. Existem trabalhos de engenharia em curso para abordar vários cenários com clientes multi-inquilinos no futuro.

Alguns clientes optam por utilizar mais do que um inquilino. Esta deve ser uma decisão cuidadosa e quase sempre condicionada pela razão comercial! Alguns exemplos incluem os seguintes motivos:

  • Uma estrutura empresarial de tipo de holding onde não é necessária uma colaboração fácil entre diferentes entidades e existem fortes necessidades administrativas e outras necessidades de isolamento.
  • Após uma aquisição, é tomada uma decisão empresarial para manter duas entidades separadas.
  • Simulação do ambiente de um cliente que não altera o ambiente de produção do cliente.
  • Desenvolvimento de software para clientes.

Nestes cenários multi-inquilinos, os clientes geralmente querem manter alguma configuração da mesma forma entre inquilinos ou comunicar alterações e desvios de configuração. Isto geralmente significa passar de alterações manuais para a configuração como código. O suporte do Microsoft Premiere oferece um workshop para estes tipos de requisitos com base neste IP público: https://Microsoft365dsc.com.

Multi-Geo

Para Multi-Geo ou não para Multi-Geo. Esta é a questão. Com o Microsoft 365 Multi-Geo, pode aprovisionar e armazenar dados inativos nas localizações geográficas que escolher para cumprir os requisitos de residência dos dados . Há muitos equívocos sobre esta capacidade. Tenha em atenção os seguintes pontos:

  • Não fornece benefícios de desempenho. Pode piorar o desempenho se a estrutura da rede não estiver correta. Coloque os dispositivos "perto" da rede da Microsoft, não necessariamente aos seus dados.
  • Não é uma solução para a conformidade com o RGPD. O RGPD não se concentra na soberania dos dados nem nas localizações de armazenamento. Existem outras arquiteturas de conformidade para a soberania de dados ou localizações de armazenamento.
  • Não resolve a delegação de administração (veja abaixo) nem barreiras de informação.
  • Não é o mesmo que multi-inquilino e requer mais fluxos de trabalho de aprovisionamento de utilizadores .
  • Não move o seu inquilino (o seu Microsoft Entra ID) para outra geografia.

Delegação de administração

Na maioria das grandes organizações, a separação de deveres e o controlo de acesso baseado em funções (RBAC) é uma realidade necessária. Vou pedir desculpas com antecedência. Esta atividade não é tão simples como alguns clientes querem. Os requisitos de cliente, legais, de conformidade e outros requisitos são diferentes e, por vezes, estão em conflito em todo o mundo. A simplicidade e a flexibilidade estão muitas vezes em lados opostos uns dos outros. Não me enganes, podemos fazer um trabalho melhor neste objectivo. Houve (e haverá) melhorias significativas ao longo do tempo. Visite o Centro de Tecnologia da Microsoft local para descobrir o modelo que se adequa aos seus requisitos empresariais sem ler 379.230 documentos! Aqui, foco-me no que deve pensar e não por que é assim. Seguem-se cinco áreas diferentes para planear e algumas das questões comuns que encontro.

Microsoft Entra ID e centros de administração do Microsoft 365

Há uma longa e crescente lista de funções incorporadas. Cada função consiste numa lista de permissões de função agrupadas para permitir a realização de ações específicas. Pode ver estas permissões no separador "Descrição" dentro de cada função. Em alternativa, pode ver uma versão mais legível por humanos destas permissões no Centro de Administração Microsoft 365. As definições para funções incorporadas não podem ser modificadas. Geralmente, agrupo estas funções em três categorias:

  • Administrador global: esta função "toda poderosa" deve ser altamente protegida tal como faria noutros sistemas. As recomendações típicas incluem: nenhuma atribuição permanente e utilização Microsoft Entra Privileged Identity Management (PIM); autenticação forte, etc. Curiosamente, esta função não lhe dá acesso a tudo por predefinição. Normalmente, vejo confusão sobre o acesso à conformidade e o acesso ao Azure, abordados mais tarde. No entanto, esta função pode sempre atribuir acesso a outros serviços no inquilino.
  • Administradores de serviço específicos: alguns serviços (Exchange, SharePoint, Power BI, etc.) consomem funções de administração de alto nível de Microsoft Entra ID. Este comportamento não é consistente em todos os serviços e mais funções específicas do serviço são abordadas mais tarde.
  • Funcional: existe uma longa (e crescente) lista de funções focadas em operações específicas (convidado convidado, etc.). Periodicamente, são adicionadas mais destas funções com base nas necessidades dos clientes.

Não é possível delegar tudo (embora a lacuna esteja a diminuir), o que significa que, por vezes, a função de Administrador global teria de ser utilizada. A configuração como código e a automatização devem ser consideradas em vez da associação de pessoas a esta função.

Nota: o centro de administração do Microsoft 365 tem uma interface mais simples de utilizar, mas tem um subconjunto de capacidades em comparação com a experiência de administrador Microsoft Entra. Ambos os portais utilizam as mesmas funções de Microsoft Entra, pelo que as alterações estão a ocorrer no mesmo local. Sugestão: se quiser uma IU de administração focada na gestão de identidades sem todo o correio secundário do Azure, utilize https://aad.portal.azure.com.

O que tem no nome? Não faça suposições a partir do nome da função. A linguagem não é uma ferramenta precisa. O objetivo deve ser definir operações que precisam de ser delegadas antes de analisar as funções necessárias. Adicionar alguém à função "Leitor de Segurança" não faz com que veja as definições de segurança em tudo.

A capacidade de criar funções personalizadas é uma questão comum. Esta capacidade é limitada em Microsoft Entra hoje (conforme explicado mais tarde), mas irá crescer em capacidades ao longo do tempo. Penso nestas funções personalizadas como aplicáveis às funções no Microsoft Entra ID e podem não abranger "abaixo" o modelo de hierarquia (conforme abordado anteriormente). Sempre que lido com "personalizado", costumo voltar ao meu director de "simples é melhor".

Outra questão comum é a capacidade de definir o âmbito das funções para um subconjunto de um diretório. Um exemplo é algo como "Administrador de Suporte Técnico apenas para utilizadores na UE". As Unidades Administrativas destinam-se a abordar este cenário. Conforme descrito anteriormente, penso nestes âmbitos como aplicáveis às funções no Microsoft Entra ID e podem não abranger "para baixo". Determinadas funções não fazem sentido para o âmbito (administradores globais, administradores de serviços, etc.).

Atualmente, todas estas funções requerem associação direta (ou atribuição dinâmica se utilizar Microsoft Entra PIM). Isto significa que os clientes têm de gerir estas funções diretamente no Microsoft Entra ID e estas funções não podem ser baseadas numa associação a um grupo de segurança. Não sou fã de criar scripts para gerir estas funções, pois teria de ser executada com direitos elevados. Geralmente, recomendo a integração de API com sistemas de processos como o ServiceNow ou a utilização de ferramentas de governação de parceiros, como o Saviynt. Há trabalhos de engenharia em curso para resolver este problema ao longo do tempo.

Mencionei Microsoft Entra PIM algumas vezes. Existe uma solução de Gestão de Acesso Privilegiado (PAM) de Microsoft Identity Manager correspondente (MIM) para controlos no local. Também poderá querer ver As Estações de Trabalho de Acesso Privilegiado (PAWs) e Microsoft Entra ID Governance. Também existem várias ferramentas de terceiros, que podem ativar a elevação de funções just-in-time, just-in-time e dinâmica. Normalmente, esta capacidade faz parte de um debate maior para proteger um ambiente.

Por vezes, os cenários exigem a adição de um utilizador externo a uma função (veja a secção multi-inquilino anterior). Este resultado funciona bem. Microsoft Entra B2B é outro artigo grande e divertido para acompanhar os clientes, talvez noutro artigo.

portais de conformidade do Microsoft Defender XDR e do Microsoft 365 Purview

Email & funções de Colaboração no portal do Microsoft Defender e *Grupos de funções para soluções do Microsoft Purview no portal de conformidade do Microsoft 365 Purview são uma coleção de "grupos de funções", que são separados e distintos das funções Microsoft Entra. Isto pode ser confuso porque alguns destes grupos de funções têm o mesmo nome que Microsoft Entra funções (por exemplo, Leitor de Segurança), mas podem ter uma associação diferente. Prefiro a utilização de Microsoft Entra funções. Cada grupo de funções consiste numa ou mais "funções" (veja o que quero dizer sobre reutilizar a mesma palavra?) e tem membros de Microsoft Entra ID, que são objetos ativados por e-mail. Além disso, pode criar um grupo de funções com o mesmo nome que uma função, que pode ou não conter essa função (evite esta confusão).

De certa forma, estas permissões são uma evolução do modelo de grupos de funções do Exchange. No entanto, Exchange Online tem a sua própria interface de gestão de grupos de funções. Alguns grupos de funções no Exchange Online são bloqueados e geridos a partir de Microsoft Entra ID ou dos portais de conformidade do Microsoft Defender XDR e do Microsoft 365 Purview, mas outros podem ter os mesmos nomes ou nomes semelhantes e são geridos no Exchange Online (aumentando a confusão). Recomendo que evite utilizar a interface de utilizador Exchange Online, a menos que precise de âmbitos para a gestão do Exchange.

Não pode criar funções personalizadas. As funções são definidas pelos serviços criados pela Microsoft e continuam a crescer à medida que novos serviços são introduzidos. Este comportamento é semelhante no conceito às funções definidas pelas aplicações no Microsoft Entra ID. Quando os novos serviços estão ativados, muitas vezes é necessário criar novos grupos de funções para conceder ou delegar acesso a estes (por exemplo, gestão de riscos internos.

Estes grupos de funções também necessitam de associação direta e não podem conter Microsoft Entra grupos. Infelizmente, hoje em dia estes grupos de funções não são suportados pelo Microsoft Entra PIM. Tal como Microsoft Entra funções, costumo recomendar a gestão destes grupos de funções através de APIs ou de um produto de governação de parceiros, como o Salvador, ou outros.

Microsoft Defender portal e as funções do portal de conformidade do Microsoft 365 Purview abrangem o Microsoft 365 e não pode definir estes grupos de funções para um subconjunto do ambiente (como pode fazer com unidades administrativas no Microsoft Entra ID). Muitos clientes perguntam como podem subdelegar. Por exemplo, "criar uma política DLP apenas para utilizadores da UE". Atualmente, se tiver direitos a uma função específica nos portais de conformidade do Microsoft Defender XDR e do Microsoft 365 Purview, terá direitos sobre tudo o que esta função abrange no inquilino. No entanto, muitas políticas têm capacidades para direcionar um subconjunto do ambiente (por exemplo, "disponibilizar estas etiquetas apenas a estes utilizadores"). A governação e a comunicação adequadas são um componente fundamental para evitar conflitos. Alguns clientes optam por implementar uma abordagem de "configuração como código" para resolver a sublegação nos portais de conformidade do Microsoft Defender XDR e do Microsoft 365 Purview. Alguns serviços específicos suportam a sub-subscrição (veja a secção seguinte).

Específico do Serviço

Conforme indicado anteriormente, muitos clientes procuram obter um modelo de delegação mais granular. Um exemplo comum: "Gerir o serviço XYZ apenas para utilizadores e localizações da Divisão X" (ou outra dimensão). A capacidade de o fazer depende de cada serviço e não é consistente entre serviços e capacidades. Além disso, cada serviço pode ter um modelo RBAC separado e exclusivo. Em vez de discutir todos estes modelos (o que demoraria uma eternidade), estou a adicionar ligações relevantes para cada serviço. Esta lista não está concluída, mas pode começar.

  • Exchange Online - (/exchange/permissions-exo/permissions-exo)
  • SharePoint Online - (/sharepoint/manage-site-collection-administrators)
  • Microsoft Teams - (/microsoftteams/itadmin-readiness)
  • Deteção de Dados Eletrónicos - (.. /compliance/index.yml)
    • Filtragem de Permissões - (.. /compliance/index.yml)
    • Limites de Conformidade - (.. /compliance/set-up-compliance-boundaries.md)
    • Deteção de Dados Eletrónicos (Premium) – (.. /compliance/overview-ediscovery-20.md)
  • Viva Engage - (/viva/engage/manage-viva-engage-users/manage-viva-engage-admins)
  • Multi-geo - (.. /enterprise/add-a-sharepoint-geo-admin.md)
  • Dynamics 365 – (/dynamics365/)

Nota

Esta ligação é para a raiz da documentação. Existem vários tipos de serviços com variações no modelo de administração/delegação.

  • Power Platform – (/power-platform/admin/admin-documentation)

    • Power Apps – (/power-platform/admin/wp-security)

      Nota

      existem vários tipos com variações nos modelos de administração/delegação.

    • Power Automate – (/power-automate/environments-overview-admin)

    • Power BI – (/power-bi/service-admin-governance)

      Nota: a segurança e delegação da plataforma de dados (que o Power BI é um componente) é uma área complexa.

  • Intune – (/mem/intune/fundamentals/role-based-access-control)

  • Microsoft Defender para Endpoint - (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

  • Microsoft Defender XDR - (.. /security/defender/m365d-permissions.md)

  • Microsoft Defender for Cloud Apps - (/cloud-app-security/manage-admins)

  • Fluxo - (/stream/assign-administrator-user-role)

  • Barreiras de informação - (.. /compliance/information-barriers.md)

Registos de Atividades

O Microsoft 365 tem um registo de auditoria unificado. É um registo muito detalhado, mas não leia muito sobre o nome. Pode não conter tudo o que pretende ou precisa para as suas necessidades de segurança e conformidade. Além disso, alguns clientes estão muito interessados em Auditoria (Premium).

Os exemplos de registos do Microsoft 365 que são acedidos através de outras APIs incluem as seguintes funcionalidades:

É importante identificar primeiro todas as origens de registo necessárias para um programa de segurança e conformidade. Tenha também em atenção que os diferentes registos têm diferentes limites de retenção na linha.

Do ponto de vista da delegação de administrador, a maioria dos registos de atividades do Microsoft 365 não tem um modelo RBAC incorporado. Se tiver permissão para ver um registo, pode ver tudo o que estiver nele. Um exemplo comum de um requisito do cliente é: "Quero ser capaz de consultar a atividade apenas para utilizadores da UE" (ou outra dimensão). Para cumprir este requisito, precisamos de transferir registos para outro serviço. Na cloud da Microsoft, recomendamos que a transfiram para o Microsoft Sentinel ou para o Log Analytics.

Diagrama de alto nível:

diagrama de origens de registo para um programa de segurança e conformidade.

O diagrama representa capacidades incorporadas para enviar registos para os Hubs de Eventos e/ou o Armazenamento do Azure e/ou o Log Analytics do Azure. Nem todos os sistemas incluem esta configuração inicial ainda. No entanto, existem outras abordagens para enviar estes registos para o mesmo repositório. Por exemplo, consulte Proteger o seu Teams com o Microsoft Sentinel.

Combinar todos os registos numa única localização de armazenamento inclui benefícios adicionais, tais como correlações cruzadas, tempos de retenção personalizados, aumento com dados necessários para suportar o modelo RBAC, etc. Assim que os dados estiverem neste sistema de armazenamento, pode criar um dashboard do Power BI (ou outro tipo de visualização) com um modelo RBAC adequado.

Os registos não têm de ser direcionados apenas para um local. Também pode ser vantajoso integrar os Registos do Microsoft 365 com Microsoft Defender for Cloud Apps ou um modelo RBAC personalizado no Power BI. Repositórios diferentes têm diferentes benefícios e audiências.

Vale a pena mencionar que existe um sistema de análise incorporado avançado para segurança, ameaças, vulnerabilidades, etc. num serviço chamado Microsoft Defender XDR.

Muitos clientes grandes querem transferir estes dados de registo para um sistema de terceiros (por exemplo, SIEM). Existem diferentes abordagens para este resultado, mas, em geral, Hubs de Eventos do Azure e Graph são bons pontos de partida.

Azure

Muitas vezes perguntam-me se existe uma forma de separar funções de privilégios elevados entre Microsoft Entra ID, Azure e SaaS (por exemplo: Administrador Global do Microsoft 365, mas não do Azure). Na verdade, não. A arquitetura multi-inquilino é necessária se for necessária uma separação administrativa completa, mas isso adiciona uma complexidade significativa (conforme abordado anteriormente). Todos estes serviços fazem parte do mesmo limite de segurança/identidade (conforme mostrado no modelo de hierarquia).

É importante compreender as relações entre vários serviços no mesmo inquilino. Estou a trabalhar com muitos clientes que estão a criar soluções empresariais que abrangem o Azure, o Microsoft 365 e o Power Platform (e, muitas vezes, também serviços cloud no local e de terceiros). Um exemplo comum:

  1. Quero colaborar num conjunto de documentos/imagens/etc. (Microsoft 365)
  2. Enviar cada um deles através de um processo de aprovação (Power Platform)
  3. Depois de todos os componentes serem aprovados, reúna estes itens num(s) material a entregar unificado (Azure) microsoft Graph API é o seu melhor amigo aqui. Não é impossível, mas significativamente mais complexo conceber uma solução que abrange vários inquilinos.

O Azure Role-Based Controlo de Acesso (RBAC) permite uma gestão de acesso detalhada para o Azure. Com o RBAC, pode gerir o acesso aos recursos ao conceder aos utilizadores o menor número de permissões necessárias para efetuar as suas tarefas. Os detalhes estão fora do âmbito deste documento, mas para obter mais informações sobre o RBAC, veja O que é o controlo de acesso baseado em funções (RBAC) no Azure? O RBAC é importante, mas apenas faz parte das considerações de governação do Azure. Cloud Adoption Framework é um excelente ponto de partida para saber mais. Gosto de como o meu amigo , Andres Ravinet, orienta os clientes passo a passo em vários componentes para decidir a abordagem. A vista de alto nível para vários elementos (não tão boa como o processo para chegar ao modelo de cliente real) é algo semelhante ao seguinte:

Vista de alto nível dos componentes do Azure para administração delegada.

Como pode ver na imagem acima, muitos outros serviços devem ser considerados como parte da estrutura (por exemplo: Políticas do Azure, Azure Blueprints, Grupos de Gestão, etc.).

Conclusão

Este artigo começou como um breve resumo, acabou por ser mais longo do que o esperado. Espero que esteja agora pronto para se aventurar numa visão aprofundada da criação do modelo de delegação para a sua organização. Esta conversação é muito comum com os clientes. Não existe um modelo que funcione para todos. A aguardar algumas melhorias planeadas da engenharia da Microsoft antes de documentar padrões comuns que vemos em todos os clientes. Entretanto, pode trabalhar com a equipa da sua conta Microsoft para organizar uma visita ao Centro de Tecnologia da Microsoft mais próximo. Até lá!