Compartilhar via

Para identidade e além do ponto de vista de um arquiteto

  • Artigo

Neste artigo, Alex Shteynberg, arquiteto técnico principal da Microsoft, discute as principais estratégias de design para organizações empresariais que adotam o Microsoft 365 e outros serviços de nuvem da Microsoft.

Sobre o autor

Alex Shteynberg foto.

Sou arquiteto técnico do Centro de Tecnologia da Microsoft de Nova York. Trabalho principalmente com clientes grandes e requisitos complexos. Meu ponto de vista e opiniões são baseados nessas 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 exclusivas, é interessante ver tendências e semelhanças. Por exemplo, uma tendência é o interesse entre setores para muitos clientes. Afinal, uma agência bancária também pode ser uma cafeteria e um centro comunitário.

Na minha função, foco em ajudar os clientes a chegar à melhor solução técnica para atender ao conjunto exclusivo de metas de negócios. Oficialmente, foco em Identidade, Segurança, Privacidade e Conformidade. Adoro o fato de que eles tocam tudo o que fazemos. Isso me dá a oportunidade de estar envolvido com a maioria dos projetos. Essa atividade me mantém ocupado e desfrutando dessa função.

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

Princípios orientadores

  • Simples geralmente é melhor: você pode fazer (quase) qualquer coisa com tecnologia, mas isso não significa que você deve. Especialmente no espaço de segurança, muitos clientes superengenharam soluções. Gosto deste vídeo da conferência Stripe do Google para sublinhar este ponto.
  • Pessoas, processo, tecnologia: projete para que as pessoas aprimorem o processo, não a tecnologia primeiro. Não há soluções "perfeitas". Precisamos equilibrar vários fatores de risco e decisões que podem ser diferentes para cada empresa. Muitos clientes projetam uma abordagem que seus usuários mais tarde evitam.
  • Concentre-se em "por que" primeiro e "como" mais tarde: seja o garoto irritante de 7 anos com um milhão de perguntas. Não podemos chegar à resposta certa se não soubermos as perguntas certas a serem feitas. Muitos clientes fazem suposições sobre como as coisas precisam funcionar em vez de definir o problema de negócios. Há sempre vários caminhos que podem ser tomados.
  • Cauda longa das práticas recomendadas passadas: reconheça que as práticas recomendadas estão mudando à velocidade da luz. Se você olhou para Microsoft Entra há mais de três meses, provavelmente está desatualizado. Tudo aqui está sujeito a alterações após a publicação. A opção "Melhor" hoje pode não ser a mesma daqui a seis meses.

Conceitos de linha de base

Não ignore esta seção. Muitas vezes acho que devo voltar a esses artigos, mesmo para clientes que usam serviços de nuvem há anos. Infelizmente, a linguagem não é uma ferramenta precisa. Muitas vezes usamos a mesma palavra para significar conceitos diferentes ou palavras diferentes para significar o mesmo conceito. Muitas vezes uso o diagrama a seguir para estabelecer alguma terminologia de linha de base e "modelo de hierarquia".

Ilustração de locatário, assinatura, serviço e dados.

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

No diagrama:

  • Locatário = uma instância de Microsoft Entra ID. Está no "topo" de uma hierarquia ou nível 1 no diagrama. Podemos considerar esse nível como o "limite" em que todo o resto ocorre (Microsoft Entra B2B à parte). Todos os serviços de nuvem empresarial da Microsoft fazem parte de um desses locatários. Os serviços de consumidor são separados. "Locatário" aparece na documentação como locatário do Microsoft 365, locatário do Azure, locatário do WVD e assim por diante. Muitas vezes acho que essas variações causam confusão para os clientes.
  • Serviços/assinaturas, Nível 2 no diagrama, pertencem a um único locatário. A maioria dos serviços SaaS é 1:1 e não pode se mover sem migração. O Azure é diferente, você pode mover a cobrança e/ou uma assinatura para outro locatário. Há muitos clientes que precisam mover assinaturas do Azure. Esse cenário tem várias implicações. Objetos que existem fora da assinatura não se movem. Por exemplo, o RBAC (controle de acesso baseado em função), objetos Microsoft Entra (grupos, aplicativos, políticas etc.) e alguns serviços (Azure Key Vault, Data Bricks etc.). Não migre serviços sem uma boa necessidade de negócios. Alguns scripts que podem ser úteis para migração são compartilhados no GitHub.
  • Um determinado serviço geralmente tem algum tipo de limite "subnível" ou nível 3 (L3). Esse limite é útil para entender a segregação de segurança, políticas, governança e assim por diante. Infelizmente, não há nenhum nome uniforme que eu saiba. Alguns exemplos de nomes para L3 são: Assinatura do Azure = recurso; Dynamics 365 ce = instância; Power BI = workspace; Power Apps = ambiente; e assim por diante.
  • O nível 4 é onde os dados reais vivem. Este "plano de dados" é um artigo complexo. Alguns serviços estão usando Microsoft Entra ID para RBAC, outros não. Discutirei um pouco quando chegarmos aos artigos da delegação.

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

  • Qualquer pessoa pode criar muitos locatários sem nenhum custo. Você não precisa de um serviço provisionado dentro dele. Tenho dezenas. Cada nome de locatário é exclusivo no serviço de nuvem mundial da Microsoft (em outras palavras, nenhum locatário pode ter o mesmo nome). Eles estão todos no formato de TenantName.onmicrosoft.com. Há também processos que criam locatários automaticamente (locatários não gerenciados). Por exemplo, esse resultado pode acontecer quando um usuário se inscreve em um serviço corporativo com um domínio de email que não existe em nenhum outro locatário.
  • Em um locatário gerenciado, muitos domínios DNS podem ser registrados nele. Esse resultado não altera o nome do locatário original. No momento, não há uma maneira fácil de renomear um locatário (além da migração). Embora o nome do locatário não seja tecnicamente crítico nos dias de hoje, algumas pessoas podem se sentir limitadas por essa realidade.
  • Você deve reservar um nome de locatário para sua organização, mesmo que ainda não esteja planejando implantar nenhum serviço. Caso contrário, alguém pode tirá-lo de você e não há nenhum processo simples para recuperá-lo (mesmo problema que nomes DNS). Ouço isso com muita frequência dos clientes. O nome do locatário também deve ser um artigo de debate.
  • Se você possui um namespace DNS, deve adicionar todos esses namespaces aos seus locatários. Caso contrário, pode-se criar um locatário não gerenciado com esse nome, o que causa interrupção para torná-lo gerenciado.
  • Um namespace DNS (por exemplo, contoso.com) pode pertencer a um único locatário. Esse requisito tem implicações para vários cenários (por exemplo, compartilhar um domínio de email durante uma fusão ou aquisição e assim por diante). Há uma maneira de registrar um sub DNS (como div.contoso.com) em um locatário diferente, mas isso deve ser evitado. Ao registrar um nome de domínio de nível superior, todos os subdomínios devem pertencer ao mesmo locatário. Em cenários de vários locatários (conforme explicado a seguir) normalmente recomendaria usar outro nome de domínio de nível superior (como contoso.ch ou ch-contoso.com).
  • Quem deve "possuir" um locatário? Muitas vezes vejo clientes que não sabem quem atualmente possui seu locatário. Essa falta de conhecimento é um sinalizador vermelho significativo. Chame 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 gerenciar um locatário. O locatário contém todos os serviços que você pode querer no futuro. O proprietário do locatário deve ser um grupo que pode tomar uma decisão para habilitação de todos os serviços de nuvem em uma organização. Outro problema é quando um grupo de proprietários de locatários é solicitado a gerenciar todos os serviços. Esse método não é dimensionado para organizações grandes.
  • Não há nenhum conceito de um sub/super locatário. Por algum motivo, esse mito continua se repetindo. Esse conceito também se aplica aos locatários B2C do Azure Active Directory . Ouço muitas vezes: "Meu ambiente B2C está no meu locatário XYZ", ou "Como fazer mover meu locatário do Azure para o meu locatário do Microsoft 365?"
  • Este documento se concentra principalmente na nuvem comercial em todo o mundo, porque é isso que a maioria dos clientes está usando. Às vezes é útil saber sobre nuvens soberanas. Nuvens soberanas têm outras implicações a discutir que estão fora do escopo dessa discussão.

Artigos de identidade de linha de base

Há muita documentação sobre a plataforma de identidade da Microsoft – Microsoft Entra ID. Para as pessoas que estão apenas começando, muitas vezes parece esmagador. Mesmo depois de aprender sobre isso, acompanhar as constantes inovações e mudanças pode ser um desafio. Em minhas interações com o cliente, muitas vezes me vejo servindo como "tradutor" entre metas de negócios e abordagens "Boa, Melhor, Melhor" para resolver essas preocupações (e "notas de penhasco" humanas para esses artigos). Raramente há uma resposta perfeita e a decisão "certa" é um equilíbrio de vários fatores de risco. Em seguida, estão algumas das questões comuns e áreas de confusão que costumo discutir com os clientes.

Provisionamento

Microsoft Entra ID não resolve por falta de governança em seu mundo de identidade! A governança de identidade deve ser um elemento crítico independente de qualquer decisão na nuvem. Os requisitos de governança mudam ao longo do tempo, razão pela qual é um programa e não uma ferramenta.

Microsoft Entra Connect vs. Microsoft Identity Manager (MIM) vs. outra coisa (terceiros ou personalizados)? Salve-se de problemas agora e no futuro e vá com Microsoft Entra Connect. Há todos os tipos de inteligência nesta ferramenta para lidar com configurações peculiares do cliente e inovações contínuas.

Alguns casos de borda que podem gerar uma arquitetura mais complexa:

  • Tenho várias florestas do AD sem conectividade de rede entre elas. Há uma nova opção chamada Provisionamento de Nuvem.
  • Não tenho o Active Directory, nem quero instalá-lo. Microsoft Entra Connect pode ser configurado para sincronizar com o LDAP (o parceiro pode ser necessário).
  • Preciso provisionar os mesmos objetos para vários locatários. Esse cenário não tem suporte tecnicamente, mas depende da definição de "mesmo".

Devo personalizar regras de sincronização padrão (filtrar objetos, alterar atributos, ID de logon alternativo e assim por diante)? Evite! Uma plataforma de identidade é tão valiosa quanto os serviços que a usam. Embora você possa fazer todos os tipos de configurações malucas, para responder a essa pergunta, você precisa examinar o efeito sobre os aplicativos. Se você filtrar objetos habilitados para email, o GAL para serviços online estiver incompleto; se o aplicativo depender de atributos específicos, filtrar esses atributos terá efeitos imprevisíveis; e assim por diante. Não é uma decisão da equipe de identidade.

O XYZ SaaS dá suporte ao provisionamento just-in-time (JIT), por que você está exigindo que eu sincronize? Consulte o parágrafo anterior. Muitos aplicativos precisam de informações de "perfil" para funcionalidade. Não é possível ter uma GAL se todos os objetos habilitados para email não estiverem disponíveis. O mesmo se aplica ao provisionamento de usuário em aplicativos integrados ao Microsoft Entra ID.

Autenticação

PHS (sincronização de hash de senha ) vs. autenticação de passagem (PTA) vs. federação.

Normalmente há um debate apaixonado em torno da federação. Mais simples geralmente é melhor e, portanto, use PHS, a menos que você tenha uma boa razão para não fazer isso. Também é possível configurar diferentes métodos de autenticação para diferentes domínios DNS no mesmo locatário.

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

Muitas vezes passo os clientes pelo fluxo de autenticação do cliente para esclarecer alguns equívocos. O resultado se parece com a imagem a seguir, que não é tão boa quanto o processo interativo de chegar lá.

Exemplo de conversa de quadro de dados.

Esse tipo de desenho de quadro ilustra onde as políticas de segurança são aplicadas no fluxo de uma solicitação de autenticação. Neste exemplo, as políticas impostas por meio do AD FS (Active Directory Federation Service) são aplicadas à primeira solicitação de serviço, mas não às solicitações de serviço subsequentes. Esse comportamento é pelo menos um motivo para mover controles de segurança para a nuvem o máximo possível.

Estamos perseguindo o sonho do SSO ( logon único ) desde que me lembro. Alguns clientes acreditam que podem obter logon único escolhendo o provedor de STS (federação "certa"). Microsoft Entra ID pode ajudar significativamente a habilitar recursos de SSO, mas nenhuma STS é mágica. Há muitos métodos de autenticação "herdados" que ainda são usados para aplicativos críticos. Estender Microsoft Entra ID com soluções de parceiros pode resolver muitos desses cenários. O SSO é uma estratégia e uma jornada. Você não pode chegar lá sem se mover para padrões para aplicativos. Relacionado a este artigo está uma jornada para a autenticação sem senha , que também não tem uma resposta mágica.

A MFA (autenticação multifator) é essencial hoje (aqui para mais). Adicione a ele análise de comportamento do usuário e você tem uma solução que impede a maioria dos ataques cibernéticos comuns. Mesmo os serviços de consumidores estão se movendo para exigir MFA. No entanto, ainda me encontro com muitos clientes que não querem mudar para abordagens modernas de autenticação . O maior argumento que ouço é que isso afeta usuários e aplicativos herdados. Às vezes, um bom pontapé pode ajudar os clientes a seguir em frente - Exchange Online alterações anunciadas. Muitos relatórios Microsoft Entra agora estão disponíveis para ajudar os clientes nessa transição.

Authorization

De acordo com a Wikipédia, "autorizar" é definir uma política de acesso. Muitas pessoas olham para ele como a capacidade de definir controles de acesso a um objeto (arquivo, serviço e assim por diante). No mundo atual de ameaças cibernéticas, esse conceito está evoluindo rapidamente para uma política dinâmica que pode reagir a vários vetores de ameaças e ajustar rapidamente os controles de acesso em resposta a eles. Por exemplo, se eu acessar minha conta bancária de um local incomum, recebo etapas extras de confirmação. Para abordar essa realidade, precisamos considerar não apenas a política em si, mas o ecossistema de metodologias de detecção de ameaças e correlação de sinais.

O mecanismo de política do Microsoft Entra ID é implementado usando políticas de Acesso Condicional. Esse sistema depende de informações de outros sistemas de detecção de ameaças para tomar decisões dinâmicas. Uma exibição simples seria algo como a seguinte ilustração:

Mecanismo de política no Microsoft Entra ID.

Combinar todos esses sinais permite políticas dinâmicas como estas:

  • Se uma ameaça for detectada em seu dispositivo, seu acesso aos dados será reduzido à Web somente sem a capacidade de baixar.
  • Se você estiver baixando um volume extraordinariamente alto de dados, qualquer coisa que você baixar será criptografada e restrita.
  • Se você acessar um serviço de um dispositivo não gerenciado, será bloqueado de dados altamente confidenciais, mas autorizado a acessar dados não restritos sem a capacidade de copiá-los para outro local.

Se você concordar com essa definição expandida de autorização, precisará implementar soluções adicionais. Quais soluções você implementa depende da dinâmica que você deseja que a política seja e quais ameaças você deseja priorizar. Alguns exemplos desses sistemas são:

Além de Microsoft Entra ID, vários serviços e aplicativos têm seus próprios modelos de autorização específicos. Alguns desses modelos são discutidos posteriormente na seção delegação.

Auditoria

Microsoft Entra ID tem recursos detalhados de auditoria e relatórios. No entanto, esses relatórios normalmente não são a única fonte de informações necessárias para tomar decisões de segurança. Confira mais discussões sobre esse assunto na seção delegação.

Não há exchange

Não entre em pânico! O Exchange não está sendo preterido (ou SharePoint e assim por diante). Ainda é um serviço principal. O que quero dizer é que, há algum tempo, os provedores de tecnologia têm feito a transição de experiências de usuário (UX) para abranger componentes de vários serviços. No Microsoft 365, um exemplo simples é "anexos modernos" em que anexos ao email são armazenados no SharePoint Online ou no OneDrive.

Anexando um arquivo a um email.

Olhando para o cliente do Outlook, você pode ver muitos serviços que estão "conectados" como parte dessa experiência, não apenas o Exchange. Exemplos incluem Microsoft Entra ID, Microsoft Search, Aplicativos, Perfil, conformidade e grupos do Microsoft 365.

Interface do Outlook com chamadas.

Leia sobre Microsoft Fluid Framework para visualização dos próximos recursos. Na versão prévia agora, posso ler e responder às conversas do Teams diretamente no Outlook. Na verdade, o cliente do Teams é um dos exemplos mais proeminentes dessa estratégia.

No geral, está se tornando mais difícil desenhar uma linha clara entre o Microsoft 365 e outros serviços nas nuvens da Microsoft. Vejo isso como um grande benefício para os clientes, pois eles podem se beneficiar da inovação total em tudo o que fazemos, mesmo que eles usem um componente. Muito legal e tem implicações de longo alcance para muitos clientes.

Hoje, acho que muitos grupos de TI do cliente estão estruturados em torno de "produtos". É lógico para um mundo local, pois você precisa de um especialista para cada produto específico. No entanto, estou feliz por não precisar depurar um banco de dados do Active Directory ou do Exchange nunca mais, pois esses serviços se mudaram para a nuvem. A automação (que a nuvem basicamente é) remove determinados trabalhos manuais repetitivos (veja o que aconteceu com as fábricas). No entanto, essas tarefas são substituídas por requisitos mais complexos para entender a interação entre serviços, o efeito, as necessidades de negócios e assim por diante. Se você estiver disposto a aprender, há grandes oportunidades habilitadas pela transformação na nuvem. Antes de entrar em tecnologia, muitas vezes converso com os clientes sobre como gerenciar mudanças nas habilidades de TI e estruturas de equipe.

Para todos os fãs e desenvolvedores do SharePoint, pare de perguntar "Como posso fazer XYZ no SharePoint Online?" Use o Power Automate (ou Flow) para fluxo de trabalho, é uma plataforma muito mais poderosa. Use o Azure Bot Framework para criar um UX melhor para sua lista de itens de 500 K. Comece a usar o Microsoft Graph em vez de CSOM. O Microsoft Teams inclui o SharePoint, mas também um mundo a mais. Há 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. Essa abordagem entre serviços parece confundir completamente muitas políticas de conformidade. Continuo vendo organizações que afirmam: "Preciso publicar todas as comunicações de email em um sistema de descoberta eletrônica." O que essa instrução realmente significa quando o email não é mais apenas email, mas uma janela para outros serviços? O Microsoft 365 tem uma abordagem abrangente para conformidade, mas a mudança de pessoas e processos geralmente é muito mais difícil do que a tecnologia.

Há muitas outras pessoas e implicações no processo. Na minha opinião, esse fator é uma área crítica e sub-discutida. Talvez mais em outro artigo.

Opções de estrutura de locatário

Locatário único versus multilocatário

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

Muitos clientes acabam com vários locatários de produção após uma fusão e aquisição (M&A) e querem se consolidar. Hoje isso não é simples e exigiria o MCS (Serviços de Consultoria da Microsoft) ou um parceiro mais software de terceiros. Há um trabalho de engenharia em andamento para resolver vários cenários com clientes multilocatários no futuro.

Alguns clientes optam por ir com mais de um locatário. Essa deve ser uma decisão cuidadosa e quase sempre orientada por motivos de negócios! Alguns exemplos incluem os seguintes motivos:

  • Uma estrutura de empresa de tipo de holding em que a colaboração fácil entre diferentes entidades não é necessária e há fortes necessidades administrativas e outras necessidades de isolamento.
  • Após uma aquisição, uma decisão comercial é tomada 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.

Nesses cenários de vários locatários, os clientes geralmente querem manter alguma configuração igual entre locatários ou relatar alterações e desvios de configuração. Isso geralmente significa passar de alterações manuais para configuração como código. O suporte ao Microsoft Premiere oferece um workshop para esses tipos de requisitos com base neste IP público: https://Microsoft365dsc.com.

Multi-Geo

Para Multi-Geo ou não para Multi-Geo. Essa é a pergunta. Com o Microsoft 365 Multi-Geo, você pode provisionar e armazenar dados em repouso nas localizações geográficas escolhidas para atender aos requisitos de residência de dados . Há muitos equívocos sobre essa funcionalidade. Lembre-se dos seguintes pontos:

  • Ele não fornece benefícios de desempenho. Isso pode piorar o desempenho se o design de rede não estiver correto. Obter dispositivos "próximos" à rede microsoft, não necessariamente aos seus dados.
  • Não é uma solução para conformidade com GDPR. O GDPR não se concentra na soberania de dados ou em locais de armazenamento. Há outras estruturas de conformidade para a soberania de dados ou locais de armazenamento.
  • Ele não resolve a delegação de administração (veja abaixo) ou barreiras de informações.
  • Ele não é o mesmo que vários locatários e requer mais fluxos de trabalho de provisionamento de usuários .
  • Ele não move seu locatário (seu Microsoft Entra ID) para outra geografia.

Delegação de administração

Na maioria das grandes organizações, a separação de tarefas e o RBAC (controle de acesso baseado em função) é uma realidade necessária. Vou me desculpar antes do tempo. Essa atividade não é tão simples quanto alguns clientes querem que seja. Clientes, legais, conformidade e outros requisitos são diferentes e, às vezes, conflitantes em todo o mundo. Simplicidade e flexibilidade geralmente estão em lados opostos um do outro. Não me entenda mal, podemos fazer um trabalho melhor neste objetivo. Houve (e haverá) melhorias significativas ao longo do tempo. Visite o Centro de Tecnologia da Microsoft local para descobrir o modelo que atende aos seus requisitos de negócios sem ler 379.230 documentos! Aqui, eu me concentro no que você deve pensar e não por que é assim. A seguir estão cinco áreas diferentes para planejar e algumas das perguntas comuns que encontro.

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

Há uma longa e crescente lista de funções internas. Cada função consiste em uma lista de permissões de função agrupadas para permitir que ações específicas sejam executadas. Você pode ver essas permissões na guia "Descrição" dentro de cada função. Como alternativa, você pode ver uma versão mais legível humana dessas permissões no Centro de Administração Microsoft 365. As definições para funções internas não podem ser modificadas. Geralmente, agrupo essas funções em três categorias:

  • Administrador global: essa função "toda poderosa" deve ser altamente protegida, assim como você faria em outros sistemas. As recomendações típicas incluem: nenhuma atribuição permanente e uso Microsoft Entra Privileged Identity Management (PIM); autenticação forte; e assim por diante. Curiosamente, essa função não lhe dá acesso a tudo por padrão. Normalmente, vejo confusão sobre o acesso à conformidade e o acesso ao Azure, discutidos posteriormente. No entanto, essa função sempre pode atribuir acesso a outros serviços no locatário.
  • Administradores de serviço específicos: alguns serviços (Exchange, SharePoint, Power BI e assim por diante) consomem funções de administração de alto nível de Microsoft Entra ID. Esse comportamento não é consistente em todos os serviços e há mais funções específicas de serviço discutidas posteriormente.
  • Funcional: há uma longa (e crescente) lista de funções focadas em operações específicas (convidado e assim por diante). Periodicamente, mais dessas funções são adicionadas com base nas necessidades do cliente.

Não é possível delegar tudo (embora a lacuna esteja diminuindo), o que significa que a função de administrador global precisaria ser usada às vezes. A configuração como código e a automação devem ser consideradas em vez da associação de pessoas a essa função.

Observação: o Centro de administração do Microsoft 365 tem uma interface mais amigável ao usuário, mas tem um subconjunto de recursos em comparação com a experiência de administrador Microsoft Entra. Ambos os portais usam as mesmas funções Microsoft Entra, portanto, as alterações estão ocorrendo no mesmo lugar. Dica: se você quiser uma interface do usuário de administrador focada em gerenciamento de identidade sem toda a desordem do Azure, use https://aad.portal.azure.com.

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

A capacidade de criar funções personalizadas é uma questão comum. Essa funcionalidade é limitada em Microsoft Entra hoje (como explicado posteriormente), mas crescerá em recursos ao longo do tempo. Penso nessas funções personalizadas conforme aplicável às funções em Microsoft Entra ID e pode não abranger "para baixo" o modelo de hierarquia (como discutido anteriormente). Sempre que lido com "personalizado", costumo voltar para minha diretora de "simples é melhor".

Outra questão comum é a capacidade de escopo de funções para um subconjunto de um diretório. Um exemplo é algo como "Administrador do Helpdesk para usuários somente na UE". As Unidades Administrativas destinam-se a resolver esse cenário. Como descrito anteriormente, penso nesses escopos como aplicáveis a funções em Microsoft Entra ID e podem não se estender "para baixo". Determinadas funções não fazem sentido para escopo (administradores globais, administradores de serviço e assim por diante).

Hoje, todas essas funções exigem associação direta (ou atribuição dinâmica se você usar Microsoft Entra PIM). Isso significa que os clientes devem gerenciar essa função diretamente no Microsoft Entra ID e essas funções não podem ser baseadas em uma associação de grupo de segurança. Não sou fã de criar scripts para gerenciar essas funções, pois ela precisaria ser executada com direitos elevados. Geralmente, recomendo a integração da API com sistemas de processo como o ServiceNow ou o uso de ferramentas de governança de parceiros como o Saviynt. Há um trabalho de engenharia acontecendo para resolver esse problema ao longo do tempo.

Mencionei Microsoft Entra PIM algumas vezes. Há uma solução PAM (Gerenciamento de Acesso Privilegiado) de Microsoft Identity Manager (MIM) correspondente para controles locais. Você também pode querer examinar PAWs (Estações de Trabalho de Acesso Privilegiado) e Microsoft Entra ID Governance. Há várias ferramentas de terceiros também, que podem habilitar a elevação de função just-in-time, just-enough e dinâmica. Essa funcionalidade geralmente faz parte de uma discussão maior para proteger um ambiente.

Às vezes, os cenários exigem a adição de um usuário externo a uma função (consulte a seção multilocatário anterior). Esse resultado funciona bem. Microsoft Entra B2B é outro artigo grande e divertido para orientar os clientes, talvez em outro artigo.

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

Email & funções de colaboração no portal 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. Isso pode ser confuso porque alguns desses grupos de funções têm o mesmo nome que Microsoft Entra funções (por exemplo, Leitor de Segurança), mas podem ter associação diferente. Prefiro o uso de Microsoft Entra funções. Cada grupo de funções consiste em uma 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 habilitados para email. Além disso, você pode criar um grupo de funções com o mesmo nome de uma função, que pode ou não conter essa função (evite essa confusão).

De certa forma, essas permissões são uma evolução do modelo de grupos de função do Exchange. No entanto, Exchange Online tem sua própria interface de gerenciamento de grupo de funções. Alguns grupos de funções no Exchange Online são bloqueados e gerenciados 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 semelhantes e são gerenciados em Exchange Online (aumentando a confusão). Recomendo que você evite usar a interface do usuário Exchange Online, a menos que precise de escopos para o gerenciamento do Exchange.

Você não pode criar funções personalizadas. As funções são definidas pelos serviços criados pela Microsoft e continuam crescendo à medida que novos serviços são introduzidos. Esse comportamento é semelhante no conceito às funções definidas por aplicativos em Microsoft Entra ID. Quando novos serviços estão habilitados, geralmente novos grupos de funções precisam ser criados para conceder ou delegar acesso a esses (por exemplo, gerenciamento de risco interno.

Esses grupos de funções também exigem associação direta e não podem conter grupos de Microsoft Entra. Infelizmente, hoje esses grupos de funções não têm suporte Microsoft Entra PIM. Como Microsoft Entra funções, costumo recomendar o gerenciamento desses grupos de funções por meio de APIs ou de um produto de governança de parceiros como o Saviynt ou outros.

Microsoft Defender portal e as funções do portal de conformidade do Microsoft 365 Purview abrangem o Microsoft 365 e você não pode escopo desses grupos de funções para um subconjunto do ambiente (como você pode com unidades administrativas em Microsoft Entra ID). Muitos clientes perguntam como podem subdelegar. Por exemplo, "crie uma política DLP apenas para usuários da UE". Hoje, se você tiver direitos a uma função específica nos portais de conformidade do Microsoft Defender XDR e do Microsoft 365 Purview, terá direitos a tudo que estiver coberto por essa função no locatário. No entanto, muitas políticas têm recursos para direcionar um subconjunto do ambiente (por exemplo, "disponibilizar esses rótulos apenas para esses usuários"). A governança 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 abordar a subdelegação nos portais de conformidade do Microsoft Defender XDR e do Microsoft 365 Purview. Alguns serviços específicos dão suporte à subdelegação (confira a próxima seção).

Específico do serviço

Como declarado anteriormente, muitos clientes estão procurando alcançar um modelo de delegação mais granular. Um exemplo comum: "Gerenciar o serviço XYZ somente para usuários e locais da Divisão X" (ou alguma outra dimensão). A capacidade de fazer isso depende de cada serviço e não é consistente entre serviços e recursos. Além disso, cada serviço pode ter um modelo RBAC separado e exclusivo. Em vez de discutir todos esses modelos (o que levaria uma eternidade), estou adicionando links 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)
  • eDiscovery - (.. /compliance/index.yml)
    • Filtragem de permissões – (.. /compliance/index.yml)
    • Limites de conformidade – (.. /compliance/set-up-compliance-boundaries.md)
    • descoberta eletrônica (Premium) – (.. /compliance/overview-ediscovery-20.md)
  • Viva Engage - (/viva/engage/manage-viva-engage-users/manage-viva-engage-admins)
  • Multi-geográfico – (.. /enterprise/add-a-sharepoint-geo-admin.md)
  • Dynamics 365 – (/dynamics365/)

Observação

Esse link é para a raiz da documentação. Há vários tipos de serviços com variações no modelo de administrador/delegação.

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

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

      Observação

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

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

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

      Observação: a segurança e a 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 Ponto de Extremidade - (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

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

  • Microsoft Defender para Aplicativos de Nuvem - (/cloud-app-security/manage-admins)

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

  • Barreiras de informações – (.. /compliance/information-barriers.md)

Logs de atividades

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

Exemplos de logs do Microsoft 365 acessados por meio de outras APIs incluem os seguintes recursos:

É importante primeiro identificar todas as fontes de log necessárias para um programa de segurança e conformidade. Observe também que os logs diferentes têm limites de retenção on-line diferentes.

Na perspectiva da delegação de administradores, a maioria dos logs de atividades do Microsoft 365 não tem um modelo RBAC interno. Se você tiver permissão para ver um log, poderá ver tudo nele. Um exemplo comum de um requisito do cliente é: "Quero poder consultar a atividade apenas para usuários da UE" (ou alguma outra dimensão). Para atingir esse requisito, precisamos transferir logs para outro serviço. Na nuvem da Microsoft, recomendamos transferi-lo para o Microsoft Sentinel ou o Log Analytics.

Diagrama de alto nível:

diagrama de fontes de log para um programa de segurança e conformidade.

O diagrama representa recursos internos para enviar logs para Hubs de Eventos e/ou Armazenamento do Azure e/ou Azure Log Analytics. Nem todos os sistemas incluem este fora da caixa ainda. Mas há outras abordagens para enviar esses logs para o mesmo repositório. Por exemplo, consulte Proteger suas Equipes com o Microsoft Sentinel.

A combinação de todos os logs em um local de armazenamento inclui benefício adicional, como correlações cruzadas, tempos de retenção personalizados, aumento com dados necessários para dar suporte ao modelo RBAC e assim por diante. Depois que os dados estiverem neste sistema de armazenamento, você poderá criar um Power BI dashboard (ou outro tipo de visualização) com um modelo RBAC apropriado.

Os logs não precisam ser direcionados apenas para um só lugar. Também pode ser benéfico integrar logs do Microsoft 365 com Microsoft Defender para Aplicativos de Nuvem ou um modelo RBAC personalizado no Power BI. Repositórios diferentes têm diferentes benefícios e audiências.

Vale mencionar que há um sistema de análise interno avançado para segurança, ameaças, vulnerabilidades e assim por diante em um serviço chamado Microsoft Defender XDR.

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

Azure

Muitas vezes me perguntam se há uma maneira de separar funções de alto privilégio entre Microsoft Entra ID, Azure e SaaS (ex.: Administrador global do Microsoft 365, mas não o Azure). Nem por isso. A arquitetura de vários locatários é necessária se a separação administrativa completa for necessária, mas isso adiciona complexidade significativa (conforme discutido anteriormente). Todos esses serviços fazem parte do mesmo limite de segurança/identidade (conforme mostrado no modelo de hierarquia).

É importante entender as relações entre vários serviços no mesmo locatário. Estou trabalhando com muitos clientes que estão criando soluções de negócios que abrangem o Azure, o Microsoft 365 e o Power Platform (e muitas vezes também serviços de nuvem locais e de terceiros). Um exemplo comum:

  1. Quero colaborar em um conjunto de documentos/imagens/etc (Microsoft 365)
  2. Enviar cada um deles por meio de um processo de aprovação (Power Platform)
  3. Depois que todos os componentes forem aprovados, monte esses itens em um Microsoft API do Graph é seu melhor amigo aqui. Não impossível, mas significativamente mais complexo para projetar uma solução que abrange vários locatários.

O RBAC (Azure Role-Based Controle de Acesso) permite o gerenciamento de acesso refinado para o Azure. Usando o RBAC, você pode gerenciar o acesso aos recursos concedendo aos usuários o menor número de permissões necessárias para executar seus trabalhos. Os detalhes estão fora do escopo deste documento, mas para obter mais informações sobre RBAC, confira O que é o RBAC (controle de acesso baseado em função) no Azure? O RBAC é importante, mas apenas parte das considerações de governança para o Azure. Cloud Adoption Framework é um ótimo ponto de partida para saber mais. Gosto de como meu amigo, Andres Ravinet, orienta os clientes passo a passo por vários componentes para decidir sobre a abordagem. A exibição de alto nível para vários elementos (não tão bom quanto o processo para chegar ao modelo de cliente real) é algo assim:

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

Como você pode ver na imagem acima, muitos outros serviços devem ser considerados como parte do design (ex.: Políticas do Azure, Blueprints do Azure, Grupos de Gerenciamento e assim por diante).

Conclusão

Este artigo começou como um resumo curto, acabou por mais tempo do que eu esperava. Espero que agora você esteja pronto para se aventurar em uma visão profunda da criação de modelo de delegação para sua organização. Essa conversa é muito comum com os clientes. Não há nenhum modelo que funcione para todos. Aguardando algumas melhorias planejadas da engenharia da Microsoft antes de documentar padrões comuns que vemos entre clientes. Enquanto isso, você pode trabalhar com sua equipe de conta da Microsoft para organizar uma visita ao Centro de Tecnologia da Microsoft mais próximo. Até lá!