Skip to content

Pontos principais

  • É provável que o Mythos acelere a descoberta de vulnerabilidades a uma escala e velocidade que superem os fluxos de trabalho tradicionais de correção, conduzidos por pessoas.
  • Princípios fundamentais de segurança, como a aplicação de patches, backups em sistemas isolados e o gerenciamento disciplinado de vulnerabilidades, continuam sendo essenciais, mas podem não ser mais suficientes por si só.
  • O principal desafio é passar da detecção para a capacidade de agir, à medida que o volume de vulnerabilidades cresce para além dos limites operacionais atuais.
  • A resiliência da IA depende da capacidade de recuperar sistemas coerentes — e não apenas dados — em todos os modelos, fluxos de trabalho e permissões.
  • As organizações que se adaptarem de forma proativa durante essa fase inicial provavelmente estarão em uma posição significativamente melhor do que aquelas que adiarem a tomada de medidas.

Há algumas semanas, eu estava em uma sala com um grupo de CIOs e CISOs quando a conversa se voltou para o Mythos e o Projeto Glasswing. A energia foi imediata — trata-se de pessoas que já passaram por muitos ciclos de hype, e isso chamou a atenção delas. As reações se dividiram em dois campos. Primeiro: as categorias de ameaças não são novas — organizações com gerenciamento sólido de vulnerabilidades e backups isolados em rede confiáveis estarão em melhor posição do que aquelas que não as possuem. Segundo: a velocidade é diferente – não apenas o que o Mythos consegue detectar, mas com que rapidez os agentes mal-intencionados poderiam aproveitar a IA para ataques na velocidade de uma máquina, e como isso afeta os cálculos nos quais a maioria dos programas de gerenciamento de vulnerabilidades se baseia. Ambos estavam certos. Foi isso que fez com que valesse a pena escrever sobre essa conversa.

O que o Mythos muda – e o que não muda

O Mythos é o modelo de IA da Anthropic para a detecção autônoma de vulnerabilidades. Ele é capaz de identificar e encadear exploits críticos nos principais sistemas operacionais com uma taxa de sucesso que, acredita-se, não tenha precedentes reais nesse domínio.

O Projeto Glasswing — o consórcio de empresas reunido para testar e fortalecer seus sistemas antes que o Mythos ou recursos semelhantes cheguem às mãos dos adversários — é o sinal de que isso é real, já está aqui e que o prazo para nos anteciparmos a isso é curto. A visão que prioriza os fundamentos permanece válida: a aplicação de patches é importante, backups virtualmente isolados são importantes, a disciplina na gestão de vulnerabilidades é importante. Nada disso muda com o Mythos. O que muda é a taxa de produção do outro lado desses programas. Após o caso Glasswing, a questão não é se você possui um programa de gerenciamento de vulnerabilidades. É se ele foi desenvolvido para lidar com descobertas que surgem aos poucos — ou como um tsunami. A maioria dos programas foi desenvolvida para o fluxo lento. Avaliações periódicas, filas de priorização baseadas no CVSS, ciclos de correção e testes medidos em semanas. Esse ritmo fazia sentido quando o ritmo das descobertas correspondia ao ritmo dos processos conduzidos por pessoas. A capacidade da classe Mythos rompe com essa suposição – o volume de descobertas exploráveis pode exceder o que a maioria das organizações consegue processar por meio dos fluxos de trabalho que possuem hoje. A questão não é a detecção. É a capacidade de agir — e o que acontece quando a lacuna entre a descoberta e a correção se amplia mais rápido do que você consegue preenchê-la.

Quando a prevenção é restringida, a resiliência ganha força

Quando os prazos para a prevenção são reduzidos, a questão da resiliência passa a ser prioridade. Se você não pode garantir que aplicará todas as correções antes que uma vulnerabilidade seja explorada — e, cada vez mais, isso não é possível —, as questões que importam mudam: com que rapidez você detecta? Como você contém o problema? E, ao se recuperar, para qual estado exato você está voltando?

Essa última pergunta é mais difícil do que parece, especialmente para organizações com interações progressivas entre agentes. Um sistema de IA não é apenas dados. É uma versão de modelo, um pipeline de treinamento, um banco de dados vetorial, um conjunto de identidades e permissões de agentes – e tudo isso precisa refletir o mesmo estado operacional para constituir algo em que você possa realmente confiar. A maioria das organizações consegue restaurar componentes individuais. Muito poucas conseguem comprovar que o que restauraram é coerente.

A recuperação de um sistema de IA não é uma questão de restauração de dados. É uma questão de coerência — e é justamente nessa lacuna entre essas duas coisas que a maioria das empresas está atualmente vulnerável. Esse é o fio condutor que liga o Mythos ao debate mais amplo sobre resiliência em IA. Não é que o Mythos introduza um novo tipo de risco que exija uma nova estrutura.

O Mythos comprime a linha do tempo de tal forma que as lacunas existentes vêm à tona mais rapidamente, deixando menos tempo para corrigi-las antes que algo dê errado, aumentando assim a probabilidade de que algo dê errado antes que uma organização consiga corrigir adequadamente as vulnerabilidades.

A janela está aberta. Mas não vai ficar assim por muito tempo.

O Glasswing foi projetado para dar uma vantagem inicial aos defensores. As organizações que utilizarem essa janela de oportunidade de forma deliberada — testando a resistência de seus programas de vulnerabilidade em termos de volume, levando a infraestrutura de resiliência de IA a um estado em que possam se defender e tratando a recuperação como algo que deve ser comprovado antes de um incidente, e não montado durante ele — estarão em uma posição significativamente melhor do que aquelas que ficarem esperando. Os princípios básicos continuam válidos. A urgência é nova.

“A Empresa Agente: Por que a resiliência da IA exige um sistema de registro” – o mais recente Relatório de Preparação da Commvault – examina as lacunas na infraestrutura de resiliência da IA que determinam se as organizações são capazes de responder às difíceis questões relacionadas à recuperação quando o ritmo das ameaças assim o exige.

Perguntas frequentes

P: O que é o Mythos e por que ele é importante?

R: O Mythos é um modelo de IA projetado para a detecção autônoma de vulnerabilidades, capaz de identificar e encadear exploits entre sistemas a uma velocidade sem precedentes. Sua importância reside na forma como ele reduz o intervalo de tempo entre a descoberta da vulnerabilidade e sua possível exploração, aumentando o desafio para os defensores.

P: O Mythos altera os princípios fundamentais da segurança cibernética?

R: Não, práticas essenciais como a aplicação de patches, backups e gerenciamento de vulnerabilidades continuam sendo importantes. O que está mudando é o volume e a velocidade das ameaças, o que exerce pressão sobre os processos existentes, que foram projetados para fluxos de trabalho mais lentos e previsíveis.

P: Por que os programas atuais de gerenciamento de vulnerabilidades podem enfrentar dificuldades?

R: Muitos programas foram desenvolvidos para lidar com um fluxo constante de descobertas, e não com o aumento repentino de descobertas possibilitado pela IA. Como resultado, as organizações enfrentam uma lacuna cada vez maior entre a identificação de vulnerabilidades e sua correção efetiva.

P: O que significa “resiliência” no contexto dos sistemas de IA?

R: A resiliência vai além da restauração de dados — envolve a recuperação de todo um sistema de IA em um estado coerente e confiável. Isso inclui modelos, pipelines de treinamento, bancos de dados vetoriais e controles de acesso, todos alinhados corretamente.

P: Por que a recuperação está se tornando mais importante do que a prevenção?

R: À medida que os prazos de prevenção se reduzem devido à exploração cada vez mais rápida, está se tornando irrealista aplicar todas as correções a tempo. Isso muda o foco para a rapidez com que as organizações conseguem detectar, conter e se recuperar de incidentes.

P: Como as organizações podem começar a se preparar?

R: As organizações podem submeter seus processos de gerenciamento de vulnerabilidades a testes de estresse, modernizar a infraestrutura de resiliência e validar os recursos de recuperação. Agir nessa janela inicial proporciona uma vantagem estratégica significativa.

Tim Zonca é vice-presidente de gestão de portfólio da Commvault.

More related posts

Thumbnail_Blog-Anthropic-Project-ResOps-2026

Anthropic’s Project Glasswing Makes the Case for ResOps

Read more

Pontos principais

  • A IA agentiva traz novos riscos à segurança, pois planeja, memoriza e age em diversos sistemas, em vez de se limitar a um único ciclo de solicitação-resposta.
  • Dados de treinamento contaminados podem influenciar discretamente o comportamento do modelo em grande escala, mesmo quando o modelo ainda parece apresentar um desempenho normal em testes padrão.
  • Bancos de dados de vetores comprometidos podem influenciar as decisões dos agentes ao corromper o contexto no qual o modelo se baseia, fazendo com que comportamentos inadequados pareçam legítimos.
  • A identidade de agentes não controlados gera um problema de controle de acesso na velocidade das máquinas que os sistemas tradicionais de identidade, centrados no ser humano, não foram projetados para lidar.
  • Decisões em cascata baseadas em um estado incorreto podem espalhar a corrupção por vários agentes e fluxos de trabalho, tornando a reversão e a recuperação muito mais difíceis.

As ferramentas, os controles e as políticas de governança que a maioria das empresas possui foram projetados para sistemas que respondem a perguntas – ferramentas de recuperação, copilotos, assistentes generativos. Sistemas que respondem a um prompt e param. Quando algo dava errado, a falha era isolada. Corrigia-se o prompt, ajustava-se a configuração e seguia-se em frente.

A IA agentiva não funciona dessa maneira. Esses sistemas planejam, memorizam e executam em toda a empresa sem instruções humanas passo a passo. Eles mantêm o estado. Eles se coordenam com outros agentes. Eles agem em sistemas de produção – gravando em bancos de dados, acionando fluxos de trabalho, tomando decisões na velocidade das máquinas. Essa mudança arquitetônica introduz quatro vetores de ameaça que as estruturas de segurança existentes nunca foram projetadas para lidar. Se sua estratégia de governança de IA não levar isso em conta, é provável que você tenha vulnerabilidades que talvez nem consiga identificar.

1. Dados de treinamento contaminados

Um sistema de IA é tão confiável quanto os dados com os quais foi treinado. Essa afirmação sempre foi verdadeira. O que mudou foi a superfície de ataque.

Em implantações de IA agente, os pipelines de treinamento são maiores, mais complexos e frequentemente montados a partir de múltiplas fontes – dados internos, feeds de terceiros, conjuntos de dados fornecidos por fornecedores. Cada dependência nessa cadeia é um ponto potencial de injeção. Um agente mal-intencionado capaz de influenciar os dados de treinamento — por meio do comprometimento da cadeia de suprimentos, acesso privilegiado ou contaminação de uma fonte de dados compartilhada — pode moldar o comportamento do modelo em grande escala. O que torna isso particularmente perigoso é que os modelos envenenados costumam apresentar desempenho normal em testes de benchmark padrão. A manipulação pode ser cirúrgica: projetada para produzir resultados específicos em contextos específicos, ao mesmo tempo em que se comporta corretamente em todas as outras situações.

Quando o efeito se manifesta na produção, o modelo já está em uso há semanas ou meses, e rastrear a contaminação até sua origem exige exatamente o tipo de proveniência de dados relacional que a maioria das organizações não possui. A pergunta a se fazer é: você consegue apresentar um registro completo e verificável dos dados com os quais seus modelos foram treinados — em um momento específico?

2. Bancos de dados de vetores comprometidos

Os bancos de dados vetoriais constituem a camada de memória dos sistemas baseados em agentes. Antes de um agente agir, ele consulta um repositório vetorial para recuperar o contexto relevante — interações anteriores, conhecimento do domínio, dados de referência — que determina o que ele fará a seguir. A maioria das equipes de segurança não encara os bancos de dados vetoriais da mesma forma que encara outros repositórios de dados confidenciais. Mas deveria. Um banco de dados vetorial comprometido não retorna apenas respostas erradas. Ele molda as decisões que se seguem. Incorporações injetadas — conteúdo malicioso inserido no armazenamento de vetores — podem redirecionar o comportamento do agente de maneiras que parecem completamente legítimas do ponto de vista externo.

Um agente solicitado a aprovar uma transação recupera um contexto que reestrutura sutilmente os critérios de aprovação. Um agente que gerencia as comunicações com os clientes extrai um contexto que direciona as respostas na direção preferida do invasor. A ação parece correta. O raciocínio parece sólido. Mas o contexto subjacente foi manipulado.

Esse vetor de ataque é particularmente difícil de detectar porque opera abaixo da camada do modelo. O monitoramento padrão do modelo não o detectará. O modelo está se comportando exatamente como foi treinado – é o contexto a partir do qual ele raciocina que foi corrompido. A pergunta a se fazer é: seu banco de dados vetorial é tratado como um ativo de dados sensível e regulamentado — com controles de acesso, monitoramento de integridade e registros de auditoria comparáveis aos de seus bancos de dados de produção mais críticos?

3. Identidade do agente não regulamentado

Em uma arquitetura multiagente, os agentes não interagem apenas com dados — eles interagem uns com os outros. Eles geram subagentes, delegam tarefas, solicitam resultados e sintetizam resultados de agentes aos quais nunca estiveram explicitamente conectados. Para isso, eles se autenticam, apresentam credenciais e estabelecem confiança.

A identidade do agente é a camada de controle de acesso para a empresa autônoma — e é uma lacuna que os fornecedores de segurança de identidade e os provedores de identidade (IDPs) não conseguem preencher. Suas estruturas de governança são projetadas para a identidade humana.

As identidades dos agentes criadas de acordo com essas mesmas regras parecem totalmente legítimas: foram provisionadas corretamente e seguiram a política. O IDP não está falhando — ele simplesmente não possui uma estrutura para determinar se um agente está agindo fora do contexto para o qual foi criado, se teve seus privilégios ampliados sem que se percebesse ou se está coordenando ações onde não deveria.

Essa exposição é qualitativamente diferente do comprometimento tradicional de credenciais. Quando as credenciais de um usuário humano são roubadas, o invasor age dentro das permissões desse usuário, na velocidade humana. Quando a identidade de um agente é comprometida, o invasor obtém acesso à camada de tomada de decisão autônoma — a capacidade de acionar fluxos de trabalho, aprovar ações, coordenar-se com outros agentes e extrair dados na velocidade de uma máquina, em grande escala, por meio de canais que parecem totalmente normais.

Falhas na camada de identidade também estão entre as mais difíceis de detectar após o fato. As ações do agente realizadas sob uma identidade comprometida não parecem anômalas – parecem um comportamento legítimo do agente. E, como são geradas por um sistema em vez de por um ser humano, o volume pode ser enorme antes que alguém perceba.

A Recovery agrava o problema. A maioria dos manuais de Recovery de IA se concentra na restauração de dados: conjuntos de treinamento, pesos de modelos, configurações de pipeline. A identidade raramente está na lista. Um sistema recuperado com dados limpos, mas com configurações de identidade desalinhadas, não está, na verdade, recuperado. É um sistema limpo com uma camada de acesso comprometida. A pergunta a ser feita é: a identidade dos agentes é gerenciada com o mesmo rigor que a identidade humana — com gerenciamento do ciclo de vida, acesso com privilégios mínimos e inclusão nos planos de recuperação?

4. Decisões em cascata baseadas em informações incorretas

Os três primeiros vetores de ataque são pontuais. Este, por sua vez, é sistêmico — e, em muitos aspectos, pode ser o mais difícil de conter. Arquiteturas multiagentes são projetadas para coordenação. Os agentes compartilham contexto, passam resultados uns aos outros e se baseiam no trabalho uns dos outros. Essa coordenação é o que os torna poderosos. É também o que faz com que as falhas se propaguem.

Um agente operando com memória corrompida não falha de forma isolada. Ele produz resultados — decisões, ações, dados — que outros agentes utilizam. Esses agentes, por sua vez, produzem seus próprios resultados. Quando a corrupção original se torna observável, a condição anômala já pode ter afetado dezenas de processos a jusante, envolvendo vários agentes, sem um caminho claro para reversão.

É isso que torna a lacuna de contexto tão significativa. A qualquer momento, seu sistema de IA consiste em uma versão do modelo, um conjunto de dados de treinamento, um repositório de artefatos, uma configuração de pipeline e um conjunto de interações de agentes ativos — todos os quais precisam refletir o mesmo estado operacional para constituir um sistema confiável e recuperável. Quando isso não acontece, você não enfrenta apenas um erro. Cada ferramenta pontual pode confirmar sua própria fatia. Nenhuma delas consegue confirmar se as partes se encaixam. Esse não é um problema de monitoramento que se resolve simplesmente adicionando outra ferramenta. Trata-se de uma lacuna estrutural — e a única maneira de preenchê-la é com um sistema que capture o estado da IA de forma relacional: o que estava em execução, com quais dados, com qual configuração e em que momento.

A pergunta a se fazer é: se sua infraestrutura de IA fosse comprometida hoje, você seria capaz de identificar exatamente em que estado cada componente se encontrava antes do incidente — e comprovar isso?

O que isso significa para sua estratégia de segurança

Cada um desses quatro vetores exige uma resposta defensiva diferente. Mas todos compartilham uma implicação comum: os marcos de governança e resiliência concebidos para a era anterior da IA não abrangem os modos de falha da era dos agentes. Para garantir uma IA agênica, é necessário ampliar sua estrutura em três direções:

  • Mais a fundo, nas camadas de dados e identidade que se encontram abaixo do modelo.
  • Mais abrangente, para cobrir as interações entre agentes que o monitoramento atual não detecta.
  • Do ponto de vista relacional, para capturar não apenas o estado de cada componente, mas também como eles se articulam entre si a qualquer momento.

Esse último requisito é aquele que a maioria das organizações ainda não enfrentou. E é ele que determinará se, quando algo der errado, você terá um sistema recuperável ou um conjunto de relatórios que parecem precisos, mas que descrevem algo que já não existe mais. Leia “O ponto cego agênico: por que a resiliência da IA exige um sistema de registro” para descobrir por que você precisa de um SOR para ajudar a proteger a consistência e a precisão dos seus dados de IA.

Perguntas frequentes

P: Por que os sistemas de IA com capacidade de ação são mais arriscados do que as ferramentas tradicionais de IA generativa?

R: Os sistemas baseados em agentes fazem mais do que apenas responder a comandos. Eles mantêm o estado, coordenam-se com outros agentes e realizam ações em ambientes de produção, o que amplia a superfície de ataque muito além da simples manipulação de comandos.

P: O que torna os dados de treinamento contaminados tão difíceis de detectar?

R: A manipulação pode ser altamente direcionada, afetando apenas situações específicas e deixando os benchmarks normais intactos. Isso significa que um modelo pode parecer estável até que o comportamento malicioso se manifeste no uso real.

P: Como um banco de dados vetorial pode se tornar um problema de segurança?

R: Um banco de dados vetorial define o contexto que um agente utiliza antes de agir. Se esse contexto for alterado, o agente pode tomar decisões que, à primeira vista, pareçam razoáveis, mas que, na verdade, estejam sendo guiadas por dados maliciosos.

P: Por que a identidade do agente é diferente da identidade humana?

R: A identidade do agente está ligada a ações autônomas, delegação e execução na velocidade de uma máquina. A governança de identidade tradicional foi projetada para pessoas; por isso, muitas vezes não percebe se um agente está agindo fora do contexto pretendido.

P: Por que a propagação de estados indesejáveis é um problema tão grave em sistemas multiagentes?

R: Quando um agente processa uma saída corrompida, esse erro pode se espalhar para os agentes e fluxos de trabalho a jusante. O resultado não é apenas uma decisão errada, mas uma cadeia de falhas interligadas.

P: Como as organizações podem melhorar a segurança da IA?

R: Ampliar a governança para as camadas de dados e identidade, monitorar as interações entre agentes e acompanhar o estado da IA de forma relacional, a fim de permitir a reconstrução do que ocorreu durante um incidente.

Michael Thelander é diretor sênior de marketing de produto na Commvault.

Blogs relacionados

More related posts

Thumbnail_Blog-Data-Access-Governance-2026

Securing AI with Unified Data Access Governance

Read more
Thumbnail_Blog-Environmental-Footprint-AI-2026

Smarter Data, Greener AI

Read more
Thumbnail_Blog-Anthropic-Project-ResOps-2026

Anthropic’s Project Glasswing Makes the Case for ResOps

Read more
Thumbnail_Blog-Data-Rooms-2025-Linkedin

Data Activate: Unlocking the Power of Trusted Data for AI Innovation

Read more
Thumbnail_Blog-AI-Agents-2026

AI Agents Are Everywhere. Do You Know What They’re Doing?

Read more
Thumbnail_Blog-Building-AI-Agents-2026

From Experimentation to Operation: Building AI Agents You Can Actually Trust

Read more

Pontos principais

  • Os sistemas de IA agênica são sensíveis ao estado e operam continuamente, o que torna os modelos tradicionais de recuperação insuficientes.
  • A camada de memória (bancos de dados vetoriais e armazenamento de contexto) é uma superfície de ataque crítica, mas pouco monitorada.
  • Os fluxos de trabalho de tomada de decisão em tempo de execução podem ser manipulados sem acionar os alertas de segurança tradicionais.
  • As lacunas de observabilidade nas interações entre agentes fazem com que a maioria das organizações tenha uma visibilidade incompleta dos riscos.
  • A verdadeira recuperação exige um registro unificado e sincronizado de todas as camadas do sistema para restaurar um estado confiável.

A maioria das empresas que está entrando na era da IA autônoma está gerenciando a resiliência com um modelo mental equivocado — e os dados confirmam isso: apenas 1 em cada 5 empresas possui um modelo maduro para governar agentes de IA autônomos. Elas estão encarando a IA da mesma forma que encaram os aplicativos: como entidades discretas, sem estado e recuperáveis por meio da restauração de dados limpos em um ambiente limpo.

A IA agentiva não funciona assim. Esses sistemas têm estado, operam continuamente e são arquitetados em camadas de maneiras que criam modos de falha para os quais a maioria das estruturas de segurança e resiliência não foi projetada para lidar. A lacuna não está nas ferramentas. Está na compreensão do que realmente está em execução – e do que “Recovery” deve significar para sistemas construídos dessa forma.

Existem quatro camadas arquitetônicas que definem o problema. Cada uma é distinta. Cada uma está desprotegida. E, juntas, elas explicam por que um sistema de IA agênica pode parecer recuperável, embora permaneça fundamentalmente comprometido.

Camada 1: Memória do agente – A superfície de ataque que você não está monitorando

Os aplicativos corporativos tradicionais não memorizam nada entre as sessões. A IA Agentic, sim. A camada de memória — composta principalmente por bancos de dados vetoriais que armazenam embeddings, mas também o estado da sessão e o contexto recuperado — é o que proporciona continuidade aos agentes ao longo das interações. É isso que permite que um agente retome de onde parou, recorra ao contexto anterior e construa um panorama coerente de um fluxo de trabalho complexo ao longo do tempo.

É também uma das superfícies de ataque mais significativas na pilha de tecnologias das empresas modernas — e uma das menos monitoradas. O vetor de ataque é sutil o suficiente para escapar da maioria das ferramentas de segurança convencionais. Um adversário capaz de influenciar o que é gravado em um banco de dados vetorial pode moldar o que o agente acredita ser verdade. Embeddings injetados ou manipulados não precisam parecer maliciosos – eles precisam parecer confiáveis.

Um armazenamento de memória comprometido pode redirecionar o comportamento do agente, extrair dados por meio das ações do agente ou fazer com que um agente tome decisões que pareçam legítimas, mas que, na verdade, atendam aos objetivos de um invasor. Nada disso requer a alteração do próprio modelo. O problema de detecção é agravado pelo volume e pela velocidade das gravações no banco de dados vetorial em implantações ativas de agentes. Ferramentas de detecção de anomalias criadas para dados estruturados não se adaptam bem ao espaço de embeddings. O sinal está lá – mas a maioria das organizações não está equipada para interpretá-lo.

O que a resiliência exige aqui: monitoramento contínuo da integridade dos bancos de dados vetoriais, não apenas backup. Incorporações com controle de versão e uma cadeia de custódia comprovável. A capacidade de identificar, a qualquer momento, exatamente o que a camada de memória continha – e restaurar para um estado limpo e verificado, não apenas para um estado recente.

Camada 2: Controle em tempo de execução – Quando o fluxo de trabalho é a ameaça

A IA agentiva não executa scripts fixos. Ela planeja. Durante a execução, um agente recebe uma meta, determina as etapas necessárias para alcançá-la, seleciona as ferramentas de que precisa e executa — muitas vezes gerando subagentes para lidar com fluxos de trabalho paralelos. O fluxo de trabalho é dinâmico, construído no momento e, frequentemente, de longa duração.

É isso que torna a IA com capacidade de ação genuinamente útil. É também o que torna sua proteção genuinamente difícil. Em um ambiente de automação convencional, um fluxo de trabalho limitado cumpre o que foi configurado para fazer e, em seguida, é interrompido. Um fluxo de trabalho agente, por outro lado, é diferente: ele se adapta.

Se um invasor conseguir influenciar a camada de planejamento — por meio de um prompt adulterado, uma resposta manipulada de uma ferramenta ou um modelo de planejamento corrompido —, o agente buscará o objetivo do invasor utilizando todas as ferramentas e acessos legítimos de que dispõe. Isso parecerá uma operação normal. Os registros, na medida em que existirem, mostrarão chamadas autorizadas às ferramentas. Considere um agente de compras encarregado de validar as faturas dos fornecedores em relação aos termos do contrato. Em operação normal, ele verifica os valores das faturas, cruza as informações com os limites de aprovação e sinaliza exceções para revisão humana. Um invasor capaz de influenciar a camada de planejamento — por meio de uma resposta manipulada de uma ferramenta proveniente do banco de dados de contratos — não precisa interferir diretamente na lógica de aprovação. Basta que ele forneça ao agente um registro de contrato com limites alterados. O agente planeja corretamente com base em entradas corrompidas. Cada chamada de ferramenta que ele faz é legítima. Cada decisão a que chega está errada. Quando a anomalia vem à tona em uma reconciliação financeira, o fluxo de trabalho já processou semanas de faturas e a trilha de auditoria não mostra nada além de ações autorizadas.

O intervalo entre o comprometimento e a detecção nesses cenários não é medido em segundos. Os fluxos de trabalho baseados em agentes operam continuamente. Quando os resultados anômalos vêm à tona, o fluxo de trabalho pode já ter afetado dezenas de sistemas, tomado centenas de decisões e deixado alterações em ambientes de produção que são difíceis de enumerar e ainda mais difíceis de reverter.

O que a resiliência exige aqui: monitoramento em tempo de execução que observe o que os agentes estão decidindo, não apenas o que estão fazendo. Mecanismos de intervenção capazes de interromper um fluxo de trabalho em execução de forma limpa, sem falhas em cascata. Manuais de Recovery criados para processos baseados em agentes de longa duração – não apenas para transações discretas.

Camada 3: Observabilidade Agente – A lacuna no registro de logs na velocidade da máquina

A infraestrutura de registro de eventos corporativos foi criada para operações em escala humana. Ela captura o que os sistemas fazem, com um nível de granularidade e latência projetados para a análise humana. A IA baseada em agentes opera a uma velocidade totalmente diferente.

Em uma implantação ativa de múltiplos agentes, os agentes estão gerando subagentes, transmitindo contexto entre si, fazendo chamadas a ferramentas e sintetizando resultados — de forma contínua, em paralelo e mais rapidamente do que os pipelines de registro convencionais foram projetados para capturar. As interações mais importantes para a segurança — comunicações entre agentes, transferências de contexto e chamadas de ferramentas que ultrapassam limites de confiança — são exatamente aquelas que as estruturas de monitoramento existentes deixam menos observadas.

Atualmente, apenas 17% monitoram continuamente as interações entre agentes. Os outros 83% estão gerenciando a IA baseada em agentes com base em uma visão parcial — que captura o que os agentes individuais fazem isoladamente, mas ignora a camada de interação, onde ocorrem os eventos de segurança mais significativos.

Essa lacuna não é resolvida com um maior volume de registros. O problema não é a quantidade de dados capturados — é que as estruturas de dados e os requisitos de latência das interações baseadas em agentes não se encaixam bem nas estruturas de observabilidade projetadas para sistemas mais lentos e estruturados. Para preencher essa lacuna, são necessárias ferramentas de observabilidade específicas para agentes ou uma adaptação significativa da infraestrutura existente.

O que a resiliência exige aqui: visibilidade de ponta a ponta das interações entre agentes, não apenas dos resultados de agentes individuais. Arquiteturas de registro que possam operar na velocidade dos agentes sem perder eventos. A capacidade de reconstruir, a posteriori, a sequência completa das decisões e interações dos agentes para qualquer fluxo de trabalho específico.

Camada 4: Coordenação entre múltiplos agentes – Onde se escondem as falhas emergentes

O risco arquitetonicamente mais inovador na IA agênica não decorre de um único agente comprometido. Ele decorre da forma como os agentes dependem uns dos outros — e de como as falhas se propagam por meio dessas dependências antes que alguém perceba que algo está errado. Em uma arquitetura multiagente, os agentes compartilham o contexto. Um agente orquestrador transmite um resumo da tarefa a um subagente; o subagente retorna um resultado que o orquestrador incorpora à sua próxima decisão.

Se a saída do subagente estiver corrompida — seja por uma camada de memória comprometida, uma resposta manipulada da ferramenta ou um modelo de planejamento adulterado —, o orquestrador não dispõe de nenhum mecanismo nativo para detectá-la. Ele trata a saída como confiável. Ele a incorpora. Ele age com base nela. E repassa sua própria saída, agora comprometida, para as etapas seguintes.

Esse é o modo de falha emergente: uma corrupção que se origina em uma camada, se propaga por meio das interações entre agentes e se manifesta como um resultado anômalo em um sistema a várias etapas de distância do comprometimento original. Quando se torna visível, a cadeia causal já é longa e o alcance do impacto é significativo.

Considere um fluxo de inteligência de ameaças no qual um agente de coleta de dados recebe feeds de fontes externas, um agente de classificação os categoriza e atribui pontuações a eles, e um orquestrador incorpora as informações pontuadas às recomendações sobre a postura de segurança enviadas às equipes a jusante. Se a camada de memória do agente de coleta de dados for comprometida — de forma sutil, por meio de embeddings injetados que o levam a classificar certos agentes maliciosos como de baixo risco —, o agente de classificação recebe informações que não tem motivos para questionar. Ele classifica com precisão com base no que lhe é fornecido.

O orquestrador incorpora os resultados com confiança. As equipes de segurança a jusante deixam de priorizar a categoria de ameaça relevante com base no que parece ser um consenso coerente e proveniente de múltiplas fontes. A falha teve origem na Camada 1. Ela se manifestou na Camada 4. Nada entre elas sinalizou uma anomalia porque nada entre elas tinha visibilidade sobre toda a cadeia.

As estruturas de governança que a maioria das empresas aplica à IA foram projetadas para os resultados dos modelos — o que a IA diz. Falhas na coordenação entre múltiplos agentes não são falhas nos resultados dos modelos. São falhas de sistema, decorrentes da camada de interação entre os modelos, e exigem um tipo diferente de governança: uma que monitore e controle não apenas o comportamento individual dos agentes, mas também as relações de confiança entre eles, a integridade do contexto à medida que este circula entre eles e os direitos de acesso que regem o que qualquer agente pode solicitar a qualquer outro.

O que a resiliência exige aqui: gerenciamento de identidade de agentes que trate a confiança entre agentes como uma preocupação de segurança de primeira ordem. Verificação da integridade do contexto à medida que ele atravessa os limites dos agentes. Políticas de governança que abranjam o comportamento autônomo dos agentes – não apenas os resultados de modelos individuais.

O problema relacional que une os quatro

Essas quatro camadas apresentam modos de falha distintos, mas compartilham uma vulnerabilidade comum: nenhuma delas possui um registro compartilhado de como se relacionam entre si em um determinado momento.

O registro de modelos sabe qual versão está em execução. O banco de dados vetorial sabe o que está na memória. A camada de orquestração sabe qual fluxo de trabalho está ativo. O sistema de identidade sabe quais agentes têm quais acessos. Cada um pode confirmar sua própria fatia do quadro. Nenhum deles pode confirmar se essas fatias se encaixam — se refletem o mesmo estado operacional, o mesmo momento, a mesma configuração confiável.

Essa é a lacuna de contexto. E é por isso que a recuperação após um comprometimento de uma IA agênica não é um problema de restauração de dados. É um problema de coerência — que exige um registro unificado das relações entre as camadas, e não apenas dos próprios componentes. Resolva essa lacuna antes que ocorra um incidente, ou passe o tempo durante o incidente tentando resolvê-la.

Os desafios de arquitetura abordados aqui são apenas uma parte do que os líderes de segurança e resiliência precisam compreender sobre o risco da IA agentiva. O artigo “O ponto cego da IA agentiva: por que a resiliência da IA exige um sistema de registro” vai além, examinando em que ponto a maioria das empresas realmente se encontra em termos de preparação para a resiliência da IA, como se apresentam as lacunas de governança na prática e o que é necessário para tornar a afirmação “nossa IA é confiável” uma alegação comprovável, e não apenas uma simples declaração.

Perguntas frequentes

P: Por que a recuperação de desastres tradicional não funciona para a IA agentiva?

R: A recuperação tradicional pressupõe que os sistemas não mantêm estado e podem ser restaurados a partir de backups limpos. Os sistemas de IA baseados em agentes retêm memória, evoluem ao longo do tempo e dependem de interações em camadas, o que torna a simples restauração insuficiente para recuperar a confiança.

P: O que torna a camada de memória na IA agentiva vulnerável?

R: A camada de memória armazena representações e dados contextuais que influenciam as decisões do agente. Se for comprometida, os invasores podem manipular sutilmente o que o agente “acredita”, levando a ações incorretas, mas aparentemente legítimas.

P: Como os invasores podem explorar os fluxos de trabalho em tempo de execução na IA baseada em agentes?

R: Os invasores podem influenciar os dados de planejamento, as instruções ou as respostas das ferramentas, fazendo com que os agentes executem ações prejudiciais por meio de processos legítimos. Essas ações geralmente parecem normais nos registros, o que dificulta a detecção.

P: Por que a observabilidade é um desafio em sistemas multiagentes?

R: Os sistemas baseados em agentes operam na velocidade da máquina, com interações contínuas entre os agentes. Os sistemas tradicionais de registro não foram projetados para capturar ou processar esse nível de atividade dinâmica e de alta frequência.

P: O que são falhas emergentes em ambientes multiagentes?

R: As falhas emergentes ocorrem quando uma pequena vulnerabilidade em um agente ou camada se propaga por agentes interconectados, resultando em problemas em grande escala cuja origem é difícil de identificar.

P: Como seria uma recuperação eficaz para uma IA autônoma?

R: Uma recuperação eficaz exige mais do que apenas restaurar dados — requer um instantâneo coerente de todas as camadas do sistema, incluindo memória, fluxos de trabalho, identidades e interações, alinhado a um estado verificado e confiável.

Tim Zonca é vice-presidente de gestão de portfólio da Commvault.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

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.

More related posts

Thumbnail_Blog-GoogleWorkspace-2026

Expanding Google Workspace Protection with Commvault eDiscovery

Read more
Thumbnail_Blog-Data-Leakage-Loops-2026

Are You Ready for Data Leakage Loops?

Read more
Thumbnail_Blog-Tornado-2025-Linkedin

The Trust Tightrope: Why New Yorkers Demand More from Businesses Than They Do from Themselves

Read more
Thumbnail_Blog_FinServ-Cybersecurity-2025

Modernizing Financial Cybersecurity: From Reactive to Resilient

Read more

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.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

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.

More related posts

Thumbnail-Digital-Sovereignty-4

Sovereign Data You Can’t Recover Isn’t Actually Sovereign

Read more
Thumbnail-Digital-Sovereignty-2

Minimum Viable Sovereignty: Why the Right Posture Isn’t the Same for Every Organization

Read more
Thumbnail-Digital-Sovereignty-1

You Don’t Have a Sovereignty Strategy. You Have a Residency Policy.

Read more

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.

More related posts

Thumbnail-Digital-Sovereignty-2

Minimum Viable Sovereignty: Why the Right Posture Isn’t the Same for Every Organization

Read more
Thumbnail-Digital-Sovereignty-3

The Pillar Most Sovereignty Strategies Forget

Read more
Thumbnail-Digital-Sovereignty-1

You Don’t Have a Sovereignty Strategy. You Have a Residency Policy.

Read more

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.

More related posts

Thumbnail-Digital-Sovereignty-4

Sovereign Data You Can’t Recover Isn’t Actually Sovereign

Read more
Thumbnail-Digital-Sovereignty-3

The Pillar Most Sovereignty Strategies Forget

Read more
Thumbnail-Digital-Sovereignty-1

You Don’t Have a Sovereignty Strategy. You Have a Residency Policy.

Read more

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.

More related posts

Thumbnail-Digital-Sovereignty-3

The Pillar Most Sovereignty Strategies Forget

Read more
Thumbnail-Digital-Sovereignty-4

Sovereign Data You Can’t Recover Isn’t Actually Sovereign

Read more
Thumbnail-Digital-Sovereignty-2

Minimum Viable Sovereignty: Why the Right Posture Isn’t the Same for Every Organization

Read more

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.

More related posts

Thumbnail_Blog-Identity-Resilience-MachineID-2026-Linkedin

The Machine Identity Blind Spot Is Now a Primary Attack Surface

Read more
Thumbnail_Blog-Help-Desk-2026-Linkedin

When the Help Desk Becomes the Front Door to Your Entire Network

Read more
Thumbnail_Blog-SHIFT-Identity-Resilience-2026-Linkedin

Your Identity Infrastructure Is a Target. Here’s What Commvault Is Doing About It.

Read more
Thumbnail_Blog-Rise-of-AI-Agents-in-Resops-2026

Commvault and Microsoft: The Rise of AI Agents in ResOps

Read more
Thumbnail_Blog_Resilient-Against-the-AI-Machine

Resilient Against the AI Machine

Read more

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.

More related posts

Thumbnail_Blog-Okta-Early-Access-2026

Commvault® Extends Identity Resilience to Okta

Read more
Thumbnail_Blog-Lateral-Access-2026

Staying Resilient Against Lateral Access Exploits

Read more
Thumbnail_3_AD_Blogs_2025

Active Directory Forest Recovery: Why Manual Methods Are No Longer Viable

Read more
Thumbnail_6_AD_Blogs_2025

AD Recovery Testing: How to Know Your Recovery Plan Will Actually Work

Read more

Pontos principais

  • As identidades não humanas (NHIs) já superam em muito o número de usuários humanos e estão crescendo a um ritmo muito mais acelerado, criando uma superfície de ataque significativa e insuficientemente regulamentada.
  • Os invasores recorrem cada vez mais à engenharia social, como o phishing por voz (vishing), para contornar as defesas humanas e obter acesso às credenciais na camada de máquina.
  • A maioria dos NHIs opera com permissões excessivas e carece de um gerenciamento adequado do ciclo de vida, o que contribui para o acúmulo de “dívida de identidade”.
  • As ferramentas tradicionais de segurança não conseguem detectar ameaças na camada de máquina porque os NHIs se comportam de maneira diferente dos usuários humanos.
  • As organizações devem passar de estratégias que priorizam a prevenção para abordagens que priorizam a recuperação, dando prioridade à detecção rápida e à neutralização de ataques baseados em identidade.

Na última década, os investimentos em segurança corporativa seguiram o foco no ser humano. Melhor autenticação. Autenticação multifatorial (MFA) mais robusta. Simulação de phishing. Arquitetura centrada na identidade. Esses investimentos foram a resposta correta ao cenário de ameaças da época. O panorama das ameaças mudou.

Os adversários mais sofisticados de hoje não estão tentando burlar sua MFA. Eles a estão usando como uma porta de entrada. Uma ligação convincente para o suporte técnico de TI, uma redefinição da MFA e uma conta humana comprometida – essa é a porta de entrada. O que eles realmente buscam é o que está por trás disso: a camada extensa e mal regulamentada de NHIs que conecta todos os sistemas em seu ambiente.

A dimensão do problema é impressionante

Contas de serviço, chaves de API, tokens OAuth, agentes de IA – as NHIs agora superam os usuários humanos na proporção de 144 para 1 e estão crescendo de 4 a 10 vezes mais rápido do que as contas humanas. No entanto, menos de 25% das organizações possuem políticas formais que regem sua criação ou desativação. Quase todas elas possuem permissões excessivas – direitos que excedem em muito o que sua função exige.

Esse não é um risco novo que surgiu do nada. Trata-se de uma dívida acumulada em matéria de identidade: anos de provisionamento sem governança, automação sem prestação de contas e cloud sem visibilidade. E os adversários perceberam isso.

O vishing é o ponto de entrada

Grupos como ShinyHunters e Scattered Spider — operando sob o que os pesquisadores chamam de cluster Scattered LAPSUS$ Hunters (SLH) — industrializaram a engenharia social para explorar exatamente essa lacuna. O phishing por voz cresceu 449% em 2025. Não se trata de chamadas oportunistas. São operações coordenadas: roteiros criados especificamente para esse fim, operadores recrutados, incentivos financeiros de até US$ 1.000 por falsificação de identidade bem-sucedida no suporte técnico.

A chamada não é o ataque. A chamada é a redefinição de credenciais que permite ao invasor ultrapassar o perímetro humano. O ataque começa quando ele migra para a camada de máquina — roubando tokens OAuth, criando contas de serviço administrativas e incorporando acesso a credenciais que raramente são monitoradas e quase nunca são renovadas. A conta humana é corrigida. O acesso na camada de máquina persiste. O invasor já seguiu em frente.

Três vulnerabilidades que os controles tradicionais não conseguem detectar

As ferramentas de segurança padrão são projetadas com base no comportamento humano. Elas sinalizam logins anômalos, geolocalização incomum e tráfego de e-mail suspeito. As NHIs operam de maneira diferente, e essa diferença é o ponto cego.

O abuso do OAuth, por exemplo, se parece com tráfego normal de API — mesmo após uma redefinição de senha. Milhares de contas de serviço não documentadas operam em grandes empresas com privilégios administrativos, muitas vezes muito tempo depois que os projetos que as criaram foram encerrados. Chaves de API de longa duração incorporadas em pipelines de DevOps conferem amplo acesso sem contexto de dispositivo e sem alerta de login. O MFA não os protege. A detecção em terminais não os identifica. A filtragem de e-mails não tem efeito sobre eles.

A mudança de paradigma: da abordagem centrada na prevenção para a abordagem centrada na recuperação

A resposta lógica a uma ameaça que muitas vezes escapa à detecção tradicional é deixar de presumir que é possível impedir todas as invasões e começar a planejar uma recuperação rápida diante daquelas que conseguem se concretizar. Isso significa tratar os NHIs como ativos de Nível 0 — com os mesmos controles de governança aplicados aos administradores de domínio ou aos planos cloud gerenciados com identidades humanas. Significa substituir segredos estáticos por tokens de curta duração e rotação automática.

Isso também significa correlacionar sinais entre domínios: uma interação com o suporte técnico seguida por uma redefinição da autenticação multifatorial (MFA) e, em seguida, pela criação de um novo token é um indicador de alto grau de confiança de que houve comprometimento, e detectá-lo precocemente faz a diferença entre a contenção e uma violação prolongada. Significa mapear os NHIs às identidades humanas para fins de responsabilização.

Acima de tudo, isso significa ter a capacidade de detectar escaladas de privilégios não autorizadas e reverter alterações maliciosas de identidade em tempo real — restaurando o ambiente a um estado conhecido e confiável antes que os danos se agravem.

A prevenção continua sendo importante. Mas, dada a lacuna de governança que muitas organizações apresentam, a velocidade de recuperação está se tornando um indicador primordial de resiliência. As organizações devem desenvolver programas de identidade projetados para os ataques que já estão ocorrendo, e não para aqueles que eram comuns há cinco anos. Visite o Readiverse e confira nosso e-book *A Crise de Identidade Não Humana*, que explora todo o escopo da superfície de ataque das máquinas e a estrutura para a resiliência da identidade.

Perguntas frequentes

P1: O que são identidades não humanas (NHIs)?

R: Os NHIs incluem contas de serviço, chaves de API, tokens OAuth e agentes de IA que permitem que sistemas e aplicativos interajam. Ao contrário dos usuários humanos, eles costumam operar automaticamente e em grande escala, o que torna mais difícil monitorá-los e controlá-los.

P2: Por que os NHIs são considerados um risco à segurança?

R: Os NHIs costumam ter permissões excessivas e carecem de governança adequada, o que os torna alvos atraentes para invasores. Como raramente são monitorados ou têm suas credenciais atualizadas, as credenciais comprometidas podem permanecer sem serem detectadas por longos períodos.

P3: Como os invasores exploram os NHIs?

R: Os invasores geralmente obtêm acesso inicial por meio de engenharia social, como o phishing por voz, e depois avançam para a camada de máquina. Eles roubam tokens, criam novas contas de serviço ou incorporam acesso persistente em credenciais que não são monitoradas de perto.

P4: Por que as ferramentas tradicionais de segurança não detectam essas ameaças?

R: A maioria das ferramentas de segurança é projetada para monitorar o comportamento humano, como anomalias no login ou tentativas de phishing. Os NHIs geram tráfego de sistema que parece normal, o que permite que atividades maliciosas se misturem às operações legítimas.

P5: O que se entende por uma abordagem de segurança que prioriza a recuperação?

R: Uma abordagem que prioriza a recuperação concentra-se na detecção rápida de violações e na restauração dos sistemas a um estado confiável, em vez de partir do princípio de que todos os ataques podem ser evitados. Isso inclui identificar alterações não autorizadas e revertê-las em tempo real.

P6: Como as organizações podem melhorar a segurança do NHI?

R: As organizações podem tratar os NHIs como ativos essenciais, implementar políticas rigorosas de governança, substituir credenciais estáticas por tokens de curta duração e correlacionar sinais entre sistemas. O mapeamento dos NHIs aos seus proprietários humanos também melhora a prestação de contas e a supervisão.

Vidya Shankaran é diretora de tecnologia de campo da Commvault.

More related posts

Thumbnail_Blog-SHIFT-Identity-Resilience-2026-Linkedin

Your Identity Infrastructure Is a Target. Here’s What Commvault Is Doing About It.

Read more
Thumbnail_Blog-Rise-of-AI-Agents-in-Resops-2026

Commvault and Microsoft: The Rise of AI Agents in ResOps

Read more
Thumbnail_Blog-Unified-Resilience-2026

Why AI Is Breaking Your Resilience Strategy (And What to Do About It)

Read more
Thumbnail_Blog-SHIFT-Sanjay-2025-Linkedin

Re-envisioning Resilience for the Age of AI

Read more
Thumbnail_Blog_Resilient-Against-the-AI-Machine

Resilient Against the AI Machine

Read more

Atualmente, as organizações estão desenvolvendo aplicativos com mais rapidez, automatizando fluxos de trabalho em grande escala e transformando dados em insights, com o apoio de plataformas como Platform Microsoft Power Platform. O que começou como uma camada de produtividade de baixo código rapidamente se tornou essencial para a missão da empresa, integrada aos processos que sustentam a geração de receita, as operações do dia a dia e a tomada de decisões estratégicas.

No entanto, à medida que aumenta a dependência desses recursos de inteligência de negócios, também aumenta o risco associado. A mesma platform a inovação também pode ampliar o impacto de erros operacionais, configurações incorretas e ações mal-intencionadas. Um fluxo de trabalho mal configurado, um relatório excluído ou um aplicativo com falha podem atrapalhar os processos de negócios, comprometer a tomada de decisões e minar a confiança nos sistemas dos quais a empresa depende. E, quando algo dá errado, a recuperação raramente é simples.

A Commvault está ajudando a superar esses desafios com proteção e recuperação de dados de nível empresarial para Platform Microsoft Power Platform, começando pelo Power BI — permitindo que as organizações mantenham protegidos e rapidamente recuperáveis os insights, fluxos de trabalho e aplicativos que criam. 

Power BI: A lacuna entre o insight e a recuperação

No centro de muitas Platform Power Platform está o Microsoft Power BI, que oferece análises e inteligência de negócios, transformando dados em relatórios, previsões e visibilidade operacional. Quando os recursos do Power BI são perdidos ou comprometidos, as equipes podem perder rapidamente o acesso a informações confiáveis, interrompendo os ciclos de geração de relatórios e atrasando a tomada de decisões empresariais.

Na prática, porém, as estratégias de proteção ficam aquém da importância desses ativos. Muitas organizações dependem de exportações manuais de arquivos ou de recursos nativos limitados que não foram projetados para uma recuperação abrangente. Quando algo dá errado, as equipes muitas vezes são forçadas a reconstruir manualmente, sem a capacidade de restaurar exatamente o que é necessário. Isso torna a recuperação lenta, propensa a erros e difícil de escalar.

Backup & Recovery Cloud da CommvaultBackup & Recovery Platform Microsoft Power Platform

Já disponível para o público em geral, o Commvault Cloud Backup & Recovery Microsoft Power Platform as organizações Platform proteger e recuperar seus ativos essenciais aos negócios, como relatórios, contra exclusão acidental, corrupção e atividades maliciosas.

  • Proteção automatizada e baseada em políticas: aplique backups orientados por políticas em todos os ativos do espaço de trabalho do Power BI, garantindo uma cobertura consistente e escalável sem intervenção manual.
  • Recuperação rápida e detalhada: recupere relatórios e pastas individuais para um momento específico no tempo, evitando reconstruções manuais e ajudando a minimizar o tempo de inatividade e as interrupções.
  • Backups isolados e imutáveis: ajudem a proteger os dados contra ransomware e alterações não autorizadas com backups projetados para impedir modificações ou exclusões não autorizadas.
  • Conformidade simplificada: mantenha a retenção de dados a longo prazo (até 10 anos), registros de auditoria centralizados e relatórios para atender aos requisitos regulatórios e internos.

Platform Unificada Platform Resiliência

O Commvault Cloud uma platform unificada platform proteger cargas de trabalho SaaS, cloud e locais, incluindo Microsoft 365, Dynamics 365, Salesforce, máquinas virtuais, bancos de dados e terminais. Com Platform Microsoft Power Platform , os clientes podem otimizar a proteção, a recuperação e a resiliência para um maior número de cargas de trabalho, ajudando a reduzir a proliferação de ferramentas e a simplificar as operações.

Como começar

O Commvault Cloud Backup and Recovery for Power Platform é fornecido como uma solução SaaS, projetada para implantação rápida e sobrecarga operacional mínima. As organizações podem conectar seu ambiente do Power BI, aplicar proteção baseada em políticas e começar a fazer backup de dados críticos em poucas etapas.

A descoberta automatizada protege novos relatórios e pastas à medida que os ambientes evoluem, enquanto o gerenciamento centralizado oferece um único local para monitorar, gerenciar e recuperar dados em escala.

Próximos passos: expansão na Power Platform

Pretendemos ampliar a proteção e a resiliência em toda Platform Microsoft Power Platform incluir o Power Apps e o Power Automate, estendendo a cobertura aos aplicativos e fluxos de trabalho que impulsionam seus negócios. Os planos, cronogramas e recursos estão sujeitos a alterações e não devem ser considerados como base para a tomada de decisões de compra.

Proteja o que impulsiona o seu negócio

À medida que Platform a dependência da Microsoft Power Platform , cresce também a necessidade de uma proteção resiliente e de nível empresarial. Com Cloud Commvault Cloud, você pode:

  • Proteja ativos críticos contra exclusão, corrupção e ataques
  • Recupere rapidamente exatamente o que você precisa – sem precisar reconstruir tudo
  • Manter a confiança nos dados, nas decisões e na automação
Pronto para tornar seu investimento no Microsoft Power BI mais resiliente?

Saiba mais e veja o Commvault Cloud ação em commvault.platform.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

Pontos principais

  • A migração de máquinas virtuais para o Red Hat OpenShift Virtualization é um processo gradual que exige proteção consistente em ambientes híbridos.
  • Uma platform unificada de proteção de dados nativa do Kubernetes platform reduzir a complexidade e platform eliminar a necessidade de ferramentas ou processos separados.
  • Resiliência confiável — incluindo backups imutáveis e detecção de ameaças — é fundamental durante a migração, quando os riscos são maiores.
  • As opções flexíveis de recuperação permitem que as organizações se adaptem rapidamente caso as etapas da migração falhem ou os prazos sejam alterados.
  • A consolidação da proteção para máquinas virtuais e contêineres ajuda a reduzir a proliferação de ferramentas e a manter uma governança consistente.

Se você é um líder de TI hoje em dia, é provável que sua estratégia de virtualização esteja passando por uma revisão ativa. O aumento dos custos, a incerteza em relação ao licenciamento e a dependência de fornecedores a longo prazo estão levando muitas organizações a reavaliar sua dependência de hipervisores tradicionais. Ao mesmo tempo, o Kubernetes amadureceu e se tornou a base operacional para aplicações modernas.

Essas duas realidades estão convergindo – e, para muitas empresas, o Red Hat OpenShift Virtualization está se tornando a opção preferida para executar máquinas virtuais dentro de um modelo operacional nativo do Kubernetes. Essa transição está se acelerando em todos os setores. À medida que as organizações modernizam sua infraestrutura de acordo com seus próprios critérios, o Red Hat OpenShift Virtualization é cada vez mais visto como uma forma de modernizar a platform a necessidade de refatoração das aplicações. Com esse impulso, surge uma questão fundamental:

Como migrar máquinas virtuais mantendo a proteção, a resiliência e a capacidade de recuperação consistentes ao longo de todo o processo? Para responder a essa pergunta, é preciso analisar como a maioria das migrações corporativas realmente ocorre — e em que pontos a proteção e a resiliência se tornam fundamentais.

A migração é uma jornada, não um evento pontual

Líderes experientes da área de TI sabem que as transições de infraestrutura raramente ocorrem de uma só vez. Para as empresas que optam por migrar de hipervisores como o VMware para o Red Hat OpenShift Virtualization, a transição geralmente ocorre em fases. Durante esse período, as organizações inevitavelmente operam em um ambiente misto:

  • As máquinas virtuais baseadas em VMware continuam a dar suporte às principais operações comerciais.
  • Máquinas virtuais que passaram a ser executadas recentemente no Red Hat OpenShift Virtualization.
  • Aplicativos em contêineres que compartilham os mesmos clusters do Red Hat OpenShift.

Esse período de coexistência traz complexidade e riscos. Os dados estão em constante movimento, os ambientes estão mudando e podem surgir lacunas de proteção se as ferramentas e os processos não evoluírem em paralelo com as cargas de trabalho.

É essencial manter uma proteção confiável

A Commvault oferece, há muito tempo, proteção e recuperação de dados tanto para ambientes VMware quanto para cargas de trabalho do Kubernetes em execução no Red Hat OpenShift. Esse mesmo modelo de proteção nativo do Kubernetes e orientado por políticas agora se estende às máquinas virtuais em execução no Red Hat OpenShift Virtualization. O que realmente chama a atenção dos clientes é a consistência:

  • Uma única platform proteção e recuperação.
  • Operações baseadas em políticas aplicadas de maneira uniforme em todas as cargas de trabalho.
  • Projetado para funcionar com suas ferramentas e processos atuais, à medida que os ambientes evoluem.

As máquinas virtuais em execução no Red Hat OpenShift Virtualization são protegidas por meio dos mesmos fluxos de trabalho e estruturas de governança utilizadas para aplicativos em contêineres. Essa abordagem unificada está sendo adotada por organizações que estão padronizando suas infraestruturas com o Red Hat OpenShift e que buscam uma maneira mais simples e consistente de gerenciar dados em todos os ambientes.

Esse recurso já está disponível. O Commvault Cloud oferece suporte à proteção de ambientes de virtualização do Red Hat OpenShift alinhados com a versão de suporte de longo prazo 11.40 e a versão de inovação 11.42, o que significa que os clientes já podem colocar esses recursos em produção.

Você não deveria precisar gerenciar a proteção de maneira diferente

Depois que as máquinas virtuais forem migradas para o Red Hat OpenShift Virtualization, elas não deverão exigir nenhum tratamento especial do ponto de vista da proteção. O Commvault Cloud e protege máquinas virtuais do Red Hat OpenShift Virtualization, juntamente com aplicativos em contêineres, ajudando a proporcionar às equipes visibilidade centralizada, aplicação consistente de políticas e operações de recuperação simplificadas. As cargas de trabalho virtualizadas e em contêineres são gerenciadas em conjunto – sem criar silos operacionais.

Para organizações que gerenciam portfólios diversificados de aplicativos, essa forma de lidar com as VMs no Kubernetes ajuda a reduzir o atrito operacional, ao mesmo tempo em que mantém controles de nível empresarial.

A resiliência cibernética é fundamental quando a migração aumenta o risco.

Os períodos de migração representam uma janela de oportunidade excepcionalmente vulnerável. As mudanças geram complexidade, e a complexidade aumenta a exposição à perda de dados e ao ransomware. Cloud Commvault Cloud manter a resiliência ao longo dessa fase por meio de:

  • Backups isolados e imutáveis para cargas de trabalho do Red Hat OpenShift Virtualization.
  • Dados de backup que apoiam a detecção de ameaças e a análise forense, ajudando as equipes a validar a prontidão para a recuperação antes de restaurar as cargas de trabalho.
  • Recursos avançados de recuperação projetados para ajudar as organizações a minimizar as interrupções operacionais.

Independentemente de as cargas de trabalho estarem na fase pré-migração, em transição ou já em pleno funcionamento no Red Hat OpenShift Virtualization, o nível de resiliência permanece inalterado.

A flexibilidade na recuperação traz confiança

Toda iniciativa de modernização precisa de margem para ajustes. A Commvault oferece suporte à recuperação no local e fora do local para máquinas virtuais do Red Hat OpenShift Virtualization, incluindo todo o contexto e a configuração da VM. Se uma etapa da migração não ocorrer conforme o planejado — ou se for necessário ajustar os prazos —, as equipes poderão se recuperar rapidamente e seguir em frente sem comprometer a disponibilidade ou a integridade dos dados.

Proteção nativa do Kubernetes além das VMs

Para muitas empresas, a virtualização é apenas uma parte de uma estratégia mais ampla de modernização de aplicativos. Cloud Commvault Cloud oferece proteção centrada em aplicativos e nativa do Kubernetes para cargas de trabalho em contêineres, incluindo volumes persistentes e metadados de aplicativos, em todas as distribuições do Kubernetes certificadas pela CNCF. Isso permite a mobilidade e a recuperação de aplicativos cloud, ao mesmo tempo em que ajuda a manter a consistência operacional entre os ambientes.

Reduzindo a proliferação de ferramentas à medida que a infraestrutura evolui

Platform costumam trazer novas ferramentas, novos processos — e uma nova complexidade. Ao utilizar o Commvault Cloud uma platform unificada de proteção platform :

  • Máquinas virtuais VMware.
  • Máquinas virtuais do Red Hat OpenShift Virtualization.
  • Aplicativos em contêineres.

As organizações podem ajudar a reduzir a proliferação de ferramentas, simplificar a administração e manter uma governança consistente, mesmo à medida que as estratégias de infraestrutura evoluem.

Como tudo se encaixa

Durante qualquer migração, é importante entender como os diferentes componentes funcionam em conjunto. O Migration Toolkit for Virtualization da Red Hat se encarrega de migrar máquinas virtuais do VMware para o Red Hat OpenShift Virtualization. O Commvault Cloud oferecer a proteção e a resiliência que acompanham suas cargas de trabalho durante todo o processo, para que os dados permaneçam protegidos antes, durante e após a migração. Isso pode ajudar a evitar que a capacidade de recuperação fique para trás à medida que as cargas de trabalho são transferidas.

Dando continuidade à conversa no Red Hat Summit

Já estamos trabalhando com clientes que estão migrando ativamente máquinas virtuais para o OpenShift Virtualization – e continuaremos essas discussões no Red Hat Summit, de 11 a 14 de maio, em Atlanta. No estande da Commvault, estaremos:

  • Conversando com líderes de TI sobre os desafios reais da resiliência.
  • Compartilhando orientações práticas para realizar a migração com confiança.
  • Demonstração Cloud do Commvault Cloud para a virtualização do Red Hat OpenShift.

Se manter a resiliência e a capacidade de recuperação em toda a sua estratégia de virtualização é uma prioridade, adoraríamos ter a oportunidade de entrar em contato com você.

Seguindo em frente com confiança

O Red Hat OpenShift Virtualization está se tornando um componente fundamental da infraestrutura empresarial moderna. Mas não se pode apressar a migração a qualquer custo; é preciso incorporar proteção, resiliência e recuperação ao processo desde o início.

Com o Commvault Cloud, proteger as cargas de trabalho do Red Hat OpenShift Virtualization não é uma meta futura. É algo que os clientes já estão fazendo — utilizando uma platform unificada platform se modernizarem com confiança, mantendo a resiliência e a capacidade de recuperação.

“O Red Hat OpenShift Virtualization oferece uma base confiável e consistente para que as organizações possam dar suporte a todo o seu ambiente virtualizado”, afirma Steve Gordon, diretor sênior de Gestão de Produtos, Cloud Híbrida, da Red Hat. “Ao aproveitar uma integração otimizada como a do Commvault Cloud o Red Hat OpenShift Virtualization, nossos clientes podem seguir em frente com maior confiança, sabendo que suas cargas de trabalho estão protegidas de forma consistente antes, durante e após a migração.”

Perguntas frequentes

P: Por que a migração de máquinas virtuais é considerada um processo em várias fases?

R: A maioria das empresas não consegue migrar todas as cargas de trabalho de uma só vez; por isso, operam em um ambiente híbrido, com ambientes legados e novos em execução simultânea. Essa abordagem em fases traz complexidade, tornando essenciais a proteção e a visibilidade consistentes ao longo de toda a transição.

P: Qual é o papel da resiliência durante a migração de máquinas virtuais?

R: A resiliência permite que as organizações mantenham a proteção dos dados, se recuperem rapidamente de falhas e se defendam contra ameaças como o ransomware. Durante a migração, quando os sistemas estão em transição, medidas robustas de resiliência podem ajudar a evitar a perda de dados e interrupções operacionais.

P: Como o Commvault Cloud a proteção em diferentes ambientes?

R: O Commvault Cloud uma platform única platform proteção baseada em políticas para máquinas virtuais VMware, máquinas virtuais do OpenShift Virtualization e aplicativos em contêineres. Essa abordagem unificada permite operações consistentes sem a necessidade de introduzir novas ferramentas ou fluxos de trabalho.

P: Por que a proteção nativa do Kubernetes é importante?

R: A proteção nativa do Kubernetes se alinha à forma como as aplicações modernas são implantadas e gerenciadas, abrangendo tanto contêineres quanto máquinas virtuais. Ela permite o gerenciamento simples de dados, a mobilidade e a recuperação em ambientes cloud.

P: De que forma a flexibilidade na recuperação aumenta a confiança na migração?

R: Opções flexíveis de recuperação, como restaurações no local e fora do local, podem ajudar as equipes a recuperar rapidamente as cargas de trabalho caso ocorra algum problema. Essa adaptabilidade ajuda a reduzir o tempo de inatividade e permite que as organizações ajustem seus planos de migração sem comprometer a integridade dos dados.

P: Como as organizações podem reduzir a complexidade durante as transições de infraestrutura?

R: Ao adotar uma platform unificada de proteção de dados, as organizações podem gerenciar todas as cargas de trabalho — virtualizadas e em contêineres — por meio de uma única interface. Essa abordagem ajuda a reduzir a proliferação de ferramentas, simplificar a administração e manter uma governança consistente em ambientes em constante evolução.

Jason Giza é gerente sênior de Marketing de Parcerias de Conteúdo Global na Commvault.

More related posts

Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more
Thumbnail_Blog_Agentic-Ransomware-Attack

Cyber Resiliency for AI and Ransomware Recovery

Read more

Pontos principais

  • A Readiverse Academy lançou um caminho de certificação estruturado e em níveis, que vai desde conhecimentos básicos até especialização avançada cloud .
  • As certificações estão alinhadas às funções profissionais reais, ajudando os alunos a desenvolver habilidades relevantes para suas responsabilidades em Cloud Commvault Cloud .
  • O programa inclui quatro níveis — Praticante, Especialista, Profissional e Perito —, cada um com maior profundidade e capacidade operacional.
  • A aprendizagem se baseia em três pilares fundamentais: platform , resiliência cibernética e conhecimento especializado em cargas de trabalho.
  • Opções flexíveis de aprendizagem, incluindo formatos individualizados e ministrados por instrutor, permitem que os profissionais avancem de acordo com seus horários e objetivos.

Os ambientes que você protege com o Commvault Cloud cada vez mais complexos, e as expectativas em relação às equipes que os administram estão mais altas do que nunca. Não se trata mais apenas de conhecer a platform. Trata-se de ser capaz de operar, proteger e recuperar, muitas vezes sob pressão.

Se você já começou sua jornada de aprendizado na Readiverse Academy, seja bem-vindo de volta. E se você é novo por aqui, está chegando na hora certa. Hoje, estamos lançando uma abordagem de certificação estruturada e em níveis que oferece aos alunos um caminho claro e baseado em competências, desde platform básico platform até a especialização avançada cloud .

Criamos conteúdo para você

Cloud da Commvault Cloud exigem conhecimento especializado em diversas áreas de responsabilidade, muitas vezes dentro da mesma função. Administradores, especialistas em segurança, cloud e responsáveis por cargas de trabalho precisam de conhecimentos com diferentes níveis de profundidade e abrangência. E nem todos precisam aprender as mesmas coisas, na mesma ordem, para serem eficazes.

Os novos níveis de certificação da Readiverse Academy refletem essa realidade. Os alunos avançam por níveis claramente definidos que se complementam, de modo que sua certificação se alinhe ao que você realmente faz e valide essas competências perante as equipes com as quais você trabalha.

  • Commvault Cloud – conhecimentos básicos sobre platform resiliência.
  • Cloud da Commvault – maior profundidade operacional e de segurança.
  • Commvault Cloud – especialização avançada em recuperação e cargas de trabalho.
  • Cloud da Commvault – liderança completa cloud e resiliência.

Cada nível é conquistado por meio de uma combinação de trabalhos acadêmicos, atividades práticas em laboratório e avaliações validadas. À medida que os alunos avançam, o escopo e a profundidade da capacidade operacional demonstrada aumentam proporcionalmente.

Um caminho claro: de iniciante a especialista

O programa de certificação está estruturado em torno de três pilares de competências essenciais que permeiam todos os níveis:

  • platform básicas platform
  • Conceitos de resiliência cibernética
  • Carga de trabalho e especialização em funcionalidades

Cada nível acrescenta requisitos específicos relacionados a esses pilares. Os alunos podem concluir cursos individuais ou combinar requisitos específicos para atingir as metas de certificação.

Já faz parte da Readiverse Academy? O que isso significa para você.

Com uma nova estrutura como essa, a pergunta mais importante é o que isso significa para o progresso que você já alcançou. Se você já concluiu cursos ou obteve certificações na Readiverse Academy, parabéns! Seu investimento é importante, e queremos deixar claro o que acontecerá a seguir.

Essas certificações representam sua trajetória e suas conquistas na Commvault. O novo programa está alinhado ao nosso portfólio ampliado de recursos de resiliência cibernética para o Commvault Software, SaaS Commvault SaaS e ambientes híbridos. À medida que suas necessidades crescerem e exigirem mais da Commvault, esses cursos e certificações ajudarão você a configurar, gerenciar e otimizar a Commvault para atender às necessidades específicas da sua organização.

Não há uma progressão direta das trilhas de certificação anteriores para o novo programa, mas suas certificações existentes validam sua expertise nas versões anteriores do produto. À medida que essas versões forem descontinuadas, essas certificações também chegarão ao fim de sua validade. Os alunos que já investiram na Readiverse Academy estão bem posicionados para progredir rapidamente.

Quem deve fazer os cursos e as certificações da Readiverse Academy

As certificações da Readiverse Academy são destinadas a profissionais que atuam em ambientes Commvault SaaS, Commvault Software e ambientes híbridos.

  • Platform responsáveis pela gestão das operações do dia a dia.
  • Especialistas em segurança dedicados à proteção de dados e ao fortalecimento de ambientes.
  • Cloud responsáveis pela configuração do plano de controle e pela resiliência avançada.
  • Responsáveis por cargas de trabalho que precisam de proficiência em domínios específicos de dados.

Todos os treinamentos estão disponíveis para aprendizagem no próprio ritmo, com alguns cursos também oferecidos em formatos ministrados por instrutor, para que os alunos possam progredir da maneira que melhor se adapte à sua função e à sua agenda.

Como começar ou dar continuidade à sua jornada de aprendizado

Quer você esteja começando do zero ou dando continuidade à sua jornada, o próximo passo é simples e foi pensado para se adequar à sua situação atual.

  • Faça login ou cadastre-se no site commvault.com.
  • É novo na Commvault? Comece com o curso “Commvault Cloud ”.
  • Responsável pelo apoio à gestão da carga de trabalho? Confira nosso catálogo de cursos, que abrange praticamente tudo.
  • Procurando estratégias para apoiar a recuperação após um ataque cibernético? O curso sobre Resiliência Cibernética é o seu primeiro passo.

O que vem a seguir

Nosso objetivo é tornar a progressão previsível, transparente e alinhada às funções do mundo real, para ajudar os alunos a saber o que vem a seguir e como se preparar para isso. Estamos comprometidos em proporcionar a todos Cloud do Commvault Cloud o conhecimento necessário para operar, proteger e recuperar seu ambiente com confiança. Pois, quando mais importa, a certificação não se resume a credenciais. Trata-se de ser resiliente e estar pronto para a recuperação.

Perguntas frequentes

P: Qual é o objetivo do programa de certificação da Readiverse Academy?

R: O programa oferece um percurso de aprendizagem estruturado e baseado em competências que ajuda os profissionais a evoluir do platform básico platform até a especialização avançada cloud . Ele alinha o treinamento às responsabilidades do mundo real para permitir que os alunos apliquem seus conhecimentos de forma eficaz em ambientes complexos.

P: Quais são os diferentes níveis de certificação disponíveis?

R: Existem quatro níveis: Commvault Cloud , Specialist, Professional e Expert. Cada nível se baseia no anterior, aumentando em profundidade técnica, escopo operacional e capacidade de liderança.

P: Quem deve se inscrever nos cursos da Readiverse Academy?

R: Os cursos foram desenvolvidos para platform , especialistas em segurança, cloud e responsáveis por cargas de trabalho que atuam em ambientes SaaS, de software e híbridos. Cada função pode seguir um plano de aprendizagem personalizado, de acordo com suas responsabilidades.

P: Como se obtêm as certificações?

R: As certificações são obtidas por meio de uma combinação de cursos, laboratórios práticos e avaliações validadas. À medida que os alunos avançam, eles demonstram níveis crescentes de especialização nas áreas de platform, segurança e cargas de trabalho.

P: O que acontece com as certificações existentes da Readiverse Academy?

R: As certificações existentes continuam válidas como comprovação de experiência anterior, mas estão vinculadas a versões anteriores do produto. À medida que essas versões forem descontinuadas, as certificações chegarão ao fim de sua validade, incentivando os alunos a fazer a transição para o novo programa.

P: Como alguém pode começar a usar o novo programa?

R: Os novos alunos podem começar pelo curso “Cloud Commvault Cloud ”, enquanto os usuários já cadastrados podem fazer login para dar continuidade ao seu progresso. Há cursos adicionais disponíveis de acordo com objetivos específicos, como gerenciamento de cargas de trabalho ou estratégias de resiliência cibernética.

Suzanne Klausner é diretora de Estratégia de Capacitação do Cliente na Commvault.

More related posts

Thumbnail_Blog-Ready-or-Not-2026

Why Every CIO Needs a ‘Ready. Or Not.’ Mindset

Read more
Thumbnail_Blog_Readiness-Update-2024

Boost Your Cyber Resilience and Readiness

Read more
Social_Readiverse_Blog_LinkedIn-1

The Readiverse: Your Go-To Learning Resource for Cyber Resilience and Readiness

Read more

Pontos principais

  • Os fluxos de trabalho tradicionais de restauração podem causar desvios na infraestrutura em ambientes gerenciados pelo Terraform, ao provisionarem novos recursos fora do estado.
  • O Clumio Backtrack foi projetado para restaurar dados diretamente em buckets S3 e tabelas DynamoDB existentes, ajudando a preservar a identidade dos recursos.
  • A recuperação no local ajuda a reduzir a necessidade de importações manuais do Terraform, reconfiguração de endpoints e reconciliação de estado durante incidentes.
  • Alinhar os fluxos de trabalho de recuperação aos princípios da Infraestrutura como Código (IaC) ajuda a manter a integridade da configuração e a previsibilidade operacional.
  • O planejamento da recuperação é tão importante quanto o planejamento do backup para equipes que operam ambientes de produção por meio do Terraform.

A IaC proporciona consistência, repetibilidade e controle de versão aos cloud . O Terraform se torna a fonte de referência para o que existe, como está configurado e como deve se comportar. A recuperação apresenta um novo desafio.

As operações tradicionais de restauração costumam criar novos recursos — novos buckets do S3, novas tabelas do DynamoDB, novos endpoints. Do ponto de vista do Terraform, esses recursos não foram definidos no código. Eles não existem no estado. Isso gera desvio. Em operações de rotina, o desvio é gerenciável. Durante um incidente, ele se agrava. É aí que o projeto de recuperação é tão importante quanto o projeto de backup.

O problema do desvio na IaC

Em um modelo típico de restauração:

  • Um recurso protegido é restaurado como um novo recurso.
  • O recurso original permanece corrompido, sobrescrito ou com falha.
  • O estado do Terraform não reconhece o novo recurso.
  • As equipes devem importar manualmente os recursos para o estado.
  • Pode ser necessário atualizar as configurações dos aplicativos.

Para platform que gerenciam a infraestrutura de produção por meio do Terraform, isso gera atritos exatamente no momento menos oportuno. O desafio não é a confiabilidade do backup em si, mas sim como os fluxos de trabalho de restauração se integram às práticas de infraestrutura como código.

Apresentando a Recuperação no Local com o Clumio Backtrack

O Clumio Backtrack é um recurso de recuperação que ajuda a restaurar dados diretamente em recursos existentes da AWS, em vez de provisionar uma infraestrutura substituta. Quando configurado por meio do provedor Clumio Terraform, o Backtrack ajuda a habilitar fluxos de trabalho de recuperação que se alinham à infraestrutura definida em código.

O Clumio Backtrack é compatível tanto com o Amazon S3 quanto com o Amazon DynamoDB. Para uma análise técnica mais aprofundada dos fluxos de trabalho de recuperação específicos do DynamoDB, consulte nossa postagem no blog sobre o Clumio Backtrack para DynamoDB.

Em vez de provisionar recursos substitutos, o Backtrack ajuda a restaurar:

  • Objetos do S3 diretamente no bucket original.
  • Dados do DynamoDB diretamente na tabela original.

Do ponto de vista do Terraform, a infraestrutura deve permanecer inalterada, com os recursos definidos continuando a corresponder à configuração declarada. Isso ajuda a reduzir a necessidade de importações manuais de recursos, tabelas de restauração temporárias, reconfiguração de endpoints e reconciliação de estado em situações de pressão.

Um exemplo prático

Considere um ambiente de produção gerenciado inteiramente por meio do Terraform. Uma tabela do DynamoDB controla o estoque; um bucket do S3 armazena os ativos do aplicativo; as funções e políticas de gerenciamento de identidade e acesso são codificadas; e as políticas de proteção são definidas por meio do Terraform. Se ocorrer corrupção antes de um grande pico de tráfego, as abordagens tradicionais de restauração podem criar novos recursos que precisarão ser reintegrados ao Terraform.

Com o Backtrack, a recuperação foi projetada para ocorrer dentro dos limites dos recursos existentes, ajudando a manter a infraestrutura definida intacta e preservando a identidade dos recursos. Essa abordagem tem como objetivo eliminar a necessidade de atualizar o Terraform para acomodar um bucket ou uma tabela recém-criados, tratando a recuperação como uma operação na camada de dados, em vez de um exercício de substituição da infraestrutura.

Por que isso é importante para Platform

Para equipes comprometidas com a IaC, os fluxos de trabalho de recuperação devem preservar a identidade dos recursos, o alinhamento de estado, a integridade da configuração e a previsibilidade operacional. A restauração no local contribui para esses objetivos, limitando as alterações na infraestrutura durante eventos de recuperação.

Recuperação em Cloud

O Backtrack foi projetado para operar em cloud — seja na restauração de um pequeno número de objetos ou de grandes conjuntos de dados. O desempenho da recuperação varia de acordo com o tamanho da carga de trabalho e a configuração do ambiente, mas o objetivo arquitetônico permanece o mesmo: restaurar dados sem introduzir novos desvios na infraestrutura. Para ambientes gerenciados pelo Terraform, essa distinção é importante.

Onde essa abordagem se encaixa

A recuperação no local é particularmente relevante para:

  • Cargas de trabalho de alto rendimento no DynamoDB
  • Buckets do S3 com grande número de objetos
  • Sistemas de produção gerenciados inteiramente por meio do Terraform
  • Ambientes complexos, nos quais é difícil redirecionar as dependências das aplicações para novos recursos

Quando a infraestrutura é definida de forma declarativa, os fluxos de trabalho de recuperação devem seguir essa mesma abordagem.

Primeiros passos

Para explorar o Clumio Backtrack e sua integração com o Terraform:

Definir a proteção como código é apenas parte da história. A concepção de fluxos de trabalho de recuperação que preservem a integridade da infraestrutura completa o modelo.

Perguntas frequentes

P: Que problema as restaurações tradicionais causam em ambientes gerenciados pelo Terraform?

R: As restaurações tradicionais costumam criar novos recursos, como buckets S3 de substituição ou tabelas do DynamoDB, que não estão definidos no estado do Terraform. Isso pode levar a desvios na infraestrutura e obrigar as equipes a importar recursos manualmente e reconciliar configurações durante incidentes de alta pressão.

P: Em que o Clumio Backtrack difere das abordagens padrão de restauração?

R: Em vez de provisionar uma nova infraestrutura, o Clumio Backtrack foi projetado para restaurar dados diretamente no recurso existente da AWS. Essa abordagem ajuda a preservar a identidade do recurso e a manter o estado do Terraform alinhado com a configuração declarada.

P: Quais serviços da AWS são compatíveis com o Clumio Backtrack?

R: O Clumio Backtrack é compatível com o Amazon S3 e o Amazon DynamoDB. Ele foi projetado para restaurar objetos do S3 no bucket original e dados do DynamoDB na tabela original, ajudando a manter a consistência com a infraestrutura definida em código.

P: Por que a recuperação no local é importante para platform ?

R: Platform contam com a infraestrutura como código para garantir consistência e controle. A recuperação no local ajuda a manter o alinhamento do estado, a integridade da configuração e a previsibilidade operacional, sem introduzir alterações adicionais na infraestrutura durante eventos de recuperação.

P: Em que situações a recuperação no local é particularmente útil?

R: É especialmente útil para cargas de trabalho de alto rendimento no DynamoDB, buckets do S3 com grande número de objetos e sistemas de produção totalmente gerenciados por meio do Terraform. Também pode ser vantajoso em ambientes em que redirecionar as dependências de aplicativos para recursos recém-criados seria complexo ou arriscado.

P: Como as equipes podem começar a utilizar a integração entre o Clumio Backtrack e o Terraform?

R: As equipes podem consultar a documentação do provedor Clumio Terraform, explorar o código-fonte do provedor no GitHub e assistir ao vídeo de demonstração do Backtrack mencionado no blog para entender os detalhes da implementação e do fluxo de trabalho.

Lawrence Chang é diretor de engenharia da Clumio e Vir Choksi é gerente sênior de marketing de produto na Commvault.

More related posts

Thumbnail_Blog-AWS-Data-Protection-Terraform-Clumio-2026

Automating AWS Data Protection with Terraform and Clumio

Read more
Thumbnail_Blog_Clumio-Tech-2025

Restore only what matters: Clumio Backtrack for DynamoDB

Read more
Thumbnail_Blog-GoogleWorkspace-2026

How the Move to Clumio Delivered 66.7% Savings on AWS Backups

Read more
Thumbnail_Blog_AWS-Marketplace-AI

Commvault Featured in New AI Agent Solutions in AWS Marketplace

Read more
Man-and-woman-working-on-laptops-profile-Crocus-Thumbnail

Protecting Your Amazon S3 Data with Clumio: A Comprehensive Solution

Read more

Clumio

Read more

Pontos principais

  • A maioria dos exercícios simulados serve para avaliar o desempenho, em vez de revelar lacunas reais na resposta a incidentes.
  • Para que os exercícios sejam eficazes, eles devem introduzir atrito, ambiguidade e pressão, a fim de refletir situações reais.
  • Limitar o escopo do exercício a alguns cenários críticos e definir o sucesso como a identificação de problemas, em vez de apenas causar boa impressão, pode levar a insights mais significativos e práticos.
  • A participação de diversas áreas, e não apenas das equipes técnicas, é essencial para avaliar com precisão a resposta da organização.
  • A verdadeira resiliência é comprovada por meio de testes reais de recuperação, e não apenas por cenários baseados em discussões.

Há um momento que a maioria dos líderes de segurança reconhece, mesmo que não o digam em voz alta. O exercício simulado acabou de terminar. A equipe está saindo. Todos parecem razoavelmente satisfeitos. E, em algum lugar no fundo da sua mente, surge uma pergunta silenciosa: será que realmente aprendemos alguma coisa?

Se você for honesto, a resposta geralmente é não.

Isso não significa que os exercícios de simulação sejam uma má ideia. Eles são uma das ferramentas mais valiosas que um líder de segurança possui. O problema é a forma como a maioria das organizações os conduz — e o que elas estão realmente medindo ao fazê-lo.

A Armadilha do Desempenho

O erro mais comum nos exercícios simulados não tem nada a ver com o cenário. Tem a ver com o objetivo. A maioria das equipes, conscientemente ou não, cria exercícios destinados a demonstrar competência, em vez de identificar lacunas.

O cenário geralmente segue um arco bem definido. As informações chegam em uma sequência lógica. As pessoas certas dizem as coisas certas. Todos se sentem preparados. E essa sensação – de confiança, de estar bem ensaiado, quase de camaradagem – é exatamente o problema. Incidentes reais não seguem um curso linear. Eles surgem com informações incompletas, sinais conflitantes, pessoas indisponíveis e uma empresa que exige respostas mais rápidas do que os fatos permitem. Se o seu exercício de simulação não recriar esse tipo de atrito, você não testou a resposta a incidentes. Você apenas ensaiou uma conversa.

Quando o exercício é projetado para validar, em vez de testar sob estresse, surge um segundo problema: as pessoas deixam de ser honestas. Ninguém diz: “Não sei de quem é essa decisão” ou “na verdade, nunca testamos esse caminho de Recovery”. Elas dizem o que soa certo. E as lacunas que deveriam vir à tona em um ambiente controlado permanecem ocultas até que apareçam em um ambiente real.

O que um bom exercício realmente avalia

Antes de criar um cenário, você precisa responder a uma pergunta mais simples: o que você realmente quer aprender? Não são 20 coisas. São três ou quatro.

Sua equipe consegue tomar uma decisão de desligamento com rapidez suficiente, e todos sabem quem tem autoridade para tomá-la? Quando os setores de segurança, TI, jurídico e de comunicações estão todos na sala com prioridades conflitantes, eles conseguem realmente chegar a decisões em conjunto? Você consegue explicar o impacto nos negócios de um incidente com clareza suficiente para que a liderança aja – e não apenas compreenda? E se você tivesse que restaurar um sistema crítico nas próximas quatro horas, conseguiria realmente fazer isso?

Depois de saber o que você está testando, crie um cenário com atritos reais. Faça com que uma pessoa-chave fique indisponível no meio do exercício. Introduza uma escalada de um cliente. Faça com que um órgão regulador faça uma pergunta que a equipe não consiga responder com base no manual de procedimentos.

Dê às pessoas informações incompletas e veja como elas tomam decisões mesmo assim. O valor não está em observar as pessoas terem sucesso sob pressão. Está em identificar os pontos em que o processo falha, enquanto os riscos ainda são baixos o suficiente para corrigi-los.

Diga isso em voz alta logo no início: hoje em dia, sucesso significa identificar problemas, e não causar boa impressão. Essa única frase muda o que as pessoas estão dispostas a dizer na sala.

O Problema das Pessoas

Uma simulação que envolva apenas segurança e TI é uma discussão técnica, não um exercício de resposta a incidentes. Se o departamento jurídico não estiver presente, se o departamento de comunicação não estiver presente, se os responsáveis pelas áreas de negócios e a alta liderança estiverem ausentes, você não estará testando como sua organização realmente responde a uma crise. Você estará testando como um grupo de pessoas inteligentes discute uma situação hipotética. Incidentes reais são tratados em toda a empresa. O exercício deve refletir isso.

Conversar sobre o assunto não é suficiente

É nesse ponto que a maioria das organizações fica para trás. Um exercício teórico é importante — mas não significa confiança. Discutir um cenário de Recovery nos dá algumas informações. Restaurar um sistema de fato nos revela algo diferente. Você consegue restaurar a identidade para um ponto específico no tempo? Você consegue validar que o que está sendo recuperado é confiável? Você consegue restaurar um aplicativo de Nível 1 e confirmar que ele volta a funcionar corretamente, sem carregar a infecção consigo?

Essas não são perguntas que se possa responder em uma sala de reuniões. Em algum momento, o plano precisa se adequar ao ambiente — e é preciso saber se eles são compatíveis.

Após o término do exercício

A análise pós-exercício indica se o exercício foi relevante. Se a avaliação imediata for silenciosa, vaga ou repleta de “bons lembretes”, o exercício não foi desafiador o suficiente. Um exercício de simulação bem conduzido deve deixar você com uma lista curta de conclusões reais, responsáveis claros e prazos definidos. Se você não conseguir responder o que deu errado, quem está corrigindo e até quando, você realizou um evento, não um exercício.

O objetivo nunca foi ser aprovado no exercício. Era aprender algo importante enquanto o custo de errar ainda fosse apenas tempo. Assista ao nosso episódio mais recente do podcast STRIVE, no qual converso com meu colega Chris Mierzwa, diretor sênior de Marketing de Portfólio, sobre exercícios simulados.

Perguntas frequentes

P: Por que a maioria dos exercícios simulados não consegue agregar valor real?

R: Muitos exercícios são elaborados para que as equipes pareçam preparadas, em vez de revelar pontos fracos. Isso leva a discussões ensaiadas, que não refletem a imprevisibilidade e a pressão de incidentes reais.

P: Qual deve ser o objetivo de um exercício de simulação?

R: Deve se concentrar em responder a um pequeno número de questões essenciais, como velocidade na tomada de decisões, clareza quanto à responsabilidade e capacidade de recuperação. Esse foco ajuda as equipes a identificar lacunas significativas, em vez de apenas observações superficiais.

P: Como as organizações podem tornar os exercícios mais realistas?

R: Introduza incertezas, informações ausentes e interrupções inesperadas durante o cenário. Esses elementos obrigam as equipes a pensar criticamente e agir sob pressão, em condições mais próximas às de um incidente real.

P: Quem deve participar de um exercício simulado?

R: Além das equipes de segurança e TI, equipes como as de assuntos jurídicos e de comunicação, líderes de negócios e executivos devem participar. Isso permite que o exercício reflita a forma como incidentes reais são gerenciados em toda a organização.

P: Por que falar sobre a recuperação não é suficiente?

R: As discussões podem destacar os planos, mas somente testes reais comprovam se os sistemas podem, de fato, ser restaurados de forma limpa e rápida. A validação prática é necessária para confirmar a prontidão para a recuperação.

P: O que define um resultado bem-sucedido em um exercício de simulação?

R: Um exercício bem conduzido resulta em conclusões claras, responsáveis designados e prazos definidos para a correção. Se esses elementos estiverem ausentes, é provável que o exercício não tenha desafiado a equipe o suficiente.

Chris Bevil é diretor da área de Resiliência Cibernética Global e IA na Commvault.

More related posts

Thumbnail_Blog-Commvault-Enhancements-Cyber-Recovery-2026

Commvault Enhancements in Cyber Recovery

Read more
Readiverse-Featured-Image-888-x-500

Ready Is Good. Resilient Is Better.

Read more
Thumbnail_5_MV_Blogs_2025

Recovery Testing: The Missing Piece in Most Cyber Resilience Programs

Read more
Urgent-Need-for-Cyber-Resilience

The Urgent Need for Cyber Resilience

Read more
Thumbnail_Blog_Modern-Playbook-2025

Your Modern Playbook for Rapid Response and Clean Recovery

Read more

Pontos principais

  • A governança de acesso a dados da Commvault, com tecnologia da Satori, unifica a visibilidade, o controle de acesso e a rastreabilidade em dados estruturados, arquivos não estruturados, SaaS e cargas de trabalho de IA.
  • Uma política de acesso única e consistente pode reger tanto usuários humanos quanto modelos de IA, ajudando a reduzir os silos e a limitar a exposição excessiva de dados confidenciais.
  • A descoberta, a classificação e a avaliação de risco contínuas ajudam a fornecer uma visão priorizada sobre onde os dados confidenciais estão armazenados e onde o risco de exposição é maior.
  • O mascaramento e a supressão dinâmicos, orientados por políticas, ajudam a garantir o acesso com o mínimo de privilégios, permitindo o uso autorizado dos dados e, ao mesmo tempo, contribuindo para a proteção de campos confidenciais.
  • Registros de auditoria centralizados e quase em tempo real oferecem visibilidade abrangente das consultas dos usuários, das solicitações de IA e dos eventos de acesso regulamentado, a fim de apoiar a conformidade e a prestação de contas.

Com a IA agora integrada a todos os fluxos de trabalho — desde copilotos e assistentes de chat até ferramentas de análise —, todos esses terminais passaram a ter uma enorme demanda por dados a serem processados. Os recursos de governança de acesso a dados da Commvault, desenvolvidos pela Satori, foram projetados para atender a essa demanda da IA, unificando a visibilidade, o controle de acesso e a auditabilidade em todo o seu ambiente de dados.

Uma base unificada para a governança de dados na era da IA

Os recursos de governança de acesso a dados da Commvault reúnem bancos de dados estruturados, arquivos não estruturados em SaaS e cargas de trabalho de IA sob um único modelo de governança, em vez de tratá-los como silos separados. Agora, as organizações podem aplicar uma única política de acesso tanto a usuários humanos quanto a modelos de IA, de modo que as mesmas regras determinem quem ou o que pode acessar informações confidenciais, independentemente de onde elas estejam armazenadas.

Ao integrar o Satori ao Commvault Command Center, esses recursos ampliam a proteção tradicional da Commvault para incluir dados em tempo real e o uso de IA, e não apenas backups e snapshots. Isso ajuda as equipes de segurança e proteção de dados a passar de uma resposta reativa a incidentes para um controle proativo sobre como os dados são identificados, acessados e utilizados em tempo real.

Descoberta, classificação e avaliação de risco contínuas

Um dos principais pilares de nossas capacidades de governança de dados é a descoberta e classificação unificadas de dados em nuvens e SaaS. À medida que as organizações se conectam a ambientes como AWS, Azure, Google Cloud, Snowflake, Databricks e outros, a Commvault mapeia automaticamente os repositórios de dados e os classifica continuamente, sejam os dados estruturados ou não estruturados.

A cada ativo é atribuída uma pontuação de risco, proporcionando às equipes uma visão priorizada de onde residem as informações confidenciais e onde a exposição é mais provável. Em vez de depender de varreduras periódicas, a platform a movimentação de dados, novos locais de armazenamento e mudanças na classificação, ajudando as equipes a identificar problemas mais cedo e a se concentrar primeiro nas áreas de maior risco.

Acesso com o mínimo de privilégios, com mascaramento dinâmico e supressão de dados

A proteção de dados tradicional geralmente se limita a saber onde os dados confidenciais estão; os recursos da Commvault enfatizam o controle sobre como esses dados são revelados. Por meio do mascaramento e da supressão de dados orientados por políticas, as organizações podem aplicar o princípio do privilégio mínimo de acesso, de modo que usuários, serviços e modelos de IA tenham acesso apenas às informações específicas para as quais estão autorizados, com campos confidenciais anonimizados ou ocultos, conforme necessário.

Como as mesmas políticas de mascaramento e supressão se aplicam a todos os ambientes conectados, as organizações podem proteger o acesso de maneira consistente, em vez de adotar regras fragmentadas, aplicadas aplicativo por aplicativo. Isso ajuda a reduzir o risco de superexposição de dados, em que um número excessivo de pessoas ou sistemas tem acesso a mais dados do que o necessário.

Segurança e manuseio seguro e ágil

Um recurso de destaque é a segurança de IA orientada por políticas, que opera no nível do prompt e da resposta. Antes mesmo que os dados sejam enviados a um modelo de IA, a Commvault, com tecnologia da Satori, pode interceptar a interação, detectar campos confidenciais (como dados pessoais sujeitos a regulamentação) e aplicar mascaramento ou supressão em linha, de acordo com as políticas de acesso a dados existentes.

Ao contrário de soluções que simplesmente bloqueiam prompts inteiros ou dependem exclusivamente da prevenção de perda de dados a jusante (tornando a segurança uma preocupação alheia), essa abordagem permite que os funcionários continuem usando assistentes de IA de forma produtiva, mantendo os dados confidenciais sob controle. Como a supressão ocorre antes que o modelo processe os dados, ela também ajuda a impedir que informações confidenciais influenciem ou contaminem os conjuntos de dados de treinamento da IA, protegendo tanto os usuários quanto o ambiente de IA como um todo.

Registros de auditoria centralizados auxiliam na conformidade

O elemento final de nossos recursos de governança de acesso a dados é o registro abrangente e centralizado de auditorias. Cada interação — seja uma consulta do usuário, um prompt de IA ou um evento de acesso regulamentado — é registrada com detalhes como quem acessou o quê, qual política foi aplicada e quais supressões ocorreram, quase em tempo real.

Essa visibilidade unificada de auditoria abrange dados em tempo real, sugestões de IA e eventos de governança de acesso, proporcionando aos líderes de segurança, TI e conformidade um único registro oficial, em vez de registros dispersos provenientes de ferramentas pontuais. Para os CISOs e CIOs, isso significa análises de conformidade mais rápidas e uma prova clara de que a governança não está apenas documentada no papel, mas é ativamente aplicada em todo o ambiente.

Ajudando as organizações a adotar a IA com segurança

Em conjunto, esses novos recursos oferecem às organizações uma maneira coesa de governar dados em um mundo habilitado para IA: visibilidade unificada entre nuvens, SaaS e IA; uma única política para usuários e modelos; mascaramento e supressão dinâmicos para acesso com privilégios mínimos; e proteção de prompts de IA baseada em políticas, respaldada por trilhas de auditoria completas. O resultado é uma mudança de controles reativos para uma governança proativa do acesso aos dados, preparada para a IA, ajudando as equipes a adotar a inovação em IA enquanto mantêm o controle sobre suas informações mais confidenciais.

Perguntas frequentes

P: O que diferencia a abordagem da Commvault à governança de dados com IA da proteção de dados tradicional?

R: A proteção de dados tradicional geralmente se concentra em backups e na resposta a incidentes após a ocorrência de uma exposição. A Commvault estende a governança para ambientes ativos e interações de IA, ajudando a possibilitar o controle proativo sobre como os dados são descobertos, acessados e utilizados em tempo real. Essa mudança ajuda as organizações a gerenciar riscos antes que se transformem em uma violação.

P: De que forma a descoberta e a classificação unificadas melhoram a segurança?

R: A descoberta e a classificação contínuas mapeiam e rotulam automaticamente dados estruturados e não estruturados em nuvens e plataformas SaaS. Ao atribuir pontuações de risco a cada ativo, as equipes obtêm uma visão priorizada da exposição de dados confidenciais. Isso ajuda a identificar mais rapidamente áreas de alto risco e a direcionar melhor os esforços de correção.

P: O que é o mascaramento dinâmico e por que ele é importante para cargas de trabalho de IA?

R: O mascaramento e a supressão dinâmicos limitam o que usuários, serviços e modelos de IA podem ver com base em políticas predefinidas. Campos confidenciais podem ser anônimizados ou ocultados, ao mesmo tempo em que ainda permitem o acesso legítimo aos dados relevantes. Essa abordagem promove a produtividade e, ao mesmo tempo, ajuda a reduzir o risco de exposição excessiva.

P: Como funciona a proteção de prompts de IA com reconhecimento de políticas?

R: A segurança de IA orientada por políticas intercepta prompts e respostas antes que os dados cheguem ao modelo de IA. Ela ajuda a detectar informações confidenciais e a aplicar mascaramento ou supressão em linha, de acordo com as políticas existentes. Isso ajuda os funcionários a continuarem usando ferramentas de IA, ao mesmo tempo em que mantém os dados regulamentados sob governança e fora dos conjuntos de dados de treinamento.

P: De que forma as trilhas de auditoria centralizadas apoiam os esforços de conformidade?

R: O registro abrangente de auditoria captura detalhes sobre quem acessou quais dados, quais políticas foram aplicadas e quais supressões ocorreram. Essa visibilidade unificada abrange dados em tempo real e interações de IA, ajudando a fornecer aos líderes de segurança e conformidade um registro claro e confiável. Isso contribui para revisões mais rápidas e demonstra que os controles de governança são ativamente aplicados.

P: Como esses recursos ajudam as organizações a adotar a IA com segurança?

R: Ao combinar visibilidade unificada, aplicação consistente de políticas, mascaramento dinâmico e trilhas de auditoria completas, os recursos de governança de dados da Commvault ajudam a proporcionar às organizações uma estrutura coesa para governar os dados na era da IA. Esses controles contribuem para viabilizar a inovação, ao mesmo tempo em que ajudam a manter o controle sobre informações confidenciais. O resultado é um caminho mais seguro e confiável para a adoção da IA.

Nico Guerrera é gerente sênior de marketing técnico na Commvault.

More related posts

Social_Blog_Satori_GigaOm_Leader_2026_Linkedin

Satori Named Leader in GigaOm’s Data Access Governance Radar Report

Read more
Thumbnail_Blog-Conversational-Resilience-2025-Linkedin

Conversational Resilience: The New Way to Manage and Protect Enterprise Data

Read more
Thumbnail_Blog_Satori-Acquisition-2025

Commvault Closes Acquisition of Satori, Strengthening Data and AI Security Platform

Read more
Thumbnail_Blog-Data-Rooms-2025-Linkedin

Data Activate: Unlocking the Power of Trusted Data for AI Innovation

Read more