Dados soberanos que não podem ser recuperados não são, na verdade, soberanos

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 voltada 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 Recovery estão localizados em outro país. Pior ainda, o próprio ambiente de Recovery (hospedado na nuvem, 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 das aplicações soberanas é 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 de 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 justamente 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 na qual 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 toda a 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 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 em 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 principal de dados: 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 de 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 atrasar 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 de 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: Elas 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.