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

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

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

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

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

Fazer um inventário de todas as identidades, consolidar plataformas, exigir a autenticação multifatorial (MFA), automatizar a governança, segmentar o acesso e aplicar políticas de verificação contínua.

Assista ao vídeo aqui para 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
o seu sistema de gerenciamento de identidade e acesso.

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

Além disso, no final, apresentarei um roteiro que você poderá utilizar e que, espero, ofereça conselhos
práticos e etapas concretas que você possa seguir para implementar o Zero Trust em seu

sistema de IAM e que realmente o ajude a dar os primeiros passos e a obter algum sucesso inicial, talvez até na próxima
semana, enquanto você reflete sobre 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

a resolver seus desafios de resiliência de identidade em suas organizações.

Vamos lá, vamos direto ao assunto.

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

a identidade é o novo perímetro.

Nossa segurança costumava existir apenas 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
centers 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
opinião, é uma ótima imagem para refletirmos e pensarmos 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 está nessa situação híbrida em que temos uma solução local

e também utilizamos diversas plataformas na nuvem.

Nossas implantações de mensagens instantâneas (MI) enfrentam um grande desafio com isso, e Geoff Cairns aborda esse tema em um
artigo que escreveu anunciando o Forrester Wave™.

Ele afirma que as implantações de mensagens instantâneas de hoje são caracterizadas pela proliferação de identidades, múltiplas contas de usuário
e credenciais espalhadas por sistemas isolados, e que temos uma higiene 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ê adicionar o problema da IA genética à equação, verá essa explosão
do que chamamos de identidade não humana, ou NHI.

A CyberArk, em 2025, em um estudo de panorama, descobriu que as identidades de máquinas pesquisadas entre seus
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ço 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 para gerenciar essa explosão de identidades e 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 definir um pouco melhor como é
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 tenham mostrado que uma estratégia
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, adicionamos essas plataformas de nuvem à nossa organização para garantir resiliência.

E então descobrimos que cada uma dessas plataformas de nuvem que precisávamos ter 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
ele, verá que o processo é totalmente diferente de adicionar uma função ao IAM da AWS.

Quero dizer, existem alguns conceitos que são semelhantes, 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 uma função ou adicionar uma função a
ela do que ao Active Directory.

E, portanto, quando você vai além da interface do usuário, a coisa 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 impor regras, queremos aplicar
políticas consistentes entre plataformas e entre aplicativos.

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

Portanto, temos constantemente fusões e aquisições ou novas empresas ingressando em nossa
organização, 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 costumava trabalhar 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 passava por muitas 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

de aquisições que ocorreram 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 na nuvem.

E isso criou um grande problema para nós.

Além disso, quando esses usuários saíam da empresa, isso gerava muitas contas órfãs.

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

Portanto, a higiene de 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 torno de nossos sistemas de identidade.

E acho que existem certos princípios do Zero Trust que podemos aplicar aos nossos sistemas de IAM
para tornar as coisas mais seguras.

O primeiro é: 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 funções de trabalho,

essa conta possui privilégios excessivos.

E imagine o que poderia acontecer se um agente mal-intencionado obtivesse essa conta e conseguisse fazer 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
, dois deles, caso você não possa implementar os 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 rede 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 é algo que, se você detectar nessa sessão, vai querer encerrar
a sessão ou solicitar uma reautenticação para garantir que ainda seja a mesma pessoa

que ela disse ser ao se autenticar.

Portanto, verificar 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 dados ou realizar ações destrutivas, é preciso

que você a 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
mentalidade de “violação presumida”, certo?

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

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 audite 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á
precauções e sempre monitorará o que está acontecendo na sua rede

e em seus sistemas de identidade.

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

Bem, a primeira coisa que acho 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
as barreiras entre todas essas ilhas de identidade e unificá-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
pessoas são contratadas e inserem seus dados no sistema de RH.

Essa pode ser a fonte única de verdade e pode ser 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 desse tipo.

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 federar 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 é federar 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 podia ser federado

à nossa estratégia padrão 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 realizar a 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 na
VPN corporativa usando uma conta de usuário e um nome de usuário e, em seguida, passar por uma autenticação em duas etapas.

Em seguida, precisava fazer login em nossa plataforma na nuvem

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

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

E todas essas identidades 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 autenticação multifatorial (MFA), não conseguíamos identificar qual delas era.

Basicamente,

tínhamos que adivinhar e descobrir com qual delas o usuário estava tendo problemas, e eles não conseguiam
nos explicar facilmente 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 fortalecimento do acesso privilegiado.

Isso também é muito importante.

Uma das coisas que você precisa fazer é tratar seus administradores como as identidades
de maior risco na 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 elevadas o tempo todo.

Nenhum administrador deve ter permissões elevadas o tempo todo.

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 período de tempo necessário para
realizar a ação que desejam realizar.

Se você fizer isso em combinação com o princípio de confiança zero, terá uma
conta de administrador que só terá acesso por um determinado período para fazer 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 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 ambiente?

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, hum… armário de cabeamento em algum lugar nas instalações da sua organização

e ele é o único que consegue fazer login nele.

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 implementar, à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ê possa acessar e encerrar para realizar
as ações de nível mais alto, como, por exemplo, acesso 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 modificar 50 contas.

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

Seria uma ação muito destrutiva se ele, digamos, gerenciasse 50 contas de uma só
vez e fizesse uma alteração que causasse um grande impacto na sua organização.

Você quer ter algum tipo de mecanismo em vigor em que a autenticação dupla ou
aprovações duplas sejam exigidas 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 precise aprovar essa ação.

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 alto impacto.

Além disso, todas as sessões com privilégios, todas as sessões de administrador, você precisa garantir que todas
elas 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 cuidadosos 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 fortalecer o controle de acesso com privilégios.

Em seguida, 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 estamos fazendo é validar continuamente os usuários e verificar se eles têm ou não acesso
para realizar o que precisam fazer.

Sabe, é muito importante lembrar que só porque autenticamos um usuário pela primeira vez, isso
não significa que ele seja considerado 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; elas podem ser assumidas por malfeitores, que realizam ações
arriscadas.

Por isso, é importante validar continuamente o que o usuário está fazendo durante a sessão e analisar
a condiçã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 em sua

rede, é muito importante acompanhar isso.

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

Portanto, se alguém acessar o sistema e quiser elevar suas permissões ou criar uma
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 alta de dinheiro para outra conta, o 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 é algo fácil de implementar na sua organização e fácil de aplicar a
ações de risco.

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

Certifique-se de que, caso ocorra qualquer anomalia em uma sessão, você reautentique
o usuário.

Portanto, se um usuário normalmente não acessa dados financeiros no SharePoint e começa a acessá-los
ou a solicitar acesso a eles, talvez seja hora de reautenticar ou examinar essa

sessão e certifique-se de que se trata de algo que ainda é válido para o usuário.

Além disso, você deve ajustar o nível de risco dinamicamente com base no risco

ou com base no 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
da manhã

da 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 comprometida ou
que seu token não foi 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
comprometidas 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 manter isso em um nível geral e prático.

Mas essas são algumas questões sobre as quais você pode refletir, 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” na sua

organização.

Então, nos primeiros 30 dias, acho que algumas das melhores coisas nas quais se 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), essa é uma conquista muito rápida.

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 já tiver MFA em todos os lugares, talvez seja o momento de

você queira migrar para uma autenticação em duas etapas resistente a phishing, com um padrão FIDO2 ou algo
nesse sentido.

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

Comece também a mapear seus silos de identidade.

Determine 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 minimamente.

Sabe, comece com pequenas medidas incrementais 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, trabalhe para construir consistência.

Comece seu plano de consolidação de identidades.

Comece a executar uma consolidação de identidades.

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

Certifique-se de que seja possível chegar a uma identidade por 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 sua
gestão do ciclo de vida.

Como será 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 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 examinar seus dispositivos e garantir que
sejam confiáveis, além de assegurar que as pessoas que os utilizam

tenham dispositivos confiáveis — talvez com uma imagem corporativa ou algo que atenda a um
determinado padrão da empresa — e marque esses dispositivos como de risco caso não atendam

a esse padrão.

E, então, crie essas contas de classe de exceçã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 estabelecer essas contas de classe de interrupção o mais rápido possível.

E, então, trabalhe em direção à maturidade a longo prazo.

Expanda sua consolidação.

Certifique-se de chegar a essa fonte única de verdade, seja o sistema de emergência (ER) ou algum tipo
de sistema IDAS.

Mude para uma forma mais avançada de autenticação.

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 comportamental 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.

Esse é um exemplo de monitoramento comportamental que você pode adicionar às suas sessões e que aumenta
sua segurança.

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

ciclo de vida de 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
que você possa garantir que não haja contas abandonadas e que possa proteger sua

rede.

Em seguida, aplique 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 tempos em tempos.

Certifique-se de ter controle de versão em suas políticas e de que elas sejam tratadas como código, sendo
registradas e retiradas quando 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á explodindo,

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
mal-intencionado obtenha uma de suas identidades.

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

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

É algo que deve ser continuamente verificado — por meio das ações dos usuários e
do que eles estão fazendo em sua organização.

Portanto, deve ser algo 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 ajuda 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.

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

Espero sinceramente que isso ajude vocês em sua jornada rumo à modelagem de confiança zero para seus sistemas de mensagens instantâneas
no futuro.

Muito obrigado pela participação de todos hoje e muito obrigado por terem vindo.