Conformidade com o Artigo 12 da DORA: Um guia de backup e recuperação para entidades financeiras

Artigo 12, parágrafo 1, alínea a): Escopo do backup e frequência mínima de backup

De acordo com o Artigo 12, parágrafo 1, alínea a), as entidades financeiras devem elaborar e manter uma política de backup que especifique quais dados são copiados e com que frequência mínima cada categoria de dados deve ser copiada. Elas devem basear o escopo e a frequência no grau de criticidade ou confidencialidade dos dados.

Como os dados apresentam diferentes níveis de risco, a regra garante que seus dados mais importantes recebam a proteção mais frequente. Para cumprir essa cláusula, classifique seus dados por grau de criticidade; por exemplo, marque os registros de contas de clientes como críticos, os arquivos de RH como importantes e os documentos antigos de projetos como de baixa prioridade. Em seguida, defina uma frequência mínima para cada classe e registre sua justificativa na política. Um livro-razão de pagamentos pode precisar de backups a cada hora, enquanto um arquivo de documentos de marketing pode ser feito semanalmente.

Artigo 12, parágrafo 1, alínea b): Procedimentos documentados de restauração e recuperação

Além da política de backup prevista na alínea (a), o Artigo 12, parágrafo 1, alínea b) abrange o aspecto de recuperação da proteção de dados. Ele exige que as entidades financeiras mantenham procedimentos escritos de restauração e recuperação que orientem a equipe sobre qual backup utilizar, onde restaurá-lo e a ordem em que os sistemas devem voltar a operar. Como a equipe não pode se dar ao luxo de improvisar durante uma crise, um plano escrito ajuda a restaurar os serviços rapidamente e reduz o tempo de recuperação. Certifique-se de manter esses documentos acessíveis mesmo quando seus sistemas principais estiverem fora do ar.

Artigo 12(2): Ativação segura dos sistemas de backup

Uma restauração descuidada pode trazer malware de volta ao ambiente de produção ou deixar os dados dos clientes expostos em um servidor desprotegido. O Artigo 12(2) protege contra esse risco ao estabelecer duas condições para seus sistemas de backup. Primeiro, você deve ser capaz de ativá-los conforme descrito em sua política de backup. Em segundo lugar, a ativação não pode comprometer a segurança da sua rede nem colocar seus dados em risco de perda, alteração, falsificação ou exposição. Para estar em conformidade com este artigo, criptografe seus backups, limite quem pode executar restaurações e para onde os dados restaurados podem ser enviados, e verifique se há malware nos dados restaurados antes que eles retornem à produção.

Artigo 12, parágrafo 2: Testes periódicos de backup e recuperação

Artigo 12, parágrafo 2 também exige a realização de testes periódicos dos seus procedimentos de backup, restauração e recuperação. Backups não testados costumam falhar no pior momento possível, e a única prova de que a recuperação funciona é restaurar os dados em um sistema de teste separado e confirmar que o aplicativo inicia, que os dados estão completos e que a restauração é concluída dentro do seu tempo-alvo de recuperação. Utilize um software de backup e recuperação ciber-resiliente para restaurar dados reais em um ambiente de teste em intervalos regulares e confirme se os sistemas funcionam. Não se esqueça de manter um registro dos resultados e de quaisquer problemas que você corrigir, pois as normas técnicas da DORA exigem resultados de testes documentados.

Artigo 12, parágrafo 3: Sistemas de restauração segregados física e logicamente

Quando as entidades financeiras restauram backups em seus próprios sistemas, o Artigo 12, parágrafo 3, obriga que utilizem sistemas que estejam fisicamente e logicamente separados do ambiente de produção e protegidos contra acesso não autorizado. A regra impede que um invasor, mesmo aquele que já tenha invadido o ambiente de produção, alcance seu ambiente de recuperação. A EIOPA interpreta isso como sistemas sob seu controle total que não estejam diretamente conectados ao sistema principal. Para estar em conformidade, construa seu ambiente de recuperação em uma infraestrutura separada, com separação de rede e controles de acesso próprios. Seu software de backup deve, então, restaurar a partir de cópias isoladas, e o Bacula Enterprise pode recuperar sistemas críticos a partir de fitas offline ou armazenamento desconectado em uma infraestrutura sob seu controle.

Artigos 12(6) e 12(7): Objetivos de recuperação e verificações de integridade

O Artigo 12(6) estabelece os objetivos de tempo de recuperação (RTO) e de ponto de recuperação (RPO) para cada função, e o Artigo 12(7) acrescenta verificações de integridade e reconciliações após a recuperação de um incidente. Essas regras definem a rapidez com que a recuperação deve ocorrer, a quantidade de dados que você pode se dar ao luxo de perder e como confirmar se os dados restaurados estão corretos. Para cumprir os Artigos 12(6) e 12(7), defina um RTO e um RPO para cada função crítica ou importante e programe backups com frequência pelo menos igual à permitida por cada RPO.

Um RPO de uma hora exige backups pelo menos a cada hora, enquanto um RPO de 24 horas pode contar com um backup noturno. Antes de colocar o sistema em operação, reconcilie os dados restaurados com seus outros sistemas. O restante do Artigo 12 acrescenta capacidade redundante de TIC para todas as empresas, exceto as menores, e regras adicionais para depositários centrais de títulos, contrapartes centrais e prestadores de serviços de relatório de dados.

Artigo 12(1)(a): Tarefas, conjuntos de arquivos e programações para a política de backup

O Artigo 12(1)(a) exige que você elabore uma política de backup que liste quais dados serão copiados e com que frequência, com base na importância desses dados. O Bacula permite que você insira essas mesmas duas decisões diretamente no software.

Você pode listar os servidores, bancos de dados e pastas a serem copiados em uma configuração chamada Conjunto de Arquivos e definir a frequência dos backups em uma configuração chamada Agendamento; por exemplo, a cada hora para registros de pagamento e uma vez por dia para e-mails. O Bacula, então, executa cada backup automaticamente de acordo com esse agendamento e registra cada execução em um Relatório de Tarefa, o que fornece a você uma prova por escrito de que seus backups efetivamente seguem sua política.

Artigo 12(1)(b): Procedimentos de recuperação com Catálogo, Arquivos de Bootstrap e Recuperação Bare-Metal

O Artigo 12(1)(b) exige procedimentos escritos passo a passo para restaurar seus sistemas e dados após uma interrupção. O Bacula oferece três ferramentas para executar esses procedimentos: o catálogo, os arquivos de bootstrap e a recuperação bare-metal.

• Primeiro, o Catálogo é um banco de dados que registra o que foi copiado e onde cada cópia está armazenada, e o Bacula recomenda fazer backup dele diariamente.
• A segunda ferramenta são os arquivos de inicialização, que informam ao Bacula exatamente onde cada backup está localizado e permitem reconstruir o Catálogo caso o próprio servidor de backup seja perdido.
• Por fim, você conta com a recuperação completa para Linux e Windows, que reconstrói um servidor com falha do zero, incluindo seu sistema operacional, configurações e dados.

Artigo 12(2): Criptografia e controle de acesso para restaurações seguras

O Artigo 12(2) exige que a ativação de seus backups não coloque seus sistemas em risco nem exponha, altere ou corrompa seus dados. Para ajudá-lo a cumprir essa cláusula, o Bacula criptografa os dados de backup em trânsito e em repouso, mantendo-os ilegíveis para qualquer pessoa que não possua suas chaves de criptografia.

Ele também controla quem pode executar uma restauração e para onde os dados restaurados podem ser direcionados, utilizando suas contas existentes do Active Directory ou LDAP, autenticação de dois fatores e permissões baseadas em funções. Durante o backup e a restauração, o Bacula pode verificar os arquivos em relação a assinaturas conhecidas de malware, ajudando a impedir que um arquivo infectado retorne à produção. Dito isso, fazer backup e proteger as chaves de criptografia continua sendo sua responsabilidade, de acordo com o Artigo 7 do regulamento delegado.

Artigo 12(2): Armazenamento imutável para cópias de backup

O Artigo 12(2) também exige que seus dados de backup permaneçam disponíveis e inalterados quando for necessário restaurá-los. O Bacula pode gravar backups em um armazenamento imutável, onde os backups salvos não podem ser alterados ou excluídos (até que o período de proteção definido por você termine).

O Bacula oferece suporte a armazenamento imutável em volumes de disco do Linux, em sistemas NAS como o NetApp SnapLock e o Data Domain Retention Lock, em fitas WORM e na nuvem por meio do Amazon S3 Object Lock e do armazenamento imutável do Azure Blob. No entanto, o armazenamento imutável ainda pode se conectar à sua rede e não substitui os sistemas de restauração separados exigidos pelo Artigo 12, parágrafo 3.

Artigos 12(2) e 11(6): Teste de Independência de Recuperação para Testes de Restauração

Os artigos 12(2) e 11(6) exigem, respectivamente, testes reais de recuperação, e a documentação do Bacula trata esses testes como parte do plano de recuperação. Com a Recuperação Independente, o Teste de Independência de Recuperação verifica se os sistemas críticos acordados podem ser restaurados utilizando apenas sua própria infraestrutura, equipe, credenciais e backups isolados, sem qualquer ajuda do Bacula. Você define o escopo e os critérios de sucesso. Os resultados, tempos e correções passam então a constituir os registros que o Artigo 25 do regulamento delegado exige que você relate.

Artigo 12, parágrafo 3: Recuperação Independente do Bacula para Restauração Segregada

Ao restaurar em seus próprios sistemas, o Artigo 12, parágrafo 3, exige que esses sistemas estejam física e logicamente separados do ambiente de produção e protegidos contra acesso não autorizado. Recuperação Independente do Bacula restaura sistemas críticos a partir de cópias offline em fita, mídia removível ou armazenamento desconectado. Ela pode ser executada inteiramente em sua própria infraestrutura, sem conexão com o Bacula ou qualquer serviço de fornecedor, o que está em conformidade com a interpretação da EIOPA sobre a regra. Além disso, você recebe um Kit de Independência de Recuperação lacrado que contém o software, as configurações, as chaves de criptografia e as instruções necessárias para reconstruir tudo do zero.

Artigo 12(7): Tarefas de verificação para checagem de integridade

O Artigo 12(7) exige que você verifique se seus dados estão completos e corretos após a recuperação de um incidente, incluindo a reconciliação com seus outros sistemas. Uma tarefa de verificação do Bacula lê os dados de backup do armazenamento e confirma se eles estão intactos e se correspondem aos registros do Bacula sobre o que foi salvo.

Ela também pode comparar arquivos em um servidor com um backup anterior e sinalizar aqueles que foram alterados inesperadamente; é importante ressaltar que esses relatórios ajudam durante as auditorias. Além disso, observe que uma tarefa de verificação não confirma se um aplicativo funciona ou se os saldos estão corretos, e suas equipes ainda precisam realizar essas verificações por conta própria.