Durante anos, o planejamento de Recovery seguiu um padrão conhecido. Elaborar o plano, documentar as etapas e presumir que ele funcionará quando necessário. Por muito tempo, essa abordagem se manteve válida. Falhas de hardware, interrupções isoladas e até mesmo desastres naturais — esses eram cenários que as organizações podiam antecipar e para os quais podiam se preparar com certo grau de confiança. Mas a situação mudou.

Neste episódio do STRIVE, conversei com Jason Cray, diretor de Experiência de Produto da Commvault, para explorar uma realidade que continuamos a observar em organizações de todos os tamanhos: a maioria não fracassa por falta de um plano de recuperação. Elas fracassam porque nunca comprovaram que esse plano se manterá firme sob pressão real. Assista ao episódio completo.

Principais conclusões: Por que os planos de recuperação fracassam

• Um plano documentado não é o mesmo que um plano comprovado. Se ele não tiver sido testado em condições reais, continua sendo apenas uma suposição.
• A recuperação é um trabalho em equipe. Segurança, infraestrutura e operações devem estar alinhadas — caso contrário, a recuperação fica mais lenta.
• A maior parte dos investimentos ainda ocorre “antes do boom”. A prevenção é importante, mas a preparação para a recuperação costuma ser negligenciada.
• Os testes revelam lacunas e geram confiança. Sem eles, as organizações acabam se baseando apenas na esperança.
• A resiliência é uma disciplina operacional. Ela exige iteração, comunicação e melhoria contínua.

O problema com a ideia de que “deveria funcionar”

No papel, a recuperação parece simples. Você define até que ponto recuperar, o que precisa ser recuperado e onde deve ser restaurado. O processo parece lógico, estruturado e fácil de gerenciar. Mas, como Jason destaca, essa simplicidade raramente resiste às condições do mundo real.

Os planos são elaborados em ambientes controlados, mas são executados em meio ao caos. Quando ocorre um incidente, as equipes não estão analisando calmamente a documentação — elas estão reagindo, solucionando problemas e tentando se alinhar em tempo real. É aí que surge a lacuna. Não entre ferramentas e tecnologia, mas entre expectativa e execução.

Antevisão: Por que os planos dão errado sob pressão

Nesse momento da conversa, Jason e eu explicamos por que ter um plano não é suficiente — e o que é realmente necessário para saber se um plano vai funcionar quando for preciso.

Já vimos isso antes

O interessante é que esse não é um problema novo; é um problema já conhecido, só que em um contexto diferente. Se voltarmos aos primórdios da recuperação de desastres, as organizações seguiam um padrão semelhante. Os planos existiam, mas os testes eram, na melhor das hipóteses, inconsistentes. Jason compartilhou um exemplo em que passou uma noite inteira ajudando um cliente a ser aprovado em um teste de recuperação de desastres para o qual achavam que estavam preparados. O plano parecia sólido. A execução contou uma história diferente.

Com o passar do tempo, as organizações se adaptaram. Passaram a realizar testes com maior frequência, introduziram exercícios de failover e, em alguns casos, chegaram até a operar a produção a partir de ambientes secundários para comprovar sua prontidão. Essa mudança da suposição para a validação é exatamente o que a resiliência cibernética exige atualmente.

A primeira falha: a comunicação

Se há uma questão que surge constantemente, é a comunicação. Em muitas organizações, as responsabilidades estão claramente definidas: a equipe de segurança cuida da prevenção, a de infraestrutura gerencia os sistemas e a de operações é responsável pela recuperação. Individualmente, cada equipe pode estar fazendo exatamente o que deve fazer. Mas a recuperação não ocorre isoladamente. Ela depende da eficácia com que essas equipes trabalham juntas quando algo dá errado.

Como Jason descreve, muitas vezes isso se transforma em um modelo de repasse de responsabilidades: “Fizemos nossa parte, agora é a vez de outra pessoa”. Essa abordagem gera atrasos, confusão e, em última instância, risco. Durante um incidente cibernético, a coordenação é mais importante do que a atribuição de responsabilidades.

O problema da “esquerda do boom”

Outro padrão que continuamos observando é o desequilíbrio na forma como as organizações concentram seus esforços. Há um investimento significativo em prevenção — ferramentas de segurança, plataformas de detecção e estratégias defensivas destinadas a impedir um ataque antes que ele ocorra. Esse investimento é necessário e desempenha um papel fundamental. Mas dá-se muito menos atenção ao que acontece depois do evento.

A suposição é que, se houver esforço suficiente na prevenção, a Recovery se torna uma preocupação secundária. Na realidade, o oposto é verdadeiro. Em algum momento, algo consegue passar. E, quando isso acontece, a Recovery se torna o fator determinante na forma como uma organização responde.

Da esperança à evidência

É aí que a mentalidade precisa mudar. Não se trata de adicionar mais ferramentas ou reescrever a documentação. Trata-se de passar de um modelo baseado na esperança para um modelo fundamentado em evidências.

Jason destaca uma observação fundamental: as organizações que lidam bem com as perturbações não são aquelas que evitam incidentes — são aquelas que sofrem menos impacto quando esses incidentes ocorrem. Elas testaram seus processos. Valida-ram suas suposições. Compreendem onde estão suas lacunas. Acima de tudo, elas conquistaram confiança — não por acreditarem que o plano vai dar certo, mas por provarem isso.

Comece aos poucos, ganhe impulso

Para muitas equipes, o desafio não é entender o problema, e sim saber por onde começar. A resposta não é mudar tudo de uma vez. É começar aos poucos e ir avançando a partir daí.

Concentre-se em um ou dois serviços essenciais. Entenda o que é necessário para recuperá-los. Reúna as equipes responsáveis por esses sistemas e teste o processo de ponta a ponta. A partir daí, amplie o escopo e continue aprimorando. Essa abordagem vai além de melhorar a recuperação — ela promove o alinhamento, reforça a comunicação e cria as bases para uma resiliência mais ampla.

A realidade: nenhum plano sobrevive ao primeiro contato

Um dos momentos mais sinceros da nossa conversa foi este: mesmo o melhor plano não vai funcionar exatamente como foi elaborado. Isso não é um fracasso — é o esperado. Jason resume assim: se você não tiver um plano, vai fracassar. Mas, mesmo que tenha um, ele não vai se desenrolar perfeitamente na hora.

O que importa é o quanto suas equipes estão preparadas para se adaptar. Os testes criam essa adaptabilidade. Eles desenvolvem a memória muscular necessária para responder de forma eficaz quando as condições não correspondem às expectativas.

Assista ao episódio completo

Ainda abordamos muitos outros assuntos nesta conversa do STRIVE, incluindo:

• Por que os planos de recuperação muitas vezes fracassam, apesar de serem bem documentados.
• O que diferencia as organizações que se recuperam de forma eficaz.
• Como as falhas de comunicação afetam a execução.
• Por onde começar para melhorar a preparação para a recuperação.
• Por que os testes são a base da resiliência.

Assista agora. Se você já se perguntou se o seu plano de recuperação realmente funcionaria, vale a pena dedicar um tempo a essa conversa.

Perguntas frequentes

P: Por que não basta ter um plano de recuperação?

R: Porque a maioria dos planos nunca é validada em condições reais. Sem testes, eles continuam sendo meras suposições, e não estratégias comprovadas.

P: O que faz com que os planos de recuperação falhem?

R: Os problemas mais comuns nos planos de recuperação são a falta de testes, a comunicação deficiente entre as equipes e as discrepâncias entre os processos documentados e a execução na prática.

P: O que significa “à esquerda da lança”?

R: “À esquerda da lança” refere-se ao foco na prevenção de incidentes antes que eles ocorram. Muitas organizações investem pesadamente nessa área, mas não investem o suficiente em recursos de recuperação.

P: Com que frequência os planos de recuperação devem ser testados?

R: Os planos de recuperação devem ser testados regularmente e em condições variadas. Os testes devem simular cenários realistas, e não apenas exercícios controlados.

P: Por onde as organizações devem começar?

R: Comece com um pequeno conjunto de serviços essenciais, coordene as equipes responsáveis e teste a recuperação de ponta a ponta antes de expandir.

P: Qual é a principal mudança de mentalidade?

R: Passar de um planejamento baseado na esperança para uma validação baseada em evidências.

Chris Mierzwa é diretor sênior de marketing de portfólio na Commvault.

Passamos anos nos concentrando na segurança de identidade no contexto das pessoas — quem tem acesso, o que elas podem fazer e como controlar isso. Esse modelo fazia sentido quando a maior parte da atividade no ambiente era conduzida por usuários humanos. Mas isso já não é mais o caso.

As identidades de máquinas – aplicativos, serviços, APIs e cargas de trabalho automatizadas – agora desempenham um papel central na forma como os sistemas modernos operam. Elas se autenticam, se comunicam e executam tarefas, muitas vezes sem supervisão direta. E, em muitos ambientes, já superam em número as identidades humanas por uma ampla margem.

Neste episódio do STRIVE, converso com Dan Conrad, Tecnólogo Principal e também CTO de Campo na Commvault. Analisamos mais de perto o que essa mudança significa – não apenas do ponto de vista da segurança, mas também do ponto de vista da governança. E exploramos por que tantas organizações ainda tratam isso como uma preocupação secundária. Assista ao episódio completo.

Principais conclusões: para onde o risco está se deslocando

• As identidades das máquinas estão crescendo mais rapidamente do que as identidades humanas, muitas vezes em ordens de magnitude.
• Os modelos de governança não acompanharam essa evolução, criando lacunas no acesso e no controle.
• A visibilidade é o principal desafio. Muitas equipes não compreendem totalmente como as identidades das máquinas se comportam.
• A proliferação de privilégios vai além dos usuários, já que as identidades das máquinas costumam ter acesso permanente.
• A resiliência depende da compreensão e do gerenciamento do escopo dessas identidades de máquinas antes que elas se tornem um problema.

O modelo de identidade mudou

Por muito tempo, o gerenciamento de identidades foi relativamente simples. Era possível mapear usuários a funções, definir políticas de acesso e criar controles com base em comportamentos previsíveis. Mesmo com toda a complexidade, o modelo ainda estava ancorado na atividade humana. As identidades das máquinas romperam esse modelo. Elas são criadas dinamicamente, muitas vezes como parte de processos de desenvolvimento ou implantação. Elas interagem entre sistemas de maneiras que nem sempre são visíveis, bem documentadas ou auditadas. E, ao contrário dos usuários humanos, elas não seguem um ciclo de vida bem definido — não são integradas e desativadas da mesma maneira estruturada.

Isso cria um tipo diferente de desafio. Não se trata mais apenas de controlar o acesso. Trata-se de entender como esse acesso está sendo utilizado, como ele evolui e como se conecta em todo o ambiente.

Antevisão: Não dá para fazer phishing com uma identidade não humana

Neste momento da discussão do STRIVE, Dan descreve como os invasores não estão atacando identidades não humanas diretamente por meio de phishing — eles são agentes mal-intencionados que utilizam contas humanas comprometidas por meio de engenharia social como um trampolim para escalar privilégios e se passar por identidades de máquinas com amplos poderes. Uma vez dentro do sistema, técnicas como “pass-the-hash” e contas de serviço com privilégios excessivos permitem que os invasores se movimentem lateralmente e verticalmente, mesmo após a redefinição das senhas.

A lacuna na governança

A verdadeira questão não é a existência das identidades de máquinas, e sim como elas são gerenciadas. Na maioria das organizações, existe um processo claro para gerenciar o acesso de pessoas:

• Os pedidos foram aprovados.
• As permissões são analisadas.
• As alterações são rastreadas.

Existe um nível de disciplina que resulta de anos de foco na identidade do usuário. No entanto, as identidades de máquinas muitas vezes ficam fora dessa estrutura. Elas são criadas rapidamente para dar suporte a aplicativos ou à automação. Recebem as permissões necessárias para funcionar, às vezes mais do que o necessário. E, com o tempo, essas permissões persistem. Esses acessos com permissões excessivas raramente são auditados, revisados e, mais importante ainda, raramente são reduzidos.

É aí que surge a lacuna. Torna-se difícil responder a perguntas básicas sobre acesso. Não porque a informação não exista, mas porque ela não foi organizada nem gerenciada de forma a torná-la utilizável.

Visibilidade antes do controle

Quando as organizações começam a lidar com esse problema, o instinto costuma ser o de reforçar os controles.

• Limitar permissões
• Restringir o acesso
• Aplicar novas políticas

Mas o controle sem visibilidade não resolve muita coisa. Se você não compreender como as identidades estão sendo utilizadas, o contexto empresarial em que se inserem — em termos de onde elas se conectam, com o que interagem e como se movimentam entre os sistemas —, então qualquer tentativa de restringi-las se tornará reativa e poderá resultar em uma desaceleração das operações comerciais. É por isso que a visibilidade precisa vir em primeiro lugar.

Quando você consegue ver como as identidades de máquinas se comportam, padrões começam a surgir. Você pode começar a entender onde o acesso é excessivo, onde existem dependências e onde o risco está concentrado. A partir daí, a governança pode se tornar mais precisa e mais eficaz.

Um tipo diferente de problema relacionado ao privilégio

A proliferação de privilégios não é novidade. A maioria das organizações vem passando anos tentando gerenciar o acesso excessivo por parte dos usuários humanos.

As identidades de máquinas trazem um problema semelhante, mas com uma dinâmica diferente. O acesso delas geralmente está integrado aos sistemas. É persistente, automatizado e raramente questionado depois de implementado. Isso torna mais difícil detectá-lo e mais fácil ignorá-lo. E quando algo dá errado, essas identidades podem se tornar uma porta de entrada para que agentes mal-intencionados as explorem

Por onde começar

Para a maioria das organizações, o desafio não é a conscientização, e sim saber por onde começar. O primeiro passo não é uma grande transformação. É criar clareza. Entender quantas identidades de máquinas existem. Onde elas estão sendo criadas. Quais permissões elas têm. Como são utilizadas. E, o mais importante, confirmar que um usuário humano está mapeado a um conjunto de identidades não humanas para fins de auditabilidade e prestação de contas.

Essas perguntas parecem simples, mas muitas vezes são difíceis de responder. E é exatamente por isso que são importantes. Pois, assim que você conseguir respondê-las, não estará mais agindo no escuro.

Assista ao episódio completo

Nesta edição do STRIVE, aprofundamos a forma como as identidades de máquinas estão mudando a maneira como as organizações devem encarar o acesso, a governança e a resiliência. É uma conversa prática sobre o que está acontecendo agora – e o que precisa mudar daqui para frente. Assista agora.

Recursos

Se você tiver interesse em saber mais sobre esse assunto, dê uma olhada neste e-book sobre identidades não humanas.

Perguntas frequentes

P: O que é uma identidade de máquina?

R: Uma identidade de máquina é uma identidade não humana utilizada por aplicativos, serviços ou sistemas para se autenticar e interagir com outros recursos.

P: Por que as identidades de máquinas estão se tornando um risco cada vez maior?

R: Porque seu número está aumentando, muitas vezes têm acesso contínuo e nem sempre são controlados com o mesmo rigor que os usuários humanos.

P: Em que elas diferem das identidades de usuário?

R: Elas operam continuamente, estão integradas a fluxos de trabalho automatizados e, muitas vezes, carecem de uma gestão estruturada do ciclo de vida.

P: Qual é o maior desafio que as organizações enfrentam ao gerenciar identidades não humanas?

R: Visibilidade. Muitas equipes não têm uma noção clara de quantas identidades de máquinas são criadas, utilizadas ou interconectadas.

P: Como isso afeta a resiliência?

R: Se forem comprometidas, as identidades das máquinas podem permitir que um agente mal-intencionado se desloque rapidamente entre os sistemas, tornando mais difícil conter os incidentes e se recuperar deles.

P: Por onde as organizações devem começar?

R: Identificando as identidades das máquinas, compreendendo suas permissões e estabelecendo práticas de governança que correspondam à sua escala e complexidade. E, acima de tudo, confirmando que um usuário humano esteja associado a um conjunto de identidades não humanas para fins de auditabilidade e prestação de contas

Vidya Shankaran é diretora de tecnologia de campo da Commvault.

Durante décadas, as operações de TI se concentraram no tempo de atividade:

• Manter a infraestrutura em funcionamento.
• Atinja sua meta de tempo de recuperação (RTO).
• Atinja sua meta de ponto de recuperação (RPO).

Mas as ameaças cibernéticas modernas não respeitam os limites da infraestrutura — e a recuperação já não se resume apenas a restaurar sistemas. Trata-se de restaurar dados limpos e confiáveis — entre equipes, mesmo sob pressão.

Neste episódio do STRIVE, conversei com Stephen Foskett, fundador e presidente do Tech Field Day do Futurum Group, para discutir uma disciplina emergente: operações de resiliência – ou ResOps. E isso é mais do que apenas uma palavra da moda. É uma mudança na forma como as organizações encaram a inteligência de recuperação. Assista ao episódio completo.

Principais conclusões: O que muda com o ResOps

• O ResOps muda o foco da recuperação, passando de uma abordagem centrada na infraestrutura para uma centrada nos negócios. Não se trata apenas de colocar os sistemas de volta em operação, mas de restaurar dados confiáveis e utilizáveis.
• As métricas tradicionais de RTO e RPO já não são suficientes. O Tempo Médio para Recuperação Completa (MTCR) está se tornando uma forma mais significativa de medir a resiliência.
• A eliminação dos silos é fundamental para a preparação cibernética. As áreas de segurança, infraestrutura e DevOps devem operar em sincronia — e não em paralelo.
• A resiliência é uma disciplina operacional, não uma ferramenta. A cultura, a comunicação e a coordenação são tão importantes quanto a tecnologia.
• A inteligência em recuperação está se tornando um diferencial competitivo. As organizações que realizam uma recuperação limpa e rápida protegem sua receita, reputação e confiança. 

De IT Ops a ResOps: o que mudou?

Stephen reflete sobre uma época anterior da TI, em que as equipes costumavam dar suporte a sistemas sem compreender totalmente as aplicações de negócios que eles alimentavam. Recuperação significava restaurar a infraestrutura. Hoje, esse modelo não é mais suficiente. Os ambientes modernos são:

• Distribuído
• Cloud
• Orientado por DevOps
• Sensível à segurança
• Profundamente integrado às fontes de receita

A ResOps reconhece que a recuperação já não é uma função isolada da área de TI. Trata-se de uma disciplina multifuncional que ajuda a conectar a infraestrutura, o desenvolvimento de software e a segurança a resultados reais para os negócios.

Por que as métricas tradicionais não revelam toda a história

RTO. RPO. Essas métricas têm orientado o planejamento de recuperação de desastres há anos. Mas, como explica Stephen, uma recuperação rápida não é suficiente se os dados recuperados não estiverem limpos. Insira uma métrica mais significativa: MTCR. Não se trata apenas da rapidez com que você se recupera; trata-se da rapidez com que você consegue se recuperar até um estado verificado e confiável.

Em um ataque de ransomware, essa diferença é extremamente importante. Restaurar dados comprometidos pode reiniciar um ciclo de ataque. O ResOps se concentra em restaurar a integridade operacional – não apenas a funcionalidade.

Antevisão: Por que a recuperação sem drogas é importante

Neste momento do STRIVE, Stephen explica por que as métricas tradicionais de recuperação não atingem o objetivo — e por que a recuperação é uma disciplina multifuncional.

A verdadeira barreira: os silos organizacionais

A tecnologia geralmente não é o maior obstáculo à resiliência. A estrutura é que o é. As equipes de segurança costumam se reportar a um executivo. As equipes de infraestrutura, a outro. As equipes de aplicativos, a outro ainda. Cada uma com prioridades diferentes, incentivos diferentes e definições diferentes de sucesso.

O ResOps desafia essa fragmentação. Stephen discute como as oficinas colaborativas e o alinhamento interfuncional estão ajudando a quebrar esses silos. Pois, durante um incidente cibernético, o desalinhamento organizacional retarda a recuperação mais do que quaisquer lacunas nas ferramentas jamais poderiam fazer.

Por que a Commvault está se posicionando nessa discussão

O STRIVE não se trata de Features de produto. Trata-se de como a visão sobre Recovery está evoluindo. O ResOps está em estreita sintonia com o que observamos na prática:

• Clientes que enfrentam dificuldades de coordenação durante incidentes.
• Organizações que estão restaurando a infraestrutura, mas questionam a integridade dos dados.
• A alta administração está solicitando indicadores que reflitam o impacto real nos negócios.

O conceito do MTCR redefine a inteligência de recuperação com foco na confiança empresarial — e é para lá que o setor está se dirigindo. A recuperação não é mais um processo administrativo. É uma preocupação da alta administração.

O Futuro da Inteligência de Recuperação

Olhando para o futuro, é provável que o ResOps amadureça rapidamente. Nos próximos 12 a 18 meses, espera-se que as organizações:

• Integrar de forma mais estreita os fluxos de trabalho de segurança e recuperação.
• Adotar novos indicadores voltados para a recuperação.
• Implementar a resiliência em um estágio mais precoce do ciclo de vida das aplicações.
• Invista em inteligência capaz de distinguir dados limpos de dados comprometidos.

As ameaças cibernéticas estão se intensificando. As estratégias de Recovery devem evoluir no mesmo ritmo. O ResOps ajuda a fornecer uma estrutura para isso.

Assista ao episódio completo

Neste episódio, discutimos:

• Como o ResOps difere das operações tradicionais de TI.
• Por que o MTCR está ajudando a redefinir os indicadores de recuperação.
• Como funciona o alinhamento organizacional na prática.
• Como a cultura DevOps influencia a resiliência.
• Para onde se espera que a inteligência de recuperação se dirija a seguir.

Assista agora. Se você é responsável pela preparação cibernética, pela continuidade de operações ou pela estratégia de recuperação, esta é uma discussão imperdível.

Perguntas frequentes

P: O que é ResOps?

R: ResOps (Operações de Resiliência) é uma disciplina emergente que integra operações de TI, segurança, DevOps e partes interessadas da empresa para ajudar a melhorar a inteligência de recuperação e a resiliência organizacional.

P: Em que o ResOps difere das operações tradicionais de TI?

R: As operações tradicionais de TI concentram-se principalmente no tempo de atividade da infraestrutura. O ResOps amplia esse foco para incluir a recuperação de dados confiáveis, a coordenação multifuncional e o alinhamento com os negócios.

P: O que é o Tempo Médio de Recuperação após a Limpeza (MTCR)?

R: O MTCR avalia a rapidez com que uma organização consegue restaurar dados verificados e livres de ameaças e retomar as operações com segurança após um incidente cibernético — e não apenas a rapidez com que os sistemas são colocados novamente em funcionamento.

P: Por que métricas como RTO e RPO são insuficientes em ambientes modernos?

R: Eles medem a velocidade e a atualidade dos dados, mas não a integridade dos dados. Em casos de ransomware, a restauração dos dados comprometidos pode prolongar a interrupção das atividades.

P: Como as organizações podem começar a implementar o ResOps?

R: Comece por:

• • Alinhamento das equipes de segurança, infraestrutura e DevOps.
  • Avaliação de métricas de recuperação além do RTO/RPO.
  • Teste de processos de recuperação sem erros.
  • Eliminando os silos operacionais.
  • Incorporar a abordagem da resiliência em um estágio mais precoce do projeto do sistema.

P: Por que a inteligência de recuperação está se tornando cada vez mais importante?

R: À medida que as ameaças cibernéticas se tornam mais sofisticadas, a capacidade de se recuperar de forma completa, rápida e segura tem impacto direto na receita, na confiança dos clientes e na conformidade regulatória.

Darren Thomson é diretor de tecnologia (CTO) de campo na Commvault.

Expandir uma empresa orientada por dados é difícil. Expandir uma empresa assim, ao mesmo tempo em que se cumpre os requisitos do GDPR, gerencia milhares de clientes, capacita equipes de análise e implanta uma nova infraestrutura em menos de duas semanas? Isso já é um outro nível de complexidade.

Em um episódio recente do STRIVE, conversei com Asif Dromi, da monday.com, e Ben Herzberg, da Commvault, para desvendar o que realmente é necessário para operacionalizar a segurança de dados em grande escala — não na teoria, mas na prática. Esta não é uma conversa genérica sobre melhores práticas. É uma visão realista de como as decisões relacionadas à segurança, conformidade, automação e infraestrutura se interligam quando o tempo está correndo.

Assista ao episódio completo. Se você é um CISO, líder de dados, arquiteto ou responsável pela conformidade, este episódio oferece algo mais valioso do que mera teoria. Ele mostra como:

• Uma empresa em rápido crescimento lidou com as exigências do GDPR sem prejudicar a inovação.
• A infraestrutura como código pode simplificar as auditorias.
• A automação reduz os riscos, em vez de aumentar a complexidade.
• A segurança e a agilidade nos negócios não precisam estar em conflito.

É raro ouvir diretamente os profissionais que já fizeram isso em condições reais de restrição. É isso que torna essa conversa do STRIVE diferente.

Pontos principais: Implementação da segurança de dados em grande escala

• Conformidade e crescimento não precisam estar em conflito. A Monday.com demonstra como os requisitos do GDPR e a rápida expansão podem coexistir quando a segurança é incorporada à arquitetura desde o início.
• Permissões manuais não são escaláveis. A automação, sim. A infraestrutura como código e os controles de acesso orientados por API podem transformar a governança de um gargalo em um multiplicador de força.
• O acesso baseado em funções deve evoluir acompanhando o uso dos dados. À medida que mais equipes passam a depender de análises, a visibilidade e os controles detalhados tornam-se importantes para ajudar a evitar a proliferação descontrolada de permissões.
• Segurança operacionalizada significa visibilidade. Não se trata apenas de definir políticas, mas de monitorar, auditar e adaptar os controles dinamicamente à medida que os ambientes mudam.
• É possível alcançar agilidade quando a arquitetura é planejada de forma intencional. Um data warehouse em conformidade com as normas europeias foi implantado em menos de duas semanas porque a governança, a automação e as ferramentas foram projetadas para escalar.
• A maturidade em segurança possibilita a inovação. Quando as permissões, a infraestrutura e a conformidade são programáveis, as organizações podem agir com mais agilidade.

O verdadeiro desafio: crescimento + conformidade + agilidade

Para a monday.com, o desafio não era apenas armazenar dados europeus na Europa. Era:

• Garantindo a conformidade com o GDPR e a residência regional de dados.
• Garantir que os funcionários acessassem apenas os dados relevantes.
• Manter a visibilidade e a auditabilidade.
• Apoiando analistas e desenvolvedores que precisavam de acesso rápido.
• Fazendo tudo isso sob prazos comerciais rigorosos.

Como Asif explica no episódio, tornar-se uma organização orientada por dados significa que o acesso interno se expande rapidamente. Quanto mais as equipes dependem da análise de dados, mais complexas se tornam as permissões. E é aí que muitas organizações esbarram em um obstáculo. A segurança passa a ser manual, as permissões se tornam frágeis e a conformidade passa a ser reativa. Isso não é segurança operacionalizada. É um castelo de cartas.

Incorporando a segurança à arquitetura desde o início 

Um dos aspectos mais interessantes do episódio é a forma como a monday.com abordou o problema do ponto de vista arquitetônico. Em vez de adaptar o sistema para atender às normas de conformidade, ela desenvolveu:

• Um data warehouse europeu dedicado.
• Controles de acesso claros e baseados em funções.
• Modelos de permissão detalhados.
• Camadas de governança automatizadas.

Ben descreve o que acontece em muitas grandes organizações: com o tempo, as permissões se acumulam em camadas, muitas vezes sem visibilidade centralizada. Eventualmente, ninguém tem certeza de quem pode acessar o quê. Operacionalizar a segurança significa evitar esse desvio. Significa construir sistemas nos quais a governança se expande automaticamente à medida que o uso cresce.

A automação é o multiplicador de força

Se há um tema que permeia este episódio, é a automação. Em vez de tratar as permissões como tickets e atualizações manuais, a monday.com envolveu sua infraestrutura em código. Bancos de dados, funções e políticas de acesso podiam ser criados e modificados programaticamente.

O resultado? Um ambiente em conformidade e escalável foi implantado em menos de duas semanas. Isso não é sorte. É arquitetura. E é um lembrete poderoso de que a segurança não atrasa o seu trabalho quando é implementada corretamente. Ela possibilita agilidade.

O que realmente significa colocar a segurança de dados em prática

O termo “operacionalização” é muito usado. Neste episódio, ele é definido como:

• Visibilidade contínua dos dados confidenciais.
• Gerenciamento centralizado e automatizado de permissões.
• Rastreamento de acesso.
• Integração com ferramentas de colaboração.
• Políticas que se adaptam à medida que o número de usuários e a quantidade de dados aumentam.

Controles estáticos não são escaláveis. Fluxos de trabalho manuais não são escaláveis. A segurança precisa se tornar dinâmica – parte da estrutura operacional da organização. E é nessa mudança que muitas empresas enfrentam dificuldades atualmente.

Assista ao episódio completo de STRIVE

Durante a discussão, você vai saber mais sobre:

• Como a monday.com estruturou seu data warehouse europeu.
• As principais lições aprendidas durante a implementação rápida.
• Por que a automação era imprescindível.
• O que as empresas costumam subestimar em relação à proliferação de permissões.
• Como abordar a implementação da governança antes que as iniciativas de IA se expandam.

Assista agora

Perguntas frequentes 

P: Como equipes pequenas podem implementar uma segurança de dados escalável?

R: Comece com um modelo de permissões bem definido e ferramentas de infraestrutura como código. Automatize o gerenciamento de permissões desde o início para ajudar a evitar gargalos manuais à medida que sua empresa cresce.

P: Qual é o papel da automação na conformidade?

R: A automação ajuda a garantir a consistência, reduzir erros e simplificar as auditorias. Com o uso de APIs e scripts, é possível monitorar e ajustar as permissões dinamicamente.

P: Quanto tempo leva, normalmente, para configurar um ambiente de dados em conformidade e escalável?

R: Com o planejamento e as ferramentas certas, organizações como a monday.com conseguiram isso em menos de duas semanas. A rapidez depende do escopo e da infraestrutura existente.

P: Quais são as melhores práticas para implementar a segurança de dados?

R: Implemente controles de acesso baseados em funções, automatize o gerenciamento de permissões, monitore regularmente os registros de acesso e integre ferramentas de segurança às plataformas de colaboração para garantir uma supervisão em tempo real.

Chris Mierzwa é diretor sênior de marketing de portfólio na Commvault.

Pontos principais

• As estruturas de conformidade codificam as lições aprendidas com falhas ocorridas na prática e ajudam as organizações a fortalecer a resiliência, a governança e a estabilidade operacional.
• As organizações que encaram a conformidade como uma iniciativa para construir confiança podem ajudar a fortalecer a confiança dos clientes, os relacionamentos com os parceiros e a credibilidade da marca.
• O alinhamento regulatório e controles de risco robustos podem ajudar a melhorar os resultados no setor de seguros, demonstrando uma postura de segurança madura e resiliente.
• A correspondência entre os requisitos de conformidade e os resultados comerciais mensuráveis permite que as organizações relacionem diretamente os investimentos em resiliência à proteção da receita e à continuidade dos negócios.
• Recursos de resiliência cibernética, como backups imutáveis, recuperação rápida e estruturas de governança, ajudam as organizações a transformar a conformidade em uma vantagem competitiva.

Nas salas de reunião por toda a Europa e além, “conformidade” tornou-se um termo carregado de conotações. Ele evoca imagens de documentação interminável, pressão regulatória crescente e a ameaça iminente de multas.

RGPD. NIS2. DORA. As siglas não param de surgir e, para muitas organizações, pode parecer que estão sufocadas pela regulamentação. Mas e se a gente tiver encarado a conformidade da maneira errada? E se a conformidade não se resumisse apenas a evitar penalidades, mas sim a construir uma empresa melhor, mais forte e mais resiliente?

A analogia com os seguros: regras que existem por um motivo

Há um paralelo interessante entre conformidade e seguros. Quando você faz um seguro para seu carro, a seguradora estabelece certas condições. Seus freios devem funcionar. Seus pneus não devem estar caridosos. Um sistema de alarme pode ser exigido. Você pode reclamar do incômodo ou do custo — mas, fundamentalmente, essas regras existem porque ajudam a reduzir o risco. Elas ajudam a diminuir a probabilidade de acidentes. Elas ajudam a proteger tanto você quanto os outros.

E aqui está o ponto principal: esses requisitos costumam ser uma boa ideia, independentemente de você contratar o seguro ou não. A regulamentação funciona de maneira muito semelhante. Governos e órgãos reguladores não criam estruturas regulatórias por prazer. As regulamentações são respostas a falhas do mundo real – violações de dados, interrupções operacionais, risco sistêmico. Elas codificam lições aprendidas da maneira mais difícil.

Você pode se opor a essa exigência. Pode achar isso frustrante. Mas, quando se analisa com atenção o que essas estruturas exigem, é difícil argumentar que os princípios fundamentais sejam falhos.

• Proteja os dados dos clientes.
• Promova a resiliência operacional.
• Conheça os riscos da sua cadeia de suprimentos.
• Ser capaz de se recuperar de incidentes cibernéticos.
• Demonstrar boa governança e prestação de contas.

Nenhuma dessas ideias é ruim.

De evitar multas a promover a confiança

Com muita frequência, a conformidade é abordada de forma defensiva: “Faça isso para não ser multado.” “Faça isso para não ir para a prisão.” Essa é uma meta muito modesta. E é uma oportunidade perdida. Quando mudamos de perspectiva, a conformidade se torna algo muito mais poderoso. Ela se torna um fator que gera confiança.

Veja o GDPR como exemplo. Em sua essência, trata-se de proteger dados pessoais. Se sua organização implementar práticas robustas de proteção de dados — não apenas para cumprir uma exigência, mas porque seus sistemas realmente salvaguardam as informações dos clientes —, isso gera confiança. Os clientes ficam mais confiantes em fazer negócios com você. Os parceiros ficam mais dispostos a se integrar com você. Os órgãos reguladores passam a vê-lo como um risco menor. A confiança não é um resultado da regulamentação. É uma vantagem comercial.

O mesmo se aplica à Lei de Resiliência Operacional Digital. Não se trata apenas de relatar incidentes; trata-se de ser capaz de resistir a interrupções e se recuperar delas. Em um mundo onde os ataques cibernéticos são inevitáveis, a resiliência não é opcional. É fundamental para a continuidade, a reputação e o valor a longo prazo. Quando a conformidade promove a resiliência, a resiliência promove a estabilidade dos negócios – e a estabilidade promove o crescimento.

Regulamentação e Seguros: Um Ciclo de Retroalimentação

Há também um alinhamento natural entre a regulamentação e os mercados de seguros. Quando os reguladores determinam certos padrões, as seguradoras rapidamente os seguem. Organizações que demonstram conformidade e controles de risco robustos são mais atraentes para as seguradoras. Elas podem se beneficiar de melhores condições, cobertura mais ampla ou prêmios mais favoráveis. Isso cria um ciclo de reforço:

• A regulamentação estabelece padrões mínimos.
• As organizações reforçam seus controles.
• As seguradoras recompensam abordagens mais rigorosas em relação aos riscos.
• Os mercados tornam-se mais estáveis e resilientes.

A conformidade, nesse contexto, torna-se um sinal para o mercado: levamos o risco a sério.

O elo que faltava: mapeando a conformidade para os resultados comerciais

Uma das oportunidades mais importantes para as organizações — especialmente para os fornecedores de tecnologia — é tornar explícita a “relação direta” entre conformidade e valor comercial. Por exemplo:

• Se um produto cria backups imutáveis, isso ajuda a atender aos requisitos regulatórios relativos à integridade dos dados.
• Se isso permitir uma rápida recuperação de incidentes cibernéticos, isso contribui para o cumprimento das exigências de resiliência operacional.
• Se o sistema fornecer trilhas de auditoria e relatórios claros, isso ajuda a atender aos requisitos de governança e supervisão.

Mas não deve parar por aí. O próximo passo é explicar os benefícios para a empresa:

• Backups imutáveis ajudam a reduzir o impacto do ransomware – e a proteger a receita.
• Uma recuperação mais rápida ajuda a minimizar o tempo de inatividade – e mantém a confiança do cliente.
• Uma boa governança ajuda a reduzir o escrutínio regulatório – e reforça a credibilidade da marca.

Esse mapeamento é fundamental. A conformidade não é o objetivo final; é o mecanismo que possibilita os resultados que importam para as empresas: continuidade, reputação, confiança do cliente e diferenciação competitiva.

A conformidade como inovação, e não como obrigação

Há uma tendência de tratar a conformidade como uma tarefa que “precisa ser cumprida”. Um centro de custos. Um mal necessário. Mas, se olharmos para a história, muitas das melhores práticas que hoje são consideradas fundamentais para a TI e a segurança modernas tiveram origem em exigências regulatórias ou de seguros. Com o tempo, elas passaram a fazer parte da forma como as organizações bem administradas operam. Criptografia. Controles de acesso. Planejamento de resposta a incidentes. Testes de continuidade de negócios. Gestão de riscos de terceiros. Em certa época, esses requisitos talvez fossem vistos como encargos regulatórios. Hoje, são condições mínimas indispensáveis para qualquer empresa que se preze. As organizações que tratam a conformidade como um catalisador de inovação — em vez de um exercício de preenchimento de formulários — costumam ser as que saem na frente. Elas incorporam resiliência à sua arquitetura. Elas projetam tendo a governança em mente. Elas transformam requisitos regulatórios em recursos de produto e propostas de valor para o cliente.

Resiliência cibernética: onde a conformidade e a estratégia se encontram

É aqui que a resiliência cibernética assume um papel central. As regulamentações modernas reconhecem cada vez mais uma verdade simples: a prevenção não é suficiente. Incidentes ocorrerão. O que faz a diferença é a capacidade de uma organização de responder e se recuperar.

A resiliência cibernética — a capacidade de resistir, se recuperar e se adaptar a perturbações cibernéticas — não é mais apenas uma questão de segurança. É um imperativo estratégico. Ela apoia a conformidade regulatória, sim. Mas, mais importante ainda, ela sustenta a continuidade operacional e a confiança nos negócios. Quando as organizações investem em arquiteturas resilientes, dados imutáveis, recursos de recuperação rápida e estruturas robustas de governança, elas não estão apenas atendendo às exigências dos órgãos reguladores. Estão construindo empresas duradouras.

Uma conversa diferente sobre conformidade

Talvez seja hora de mudar a narrativa. Em vez de perguntar: “Qual é o mínimo que precisamos fazer para cumprir as normas?”, deveríamos perguntar:

• De que forma esse regulamento nos torna mais fortes?
• Que boa prática está sendo codificada aqui?
• Como podemos usar isso para fortalecer a confiança dos clientes e parceiros?
• Em que aspectos isso gera uma vantagem competitiva?

A conformidade bem feita não tem a ver com medo. Tem a ver com visão de futuro. Isso reflete as lições aprendidas em diversos setores. Incorpora as melhores práticas às operações diárias. E, quando claramente associado aos recursos do produto e aos resultados comerciais, torna-se uma narrativa comercial poderosa.

Sim, a regulamentação pode parecer um fardo. Sim, as siglas não param de surgir. Mas, por trás da burocracia, há algo muito mais valioso: uma estrutura para administrar melhor uma empresa. A conformidade não se resume apenas a evitar penalidades. Trata-se de promover a resiliência. E a resiliência, em última análise, é o que impulsiona o sucesso sustentável. Saiba mais sobre como a Commvault oferece proteção de dados para ajudar sua organização a atender aos requisitos de conformidade aqui.

Perguntas frequentes

P: Por que as organizações deveriam encarar a conformidade como algo mais do que uma obrigação regulatória?

R: As estruturas de conformidade geralmente refletem as melhores práticas desenvolvidas em resposta a incidentes cibernéticos reais, falhas operacionais e desafios de governança. As organizações que adotam a conformidade de forma estratégica podem ajudar a fortalecer a resiliência, aumentar a confiança e gerar valor comercial de longo prazo.

P: De que forma a conformidade contribui para a confiança do cliente?

R: Práticas sólidas de conformidade demonstram que uma organização leva a sério a proteção de dados, a governança e a continuidade operacional. Isso pode ajudar a aumentar a confiança dos clientes, fortalecer as relações com os parceiros e posicionar a organização como uma empresa de menor risco.

P: Qual é a relação entre conformidade e resiliência cibernética?

R: As regulamentações atuais têm se concentrado cada vez mais na capacidade de uma organização de se recuperar de interrupções, em vez de apenas preveni-las. Investimentos em infraestrutura resiliente, backups imutáveis e recursos de recuperação rápida podem ajudar as organizações a manter a continuidade durante incidentes cibernéticos.

P: De que forma a conformidade pode ter um impacto positivo no setor de seguros e na gestão de riscos?

R: As seguradoras costumam ver com bons olhos as organizações que possuem programas de conformidade maduros e controles de segurança robustos. Isso pode resultar em melhores opções de cobertura, condições mais favoráveis nas apólices e, possivelmente, prêmios mais baixos.

P: Por que é importante vincular as iniciativas de conformidade aos resultados comerciais?

R: As iniciativas de conformidade são mais eficazes quando as organizações demonstram claramente como os controles contribuem para objetivos mais amplos, como proteger a receita, reduzir o tempo de inatividade e preservar a confiança dos clientes. Isso ajuda a liderança a encarar a conformidade como um investimento estratégico, em vez de um centro de custos.

P6: Como as organizações podem transformar a conformidade em uma vantagem competitiva?

R: As empresas que incorporam resiliência, governança e segurança em seus produtos e operações podem se diferenciar no mercado. Ao se alinharem proativamente às expectativas regulatórias, as organizações podem fortalecer sua reputação e gerar maior confiança entre clientes e partes interessadas.

Darren Thomson é Diretor Técnico de Campo (Field CTO) da Commvault.

Pontos principais

• A soberania operacional se concentra em quem pode acessar os sistemas e sob quais jurisdições eles operam.
• O acesso de fornecedores, os fluxos de telemetria e os canais de suporte podem criar lacunas ocultas em matéria de soberania.
• A soberania operacional é mais difícil de comprovar, pois exige visibilidade e auditoria contínuas.
• As organizações devem ser capazes de demonstrar e documentar todas as vias de acesso a ambientes soberanos.

Pergunte à maioria das organizações onde seu programa de soberania é mais forte, e a resposta geralmente é alguma variação das mesmas duas coisas: localização dos dados e criptografia. Elas sabem onde seus dados primários estão armazenados. Implementaram acordos do tipo “traga sua própria chave” ou “guarde sua própria chave”. Podem apresentar certificações.

Pergunte a eles quem acessou seu ambiente soberano nos últimos noventa dias, de quais países e sob quais jurisdições legais — e a confiança tende a desaparecer. A soberania operacional é o pilar mais difícil de auditar, o mais propenso a ser subestimado e o local mais comum onde uma postura de soberania que parece sólida no papel desmorona na prática. O Relatório de Readiness para a Soberania Digital a aponta como um dos quatro pilares – este artigo vai além. A pergunta que a maioria das organizações não consegue responder: “Quem acessou seu ambiente soberano nos últimos 90 dias, de quais países e sob quais jurisdições legais?”

O que realmente significa soberania operacional

A soberania operacional não se refere ao local onde os dados estão armazenados. Trata-se de quem administra o ambiente — e quem tem acesso a ele. Ela abrange três aspectos que a maioria dos programas de soberania trata como detalhes de implementação, em vez de questões prioritárias:

• Acesso de pessoal e jurisdição. Toda pessoa com acesso ao seu ambiente soberano — para suporte, manutenção, monitoramento ou resposta a incidentes — atua sob uma jurisdição legal definida. Se um engenheiro de suporte de um país sujeito a uma lei estrangeira de acesso a dados puder acessar seus sistemas, a soberania da sua infraestrutura será tão forte quanto a exposição legal desse engenheiro.

A maioria das organizações, ao realizar essa auditoria pela primeira vez, identifica pelo menos uma rota de suporte que atravessa um limite jurisdicional que não havia sido mapeado.

• Acesso de terceiros e fornecedores. Seu limite de soberania se estende a todos os fornecedores, prestadores de serviços gerenciados e platform de software platform acesso ao seu ambiente soberano. Plataformas de ITSM, ferramentas de monitoramento, sistemas SIEM — se esses recursos estiverem fora do seu limite de soberania, mas tiverem acesso a dados ou metadados dentro dele, você terá uma lacuna que os controles de localidade de dados não conseguem preencher.
• Tráfego de telemetria, faturamento e plano de controle. Os programas de soberania de dados concentram-se nos dados primários. A soberania operacional exige o mapeamento do destino de todo o restante: a telemetria gerada pela sua infraestrutura, os metadados coletados pelos seus sistemas de monitoramento e os dados de faturamento processados pelo seu provedor. Esses fluxos podem ultrapassar fronteiras jurisdicionais mesmo quando os dados primários não o fazem — e raramente são mapeados.

Por que esse pilar é mais difícil de certificar – e por que isso é importante

A localidade de dados é relativamente simples de documentar. Você pode indicar uma região de armazenamento, um acordo de residência de dados, uma auditoria de terceiros. A soberania operacional não possui o mesmo rastro documental. Não há certificação que garanta o status jurisdicional de cada engenheiro de suporte que possa acessar seu ambiente.

É exatamente isso que faz com que esse seja tanto o pilar mais difícil de auditar quanto o mais importante de se acertar. Isso também se relaciona diretamente com o desafio da soberania mínima viável: aplicar os controles operacionais corretos às cargas de trabalho certas exige saber quais são esses controles — e é justamente na soberania operacional que esse conhecimento costuma estar ausente.

A dimensão da cadeia de suprimentos

A NIS2, que amplia as obrigações de segurança cibernética nos setores de energia, transporte, saúde e infraestrutura digital, agora exige que as organizações avaliem as práticas de segurança cibernética de seus fornecedores de tecnologia. Para os programas de soberania, isso tem uma implicação direta: a postura de soberania em relação aos fornecedores não é mais apenas uma questão de conveniência nas aquisições. Trata-se de um requisito passível de auditoria.

Isso significa fazer novas perguntas a cada fornecedor dentro de seus limites de soberania: Onde está localizada sua equipe de suporte? Sob qual jurisdição legal eles operam? O que acontece com o acesso que eles têm ao meu ambiente se sua empresa for adquirida por uma entidade de fora da UE?

Como é o que é bom

Um ambiente operacionalmente soberano apresenta quatro características que podem ser comprovadas, e não apenas documentadas:

• Todas as vias de acesso ao ambiente soberano são mapeadas — não apenas o acesso principal, mas também o acesso de fornecedores, o acesso de suporte e o acesso ao sistema de monitoramento.
• A situação jurisdicional de cada pessoa ou sistema com esse acesso é documentada e auditada em intervalos definidos.
• Os fluxos de tráfego de telemetria, metadados e do plano de controle são inventariados e, ou ficam contidos dentro dos limites de soberania, ou são explicitamente avaliados e aceitos como estando fora do escopo.
• A organização pode responder à questão sobre o acesso em noventa dias – de forma precisa, com provas.

Mais uma coisa: a soberania operacional não se limita ao controle de acesso. Se a recuperação exigir pessoal que atue fora dos limites da sua soberania, a postura de segurança falha no momento em que ocorre um incidente. Esse é o tema do quarto post desta série. O Relatório de Preparação para a Soberania Digital inclui uma pergunta de avaliação direta sobre soberania operacional.

Perguntas frequentes

P: O que é soberania operacional?

R: A soberania operacional diz respeito a quem gerencia e acessa um ambiente, incluindo pessoal, fornecedores e sistemas de suporte. Ela vai além do local onde os dados são armazenados.

P: Por que a soberania operacional costuma ser negligenciada?

R: Muitas organizações concentram-se principalmente na localização e na criptografia dos dados. As vias de acesso, o pessoal de suporte e os fluxos de telemetria muitas vezes não são totalmente auditados.

P: Como os fornecedores afetam a postura de soberania?

R: Fornecedores e prestadores de serviços gerenciados podem ter acesso a sistemas confidenciais ou metadados. Suas jurisdições legais e práticas operacionais podem afetar a conformidade geral com as normas de soberania.

P: Por que a telemetria e os metadados são importantes?

R: Mesmo que os dados primários permaneçam locais, a telemetria e os metadados podem ultrapassar fronteiras jurisdicionais. Esses fluxos podem gerar riscos de conformidade se não forem gerenciados.

P: O que inclui um modelo sólido de soberania operacional?

R: Isso inclui rotas de acesso mapeadas, controles jurisdicionais documentados, acesso de fornecedores auditado e visibilidade de todos os fluxos de telemetria e metadados.

Alex Zinin é vice-presidente e gerente geral da área de Provedores de Serviços Gerenciados, da Commvault.

Pontos principais

• As arquiteturas soberanas costumam priorizar auditorias e controles de acesso em detrimento da prontidão para recuperação.
• Equipes de recuperação, sistemas de backup e modelos de custódia de chaves podem criar lacunas de soberania durante incidentes.
• É essencial que haja controles consistentes entre os ambientes primário e de recuperação.
• A resiliência pronta para a soberania exige procedimentos de recuperação testados em condições realistas.

Imagine uma situação. O ataque já ocorreu. A equipe de resposta a incidentes está se reunindo. Alguém precisa decidir quais sistemas serão restaurados primeiro, em que ordem, utilizando os pontos de Recovery corretos.

E então alguém percebe: os funcionários com acesso ao sistema de recuperação estão localizados em outro país. Pior ainda, o próprio ambiente de recuperação (hospedado em uma cloud , em um data center de um parceiro ou em um local secundário) nunca esteve sujeito aos mesmos controles de soberania que os dados primários. A prática não estava sujeita aos mesmos controles de soberania que os dados primários. O órgão regulador está solicitando informações sobre a situação. O tempo está passando.

Esse é o cenário para o qual a maioria das arquiteturas soberanas não foi projetada – e aquele que o Relatório sobre a Preparação para a Soberania Digital destaca diretamente: a maioria dos aplicativos soberanos é projetada para a auditoria, não para o incidente. A maioria das aplicações soberanas é projetada para a auditoria, e não para incidentes. A diferença fica evidente no pior momento possível.

O ponto cego da recuperação na arquitetura soberana

Os programas de soberania são construídos em torno do controle de acesso – quem pode acessar os dados, sob que autoridade, por qual caminho. Essa arquitetura é necessária. Mas não é suficiente. E ela se conecta diretamente às lacunas de soberania operacional exploradas no terceiro artigo desta série: se as pessoas que administram seu ambiente operam fora dos limites da sua soberania, esse problema não desaparece durante um incidente. Ele se torna o problema.

O que o controle de acesso deixa sem resposta é a questão mais complexa: o que acontece após um incidente, quando a recuperação não é apenas uma operação técnica, mas também está sujeita a restrições legais?

Um ataque de ransomware a uma organização europeia regulamentada não gera apenas um problema de recuperação. Ele gera um problema de recuperação que deve ser resolvido dentro de uma jurisdição, por meio de pessoal com as autorizações adequadas, com base em pontos de recuperação que possam ser comprovadamente limpos e não comprometidos. A arquitetura soberana projetada para proteger os dados pode dificultar a recuperação caso a resiliência não tenha sido incorporada ao projeto original.

Os modos específicos de falha

As formas como as arquiteturas de recuperação soberana falham são previsíveis – e comuns:

• Pessoal de Recovery fora dos limites da soberania. Os engenheiros que conhecem os sistemas de Recovery podem atuar em uma jurisdição diferente. Sob pressão, recorrer a eles é o caminho de menor resistência. É também uma violação da soberania no momento em que é menos conveniente que isso ocorra.
• Infraestrutura de backup sem controles adequados. Os ambientes primários sob jurisdição soberana são cuidadosamente controlados. A infraestrutura de backup — especialmente os ambientes mais antigos ou secundários — frequentemente não está sujeita aos mesmos requisitos de soberania. Se os pontos de recuperação forem armazenados ou processados fora dos limites, não será possível realizar uma recuperação em conformidade a partir de uma infraestrutura em conformidade.
• Custódia de chaves em situações de crise. Os acordos do tipo “cada um cuida da sua própria chave” são concebidos para operações normais. Em situações de crise — com os sistemas primários comprometidos e a pressão de tempo aguda —, o modelo de custódia de chaves que funciona durante uma janela de manutenção de rotina pode se tornar um obstáculo à recuperação. Se isso não tiver sido testado, trata-se de uma suposição, não de um controle.
• Lacunas de governança entre ambientes. As organizações que operam em vários níveis soberanos — o que se aplica à maioria delas — costumam ter controles rigorosos nos ambientes primários e controles mais fracos nos ambientes secundários, que também fazem parte do caminho de recuperação. A consistência em todo o parque de sistemas é o que os auditores irão buscar. As lacunas nos ambientes secundários tornam-se visíveis exatamente quando a consistência é mais importante.

Por que as restrições de soberania podem complicar a recuperação

Os mesmos controles que tornam um ambiente soberano defensável perante um auditor podem dificultar a recuperação a partir dele. Restrições à movimentação de dados que impedem a exfiltração não autorizada também limitam a orquestração da recuperação. Acordos-chave de custódia que garantem que nenhum provedor possa acessar seus dados sem autorização também criam atritos quando é necessário restaurar rapidamente.

Nada disso significa que esses controles estejam errados. Significa que eles precisam ser projetados tendo a recuperação em mente desde o início — e não adicionados a uma arquitetura em que a recuperação foi uma consideração tardia. Esse é o cerne do princípio da soberania mínima viável: calibrar os controles de acordo com os requisitos reais inclui os requisitos de recuperação, e não apenas os requisitos de controle de acesso.

O que é necessário para uma resiliência preparada para a soberania

• Validação de recuperação limpa. Comprovar que os pontos de recuperação estão livres de comprometimento antes da restauração para produção – não apenas recentes, mas não comprometidos. Em um cenário de ransomware, um backup recente pode, por si só, estar comprometido. A capacidade de identificar e restaurar a partir de um ponto de recuperação comprovadamente limpo, validado antes de ser necessário, é um requisito de soberania, não apenas um requisito de recuperação de desastres.
• Governança entre ambientes. Controles de soberania e evidências de auditoria consistentes em todo o parque de infraestrutura — não apenas na implantação soberana principal. Cada ambiente na rota de recuperação deve atender aos mesmos requisitos que o ambiente principal.
• Testado em condições realistas. Exercícios regulares que validam a recuperação nas condições que realmente existirão durante um incidente: as restrições legais aplicáveis, o pessoal disponível e os pontos de recuperação que estão em condições adequadas. Um teste anual de recuperação de desastres que não leve em conta as restrições de soberania não é um exercício preparado para a soberania.

A pergunta a ser incluída na sua análise sobre soberania

Existe uma maneira direta de avaliar se sua arquitetura de recuperação atende aos mesmos requisitos de soberania que seu ambiente de dados principal: faça essa pergunta e exija uma resposta sincera. Você consegue recuperar seus dados soberanos, de forma adequada, dentro das tolerâncias definidas, utilizando pessoal que atue dentro dos limites da sua soberania, neste exato momento — em condições reais, e não em um exercício controlado?

Para a maioria das organizações, a resposta sincera revela uma lacuna. As organizações que identificarem essa lacuna agora — antes que ocorra um incidente — estarão mais bem preparadas para apresentar evidências quando o órgão regulador as solicitar. As que não o fizerem terão que criá-las sob pressão, diante das pessoas que menos querem decepcionar. O Relatório de Preparação para a Soberania Digital inclui uma pergunta sobre a avaliação da arquitetura de recuperação direta.

Perguntas frequentes

P: Por que a recuperação é importante para a soberania digital?

R: A soberania é incompleta se as organizações não puderem recuperar dados dentro dos mesmos limites legais e operacionais utilizados para protegê-los.

P: Quais são as falhas comuns na Recovery soberana?

R: Entre as falhas mais comuns estão: equipes de recuperação atuando fora dos limites da soberania, infraestrutura de backup sem controles adequados e governança inconsistente entre os ambientes.

P: Como a custódia de chaves pode complicar a Recovery?

R: Os modelos do tipo “chave própria” reforçam a segurança durante as operações normais, mas podem retardar os esforços de recuperação durante incidentes se não forem devidamente testados.

P: O que é a validação de Recovery limpa?

R: A validação da recuperação limpa confirma que os pontos de recuperação não foram comprometidos antes da restauração dos sistemas. Isso é especialmente importante em casos de ransomware.

P: Como as organizações devem testar a resiliência preparada para a soberania?

R: Eles devem realizar exercícios realistas que levem em conta as restrições legais, a disponibilidade operacional e os pontos de recuperação validados — e não apenas testes padrão de recuperação de desastres.

Alex Zinin é vice-presidente e gerente geral da área de Provedores de Serviços Gerenciados, da Commvault.

Pontos principais

• A soberania mínima viável (MVS) concentra-se em aplicar o nível adequado de controle às cargas de trabalho certas.
• Tratar todas as cargas de trabalho da mesma forma pode levar a complexidade e custos desnecessários ou a proteção insuficiente.
• As organizações geralmente se enquadram em três perfis de soberania: soberania total, empresa regulamentada e multicloud híbrido.
• A governança consistente em ambientes mistos é um dos maiores desafios operacionais.

Existe uma versão do debate sobre soberania digital que leva as organizações a uma situação cara, operacionalmente onerosa e — se forem honestas — que vai além do que suas obrigações reais exigem. A soberania máxima parece responsável. Na prática, muitas vezes é um equilíbrio equivocado.

Há uma versão igualmente comum que leva a algo perigosamente superficial — controles que atendem a uma lista de verificação, mas não resistiriam a uma auditoria, a um incidente ou a um órgão regulador que deixou de aceitar a intenção documentada como prova de controle comprovado.

As organizações que acertam na soberania tendem a adotar uma abordagem mais rigorosa e prática do que qualquer um dos extremos: elas se perguntam o que realmente devem, a quem e para quê. Em seguida, atuam de acordo com esse padrão — nem mais, nem menos.

Essa é a disciplina do MVS, apresentada no Relatório de Readiness para a Soberania Digital e desenvolvida na íntegra aqui.

O MVS não é um atalho. É o reconhecimento de que o objetivo é o nível correto de controle, aplicado de forma consistente em todas as cargas de trabalho que o exigem.

Nem todas as cargas de trabalho são iguais

O ponto de partida para uma abordagem MVS é a classificação das cargas de trabalho – e a maioria das organizações ignora isso completamente.

Um sistema de negociação que processa dados financeiros regulamentados tem obrigações de soberania fundamentalmente diferentes das de uma ferramenta interna de colaboração de RH. Um banco de dados que armazena dados pessoais de cidadãos da UE está sujeito a um regime jurídico e regulatório diferente daquele de um ambiente de desenvolvimento que executa dados de teste anônimos.

Tratar todas essas cargas de trabalho da mesma forma — seja aplicando controles máximos de soberania de maneira generalizada, seja presumindo que um único modelo de implantação abranja tudo — é o que faz com que as organizações acabem com uma infraestrutura superdimensionada ou com proteção insuficiente.

A pergunta certa a se fazer antes de qualquer decisão de implantação: O que essa carga de trabalho exige em cada um dos quatro pilares de soberania? O Relatório de Readiness inclui uma autoavaliação estruturada exatamente em torno dessa pergunta.

Os três perfis – e o que eles realmente precisam

As empresas regulamentadas se enquadram em três perfis reconhecíveis, cada um com diferentes motivadores principais e prioridades de investimento.

• A Verdadeira Soberana. Órgãos governamentais, empresas contratadas pela defesa e operadoras de infraestrutura nacional crítica. Para essas organizações, a soberania não é um requisito de conformidade – é uma exigência operacional. O controle máximo sobre todas as dimensões da pilha de tecnologia é frequentemente exigido por lei, e as compensações de custo são aceitas porque a alternativa não é.
• A Organização Regulamentada. Empresas de serviços financeiros, organizações de saúde e empresas de energia. Essas organizações enfrentam requisitos vinculativos da DORA, NIS2, GDPR e estruturas específicas do setor. As obrigações de conformidade também podem se alinhar a esquemas de certificação da UE – incluindo EUCS, EUCC, BSI C5 e SecNumCloud –, dependendo do setor e do contexto de implantação.

Em certas áreas, isso é inegociável – particularmente no que diz respeito à residência de dados, controles de acesso operacional e Recovery dentro dos limites jurisdicionais. Mas nem toda carga de trabalho acarreta a mesma obrigação.

• A organização híbrida em multi-cloud. Organizações com investimentos existentes em hyperscalers que enfrentam pressão crescente em relação à soberania por parte de clientes, órgãos reguladores ou requisitos de aquisição. Seu desafio não é a migração em massa – é sobrepor controles de soberania a um ambiente misto e manter uma governança consistente em todo ele.

O custo de um ajuste incorreto

O excesso de engenharia na soberania gera seus próprios riscos operacionais. Organizações que aplicam controles soberanos máximos a cargas de trabalho que não os exigem absorvem custos e complexidade que não servem a nenhum propósito regulatório ou comercial.

A subengenharia é o modo de falha mais comum e também o mais perigoso. Normalmente, ela só se manifesta quando chega a auditoria – ou, o que é mais grave, quando ocorre um incidente e a Recovery se torna um problema com restrições legais. (Esse modo de falha é o tema da quarta postagem desta série.)

Um ponto de partida prático

Uma abordagem MVS segue três etapas:

1. Classifique as cargas de trabalho de acordo com seus requisitos reais de soberania em cada pilar – não comece pelos modelos de implantação.
2. Mapeie cada classe de carga de trabalho para o nível de implantação que atenda a esses requisitos, em todo o espectro, desde regiões de hiperescaladores públicos até nuvem pública soberana e ambientes gerenciados no local.
3. Gerencie o ambiente misto resultante de forma consistente – controles, evidências de auditoria e recursos de Recovery devem ser comprováveis em todo o ambiente, não apenas na camada mais soberana.

A terceira etapa é onde a maioria dos programas enfrenta dificuldades. Manter controles de soberania consistentes em um ambiente misto é um desafio de governança operacional – e, especificamente, do domínio da Soberania Operacional –, tema da terceira postagem desta série, o pilar que a maioria das estratégias trata como algo secundário.

Use a autoavaliação do Relatório de Readiness para a Soberania Digital para identificar sua posição atual em todos os quatro pilares.

Perguntas frequentes

P: O que é soberania mínima viável (MVS)?

R: A MVS é a prática de aplicar controles de soberania com base nas necessidades reais de negócios e regulatórias. Seu objetivo é ajudar a evitar tanto o excesso de engenharia quanto a proteção insuficiente.

P: Por que a classificação de cargas de trabalho é importante?

R: Cargas de trabalho diferentes acarretam obrigações regulatórias e operacionais diferentes. Classificar as cargas de trabalho ajuda as organizações a aplicar o nível adequado de controles de soberania.

P: Quais são os três perfis comuns de soberania?

R: Os três perfis são: organizações verdadeiramente soberanas, organizações reguladas e organizações híbridas multicloud. Cada um deles possui requisitos operacionais e de conformidade distintos.

P: Quais riscos decorrem de um excesso de controles de soberania?

R: Controles excessivos podem aumentar a complexidade operacional e os custos sem proporcionar conformidade significativa ou valor comercial.

P: Por que ambientes mistos criam desafios de governança?

R: As organizações costumam operar em vários modelos de nuvem e infraestrutura. É difícil manter controles consistentes, evidências de auditoria e padrões de Recovery em todos os ambientes.

Ruben Renders é diretor de soluções, MSP, na Commvault.

Pontos principais

• A residência de dados diz respeito ao local onde os dados são armazenados, mas a soberania digital também exige controle sobre o acesso, as operações e a compreensão adequada das implicações jurisdicionais.
• A soberania operacional costuma ser a parte mais frágil e menos auditada da maioria dos programas de soberania.
• Uma postura de soberania completa assenta em quatro pilares: localização dos dados, soberania tecnológica, soberania operacional e soberania jurisdicional.
• A soberania não é uma questão binária; as organizações devem definir uma postura alinhada às suas obrigações regulatórias e operacionais.

Aqui está uma questão que vale a pena refletir: quando sua organização tomou sua decisão sobre soberania, o que exatamente ela decidiu? Para a maioria, a resposta é alguma versão da mesma coisa. Escolher uma região. Transferir as cargas de trabalho. Escolher um provedor de nuvem com data centers no próprio país. Marcar a caixa. A questão de onde os dados ficam foi respondida, e a discussão sobre soberania foi considerada encerrada.

Mas não tinha acabado. Mal tinha começado. A residência de dados responde a uma pergunta: onde? A soberania digital levanta mais três: quem, como e em que condições? A confusão entre residência e soberania é compreensível. As hiperescaladoras fizeram com que a seleção da região parecesse uma decisão de soberania. As listas de verificação de conformidade perguntam onde os dados estão armazenados. As orientações regulatórias, pelo menos em suas versões iniciais, focavam fortemente na geografia.

A escolha de uma cloud soberana é algo concreto — é importante, tem implicações operacionais e é um primeiro passo necessário. Mas é apenas um primeiro passo. E a maioria das organizações parou por aí.

O que “Residency” não responde

Pense da seguinte maneira: escolher uma região de nuvem soberana é como comprar um cofre. Isso indica onde seus objetos de valor estão armazenados. Não diz nada sobre quem tem uma cópia da combinação, quem fabricou o cofre, quais leis regem o fabricante, nem se você pode abri-lo caso seja obrigado a isso.

A escolha da região responde a uma pergunta. Restam ainda três outras totalmente em aberto — e são essas as perguntas que os órgãos reguladores, as comissões de compras e os auditores estão fazendo agora com cada vez mais precisão:

• Quem pode operar seu ambiente e de onde? Se a equipe de suporte do seu provedor de nuvem está sujeita a jurisdição estrangeira é uma questão de soberania que a residência de dados não consegue resolver. Uma janela de manutenção de rotina realizada por um engenheiro de suporte em uma jurisdição legal diferente é uma via de acesso que sua política de residência não abrange. Esse é o domínio da Soberania Operacional – o pilar mais difícil de auditar e o mais comumente negligenciado.
• Sob qual regime jurídico seus dados podem ser acessados? Um provedor de tecnologia estrangeiro que opera infraestrutura no país não fica automaticamente isento da aplicação da legislação de sua jurisdição de origem. O alcance extraterritorial dos regimes jurídicos estrangeiros é um risco que a localização geográfica por si só não pode eliminar.
• Você consegue recuperar seus dados se algo der errado? A maioria dos programas de soberania é construída em torno do controle de acesso. Muito poucos abordam a Recovery – se seus dados podem ser restaurados de forma limpa, dentro de tolerâncias definidas, por pessoal que opera dentro dos limites da sua soberania. Essa lacuna é onde as estratégias de soberania mais comumente falham em condições reais.

A estrutura que preenche a lacuna

Uma postura completa de soberania abrange quatro pilares interdependentes. O Relatório sobre a Preparação para a Soberania Digital – disponível em readiverse.com – aborda cada um deles em detalhes. Resumidamente:

• A localidade dos dados refere-se aos locais por onde os dados e os metadados realmente trafegam.
• A soberania tecnológica abrange o controle sobre a criptografia, a custódia das chaves e a portabilidade da arquitetura.
• A soberania operacional abrange quem controla o ambiente e de onde.
• A soberania jurisdicional estabelece o marco jurídico que rege e afeta todos os aspectos acima mencionados.

Nenhum pilar, por si só, é suficiente. Uma postura sólida em relação à localidade dos dados, combinada com controles operacionais fracos, não é soberania — é residência com riscos não avaliados.

O que torna essa estrutura útil não é sua complexidade. São as perguntas que ela suscita. Quando uma organização mapeia sua situação atual em relação aos quatro pilares pela primeira vez, quase sempre descobre lacunas das quais não tinha conhecimento — não porque faltem controles, mas porque essas perguntas nunca foram feitas.

A soberania é uma escala variável

Mais uma coisa que vale a pena mencionar: a soberania não é um estado binário. Não há certificação que a conceda nem um único modelo de implantação que a garanta. É uma postura – um conjunto de decisões deliberadas e auditáveis. E o nível adequado dessa postura varia de acordo com a organização, a carga de trabalho e o que você realmente deve aos reguladores e clientes.

Essa calibração é o que define a soberania mínima viável — tema do segundo post desta série. A confiança regulatória é construída muito antes da própria auditoria – por meio de requisitos claramente definidos, e não de suposições vinculadas à localização geográfica. Baixe o Relatório de Preparação para a Soberania Digital para conhecer a estrutura de quatro pilares e uma ferramenta prática de autoavaliação.

Perguntas frequentes

P: Qual é a diferença entre residência de dados e soberania digital?

R: A residência de dados se concentra no local onde os dados são fisicamente armazenados. A soberania digital vai além, abordando quem pode acessar os dados, como os sistemas são operados e a exposição a quais jurisdições pode gerar risco jurídico.

P: Por que a seleção de uma região não é suficiente para garantir a soberania?

R: A escolha de uma cloud leva em conta apenas a localização geográfica. Ela não resolve questões relacionadas ao acesso operacional, à exposição a riscos jurídicos ou aos recursos de recuperação.

P: Quais são os quatro pilares da soberania digital?

R: Os quatro pilares são: localidade dos dados, soberania tecnológica, soberania operacional e soberania jurisdicional. Juntos, eles formam, em nossa opinião, uma estrutura mais completa para avaliar o grau de preparação soberana.

P: Por que a soberania operacional é difícil de gerenciar?

R: A soberania operacional envolve monitorar quem pode acessar os sistemas, de onde essas pessoas operam e sob qual regime jurídico. Esses controles são mais difíceis de auditar do que simples requisitos de localização de dados.

P: A soberania digital é uma certificação fixa?

R: Não. A soberania é uma postura contínua baseada em decisões deliberadas e auditáveis, que variam de acordo com a organização, a carga de trabalho e o ambiente regulatório.

Ruben Renders é diretor de soluções, MSP, na Commvault.

Pontos principais

• Os ataques de vishing aumentaram drasticamente, com grupos organizados industrializando a engenharia social para obter acesso inicial por meio de centrais de atendimento.
• Os invasores passam rapidamente de contas humanas comprometidas para identidades de máquina persistentes, como tokens OAuth e contas de serviço.
• A maioria das organizações carece de governança e visibilidade sobre identidades não humanas (NHI), criando um grande ponto cego de segurança.
• Readiness eficaz depende da correlação de sinais de identidade e do tratamento das identidades de máquinas como ativos de alto risco.
• A verdadeira resiliência requer a capacidade de detectar e reverter alterações não autorizadas de privilégios antes que os invasores estabeleçam persistência.

A equipe do seu suporte técnico acabou de receber uma ligação. Quem ligou sabia o nome do funcionário, o nome de seu gerente e os últimos quatro dígitos do número do crachá. Pediu a redefinição de senha. Procedimento padrão. O representante de TI atendeu ao pedido.

Aquela ligação era uma fraude. E o invasor agora está dentro do sistema.

O phishing por voz – vishing – aumentou 449% em 2025. Grupos de adversários transformaram a engenharia social em uma operação escalável: recrutando operadores, escrevendo roteiros e pagando de US$ 500 a US$ 1.000 por cada falsificação de identidade bem-sucedida no suporte técnico. Eles não estão atrás dos seus dados. Estão procurando um ponto de entrada.

Uma vez dentro, os invasores não se detêm na conta do usuário. Eles se movem lateralmente – roubando tokens OAuth, criando novas contas de serviço administrativo, incorporando acesso em credenciais da camada de máquina que ninguém monitora. Ao contrário das senhas de usuários, essas credenciais raramente são trocadas. Elas não acionam alertas de login. Podem sobreviver a uma correção completa do usuário originalmente comprometido.

Quando sua equipe de segurança encerra o ticket do incidente no help desk, o invasor pode já estar silenciosamente presente em seu ambiente há semanas. A lacuna de governança agrava ainda mais a situação.

Menos de 25% das organizações possuem políticas formais para a criação ou desativação de NHIs — as contas de serviço, chaves de API e tokens OAuth que agora superam em número os usuários humanos na proporção de 144 para 1. Quase todas elas possuem permissões que vão muito além do que sua função exige.

A maioria das organizações não tem praticamente nenhuma confiança em sua capacidade de detectar um ataque direcionado a essa camada. Isso não é uma falha de prevenção. É uma falha no planejamento de Recovery.

Como se apresenta a Readiness

Readiness significa correlacionar os sinais: uma interação com o suporte técnico seguida imediatamente por uma redefinição da autenticação multifatorial (MFA) ou pela criação de um novo token é um indicador de alta probabilidade de comprometimento.

Significa tratar as identidades de máquinas como ativos de Nível 0 – controlando sua criação, definindo o escopo de suas permissões e monitorando para evitar escalonamentos não autorizados. E significa ter a capacidade de detectar e reverter alterações maliciosas de privilégios rapidamente, antes que se tornem o novo normal.

Explore como a resiliência de identidade da Commvault oferece suporte à detecção rápida, reversão e Recovery do seu ambiente de identidade.

Perguntas frequentes

P: O que é um ataque de vishing no contexto da segurança corporativa?

R: O vishing (phishing por voz) usa chamadas telefônicas para se passar por funcionários e manipular os serviços de suporte de TI a fim de obter acesso – normalmente por meio de redefinições de senha ou de autenticação multifatorial (MFA). Trata-se de uma prática cada vez mais industrializada, com grupos organizados recrutando operadores e utilizando roteiros pré-escritos para maximizar as taxas de sucesso.

P: Por que os invasores mudam o foco para identidades de máquinas após um ataque de vishing?

R: Contas humanas são corrigidas. As identidades de máquina (NHIs) — tokens OAuth, contas de serviço, chaves de API — são mais persistentes e raramente são alternadas, muitas vezes ficando invisíveis ao monitoramento tradicional. A migração do acesso para a camada de máquina permite que os invasores mantenham essa persistência muito tempo depois que a violação original das credenciais humanas é detectada e corrigida.

P: O que significa “resiliência de identidade” na prática?

R: Significa que sua organização pode ajudar a detectar alterações não autorizadas de privilégios quase em tempo real e ajudar a restaurar rapidamente o ambiente de identidades a um estado confiável. A detecção por si só não é suficiente – a capacidade de reverter atividades maliciosas e verificar se as identidades de máquinas não foram adulteradas (ou, caso tenham sido, revertê-las para um ponto anterior em que estavam em bom estado) é o que diferencia a Readiness da exposição.

Vidya Shankaran é diretora de tecnologia de campo da Commvault.

Pontos principais

• A engenharia social no suporte técnico tornou-se atualmente um dos principais pontos de entrada, com os ataques de vishing (phishing por voz) aumentando rapidamente e levando ao comprometimento de credenciais.
• Identidades não humanas, como contas de serviço e tokens, constituem um grande ponto cego de segurança, muitas vezes não gerenciadas e amplamente exploradas para movimentação lateral.
• O Active Directory (AD) é um alvo de grande valor devido ao seu controle centralizado e às possíveis configurações incorretas.
• A prevenção por si só não é suficiente; as organizações precisam de recursos robustos de detecção e recuperação rápida para limitar os danos.
• Medidas operacionais imediatas — como a auditoria de contas e a correlação entre as atividades do suporte técnico e as alterações de identidade — podem reduzir significativamente o risco.

O AD continua sendo um dos principais alvos dos invasores, pois está no centro da identidade corporativa. Pesquisas recentes mostram que 67% dos incidentes envolvem atualmente violações relacionadas à identidade, com os invasores atacando sistemas críticos, como o AD, poucas horas após o acesso inicial. Uma vez comprometido, a recuperação pode levar dias ou semanas – causando uma interrupção significativa nas atividades da empresa.

A questão que vale a pena levantar não é se o AD é um alvo. É como os invasores chegam até lá – e por que o caminho é muito mais curto do que as equipes de segurança poderiam imaginar.

3 Passos para um Compromisso Total

Grupos de adversários como ShinyHunters e Scattered Spider transformaram a engenharia social em uma operação de produção. O phishing por voz – vishing – aumentou 449% em 2025. Os operadores de chamadas são recrutados, recebem roteiros e são pagos até US$ 1.000, dependendo do sucesso e da taxa de acerto.

Isso significa que é possível iniciar um ataque com apenas um passo: solicitar a redefinição de uma senha ou uma alteração na autenticação multifatorial (MFA). É só isso.

A partir dessa única credencial, o invasor se move lateralmente para ambientes em nuvem e virtualizados. Ele coleta tokens OAuth, cria novas contas de serviço administrativas e incorpora o acesso em credenciais na camada de máquina. Essas identidades não humanas – contas de serviço, chaves de API, tokens – agora superam os usuários humanos na proporção de 144 para 1. A expansão descontrolada e a sobrecarga operacional dificultam a rotação e a auditoria. Esse movimento lateral tem um destino: o Active Directory.

A publicidade é o alvo

O AD é o sistema nervoso central da identidade corporativa. Controle-o e você controlará tudo – contas de usuário, políticas de grupo e acesso a todos os sistemas associados ao domínio na rede. A razão pela qual ele é tão atraente para os invasores – e tão difícil de defender – é estrutural. Qualquer usuário autenticado pode ler o diretório inteiro. Todos os sistemas associados ao domínio herdam a confiança dele.

Os Objetos de Política de Grupo vinculados à raiz do domínio podem ser usados como arma para desativar completamente os controles de segurança. Protocolos legados mantidos ativados para compatibilidade de aplicativos oferecem acesso direto. A própria documentação da Microsoft afirma que “a maioria dos ataques à identidade utiliza configurações incorretas comuns no Active Directory”. Quando um invasor chega ao AD, ele não precisa forçar a entrada. A porta geralmente está aberta.

A prevenção é necessária, mas não suficiente

A pilha de segurança padrão — MFA, detecção de endpoints, filtragem de e-mail — é construída com base no comportamento humano. Ela não foi projetada para controlar a camada de identidade das máquinas nem para detectar o tipo de escalada de privilégios lenta e aparentemente legítima que caracteriza os ataques modernos ao AD. Um invasor que passa de uma conta humana comprometida para uma conta de serviço e, em seguida, para um administrador de domínio ao longo de 72 horas pode nunca acionar um único alerta.

É por isso que o foco da discussão deve passar de “prevenção em primeiro lugar” para “recuperação em primeiro lugar”. A prevenção continua sendo importante. Acesso com privilégios mínimos, auditoria das alterações no AD, fortalecimento das configurações padrão e desativação de contas inativas — essas medidas podem ajudar a reduzir a superfície de ataque. Mas, considerando que metade das organizações já sofreu um ataque ao AD, projetar apenas com foco na prevenção significa projetar para o fracasso.

A verdadeira resiliência de identidade requer a capacidade de detectar escaladas de privilégios não autorizadas quase em tempo real, reverter alterações maliciosas antes que elas se propaguem e restaurar o ambiente de identidade a um estado conhecido e confiável rapidamente — não em dias ou semanas, mas com rapidez suficiente para conter o alcance do impacto. Isso significa tratar o AD e a camada de identidades não humanas como ativos de Nível 0, com o mesmo investimento em governança e recuperação que você aplicaria a qualquer outro sistema de missão crítica.

O que fazer agora mesmo para garantir a resiliência da identidade

A lacuna entre onde a maioria das organizações se encontra e onde precisa estar em termos de resiliência de identidade é real. Mas é possível preenchê-la. As prioridades imediatas são pouco glamorosas e operacionais:

1. Faça uma auditoria no conteúdo do seu AD.
2. Identifique as contas que não deveriam mais existir.
3. Alterne as credenciais que não são utilizadas há anos.
4. Correlacione a atividade do help desk com os eventos de criação de tokens e contas.

Uma interação com o suporte técnico seguida de uma redefinição da autenticação multifatorial (MFA) e, em seguida, da criação de uma nova conta de serviço é um sinal de ataque de alta confiabilidade — e é detectável se você estiver atento a isso.

O trabalho de longo prazo é de natureza estrutural: incorpore capacidade de recuperação ao seu programa de identidade para que, quando um ataque for bem-sucedido — e geralmente é uma questão de “quando”, não de “se” —, você possa contê-lo, reverter seus efeitos e tentar restaurar a confiança mais rapidamente do que o invasor consegue consolidar sua posição.

Os invasores contam com o fato de seu AD não ser governado, suas identidades de máquina serem invisíveis e seu plano de recuperação ser apenas teórico. Preencha uma dessas lacunas neste trimestre. Preencha todas as três e você terá mudado fundamentalmente a equação. Saiba como o Commvault Cloud proteção abrangente para o AD – desde a avaliação de vulnerabilidades até a reversão com um clique e a recuperação completa da floresta.

Recentemente, participei do podcast STRIVE com Vidya Shankaran para discutir a lacuna de governança para identidades não humanas. Confira nosso episódio aqui. E não deixe de ler o blog da Vidya, “O ponto cego da identidade de máquina agora é uma superfície de ataque primária”.

Perguntas frequentes

P: Por que os serviços de suporte estão se tornando um grande risco à segurança? R: Os serviços de suporte técnico costumam ser encarregados de redefinir senhas e alterar configurações de autenticação multifatorial (MFA), o que os torna alvos atraentes para ataques de engenharia social. Os invasores exploram essa confiança para obter acesso inicial com o mínimo de resistência. P: Qual é o papel das identidades não humanas nos ataques?

R: A complexidade e a sobrecarga operacional dificultam a rotação e a auditoria de identidades não humanas, como contas de serviço e chaves de API. Os invasores as utilizam para manter a persistência e se deslocar sem serem detectados entre os sistemas. P: Por que o AD é um alvo tão crítico? R: O AD controla a autenticação e o acesso em toda a rede. Assumir o controle sobre ele permite que os invasores gerenciem usuários, políticas e sistemas em grande escala. P: A autenticação multifatorial (MFA) e a segurança de endpoints não são suficientes para impedir esses ataques? R: Essas ferramentas se concentram no comportamento humano e podem não detectar uma escalada de privilégios lenta e que pareça legítima. Os invasores podem agir dentro dos padrões normais e evitar acionar alertas. P: O que significa uma abordagem de segurança que prioriza a recuperação? R: Significa se preparar para a realidade de que violações ocorrerão e priorizar a capacidade de detectá-las, contê-las e revertê-las rapidamente. Essa abordagem ajuda a reduzir o tempo de inatividade e pode ajudar a limitar o impacto geral. P: Quais são as medidas mais importantes a serem tomadas imediatamente? R: Comece fazendo uma auditoria no seu AD, removendo contas desnecessárias, atualizando credenciais antigas e monitorando sequências suspeitas de atividades relacionadas ao suporte técnico e à identidade. Dan Conrad é Tecnólogo Principal e Diretor de Tecnologia de Campo na Commvault.