Além do perímetro: implementação de IAM com modelo Zero-Trust em ambientes híbridos e multicloud

Os ambientes modernos dependem de plataformas em nuvem, aplicativos SaaS e infraestruturas híbridas, tornando obsoletas as fronteiras da rede. A identidade oferece o ponto de controle mais consistente em todos os serviços, aplicativos e ambientes. 

A dispersão de identidades ocorre quando contas, credenciais e permissões estão distribuídas por plataformas desconectadas, criando pontos cegos e uma governança deficiente. 

As identidades das máquinas se multiplicam mais rapidamente do que as humanas e, muitas vezes, carecem de gerenciamento do ciclo de vida, rotação e monitoramento— o que torna difícil protegê-las manualmente. 

Unificando os sistemas de identidade, implementando autenticação forte, verificando continuamente o acesso eeliminando a confiança implícita entre os sistemas. 

Faça um inventário de todas as identidades, consolide plataformas, implemente a autenticação multifatorial (MFA), automatize a governança, segmente o acesso e aplique políticas de verificação contínua.

Assista ao vídeoaquipara ver a transcrição com marcação de tempo

Olá a todos, sejam bem-vindos ao “Beyond the Perimeter”.

Acho que o título desta sessão é ótimo.

É um ótimo título para um filme, mas, bem, nesta sessão não vamos falar sobre
nada relacionado a filmes.

Vamos falar sobre seu sistema de IAM e sobre como o Zero Trust pode ajudar a
proteger seus sistemas de IAM e tornar suas redes mais seguras.

Aqui estão alguns dos principais objetivos que abordaremos durante esta apresentação.

Vamos falar sobre por que a identidade é agora o novo perímetro de segurança.

Também abordaremos os princípios fundamentais do IAM com Zero Trust que consideramos mais importantes para
ao seu sistema de gerenciamento de identidade e acesso.

E vamos falar sobre algumas estratégias que podemos implementar para unificar e fortalecer
e verificar o acesso em seu sistema de gerenciamento de identidade e acesso.

Além disso, no final, apresentarei um guia que você poderá utilizar e que, espero, forneça orientações
dicas práticas e passos concretos que você pode seguir para implementar o Zero Trust em sua

um sistema de IAM que realmente o ajude a dar os primeiros passos e a obter algum sucesso inicial, talvez até na próxima
semanalmente, à medida que você planeja seus projetos de Zero Trust.

Meu nome é Ron Robbins e sou gerente sênior de produto aqui na Commvault. Trabalho na
Área de Resiliência de Identidade e ajudo os clientes

a resolver os desafios relacionados à resiliência de identidade em suas organizações.

Vamos lá, vamos direto ao ponto.

A única coisa que acho que aprendi acima de tudo ao me preparar para esta apresentação —
E acho que a coisa mais importante a se lembrar sobre isso é que…

A identidade é o novo limite.

Nossa segurança costumava ficar só no firewall, certo?

Estávamos acostumados com modelos tradicionais de rede, nos quais

configurávamos firewalls, configurávamos VPNs e considerávamos nossa rede ou nosso data center
protegidos por esses firewalls e VPNs.

Isso não é mais o caso.

Sabe, adicionamos novas cargas de trabalho e novos aplicativos SaaS.

Adicionamos novas plataformas de nuvem ao nosso ambiente.

E, como John Hawley destacou em um artigo da revista CSO Magazine de 2012, ele afirmou que nossos data
Os centros estão se tornando altamente fragmentados.

Eles estão se espalhando para além do confortável perímetro de segurança dos firewalls e das VPNs, o que, na minha
Na minha opinião, é uma ótima imagem para refletirmos sobre a situação em que todos nós

hoje, em que não temos mais essa rede local tradicional, na qual estamos
protegidos por um firewall e uma VPN.

Mas fomos muito além disso.

Por exemplo, a maioria de nós se encontra nessa situação híbrida em que temos uma solução local

E também temos muitas plataformas em nuvem com as quais talvez venhamos a trabalhar.

Nossas implantações de mensagens instantâneas (IM) enfrentam um grande desafio nesse sentido, e Geoff Cairns aborda esse assunto em um
artigo que ele escreveu anunciando o Forrester Wave™.

Ele afirma que as plataformas de mensagens instantâneas atuais são caracterizadas pela proliferação de identidades e contas múltiplas de usuário
as credenciais estão espalhadas por sistemas isolados, e que temos uma prática de segurança de identidade deficiente, como

resultado.

E, de fato, é algo que precisamos colocar sob controle e que vem
crescendo a cada dia.

Além disso, se você incluir o problema da IA genética nessa equação, verá essa explosão
o que chamamos de identidade não humana ou NHI.

A CyberArk, em 2025, em um estudo de panorama, descobriu que as identidades das máquinas que pesquisou
ao lado dos clientes

superam as identidades humanas atualmente por uma margem impressionante de 82 para 1, o que é surpreendente de
se pensar.

O número de agentes que utilizam essas identidades e o número de contas de serviço que as utilizam
.

Costumávamos ter essa noção de nossa rede com uma identidade por pessoa.

E costumávamos gerenciar apenas esse pequeno número de identidades.

Agora, porém, temos milhares e milhares de contas de serviços que precisamos
gerenciar

com nomes como “conta de serviço 01”, “conta de serviço 02”, e isso simplesmente se torna um problema realmente enorme
Para nós, um problema realmente enorme é gerenciar essa explosão de identidades e manter

manter a higiene em todo esse ambiente.

Portanto, agora mais do que nunca, acredito sinceramente que precisamos de algum tipo de estratégia de confiança zero para
nosso ambiente de IAM.

Então, vamos explicar um pouco melhor como funciona
o desafio dos ambientes híbridos e multicloud.

Quantos de vocês, eu me pergunto, têm uma estratégia multicloud?

Se vocês estivessem apenas na AWS, as notícias recentes talvez tivessem mostrado que uma estratégia
A arquitetura multicloud é algo que talvez vocês precisem adotar, na qual é necessário ter aplicativos localizados

em várias plataformas, em várias nuvens, ou pelo menos ter failover entre
nuvens, se possível.

Então, incorporamos essas plataformas de nuvem à nossa organização para garantir a resiliência.

E então descobrimos que cada uma dessas plataformas de nuvem de que precisávamos na organização
possui seus próprios sistemas de IAM.

E cada um desses sistemas de IAM tem sua própria linguagem.

Por exemplo, se você analisar o Active Directory e tentar adicionar uma função a
No entanto, o processo é totalmente diferente de adicionar uma função ao IAM da AWS.

Quero dizer, existem alguns conceitos que são parecidos, certo?

Mas a linguagem e o processo que você segue no Active Directory e no
IAM da AWS

São duas coisas totalmente diferentes.

Quero dizer, o IAM da AWS se assemelha mais a uma linguagem de script para acessar ou adicionar uma função do
ao Active Directory.

E, portanto, quando você vai além da interface do usuário, a situação fica muito mais complexa e não há consistência
entre os sistemas de IAM.

E isso cria um grande problema para nós quando queremos estabelecer regras, queremos aplicar
políticas consistentes entre plataformas e entre aplicativos.

Além disso, as fusões e aquisições contribuem para o problema.

Portanto, temos constantemente fusões e aquisições ou novas empresas entrando em nosso
organizações que podem ter suas próprias contas e podem ter suas próprias

contas que precisamos gerenciar.

E elas podem trazer consigo problemas de higiene de identidade que nem sequer tínhamos considerado
antes.

Eu trabalhava para uma organização e, a propósito, vou omitir nomes para
garantir que os culpados fiquem protegidos.

Mas eu trabalhava para uma organização que tinha muitas atividades relacionadas a fusões e aquisições.

Passamos por uma auditoria de confiança zero e descobrimos que havia muitas contas na nuvem
que simplesmente não eram gerenciadas, das quais simplesmente não tínhamos conhecimento devido ao número

das aquisições ocorridas no último ano.

Descobrimos que tínhamos 12 contas na nuvem das quais nem sabíamos que existiam.

E, em cada uma dessas 12 contas na nuvem, havia contas de administrador exclusivas

para um único usuário.

Portanto, um único usuário poderia ter 12 contas de administrador diferentes em todas essas 12
plataformas em nuvem.

E isso nos causou um grande problema.

Além disso, quando esses usuários deixavam a empresa, isso gerava muitas contas abandonadas.

Havia, portanto, contas de administrador abandonadas, o que é realmente algo que você não quer ter na
sua organização.

Portanto, a higiene das identidades se torna um grande problema quando você começa a considerar

a quantidade de plataformas em nuvem que você inclui na equação e a quantidade de aplicativos SaaS
que você inclui na equação.

Portanto, mais do que nunca, precisamos de algum tipo de estratégia em relação aos nossos sistemas de identidade.

E acho que existem certos princípios do Zero Trust que podemos aplicar aos nossos sistemas de IAM
para garantir que tudo seja mais seguro.

A primeira regra é: nunca confie e sempre verifique.

Cada usuário, cada dispositivo,

Tudo o que acessa sua rede precisa comprovar sua identidade.

É preciso garantir que ele comprove sua identidade e que seja algo
confiável, capaz de acessar e executar funções em sua rede.

Além disso, é preciso implementar esse conceito de privilégio mínimo para suas identidades.

Portanto, os usuários devem receber apenas acesso suficiente para realizar uma tarefa ou desempenhar suas funções profissionais, e
nada além disso.

Portanto, se eles tiverem acesso a qualquer coisa além do que está dentro de suas atribuições de trabalho,

essa conta possui privilégios excessivos.

E imagine o que poderia acontecer se um agente mal-intencionado conseguisse obter essa conta e fizesse login
e executar funções que não deveria realizar em sua organização.

Além disso, você precisa de autenticação forte e MFA em todos os lugares, caso ainda não as tenha.

A autenticação consiste em três elementos.

Consiste em algo que você sabe, algo que você tem e algo que você é.

Portanto, é importante que a autenticação forte inclua todos esses três elementos ou, pelo menos
, duas delas, caso você não consiga implementar todas as três neste momento em sua rede.

Isso é muito importante.

As decisões de acesso precisam se basear no contexto e na postura.

O que isso significa?

Digamos que tenhamos uma pessoa acessando a rede com um laptop e que ela
tenha feito login em algum lugar na região de Nova Jersey.

Então, ela começou a realizar atividades na rede e, de repente, cinco minutos depois,

o endereço IP do computador dela muda para um endereço IP que talvez esteja localizado
na Califórnia, e ela começa a realizar atividades na internet a partir da Califórnia.

Bem, não há como essa pessoa ter atravessado o país em cinco
minutos.

É uma viagem impossível.

E isso é algo que, se você perceber nessa sessão, vai querer encerrar
encerrar a sessão ou solicitar uma nova autenticação para garantir que a pessoa ainda seja

que ela disse ser ao fazer o login.

Portanto, verifique o estado do dispositivo

e o contexto é extremamente importante.

Além disso, a verificação contínua anda de mãos dadas com isso.

Garantir que a pessoa que você autenticou uma vez continue a demonstrar confiabilidade
durante toda a sessão.

Portanto, se ela começar a apresentar comportamentos de risco, se começar a acessar contas para as quais não
tem permissão; se começar a excluir ou realizar ações destrutivas, é preciso

que você verifique novamente ou

que encerre a sessão, caso haja risco.

Outra grande vantagem do modelo “zero trust” é que você deve sempre partir do princípio de que houve uma violação ou manter essa
a “mentalidade de ‘presunção de violação’”, certo?

Você deve construir sua rede como se já houvesse agentes mal-intencionados nela.

E acho que um exercício desafiador — ou talvez divertido para alguns de vocês
que gostam de ser investigadores — seria sair por aí e partir do princípio de que alguém já invadiu

sua rede todos os dias.

Saia e monitore as sessões, saia e observe as ações dos usuários, saia e

descubra se alguém está fazendo algo errado na sua rede todos os dias e tente pegar
os invasores em flagrante.

Se você sempre partir do princípio de que há uma invasão, estará sempre cauteloso, sempre tomará
tomará as devidas precauções e acompanhará constantemente o que está acontecendo em sua rede

e em seus sistemas de identidade.

Então, quais são algumas estratégias que podemos adotar para implementar algumas dessas políticas de confiança zero?

Bem, acho que a primeira coisa que podemos fazer é unificar identidade, autenticação e
acesso.

E o que quero dizer com isso?

Então, hum…

com todas essas plataformas na nuvem, com todos esses aplicativos SaaS que implementamos,
Temos esses silos de identidade.

Gosto de chamá-los de “ilhas de identidade” — são essas ilhas de identidade que existem por aí.

E a maneira mais fácil de colocar tudo isso sob controle é quebrar os silos ou
como divisões entre todas essas “ilhas de identidade” e reuni-las.

Estabeleça uma única fonte de verdade para sua identidade.

Às vezes, na maioria das organizações, isso pode ser um sistema de RH, quando as
As pessoas são contratadas e inserem seus dados no sistema de RH.

Essa pode ser a única fonte de verdade, e é a partir dela que você cria contas.

Também pode ser um sistema de identidade como serviço, como, digamos, um Entra AD, um Ping ou um
Octa, algo nesse sentido.

O ponto principal aqui é chegar a uma identidade única por usuário.

É muito mais fácil gerenciar usuários e identidades quando se tem uma identidade por usuário.

Além disso, é mais fácil unificar essa identidade entre vários sistemas e
serviços quando se tem uma identidade por usuário.

E esse é o próximo passo.

O que você precisa fazer é consolidar essa identidade.

Tenho um bom exemplo de uma organização anterior com a qual trabalhei.

Prometo que não será a mesma organização, mas, mais uma vez, trata-se de uma organização anônima.

Mas implementamos um serviço FTP.

Esse serviço FTP não pôde ser federado

com a nossa estratégia típica de federação que tínhamos.

Por isso, ele tinha seu próprio repositório de identidades.

Ele também contava com seu próprio componente de autenticação multifatorial (MFA).

Na época, não tínhamos muita experiência em estabelecer federação entre nosso ambiente
corporativo e nosso ambiente na nuvem.

Portanto, uma pessoa que quisesse acessar esse serviço FTP na nuvem precisava primeiro fazer login no
VPN corporativa usando uma conta de usuário e um nome de usuário e, em seguida, passar por uma verificação de MFA.

Em seguida, eu precisava fazer login na nossa plataforma em nuvem

usando uma conta de usuário corporativa, um nome de usuário, uma senha e uma verificação MFA.

Depois, eu precisava fazer login no serviço FTP usando um nome de usuário, senha e uma
autenticação MFA.

E todos esses elementos tinham o mesmo nome.

Portanto, sempre que ligavam para o suporte técnico e tinham um problema com sua identidade
ou com uma de suas contas de MFA, não conseguíamos identificar qual era.

Basicamente,

tínhamos que adivinhar e descobrir com qual deles o usuário estava tendo problemas, e ele não conseguia
nos explicar de forma simples qual era.

Então, às vezes os problemas eram resolvidos, outras vezes não, e realmente não
tínhamos ideia de onde estavam os problemas de identidade naquele sistema específico.

Portanto, é muito importante, de alguma forma, chegar a essa identidade única por usuário.

Além disso, fica muito mais fácil unificar políticas e modelos de acesso baseados em funções entre
plataformas se você tiver uma identidade única.

E, além disso, quando se trata de automatizar o provisionamento do ciclo de vida e a governança dos usuários
, fica muito, muito mais fácil com uma identidade única e um cenário de identidades consolidado.

Então, vamos falar a seguir sobre o reforço do acesso privilegiado.

Isso também é muito importante.

Uma das coisas que você precisa fazer é tratar seus administradores como identidades
de maior risco em sua organização.

Elas são as contas mais perigosas e são as mais

buscadas em caso de violação.

São elas que têm maior valor para os agentes mal-intencionados, certo?

Ninguém na sua organização deve ter permissões de alto nível o tempo todo.

Nenhum administrador deve ter permissões de alto nível o tempo todo.

Eles simplesmente não precisam disso.

Eles não precisam disso para navegar na internet ou ler notícias sobre o que está acontecendo no mundo.

Você precisa implementar algum tipo de elevação de privilégios “just-in-time”

em que os administradores só recebam contas com privilégios elevados pelo tempo necessário para
realizar a ação que desejam realizar.

Se você fizer isso em combinação com o princípio da confiança zero, terá uma
conta de administrador que só terá acesso por um determinado período para realizar o que precisa ser feito.

E ela só terá acesso para executar aquela função específica que limitamos
que ela realizasse.

Isso torna suas contas de administrador muito mais seguras.

Você também deve definir algum tipo de conta de emergência que seja monitorada.

Tenho uma ótima história sobre isso.

Fico pensando: perguntem a si mesmos, quantos de vocês por aí têm um Bob no seu círculo de amigos?

Quero dizer, vocês conhecem esse cara, conhecem o Bob.

Bob é aquele cara que é a única pessoa capaz de acessar aquele servidor empoeirado,
guardado em um velho armário de cabeamento em algum lugar nas instalações da sua organização

e ele é o único que consegue acessá-lo.

E se o Bob algum dia saísse da organização ou se, Deus me livre, ele viesse a falecer, vocês
perderiam o acesso a esse servidor.

Vocês não conseguiriam mais fazer login nele.

Vocês não conseguiriam mais fazer backups e restaurações.

Você não conseguiria mais atualizá-lo.

E o Bob sabe disso, e o Bob sabe que é muito valioso.

Por isso, você precisa garantir que elimine os “Bobs” do seu ambiente.

Você quer ter contas de emergência que possa ativar, às quais possa recorrer quando
necessário, caso aconteça o impensável, caso ocorra um desastre, e contas que sejam

seções monitoradas e controladas, contas que você pode acessar e encerrar para realizar
como ações de nível mais alto, como, por exemplo, acesso como root em uma conta na nuvem de sua propriedade.

Outro aspecto importante para restringir e controlar o acesso a privilégios é exigir aprovações duplas para ações de alto
impacto.

O que quero dizer com isso?

Digamos que você tenha um administrador que precise fazer login e alterar 50 contas.

Ele normalmente nunca faz isso, mas, como você sabe, essa é uma ação de altíssimo impacto.

Seria uma ação muito destrutiva se ele alterasse 50 contas de uma só vez
se alguma vez fizesse uma mudança que causasse impacto em sua organização.

Você quer ter algum tipo de mecanismo em que seja exigida a autenticação de dois fatores ou
aprovação dupla para essa ação específica, de modo que, quando o Bob fizer essa alteração,

ele tenha que obter a aprovação de outra pessoa; talvez alguém em um cargo superior na organização
também tenha que aprovar essa medida.

E isso é muito importante.

Se um invasor conseguisse acessar a conta do Bob ou a conta de qualquer outra pessoa — olha, só
Estou usando o Bob como exemplo —; ele precisaria ter uma segunda conta para poder realizar essas

ações destrutivas ou de grande impacto.

Além disso, em todas as sessões com privilégios e em todas as sessões de administrador, é preciso garantir que todas
para que sejam registradas.

Certifique-se de que todas elas sejam monitoradas e auditadas.

E, então, informe à sua equipe que essas sessões são auditadas e registradas.

Acho que os administradores ficam muito mais cautelosos quando sabem que suas ações estão sendo observadas.

Eles tomam muito mais cuidado para não cometer erros e para não se envolver em
comportamentos inadequados, caso saibam que suas sessões estão sendo

monitoradas e auditadas.

Então, acho que essas são medidas importantes para reforçar o acesso com privilégios.

A seguir, vamos incluir a verificação contínua.

A verificação contínua é algo semelhante ao modelo “zero trust”, mas é um “zero trust” em tempo real.

O que fazemos é validar continuamente os usuários e verificar se eles têm ou não acesso
para fazer o que precisam fazer.

Sabe, é muito importante lembrar que só porque autenticamos um usuário pela primeira vez, isso
isso não significa que ele seja confiável durante todo o tempo em que estiver

online ou durante toda a sessão.

Os tokens de sessão

podem ser roubados e as sessões podem ser sequestradas; além disso, podem ser assumidas por terceiros, permitindo que sejam realizadas ações
que sejam realizadas por agentes mal-intencionados.

Por isso, é importante verificar constantemente o que o usuário está fazendo durante sua sessão e analisar
a posição do dispositivo.

Se o dispositivo que está acessando a sessão for corporativo ou se for, digamos, um
dispositivo pessoal que possa estar introduzindo malware no seu

rede, é muito importante ficar de olho nisso.

É preciso haver algum tipo de autenticação reforçada para ações de risco.

Portanto, se alguém acessar o sistema e quiser aumentar seus privilégios ou criar uma
Na conta de administrador, deve haver algum tipo de autenticação reforçada.

Um bom exemplo disso é quando você faz login no seu banco: ao acessar o
site, você digita seu nome de usuário e senha e, possivelmente, usa a autenticação multifatorial (MFA), se for um

banco de confiança, e você está apenas monitorando sua conta ou verificando suas transações

, mas então você quer transferir uma quantia elevada para outra conta — algo que você simplesmente
nunca faz.

O banco pode solicitar uma autenticação multifatorial (MFA) adicional ou enviar um e-mail dizendo: “Digite
o código que acabamos de enviar por e-mail para que você possa confirmar essa transação”.

Esse é um exemplo de autenticação reforçada.

E isso é algo fácil de implementar na sua organização e fácil de aplicar à
ações de risco.

Você precisa monitorar as sessões em busca de anomalias.

Certifique-se de que, caso ocorra qualquer anomalia durante uma sessão, o usuário seja reautenticado
.

Portanto, se um usuário normalmente não acessa dados financeiros no SharePoint e passa a acessá-los
Se você não consegue acessá-los, talvez seja hora de se autenticar novamente ou verificar isso

sessão e verifique se a ação ainda é válida para o usuário.

Além disso, você deve ajustar o risco dinamicamente com base no risco

ou de acordo com o que ele estiver fazendo.

Digamos, por exemplo, que falemos sobre, hum, viagens impossíveis.

Bem, digamos, por exemplo, que alguém, durante sua sessão, comece a realizar ações de risco às 2
desde a manhã

de manhã, quando seu horário normal de trabalho é das 9h às 17h.

Bem, talvez você queira se certificar de que a sessão dessa pessoa não foi invadida ou
que seu token não tenha sido roubado e reutilizado em outro lugar por alguém no exterior ou por alguém

que, hum, esteja tentando fazer coisas ruins dentro da sua rede.

Você precisa detectar ou ter um método ou uma maneira de detectar e interromper sessões
tomadas imediatamente assim que perceber que há um risco envolvido ou assim que detectar que há

agentes mal-intencionados envolvidos.

Ok, agora que já abordamos a estratégia, vamos falar sobre algumas medidas
práticas que você pode adotar imediatamente em sua organização para implementar a abordagem “zero trust” em seus sistemas de IAM.

Sei que isso não se aplica a todas as organizações.

Tentei abordar o assunto de forma geral e prática.

Mas essas são algumas coisas nas quais você pode pensar, e espero que elas lhe deem ideias de como
você pode ter sucesso em sua organização e implementar algumas das políticas de zero trust em sua

organização.

Então, nos primeiros 30 dias, acho que alguns dos principais pontos em que se deve concentrar são, por exemplo, a implementação da autenticação multifatorial (MFA)
) em todos os lugares.

Se você ainda não tem a autenticação multifatorial (MFA), é muito rápido configurá-la.

Se você conseguir implementar um sistema de MFA na sua organização — algo que exija que os usuários digitem um
código — ou, se você já tiver a autenticação multifatorial (MFA) em todos os lugares, talvez seja a hora de

se você quiser migrar para uma autenticação multifatorial resistente a phishing, como o padrão FIDO2 ou algo
nesse sentido.

Essa também é uma ótima medida, de fácil implementação na sua organização, e que
torna suas contas muito mais seguras.

Comece também a mapear seus silos de identidade.

Descubra onde todas as suas identidades estão localizadas, em quais “ilhas” elas se encontram, onde
estão seus aplicativos na nuvem, quais plataformas de nuvem você está usando e quais silos de identidade estão localizados

dentro delas.

Tente descobrir onde tudo está e faça uma análise bem completa.

Em seguida, você deve proteger suas contas de administrador e suas contas de serviço.

Isso é algo que pode ser feito desde o primeiro dia.

Torne-as mais seguras, da maneira que for possível, mesmo que seja apenas um pouco.

Sabe, comece com pequenas medidas graduais para tornar essas contas de administrador mais seguras e não permitir
que alguém tenha privilégios o tempo todo para agir dentro da sua organização.

Nos primeiros 30 dias, é importante obter resultados positivos.

É importante justificar

Por que esse projeto de Zero Trust é importante.

Nos próximos 90 dias, esforce-se para desenvolver consistência.

Comece seu plano de consolidação de identidades.

Comece a executar a consolidação de identidades.

Junte todas as suas “ilhas de identidade” e unifique seus silos.

Certifique-se de que seja possível atribuir uma identidade a cada pessoa.

Defina como será sua estrutura de políticas.

Mesmo que você ainda não a implemente, é importante começar a defini-la, juntamente com o
gerenciamento do ciclo de vida.

Como será o seu processo de ciclo de vida?

Como os usuários são integrados à sua organização?

Como eles são desligados?

Como você lida com as saídas de pessoal que ocorrem na sua organização?

Como você exclui as contas deles?

É importante definir isso desde o início para que, à medida que sua organização amadureça, você possa implementar
a automação.

Além disso, implemente a verificação de integridade dos dispositivos.

Se você ainda não tiver isso, é importante verificar seus dispositivos e garantir que
sejam confiáveis, além de garantir que as pessoas que os utilizam

tenham dispositivos confiáveis, que possam apresentar uma identidade visual corporativa ou algo que atenda a um
um determinado padrão da empresa e marque esses dispositivos como de risco caso não atendam a ele

segundo esse padrão.

E, então, crie essas contas da classe de interrupção.

Não queremos que o Bob morra, não queremos que ele saia da organização e não queremos
perder o acesso àquele servidor no armário empoeirado ao qual só o Bob tem acesso.

Portanto, certifique-se de criar essas contas de classe de interrupção o mais rápido possível.

E, em seguida, trabalhe com o objetivo de alcançar a maturidade a longo prazo.

Expanda sua consolidação.

Certifique-se de acessar essa única fonte de verdade, seja o sistema ER ou qualquer outro tipo
do sistema IDAS.

Mude para um método de autenticação mais avançado.

Para você, isso pode ser uma autenticação sem senha, baseada em algo como o FIDO2.

Eu realmente adoro autenticação.

Eu poderia falar uns 30 minutos só sobre isso.

Mas a autenticação sem senha é algo que seus usuários vão realmente apreciar e que
, na minha opinião, torna o sistema muito mais seguro.

Senhas simplesmente não são um método seguro de autenticar o usuário.

Certifique-se de incluir o monitoramento de comportamento em sua verificação ou em sua verificação contínua
.

Como mencionei, comportamentos como acessar a rede às 2 da manhã,

quando, normalmente, você trabalha das 9h às 17h.

Este é um exemplo de monitoramento comportamental que você pode incluir em suas sessões e que aumenta
sua segurança.

Incorpore a automação à sua gestão do ciclo de vida e ao

ciclo de vida da identidade.

Assim, quando um usuário ingressa na organização, ele recebe imediatamente o acesso de que precisa.

E, quando ele sai da organização, perde completamente o acesso que tinha, para
para que você possa garantir que não haja contas abandonadas e possa proteger sua

rede.

Em seguida, implemente suas políticas como código para garantir uma aplicação consistente.

Trate suas políticas como código.

Tenha um repositório de políticas, por assim dizer.

Certifique-se de testar suas políticas de vez em quando.

Certifique-se de que suas políticas tenham controle de versão e de que sejam tratadas como código, sendo
registradas e removidas do repositório quando forem modificadas.

Espero que isso tenha fornecido informações suficientes para que vocês descubram como implementar uma política de confiança
zero para seus sistemas de IAM e realmente tornem sua rede mais segura.

Há algumas coisas que gostaria que vocês lembrassem sobre esta sessão.

Quero que vocês se lembrem de que é importante melhorar a higiene das identidades.

O número de identidades está disparando,

identidades no Novo Perímetro, e certifiquem-se de ter um plano em vigor que traga
melhorias, seja por meio da consolidação, limpeza desses silos e dessas

ou simplesmente aplicar políticas e práticas consistentes em toda a sua
organização.

Sempre tentem implementar algo que lhes dê vantagem, caso um agente
que alguém com más intenções consiga obter uma de suas identidades.

E uma coisa que é realmente importante lembrar de toda essa apresentação é que

A confiança não é algo que você concede apenas uma vez, quando o usuário se autentica.

É algo que deve ser verificado continuamente com base em suas ações e
o que, você sabe, eles estão fazendo na sua organização.

Portanto, deve ser algo que seja monitorado continuamente.

Espero que isso tenha sido útil para vocês.

Se houver alguns próximos passos que eu possa recomendar que vocês sigam, dois deles seriam
assistir a um podcast sob demanda.

Temos um podcast ou um webcast que aborda a resiliência de identidade do Active Directory.

É um ótimo webcast e recomendo que você assista.

Além disso, você pode aprender sobre resiliência cibernética e como a Commvault oferece suporte nessa área inscrevendo-se em um workshop sobre resiliência cibernética
ou participando de um treinamento de preparação para resiliência cibernética

, e os links estão ali na tela para você acessá-los.

Gostaria de agradecer imensamente pelo seu tempo hoje e pela sua
atenção.

Espero sinceramente que isso ajude vocês em sua jornada rumo ao modelo Zero Trust para seus sistemas de mensagens
instantâneas no futuro.

Muito obrigado pela presença de todos hoje e muito obrigado por terem participado.