Risco dos dados de backup do fornecedor

Um fornecedor de serviços de folha de pagamento sofreu uma violação que os investigadores rastrearam até um bucket de backup do Amazon S3. O bucket continha um backup completo do banco de dados de catorze meses antes: uma cópia integral dos registros de folha de pagamento dos funcionários, das informações fiscais e dos dados bancários de todos os clientes. O banco de dados de produção tinha controles rigorosos: criptografado com chaves gerenciadas pelo cliente, acessível apenas por uma camada de aplicativo com acesso baseado em funções, com registro de auditoria e revisado trimestralmente. O bucket de backup havia sido criado por um engenheiro de infraestrutura durante um exercício trimestral de verificação de backups. A política do bucket havia sido configurada para permitir o acesso a partir da função de IAM do engenheiro, que tinha amplo acesso à infraestrutura. O engenheiro havia deixado a organização seis meses antes. Sua função de IAM havia sido desativada para o acesso de produção, mas a política do bucket fazia referência direta à função e nunca havia sido atualizada. Uma varredura de configurações incorretas feita por um pesquisador de segurança encontrou o bucket com listagem pública por meio de uma configuração de ACL separada, aplicada por engano e nunca corrigida. O banco de dados de produção estava seguro. O backup era uma cópia de catorze meses dos mesmos dados, acessível por meio de um erro de configuração que existia desde que o engenheiro o criou.

O que é, de fato, o problema do risco dos dados de backup de fornecedores?

Os dados de backup contêm as mesmas informações que os dados de produção no momento em que o backup foi feito. Têm a mesma sensibilidade, a mesma classificação regulatória e as mesmas implicações de notificação de violação se forem expostos. O que normalmente lhes falta é a continuidade de governança que os dados de produção recebem: as revisões de acesso, a rotação de chaves, as auditorias de permissões e o monitoramento de segurança aplicados aos sistemas de produção por meio de processos operacionais que nunca foram estendidos à infraestrutura de backup. Os backups são criados por processos operacionais. São governados por processos que muitas vezes nunca existiram.

O problema da deterioração da governança é estrutural e depende do tempo. Um backup criado há dezoito meses foi configurado com os controles de acesso, as chaves de criptografia e as políticas de armazenamento adequados naquele momento. Nos dezoito meses seguintes, o cenário de acessos da organização mudou: funcionários saíram, funções foram reestruturadas, políticas de rotação de chaves foram aplicadas à produção, mas não aos backups históricos, e configurações de políticas de armazenamento que estavam corretas na criação podem não ser mais adequadas ao modelo de ameaças atual. Os controles do banco de dados de produção são mantidos continuamente. Os controles do backup refletem um retrato da postura de governança no momento da criação, e nada os atualizou desde então.

O volume de dados de backup no ambiente de um fornecedor empresarial típico é consideravelmente maior do que a presença em produção sugere. Um fornecedor com um relacionamento de três anos com um cliente pode manter backups diários de meses atrás, backups semanais de até um ano, backups mensais de vários anos e backups trimestrais de verificação de DR em diversos momentos do relacionamento. Cada backup contém os dados completos do cliente naquele momento. Cada um tem sua própria configuração de armazenamento, seus próprios controles de acesso e sua própria chave de criptografia. O banco de dados de produção é um sistema governado. O acervo de backups são dezenas de cópias em vários locais de armazenamento, cada uma com uma governança que reflete o que foi configurado na criação e que talvez nunca tenha sido revisada.

O risco dos dados de backup de fornecedores se concentra em cinco padrões específicos de falha de governança:

• Desvio no controle de acesso ao armazenamento de backups: funções de IAM, políticas de buckets de armazenamento e credenciais de acesso configuradas na criação do backup e nunca revisadas em relação aos requisitos de acesso atuais
• Lacunas na gestão de chaves de criptografia: dados de backup criptografados com chaves que foram retiradas do uso em produção, mas continuam aplicadas aos backups históricos, criando um ciclo de vida de chaves separado que não é mantido pela governança das chaves de produção
• Configuração incorreta do armazenamento de backups: buckets de armazenamento em nuvem ou repositórios de backup com políticas excessivamente permissivas, acessibilidade pública ou acesso entre contas não intencional e nunca corrigido
• Falhas na política de retenção: backups mantidos além dos períodos de retenção definidos por falhas em processos manuais ou pela ausência de exclusão automatizada, acumulando exposição de dados históricos
• Criptografia dos backups em repouso versus em trânsito: backups criptografados em repouso no armazenamento, mas transmitidos em texto claro durante a criação do backup, os testes de restauração ou a transferência entre locais de armazenamento

Por que isso importa

O risco dos dados de backup de fornecedores é importante para TPRM porque os sistemas de backup representam o maior ponto de acúmulo de dados históricos no ambiente de um fornecedor: eles guardam cópias de dados de clientes de anos atrás, com uma governança que reflete o estado da organização no momento da criação de cada backup, e não os padrões de segurança atuais. Uma violação do sistema de backup de um fornecedor pode expor um conjunto de dados maior e mais antigo do que qualquer violação de produção, porque os backups se acumulam ao longo do tempo sem a governança de minimização e retenção de dados aplicada aos sistemas de produção.

O desafio forense e regulatório é agravado pela natureza histórica dos dados de backup. Quando uma violação de backup é descoberta, o escopo da notificação deve descrever quais dados estavam no backup, o que pode exigir a reconstrução do estado do banco de dados no momento em que o backup foi feito, meses ou anos atrás. Registros que já foram excluídos da produção podem estar presentes em backups históricos. Registros que foram objeto de pedidos de eliminação podem existir em backups criados antes de a eliminação ser executada. O backup contém os dados como existiam em um momento anterior à postura de governança atual, possivelmente incluindo dados que o fornecedor não mantém mais em produção e que talvez nem saiba que estão presentes nos backups.

Para profissionais de TPRM, a preocupação específica é se o programa de governança de backups do fornecedor abrange todo o acervo de backups, e não apenas o backup mais recente, mas todo o arquivo de retenção, com o mesmo rigor da governança dos dados de produção. O banco de dados de produção é a ponta visível do iceberg da segurança de dados. O acervo de backups é o resto.

Onde a maioria das equipes erra

A falha mais recorrente é avaliar a segurança dos backups como uma capacidade de continuidade de negócios, e não como uma capacidade de segurança de dados. As avaliações de backup normalmente perguntam sobre RTO e RPO, criptografia dos dados de backup e frequência dos testes de backup, que são perguntas de resiliência operacional. Raramente perguntam sobre os controles de acesso ao armazenamento de backups, a gestão do ciclo de vida das chaves de criptografia dos dados de backup, a governança da retenção de backups ou se os controles de acesso aos backups históricos refletem os requisitos de acesso atuais. As perguntas de resiliência e as perguntas de segurança são avaliações diferentes, e a maioria dos programas de TPRM realiza a primeira sem a segunda.

A segunda falha é tratar a confirmação da criptografia dos backups como equivalente à governança de segurança dos backups. Backups criptografados em repouso no armazenamento em nuvem estão protegidos contra o acesso direto ao armazenamento: a configuração incorreta da política do bucket S3 no caso de abertura expôs os metadados dos backups que permitiram a descoberta, e depois disso a criptografia ainda precisaria ser quebrada. Mas a criptografia dos backups não resolve o desvio no controle de acesso, as lacunas na rotação de chaves nem as falhas na política de retenção, as outras dimensões da segurança de backups que são igualmente relevantes.

• Tratar a segurança dos backups como equivalente à maturidade operacional dos backups: avaliação de resiliência versus avaliação de segurança de dados
• Controles de acesso aos backups históricos nunca revisados: funções de IAM e políticas de armazenamento configuradas na criação e nunca atualizadas
• Ciclo de vida das chaves de criptografia dos backups não avaliado: a rotação das chaves de produção não é aplicada às chaves de criptografia dos backups históricos
• Governança da retenção de backups não verificada: backups se acumulam além dos períodos de retenção definidos por falhas de processo
• Configuração incorreta do armazenamento de backups não avaliada: políticas de buckets e configurações de acesso não revisadas em busca de definições excessivamente permissivas

Como é uma boa prática

Programas maduros de segurança de backups tratam os dados de backup com os mesmos padrões de governança dos dados de produção, incluindo revisão de acesso, gestão de chaves de criptografia, aplicação da retenção e monitoramento de segurança. O acervo de backups é inventariado, os controles de acesso são revisados com a mesma periodicidade das revisões de acesso de produção e as políticas de retenção são aplicadas por exclusão automatizada, e não por processos manuais.

• Revisões de controle de acesso dos backups na periodicidade de produção: permissões de acesso ao armazenamento de backups revisadas trimestralmente, acompanhando o cronograma de revisão de acesso de produção
• Gestão do ciclo de vida das chaves de criptografia dos backups: chaves de criptografia dos backups rotacionadas no mesmo cronograma que as chaves de produção, ou nova criptografia dos backups quando as chaves de produção são rotacionadas
• Aplicação automatizada da retenção no armazenamento de backups: exclusão dos backups acionada automaticamente quando o período de retenção expira, sem depender de processo manual
• Varredura de segurança do armazenamento de backups: varredura regular do armazenamento de backups em busca de políticas excessivamente permissivas, acessibilidade pública e caminhos de acesso não autorizados
• Inventário de backups mantido: todos os locais de armazenamento de backups documentados com controles de acesso, referência da chave de criptografia e situação da retenção

Ferramentas

A governança de dados de backup exige tanto as ferramentas operacionais de backup quanto as ferramentas de governança de segurança aplicadas ao armazenamento onde os backups ficam.

Segurança do armazenamento em nuvem: AWS S3 Security Hub, Azure Policy, GCP Security Command Center

As ferramentas de postura de segurança em nuvem fazem varreduras contínuas das configurações de armazenamento em nuvem em busca de problemas de segurança, identificando políticas de buckets excessivamente permissivas, acessibilidade pública, acesso entre contas e configurações de criptografia incorretas. O AWS Security Hub oferece avaliação automatizada das configurações de buckets S3 com base nas boas práticas de segurança. Para profissionais de TPRM, perguntar se o fornecedor faz varreduras regulares das configurações de armazenamento de backups em busca de configurações incorretas revela se o erro de política do bucket que produziu o cenário de abertura seria detectado antes de ser explorado.

Gestão de chaves para criptografia de backups: AWS KMS, Azure Key Vault

Os serviços de KMS em nuvem permitem a gestão separada de chaves para dados de backup, possibilitando cronogramas de rotação de chaves, políticas de acesso e registros de auditoria diferentes para as chaves de criptografia dos backups e as chaves de produção. Para profissionais de TPRM, perguntar se o fornecedor gerencia as chaves de criptografia dos backups separadamente das chaves de produção, com cronograma de rotação próprio, revela se a governança das chaves de criptografia se estende ao acervo de backups.

Governança de dados de backup: Cohesity DataHawk, Rubrik Security Cloud

Plataformas modernas de proteção de dados, como Cohesity e Rubrik, oferecem recursos de governança de segurança para dados de backup, incluindo gestão de controles de acesso, detecção de anomalias nos padrões de acesso aos backups e relatórios de conformidade para dados de backup. Essas plataformas tratam os dados de backup como um acervo de dados governado, e não como uma capacidade puramente operacional. Para profissionais de TPRM, perguntar se o fornecedor usa uma plataforma moderna de proteção de dados com recursos de governança de segurança revela se a segurança dos backups foi operacionalizada ou deixada a cargo de uma gestão de infraestrutura improvisada.

Desafios de governança

O desafio de governança dos dados de backup é a lacuna de responsabilidade. Os sistemas de backup normalmente pertencem às equipes de infraestrutura ou de operações, cuja responsabilidade principal é a disponibilidade e a capacidade de recuperação: garantir que os backups sejam criados, armazenados de forma confiável e possam ser restaurados quando necessário. A governança de segurança de dados (controles de acesso, rotação de chaves, aplicação da retenção) é responsabilidade das equipes de segurança e de governança de dados. Na maioria das organizações, os processos de governança da equipe de segurança se estendem aos sistemas de produção e não alcançam a infraestrutura de backup gerenciada pelas equipes de operações, o que cria um ambiente de produção governado e um ambiente de backup sem governança para os mesmos dados subjacentes.

Eliminar essa lacuna exige incluir explicitamente o armazenamento de backups nos programas de governança de segurança de dados, estendendo a periodicidade das revisões de acesso, a gestão de chaves de criptografia e a varredura de segurança à infraestrutura de backup, com a mesma responsabilização organizacional dos sistemas de produção. Essa conexão normalmente não existe, e estabelecê-la exige tanto mudanças de processo quanto alinhamento organizacional entre as equipes de operações e de segurança, algo que a maioria dos programas de TPRM não consegue impulsionar de fora, mas pode tornar visível por meio de perguntas de avaliação direcionadas.

• Perguntar especificamente sobre a periodicidade de revisão do controle de acesso aos backups (quando o acesso ao armazenamento de backups foi revisado pela última vez), e não apenas se o acesso de produção é revisado
• Perguntar sobre a rotação das chaves de criptografia dos dados de backup, separada da rotação das chaves de produção e aplicada aos backups históricos
• Exigir a aplicação automatizada da retenção: exclusão acionada pela política de retenção, e não por processo manual
• Perguntar sobre a varredura de segurança do armazenamento de backups: detecção de configurações incorretas aplicada ao armazenamento de backups em um cronograma regular
• Incluir a infraestrutura de backup no escopo da avaliação de segurança, sem excluí-la como infraestrutura operacional

Se você faz parte de uma equipe pequena

Faça aos seus fornecedores de maior risco duas perguntas que a maioria das avaliações nunca alcança. Primeira: quando a política de acesso ao armazenamento de backups foi revisada pela última vez, e a configuração de acesso atual reflete os requisitos atuais das funções? Especificamente, algum ex-funcionário ou função descontinuada tem acesso ao armazenamento de backups? Segunda: as chaves de criptografia dos backups são rotacionadas no mesmo cronograma que as chaves de criptografia de produção, ou os backups históricos mantêm as chaves usadas quando foram criados? Essas duas perguntas revelam o desvio no controle de acesso e as lacunas na gestão de chaves que produzem cenários de violação de backups.

• Perguntar quando as políticas de acesso ao armazenamento de backups foram revisadas pela última vez
• Perguntar se ex-funcionários ou funções descontinuadas têm acesso ao armazenamento de backups
• Perguntar sobre a rotação das chaves de criptografia dos backups históricos
• Perguntar se a varredura de configurações incorretas abrange o armazenamento de backups

O que exigir

Pergunte diretamente:

"Quando os controles de acesso ao seu armazenamento de backups foram revisados pela última vez? E alguma função de IAM, conta de serviço ou usuário com acesso aos backups pertence a ex-funcionários ou a funções descontinuadas?"

"As chaves de criptografia dos backups são rotacionadas no mesmo cronograma que as chaves de criptografia de produção? E, quando as chaves de produção são rotacionadas, os backups históricos são criptografados novamente com as novas chaves ou mantêm as chaves originais?"

"O seu armazenamento de backups está incluído nas varreduras regulares de configurações incorretas? E qual é a constatação mais recente relacionada às permissões de acesso ao armazenamento de backups?"

O que esperar como evidência

• Histórico de revisões de acesso aos backups: quando foi a última revisão e qual é o conjunto atual de pessoas com acesso
• Ciclo de vida das chaves de criptografia dos backups: cronograma de rotação e política de nova criptografia dos backups históricos
• Histórico de varreduras de segurança do armazenamento de backups: varredura mais recente e eventuais constatações
• Confirmação da aplicação automatizada da retenção

Um fornecedor que responde à pergunta sobre revisão de acesso aos backups com 'nossos backups são criptografados' apenas confirmou de novo a criptografia. Pergunte especificamente quando as políticas dos buckets de armazenamento, ou configurações de acesso equivalentes, foram revisadas pela última vez em relação aos requisitos atuais das funções. A criptografia protege o que está dentro do bucket. A política de acesso determina quem pode abri-lo.

Como comprovar

A segurança dos dados de backup é tratada no Artigo 32 do GDPR, como parte das medidas técnicas e organizacionais adequadas, nos Requisitos 9 e 10 do PCI-DSS, quanto à segurança das mídias de backup, e nas salvaguardas técnicas do HIPAA para backup de PHI. Demonstrar diligência devida exige evidências de que a governança de segurança dos backups foi avaliada além da capacidade operacional de backup.

• Registros de avaliação de fornecedores que documentam as perguntas sobre controle de acesso, gestão de chaves e governança de retenção dos backups
• Evidências de varredura de segurança do armazenamento de backups
• Histórico de revisões de acesso à infraestrutura de backup
• Confirmação da automação da aplicação da retenção

Principal conclusão

O backup são os seus dados de produção. Ele tem a mesma sensibilidade, a mesma classificação regulatória e as mesmas implicações de notificação de violação. O que lhe falta é a governança contínua que os dados de produção recebem: as revisões de acesso, as rotações de chaves, as auditorias de permissões e as varreduras de segurança que mantêm os controles de produção atualizados. Um backup criado há dezoito meses tem os controles de acesso, as chaves de criptografia e as políticas de armazenamento que eram adequados dezoito meses atrás. Nada os atualizou desde então. O cenário de violação do banco de dados de produção exige comprometer uma infraestrutura bem governada. O cenário de violação do backup exige encontrar o bucket de armazenamento configurado por um engenheiro que saiu há seis meses e cujas políticas nunca foram revisadas. Os dados são os mesmos. A governança não.