Cloud que realmente funciona

A nuvem nos oferece flexibilidade, além de:

Serviços de ponta.
Inovação na nuvem.
Liberdade da dependência de um único fornecedor.

Mas, quando ocorre um incidente cibernético, essa flexibilidade muitas vezes se transforma em complexidade. Neste episódio do STRIVE, conversei com o diretor sênior de gestão de produtos, Akshay Joshi — cuja carreira abrange a IBM, a AWS, a Microsoft, a Clumio e, atualmente, a Commvault — para abordar uma verdade incômoda: a maioria das organizações acredita estar pronta para a nuvem. Até descobrirem que não estão. Assista ao episódio completo.

Pontos principais: O que a nuvem realmente exige

O backup no nível do serviço não equivale à recuperação no nível do aplicativo. Proteger fontes de dados individuais não é o mesmo que restaurar um ecossistema de aplicativos sincronizados.
A complexidade da recuperação aumenta quando se trata de várias nuvens. Diferentes pontos de recuperação, diferentes contas, diferentes equipes de administração — cada um desses fatores cria obstáculos justamente quando o tempo é o que mais importa.
As ferramentas nativas de hiperescala são necessárias, mas não suficientes. Elas oferecem proteção dentro de sua própria nuvem, mas não coordenam operações entre nuvens.
O isolamento é a primeira peça de dominó em um incidente cibernético. Quanto maior for a exposição do ambiente, mais difícil será conter o impacto.
A resiliência deve ser incorporada desde o início — e não implementada posteriormente. O mapeamento de dependências e o planejamento de recuperação devem começar na fase de projeto da aplicação, e não após a implantação.
A automação baseada em IA traz mais poder — e novos riscos. Os fluxos de trabalho baseados em agentes exigem controles rigorosos de permissão e disciplina em termos de governança.

A diferença entre o que está “no papel” e a realidade

No papel, a recuperação parece simples: até quando se deve recuperar? O que se deve recuperar? Onde se deve recuperar? Mas, como explica Akshay, cada uma dessas perguntas se fragmenta em um ambiente multicloud. Serviços diferentes podem ter pontos de recuperação distintos. Alguns microsserviços podem ser afetados, enquanto outros não. A recuperação pode exigir uma reestruturação da arquitetura se for realizada entre regiões ou entre contas.

O que parece simples na documentação torna-se extremamente complexo na prática. E quando um ransomware ataca, as equipes não consultam calmamente os manuais de procedimentos — elas entram em pânico.

A primeira peça do dominó: o isolamento

Cada vetor de ameaça se expande proporcionalmente à complexidade do ambiente. À medida que a nuvem diversifica a infraestrutura, ela amplia o escopo operacional.

Backup no nível do serviço x recuperação no nível da aplicação

É aqui que a maioria das organizações tropeça. Elas afirmam:

Dados do Azure com o Azure Backup
Dados da AWS com o AWS Backup
Google Cloud com uma ferramenta separada

Individualmente, cada serviço pode estar protegido. Coletivamente, o aplicativo pode não ser recuperável em um estado sincronizado. As ferramentas nativas não se comunicam entre nuvens. Elas não são, por natureza, de orquestração de nuvem. Não estão otimizadas para garantir o tempo de recuperação (RTO) ou o ponto de recuperação (RPO) em grande escala para a nuvem.

E quando a recuperação depende do alinhamento de várias fontes de dados entre hiperescaladores, a orquestração faz toda a diferença entre horas e dias. É exatamente por isso que existem estratégias de recuperação unificadas – não para substituir os hiperescaladores, mas para coordená-los.

O mapeamento de dependências não é mais opcional

Há mais de uma década que falamos sobre o mapeamento de dependências de aplicativos. Mas, em um mundo multicloud, isso não é mais apenas um “diferencial”. Os aplicativos agora abrangem vários hiperescaladores, várias equipes de DevOps, vários domínios de administração e várias ferramentas de backup de fornecedores.

A fragmentação da responsabilidade retarda a Recovery. A fragmentação de fornecedores complica a orquestração. Silos operacionais geram atrasos no pior momento possível. A resiliência deve ser implementada desde o início – e não acrescentada após a implantação.

Prévia: Por que a nuvem falha sem o mapeamento de dependências

Neste trecho da conversa do STRIVE, Akshay explica por que é fundamental incorporar a resiliência já na fase de arquitetura para sobreviver a incidentes cibernéticos reais.

Projetando para a recuperação – Não apenas para a proteção

Um dos pontos mais importantes deste episódio: as aplicações modernas devem ser projetadas não apenas com foco no desempenho e na escalabilidade, mas também na capacidade de recuperação. Isso significa que:

Levar em conta tanto o RTO quanto o RPO.
Projetar tendo em mente a nuvem.
Consolidar a visibilidade sempre que possível.
Reduzir a fragmentação de fornecedores e de tarefas administrativas.
Testar a recuperação em diferentes ambientes.

A velocidade da recuperação afeta a receita. A clareza da recuperação afeta a reputação. O tempo de inatividade afeta a confiança do cliente. A inovação multicloud deve ser acompanhada por uma disciplina de recuperação multicloud.

A camada de IA e automação

Nenhuma discussão está completa sem abordar a IA. Os fluxos de trabalho baseados em agentes estão cada vez mais integrados às plataformas SaaS corporativas. Mas a automação traz novas considerações:

Quais são as permissões dos agentes?
Com que frequência os backups são executados?
Quais são as implicações financeiras decorrentes das decisões de automação?
Os agentes são tratados como identidades com acesso controlado?

A IA pode acelerar a resiliência – mas, sem medidas de segurança, também pode ampliar os riscos. O segredo está na delegação controlada.

Por que tivemos essa conversa no STRIVE

O STRIVE não se trata de repetir o que todos já sabem. Trata-se de enfrentar as lacunas que surgem durante eventos cibernéticos do mundo real. A adoção da multicloud não está diminuindo. Mas, a menos que as estratégias de Recovery evoluam junto com a arquitetura, a complexidade ultrapassará o nível de preparação.

É por isso que essa discussão é importante. E é por isso que convidamos o Akshay – alguém que já trabalhou com hiperescaladores e compreende tanto o poder quanto as limitações deles.

Assista ao episódio completo

No episódio completo do STRIVE, você descobrirá:

A verdadeira lacuna entre o backup no nível do serviço e a recuperação no nível da aplicação.
Por que o isolamento é o primeiro dominó em casos de ransomware.
Como a fragmentação de fornecedores complica a orquestração.
O que os CISOs e os líderes de DevOps precisam alinhar.
Como a IA muda a equação da resiliência.

Assista agora. Se você opera na AWS, no Azure ou no Google Cloud, essa conversa é essencial.

Perguntas frequentes

P: Por que o backup nativo dos hyperscalers não é suficiente?

R: As ferramentas nativas protegem os dados dentro de uma nuvem específica, mas não coordenam a recuperação entre nuvens. Isso exige uma restauração coordenada entre serviços e provedores.

P: Qual é a maior lacuna na nuvem?

R: A discrepância entre a forma como os backups são feitos (serviço por serviço) e a forma como a recuperação deve ocorrer (em toda a aplicação).

P: O que significa “abertura ambiental”?

R: Refere-se à amplitude de contas, nuvens, identidades e serviços em um ambiente. À medida que essa amplitude se expande, o risco e a complexidade aumentam proporcionalmente.

P: Por que o mapeamento de dependências é fundamental?

R: Atualmente, as aplicações abrangem várias nuvens e equipes. Sem um mapeamento das dependências dos serviços, a sequência de recuperação torna-se uma questão de adivinhação.

P: Como a IA influencia a recuperação de desastres?

R: Os fluxos de trabalho baseados em IA podem ajudar a automatizar as decisões relacionadas a backup e recuperação, mas exigem controles de acesso rigorosos, gestão de custos e supervisão.

P: Por onde as organizações devem começar para melhorar a nuvem?

R: Comece avaliando:

- Alinhamento da recuperação no nível da aplicação.
- Oportunidades de consolidação de fornecedores.
- Sincronização entre equipes.
- Estratégia de isolamento durante incidentes.
- Frequência de uso da nuvem.

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