Riscos da replicação de dados

A avaliação de TPRM de um fornecedor de tecnologia financeira confirmou uma segurança de banco de dados robusta: criptografia AES-256 em repouso, controles de acesso baseados em funções, registro de auditoria habilitado e revisões trimestrais de acesso concluídas. A avaliação era precisa para o banco de dados de produção. O que ela não captou foi que os mesmos dados financeiros dos clientes existiam em um banco de dados em hot standby com controles de acesso idênticos, em três instâncias regionais de backup restauradas semanalmente para testes de DR, em um sandbox de desenvolvedor preenchido com dados de produção para testes de integração, em um ambiente de QA atualizado mensalmente a partir da produção, em um data warehouse de análise com um job de replicação noturno e em uma réplica de compartilhamento de dados com parceiros usada em uma integração de relatórios. O banco de dados principal tinha sete cópias dependentes. Cada uma havia sido provisionada em momentos diferentes, por equipes diferentes. Cada uma tinha sua própria configuração de controle de acesso, ou, no caso do sandbox do desenvolvedor, nunca tivera controles de acesso configurados porque deveria ser 'temporário'. O sandbox era temporário havia três anos.

O que é, de fato, o problema do risco de replicação de dados?

A replicação de dados é a criação de cópias de dados para fins operacionais, de disponibilidade e analíticos: hot standbys que garantem a continuidade se o sistema principal falhar, cópias de backup que permitem a recuperação após eventos de perda de dados, ambientes de DR que espelham a produção para testes de failover, ambientes de desenvolvimento e teste preenchidos com dados realistas, réplicas de análise que alimentam sistemas de relatórios e compartilhamentos de dados com parceiros que viabilizam casos de uso de integração. A replicação é uma prática arquitetural fundamental que proporciona a resiliência, o desempenho e a funcionalidade que as aplicações corporativas modernas exigem. Ela também é o mecanismo pelo qual um único conjunto de dados governado se torna muitas cópias com governança variável.

A lacuna de governança decorre da assimetria de ciclo de vida entre replicação e governança. Os dados são replicados por processos automatizados: jobs de backup executados em horários programados, configurações de replicação que propagam alterações continuamente, scripts de provisionamento de ambientes que copiam dados de produção sob demanda. Cada evento de replicação cria uma nova cópia dos dados com os controles de acesso e as configurações de segurança aplicados no momento do provisionamento. Essas configurações não são herdadas automaticamente do sistema de origem, não são atualizadas automaticamente quando a governança do sistema de origem muda e não são excluídas automaticamente quando os dados deixam de ser necessários. Os controles de acesso do banco de dados principal são mantidos com cuidado. A cópia criada para um desenvolvedor há três anos tem os controles de acesso aplicados no provisionamento, e nada mudou desde então.

O problema de escala é o que torna o risco de replicação realmente difícil de governar. Em um ambiente moderno de aplicações corporativas, o número de cópias de dados sensíveis pode ser grande, não porque alguém decidiu criar tantas cópias, mas porque cada necessidade operacional independente gerou uma cópia por meio de seu próprio processo de provisionamento. Os testes de DR criam cópias. Os ambientes de desenvolvimento criam cópias. Os testes de desempenho criam cópias. Os fluxos de análise criam cópias. As integrações com parceiros criam cópias. Cada cópia é uma superfície de ataque separada, com seus próprios controles de acesso, sua própria governança de retenção e sua própria exposição em caso de comprometimento. O banco de dados principal pode ser o alvo mais visível. As cópias não revisadas são as mais acessíveis.

O risco de replicação de dados se concentra em cinco padrões específicos de falha de governança:

• Ambientes de desenvolvimento e teste com dados de produção: sandboxes de desenvolvedores, ambientes de QA e instâncias de testes de integração preenchidos com dados reais de clientes e governados por controles de acesso pensados para a conveniência dos desenvolvedores, e não pelos padrões de segurança de produção
• Desvio dos controles de acesso das cópias de backup: instâncias de backup e cópias restauradas provisionadas com controles de acesso que estavam corretos na criação, mas se afastaram dos padrões de segurança atuais à medida que os controles do sistema principal evoluíram
• Proliferação de réplicas de análise: bancos de dados de relatórios, snapshots de data warehouse e conexões de ferramentas de BI que criam réplicas de dados sensíveis governadas pelos controles de acesso da equipe de análise, e não pelos padrões de segurança de dados
• Persistência de compartilhamentos de dados com parceiros: dados compartilhados com parceiros de integração que permanecem em réplicas acessíveis ao parceiro depois que o caso de uso da integração mudou ou terminou
• Lacuna de segurança no ambiente de DR: ambientes de recuperação de desastres que espelham os dados de produção, mas são testados com pouca frequência, de modo que seus controles de acesso podem não refletir os padrões atuais de produção e podem ter acumulado acessos não autorizados ao longo do tempo

Por que isso importa

O risco de replicação de dados importa para TPRM porque a avaliação de segurança do fornecedor normalmente cobre o sistema principal: o banco de dados que o fornecedor descreve em sua documentação de segurança, que a avaliação SOC 2 cobre e que o processo de revisão de acessos mantém. As cópias replicadas que existem em todo o ambiente do fornecedor para fins operacionais raramente passam por uma avaliação equivalente. Quando ocorre uma violação por meio de uma dessas cópias (o sandbox do desenvolvedor, a réplica de análise não revisada, a instância de backup com controles de acesso desatualizados), o escopo da violação inclui todos os dados daquela cópia, que muitas vezes equivalem ao conjunto completo de dados de produção.

A investigação da violação mostrará que o banco de dados principal estava bem protegido. O atacante não violou o banco de dados principal. Ele violou a réplica de análise provisionada dezoito meses antes com credenciais de leitura que nunca foram trocadas nem revisadas. O SOC 2 do fornecedor cobria o sistema principal. A réplica de análise foi provisionada pela equipe de engenharia de dados e nunca esteve no escopo do SOC 2. Os dados do cliente estavam em ambos. A avaliação cobriu um. A violação expôs o outro.

A dimensão dos direitos dos titulares dos dados é igualmente relevante. O direito do titular à eliminação exige a exclusão de seus dados de todas as cópias no ambiente do fornecedor: o banco de dados principal e todas as réplicas. Um fornecedor que não consegue enumerar suas réplicas não consegue cumprir integralmente a eliminação. Um fornecedor que atendeu a um pedido de eliminação excluindo os dados do banco de dados principal, sem excluí-los da réplica de análise, das instâncias de backup e dos ambientes de desenvolvimento, cumpriu a obrigação apenas parcialmente e deixou cópias dos dados excluídos intactas em sistemas que estavam fora do escopo do processo de exclusão.

Onde a maioria das equipes erra

A falha mais disseminada é avaliar a segurança do banco de dados sem perguntar quantos bancos de dados mantêm os mesmos dados. Uma avaliação de segurança que cobre com precisão o banco de dados de produção, mas não pergunta sobre réplicas, backups, ambientes de desenvolvimento e cópias de análise, avaliou um único nó de um panorama de dados com vários nós. O relatório SOC 2 que cobre os sistemas de produção pode excluir explicitamente ambientes de desenvolvimento, instâncias de sandbox e réplicas de parceiros, exclusões que são padrão na definição do escopo do SOC 2, mas relevantes na avaliação de segurança de dados.

A segunda falha é tratar a segurança dos ambientes de desenvolvimento e teste como uma questão de operações de desenvolvimento, e não de segurança de dados. As equipes de desenvolvimento precisam de dados de teste realistas. Os controles de segurança dos ambientes de desenvolvimento costumam ser menos restritivos do que os de produção, porque a velocidade de desenvolvimento é o requisito principal. Quando dados de clientes de produção alimentam os ambientes de desenvolvimento, que é a abordagem mais conveniente para testes realistas, a segurança menos restritiva do ambiente de desenvolvimento passa a ser a postura de segurança efetiva de uma cópia completa do conjunto de dados de produção. A maioria das avaliações de TPRM nunca pergunta se os ambientes de desenvolvimento contêm dados de clientes de produção.

• Avaliar o banco de dados principal sem enumerar as réplicas: avaliações SOC 2 e de segurança que cobrem os sistemas de produção, enquanto as cópias de desenvolvimento, backup e análise ficam fora do escopo
• Segurança de dados em ambientes de desenvolvimento não avaliada: dados de produção de clientes em sandboxes de desenvolvedores e ambientes de QA regidos por controles de acesso de desenvolvimento
• Nenhum inventário de réplicas mantido: fornecedores que não conseguem enumerar todos os locais em que os dados do cliente existem de forma replicada não conseguem governar essas réplicas
• Controles de acesso das réplicas de análise não revisados: réplicas de data warehouse e de BI provisionadas e governadas pelas equipes de análise sem supervisão de segurança de dados
• Pedidos de eliminação restritos ao banco de dados principal: exclusão de dados executada nos sistemas principais sem acionar a exclusão nas réplicas

Como é uma boa prática

Programas maduros de governança da replicação de dados de fornecedores mantêm um inventário atualizado de todos os sistemas em que os dados do cliente existem de forma replicada, aplicam controles de acesso e padrões de segurança consistentes nos sistemas principais e nas réplicas, usam dados sintéticos ou anonimizados nos ambientes de desenvolvimento e teste em vez de cópias de produção e incluem a governança das réplicas nos processos de atendimento aos direitos dos titulares dos dados.

• Inventário de réplicas mantido: todos os sistemas que mantêm dados do cliente de forma replicada documentados com responsável, controles de acesso e situação de retenção
• Dados sintéticos ou anonimizados nos ambientes de desenvolvimento: desenvolvimento e testes alimentados com dados realistas, mas não identificáveis, em vez de registros de clientes de produção
• Padrões de controle de acesso consistentes entre réplicas: alterações nos controles de acesso do sistema principal propagadas aos sistemas de réplica em uma periodicidade definida
• Inclusão das réplicas nos processos de eliminação e exclusão: atendimento aos direitos dos titulares dos dados e exclusão no offboarding do fornecedor abrangendo explicitamente todos os sistemas de réplica
• Revisão periódica dos acessos às réplicas: controles de acesso dos sistemas de réplica revisados na mesma periodicidade das revisões de acesso do sistema principal
• Classificação e governança das réplicas de análise: réplicas de data warehouse e de BI governadas por padrões de segurança de dados equivalentes à classificação dos dados de origem

Ferramentas

Gerenciar o risco de replicação de dados exige ferramentas de descoberta para enumerar as réplicas e ferramentas de mascaramento de dados para eliminar a necessidade de dados de produção nos ambientes de desenvolvimento.

Descoberta de dados: BigID, Varonis, Microsoft Purview

Plataformas de descoberta de dados varrem o ambiente de armazenamento de uma organização (bancos de dados, armazenamento em nuvem, sistemas de arquivos) para identificar onde determinados dados existem de forma replicada. Para profissionais de TPRM, perguntar se um fornecedor usa ferramentas de descoberta de dados para manter um inventário de todos os sistemas em que os dados do cliente existem é uma pergunta específica sobre capacidade que determina se a governança das réplicas se baseia em um inventário documentado ou na memória da organização.

Mascaramento de dados e dados sintéticos: Informatica, IBM InfoSphere Optim, Tonic.ai, Gretel.ai

Plataformas de mascaramento de dados transformam dados de produção em equivalentes realistas, mas não identificáveis, para uso em ambientes de desenvolvimento e teste, eliminando a exposição de dados de produção que faz da segurança do ambiente de desenvolvimento um risco de violação de dados. Tonic.ai e Gretel.ai geram dados sintéticos que preservam as propriedades estatísticas dos dados de produção sem conter informações pessoais reais. Para profissionais de TPRM, perguntar se o fornecedor usa dados sintéticos ou mascarados nos ambientes de desenvolvimento, em vez de cópias de produção, é a pergunta mais direta para a categoria de risco dos ambientes de desenvolvimento.

Monitoramento de atividade de banco de dados: Imperva, IBM Guardium

Plataformas de DAM monitoram a atividade de acesso em todas as instâncias de banco de dados, incluindo réplicas, backups e cópias de análise, fornecendo uma trilha unificada de auditoria de acesso em todo o panorama de replicação de dados. Para fornecedores com grande número de réplicas, o DAM oferece a cobertura de monitoramento que torna a governança das réplicas operacionalmente sustentável.

Desafios de governança

O desafio de governança da replicação de dados é a fragmentação da responsabilidade. Os bancos de dados de produção têm uma equipe definida que os gerencia e governa. A réplica de análise foi criada pela equipe de engenharia de dados. O sandbox do desenvolvedor foi provisionado pela equipe de plataforma. A instância de DR é gerenciada pela equipe de infraestrutura. Cada equipe aplicou os controles de segurança que faziam sentido do seu ponto de vista operacional, que podem ser muito menos restritivos do que os padrões de segurança aplicáveis aos dados de origem. Ninguém tem a responsabilidade integral pela questão de quantas cópias existem e se cada uma é governada adequadamente.

Fechar essa lacuna exige tratar a replicação de dados como um evento de governança de dados: cada criação de nova réplica deve acionar uma revisão de governança que aplique os controles adequados antes que a réplica seja usada. Trata-se de uma mudança de processo e de política tanto quanto de uma mudança técnica, e ela exige uma coordenação entre as equipes de segurança de dados, engenharia de dados e desenvolvimento que a maioria das organizações ainda não estabeleceu.

• Trate a criação de réplicas como um evento de governança de dados: o provisionamento de uma nova réplica aciona a revisão dos controles de acesso e a classificação antes do uso
• Exija dados sintéticos ou mascarados nos ambientes de desenvolvimento: eliminação dos dados de produção dos sandboxes de desenvolvedores como requisito de política
• Mantenha um inventário atualizado de réplicas: todos os sistemas que mantêm dados do cliente documentados e com responsável definido
• Inclua as réplicas na periodicidade de revisão de acessos: controles de acesso das réplicas revisados na mesma periodicidade dos controles do sistema principal
• Inclua as réplicas nos processos de exclusão e eliminação: direitos dos titulares dos dados e exclusão no offboarding abrangendo explicitamente todas as réplicas documentadas

Se você faz parte de uma equipe pequena

Faça aos fornecedores de maior risco uma pergunta que a maioria das avaliações nunca faz: quantas cópias dos dados que vocês tratam em nosso nome existem no seu ambiente, incluindo backups, ambientes de DR, instâncias de desenvolvimento e teste, réplicas de análise e compartilhamentos de dados com parceiros, e cada uma dessas cópias é governada com controles de segurança equivalentes aos do sistema principal de produção? A resposta a essa pergunta revelará mais sobre a exposição real dos dados do que qualquer avaliação de segurança de banco de dados focada apenas no sistema principal.

• Peça aos fornecedores que enumerem todos os sistemas em que os dados do cliente existem de forma replicada
• Pergunte especificamente se os ambientes de desenvolvimento e teste contêm dados de clientes de produção ou equivalentes sintéticos
• Inclua a governança das réplicas nos seus requisitos de exclusão no offboarding, e não apenas a exclusão do banco de dados principal
• Pergunte se o SOC 2 do fornecedor, ou cobertura de auditoria equivalente, inclui os sistemas de réplica ou se limita à produção

O que exigir

Pergunte diretamente:

"Quantas cópias dos dados que vocês tratam em nosso nome existem no seu ambiente, incluindo standbys de produção, backups, ambientes de DR, instâncias de desenvolvimento e teste, réplicas de análise e compartilhamentos de dados com parceiros?"

"Os seus ambientes de desenvolvimento e teste contêm dados reais de clientes vindos da produção, ou vocês usam dados sintéticos ou anonimizados para fins de desenvolvimento e teste?"

"Quando solicitamos a exclusão dos nossos dados, seja no encerramento do contrato, seja em resposta a um pedido de eliminação de um titular dos dados, o seu processo de exclusão abrange todos os sistemas de réplica ou apenas o banco de dados principal de produção?"

O que esperar como evidência

• Inventário de réplicas: todos os sistemas que mantêm dados do cliente, com o responsável e a situação dos controles de acesso
• Confirmação dos dados do ambiente de desenvolvimento: dados sintéticos/mascarados ou dados de produção com controles equivalentes
• Confirmação do escopo de exclusão: todas as réplicas incluídas nos processos de exclusão
• Cobertura da revisão de acessos: sistemas de réplica incluídos na revisão periódica de acessos

Um fornecedor que responde à pergunta sobre o inventário de réplicas com 'temos uma segurança de banco de dados robusta' descreveu de novo o sistema principal. Pergunte especificamente quantas instâncias de banco de dados contêm dados do cliente. O número é a resposta. A governança de cada instância é a pergunta seguinte.

Como comprovar

A governança da replicação de dados é tratada implicitamente nos princípios de limitação da conservação e de exatidão do GDPR, nos requisitos de mínimo necessário e de salvaguardas da HIPAA e nos critérios de disponibilidade e confidencialidade do SOC 2. Demonstrar a devida diligência exige evidências de que a governança das réplicas foi avaliada, e não apenas a segurança do banco de dados principal.

• Registros de avaliação de fornecedores que documentam as perguntas sobre o inventário de réplicas e as respostas
• Confirmação do tipo de dados do ambiente de desenvolvimento: sintéticos ou de produção
• Documentação do escopo de exclusão, incluindo as réplicas
• Revisão do escopo do SOC 2 que confirme se os sistemas de réplica estão incluídos ou excluídos

Principal conclusão

O banco de dados principal é a cópia que todos governam. As outras onze cópias são as que todos esquecem. Cada réplica é uma cópia completa do conjunto de dados de produção, com seus próprios controles de acesso, sua própria governança de retenção e sua própria exposição em caso de comprometimento. O sandbox do desenvolvedor que deveria ser temporário há três anos tem dados completos de produção e nenhuma revisão de acesso. A réplica de análise provisionada pela equipe de engenharia de dados tem os controles de acesso que o engenheiro de dados aplicou às duas da tarde do dia em que precisava colocar o painel de relatórios no ar. A segurança do banco de dados principal é excelente. Ela cobre uma cópia. Pergunte quantas cópias existem. Depois, pergunte quais delas foram revisadas.