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

A ideia desse texto é, de forma simples, responder essa pergunta que aflige tantas mentes de TI.

Anteriormente conhecido como Office365 a plataforma Microsoft 365 engloba soluções de colaboração, produtividade, gerenciamento de identidade, gerenciamento de dispositivos, compliance e segurança (sim, isso tudo).

Parte do ecossistema cloud Microsoft o M365 (para os mais chegados) tem total integração com o Azure e por vezes recursos e funções são compartilhamos entre ambos. Como exemplo posso citar o AzureAD, que embora carregue no nome o Azure faz interface direta com as demais soluções do 365.

Claro que o bom e velho pacote office também faz parte dessa suíte e sempre é a porta de entrada para recursos mais avançados que podem ajudar seu ambiente corporativo a ficar mais moderno, colaborativo e seguro

Como tenho acesso o Microsoft 365?

Assim como grande parte de vários serviços de vários players, o Microsoft 365 é entregue via Assinatura, a famosa Subscription. O primeiro passo é definir quais recursos serão necessários para seu ambiente e, baseado na lista de assinaturas disponíveis, realizar a assinatura.

Existem planos, como o Microsoft 365 App for Business, que viabilizará a instalação do pacote Office e alguns recursos simples de cloud, outros, ainda da “família” Business, como o Business Premium, entregará, além do pacote Office instalado, vários recursos de segurança, compliance e colaboração. Mais a frente falamos um pouco sobre esses recursos.

Por ser um serviço via assinatura qualquer empresa que faça uso consegue adequar a quantidade de licenças de acordo com sua demanda, logo, se hoje seu ambiente possui 50 usuários, você assinará 50 licenças. Se no próximo mês o número reduzir ou aumentar, com alguns cliques é possível ajustar o número de licenças em uso, e por consequência o investimento mensal.

Por que eu deveria aderir ao Microsoft 365?

Como comentei no início do texto, o M365 vai muito além de apenas entregar o pacote Office. Existe uma série de recursos que vão do mais simples gerenciamento de usuários até recursos de segurança e compliance que podem e são aplicados em ambientes gigantes mundo a fora.

A grande vantagem, a meu ver, é o poder de gerenciamento que a suíte te entrega. TUDO, fica centralizado em uma console e acessível com apenas alguns cliques. Imagine um ambiente de médio porte, o que encontraríamos, NO MÍNIMO:

• 1x Solução de E-mail
• 1x Solução de Anti-Spam
• 1x Solução de Anti-Phishing
• 1x Solução de armazenamento de Arquivos/File Share
• 1x Solução para comunicação Interna
• 1x Solução de Antivírus
• 1x Solução para categorização de informação (Alô LGPD/GDPR)
• 1x Solução de DLP
• 1x Solução de MDM
• 1x Servidor/Serviço para gerir atualizações
• 1x Servidor/Serviço para gerir políticas de segurança
• 1x Servidor/Serviço para gerir Identidade
• 1x Servidor/Serviço de telefonia
• 1x Servidor/Serviço para reuniões e videoconferência
• …..

Tudo isso, sem contar o que eu não citei, pode ser entregue com soluções Microsoft 365! Além de elevar o nível de Gerenciamento tem a estabilidade e segurança garantida pela Msft.

Fazendo um simples DE>PARA teríamos:

• Exchange Online
  • Solução de E-mail
  • Solução de Anti-Spam
  • Solução de Anti-Phishing
• SharePoint / OneDrive
  • Solução de armazenamento de Arquivos/File Share
• Teams
  • Solução para comunicação Interna
  • Serviço de telefonia
  • Serviço para reuniões e videoconferência
• Defender for Endpoint – xDR
  • Solução de Antivírus de nova Geração
• Microsoft Information Protection
  • Solução para categorização de informação (Alô LGPD/GDPR)
  • Solução de DLP
• Microsoft Endpoint Manager – Intune
  • Solução de MDM/MAM
  • Serviço para gerir atualizações
  • Serviço para gerir políticas de segurança
• Azure AD
  • 1x Servidor/Serviço para gerir Identidade

Reparem que um recurso disponível na suíte Microsoft 365 pode suprir vários pontos que, em um ambiente comum local, precisaríamos de mais de um player. Por consequência, além do gerenciamento, como já citei antes, temos uma tendência em REDUZIR CUSTO agregando VALOR!

E para fazer tudo isso funcionar?

Embora alguns serviços/recursos possuam configurações padrão é recomendável que se tenha um profissional instruído e que conheça bem os recursos disponível em cada assinatura. Além do conhecimento técnico é muito importante entender a necessidade do negócio como um todo, assim é possível alinhar a tecnologia ao objetivo do negócio e GERAR VALOR!

Conclusão

Confesso que existem muitos outros detalhes a serem comentados sobre os recursos do Microsoft 365. Obviamente qualquer mudança a nível de solução utilizada ou no ambiente requer planejamento e muito estudo. O que posso garantir é que, uma vez no mundo 365, dificilmente buscará outra solução, tamanha a flexibilidade, estabilidade e qualidade das soluções entregues pela Microsoft nessa suíte.

Como comentado lá no início, a ideia do texto é de forma breve te mostrar o quão poderosa é a suíte M365 e estigar a curiosidade para estudar e entender melhor como tudo funcionar.

Se você é um profissional de TI e quer elevar seu nível de conhecimento sobre o assunto, acompanhe o site, garanto que encontrará muito material de valor por aqui. Se é gestor e está em dúvida sobre aderir ou não ao M365 fique por aqui também, todo artigo/texto/post terá uma pitada de negócio!

Espero que tenha curtido e que de alguma forma eu tenha te ajudado!

Um grande abraço ⧵,,/

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 \,,/

A algum tempo o Global Secure Access se tornou realiade em vários ambientes. O conceito de Zero Trust Network Access (ZTNA) tem sido aplicado com sucesso, fortalecendo ainda mais a posição da Microsoft como um provedor de soluções SASE. Como parte do Global Secure Access, temos o Microsoft Entra Private Access, que é, de forma bem simplista, a ferramenta que te permite acessar recursos internos (onPrem ou em sua rede no Azure) sem nenhum tipo de VPN. Eu falei e demonstrei como funciona nesse vídeo aqui.

Outro recurso do mundo Microsoft que é MUITO utilizado globalmente é o Azure SQL, que cá entre nós não precisa de apresentações. Como é de conhecimento geral, após a implantação do Azure SQL, é preciso liberar o acesso para gerenciar as bases de dados. Isso no geral é feito adicionando IPs Publicos a lista de Firewall do SQL ou utilizando uma solução de VPN que tunela o tráfego e sempre entrega o mesmo IP de saída.

Essa soluçã funciona, é segura mas não é escalável. Imagina um tim de 20 DBAs com IPs dinamicos e alguem (você Azure Admin), tendo que atualizar a lista de IPs e garantir que não tenha adicionado nenhum errado. Nada bom!

Pensando nisso, e repetindo o mantra da abordage Zero Trust, uma ideia surgiu?

“Por que não “integrar” o Azure SQL com o GSA e utilizar o Entra Private Access pra garantir um acesso seguro, gerenciável e escalável? Pois bem…funciona, e super bem.”

Pre Requisitos

1. Acesso ao Global Secure Access — Você pode usar uma conta com as roles de Global Secure Access Administrator e também precisará de Application Administrator
2. Acesso de Contributor no recurso Azure SQL, no Azure
3. Caso queria trabalhar com atribuição baseada em grupo (eu recomendo), role de Group Administrator no Entra ID
4. 1 Windows Server na mesma região do Azure SQL. Esse carinha atuará como Conector

O Setup

Azure SQL

O processo é relativamente simples, o primeiro passo é subir seu Azure SQL, no Azure. Quando fizer isso, terá acesso as propriedades do SQL Server que hospeda as bases de dados.

Nota 1: O Entra Private Access controlará o acesso ao Azure SQL Server, não a base de dados em si. O Acesso a base deve ser gerenciado pelo seu DBA, da forma que ele preferir.

Nota 2: A autenticação do Azure SQL Server deve permitir uso de credenciais do Entra ID

1. Acesse seu Azure SQL Server, e na sessão de Overview precisaremos do “Server Name” e também da Região.
2. Navegue até Netwoking, na sessão de Security. Aqui é onde você define quais IPs podem ou não ter acesso a sua base. Aqui é importante manter o acesso publico ativado, mas, sem nenhum IP listado. Sem o acesso publico liberado, a conexão falhará, mesmo que o Entra Private Access utilize um faixa que faça parte dos serviços do Azure.
3. Na mesma tela, mas na aba “Connectivity” é onde está o “detalhe”. Aqui o tipo de Connection Policy deve ser alterado de “Default” para “Proxy”. Isso garantirá que apenas conexões utilizando um “intermediador” serão aceitas. Nesse caso, o Entra Private connector.

Importante 1: Uma vez alterada a política de conexão, é importante garantir que as aplicações que fazem uso da base funcionarão 100%.

Importante 2: O uso da Política de Conexão proxy, pode impactar na performance da conexão. Avalie antes de alterar seu ambiente

Global Secure Access – Entra Private Access

Aqui é a parte divertida! Como já mostrei como realizar o setup inicial do Private Access no video que deixei no link acima, vou pular essa etapa.

Antes de configurar qualquer coisa no Global Secure Access, precisamos adicionar um serviço lá vnet onde o servidor que atuará como Conector reside.

1. Navegue até a vnet do seu server e na sessão de Settings, encontrei “Service Endpoint”.
2. Adicione o Service Endpoint “Microsoft.SQL”. Essa config garante que o trafego destinado a serviços do Azure SQL seja direcionado pelo backbone da Microsoft, e não via Internet. Não existe custo atrelado a essa config

Uma vez criado, vamos ao config do Global Secure Access.

1. Antes de mais nada, se você utiliza Grupos para controlar acesso ao Private Access, garanta que o usuário que terá acesso a esse recurso, faça parte desse grupo, lá em Connect > Traffic Forwarding.
2. No menu Applications, crie um novo Enterprise App ou, se preferir, use o Quick Access. O app deve ter um Application Segment com as seguintes configurações;
   1. Destination Type: FQDN
   2. Fully Qualified Domain Name: Digite o endereço do seu SQL Server (pegamos essa info lá atrás, nos primeiros passos)
   3. Ports: 1433 (ou a porta padrão que definiu durante o setup do seu Azure SQL Server
   4. Protocol: TCP
   5. Clique em Add
3. Uma vez adicionado o App, hora de permissionar. Na mesma tela, vá em Users and Groups e defina quem terá acesso a essa aplicação via GSA.
4. Caso você queira um nível a mais de controle, você pode criar uma Política de Acesso Condicional para esse App, exigindo MFA e/ou setando outros controles de sessão.

Feito!

Hora do Teste

Se seguiu todos os passos acima, deverá conseguir acesso ao seu Azure SQL via GSA apenas.

Aqui vai meu teste…veja que quando desabilito o GSA, a conexão é recusada.

Espero que tenha te ajudo! Envie pra galera que curte soluções não tão dentro do padrão.

Grande abraço \,,/