A recuperação de desastres na nuvem começa com a empresa

Uma tarefa de backup bem-sucedida constitui uma evidência útil. No entanto, não é prova de que aplicativos, identidades, dados e processos de negócios possam ser recuperados em conjunto.

O verdadeiro teste é saber se a organização consegue restabelecer um serviço operacional dentro do prazo acordado, com um nível aceitável de perda de dados e responsabilidade clara por cada decisão.

O backup e a recuperação de desastres resolvem problemas diferentes

Os backups preservam cópias dos dados que podem ser restauradas após uma exclusão, corrupção ou um ataque. Eles são uma parte essencial da recuperação, mas não definem todo o processo de recuperação.

A recuperação de desastres reúne a tecnologia, as pessoas e os procedimentos necessários para restaurar os serviços de TI após uma interrupção. Dependendo do serviço e do incidente, isso pode envolver a restauração de backups, a reconstrução de sistemas ou a migração para um ambiente alternativo.

A continuidade dos negócios é um conceito ainda mais amplo. Ela leva em consideração como a organização continua operando enquanto os serviços estão indisponíveis, incluindo pessoas, fornecedores, comunicações e formas temporárias de trabalho.

Portanto, um plano de recuperação precisa ir além da simples pergunta: “Temos uma cópia?”

É preciso definir quais serviços têm prioridade, de que dependem, quem pode autorizar a recuperação e como a empresa confirmará que eles estão prontos para uso.

Defina o RTO e o RPO antes de escolher a tecnologia

Duas medidas ajudam a traduzir as prioridades empresariais em requisitos de recuperação:

Trata-se de decisões comerciais fundamentadas em avaliações técnicas. Uma plataforma financeira, um aplicativo voltado para o cliente e um arquivo interno não precisam, necessariamente, do mesmo modelo de recuperação.

As definições do NIST para RTO e RPO constituem um ponto de partida útil. O próximo passo é chegar a um consenso sobre o que esses objetivos significam para cada serviço crítico.

As metas também precisam de comprovação. Um RTO definido por escrito em um plano não é o mesmo que um tempo de recuperação comprovado em um exercício realista.

O ransomware dificulta a escolha do ponto de recuperação

O backup mais recente nem sempre é o mais seguro para restauração.

Um invasor pode ter comprometido um ambiente antes que o incidente se tornasse visível. Pontos de recuperação recentes podem, portanto, conter software malicioso, dados corrompidos ou alterações indesejadas na configuração.

Isso não altera a definição de RPO. O que muda é se a organização consegue atingir sua meta utilizando um ponto de recuperação no qual possa confiar.

As equipes de recuperação precisam investigar a linha do tempo do incidente, identificar um ponto de recuperação adequado e validar os sistemas restaurados em um ambiente controlado antes de reconectá-los ao ambiente de produção.

As orientações da Microsoft para recuperação após ataque de ransomware recomendam identificar o último ponto de recuperação sem infecção, restaurar os dados em uma rede isolada e verificar se os dados restaurados estão infectados.

A detecção de anomalias no backup pode ajudar a identificar alterações incomuns. Ela deve servir como apoio à investigação e à validação, em vez de ser considerada uma prova de que um ponto de recuperação está intacto.

A nuvem oferece opções, não resiliência automática

Os serviços em nuvem oferecem diferentes maneiras de equilibrar a velocidade de recuperação, o custo operacional e os requisitos das aplicações.

Algumas cargas de trabalho podem ser restauradas a partir de backups. Outras exigem um ambiente de recuperação preparado ou sistemas replicados para atender a objetivos de recuperação mais rigorosos.

A abordagem correta depende do impacto nos negócios causado pelo tempo de inatividade e pela perda de dados, além das dependências do aplicativo.

A nuvem não elimina os custos de recuperação. Armazenamento, replicação, rede, licenciamento, capacidade de reserva e testes: tudo isso precisa ser incluído. Opções de recuperação mais rápidas geralmente exigem maior investimento e preparação operacional.

As orientações da AWS sobre recuperação de desastres na nuvem explicam por que as estratégias de recuperação devem ser reavaliadas levando em conta o impacto nos negócios, o risco e o custo.

A mesma disciplina se aplica a ambientes híbridos e multicloud. O uso de mais de uma plataforma, por si só, não garante um caminho de recuperação funcional. A identidade, a conectividade, a compatibilidade de aplicativos e a responsabilidade operacional ainda precisam ser planejadas e testadas.

O objetivo é adequar a proteção ao nível de criticidade dos negócios, sem arcar com os custos de um modelo de recuperação desnecessariamente exigente para todas as cargas de trabalho.

Incluir serviços de IA no plano de recuperação

À medida que as organizações colocam a IA em produção, o planejamento de recuperação precisa levar em conta mais do que apenas aplicativos convencionais e armazenamento de arquivos.

Um serviço baseado em IA pode depender de:

• Versões do modelo e artefatos de ajuste fino.
• Documentos de origem, conjuntos de dados e suas permissões.
• Bancos de dados vetoriais e índices de pesquisa.
• Configuração do aplicativo, mensagens de solicitação e definições de fluxo de trabalho.
• Serviços de identidade, credenciais e provedores de modelos externos.

Alguns ativos precisam ter cópias de segurança. Outros podem ser reconstruídos a partir de material de origem protegido, desde que o tempo de reconstrução atenda aos requisitos de recuperação do serviço.

No caso de modelos hospedados externamente, a organização também precisa entender quais são as responsabilidades do provedor e o que acontece caso esse serviço fique indisponível.

A questão prática é simples: o que precisa ser restaurado, reconstruído ou reconectado para que a empresa possa voltar a utilizar o serviço de IA?

Três pilares para uma recuperação mais segura

Esses controles atuam em conjunto. Os dados protegidos têm valor limitado se ninguém puder acessar as ferramentas de recuperação ou se os aplicativos restaurados forem imediatamente reconectados a um ambiente que continue comprometido.

Teste o serviço de negócios, não apenas a tarefa de restauração

As medidas de recuperação precisam ser adaptadas à medida que os aplicativos, as integrações, as identidades e as prioridades de negócios mudam.

Um exercício útil deve demonstrar que o serviço funciona, em vez de simplesmente confirmar que o servidor é iniciado.

Isso significa testar as dependências das aplicações, o acesso, a consistência dos dados, as verificações de segurança e a capacidade da equipe de negócios de realizar tarefas essenciais.

A automação pode facilitar as verificações repetitivas. No entanto, ela não elimina a necessidade de exercícios coordenados e da aprovação da empresa.

Registre o que aconteceu, compare os resultados com o RTO e o RPO acordados e designe responsáveis para quaisquer lacunas. Repita os testes relevantes após alterações significativas.

Antes do próximo incidente, a liderança deve ser capaz de responder:

• Quais serviços empresariais devem se recuperar primeiro?
• Quais níveis de tempo de inatividade e perda de dados os proprietários aceitaram?
• Quando foi a última vez em que se observou uma recuperação representativa?
• Como vamos selecionar e validar um ponto de recuperação válido?
• A equipe de recuperação pode operar caso os serviços normais de identificação não estejam disponíveis?
• Quem autoriza o failover, a reconexão e o retorno às operações normais?

Um plano de recuperação só se torna confiável quando essas respostas são respaldadas por evidências.

Como a Getronics ajuda

Os serviços de Gestão da Continuidade de Serviços de TI da Getronics oferecem suporte ao planejamento de recuperação por meio da análise de requisitos, avaliação de riscos, definição de RTO e RPO, estratégia de recuperação de desastres e testes gerenciados.

Nossos serviços de nuvem e infraestrutura integram esse planejamento às operações em nuvem privada, pública e híbrida, incluindo opções de backup, replicação e recuperação de desastres.

O ponto de partida é entender o que a empresa precisa para se recuperar e, em seguida, elaborar e testar uma estratégia de recuperação com base nessas necessidades.

O seu plano de recuperação é capaz de atender às necessidades da sua empresa?

Discuta com a Getronics seus serviços essenciais, metas de recuperação e lacunas nos testes.