O recursos que faltava

É isso mesmo que leu no título! O tão esperado recurso para ambientes PHS ou Cloud Only está saindo do forno!

Não é de hoje nem do ano passado que eu recebo perguntas do tipo:

“E como faço para controlar o horario que os usuários podem acessar os apps do M365?”.

O pedido não é apenas um “perfume”. Vários ambientes exigem esse tipo de controle que era fácilmente atingível utilizando as opções de Logon Hours no AD. Se você hoje tem um ambiente híbrido e utiliza PHS ou se tem um ambiente Cloud Only, a única forma de entregar esse controle é por meio de automação. Relativamente simples, mas ainda assim, algo customizado, nada built-in.

Pequeno adendo, se você tiver identidade hibrida e utiliza PTA, o Logon Hours do AD já resolve seu problema =D.

Acesso Condicional baseado em Horário

Antes de mais nada

Os testes realizados aqui são de um recurso que ainda está em Beta, nem mesmo em preview e sem documentação oficial da Microsoft. Utilize por sua conta e risco e NUNCA em produção

Indo até o Graph Explorer e rodando um GET nas políticas de Acesso Condicional, você notará um campo disponível chamado: “Times“.

Expandindo um pouco mais os testes, podemos rodar um PATCH na seção de Times da política e definir dias da semana e horário em que essa regra será aplicada.

{
    "conditions": {
        "times": {
            "includeAllTimes": true,
            "includeDays": null,
            "excludeDays": {
                "daysOfWeek": ["monday", "tuesday", "wednesday", "thursday", "friday"],
                "timeZone": "UTC",
                "startTime": "02:15:00",
                "endTime": "00:00:00",
                "allDay": false
            },
            "includeRange": null,
            "excludeRange": null
        }
    }
}

Note que os horarios devem ser informados no padrão UTC. Eu testei utilizando outras Time Zones mas em todas as opções retorno erro. Por enquanto, utilize um conversor de Time Zone para encontrar o horario exato para seus testes. Tudo caminhando bem, sua política será configurada considerando o horario que você definiu ali no Patch. No meu caso, criei uma política de Block para um usuário apenas, e nela defini que entre 23:15 e 00:00 o acesso seria bloqueado.

O resultado

Ao tentar logar após o horario definido, recebo uma mensagem informando que o acesso não é permitido. Aquele genérico de blocks por conta de Acesso Condicional. Por enquanto nenhuma mensagem personalizada que indique o motivo do block tem sido exibida, tampouco lá nos Sign-in Logs.

O que encontrará será apenas, também, um log genérico te mostrando que um bloqueio ocorreu, mas nada indica que foi por conta do horário definido.

Detalhes Importantes

• Eu vou repetir! Esse recurso é para ser utilizado como TESTE, e nada além disso. Não existe suporte alguem da Microsoft ainda. Espero ver em breve o recurso em Preview
• Você pode esperar ainda instabilidade nesse recurso. Como comentei, é um BETA no Graph API
• A opção de horario (Times) não está disponível e nem é exibida na console do Entra. Você conseguirá ver isso apenas via Graph
• As alterações não alterarão nada na console do Entra (nenhum campo novo será exibido). Novamente, tudo via Graph
• Os logs sign-in não dão pista nenhuma. Conseguimos concluir que a política foi aplicada dando comparando o horario de acesso com o que foi configurado. No meu caso, testei com dois usúarios, um que era alvo da política de horario e outra que não estava listado.

Só pra reforçar. NEM PENSE EM USAR ISSO EM PRODUÇÃO, POR ENQUANTO.

Conclusão

Ainda em Beta, mas tudo indica que logo menos teremos esse baita recurso disponível nas console do Entra, entregando ainda mais flexibilidade para gestão e governança de identidades com o Entra ID.

Depois me conta se testou e funcionou. Espero que tenha curtido!

Grande abraço \,,/

Faaala pessoal, 100%?

A Microsoft não postou a seção de julho no portal de News do Entra, mas mesmo assim, tivemos alguns anúncios que valem ser citados.

Temos duas grandes notícias para julho, ambas podem impactar diretamente sua operação.

Adios, SMS e ligação. Welcome passkey como método de autenticação padrão

A nave mãe anunciou que aposentará o serviço de SMS e ligações como segundo método de autenticação, no formato que existe hoje. Isso não quer dizer que essas duas opções estarão indisponíveis, a grande mudança aqui é que agora, você terá de pagar pelo uso delas. Sim, a entrega dos SMSs e ligações não será mais feita de forma gratuita pela Microsoft. Para continuar utilizando esses dois metodos, você terá de contratar uma das opções disponíveis no EntraID e, obviamente, pagar por isso.

Essa manobra era meio que esperada, visto o crescimento de ataques de roubo de token. E também funciona como um pequeno empurrão para a adoção mais acelerada do Passkey.

Status: Anúncio oficial (rollout começa em setembro/2026, corte em fevereiro/2027)

O que indico como próximos passos:

1. Levante quem no seu tenant usa exclusivamente SMS ou ligação como MFA
2. Rode (ou acelere) uma campanha de registro de passkey pra esse grupo antes de setembro
3. Decida se precisará de um provedor de telecom customizado — se sim, comece a avaliar opções desde já, porque a Security Store só liberará isso em 18/09
4. Trabalhe em conjunto com seu time de suporte. É certeza que o fluxo de chamados aumentará durante essa possível transição

Rollout do Cloud Sync iniciado

Como anunciado em Abril, Microsoft Entra releases and announcements – Microsoft Entra | Microsoft Learn, a Microsoft iniciou a preparação para a migração de Tenants para o Cloud Sync.

Se você faz parte das primeiras ondas, já pode ter recebido em seu Message Center ou Entra Connect Health uma mensagem alertando-o sobre a mudança.

Apenas reforçando, essa é uma mudança que não haverá um opt-out, a Microsoft empurrará a alteração sem opt-out.

Vale conectar isso com outro reforço de segurança do mesmo ciclo: desde 1º de junho de 2026, o Entra já bloqueia qualquer tentativa de “hard-match” vindo do AD que tente assumir um usuário cloud que já tenha Entra Role atribuída. Isso fecha uma brecha já conhecida de escalação de privilégio via manipulação de atributo no on-prem.

Status: Plan for change (notificações começaram em julho/2026, rollout em ondas ao longo dos próximos meses)

Jailbreak/Root Detection no Authenticator: agora oficialmente também no Android

Já falamos sobre o bloqueio implementado no Authenticator, onde o app passou a bloquear celular com jailbreak/root. Em julho temos a expansão desse padrão também para Android.

Embora você já faça isso utilizando App Protection (Se não faz, deveria), qualquer usuário agora não conseguirá mais utilizar o Microsoft Authenticator caso tenha o celular com Jailbreak (iPhone) ou Root (Android).

Mais uma vez, vemos a Microsoft se posicionando de maneira mais robusta em relação a requisitos de segurança para utilização de seus Apps.

Status: GA

Conclusão

Não tivemos volume de novidades em Julho mas, garanto que não faltará planejamento e atividades com as mudanças previstas

Espero que tenha te ajudado! Grande abraço \,,/

Fonte oficial: Microsoft Entra releases and announcements – Microsoft Entra | Microsoft Learn

Há, informação importante. Eu já disse isso no artigo inicial sobre o ADConnect mas vale repetir, em se tratando de senha o sync ocorre a cada 2 minutos, ok?!

O que é o PHS?

O escolhido para começar a jornada de estudo é o Password hash synchronization (PHS). Como o nome propõe esse método de sincronização leva o hash da senha do AD para nuvem e com isso os usuários conseguem utilizar a mesma senha que usam “dentro de casa” para logarem em cargas de nuvem (OneDrive, Exchange…).

Utilizando vários mecanismos para realizar essa sincronização de maneira segura e efetiva (relax que vou explicar), o PHS, a meu ver, é o método mais popular e fácil para se iniciar um ambiente híbrido de pequeno ou grande porte! Esse “popularismo” se dá ao fato de não exigir nada além do ADConnect pra que funcione e, em caso de falha ou indisponibilidade temporária do ADConnect o acesso a cargas cloud não são prejudicados. Entenda aqui que, obviamente, se houver uma alteração de senha enquanto houver uma indisponibilidade do ADConnect, o hash da nova senha não será sincronizado e como esperado a senha antiga deve ser utilizada. Após reestabelecimento do serviço e sincronização Delta o user poderá utilizar a nova senha para login!

Como funciona o PHS?

Como sempre digo, melhor do que saber qual opção selecionar ou qual botão apertar, é saber como as opções funcionam “por baixo dos panos”.

Muitos pensam que optar pelo PHS é basicamente permitir que o ADConnect copie a senha do seu AD e cole no AzureAD! Not that simple, bitch! É super importante dizer que o AzureAD, em momento algum, tem contato com a senha de ambiente local. O que é enviado ao AzureAD é hash do hash da senha do AD.

“Ok Nathan, mas o que diabos é hash?”

Eu não sou matemático pra entender a fundo como um hash funciona, mas sei que o “Hash” é um tipo de criptografia utilizada para garantir a integridade de uma informação sem expor tal informação. Um exemplo (nada real, apenas fictício a nível didático):

MinhaSenha + hash = 2ab96390c5dbe1437na23l0c6b1b1762

Agora que temos uma ideia básica do que seja o hash, vamos entender como o processo todo funciona, de forma simples e direta.

1. A cada 2 minutos um o agente de sincronização utilizando o protocolo MS-DRSR consulta o atributo “UnicodePWD” e busca o MD4 da senha no AD.
2. Antes de enviar o MD4 o DC encripta esse hash com uma chave baseada em MD5+salt (entenda salt como alguns bit que são acrescido para fins de segurança) da sessão RPC.
3. O DC então envia essas informações ao agente de sincronização
4. Por sua vez o agente de sincronização remove o MD5 para ter acesso ao Hash MD4 da senha.
5. O Agente de sincronização realiza alguns processos de expansão e conversão desse Hash MD4. No final, o hash de 16 bytes torna-se um de 64 bytes.
6. Em posse do do hash de 64-bytes o processo ainda adiciona um salt de mais 10-bytes.
7. Não acaba por ai…depois disso tudo o agente de sincronização combinará o MD4 como salt e imputará isso tudo em uma função PBKDF2 que é basicamente um mecanismo de criptografia que expande chaves de forma randômica para aumentar o nível de complexidade da mesma. Além disso são realizadas 1000 interações com o algoritmo HMAC-SHA256.
8. No final, tudo isso é concatenado (MD4+salt+PBKDF2+HMAC-SHA256) é enviado ao AzureAD através de um túnel TLS 1.2.
9. A validação da senha ocorre com o AzureAD comparando os hashes que ele já possui com os recebidos por esses processos

copyright: https://security4cloud.fr/

O PHS é seguro?

Você leu o topico anterior?

Eu ouvi muito e li alguns textos de pessoas defendendo que o PHS não seria um método seguro de sincronização de senha. Esse tipo de afirmação vem da falsa ideia de que a senha, em texto plano, é transmitida e armazenada no AzureAD.

Eu já citei, mas vale reforçar: Sua senha em texto plano não é exposta em momento algum a nenhum serviço que faz parte de todo esse processo!

Entenda que, do passo 1 ao passo 7, tudo ocorre do lado local, entre ADConnect e DC. A autenticação do usuário em si ocorre na nuvem. O pacote enviado ao AzureAD contendo o hash do hash da senha do AD está mais protegido do que é armzenado no seu AD OnPrem.

Caso esteja curioso de como uma senha comum fica depois de parte desse processo realizado pelo ADConnect, de uma olhada nesse site.

Mas e se capturarem o hash do hash e fizerem engenharia reversa?

A Microsoft garante que esse processo não é possível. Por conta do SHA256 uma decriptação não é opção e, tentar utilizar o hash enviado ao AzureAD localmente, numa tentativa de ataque pass-the-hash, não funcionará.

O tenho de Pros/Cons utilizando o PHS?

• Pro – Smart Lockou
• Pro – IP Lockout
• Pro – Microsoft Leaked credentials Service
• Pro – DoS Protection
• Pro – Password Spray Attack protection
• Con – Não pode utilizar recursos como restrição de horários para login

Conclusão

Embora simples o PHS é uma baita solução de autenticação e em minha opinião a melhor escolha para grande parte dos ambientes.

Unindo simplicidade e segurança o método e autenticação ainda consegue entregar estabilidade e mais alguns recursos nativos da Cloud Microsoft (se a licença do AzureAD permitir, é claro).

Obviamente temos ainda o PTA e o ADFS (veio de guerra) que, dependendo da situação, podem ser boas opções também.

Espero que tenha te ajudado! Grande abraço \,,/

A quantidade de dispositivos móveis acessando dados corporativos e o aumento exponencial de pessoal que trabalham remotamente vem chacoalhando a vida dos especialistas em cybersec a um tempinho. A evolução no formato de trabalho trouxe o desafio de prover segurança a dados corporativos, além da fronteira das empresas. O que antes um firewall e um AV dava conta, hoje em dia, não dá “nem pro cheiro”.

Tendo toda essa problemática em mente, a “solucionática”, com diria Dadá Maravilha, passou a ser considerar a identidade como ponto crucial de gerenciamento e proteção, visto que a segurança de perímetro, já havia ficado obsoleta, e daí que surge o termo “Zero Trust”.

O que é Zero Trust?

O temo que hoje é super popular não dá nome a uma solução em si, mas a um conjunto de práticas que visa aumentar sua postura de segurança localmente e na internet (cloud). O modelo tem como premissa a frase: Nunca confie, sempre verifique. Tendo isso como base, uma solução baseada em Zero Trust assume que não é possível garantir que um device ou usuário é/são confiáveis usando única e exclusivamente sua localização (perímetro). É preciso garantir formas de verificação explicita de que o usuário X, é de fato o X e não o Z. Para se atingir esse nível é preciso, como já disse um pouco antes, deixar de focar no perímetro e focar na identidade, que vai muito além dos limites que seu firewall protege!

O NIST publicou em 2020 um paper bem bacana falando sobre o modelo Zero Trust. Nele, os autores defendem que uma solução deve focar em proteger recursos como ativos, serviços, contas, fluxos de trabalho, contas de rede e outros, não apenas segmentos de rede, visto que estes deixaram de ser a principal preocupação em um ambiente protegido.

Existem três princípios no modelo:

• Verifique Explicitamente: Sempre autorize e autentique baseado em todas as informações disponíveis
• Use o menor privilégio de acesso possível: Não dê permissão além da necessária. Siga a ideia do JIT/JEA (Just-in-time / Just-enough-access)
• Assuma que brechas existem: Garanta, sempre que possível, criptografia de ponta a ponta e recursos para evitar movimentação lateral

Quando os três pontos, em teoria, atingimos o objetivo proposto pelo modelo. Obviamente, cenários corporativos mudam com frequência e ajustes devem ser feitos para que maturidade de segurança do ambiente se ajuste as mudanças e não seja reduzida com o passar do tempo.

Sugiro a leitura do paper na íntegra pra mais detalhes.

Zero Trust e Microsoft 365

Agora que já entendeu (espero que sim) a ideia base do modelo Zero Trust, a pergunta que fica é: como o M365 pode te ajudar a atingir esse objetivo?

Bom, existe “N” recursos que podem e se encaixam em um modelo de implementação Zero Trust! A Microsoft entende e leva em consideração 6 grandes áreas que geram “sinais” e devem ser consideradas em seu plano de implantação

Cada ponto apresentado na imagem acima é um pequeno mundo a ser analisado e considerado. Claro que nem sempre todos os pontos acima serão encontrados em todos os ambientes, cada caso é um caso. O importante é saber que a nave mãe consegue te apoiar em todos eles, da identidade a rede local.

E como posso dar os primeiros passos rumo ao Zero Trust, usando Microsoft 365?

Nada melhor do que mão na massa, certo? Então, vou deixar três recursos que vão te ajudar na missão Zero Trust. Vamos considerar um cenário simples, com licenciamento nível Business.

• MFA – Duplo fator de autenticação
• Acesso Condicional – O core do Zero Trust. Esse recurso será um de seus melhores amigos na missão Zero Trust, com ele é possível analisar vários sinais e liberar ou não o acesso baseado nos resultados encontrados
• Endpoint Manager/Intune – Esse cara lhe dará condições de gerenciar dispositivos corporativos que estejam fora da rede da empresa

As três soluções acima, se bem configuradas e ajustadas a seu ambiente, vão garantir um nível segurança maduro a seu ambiente e dados corporativos.

A configuração de cada um varia de acordo com a necessidade de cada ambiente, mas é claro que trarei alguns artigos mostrando como configurá-los, na prática.

Para cenários mais avançados que possuem licenciamento Entreprise, incluiria na lista mais 3 recursos:

• Azure AD Password Protection – Recuso que permite a criação de uma lista de senhas banidas, além de utilizar uma lista global da msft. Protege tanto cloud quanto OnPrem
• Azure AD Identity Protection – Recurso analisa a fundo localidade do login, IP utilizado para login, vazamento de credenciais, viagem atípica e alguns outros.
• SSPR – Portal de reset de senha para usuários, via cloud

Conclusão

Zero Trust é o presente e futuro da segurança em nuvem. Entender como funciona e como atingir o modelo sugerido fará uma diferença gigantesca pra você enquanto profissional e para os ambientes que você gerenciará.

Estude a fundo as possibilidades e cole aqui pois falaremos bastante sobre o tema!

Espero que tenha te ajudado! Grande abraço \,,/

O objetivo central deste artigo é explicar de forma simples o que é um Tenant no mundo Microsoft. Além de explicar o que é, a ideia é esclarecer algumas situações em que conhecer e entender o termo será de grande ajuda!

Você já deve ter notado que toda empresa que possui algum serviço na Nuvem Microsoft, seja Azure, M365, PBI, qualquer coisa, sempre terá uma conta, geralmente a de administrador, com o domínio @onmicrosoft.com, certo? Observe que o domínio onmicrosoft.com é comum a todas as empresas que utilizam um serviço na Nuvem Microsoft. Esse domínio é chamado de domínio de fallback e sempre vem acompanhado de outros atributos chamados “Tenant Name” e “Tenant ID”. Esses três elementos identificam de forma única e global o seu Tenant.

O que é um Tenant

Em uma tradução literal para o nosso querido português, “Tenant” seria equivalente a inquilino ou locatário. Entendeu? Podemos encerrar o artigo agora?

“OK, Nathan, mas e aí? Ainda não tenho ideia do que seja um Tenant”.

Vamos a uma analogia:

Imagine uma cidade chamada “Cloud Computing”. Na cidade Cloud Computing, existe um condomínio chamado Microsoft. Esse condomínio permite que outras empresas utilizem seu espaço e, para isso, cobra um valor pelo uso desse espaço.

Dentro do condomínio Microsoft, você pode ter um lote ou espaço só seu. Para cada espaço que você “aluga” dentro do condomínio, chamamos de Tenant. Esse Tenant deve ter um nome único no condomínio e ganhará um endereço que obrigatoriamente terá um sufixo onmicrosoft.com (NaMicrosoft.com). Claro que você pode e deve ter endereços customizados como nathanpinotti.com.br, mas o endereço único dado ao seu lote (nathan.onmicrosoft.com) sempre existirá, mesmo que não seja o seu principal.

No mundo técnico, a Microsoft aluga espaço em sua nuvem para que empresas consumam e paguem por seus serviços. Para que a Microsoft o identifique de forma única, você deve definir um nome globalmente único, que receberá o sufixo onmicrosoft.com. Esse sufixo também será utilizado nas URLs de serviços que você acessa, como SharePoint, OneDrive, PowerBI e outros.

Em seu lote (Tenant), você pode cadastrar vários endereços customizados (domínios personalizados) e usá-los como preferir e nos serviços que preferir. É possível também ter várias assinaturas (subscriptions) sem nenhum problema e, nelas, realizar mais uma segmentação a nível financeiro e de recursos. Além das subscriptions, o licenciamento utilizado na empresa fica atrelado ao Tenant.

Perguntas/Dúvidas comuns (FAQ)

• Minha empresa pode ter mais de um tenant?

Sim, quantos você quiser. O ponto é medir se vale o custo o custo operacional (gestão) de vários tenants. No geral essa ideia vem para segmentar os serviços mas é totalmente possível seguir outras estratégias e facilitar sua vida a nível de gerenciamento.

• Meu grupo possui 3 empresas cada uma com um Tenant e preciso que todas elas colaborem entre sim, é possível?

Sim! A forma mais comum e fácil de fazer isso é configurando uma relação de confiança entre os Tenants. O Entra External ID for partners (B2B) antigo AzureAD B2B é o formato mais simples de se fazer isso

• Preciso alterar a URL do meu tenant. É possível?

Do SharePoint e serviços que o consomem, sim! Desde o segundo semestre do ano passado a Microsoft permite alterar a URL do SharePoint. Você também pode ter um segundo fallback domain.

• Consigo migrar recursos e configurações de um Tenant para o outro?

Não! O que conseguimos no momento é migrar cargas de trabalho como OneDrive, Emails, Teams e SharePoint site. Mesmo conseguindo migrar utilizando ferramentas nativas, pra essa tarefa indico ferramenta de terceiros

Conclusão

Embora simples, o conceito pode não ser tão claro pra muitos profissionais de TI e usuários. Aos profissionais de TI, esse é um conhecimento base e estar na ponta da lingua quando um cliente o questionar.

Espero que tenha te ajudado a clarear esse conceitos! Um grande abraço \,,/

A identidade tornou-se o item mais crítico e sensível em um ambiente corporativo quando o perímetro deixou de ser um limitador para o uso de informações e sistemas corporativos. Em uma época em que seus ativos de TI estavam atrás de um firewall e/ou ingressavam em um domínio com uma boa solução antivírus, seu dispositivo e suas informações estavam protegidos. Hoje, em um mundo onde a cultura do trabalho remoto é realidade e o perímetro da rede não existe, o foco deve e precisa ser a identidade.

Sem o perímetro de rede o conceito Zero Trust se torna o padrão recomendado para gerenciar e proteger ambientes. Uma parte essencial do Zero Trust refere-se à proteção e governança da Identidade, pela qual a Entra ID é responsável.

Anteriormente conhecido como Azure AD, o Entra ID, tem é responsável por fornecer recursos que gerenciam, protegem e controlam a identidade de seu usuário, seja em nuvem ou sincronizadas com o domínio local. Quando as credenciais são sincronizadas do Active Directory para o Entra ID, temos o famoso ambiente de identidade híbrida.

Sincronizando suas identidades com a nuvem

Para gerenciar e fornecer um alto nível de segurança às credenciais locais você precisa primeiro sincronizá-las com a nuvem usando o Microsoft Entra Connect, onde exitem três opções de métodos de autenticação de entrada para escolher.

PHS

O principal e mais utilizado é o PHS (Password Hash Synchronization), eu já escrevi sobre ele aqui, o método padrão e mais fácil de se ter um ambiente de Identidade Híbrida. Como o nome sugere, o PHS sincroniza apenas os hashes de senha, que é um processo matemático de transformar qualquer chave ou uma cadeia de caracteres em outro valor do Active Directory para o Entra ID. Por conta desse processo de hash contínuo e repetido, a Microsoft garante que é impossível usar engenharia reversa para ter acesso à senha em texto plano no caso de uma interceptação de tráfego ou vazamento de dados. É essencial deixar claro que nem o Active Directory nem o Entra têm contato com a senha em si.

Durante a configuração do Entra Connect, um link é criado entre o objeto local (usuário) e o objeto na nuvem. Assim, sempre que um usuário alterar sua senha localmente, o hash de senha do AD será sincronizado com o Entra ID. Isso significa que, usando o PHS, não há dependência do ambiente local para autenticar um usuário em uma carga de trabalho de nuvem, como Exchange, Teams ou OneDrive. Tudo acontece na nuvem.

Também vale ressaltar que o uso do PHS Entra ID pode avaliar se as credenciais estão listadas na deep ou dark web. Esse tipo de informação é essencial para que a equipe de segurança possa aprimorar a política de senhas, exigindo maior complexidade, por exemplo. E mais uma vez, NENHUMA SENHA É ENVIADA OU MANTIDA NA NUVEM, o que é sincronizado é o Hash de sua senha.

PTA

A segunda opção disponível como método de autenticação de sign-in é o Pass Through Authentication (PTA). Essa opção, diferente do PHS, depende do AD para autenticar os usuários que acessam cargas de trabalho na nuvem. Quando os usuários tentam acessar suas caixas de correio ou arquivos na nuvem, a solicitação é enviada de volta ao ambiente local por meio de agentes PTA e o Active Directory valida as credenciais. Com base nisso, a Microsoft garante que o Entra ID não tem contato com as credenciais dos usuários.

O principal aspecto do PTA que você deve ter em mente se estiver planejando escolher esse método é que você de agentes PTA para lidar com as solicitações de autenticação. Considerando que há uma dependência de entrar em contato com o AD para autenticar o usuário, ter uma abordagem de failover é essencial para seu ambiente. Como recomendação, você deve ter pelo menos 3 agentes PTA instalados em servidores diferentes que não sejam Controladores de Domínio.

Por que escolher PTA em vez de PHS se o custo operacional é maior? Bem, certas organizações podem querer impor suas diretivas locais de segurança e senha do Active Directory. Algumas empresas usam o recurso AD de horário de logon para definir quando um usuário pode ou não fazer logon no ambiente. Então, se esse é o seu caso, a PTA é para você.

ADFS

O ADFS (Serviço de Federação do Active Directory) é uma tecnologia antiga usada para integrar e consolidar o processo de autenticação, aproveitando as credenciais do Active Directory. Aquite termos a mesma dependencia e no PTA em relação ao ambiente local. A grande diferença é em como o ADFS lida com as requisições e claro a estrutura necessária para ter um ambiente setguindo as recomendações Microsoft.

Hoje em dia, a menos que seu ambiente solicite o uso do ADFS, não consigo ver uma razão para escolher essa opção em vez de PHS ou PTA. Embora a Microsoft não tenha anunciado uma data de fim de vida útil para o ADFS, ela aconselha a transição para o Entra ID em vez de atualizar para uma versão mais recente do ADFS devido ao serviço de gerenciamento de identidade e acesso baseado em nuvem que pode ajudá-lo a gerenciar seus usuários e aplicativos com mais eficiência.

Agora que você tem uma visão melhor das opções de sincronização, vamos checar como e quais recursos estão disponíveis no Entra ID para melhorar a segurança de identidade em seu negócio.

Protegendo senhas com o Entra ID

Considero o gerenciamento de senhas um dos calquanhares de aquiles para qualquer ambiente, independentemente do tamanho. Mesmo com treinamentos e uma excelente política de segurança, os usuários tendem a escolher combinações facilmente adivinháveis ou termos simples como parte da senha.

O Entra Password Protection ajuda você a enfrentar esse desafio e evitar o uso de combinações nao seguras. Usando uma lista Global da Microsoft somado a uma lista de termos proibidos personalizadas, o Microsoft Entra Password Protection pode detectar e bloquear senhas fracas/conhecidas e suas variantes. A lista global é mantida pela Microsoft e é atualizada constantemente com base nos dados de telemetria de segurança da Microsoft, enquanto a lista personalizada pode ser preenchida com até 1000 itens, de acordo com as necessidades da empresa.

Com um algoritmo robusto de validação de senha, o Entra Password Protection usa um processo chamado normalização para detectar e bloquear variantes. Se eu incluir a palavra “Nathan” à lista de banidos personalizados e tentado definir “N41h4n” como uma senha o Entra bloquearia a ação. Isso é útil porque você não precisa lembrar ou considerar todas as variações possíveis, o Entra faz isso por você.

Você pode expandir essas políticas para seu ambiente local usando um agente e um proxy. A recomendação é ter o agente instalado em todos os Controladores de Domínio e, em pelo menos dois servidores membro, instâncias do serviço Proxy. Esses dois componentes são responsáveis por receber as políticas do Entra ID e avaliar se a senha pode ou não ser aceita. Os DCs, usando uma DLL de filtro, recebem a nova solicitação de alteração de senha e a encaminham para um proxy que, que por sua vez, a envia ao Entra ID para verificação. O processo acontece da mesma forma nos dois sentidos.

É importante mencionar que a validação, detecção e bloqueio de senha só acontecem durante o evento de redefinição. Se o seu usuário já tiver uma senha fraca, o Entra Password Protection não fará nada a respeito.

Redefinição de senha de autoatendimento (SSPR)

Ainda falando sobre gerenciamento de senhas, um recurso simples, mas útil, é o Self-Service Password Reset (SSPR), um portal da web que permite aos usuários redefinir suas senhas, fornecendo apenas o endereço de e-mail e o segundo fator de autenticação, como um código de verificação, um token para um aplicativo ou respondendo a perguntas de segurança.

Mas o que isso tem a ver com segurança? Well, well…todas as senhas estarão sob a política da empresa, e o principal fator é que ninguém além do próprio usuário terá acesso à senha. Assim como no Entra Password Protection, você também pode aproveitar esse recurso no ambiente local sinalizando uma opção para habilitar a opção de password Writeback no Entra Connect. Como o nome sugere, esse recurso permitirá que senhas alteradas na nuvem sejam gravadas de volta no Active Directory.

Proteção avançada de identidade

O Microsoft Entra ID Protection é um recurso avançado que pode detectar, investigar e corrigir riscos baseados em identidade. Ele usa insights a partir de  trilhões de sinais que a Microsoft coleta para detectar e determinar usuários, logins ou aplicativos em risco.

Antes de entrar na explicação do recurso, é importante definir um risco. A Microsoft define um risco como qualquer ação suspeita identificada relacionada a contas de usuário em seu Tenant. Essas ações podem ser consideradas um risco para o ambiente e podem ser detectadas no nível de Usuário  (risk user) e Login (risky sign-in), em tempo real (online) ou offline.

O processo de detecção é baseado em comportamentos de risco que já estão catalogados pela Microsoft (25 built-in) para te ajudar seu ambiente. Alguns deles são:

Detecções de risco de entrada

• Endereço IP mal-intencionado – Essa detecção indica a entrada de um endereço IP mal-intencionado. Um endereço IP é considerado malicioso com base em altas taxas de falha devido a credenciais inválidas recebidas do endereço IP ou de outras fontes de reputação de IP
• Viagem impossível – Esta detecção identifica as atividades do usuário (sessões únicas ou múltiplas) originadas de locais geograficamente distantes dentro de um período de tempo menor do que o tempo que leva para viajar do primeiro local para o segundo.
• Usuário confirmado pelo administrador comprometido — essa detecção indica que um administrador selecionou ‘Confirmar usuário comprometido’ na interface do usuário de Usuários de Risco ou usou a API de Usuários Arriscados.

Detecções de risco do usuário

• Credenciais vazadas – Esse tipo de detecção de risco indica que as credenciais válidas do usuário foram vazadas com base nos dados da Microsoft coletados da investigação na deep/dark web.
• Tráfego de API suspeito – Essa detecção de risco é relatada quando o tráfego anormal do gráfico ou a enumeração de diretório é observada por um usuário. O tráfego suspeito da API pode sugerir que um usuário está comprometido e realizando reconhecimento em seu ambiente.
• Atividade anômala do usuário – Essa detecção de risco linha de base o comportamento normal do usuário administrativo no Microsoft Entra ID e identifica padrões de comportamento estranhos, como alterações suspeitas no diretório.

Durante cada evento de autenticação, o Identity Protection executa um conjunto de algoritmos de detecção em tempo real, gerando assim uma métrica de risco que indica a probabilidade de comprometimento de determinada sessão. Com base nessa pontuação de risco, um conjunto específico de regras de segurança é automaticamente colocado em ação.

Para a etapa de investigação, o Entra ID Protection fornece relatórios importantes com dados chave para os administradores analisarem e entenderem o que está ocorrenco e como pode ser corrigido.

Quando existe um match para um evento arriscado, você tem a opção de agir manualmente ou aproveitar as ações de correção built-in usando o Acesso Condicional. O Acesso Condicional pode exigir controles de acesso, como uma alteração de senha ou fornecer um método de autenticação forte. Se o usuário concluir as etapas necessárias com êxito, o risco será corrigido automaticamente.

Acesso Condicional

O Acesso Condicional é uma validação de segundo estágio que fornece um amplo conjunto de verificações usadas como condições para saber se o acesso é permitido ou bloqueado durante o processo de autenticação, eu já escrevi sobre os serviço aqui. Com  o Acesso Condicional, o Entra ID pode determinar a localização, o tipo de dispositivo, o aplicativo que está sendo acessado, o status de conformidade do dispositivo, os alertas da Proteção de Identidade e até mesmo se a empresa gerencia o dispositivo no qual o usuário está acessando um aplicativo específico.

Dependendo dos resultados da validação das condições, a política de Acesso Condicional pode impor um processo de MFA (Multi-Factor Authentication), uma solicitação de alteração de senha ou até mesmo bloquear o processo de logon.

Um recurso interessante que faz parte das políticas de acesso condicional é a avaliação contínua de acesso (CAE), que avalia as sessões dos usuários em tempo real e pode responder a violações ou atualizações de políticas prontamente. Ele garante que o acesso do usuário será afetado quase em tempo real quando um token de sessão for revogado.

Conclusão

O Microsoft Entra ID oferece uma vasta oportunidade de proteger suas identidades locais e na nuvem com uma abordagem flexível e moderna. Para as empresas nascidas na nuvem, o processo de modernização pode ser menos complexo em comparação com as empresas que planejam iniciar a jornada na nuvem. Em qualquer caso, validações e MUITO planejamento devem ser os primeiro passo pra quem deseja seguir o futuro em relação a gerenciamento e proteção de identidades!

Fique a vontade para me pingar!

Abraço \,,/

Facilitar a vida para focar no que de fato importa é um dos lemas que devemos seguir para trazer inovação e garantir que o melhor está sendo entregue. Longe de mim cogitar que o tema do nosso artigo de hoje não seja importante, mas eu tenho certeza de que você vai curtir ter uma ajuda do Entra ID para te lembrar de rodar aquela verificação semestral de acessos.

A revisão de acessos é um ponto crítico na gestão de segurança da informação, principalmente quando se trata de acessos administrativos. O artigo de hoje vista compartilhar uma solução de revisão que utiliza o PIM (Privileged Identity Management) e o Access Review, dois recursos presentes na licença M365 E5 ou add-ons de compliance.

Antes de pular para a solução em si, obviamente, vamos começar do começo, definindo o que é cada recurso e como juntar as duas peças.

RBAC

Na nuvem Microsoft temos o conceito de acesso baseado em função, o famoso RBAC (Role based access). A ideia desse tipo de acesso é flexibilizar e granulizar as permissões existentes em cada workload. No Entra ID, por exemplo, ao invés de entregar a permissão de global admin, podemos ter o acesso específico para user administrators ou grupos. A ideia é trabalhar sempre considerando a maxima do zero trust de entregar a menor permissão necessária (least privilege access).

Além das funções padrões, é possível criar as custom roles, atribuindo ou removendo o que for necessário para seu cenário. Complexo, mas funcional.

PIM

Ainda considerando o Zero Trust, framework que deve ser seu guia, temos o conceito de just-in-time access (Acesso quando necessário). A ideia aqui é que administradores tenha acesso administrativo apenas quando for necessário e não o tempo todo, como era o padrão em ambientes ADDS.

O conceito busca manter o ambiente o mais fechado possível, considerando que uma conta administrativar não é e não deve ser utilizada o tempo todo.

A solução de PIM permite que você solicite elevação de privilegio, atrás de uma role, apenas quando for necessário e por um tempo determinado. Essa solicitação é feita via Entra ID e pode ter efeito imediato ou exigir uma aprovação antes de surtir efeito. A aprovação funciona como um segundo filtro, em que, caso a conta seja comprometida, o atacante não conseguirá executar nada visto que para ter o privilegio Global Admin uma segunda pessoa deve aprovar.

O PIM pode ser aplicado a usuário e grupos que estão habiltiados a receberem Roles do Entra.

Lembre-se que para adicionar uma role a um grupo a flag que permite essa configuração deve ser ativada no momento da criação do grupo.

Access Review

Parte do processo de governança inclui a revisão acesso a grupos e aplicações em seu ambiente. Como já comentado, embora simples, é um processo que pode ser moroso e nem sempre é tido como prioridade.

Para faciltiar a vida de todos, com o Access Review você pode escolher quais grupos ou aplicações farão parte da revisão de acesso e definir qual a peridiocidade e quem deve realizar a revisão.

Na data configurada, o Entra ID informará ao revisor ou revisores, a depender da configuração, para acessarem o portal e informar quem continuar tendo acesso (sendo membro) do grupo ou aplicação definido. E se ninguem responder? É possível definir uma ação automatica, sendo essa não realizar nada ou seguir o que a analise do Entra julga como correta.

Juntando as peças

Você já deve ter entendido onde quero chegar mas seguirei escrevendo, just in case.

Considerando que podemos adicionar grupos ao PIM, por que não incluir revisões periódicas utilizando o Acces Review? Dessa forma teremos o processo de revisão de acessos administrativos automatizado e garantiremos que apenas as pessoas corretas terão a possibilidade de solicitar elevação de privilegio via PIM.

O processo, de forma macro seria:

1. Crie um grupo que permita atribuição de roles
2. Configure as roles no PIM utilizando esse grupo
3. Adicione os usuários que pode soclitiar elevação de privilegio a esse grupo (obviamente, um grupo por role)
4. Crie uma politica no Access Review para esse grupo

Com essa estratégia você garantirá que periodicamente os usuários serão revisados e manutenção no grupo e de acesso privilegiado estará em dia.

Proximos passos

Agora que já temos a solução desenhada, vamos a implantação!

Meu proximo artigo será um passo a passo mostrando como encaixar todas as peças e entregar essa solução. Da criação do usuário até a configuração final e teste do Access Review.

Espero que esse artigo tenha te ajudado!

Grande abraço \,,/

Talvez um dos recursos mais pedidos e esperados do Entra, finalmente está em GA, o Backup and Recovery.

Totalmente integrado e automatizado, o Entra ID Backup and Recovery garante recuperação de objetos criticos do Entra ID, de Usuários a Service Principals.

Quais objetos são protegidos

Nem tudo no Entra ID faz parte do Backup. Deixo aqui a lista do que hoje é suportado. Sempre verifique a lista oficial para entender se houve adição ou remoção de algum dos objeto.

• Users
• Groups
• Apps
• Service Principals
• Conditional Access Policies
• Named Locations
• Authentication Method Policy
• Partial Authorization Policy
• Agent ID

Mais uma vez confira sempre a documentação oficial para ter acesso a lista atualizada

Como funciona

Enquanto administrador você não precisa realizar nenhum tipo de ação ou configuração no Tenant. Os backups ocorrem uma vez ao dia e são retidos sempre por 5 dias.

Algo me diz que num futuro proximo a Microsoft deva abrir o leque de opções e permitir configurações desse tipo, onde o cliente poderá definir um ciclo de backup que se adeque ao segu negócio.

Os dados do backup são salvos na mesma região em que está seu Tenant e são mantidos pela Microsoft. Você pode chegar a localização nesse link: Localização tenant – EntraID

Difference Reports

Além do backup em si, o EntraID Backup and Recovery entrega a possibilidade de visualizar o que foi backupeado e também comparar com uma das copias realizadas. Imagine que você tenha realizado uma mudança ontem a alguns dias e queir conferir o que foi alterado desde então. Com o recurso Difference Reports (Relatório diferencial) você terá essa visão, podendo escolher se prefere enxergar todas as diferenças ou apenas de objetos específicos.

Uma vez selecionada a opção que queria utlizar, basta clicar em Create Difference Report e aguardar.

Aqui nos meus testes levou cerca de 10 minutos para gerar o report.

Recovery

Obviamente, a opção de Recovery faz parte do pacote. O proceso é super simples e direto. Basta selecionar o dia que deseja recuperar e clicar na opção de “Recover Backup”, que fica dentro do menu Backups.

Caso você não tenha feito um Difference Report  da data que está solicitando o recovery, o Entra te alertará sobre e recomendará primeiro analistar o Relatório Diferencial, fica a seu criterio fazer isso ou realizar o recovery direto.

Assim como no Relatório Diferencial, durante o recovery é possível definir se fará um recovery completo ou se selecionará objetos ou tipos de objetos específicos.

A dica aqui é estar bem ciente do que deseja fazer antes de seguir com o recovery.

Pre-Requisitos

Em relação a licenciamento, o recuros estará disponível para quem tem Entra P1 ou Entra P2.

Em relação a permissionamento, a Microsoft adicionou das novas Entra Roles, específicas para esse novo recurso;

• Microsoft Entra Backup Reader: Consegue visualizar os backups e resultados dos relatórios diferenciais
• Microsoft Entra Backup Administrator: Manda em tudo. Consegue criar relatórios e recuperar objetos

Conclusão

Embora ainda um pouco “verde” o Entra ID Backup and Recovery promete ajudar MUITO e elevar ainda mais o nível de maturidade e segurança do Tenant. Entendo que muitas novidades ainda estão por vir, para esse recurso.

Lembre-se, o recurso ainda está em Preview. Use com moderação.

Espero que tenha ajudado! Um grande abraço \,,/

Faaala pessoal, 100%?

A tempo atrás a gestão de acesso web era relativamente simples, tinhamos a rede como perímetro, um firewall delimitando isso e um web filter, seja proxy ou seja embutido no firewall, interceptando as requisições HTTP e comparando com as regras de acesso, pra então definir se aquele site poderia ou não ser acessado.

Com a era do Officeless e trabalho remoto, a ideia do perimetro de rede vai por água abaixo, e a gestão de acesso web começa a ficar um pouco desafiadora. Alguns utilizam um client VPN, tunelando o trafego direcionado a porta 80 ou 443. Outros, utilizam o filtro web da solução de Antivirus. Tudo isso funciona, mas são várias pontas para se amarrar, diferentes fornecedores, gestão descentralizada e em alguns casos mais dor de cabeça para o time TI.

A ideia desse artigo é trazer uma possível solução pra esse desafio, utilizando um recurso que faz parte do Global Secure Access, recurso que está disponível no Entra Suite. O Microsoft Entra Internet Access entrega toda a gestão de acesso web, de forma centralizada, simplificada e independente de equipamento físico. Fazendo uso do cliente do Global Secure Access, você e seu time de TI, conseguirão controlar/gerir ~bloquear geral~, a partir da console do Entra.

Importante mencionar que o Web Content Filtering é apenas um dos recursos do Entra Internet Access. Os demais serão explorador mais a frente, em outros artigos ou vídeos.

Como funciona o Web Content Filtering

Entra Internet Access funciona como um Web Secure Gateway (SWG), centrado em Identidade, para o Web Content Filtering e demais recursos da Suite.

O Web Content Filtering, especificamente, entrega controle de acesso web baseado em categorias ou FQDNs. Atuando na camada 3 e 7 do modelo OSI, esse carinha consegue filtrar, inclusive, sites HTTPs  utilizando SNI (Server Name Indication), sem uso de certificado instalado nos clientes.

Importante lembrar pra que toda a mágica aconteça, o Global Secure Access precisa estar instalado no dispositivo do usuário.

Web content filtering policies

A definição do que está bloqueado é definido por Políticas de Filtro de Conteúdo Web. Essas políticas funcionam como um grupo, onde você Categorias e/ou FQDNs. Cada políticas (grupo) terá sua ação, que pode ser um Allow ou Block.

Blz, não entendi nada!

Pense o seguinte;

• Web Filter Padrão – Block

Aqui quero definir qual será o filtro padrão, por categoria.

• Web Filter Financeiro – Allow

Aqui algumas URLs que são específicas para a galera do Financeiro. É possível incluir um FQDN que talvez tenha sido bloqueado na política Web Filter Padrão.

Security Profiles

Uma vez que as políticas de Web Filter estejam criadas, entram em cena os Perfis de Segurança, que é onde você agrupará isso tudo e aplicará aos usuários, através de Politicas de Acesso Condicional.

Sim, eu sei…políticas e perfil pra tudo quanto é lado, mas calma…vai dar certo.

Veja no exemplo. Terei duas Security Policies, a padrão, que será utilizada em todos os users, e uma segunda, onde eu agrupo o Filtro Padrão (por que eu quero que TODOS os usúarios, independe de departamento, tenham esses filtros Web) e mais o Web Filter específico para o Financeiro.

Lógica de Processamento das Políticas

A chave pra trazer flexibilidade e ajustar a solução ao que o seu ambiente precisa, é entender como de fato tudo funciona.

Usando como base O perfil “Politica Web – Financeiro”. Note que eu tenho nele, duas Políticas de Web Filter, que criamos anteriormente.

A leitura do Entra Internet é similar a de um firewall, de cima pra baixo. Utilizei o campo prioridade pra definir que, durante a avaliação do Entra Internet Access, o filtro “Financeiro – Liberado” seja lido primeiro (valor menor — 100, prioridade maio) e depois, o Web Filter Padrão.

Com essa abordagem eu posso incluir exceções nos filtros de maior prioridade e ainda garantir o filtro mínimo para qualquer usuário seja aplicado (politica de prioridade menor, nesse caso a Web Filter Padrão).

E como eu aplico esse perfil aos usuarios?

Os Perfis de Segurança são aplicados via Política de Acesso Condicional, selecionando o grupo de usuários ou usuáro alvo, e escolhendo o Perfil de Segurança que deseja aplicar.

Ponto importante! Se um usuário receber dois ou mais Perfis de Segurança, a ideia da prioridade se aplicará. O de menos prioridade, sempre vencerá.

Behind the Scenes – Diagrama de Fluxo

Como eu sempre digo, não basta saber clicar no botão, é preciso entender como tudo funciona por debaixo dos panos. O diagrama abaixo vai te mostrar isso: O que acontece quando o usuário que possui um perfil de segurança do Entra Internet Access tenta acessar um site.

1. Tudo começa com o User tentando se autenticar nos serviços de Borda de Segurança da Microsoft (nesse caso para uso do cliente do GSA)
2. O GSA redireciona a requisição pra o Entra ID
3. Usuario e device se autenticam
4. As politicas de Acesso Condicional são lidas e aplicadas aos perfil de segurança do client do GSA
5. Valdiação do Token de user junto ao Serviço de Segurança de Borda da Microsoft ocorre
6. Tunel entre o GSA Client e Microsoft é estabelecido
7. Trafego de Internet começa a se interceptado e analisado pelo GSA
8. Aqui nesse passo acontece a avaliação da solicitação de acesso ao site com base na prioridade políticas de segurança que o user recebeu. Uma vez que um match tenha ocorrido, a avaliação é interrompida
9. O serviço de segurança de borda aplica a o perfil/política definido para esse user
10. Em caso de Block, uma tela informando o bloqueio é exibida ao user
11. Em caso de Allow, o user acessa o site requisitado

Desfecho

Embora trivial, a Gestão e Segurança de acesso web ainda é um desafio para vários ambientes. O fato do Entra Internet Access ser centrado em identidade e não depender de nenhum hardware ou serviço extra para funcionar simplifica muito sua implantação. Ainda que com pouco tempo de mercado, as melhorias que a Microsoft tem feito na solução a posicionam como uma das mais completas e funcionais para ambiente que desejam seguir as diretrizes do Zero Trust, sem abrir mão da flexibilidade que ambientes remotos ou hibridos exigem.

Espero que esse artigo tenha te ajudado! Sinta-se a vontade para enviar perguntas ai nos comentários ou em meu Linkedin.

Grande abraço! \,,/

Faaala pessoal, 100%?

Dando sequencia a assunto Passkey, hoje trago um pouco dos Perfils de Passkey, ou Passkey Profiles pra quem prefere os termos e ingles. Iniciamos essa conversa com o artigo Passkey (FIDO2) no Entra ID – O que é por que você deve utilizar. Caso não tenha lido, volte uma casa, leia o artigo pra ter as informações base e siga nesse artigo aqui.

No momento em que estou escrevendo esse artigo, esse recurso de Passkey Profiles, assim como o Passkey Sync, está em Preview e deve ser utilizado em ambiente bem controlado e como piloto. Algo me diz que logo menos teremos esses em GA.

O Conceito

Voltando lá  ao nosso primeiro artigo, vemos que em Metodos de Autenticação, dentro do Entra ID, temos a opção de habilitar o uso de Passkey (FIDO2) a nível de usuário ou grupos, e uma vez habilitado teremos várias opções de controle, sendo uma delas a possibilidade de determinas qual Passkey/chave FIDO2 é permitida em seu ambiente. Através do AAGUID A ideia do Passkey Profiles é trazer flexiblidade quanto ao uso de chaves FIDO2 ou Passkey.

Hoje, sem o recurso em preview, uma vez que você libere um AAGUID, ele será válido ou poder ser utilizado por qualquer usuário (obviamente que tenha sido habilitado a utilizar o Passkey).

Flexibilidade – O divisor de aguas

O grande lance do Passkey Profiles é flexibilizar essa parte do: “Quem pode usar o que”. O recurso permite que você crie divisões dentro da configuração de Metodos de  Autenticação e defina o que cada grupo/divisão poderá utilizar como chave de autenticação FIDO2/Passkey. Imagine o cenário em que você quer que o time de TI não utilze as Passkeys geradas via Microsoft Authenticator. Apenas chaves Yubikey 5 NFC são permitidas.

Sem o Passkey Profiles, essa restrição seria aplicada a TODOS os usuários do Tenant, não apenas a TI.

Antes de pularmos para um cenário de uso, pra tudo ficar mais claro, é preciso checar o que já tens em seu ambiente. Caso você ainda não tenha explorado essa opção, ao clicar em Passkey, adentro do menu Metodos de Autenticação no Entra ID, esse baner será exibido, informando que exist euma opção em Preview e você pode testar

Clicando em “Begin opting-in to public Preview” a tela será atualizada já trazendo as do Passkey Profile. Note que já é possível ver a opção de adicionar perfil, e que é preciso editar o Default Profile (Perfil Padrão) para definir o tipo de Passkey que será utilizado.

Clicando em Edit, expanda as opções de Target Types e selecoine Device-Bound. Veja que essa opção manteve as configurações anteriores, e que já temos os AAGUIDS do passkey para Android e iOS.

Feito isso, é possível voltar para a tela anterior, atualizar a pagina e a opção de Adicionar Perfis estará disponível na aba Configure.

Configurando

Agora basta aplicar a estratégia que preferir, definindo os usúarios ou grupos que receberam os perfis e quais configurações cada perfil terá. Vou usar como exemplo o seguinte caso de uso:

1. Devido a regulações, o time de TI só pode utilizar Token físico Yubikey do modelo 5 NFC e com enforce attestation habilitado;
2. Gestores dos times administrativos poderão utilizar Microsoft Passkey;

Para atender a esse caso de uso termos dois Passkey Profile, seguindo os requisitos de cada um deles. Vamos a mão na massa

Navegue novamente até Authentication Methods > Policies > Passkey(FIDO2). Na aba configure, clique em “Add Profile”. Iniciaremos pelo perfil da TI, onde é solicitado um modelo específico e com Enforce Attestation habilitado. A configuração ficará assim:

Note que temos apenas um AAGUID, que é o do token que foi mencionado como requisito, e o behavior (comportamento/ação) ficará como Allow, por que queremos permitir apenas esse AAGUID em específico. Você pode encontrar os AAGUID para Yubikey aqui: YubiKey hardware FIDO2 AAGUIDs

Já para o perfil de Gestores ADM, utilizaremos os AAGUIDs do Microsoft Authenticator. Veja como ficou a config:

Pronto! Requisitos atendidos. Agora é preciso linkar os perfis ao respectivo grupo de usários. Volte ao menu “Enable and Target” clique em “Add Target” e logo depois em “Select Targets”.

Selecione os grupos que receberão os perfis e logo depois, informe qual perfil se aplicará a cada um. No nosso exemplo, ficará assim:

Com essa configuração, os perfis serão aplicados a cada usuário que faça parte de algum dos grupos, seguindo o que foi pedido lá em cima nos requisitos que criamos.

Note que não temos nesse print o grupo Default Profile. Eu preferi deletar pra manter a visualização mais limpa, mas fica a seu criterio manter ou não.

Conclusão

Perfis configurados! Embora nem sempre simples, é possível ter um ambiente seguro e flexível. Agora, cada qual utilizará conforme o que pede sua política de segurança e compliance.

Espero que tenha te ajudado! Grande abraço \,,/