Cloud nos proporcionar flexibilidade, além de:
- Serviços de ponta.
- Inovação Cloud.
- 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 paracloud. 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 da aplicação. Proteger fontes de dados individuais não é o mesmo que restaurar um ecossistema de aplicações sincronizadas.
- 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 cloud não coordenam operações entre nuvens.
- O isolamento é o primeiro 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 mundo 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 restaurada 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.
O primeiro dominó: o isolamento
Cada vetor de ameaça se expande proporcionalmente à complexidade do ambiente.cloud a diversificar a infraestrutura – ela amplia o escopo operacional.
Backup no nível do serviço vs. recuperação no nível da aplicação
É aqui que a maioria das organizações tropeça. Eles 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,cloud orquestração. Não estão otimizadas para garantir o tempo de recuperação (RTO) ou o ponto de recuperação (RPO) em grande escala paracloud .
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”. Atualmente, os aplicativos abrangem vários hyperscalers, várias equipes de DevOps, vários domínios de administração e várias ferramentas de backup de diferentes 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.
Antevisão: Por queCloud 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.
- Testando 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á desacelerando. Mas, a menos que as estratégias de Recovery evoluam junto com a arquitetura, a complexidade superará 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ê vai 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 esta 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 cloud específica, cloud não coordenam a recuperação entre nuvens.cloud exigem uma restauração coordenada entre serviços e provedores.
P: Qual é a maior lacuna nacloud ?
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 a melhorarcloud ?
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ênciacloud .
Chris Mierzwa é diretor sênior de marketing de portfólio na Commvault.
