Microsoft Entra ID, Tipos de Identidade e Ambientes Híbridos

radio_button_uncheckedshort_text 1. Introdução

Os primeiros sistemas corporativos de identidade nasceram em um mundo no qual usuários, computadores e servidores permaneciam, em grande parte, dentro da rede da empresa. Diretórios locais, especialmente o Active Directory Domain Services , tornaram possível centralizar contas, computadores, grupos e políticas. A adoção de serviços em nuvem, dispositivos móveis, aplicativos SaaS e trabalho remoto mudou esse cenário: a identidade precisava acompanhar o usuário e a aplicação além do domínio físico da organização. O Microsoft Entra ID surgiu dessa transição, inicialmente como Windows Azure Active Directory , depois Azure Active Directory e, desde 2023, com a marca atual.

Compreender essa evolução ajuda o leitor a perceber por que identidade não é apenas “criar usuários”. Uma plataforma moderna de IAM precisa representar pessoas, dispositivos, aplicativos, automações, parceiros e agentes de IA; autenticar cada entidade; emitir tokens ; aplicar políticas; registrar atividades; e manter o ciclo de vida coerente. Para a sociedade, esse modelo sustenta colaboração remota, serviços digitais, educação on-line, saúde conectada, governo digital e transações financeiras com maior controle e rastreabilidade.

Ao longo deste capítulo, a pergunta central será: como uma organização representa, conecta e governa entidades tão diferentes sem multiplicar credenciais, privilégios e pontos cegos? A resposta começa no tenant do Microsoft Entra ID , passa pelos objetos de identidade e chega aos cenários híbridos e externos. Entender essas relações evita a memorização superficial e permite resolver questões do SC-900 por raciocínio.

Ideia-guia do capítulo

Uma identidade é a representação de uma entidade; um principal de segurança é uma identidade capaz de receber permissões; um tenant é a fronteira lógica na qual essas identidades, políticas, consentimentos e registros são administrados.

radio_button_uncheckedshort_text 2. Breve evolução: do diretório local ao Microsoft Entra

O Active Directory Domain Services , introduzido com o Windows 2000 Server, consolidou um modelo de diretório empresarial baseado em domínios, florestas, unidades organizacionais, controladores de domínio e protocolos como Kerberos e LDAP. Esse modelo continua essencial para muitas organizações, sobretudo em estações Windows, servidores locais, políticas de grupo e aplicações legadas. Contudo, ele foi projetado para um ambiente em que o domínio corporativo e a conectividade com controladores de domínio eram referências centrais.

Quando o Microsoft 365 e o Azure passaram a hospedar aplicações e dados fora da rede local, tornou-se necessário um serviço de identidade nativo da nuvem. O Windows Azure Active Directory foi lançado como esse serviço. Apesar do nome histórico, ele não era simplesmente “um Active Directory hospedado”: sua arquitetura foi construída para autenticação baseada em Internet, APIs , aplicações modernas, tokens e múltiplos tenants. O nome Azure Active Directory foi substituído por Microsoft Entra ID para reduzir essa confusão e posicionar o produto dentro de uma família mais ampla de identidade e acesso.

A mudança de nome não removeu integrações nem alterou automaticamente licenças e configurações. Ela reforçou uma diferença conceitual importante para o exame: AD DS é um serviço de diretório de domínio tradicional; Microsoft Entra ID é um serviço de gerenciamento de identidade e acesso baseado em nuvem. Eles podem coexistir e formar uma identidade híbrida, mas não são o mesmo produto.

radio_button_uncheckedshort_text 3. A família Microsoft Entra

Microsoft Entra é a família de produtos da Microsoft voltada a identidade, acesso, governança e segurança de conexões. O Entra ID é seu produto fundamental: autentica usuários e cargas de trabalho, emite tokens , aplica políticas e mantém objetos do diretório. Outros produtos ampliam esse núcleo para necessidades específicas, como governança de ciclo de vida, colaboração externa, acesso de rede, identidades de aplicações e agentes de IA.

Foco do SC-900

O exame não exige administrar profundamente todos os produtos. Ele exige reconhecer sua finalidade e, neste capítulo, compreender a função do Entra ID e os tipos de identidade que ele representa.

radio_button_uncheckedshort_text 4. O que é o Microsoft Entra ID

Microsoft Entra ID é o serviço de gerenciamento de identidade e acesso baseado em nuvem da Microsoft. Ele conecta pessoas e identidades não humanas a aplicativos, dispositivos, dados e recursos. Quando uma entidade tenta acessar um recurso protegido, o Entra ID pode autenticar essa entidade, avaliar políticas, emitir um token com declarações e permitir que o recurso tome uma decisão de autorização.

O serviço é usado diretamente pelo Microsoft 365 , pelo Azure e por milhares de aplicativos SaaS. Também pode proteger aplicativos personalizados, APIs internas e soluções multicloud. Isso significa que o Entra ID não se limita a “entrar no portal do Azure ”: ele funciona como provedor de identidade, diretório, emissor de tokens , mecanismo de política e fonte de sinais para decisões de acesso.

Algumas capacidades dependem de licenças específicas, mas a lógica conceitual permanece: objetos representam identidades; credenciais e métodos de autenticação comprovam quem ou o que está solicitando acesso; funções, permissões e políticas controlam o acesso; e logs registram os eventos. Serviços como Acesso Condicional , Identity Protection , PIM e governança serão aprofundados em capítulos posteriores.

radio_button_uncheckedshort_text 5. Tenant, diretório, domínios e assinaturas

5.1 Tenant ou locatário

Um tenant é uma instância dedicada e isolada do Microsoft Entra ID associada a uma organização. Ele contém objetos, domínios, configurações, políticas, registros de aplicativos e logs . Cada tenant possui um identificador globalmente único, o tenant ID, normalmente representado por um GUID. Esse identificador é diferente do nome do tenant e dos domínios usados para entrada.

Ao criar um tenant, a organização recebe um domínio inicial, como contoso.onmicrosoft.com. Domínios personalizados, como contoso.com, podem ser adicionados e verificados. A verificação demonstra que a organização controla o domínio DNS e permite utilizá-lo em nomes de entrada, como ana@contoso.com. O domínio não substitui o tenant ID e uma mesma organização pode administrar mais de um tenant por razões jurídicas, geográficas, técnicas ou de segregação.

5.2 Diretório

No uso cotidiano, “tenant” e “diretório” aparecem quase como sinônimos. A diferença de ênfase é útil: tenant destaca a instância isolada e a fronteira administrativa; diretório destaca o conjunto organizado de objetos e atributos existentes nessa instância. Um objeto possui um object ID próprio dentro do tenant, enquanto determinados tipos também têm identificadores específicos, como o application (client) ID de um aplicativo.

5.3 Tenant e assinatura do Azure não são a mesma coisa

Uma assinatura do Azure é uma fronteira de cobrança, quotas e organização de recursos. Para autenticação e autorização, a assinatura confia em um tenant do Microsoft Entra ID . Um tenant pode estar associado a várias assinaturas, e cada assinatura mantém uma relação com um tenant em determinado momento. Criar uma assinatura não significa criar uma nova identidade para cada usuário; as identidades do tenant recebem funções sobre assinaturas, grupos de recursos ou recursos específicos por meio do Azure RBAC .

Armadilha de prova

Tenant, assinatura e domínio são conceitos relacionados, mas distintos. O tenant contém identidades; a assinatura contém recursos e cobrança; o domínio fornece um namespace de nomes e precisa ser verificado.

radio_button_uncheckedshort_text 6. Tipos de identidade e principais de segurança

Uma identidade é uma representação digital de uma entidade. Em Microsoft Entra ID , essa entidade pode ser uma pessoa, um dispositivo, um aplicativo, um serviço, uma automação ou um agente de IA. Para que uma identidade receba permissões e participe de decisões de acesso, ela precisa ser representada como um principal de segurança apropriado. Usuários são user principals; aplicativos e várias identidades não humanas são representados por service principals ou tipos especializados construídos sobre essa infraestrutura.

A classificação ajuda a escolher mecanismos de autenticação e governança. Pessoas podem usar MFA e métodos sem senha; dispositivos constroem confiança de dispositivo; workloads devem evitar contas humanas e segredos estáticos; agentes de IA precisam de identidade própria, patrocinador, permissões específicas e trilha de auditoria. Tratar todas essas entidades como “usuários” leva a credenciais compartilhadas, privilégios excessivos e pouca rastreabilidade.

radio_button_uncheckedshort_text 7. Usuários, grupos e identidades externas

7.1 Objetos de usuário

Um objeto de usuário representa uma pessoa ou, em casos legados que devem ser evitados, uma conta utilizada por processo. O objeto contém atributos como nome, UPN, endereço de e-mail, cargo, departamento, status, métodos de autenticação, grupos e funções. A origem da identidade pode ser exclusivamente em nuvem, sincronizada de um Active Directory local ou externa.

Member e Guest são propriedades de tipo de usuário, não uma prova absoluta de vínculo trabalhista ou origem. Um usuário convidado normalmente tem restrições padrão e é criado por colaboração B2B, mas administradores podem alterar propriedades e conceder acesso. A segurança depende de políticas, grupos, funções e revisões, não apenas do rótulo.

7.2 Grupos

Grupos simplificam a administração ao permitir que permissões, licenças e acesso a aplicativos sejam atribuídos a um conjunto de identidades. Grupos de segurança são usados principalmente para controle de acesso. Grupos do Microsoft 365 também fornecem recursos de colaboração, como caixa de correio, calendário e espaço compartilhado. A associação pode ser atribuída manualmente ou, em edições compatíveis, calculada dinamicamente com base em atributos.

A melhor prática é conceder acesso a grupos sempre que fizer sentido, em vez de criar muitas atribuições individuais. Entretanto, grupos também precisam de proprietários, critérios de associação e revisão. Um grupo dinâmico com regra incorreta pode conceder acesso em massa; um grupo sem proprietário pode manter usuários desligados por tempo excessivo.

Princípio operacional

O usuário é a identidade individual; o grupo é um mecanismo de organização e atribuição. Em geral, o grupo não “faz login”, mas pode receber permissões que serão efetivas para seus membros.

radio_button_uncheckedshort_text 8. Identidades de dispositivo

Uma identidade de dispositivo é um objeto no Microsoft Entra ID que representa um equipamento. Ela fornece informações usadas em decisões de acesso e gerenciamento, como ID do dispositivo, proprietário, estado de registro, sistema operacional e vínculo com serviços de gerenciamento. A identidade de dispositivo não substitui a identidade do usuário; ela acrescenta contexto. Uma política pode exigir que o usuário esteja autenticado e que o dispositivo esteja registrado, gerenciado ou em conformidade.

Esses estados são frequentemente confundidos com gerenciamento. Registrar ou ingressar um dispositivo cria uma identidade e uma relação de confiança; gerenciá-lo com Microsoft Intune envolve políticas, configurações e avaliação de conformidade. Os conceitos podem trabalhar juntos, mas não são sinônimos.

Ponto para o exame

Dispositivo registrado está associado ao Entra ID; dispositivo joined pertence ao modelo de entrada da organização; dispositivo hybrid joined mantém relação com AD DS e Entra ID. O estado do dispositivo pode ser um sinal de acesso.

radio_button_uncheckedshort_text 9. Aplicativos, registros e aplicativos empresariais

Aplicativos também precisam de identidade. Quando um desenvolvedor registra um aplicativo no Microsoft Entra ID , é criado um application object no tenant de origem. Esse objeto funciona como definição ou blueprint: contém identificadores, URIs de redirecionamento, tipos de conta suportados, permissões solicitadas e outros metadados usados pela plataforma de identidade.

Para que o aplicativo seja usado em um tenant, existe uma representação local denominada service principal. No centro de administração, a área App registrations exibe application objects do tenant de origem; a área Enterprise applications exibe service principals, isto é, instâncias locais de aplicações utilizadas no tenant. Essa distinção é uma das mais importantes para administradores e aparece em questões conceituais.

Em um aplicativo single-tenant, o uso é restrito ao tenant previsto. Em um aplicativo multitenant, outros tenants podem consentir com seu uso; cada tenant consumidor cria seu próprio service principal, com consentimentos, atribuições e políticas locais. Assim, um único application object pode originar vários service principals.

radio_button_uncheckedshort_text 10. Service principals e identidades de carga de trabalho

Carga de trabalho, ou workload, é software que executa uma função: aplicativo web, API , serviço em segundo plano, pipeline , função serverless, máquina virtual, contêiner ou automação. Uma workload identity é a identidade usada por esse software para autenticar e acessar recursos. No Microsoft Entra , aplicações, service principals e identidades gerenciadas fazem parte desse universo.

Um service principal pode autenticar-se com segredo, certificado, credencial federada ou outro mecanismo suportado. Depois de autenticado, recebe um token e age com permissões concedidas. Como não há uma pessoa digitando credenciais, os controles são diferentes: rotação de certificados, restrição de escopo, revisão de permissões, logs de entradas de service principals e eliminação de credenciais desnecessárias tornam-se fundamentais.

Usar uma conta de usuário para uma automação é uma prática frágil. A senha pode expirar, MFA pode interromper o processo, a conta pode acumular permissões e os logs deixam de distinguir pessoa e workload. Uma identidade de carga de trabalho torna o propósito explícito e possibilita governança independente.

radio_button_uncheckedshort_text 11. Identidades gerenciadas

Managed identities for Azure resources resolvem um problema recorrente: como permitir que código acesse Key Vault , Storage, SQL ou outra API protegida sem colocar senha, segredo ou certificado em arquivo de configuração. Ao habilitar uma identidade gerenciada, o Azure cria uma representação apropriada no Microsoft Entra ID . O código solicita um token ao ambiente de hospedagem, e a plataforma cuida da credencial subjacente.

11.1 Atribuída pelo sistema

A identidade gerenciada atribuída pelo sistema nasce junto ao recurso Azure e compartilha seu ciclo de vida. Uma máquina virtual ou App Service recebe uma identidade exclusiva; quando o recurso é excluído, a identidade correspondente também é removida. Ela não pode ser compartilhada entre vários recursos. É adequada quando a identidade pertence claramente a um único recurso.

11.2 Atribuída pelo usuário

A identidade gerenciada atribuída pelo usuário é criada como recurso independente e pode ser associada a um ou mais recursos Azure . Seu ciclo de vida não depende de uma VM ou aplicação específica. Isso permite pré-autorizar uma identidade, reutilizá-la em instâncias que são recriadas e manter permissões consistentes. A Microsoft atualmente recomenda esse tipo para muitos serviços quando a reutilização e a independência são desejáveis.

Regra de segurança

Identidade gerenciada elimina o gerenciamento de credenciais, mas não elimina a necessidade de autorização. Ela só acessará o recurso de destino se receber a função ou permissão adequada.

radio_button_uncheckedshort_text 12. Identidades de agentes de IA

Agentes de IA são softwares capazes de interpretar objetivos, planejar ações e interagir com ferramentas, dados e serviços. Quando um agente lê documentos, consulta APIs , cria tickets ou executa tarefas em nome de usuários, tratá-lo como um aplicativo genérico pode produzir pouca granularidade e auditoria. O Microsoft Entra Agent ID estende a infraestrutura de identidade para representar e governar agentes em escala.

Na arquitetura atual, identidades de agente são construídas sobre a infraestrutura de service principals, mas constituem um tipo distinto. Um agent identity blueprint descreve propriedades e capacidades compartilhadas e pode originar várias identidades de agente. O blueprint mantém credenciais e realiza obtenção ou troca de tokens em nome das identidades; cada agente pode ter permissões e registros de auditoria próprios. Esse modelo separa a plataforma que executa agentes da identidade concreta que age.

A noção de sponsor, ou patrocinador responsável, é importante para governança. Uma identidade não humana precisa ter uma pessoa ou unidade responsável por seu propósito, acesso e ciclo de vida. Sem essa responsabilidade, agentes podem permanecer ativos após o projeto acabar, manter permissões excessivas ou executar ações difíceis de atribuir.

Para o SC-900

Concentre-se no motivo: agentes de IA precisam de identidade própria, privilégio mínimo, governança e auditoria. A implementação é recente e evolui rapidamente; detalhes de administração podem mudar além do escopo fundamental do exame.

radio_button_uncheckedshort_text 13. Identidade híbrida

Identidade híbrida é o modelo em que uma organização conecta capacidades locais e de nuvem para fornecer uma identidade comum. O usuário pode existir inicialmente no AD DS , ser provisionado no Microsoft Entra ID e utilizar o mesmo nome de entrada para acessar estações locais, Microsoft 365 , Azure e aplicativos SaaS. A meta não é manter duas contas independentes manualmente, mas coordenar ciclo de vida e atributos.

Provisionamento é o processo de criar, atualizar, habilitar, desabilitar ou remover objetos conforme regras. Sincronização mantém atributos correspondentes entre diretórios. Autenticação é o processo de comprovar a identidade durante a entrada. Essas três palavras se relacionam, mas não são sinônimos. Uma organização pode sincronizar usuários e escolher diferentes métodos de autenticação híbrida.

13.1 Origem de autoridade

A origem de autoridade indica onde determinado atributo ou objeto é administrado. Para um usuário sincronizado, vários atributos continuam sendo controlados no AD DS e enviados ao Entra ID. Alterá-los apenas na nuvem pode ser impedido ou sobrescrito pela próxima sincronização. Em ambientes cloud-only, a origem é o próprio Entra ID. Definir claramente essa autoridade evita divergências e alterações perdidas.

13.2 Correspondência e source anchor

O mecanismo de sincronização precisa associar o objeto local ao objeto correto na nuvem. Para isso, utiliza atributos de correspondência e um identificador estável, frequentemente chamado source anchor. Alterações de UPN, e-mail ou nome não devem criar automaticamente uma nova pessoa. Erros de correspondência podem produzir objetos duplicados ou conectar identidades erradas, por isso planejamento de domínios e limpeza de diretório são etapas críticas.

radio_button_uncheckedshort_text 14. Microsoft Entra Connect Sync e Cloud Sync

14.1 Microsoft Entra Connect Sync

Microsoft Entra Connect é uma aplicação instalada no ambiente local para atender objetivos de identidade híbrida. Seu componente de sincronização, Connect Sync , lê objetos e atributos de diretórios locais, processa regras no mecanismo de sincronização e exporta alterações para o Microsoft Entra ID . Ele sucedeu ferramentas históricas como DirSync e Azure AD Sync.

O Connect Sync oferece recursos maduros e cenários complexos, mas exige servidor, banco de dados local, atualização, monitoramento e planejamento de alta disponibilidade. Staging mode permite manter um servidor adicional preparado sem exportar alterações até ser ativado. Connect Health fornece monitoramento de componentes híbridos em cenários licenciados.

14.2 Microsoft Entra Cloud Sync

Microsoft Entra Cloud Sync é uma abordagem moderna e gerenciada pela nuvem. Agentes leves instalados localmente conectam o AD DS ao serviço de provisionamento na nuvem. Essa arquitetura reduz a dependência de um servidor de sincronização completo, facilita múltiplos agentes e pode atender cenários com florestas desconectadas. A Microsoft apresenta o Cloud Sync como direção estratégica para sincronização híbrida, embora a escolha dependa dos recursos e requisitos da organização.

Não memorize “um sempre substitui o outro”

Para o exame, reconheça que ambos viabilizam identidade híbrida. Em projeto real, use a matriz oficial de recursos e a ferramenta de avaliação para escolher. Compatibilidade e migração mudam com a evolução do produto.

radio_button_uncheckedshort_text 15. Sincronização de hashes e métodos de entrada híbridos

15.1 Password Hash Synchronization - PHS

Na sincronização de hash de senha, o Microsoft Entra Connect processa uma representação derivada do hash de senha existente no AD DS e envia um hash adicional para o Microsoft Entra ID por canal protegido. A senha em texto simples não é sincronizada, e o hash original do AD DS não é enviado diretamente. Quando o usuário entra na nuvem, o Entra ID valida a senha usando o valor armazenado em sua infraestrutura.

Uma forma útil de lembrar é “ hash do hash ”, embora a implementação inclua sal e funções adicionais. O objetivo conceitual é permitir autenticação na nuvem com a mesma senha sem depender do controlador de domínio local a cada entrada. Isso melhora resiliência e reduz dependência de conectividade, além de permitir que sinais de credenciais vazadas sejam aplicados a identidades híbridas em cenários suportados.

15.2 Pass-through Authentication - PTA

Na autenticação de passagem, o usuário informa a senha à experiência de entrada do Entra ID, e agentes locais validam a credencial contra o Active Directory. A validação depende da infraestrutura local e dos agentes disponíveis. O PTA pode atender organizações que não desejam manter uma representação de hash para autenticação na nuvem, mas exige planejamento de disponibilidade e conectividade.

15.3 Federação

Na federação, o Microsoft Entra ID confia em um serviço de federação, como AD FS ou outro provedor compatível, para autenticar o usuário. O IdP federado aplica sua lógica e emite uma asserção ou token reconhecido pela Microsoft. O modelo oferece controle e integração com requisitos específicos, mas adiciona infraestrutura, certificados, disponibilidade e complexidade operacional.

15.4 Password writeback e SSO

Password writeback permite que determinadas alterações ou redefinições de senha realizadas na nuvem sejam gravadas de volta no AD DS em cenários configurados e licenciados. Isso é diferente de PHS : PHS envia material derivado da senha local para autenticação na nuvem; writeback envia uma nova senha definida na nuvem para o ambiente local. Seamless SSO pode reduzir solicitações de credencial em dispositivos corporativos, mas também é uma capacidade distinta do método de sincronização.

Armadilha importante

Sincronizar usuários não determina automaticamente como eles autenticarão. Provisionamento/sincronização e método de entrada são decisões separadas, embora configuradas no mesmo projeto híbrido.

radio_button_uncheckedshort_text 16. Microsoft Entra External ID e colaboração B2B

Microsoft Entra External ID reúne capacidades para trabalhar com pessoas de fora da organização. Em um workforce tenant, B2B collaboration permite compartilhar aplicativos e recursos corporativos com parceiros e convidados sem criar e administrar uma senha interna separada para cada pessoa. O usuário normalmente autentica com sua própria identidade de origem, enquanto o tenant de recurso controla autorização e políticas locais.

16.1 Convite e resgate

No fluxo tradicional, um usuário ou administrador envia um convite. O parceiro resgata esse convite e autentica usando uma conta corporativa, conta Microsoft, código de uso único por e-mail ou outro provedor configurado. Após o resgate, o tenant de recurso mantém um objeto de usuário que normalmente possui userType Guest. Em representações históricas, o UPN pode incluir o marcador #EXT#, mas o convidado continua utilizando suas credenciais de origem.

Essa separação é poderosa: a organização de origem administra credencial e ciclo de vida da conta doméstica; a organização de recurso decide quais aplicativos, grupos, sites e dados o convidado acessa. Se o parceiro deixar a empresa, sinais entre tenants e processos de governança podem reduzir risco, mas o tenant de recurso ainda deve revisar e remover acessos que não são mais necessários.

16.2 Configurações entre tenants

Cross-tenant access settings controlam confiança e restrições de entrada e saída entre organizações Microsoft Entra . Podem determinar colaboração B2B, confiança em MFA ou estado de dispositivo de outro tenant e acesso por organização. External collaboration settings controlam, entre outros pontos, quem pode convidar convidados e quais domínios podem ser permitidos ou bloqueados. São camadas complementares, não sinônimas.

16.3 B2B direct connect

B2B direct connect cria uma relação de confiança mútua para colaboração direta entre tenants. O cenário atual mais conhecido é Teams shared channels, no qual usuários colaboram com suas identidades domésticas sem serem adicionados como convidados tradicionais no outro tenant. O recurso exige configuração entre as organizações e não deve ser confundido com convite B2B comum.

radio_button_uncheckedshort_text 17. B2B, B2C e CIAM: diferenças conceituais

B2B significa business-to-business e descreve colaboração entre organizações. O usuário externo acessa recursos de uma força de trabalho, geralmente mantendo sua identidade de origem. B2C significa business-to-consumer e descreve relacionamento entre uma organização e consumidores. Em identidade, esse domínio costuma ser chamado CIAM - Customer Identity and Access Management - e envolve autoinscrição, recuperação de conta, provedores sociais, consentimento, personalização de marca e grande escala.

Na arquitetura atual do Microsoft Entra External ID , a organização usa um workforce tenant para empregados e colaboração B2B. Para aplicativos voltados a consumidores ou clientes comerciais, cria um external tenant separado, configurado para CIAM. Esse tenant contém os usuários dos aplicativos e oferece fluxos de inscrição e entrada próprios. Separar os cenários reduz exposição dos recursos internos e permite políticas adequadas ao público externo.

Azure AD B2C é o produto legado conhecido por muitos profissionais. A Microsoft informa que ele não está disponível para compra por novos clientes desde 1º de maio de 2025; tenants existentes continuam sendo tratados pela documentação de migração e suporte aplicável. Para novos projetos, a direção é Microsoft Entra External ID em external tenants. Para o SC-900, a distinção conceitual é mais importante que detalhes comerciais: B2B é colaboração com parceiros; B2C/CIAM é identidade de clientes em aplicações.

radio_button_uncheckedshort_text 18. Cenário prático integrado

Considere a Contoso, uma empresa com Active Directory local, Microsoft 365 , workloads no Azure e um portal para clientes. Ela deseja reduzir senhas técnicas, colaborar com fornecedores e preparar agentes de IA para atendimento interno. A arquitetura de identidade pode ser raciocinada em camadas.

1. A Contoso utiliza um workforce tenant do Microsoft Entra ID . Seus domínios contoso.com e subsidiarias são verificados no tenant.
2. Usuários e grupos do AD DS são provisionados para o Entra ID. A empresa avalia Cloud Sync para novos ambientes e mantém Connect Sync onde há requisitos ainda não cobertos.
3. PHS é escolhido como método primário de entrada em nuvem por simplicidade e resiliência. Password writeback é configurado para integrar redefinição de senha ao AD DS .
4. Notebooks corporativos modernos são Microsoft Entra joined e gerenciados; equipamentos em transição permanecem hybrid joined; dispositivos pessoais são registered quando permitido.
5. Uma aplicação interna é registrada no tenant. Seu application object define autenticação; o service principal local recebe atribuições e políticas.
6. Um App Service usa identidade gerenciada atribuída pelo usuário para ler segredos do Key Vault . Nenhum client secret é armazenado no código.
7. Fornecedores são convidados por B2B e adicionados a grupos específicos. Pacotes e revisões de acesso serão usados para limitar duração e confirmar necessidade.
8. O portal de clientes é registrado em um external tenant de CIAM, separado do workforce tenant, com autoinscrição e provedores sociais.
9. Cada agente de IA recebe identidade de agente e permissões mínimas para as ferramentas necessárias, com sponsor e logs específicos.

Como resolver questões de cenário

Primeiro identifique a entidade: pessoa, dispositivo, aplicativo, parceiro, cliente ou agente. Depois identifique a fronteira: tenant interno, tenant externo ou AD DS . Por fim, escolha o mecanismo: sincronização, service principal, managed identity, B2B ou CIAM.

radio_button_uncheckedshort_text 19. Boas práticas de arquitetura e segurança

19.1 Use privilégio mínimo e identidades específicas

Conceda somente as permissões necessárias, no escopo necessário e pelo tempo necessário. Separe contas administrativas de contas de produtividade. Para workloads, crie identidades por função ou componente quando isso melhorar isolamento e auditoria. Evite uma única identidade altamente privilegiada compartilhada por muitas automações.

19.2 Elimine segredos sempre que possível

Prefira managed identities para workloads no Azure e credenciais federadas para plataformas externas compatíveis. Quando segredo ou certificado for inevitável, use cofre, expiração, rotação e alertas. Nunca incorpore credenciais em código-fonte, imagem de contêiner ou arquivo distribuído sem proteção.

19.3 Controle o ciclo de vida

Toda identidade precisa de criação, manutenção e encerramento. Defina proprietários para grupos, aplicativos, service principals e agentes. Desabilite identidades órfãs, remova credenciais antigas e revise consentimentos. Em B2B, acesso externo deve ter prazo e justificativa quando possível.

19.4 Planeje a origem de autoridade

Em ambientes híbridos, documente quais atributos são administrados no AD DS e quais são cloud-managed. Teste alterações de UPN, fusões, desligamentos e recuperação. Monitore erros de sincronização e mantenha procedimentos para falha do componente híbrido.

19.5 Use logs e sinais

Entradas de usuários, service principals e identidades gerenciadas produzem registros distintos. Audite alterações administrativas, consentimentos e atribuições. Identidades modernas são valiosas justamente porque permitem atribuir ações a uma entidade específica; compartilhar conta ou credencial destrói essa capacidade.

radio_button_uncheckedshort_text 20. Revisão para o SC-900 e armadilhas de prova

20.1 Confusões frequentes

• Microsoft Entra ID não é um controlador de domínio hospedado e não substitui automaticamente todas as funções do AD DS .
• Tenant e assinatura do Azure não são a mesma fronteira.
• App registration e enterprise application não são duas aplicações independentes; normalmente representam application object e service principal.
• Managed identity é um tipo especial de identidade para workload, não um usuário humano sem senha.
• Identidade híbrida não significa que a senha em texto simples é copiada para a nuvem.
• B2B não é um portal para consumidores; B2C/CIAM não é a forma padrão de convidar um fornecedor para SharePoint.
• Dispositivo registrado, joined e gerenciado são conceitos diferentes, ainda que possam coexistir.
• Uma identidade autenticada ainda precisa ser autorizada para cada recurso.

Resumo em uma frase

Microsoft Entra ID mantém a fronteira de identidade na nuvem; representa pessoas e entidades não humanas; integra diretórios locais; e estende confiança a parceiros, clientes, workloads e agentes com políticas e auditoria.

radio_button_uncheckedshort_text 21. Conclusão

O Microsoft Entra ID é o núcleo de identidade da nuvem Microsoft. Seu valor não está apenas em armazenar contas, mas em representar entidades diferentes dentro de uma fronteira lógica, autenticar essas entidades, emitir tokens , aplicar políticas e registrar atividades. Tenants, usuários, grupos, dispositivos, application objects e service principals formam a linguagem básica usada para compreender o produto.

As identidades não humanas ganham importância crescente. Workload identities e managed identities permitem que aplicações acessem recursos sem depender de contas humanas e, em muitos casos, sem segredos administrados manualmente. Agent ID amplia essa lógica para agentes de IA, acrescentando separação entre blueprint, identidade do agente, permissões, sponsor e auditoria.

Ambientes híbridos demonstram que modernização raramente acontece de uma vez. AD DS e Entra ID podem coexistir por meio de provisionamento e sincronização, usando Connect Sync ou Cloud Sync e métodos de entrada como PHS , PTA ou federação. Já External ID separa colaboração B2B de experiências de clientes em CIAM. Minha avaliação é que dominar essas distinções é mais valioso do que decorar nomes: quando o leitor entende qual entidade existe, em qual tenant e com qual responsabilidade, a arquitetura se torna previsível e as questões do SC-900 deixam de parecer uma lista desconectada de produtos.

Próximo passo da trilha

Com os tipos de identidade e os ambientes híbridos compreendidos, o próximo capítulo aprofunda como essas identidades comprovam quem são: métodos de autenticação, MFA , Microsoft Authenticator , FIDO2, Windows Hello for Business , SSPR e tecnologias sem senha.

radio_button_uncheckedshort_text 22. Questões de revisão

1. Uma organização registra um aplicativo multitenant no tenant A. Quando o tenant B concede consentimento para usar esse aplicativo, qual objeto representa a instância local no tenant B?

• A) Um novo tenant do Microsoft Entra ID .
• B) Um service principal.
• C) Um usuário convidado.
• D) Uma identidade de dispositivo.

Gabarito comentado

Resposta correta: B. O application object permanece no tenant de origem; cada tenant consumidor cria seu próprio service principal, que recebe consentimentos e permissões locais.

2. Qual opção permite que um App Service acesse o Azure Key Vault sem que o desenvolvedor armazene client secret no código?

• A) Usuário convidado B2B.
• B) Grupo dinâmico.
• C) Identidade gerenciada.
• D) Sincronização de hash de senha.

Gabarito comentado

Resposta correta: C. Managed identity fornece ao recurso uma identidade no Entra ID e permite obtenção de tokens sem expor credenciais ao código. A identidade ainda precisa receber autorização no Key Vault .

3. Uma empresa quer que funcionários do AD DS usem a mesma senha para autenticar diretamente na nuvem, mesmo durante indisponibilidade dos controladores de domínio locais. Qual método é mais compatível com esse objetivo?

• A) Password Hash Synchronization .
• B) Pass-through Authentication .
• C) B2B direct connect.
• D) Apenas federação com AD FS .

Gabarito comentado

Resposta correta: A. Com PHS , uma representação derivada do hash é mantida no Entra ID, permitindo validação na nuvem sem consultar o AD DS a cada entrada.

4. Qual afirmação diferencia corretamente B2B de B2C/CIAM?

• A) B2B é para clientes anônimos; CIAM é apenas para administradores.
• B) B2B compartilha recursos corporativos com parceiros; CIAM gerencia inscrição e entrada de clientes em aplicativos.
• C) B2B e CIAM são nomes diferentes para a mesma configuração de tenant.
• D) CIAM exige que todo cliente tenha uma conta de funcionário no workforce tenant.

Gabarito comentado

Resposta correta: B. B2B atende colaboração com parceiros e convidados. B2C/CIAM atende consumidores e clientes de aplicações, normalmente em um external tenant dedicado.

radio_button_uncheckedshort_text 23. Referências e fontes de aprofundamento

Base primária do escopo: plano de estudos SC-900 fornecido pelo usuário, Capítulo 3 - Microsoft Entra ID , Tipos de Identidade e Ambientes Híbridos.

• Microsoft Learn - Study guide for Exam SC-900
• Microsoft Learn - Describe the function and identity types of Microsoft Entra ID
• Microsoft Learn - O que é Microsoft Entra?
• Microsoft Learn - Apps and service principals in Microsoft Entra ID
• Microsoft Learn - Managed identities for Azure resources
• Microsoft Learn - Agent identities, service principals, and applications
• Microsoft Learn - Hybrid identity with Microsoft Entra ID
• Microsoft Learn - O que é a sincronização de hash de senha?
• Microsoft Learn - Microsoft Entra B2B collaboration
• Microsoft Learn - Device identity in Microsoft Entra ID

Fontes oficiais consultadas em 23 de julho de 2026. Como os serviços de nuvem evoluem continuamente, detalhes de licenciamento, disponibilidade regional, nomes de menus e recursos em versão preliminar devem ser confirmados na documentação atual antes de uma implementação real.

Encerramento do capítulo

Você concluiu os tipos de identidade e os ambientes híbridos do Microsoft Entra ID . O próximo passo natural é estudar os métodos de autenticação modernos: MFA , Microsoft Authenticator , FIDO2, Windows Hello for Business , SSPR e as tecnologias sem senha.