No cen\u00e1rio atual de amea\u00e7as, o ransomware evoluiu de uma criptografia oportunista para campanhas de extors\u00e3o m\u00faltipla altamente direcionadas. Amea\u00e7as Persistentes Avan\u00e7adas (APTs) e sindicatos de ransomware agora buscam ativamente por infraestrutura de backup e arquivos de banco de dados durante seu tempo de perman\u00eancia no sistema. Se um invasor comprometer seu banco de dados principal e, simultaneamente, excluir ou criptografar seus reposit\u00f3rios de backup, sua organiza\u00e7\u00e3o enfrentar\u00e1 uma perda catastr\u00f3fica de dados.<\/p>\n
Para Administradores de Banco de Dados (DBAs) e engenheiros de DevOps, a estrat\u00e9gia tradicional de backup 3-2-1 n\u00e3o \u00e9 mais suficiente. Para garantir a sobreviv\u00eancia dos dados, as equipes de infraestrutura devem adotar a regra 3-2-1-1, onde o “1” final representa o armazenamento imut\u00e1vel<\/strong>.<\/p>\n Este artigo fornece uma an\u00e1lise t\u00e9cnica abrangente sobre como arquitetar, implementar e gerenciar o armazenamento imut\u00e1vel para arquivos de banco de dados, a fim de garantir uma resili\u00eancia absoluta contra ransomware.<\/p>\n O armazenamento imut\u00e1vel baseia-se em uma arquitetura WORM (Write-Once-Read-Many – Gravar uma vez, ler muitas). Uma vez que os dados s\u00e3o gravados em um destino imut\u00e1vel, eles n\u00e3o podem ser modificados, criptografados ou exclu\u00eddos por nenhum usu\u00e1rio \u2014 incluindo administradores com privil\u00e9gios de root ou contas de servi\u00e7o comprometidas \u2014 at\u00e9 que um bloqueio temporal matematicamente imposto expire.<\/p>\n Ao implementar a imutabilidade, particularmente em armazenamento de objetos em nuvem como AWS S3, Azure Blob ou SANs locais compat\u00edveis com S3, voc\u00ea deve entender a distin\u00e7\u00e3o entre os modos de reten\u00e7\u00e3o:<\/p>\n Uma arquitetura robusta de arquivamento de banco de dados separa as opera\u00e7\u00f5es ativas do banco de dados da camada de arquivo imut\u00e1vel. Voc\u00ea n\u00e3o pode aplicar imutabilidade a arquivos de banco de dados ativos (como Em vez disso, a imutabilidade \u00e9 aplicada a: Voc\u00ea pode implementar armazenamento imut\u00e1vel em diferentes camadas de infraestrutura: Para proteger dumps de banco de dados e logs de transa\u00e7\u00e3o na AWS, voc\u00ea deve habilitar o Object Lock no momento da cria\u00e7\u00e3o do bucket.<\/p>\n Primeiro, crie o bucket com o Object Lock habilitado:<\/p>\n Em seguida, configure a pol\u00edtica de reten\u00e7\u00e3o padr\u00e3o. Para arquivos de banco de dados, um bloqueio de conformidade de 30 dias \u00e9 uma base padr\u00e3o, garantindo que voc\u00ea tenha um m\u00eas de backups inalter\u00e1veis.<\/p>\n Quando seu script ou agente de backup de banco de dados envia um arquivo para este bucket, o S3 calcula automaticamente a Se voc\u00ea estiver arquivando bancos de dados em um servidor de backup Linux local, pode obter uma pseudo-imutabilidade usando o comando Usando Nota: Embora o Usando Snapshots ZFS:<\/strong> Para obter a Recupera\u00e7\u00e3o para um Ponto no Tempo (PITR), voc\u00ea deve arquivar continuamente os logs de transa\u00e7\u00e3o em seu armazenamento imut\u00e1vel.<\/p>\n O Em seu Considera\u00e7\u00e3o Crucial:<\/em> Se o seu bucket S3 imp\u00f5e um bloqueio de Conformidade de 30 dias, mas o O SQL Server suporta backups nativos diretamente para armazenamento de objetos compat\u00edvel com S3. Voc\u00ea pode configurar um trabalho do SQL Server Agent para gravar arquivos Gerenciar flags de reten\u00e7\u00e3o imut\u00e1vel, rotacionar chaves de acesso e garantir a sincroniza\u00e7\u00e3o entre pol\u00edticas de reten\u00e7\u00e3o de banco de dados e bloqueios de armazenamento via scripts personalizados \u00e9 altamente propenso a erros. Uma \u00fanica configura\u00e7\u00e3o incorreta em um cron job ou chamada de API pode deixar seus arquivos expostos ou resultar em custos de armazenamento em nuvem disparados devido a objetos bloqueados \u00f3rf\u00e3os.<\/p>\n Plataformas de backup corporativas como o CloudSave simplificam essa arquitetura. O CloudSave integra-se nativamente ao AWS S3 Object Lock, Azure Blob Immutable Storage e APIs locais compat\u00edveis com S3.<\/p>\n Ao configurar um plano de backup de banco de dados no CloudSave: Para garantir que sua arquitetura imut\u00e1vel seja verdadeiramente resiliente, siga estas melhores pr\u00e1ticas de engenharia de sistemas:<\/p>\n Bloqueios imut\u00e1veis est\u00e3o matematicamente vinculados a carimbos de data\/hora. Se o servi\u00e7o NTP (Network Time Protocol) em seu array de armazenamento ou servidor de backup for comprometido ou sofrer desvio, isso pode causar a expira\u00e7\u00e3o prematura dos bloqueios ou impedir que eles expirem. Garanta que sua infraestrutura de armazenamento use fontes NTP autenticadas e redundantes.<\/p>\n As credenciais usadas para gravar no bucket imut\u00e1vel devem ter apenas permiss\u00f5es Exemplo de uma pol\u00edtica IAM de privil\u00e9gio m\u00ednimo para um agente de backup de banco de dados:<\/p>\n N\u00e3o defina bloqueios de conformidade por per\u00edodos excessivamente longos (por exemplo, 7 anos para conformidade) em sua camada principal de recupera\u00e7\u00e3o r\u00e1pida. Bancos de dados geram quantidades massivas de dados de log de transa\u00e7\u00e3o\/WAL. Bloquear esses dados por anos resultar\u00e1 em um crescimento exponencial dos custos de armazenamento. A imutabilidade garante que os dados n\u00e3o possam ser exclu\u00eddos, mas n\u00e3o garante que os dados estejam livres de corrup\u00e7\u00e3o l\u00f3gica. Voc\u00ea deve automatizar a restaura\u00e7\u00e3o de seus arquivos de banco de dados imut\u00e1veis em uma VPC ou VLAN isolada (air-gapped). Execute A defesa contra ransomware \u00e9 um exerc\u00edcio de assumir a viola\u00e7\u00e3o. No momento em que um alerta \u00e9 disparado em seu SIEM, os agentes de amea\u00e7as provavelmente j\u00e1 tentaram comprometer sua infraestrutura de backup. Ao arquitetar seus arquivos de banco de dados usando armazenamento imut\u00e1vel no Modo de Conformidade, voc\u00ea retira dos invasores sua principal alavanca. Esteja voc\u00ea utilizando APIs nativas de nuvem, bloqueios ZFS ou uma plataforma de orquestra\u00e7\u00e3o corporativa como o CloudSave, implementar armazenamento WORM n\u00e3o \u00e9 mais opcional \u2014 \u00e9 um pilar obrigat\u00f3rio da administra\u00e7\u00e3o moderna de banco de dados e recupera\u00e7\u00e3o de desastres.<\/p>\n","protected":false},"excerpt":{"rendered":" ** Learn how to protect enterprise database archives from ransomware using immutable storage. Discover technical implementation steps for AWS S3 Object Lock, ZFS, PostgreSQL, and SQL Server.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"Immutable Database Storage to Defeat Ransomware","rank_math_description":"** Learn how to protect enterprise database archives from ransomware using immutable storage. Discover technical implementation steps for AWS S3 Object Lock, ZFS, PostgreSQL, and SQL Server.","rank_math_focus_keyword":"immutable database storage","footnotes":""},"categories":[615],"tags":[4715,4716,4717,1339,4718,4719],"class_list":["post-6393","post","type-post","status-publish","format-standard","hentry","category-database-backup","tag-3-2-1-1-backup","tag-data-survivability","tag-database-archives","tag-enterprise-backup","tag-immutable-storage","tag-ransomware-protection"],"yoast_head":"\nA Mec\u00e2nica do Armazenamento Imut\u00e1vel<\/h2>\n
Modo de Conformidade vs. Modo de Governan\u00e7a<\/h3>\n
\n
s3:BypassGovernanceRetention<\/code>) podem ignorar o bloqueio. Isso \u00e9 \u00fatil para testes, mas insuficiente para prote\u00e7\u00e3o contra ransomware<\/strong>, j\u00e1 que os invasores frequentemente elevam privil\u00e9gios para administrador de dom\u00ednio ou root.<\/li>\nArquitetando um Pipeline de Backup Imut\u00e1vel<\/h2>\n
.mdf<\/code>\/.ldf<\/code> no SQL Server ou o diret\u00f3rio pg_data<\/code> no PostgreSQL) porque os bancos de dados exigem acesso constante de leitura\/grava\u00e7\u00e3o.<\/p>\n
\n1. Arquivos de Backup Completo e Diferencial:<\/strong> Os snapshots de base do banco de dados.
\n2. Logs de Transa\u00e7\u00e3o \/ Arquivos WAL:<\/strong> O fluxo cont\u00ednuo de altera\u00e7\u00f5es no banco de dados necess\u00e1rio para a Recupera\u00e7\u00e3o para um Ponto no Tempo (PITR).<\/p>\nDestinos de Armazenamento para Imutabilidade<\/h3>\n
\n* Armazenamento de Objetos em Nuvem:<\/strong> AWS S3 Object Lock, Azure Blob Immutable Storage, Pol\u00edticas de Reten\u00e7\u00e3o do Google Cloud Storage.
\n* Armazenamento de Objetos Local (On-Premises):<\/strong> MinIO, Cloudian ou Pure Storage FlashBlade com suporte a APIs S3 Object Lock.
\n* Armazenamento em Bloco\/Arquivo:<\/strong> ZFS com snapshots somente leitura e administra\u00e7\u00e3o delegada, ou atributos de arquivo Linux.<\/p>\nImplementando Armazenamento Imut\u00e1vel: Passo a Passo T\u00e9cnico<\/h2>\n
1. Armazenamento de Objetos em Nuvem: AWS S3 Object Lock<\/h3>\n
aws s3api create-bucket \n --bucket prod-db-archive-immutable \n --region us-east-1 \n --object-lock-enabled-for-bucket\n<\/code><\/pre>\naws s3api put-object-lock-configuration \n --bucket prod-db-archive-immutable \n --object-lock-configuration '{\n "ObjectLockEnabled": "Enabled",\n "Rule": {\n "DefaultRetention": {\n "Mode": "COMPLIANCE",\n "Days": 30\n }\n }\n }'\n<\/code><\/pre>\nRetain Until Date<\/code> (Data de Reten\u00e7\u00e3o) com base no carimbo de data\/hora de cria\u00e7\u00e3o do objeto mais 30 dias.<\/p>\n2. Imutabilidade Local: ZFS e Atributos Linux<\/h3>\n
chattr<\/code>, ou verdadeira imutabilidade usando snapshots ZFS.<\/p>\nchattr<\/code> no Linux:<\/strong>
\nA flag +i<\/code> (imut\u00e1vel) impede a modifica\u00e7\u00e3o, exclus\u00e3o ou renomea\u00e7\u00e3o de arquivos.<\/p>\n# Dump do banco de dados\npg_dump -U postgres -Fc mydb > \/backups\/mydb_$(date +%F).dump\n\n# Tornar o backup imut\u00e1vel\nsudo chattr +i \/backups\/mydb_$(date +%F).dump\n\n# Verificar o atributo\nlsattr \/backups\/mydb_$(date +%F).dump\n# Sa\u00edda: ----i---------e------- \/backups\/mydb_2023-10-27.dump\n<\/code><\/pre>\nchattr<\/code> impe\u00e7a scripts b\u00e1sicos de ransomware, um invasor sofisticado com acesso root pode simplesmente executar chattr -i<\/code>. Portanto, isso deve ser combinado com RBAC rigoroso e redes de backup isoladas.<\/em><\/p>\n
\nO ZFS oferece uma defesa muito mais forte. Ao tirar um snapshot e colocar um “hold” (bloqueio) nele, voc\u00ea impede que o snapshot seja destru\u00eddo.<\/p>\n# Tirar um snapshot do dataset de backup\nzfs snapshot tank\/db_backups@archive_$(date +%F)\n\n# Colocar um bloqueio no snapshot para impedir a exclus\u00e3o\nzfs hold keep_30_days tank\/db_backups@archive_$(date +%F)\n\n# Nem mesmo o root pode destruir este snapshot sem liberar o bloqueio\nzfs destroy tank\/db_backups@archive_$(date +%F)\n# Sa\u00edda: cannot destroy 'tank\/db_backups@archive_...': dataset is busy\n<\/code><\/pre>\nEstrat\u00e9gias de Arquivamento Espec\u00edficas para Banco de Dados<\/h2>\n
Arquivamento de WAL do PostgreSQL com pgBackRest<\/h3>\n
pgBackRest<\/code> \u00e9 uma ferramenta de backup altamente confi\u00e1vel para PostgreSQL que suporta nativamente armazenamento compat\u00edvel com S3. Para proteger seus Write-Ahead Logs (WAL), configure o pgBackRest<\/code> para enviar os dados diretamente para seu bucket S3 imut\u00e1vel.<\/p>\npgbackrest.conf<\/code>:<\/p>\n[global]\nrepo1-type=s3\nrepo1-s3-bucket=prod-db-archive-immutable\nrepo1-s3-region=us-east-1\nrepo1-s3-endpoint=s3.amazonaws.com\nrepo1-s3-key=AKIAIOSFODNN7EXAMPLE\nrepo1-s3-key-secret=wJalrXUtnFEMI\/K7MDENG\/bPxRfiCYEXAMPLEKEY\n\n# Garanta que a reten\u00e7\u00e3o esteja alinhada com sua configura\u00e7\u00e3o de S3 Object Lock\nrepo1-retention-full=2\nrepo1-retention-archive=2\n\n[prod_cluster]\npg1-path=\/var\/lib\/postgresql\/14\/main\n<\/code><\/pre>\npgBackRest<\/code> tenta expirar e excluir arquivos WAL ap\u00f3s 14 dias com base em repo1-retention-archive<\/code>, as chamadas de API de exclus\u00e3o falhar\u00e3o. Voc\u00ea deve garantir que a pol\u00edtica de reten\u00e7\u00e3o do seu software de backup seja maior ou igual ao bloqueio imut\u00e1vel no n\u00edvel de armazenamento.<\/p>\nMicrosoft SQL Server: Backup para URL<\/h3>\n
.bak<\/code> e .trn<\/code> diretamente em um bucket imut\u00e1vel.<\/p>\nCREATE CREDENTIAL [s3:\/\/prod-db-archive-immutable.s3.us-east-1.amazonaws.com]\nWITH IDENTITY = 'S3 Access Key',\nSECRET = 'AccessKeyID:SecretAccessKey';\nGO\n\nBACKUP DATABASE [ProductionDB]\nTO URL = 's3:\/\/prod-db-archive-immutable.s3.us-east-1.amazonaws.com\/ProductionDB_Full.bak'\nWITH FORMAT, COMPRESSION, STATS = 10;\nGO\n<\/code><\/pre>\nAutomatizando e Orquestrando com CloudSave<\/h2>\n
\n1. A plataforma lida automaticamente com a quiesc\u00eancia do VSS (Volume Shadow Copy Service) para SQL Server ou a API pg_start_backup()<\/code> para PostgreSQL.
\n2. Ele transmite os dados de backup desduplicados e criptografados diretamente para o destino de armazenamento.
\n3. O CloudSave aplica dinamicamente as chamadas de API WORM (por exemplo, PutObjectRetention<\/code>) por objeto, alinhando perfeitamente a dura\u00e7\u00e3o do bloqueio de armazenamento com o cronograma de reten\u00e7\u00e3o definido pela pol\u00edtica.
\n4. Se um invasor comprometer o console de gerenciamento do CloudSave, ele ainda n\u00e3o poder\u00e1 excluir os backups, pois o bloqueio de conformidade \u00e9 imposto pela infraestrutura de armazenamento subjacente, n\u00e3o pelo software de backup.<\/p>\nMelhores Pr\u00e1ticas para Arquivos de Banco de Dados Imut\u00e1veis<\/h2>\n
1. Sincroniza\u00e7\u00e3o NTP Rigorosa<\/h3>\n
2. Isole Fun\u00e7\u00f5es e Credenciais IAM<\/h3>\n
s3:PutObject<\/code> e s3:PutObjectRetention<\/code>. Elas nunca<\/strong> devem ter permiss\u00f5es s3:DeleteObject<\/code> ou s3:PutBucketObjectLockConfiguration<\/code>.<\/p>\n{\n "Version": "2012-10-17",\n "Statement": [\n {\n "Effect": "Allow",\n "Action": [\n "s3:PutObject",\n "s3:GetBucketObjectLockConfiguration"\n ],\n "Resource": [\n "arn:aws:s3:::prod-db-archive-immutable",\n "arn:aws:s3:::prod-db-archive-immutable\/*"\n ]\n }\n ]\n}\n<\/code><\/pre>\n3. Dimensionamento do Per\u00edodo de Reten\u00e7\u00e3o<\/h3>\n
\nEm vez disso, use uma abordagem em camadas:
\n* Camada de Recupera\u00e7\u00e3o Operacional:<\/strong> 14 a 30 dias de reten\u00e7\u00e3o imut\u00e1vel para backups completos e logs.
\n* Camada de Arquivamento de Longo Prazo:<\/strong> Backups completos mensais movidos para Glacier\/Deep Archive com Vault Lock por 1 a 7 anos.<\/p>\n4. Testes Regulares de Recupera\u00e7\u00e3o em VPCs Isoladas (Air-Gapped)<\/h3>\n
DBCC CHECKDB<\/code> (SQL Server) ou pg_amcheck<\/code> (PostgreSQL) nos dados restaurados para verificar a integridade estrutural.<\/p>\nConclus\u00e3o<\/h2>\n