Existe um padrão nos incidentes com banco de dados que atendemos ou acompanhamos. Quase nunca o ataque começa com uma técnica sofisticada. Começa com uma instância de PostgreSQL exposta na internet porque “era só para o teste”, com uma senha que virou permanente, com um usuário de aplicação que tem privilégio de superusuário, ou com um backup que ninguém restaurou desde a implantação.

O relatório Cost of a Data Breach da IBM (2024) mediu que o tempo médio para identificar e conter uma violação de dados chega a 258 dias. Ou seja, mais de oito meses. Nesse intervalo, a operação segue normal, os relatórios fecham e o incidente já aconteceu.

Na prática, saber como proteger um banco de dados é executar um conjunto pequeno de controles bem conhecidos e nunca implantados até o fim. Este é o checklist. Doze pontos, agrupados em quatro camadas, na ordem em que valem mais.

Cada item traz o que verificar e o que fazer. Vale dizer que, se você trabalha com PostgreSQL, MySQL/MariaDB ou SQL Server, os exemplos se aplicam com pequenas variações de sintaxe.

Camada 1: superfície de exposição (pontos 1 a 3)

A primeira camada elimina o acesso que não deveria existir. É também a que dá mais resultado por hora de trabalho: reduz o número de pessoas e máquinas capazes de sequer tentar uma conexão.

1. Tire o banco de dados da internet

Banco de dados não deve ter IP público. Ele fica em sub-rede privada, e o acesso chega por VPN, bastion host (uma máquina intermediária, endurecida, usada como único ponto de entrada) ou pela própria rede interna da aplicação.

O que fazer:

• Remova o IP público da instância. Se a aplicação está na mesma rede, ela não precisa dele.
• Configure o grupo de segurança / firewall para aceitar conexões apenas do IP ou do grupo da aplicação. Nunca 0.0.0.0/0.
• Se alguém da equipe precisa acessar de casa, a resposta é VPN, não liberação de IP.

Teste rápido: de uma rede externa, tente telnet seu-host 5432 (PostgreSQL) ou 3306 (MySQL). Se conecta, então você tem um problema hoje, não amanhã.

2. Feche a porta padrão e o acesso administrativo remoto

Trocar a porta padrão não é segurança de verdade, mas reduz ruído de varredura automatizada. O controle que importa, contudo, é impedir login administrativo remoto e restringir por origem no próprio banco.

O que fazer:

• PostgreSQL: revise o pg_hba.conf. Nenhuma linha com trust. Use scram-sha-256 como método de autenticação e restrinja por faixa de rede. Confirme que listen_addresses não é * sem necessidade.
• MySQL/MariaDB: ajuste bind-address para a interface interna. Remova usuários com host %: rode SELECT user, host FROM mysql.user; e trate qualquer % em conta administrativa como liberação global.
• SQL Server: desative o protocolo TCP para a instância se ela só atende localmente e restrinja o endpoint pelo firewall.
• Em todos: remova contas de demonstração, bancos de exemplo e o usuário anônimo.

3. Mantenha versão e patch em dia

Versão fora de suporte não recebe correção de segurança. Logo, rodar um banco em fim de vida é aceitar, por contrato, conviver com falhas conhecidas e publicadas.

O que fazer:

• Levante a versão de cada instância e a data de fim de suporte do fabricante.
• Defina janela mensal de manutenção. Patch de segurança não espera pelo próximo projeto.
• Assine o feed de vulnerabilidades do seu banco. CVEs de motores de banco costumam ter exploração pública em pouco tempo.
• Teste o patch em ambiente de homologação com uma cópia recente dos dados, que você tem, se o ponto 11 estiver feito.

Camada 2: identidade e privilégio (pontos 4 a 6)

A segunda camada trata de quem entra e do que consegue fazer depois de entrar. Credencial válida usada indevidamente é o vetor mais difícil de detectar, porque o sistema não distingue invasor de usuário.

4. Aplique privilégio mínimo, de verdade

Cada usuário e cada aplicação recebem apenas as permissões necessárias para a função. Por exemplo, aplicação que só lê recebe SELECT. Nenhuma aplicação, em hipótese alguma, precisa de superusuário.

O que fazer:

• Crie um usuário por aplicação, não um usuário compartilhado por todo o ambiente.
• Separe leitura de escrita. Relatórios, BI e integrações leem por uma conta somente-leitura.
• No PostgreSQL, bloqueie o schema público, que é aberto por padrão em versões mais antigas: REVOKE ALL ON SCHEMA public FROM PUBLIC;
• Revogue DROP, TRUNCATE e ALTER de contas de aplicação. Migração de schema roda com credencial própria, usada apenas no deploy.
• Rode um inventário: liste todas as roles e o que cada uma pode fazer. Quase sempre aparecem três ou quatro contas que ninguém sabe de onde vieram.

5. Exija acesso nominal e MFA para humanos

Pessoas acessam com contas individuais e autenticação multifator (MFA), nunca com credencial compartilhada. Afinal, sem identidade individual, o log de auditoria não serve para nada.

O que fazer:

• Elimine o uso direto de postgres, root ou sa por pessoas. Essas contas ficam para processo, com senha em cofre e uso registrado.
• Integre a autenticação ao diretório corporativo, quando houver, para que o desligamento de um funcionário revogue o acesso automaticamente.
• Exija MFA no bastion host e na VPN.
• Faça revisão trimestral de acessos. Uma hora de reunião, uma planilha, e a lista de ex-funcionários com credencial ativa deixa de existir.

6. Tire senha do código e rotacione segredos

Senha de banco não fica em repositório, em arquivo .env versionado, em variável de ambiente de imagem pública nem em planilha compartilhada. Ela fica em cofre de segredos, com rotação programada.

O que fazer:

• Migre as credenciais para um gerenciador de segredos. A aplicação busca a senha em tempo de execução.
• Varra o histórico do repositório: uma senha removida em um commit continua no histórico do Git. Portanto, se apareceu lá, considere-a comprometida e troque.
• Defina rotação: 90 dias para credenciais de aplicação é um ponto de partida razoável.
• Chaves de API e tokens de integração seguem a mesma regra, com prazo de expiração.

Camada 3: o dado em si (pontos 7 a 9)

A terceira camada assume que alguém vai passar pelas duas primeiras. Trata-se, então, de tornar o dado inútil, ilegível ou inalcançável para quem chegou até ele.

7. Criptografe em repouso e em trânsito

O dado é criptografado no disco (com TDE, transparent data encryption, ou criptografia no nível do volume) e durante o tráfego pela rede (TLS 1.2 ou superior, obrigatório e não opcional).

O que fazer:

• Ative a criptografia de volume ou o TDE do motor. Isso protege contra roubo de disco e descarte inadequado de hardware.
• Force TLS nas conexões. MySQL: require_secure_transport = ON. PostgreSQL: ssl = on e hostssl no pg_hba.conf, sem linha host equivalente. Conexão sem TLS deve ser recusada, não apenas desencorajada.
• Criptografe também o arquivo de backup. Cópia em claro num bucket é o mesmo dado, com menos vigilância.
• Defina quem guarda a chave. Chave gerenciada pelo cliente em um KMS (key management service, serviço que armazena e controla o uso de chaves) dá controle de revogação e rotação.

8. Trate dado sensível como dado sensível

Nem todo dado tem o mesmo peso. CPF, dados de saúde, dados financeiros e credenciais, por exemplo, exigem controles adicionais. Vale lembrar que a LGPD (Lei nº 13.709/2018) responsabiliza a empresa por essa distinção.

O que fazer:

• Classifique as tabelas e colunas que contêm dado pessoal e dado pessoal sensível. Sem inventário, não existe conformidade.
• Nunca use dump de produção em homologação sem mascarar. É a falha mais comum e a mais fácil de corrigir: um script de anonimização no pipeline de refresh resolve.
• Aplique minimização: se o sistema não precisa do CPF completo para funcionar, guarde o hash ou os últimos dígitos.
• Defina descarte. Dado retido além da finalidade é risco sem contrapartida.

9. Blinde a camada de aplicação contra injeção

A maior parte dos vazamentos de banco não passa pelo banco: passa pela aplicação. A injeção de SQL segue listada entre os principais riscos de aplicações web pelo OWASP Top 10 (2021, categoria A03).

O que fazer:

• Use prepared statements e consultas parametrizadas em todos os pontos. Concatenação de string com entrada de usuário é proibida, sem exceção de “esse é interno”.
• Valide entrada por lista de permissão, não por lista de bloqueio.
• Configure mensagens de erro genéricas em produção. Stack trace com nome de tabela é mapa entregue de graça.
• Considere um WAF (web application firewall, filtro de tráfego HTTP) como camada adicional, nunca como substituto do código correto.
• Limite o resultado: uma API que devolve 200 mil registros em uma chamada é um vazamento esperando pelo momento certo.

Camada 4: detecção e recuperação (pontos 10 a 12)

A quarta camada parte de uma premissa desconfortável: em algum momento, algo vai passar. Assim, o que define o tamanho do estrago é a velocidade com que você percebe e a qualidade da cópia que sobrou.

10. Ligue log, auditoria e alerta

Registro de conexões, de tentativas falhas e de comandos administrativos, enviado para fora do próprio servidor. Log que mora na máquina comprometida é apagado junto com ela.

O que fazer:

• PostgreSQL: log_connections = on, log_disconnections = on, log_statement = 'ddl' no mínimo. Para auditoria detalhada, a extensão pgaudit.
• MySQL: ative o audit log da sua distribuição e o general_log em janelas de investigação.
• Envie tudo para um coletor externo, com retenção definida.
• Configure alerta para o que importa: pico de falhas de autenticação, criação de usuário, alteração de privilégio, DROP ou TRUNCATE em tabela de produção, e volume atípico de leitura.

O último é o mais negligenciado. Afinal, exfiltração de dados aparece como consulta bem-sucedida: legítima em forma, anômala em volume.

11. Backup imutável, com regra 3-2-1 e recuperação pontual

O backup precisa ser inalcançável a partir da produção. Isso significa cópia imutável (que não pode ser alterada ou apagada durante um prazo definido, nem por administrador) e credencial separada.

O que fazer:

• Aplique a regra 3-2-1: três cópias do dado, em dois tipos de mídia diferentes, com uma delas fora do local principal (Peter Krogh, The DAM Book, 2005).
• Combine backup físico com dump lógico. O físico volta rápido; o lógico, por sua vez, permite recuperar objeto isolado.
• Ative a recuperação pontual (PITR, point-in-time recovery): no PostgreSQL, via arquivamento de WAL; no MySQL, via binlog. É o que permite voltar para as 14h07, e não só para a cópia da madrugada.
• Marque as cópias como imutáveis com prazo mínimo e mantenha o repositório em conta separada da produção. Isso se aproxima de um air gap, ou seja, a ausência de rota de rede direta entre o ambiente ativo e as cópias.

Isso deixou de ser preciosismo: no State of Ransomware da Sophos (2024), 94% das organizações atingidas por ransomware relataram que os criminosos tentaram comprometer os backups, e as tentativas tiveram sucesso em 57% dos casos.

12. Escreva o plano de resposta e teste a restauração

Um backup nunca restaurado é uma hipótese. O plano de resposta define quem faz o quê, em que ordem e em quanto tempo. Já o teste comprova que o número no contrato é real.

O que fazer:

• Defina RPO (recovery point objective: quanto dado a empresa aceita perder, em tempo) e RTO (recovery time objective: quanto tempo o sistema pode ficar fora do ar) para cada base. Em horas, por escrito.
• Escreva um runbook de uma página: contatos, ordem de restauração, comandos, critério para declarar incidente.
• Teste a restauração completa a cada seis meses, em ambiente isolado, cronometrando. O tempo real é o seu RTO verdadeiro.
• Inclua o prazo regulatório no plano: a Resolução CD/ANPD nº 15/2024 estabelece 3 dias úteis para comunicação de incidente de segurança com dados pessoais à Autoridade Nacional de Proteção de Dados. Descobrir esse prazo durante a crise, portanto, é tarde demais.

Tabela de priorização: por onde começar na segunda-feira

Se você não pode fazer tudo, faça nesta ordem. A coluna de esforço considera uma equipe pequena de TI.

Note que quatro dos oito primeiros controles da tabela levam de um a dois dias. Ou seja: proteger banco de dados é menos uma questão de orçamento e mais de decidir que a tarefa entra no calendário.

Para o desenho completo das camadas de defesa, incluindo governança e segregação de ambientes, vale ler segurança do banco de dados: as 8 camadas que a sua empresa precisa ter. E para avaliar o repositório onde as cópias vivem, os critérios estão em armazenamento em nuvem seguro.

Como a Prodb aplica esse checklist em ambientes de cliente

A Prodb Tecnologia opera infraestrutura em nuvem há 15 anos, atende mais de 550 clientes e trabalha a partir da região de Campinas, em São Paulo. Nos projetos de banco de dados, o checklist acima não é entregue como recomendação: é implantado e verificado.

• Arquitetura por ambiente. Os servidores cloud são dimensionados conforme a carga real do banco, com isolamento de rede, sub-rede privada e regras de acesso definidas no desenho, não improvisadas depois.
• Backup com separação real. Os planos de backup usam credenciais e políticas de retenção independentes da produção, com camada de imutabilidade e recuperação pontual quando o motor suporta. A escolha de retenção parte do RPO acordado com o cliente, não de um padrão de catálogo.
• Dado no Brasil. Servidores em território nacional, infraestrutura com certificações internacionais de cloud e faturamento em real. Isso simplifica a resposta a auditorias de LGPD e evita a discussão sobre jurisdição estrangeira.
• Suporte técnico dedicado. Quem atende conhece o ambiente. Em restauração de banco, sobretudo, esse detalhe é a diferença entre uma hora e um turno inteiro.

Uma ressalva necessária: migrar o banco para a nuvem não protege o banco. Um ambiente mal configurado na nuvem é tão vulnerável quanto no rack da sala dos fundos, com a diferença de estar mais perto da internet. O que protege, no fim das contas, é a disciplina dos doze pontos. A nuvem só torna vários deles mais fáceis de aplicar. E se o seu provedor atual promete backup diário, vale conferir o que essa promessa costuma esconder.

Perguntas frequentes

O post Como proteger um banco de dados: checklist técnico em 12 pontos apareceu primeiro em Prodb.

Uma empresa de logística com 90 funcionários migrou todos os arquivos operacionais para um serviço de armazenamento em nuvem. Contratos, notas, laudos de vistoria, fotos de avarias. Em quatro anos, nunca teve um incidente. Então, num sábado de manhã, um analista do financeiro clicou em um anexo, a máquina dele foi criptografada por ransomware, e a pasta sincronizada no desktop levou junto 1,2 TB de arquivos da nuvem. O provedor tinha criptografia AES-256, data center certificado e SLA de 99,9%. Ainda assim, nada disso impediu nada.

O problema não era o provedor. Era a suposição.

Armazenamento em nuvem seguro é uma expressão que a maioria das empresas usa sem definir. Na prática, ela significa coisas muito diferentes dependendo de quem fala: o fornecedor entende disponibilidade e criptografia de disco; o cliente entende “meus dados não podem sumir nem vazar”. Porém, as duas leituras raramente se encontram no contrato.

Este texto é uma auditoria. Sete critérios, cada um com uma pergunta que você consegue fazer ao seu fornecedor hoje à tarde e, em seguida, conferir a resposta.

O que é, de fato, um armazenamento em nuvem seguro

Armazenamento em nuvem seguro é aquele em que o dado permanece confidencial, íntegro e recuperável mesmo quando alguma coisa dá errado: falha do provedor, erro humano, ataque ou exclusão acidental. Segurança aqui não é um recurso ligado no painel. É a soma de criptografia, controle de acesso, versionamento, isolamento e capacidade comprovada de restaurar.

Repare na expressão “mesmo quando”: um armazenamento que funciona bem no dia normal não prova nada. A prova está no dia ruim.

A norma ISO/IEC 27001, referência internacional para gestão de segurança da informação, organiza isso em três propriedades: confidencialidade, integridade e disponibilidade. É um bom teste mental. Pergunte, para cada pasta crítica da sua empresa: quem pode ler? Quem pode alterar sem deixar rastro? E se sumir hoje, em quanto tempo volta?

Portanto, se você não sabe responder às três, o armazenamento não é seguro. É só remoto.

Armazenamento não é backup, e confundir os dois é o erro mais caro

Armazenamento em nuvem guarda a versão atual do arquivo e a sincroniza entre dispositivos. Backup, por outro lado, guarda cópias históricas, isoladas, com política de retenção. Ou seja: sincronização replica o erro; backup permite voltar atrás dele.

Foi exatamente o que aconteceu com a empresa de logística do início. O serviço fez o que foi contratado para fazer: sincronizou. Em seguida, os arquivos criptografados pelo ransomware substituíram os originais em todos os dispositivos conectados, com fidelidade impecável.

A distinção prática:

• Armazenamento responde a “onde está meu arquivo agora?”
• Backup responde a “como estava meu arquivo na terça-feira passada, antes do incidente?”

Muitos serviços de armazenamento oferecem versionamento e lixeira, e isso ajuda. Mas versionamento com retenção de 30 dias não é política de backup. É rede de proteção contra o erro percebido rápido. Na prática, fraude interna, corrupção silenciosa de banco e ransomware com detonação atrasada costumam passar dessa janela.

Se você quer entender a diferença de forma mais detalhada, vale a leitura sobre as vantagens do backup em nuvem, que trata do assunto pelo outro lado.

Criptografia: em trânsito, em repouso e quem guarda a chave

Um armazenamento em nuvem seguro criptografa o dado em trânsito (enquanto trafega pela rede, via TLS 1.2 ou superior) e em repouso (enquanto está gravado no disco, normalmente com AES-256). A pergunta que quase ninguém faz, no entanto, é a terceira: quem controla a chave.

Criptografia em repouso protege contra roubo físico de disco e contra descarte inadequado de hardware. É importante e é o mínimo. Só que, se a chave é gerenciada inteiramente pelo provedor, o dado está criptografado para o mundo e legível para o provedor.

Existem três modelos, do mais simples ao mais controlado:

1. Chave gerenciada pelo provedor. Padrão da maioria dos serviços. Simples, sem esforço operacional, sem controle do cliente.
2. Chave gerenciada pelo cliente (CMK). A chave vive em um cofre (KMS, ou key management service, serviço que armazena e controla o uso de chaves criptográficas), mas o cliente define rotação, permissão de uso e revogação.
3. Chave fornecida pelo cliente. O cliente guarda a chave fora da nuvem. Máximo controle, porém máximo risco operacional: perdeu a chave, perdeu o dado. Sem exceção.

Para a maioria das PMEs brasileiras, o modelo 2 é o ponto de equilíbrio. Ele permite responder a uma auditoria de LGPD com propriedade e, além disso, revogar acesso a um conjunto de dados sem depender de chamado.

Pergunte ao seu fornecedor: o dado é criptografado em repouso? Com qual algoritmo? Quem detém a chave e com que frequência ela é rotacionada?

Controle de acesso: identidade, privilégio mínimo e MFA

A maior parte dos incidentes em ambientes de nuvem não começa com a quebra de criptografia. Começa com uma credencial válida usada por quem não deveria: senha reaproveitada, conta de ex-funcionário ativa, chave de API em repositório público.

O relatório Cost of a Data Breach da IBM (2024) apontou que o tempo médio para identificar e conter uma violação de dados foi de 258 dias. Boa parte desse tempo se explica por um detalhe simples: quando o invasor usa uma credencial legítima, o sistema não vê invasão. Vê trabalho.

O que exigir:

• Autenticação multifator (MFA) obrigatória para qualquer acesso administrativo. Não opcional, não “recomendada”.
• Privilégio mínimo. Cada usuário e cada aplicação recebem apenas a permissão necessária para a função. Ninguém precisa, por exemplo, de acesso total ao bucket inteiro para subir um PDF.
• Contas nominais. Nada de login compartilhado entre a equipe. Sem identidade individual, não existe auditoria possível.
• Revisão trimestral de acessos. Uma planilha e uma hora de reunião resolvem. O que mata não é a dificuldade: é nunca fazer.
• Rotação de chaves de API e expiração automática de links públicos de compartilhamento.

Link público sem prazo de validade é a porta lateral mais esquecida de todo ambiente corporativo. Portanto, se a sua empresa gera links de compartilhamento, defina expiração padrão e revise os ativos.

Onde o dado mora: soberania, LGPD e jurisdição

A LGPD (Lei nº 13.709/2018) não proíbe armazenar dados de brasileiros fora do Brasil, mas impõe condições à transferência internacional e responsabiliza o controlador pelo que acontece com o dado. Por isso, manter o armazenamento em território nacional simplifica conformidade, reduz latência e elimina a discussão sobre jurisdição estrangeira.

Três consequências práticas de escolher armazenamento fora do país:

• Jurídica. Em caso de requisição judicial, incidente ou pedido de titular, o caminho é mais longo e envolve legislação de outro país. Vale dizer que a ANPD (Autoridade Nacional de Proteção de Dados) fiscaliza a empresa brasileira, não o provedor estrangeiro.
• Operacional. Latência entre São Paulo e um data center na Virgínia gira em torno de 110 a 130 milissegundos de ida e volta. Para armazenamento de arquivos frios, é irrelevante. Já para um sistema que lê e grava a cada operação, é gargalo.
• Financeira. Contrato em dólar significa que sua fatura de infraestrutura acompanha o câmbio. Assim, em três anos de variação cambial, o orçamento planejado deixa de existir.

Para setores regulados, a exigência é ainda mais dura. A Resolução CMN nº 4.893/2021, que trata de política de segurança cibernética e contratação de serviços de processamento e armazenamento de dados em nuvem por instituições financeiras, estabelece requisitos específicos de contrato, auditoria e comunicação ao Banco Central.

Resiliência: redundância, versionamento e imutabilidade

Redundância protege contra falha de hardware. Versionamento protege contra erro humano. Imutabilidade protege contra ataque. São, portanto, três coisas diferentes, e nenhuma substitui as outras.

• Redundância significa que o mesmo dado existe em mais de um disco, rack ou zona de disponibilidade. É o que sustenta o SLA. Contudo, não protege contra exclusão: se você apagou, apagou em todas as cópias, de forma consistente e rápida.
• Versionamento mantém revisões anteriores do mesmo objeto. Protege, assim, contra sobrescrita e exclusão acidental, dentro da janela de retenção configurada.
• Imutabilidade (também chamada de WORM, de write once, read many: grava uma vez, lê muitas) impede que um arquivo seja alterado ou excluído durante um período definido, mesmo por quem tem permissão de administrador. É o único dos três que resiste a um invasor com credencial de admin na mão.

Esse ponto ficou central porque os atacantes mudaram de alvo. O relatório State of Ransomware da Sophos (2024) registrou que, na ampla maioria dos ataques analisados, os criminosos tentaram comprometer os backups da vítima. Backup acessível pela mesma credencial da produção não é backup: é mais uma pasta.

Um passo adicional é o air gap: separação real entre o ambiente de produção e a cópia de segurança, de modo que não exista rota de rede direta entre os dois. Na nuvem, isso se implementa com conta separada, credencial separada e política de retenção que o time de produção não consegue alterar.

Checklist: audite o seu armazenamento em nuvem em 12 perguntas

Use esta lista em uma reunião de uma hora com o responsável de TI ou com o fornecedor. E vale um critério prévio: respostas vagas contam como “não”.

Se as perguntas 9, 10 e 11 ficarem em branco, o restante importa menos do que parece. Afinal, a capacidade de restaurar é o que transforma armazenamento em segurança.

Para o caso específico de bases de dados, os controles são outros e mais profundos. Tratamos disso em segurança do banco de dados: as 8 camadas que a sua empresa precisa ter.

Como a Prodb trata armazenamento em nuvem seguro

A Prodb Tecnologia trabalha com infraestrutura em nuvem há 15 anos, atende mais de 550 clientes e opera a partir da região de Campinas, em São Paulo. O ponto de partida de qualquer projeto de armazenamento aqui não é o volume em terabytes: é a pergunta sobre o que precisa voltar, em quanto tempo, e a partir de qual cópia.

O que isso significa na prática:

• Dado no Brasil. Servidores em território nacional, faturamento em real e infraestrutura com certificações internacionais de cloud. Como resultado, não há discussão de jurisdição estrangeira nem exposição cambial no orçamento anual.
• Separação entre produção e cópia. Os planos de backup da Prodb são desenhados com credenciais e políticas independentes do ambiente de produção, com retenção e imutabilidade definidas por perfil de dado, não um padrão único aplicado a todo mundo.
• Arquitetura sob medida. Um ERP transacional, um repositório de imagens médicas e um data lake analítico têm exigências de acesso, latência e retenção diferentes. Por isso, os servidores cloud e o armazenamento associado são dimensionados por ambiente, não por template de catálogo.
• Suporte técnico dedicado. Quando a restauração precisa acontecer, o cliente fala com um engenheiro que conhece o ambiente dele, não com uma fila genérica de tickets.

E uma observação honesta: nuvem não resolve tudo. Ela não corrige processo interno frouxo, não substitui política de acesso e não impede que alguém com permissão excessiva apague o que não deveria. O que uma boa arquitetura faz é garantir que, quando isso acontecer, exista uma cópia que o erro não alcançou. Se a sua estratégia ainda envolve equipamento no escritório, vale ler nossa análise sobre backup local em 2026 antes de decidir.

Perguntas frequentes

O post Armazenamento em nuvem seguro: como avaliar se o seu realmente é apareceu primeiro em Prodb.

Existe um equipamento na sala da TI da maioria das empresas brasileiras de médio porte.

Ele fica em um rack, tem quatro discos, uma luz verde piscando e um nome de fabricante na frente. Todo mundo chama de “o backup”. Ele funciona há anos.

No entanto, ele está no mesmo endereço dos servidores que ele protege. Na mesma rede. No mesmo circuito elétrico. Sob o mesmo telhado. Acessível pelas mesmas credenciais de administrador de domínio.

Isso quer dizer que quase tudo que pode dar errado com os servidores pode dar errado com ele ao mesmo tempo: incêndio, alagamento, furto, surto elétrico, ransomware que se propaga pela rede. Ou seja, o backup existe justamente para cobrir a falha do original, mas está exposto exatamente às mesmas causas de falha.

Essa é a razão principal para tirar o backup do escritório. As outras cinco vantagens vêm depois, e são boas. Mas essa é a que muda a natureza do problema.

Este artigo trata da decisão de negócio. Se você procura a comparação técnica ponto a ponto entre os dois modelos, ela está em backup em nuvem ou local: qual é o mais seguro.

O que muda quando o backup sai do escritório

Backup em nuvem é a cópia dos seus dados mantida em infraestrutura de um provedor, fora das suas instalações, acessível por rede e gerenciada por contrato de serviço. A mudança central é a eliminação do risco correlacionado: a cópia deixa de compartilhar o destino físico do original.

Além disso, três coisas mudam de lugar:

• O custo sai do investimento em ativo e vira despesa recorrente proporcional ao volume.
• A operação (troca de disco, atualização, monitoramento da rotina) sai do seu time e vai para o provedor.
• A responsabilidade contratual passa a ter um documento com prazos e obrigações, em vez de depender da memória de quem configurou.

O que não muda: você continua sendo o dono do dado e o responsável final pela política. Nuvem não terceiriza a decisão sobre o que guardar, por quanto tempo e com que frequência.

Vantagem 1: o backup deixa de compartilhar o destino do escritório

Manter a cópia em outro local elimina o risco correlacionado, ou seja, a situação em que um único evento destrói o dado original e a sua cópia ao mesmo tempo. É o motivo pelo qual a regra 3-2-1 (três cópias, em dois tipos de mídia, com uma fora do local) existe há décadas.

Vale listar os eventos que atingem os dois ao mesmo tempo quando o backup está no mesmo prédio:

• Incêndio, alagamento e infiltração
• Furto de equipamento
• Surto elétrico ou falha prolongada de energia
• Ransomware que se propaga por compartilhamento de rede
• Erro humano em manutenção física
• Interdição do imóvel

O último costuma ser ignorado e é bastante real: se o prédio for interditado por qualquer motivo, o dado pode estar íntegro e inacessível. Na prática, para efeito de continuidade, dado inacessível e dado perdido são a mesma coisa.

Vantagem 2: o custo vira previsível e sai do investimento

Backup local exige compra de equipamento, discos de reposição, licença de software e substituição a cada 4 ou 5 anos. Backup em nuvem transforma isso em uma despesa mensal proporcional ao volume armazenado.

Além do desembolso concentrado, o modelo local tem três custos que raramente entram na planilha de comparação:

• Capacidade ociosa. Você compra para o volume esperado em 4 anos e paga por ele desde o primeiro mês.
• Ciclo de renovação. Em algum momento o equipamento sai de garantia e o custo reaparece inteiro.
• Horas do time. Monitorar a rotina, trocar disco, atualizar firmware, testar restauração e refazer a configuração quando algo muda.

Por outro lado, o modelo em nuvem cresce com o volume. Se os seus dados dobram, a conta acompanha, e é por isso que política de retenção deixa de ser detalhe técnico e vira decisão financeira. Ou seja, guardar tudo para sempre é uma escolha, e ela tem preço.

Vantagem 3: imutabilidade, a defesa específica contra ransomware

Backup imutável é aquele que não pode ser alterado nem apagado durante um período definido, nem por quem tem credencial de administrador. É a única proteção estrutural contra o ataque que hoje mira primeiro o backup e só depois a produção.

Esse ponto merece atenção porque mudou o comportamento dos ataques. Em levantamento com organizações atingidas por ransomware, 94% relataram que os atacantes tentaram comprometer os backups durante o ataque, e essas tentativas tiveram sucesso em 57% dos casos (Sophos, The State of Ransomware, 2024).

De fato, a lógica do atacante é direta: uma empresa com backup íntegro não paga resgate. Então o backup é o primeiro alvo.

Por isso, um backup local ligado à rede, acessível com as mesmas credenciais de administrador do ambiente, é um alvo fácil. A imutabilidade quebra isso porque a regra é aplicada na camada de armazenamento do provedor: mesmo que a credencial seja comprometida, o comando de exclusão é recusado até o fim do prazo de retenção.

Três perguntas para fazer ao seu fornecedor atual:

1. Existe retenção imutável configurada? Por quantos dias?
2. Um administrador comprometido consegue reduzir esse prazo?
3. As credenciais do sistema de backup são separadas das credenciais do domínio?

Se a resposta para a primeira for “não”, as outras duas perdem o sentido.

Vantagem 4: o teste de restauração deixa de depender de hardware ocioso

Backup só vale o que consegue restaurar. Em ambiente local, testar restauração exige hardware sobrando; em nuvem, exige apenas provisionar um ambiente temporário e destruí-lo depois. É a vantagem menos citada e uma das mais importantes.

Ter backup não é o mesmo que conseguir recuperar. A diferença aparece exatamente no momento em que ninguém quer descobrir.

O teste precisa validar quatro coisas:

• Integridade: o arquivo restaurado abre e o sistema sobe.
• Completude: todos os componentes vieram, ou seja, banco, arquivos, configuração e chaves.
• Tempo: quanto demora, de fato, do comando à operação retomada.
• Procedimento: alguém além do responsável habitual consegue executar o roteiro.

Dois termos ajudam a organizar isso. RPO (Recovery Point Objective) é quanto de dado a empresa aceita perder, medido em tempo. Por exemplo, se o backup é diário às 22h e a falha ocorre às 20h, o RPO é de quase 24 horas. RTO (Recovery Time Objective) é quanto tempo a empresa aceita ficar parada até voltar a operar.

Os dois são decisões de negócio, não de TI. Portanto, quem define quanto tempo o faturamento pode ficar parado é a diretoria. A TI dimensiona a solução para atender esse número.

Vantagem 5: retenção, LGPD e prova de auditoria

Backup em nuvem gerenciado entrega registro de execução, retenção configurável por política e relatório, o que transforma “nós fazemos backup” em algo demonstrável. Em auditoria e em incidente, a diferença entre afirmar e demonstrar é grande.

A LGPD (Lei 13.709/2018) exige que o controlador adote medidas de segurança aptas a proteger dados pessoais e prevê sanções administrativas de até 2% do faturamento no Brasil, limitadas a R$ 50 milhões por infração. Não existe um artigo que diga “faça backup diário”. No entanto, existe a obrigação de garantir disponibilidade e integridade, e a de demonstrar que você fez o que era razoável.

Na prática, isso significa ter:

• Política escrita de retenção por tipo de dado
• Log de execução das rotinas, com sucesso e falha
• Registro dos testes de restauração
• Definição de onde o dado está armazenado geograficamente
• Procedimento de exclusão ao fim do prazo de retenção

Esse último ponto merece nota: retenção infinita não é conservadorismo, é passivo. Guardar dado pessoal além do necessário aumenta a superfície de exposição e contraria o princípio de necessidade previsto na própria lei.

Manter o backup em território nacional simplifica esse cenário, não porque a LGPD proíba transferência internacional, mas porque ela impõe requisitos adicionais que dão trabalho.

Vantagem 6: o tempo do seu time volta para o time

Backup local consome horas recorrentes de profissionais caros em tarefas que não diferenciam a empresa: verificar rotina, trocar disco, atualizar software, refazer configuração. Em nuvem gerenciada, essas horas voltam.

Em uma equipe de TI de três ou quatro pessoas (realidade da maioria das médias empresas brasileiras), essa é frequentemente a vantagem de maior efeito prático, mesmo que não apareça na comparação de preço.

E há um efeito secundário relevante: reduz o risco de conhecimento concentrado. Quando a rotina de backup só existe na cabeça de uma pessoa, o desligamento dela é um evento de risco.

O que o backup em nuvem NÃO resolve

Nuvem não é sinônimo de proteção automática. Cinco limitações reais precisam entrar na decisão. Quem vende sem falar delas está vendendo mal.

1. Banda de subida. A primeira carga completa de vários terabytes pode levar dias ou semanas em um link comercial típico. Existem soluções (carga inicial por mídia física, janela noturna, backup incremental permanente), mas a limitação é real e precisa ser dimensionada antes de contratar.
2. Tempo de restauração de grande volume. Descer 8 TB pela internet não é instantâneo. Se o seu RTO é de 4 horas para um volume grande, backup exclusivamente em nuvem pode não atender. É o principal argumento a favor do modelo híbrido.
3. Custo de recuperação. Alguns modelos cobram pela saída de dados ou pela restauração antecipada de camadas de arquivamento. Por isso, pergunte o preço da restauração antes de assinar, não durante o incidente.
4. Configuração continua sendo sua responsabilidade. O provedor garante a infraestrutura; o que é copiado, com que frequência e por quanto tempo é decisão do cliente. Backup em nuvem mal configurado falha exatamente como backup local mal configurado. Esse é o modelo de responsabilidade compartilhada, detalhado em segurança e backup de banco de dados na nuvem.
5. SaaS não faz backup por você. Sistemas de e-mail, CRM e ERP em nuvem garantem a disponibilidade do serviço, não a recuperação de um dado que o seu usuário apagou há três meses. Assim, verifique a política de retenção de cada um. Na maioria dos casos, ela é curta.

Tabela: local, nuvem ou híbrido

O híbrido (cópia local para restauração rápida e cópia em nuvem imutável para desastre) costuma ser a resposta correta para empresas com operação crítica. É verdade que ele custa mais que os dois isolados. Em compensação, entrega o que nenhum dos dois entrega sozinho. Se você está avaliando o lado físico dessa equação, vale ler melhor equipamento para backup local.

7 perguntas antes de trocar

1. Qual é o nosso RPO e o nosso RTO por sistema, definidos pela diretoria e não estimados pela TI?
2. Qual o volume total hoje e qual a taxa de crescimento anual?
3. Qual a capacidade real de subida do nosso link, no horário da janela de backup?
4. Existe retenção imutável? Por quantos dias e sob qual credencial?
5. Quando foi o último teste de restauração completo e quanto tempo ele levou?
6. Quais sistemas SaaS estão fora da nossa política de backup hoje?
7. Quanto custa restaurar 100% do volume, em reais e em horas?

Se a pergunta 5 não tiver resposta com data, comece por ela. É a que mais frequentemente revela que o backup existente não é backup: é rotina que roda.

Como a Prodb ajuda no backup em nuvem

A Prodb Tecnologia trabalha com infraestrutura em nuvem no Brasil há 15 anos e atende mais de 550 clientes. Backup é um dos nossos serviços centrais, do plano básico ao totalmente personalizável.

O que costuma diferenciar na prática:

• Plano dimensionado pelo seu RPO e RTO reais, e não por um pacote de prateleira. A conversa começa por quanto tempo a sua operação pode ficar parada, não por quantos gigabytes você quer contratar.
• Infraestrutura no Brasil. Dado em território nacional, faturamento em real e latência menor na hora da restauração. Conheça os planos de backup.
• Monitoramento contínuo e arquitetura de resiliência. A rotina é acompanhada, e a falha de execução gera alerta, em vez de ser descoberta no dia em que alguém precisa restaurar.
• Suporte técnico dedicado. No momento de uma restauração, você fala com quem conhece o seu ambiente.
• Certificações internacionais de nuvem na infraestrutura utilizada.

Não prometemos que nada vai dar errado. Prometemos que, quando der, existe um procedimento testado, um prazo acordado e alguém do outro lado.

Ter backup não é o mesmo que conseguir recuperar. E a diferença entre os dois é exatamente o que se contrata.

Perguntas frequentes

O post Vantagens do backup em nuvem: o que muda de verdade quando o backup sai do escritório apareceu primeiro em Prodb.

Na prática, a maioria dos incidentes graves com banco de dados não começa com uma técnica sofisticada.

Em geral, começa com uma porta 3306 ou 5432 exposta à internet. Com um usuário de aplicação que tem permissão de administrador porque, na migração de 2021, era mais rápido assim. Com uma cópia do banco de produção restaurada em homologação, com os dados reais dos clientes, acessível ao time de desenvolvimento inteiro.

Nenhuma dessas três coisas é um ataque. São aberturas. O ataque é só o que passa por elas.

A Gartner projetou que, até 2025, mais de 99% das falhas de segurança em nuvem seriam causadas por erro de configuração do próprio cliente, e não por falha do provedor (Gartner). Nesse sentido, a leitura prática dessa projeção é desconfortável: a maior parte do trabalho de segurança do banco de dados não está em comprar proteção; está, em vez disso, em configurar corretamente o que já existe.

Este artigo trata, sobretudo, das camadas de proteção do banco em si. Se você procura o quadro mais amplo (modelo de responsabilidade compartilhada, panorama de ameaças e estratégia de backup), ele está detalhado em segurança e backup de banco de dados na nuvem. Aqui, descemos um nível.

Por que segurança do banco de dados se organiza em camadas

Camadas existem porque nenhum controle isolado sobrevive a um erro. A lógica é que o atacante que vence a rede ainda precise vencer a autenticação; quem vence a autenticação ainda esbarre na autorização; e quem chega aos dados encontre criptografia e trilha de auditoria. Em resumo, é defesa em profundidade aplicada ao dado.

O modelo tem uma consequência prática importante: cada camada deve ser avaliada assumindo que a anterior falhou. Portanto, a pergunta correta não é “estamos protegidos?”. É “se alguém já estiver dentro da rede, o que ele consegue ler?”.

As oito camadas, na ordem em que um invasor as encontraria:

1. Superfície de rede
2. Autenticação e identidade
3. Autorização e privilégio mínimo
4. Criptografia e gestão de chaves
5. Camada de aplicação e injeção de SQL
6. Auditoria e trilha de log
7. Detecção e resposta
8. Hardening e ciclo de vida

Camada 1: Superfície de rede (onde o banco escuta)

O banco de dados nunca deve ser acessível diretamente da internet. Por isso, ele deve escutar apenas em rede privada, com acesso administrativo mediado por VPN ou host de salto (bastion), e com regras de firewall que liberem por origem específica, não por faixa aberta.

Controles mínimos:

• Bind em interface privada. O serviço escuta em endereço interno, não em 0.0.0.0.
• Sub-rede privada sem rota para a internet. Se o banco precisa sair para baixar atualização, isso passa por gateway controlado, não por IP público atribuído a ele.
• Grupo de segurança por origem. Libere a porta do banco apenas para os endereços dos servidores de aplicação. Nunca para 0.0.0.0/0.
• Acesso administrativo por VPN ou bastion. O DBA entra na rede antes de entrar no banco.
• Porta padrão alterada, quando não houver impacto operacional. Não é segurança de verdade, mas reduz ruído de varredura automatizada.

Como testar: faça uma varredura de portas a partir de um endereço externo à sua rede. Se a porta do banco responder, então essa camada não existe.

Camada 2: Autenticação e identidade

Autenticação responde a uma pergunta: quem está se conectando? A regra é eliminar credencial compartilhada, exigir segundo fator para acesso humano administrativo e guardar segredos em cofre, nunca em código ou arquivo de configuração versionado.

Controles mínimos:

• Uma identidade por pessoa. O usuário admin compartilhado por quatro pessoas torna impossível qualquer investigação posterior. Em outras palavras, se todos são admin, ninguém é responsável.
• Contas de serviço separadas das contas humanas. A aplicação usa uma credencial; a pessoa usa outra. Além disso, elas têm permissões diferentes e ciclos de vida diferentes.
• Autenticação multifator (MFA) para acesso administrativo. MFA é a exigência de um segundo elemento além da senha (token, aplicativo ou chave física).
• Cofre de segredos. Ferramenta que armazena senhas e chaves de forma criptografada e as entrega à aplicação em tempo de execução, com registro de quem pediu o quê. Credencial em .env no repositório é vazamento adiado.
• Rotação de credenciais. Senha de conta de serviço com prazo de validade e processo de troca sem parada.
• Bloqueio após tentativas. Limite de tentativas de autenticação com atraso progressivo.

O peso dessa camada é alto. Não por acaso, o relatório de investigação de violações da Verizon aponta que 68% das violações analisadas envolveram um elemento humano não malicioso, como erro, engano ou credencial cedida (Verizon, Data Breach Investigations Report, 2024). De fato, credencial é a porta mais usada porque é a mais barata de atravessar.

Como testar: liste todos os usuários do banco e, em seguida, identifique o dono de cada um. Se houver algum sem dono nomeado, você encontrou o problema.

Camada 3: Autorização e privilégio mínimo

Privilégio mínimo significa que cada conta recebe exatamente as permissões necessárias para a sua função e nada além disso. Ou seja, é a camada que determina o tamanho do estrago quando uma credencial vaza.

Controles mínimos:

• Nenhuma conta de aplicação com perfil de administrador. A aplicação que só lê e grava em cinco tabelas não precisa de DROP, não precisa criar usuário e não precisa acessar outros bancos da mesma instância.
• Permissão por papel (role), não por usuário. Crie papéis (leitura, escrita operacional, relatórios, administração) e associe pessoas a papéis. Na prática, isso torna a revisão viável.
• Separação entre leitura e escrita. Ferramentas de BI e relatórios conectam com credencial exclusivamente de leitura, preferencialmente em réplica.
• Views e colunas restritas. Em vez de dar acesso à tabela inteira, exponha uma view sem os campos sensíveis.
• Segurança em nível de linha (row-level security). Recurso que filtra automaticamente quais linhas cada usuário enxerga, útil em bancos multiempresa, onde um cliente jamais pode ver o registro de outro.
• Revisão trimestral de acessos. Lista de quem tem o quê, assinada pelo gestor da área.

Como testar: conecte-se com a credencial da aplicação e tente executar DROP TABLE em uma tabela de teste, ou consultar uma tabela fora do escopo dela. Se funcionar, o privilégio não é mínimo.

Camada 4: Criptografia e gestão de chaves

Criptografia protege o dado quando as camadas anteriores falham. São três frentes: em trânsito, em repouso e em nível de campo. A pergunta decisiva em todas elas, no entanto, é quem controla a chave.

• Criptografia em trânsito. Todo tráfego entre aplicação e banco passa por TLS, o protocolo que cifra a comunicação na rede. Não basta suportar: o banco deve recusar conexão não cifrada.
• Criptografia em repouso. Os arquivos de dados no disco ficam cifrados, de modo que uma cópia física do volume ou um snapshot vazado não seja legível. Nos bancos comerciais, isso costuma aparecer com o nome de TDE (Transparent Data Encryption).
• Criptografia em nível de coluna ou campo. Aplicada a dados especialmente sensíveis, como CPF, cartão e dados de saúde. O campo é cifrado individualmente, e nem quem tem acesso à tabela lê o conteúdo sem a chave.

Gestão de chaves é o ponto que quase todo mundo trata por último e que define se a criptografia vale alguma coisa:

• A chave nunca fica no mesmo lugar que o dado cifrado.
• Existe cofre de chaves (KMS) com controle de acesso e log próprio.
• Existe rotação periódica de chave.
• Existe procedimento documentado de recuperação. Chave perdida é dado perdido. Ou seja, criptografia sem plano de recuperação é ransomware que você aplicou em si mesmo.

Um cuidado adicional: criptografia em repouso não protege contra credencial comprometida. Isto é, quem se conecta legitimamente ao banco recebe o dado já decifrado. Ela protege contra roubo de mídia, snapshot vazado e acesso ao armazenamento por fora do banco, o que é relevante, mas é um cenário específico. O tema aparece também em armazenamento em nuvem seguro.

Como testar: tente abrir uma conexão sem TLS. Deve ser recusada. Depois, verifique se a chave de criptografia está armazenada em cofre separado e quem tem permissão para lê-la.

Camada 5: Aplicação, injeção de SQL e proxy

A maior parte dos vazamentos de banco não acontece por invasão do banco: acontece por abuso da aplicação que tem acesso legítimo a ele. Injeção de SQL é a técnica de inserir comando malicioso em um campo de entrada para que o banco o execute como se fosse parte da consulta.

Controles mínimos:

• Consultas parametrizadas (prepared statements). O comando e os dados trafegam separados, o que impede que o conteúdo digitado por um usuário vire instrução executável. De fato, é o controle mais eficaz e o mais barato.
• Validação de entrada no servidor. Validação apenas no navegador não vale nada, porque ela pode ser contornada.
• Mensagens de erro genéricas. Erro de banco exibido na tela entrega estrutura de tabela, nome de coluna e versão do servidor.
• WAF (firewall de aplicação web). Filtro que inspeciona requisições HTTP e bloqueia padrões conhecidos de ataque. Contudo, é complemento, não substituto de código correto.
• Proxy de banco de dados. Camada intermediária que centraliza conexões, aplica limites e registra consultas. Útil em ambientes com muitas aplicações acessando o mesmo banco.
• Limite de volume por consulta. Uma conta de relatório que normalmente lê 500 linhas não precisa poder extrair 4 milhões.

Como testar: rode uma varredura automatizada de injeção de SQL em ambiente de homologação e, em seguida, revise o código dos pontos onde a consulta é montada por concatenação de texto.

Camada 6: Auditoria e trilha de log

Auditoria responde a três perguntas depois do incidente: quem acessou, o que leu ou alterou e quando. Sem ela, uma investigação vira reconstituição por memória, e o prazo legal de notificação continua correndo.

Controles mínimos:

• Log de autenticação. Toda tentativa de conexão, bem-sucedida ou não, com origem e horário.
• Log de alteração de estrutura e permissão. Criação de usuário, mudança de privilégio, alteração de tabela.
• Log de acesso a dados sensíveis. Nem todo SELECT precisa ser registrado, mas consultas às tabelas com dado pessoal precisam.
• Log fora do banco. O registro deve ser enviado para um destino separado e, idealmente, imutável, isto é, armazenamento que não permite alteração nem exclusão dentro do período de retenção. Log que mora no servidor invadido é log que o invasor apaga.
• Retenção definida. Prazo escrito, alinhado com jurídico e com as obrigações do seu setor.
• Sincronização de relógio. Sem NTP, correlacionar eventos entre sistemas é impossível.

O tempo importa. O ciclo médio global entre a ocorrência e a contenção de uma violação foi de 258 dias (IBM, Cost of a Data Breach Report, 2024). Além disso, uma parte relevante desse tempo é gasta justamente descobrindo o que aconteceu, trabalho que só é possível com trilha de auditoria confiável.

Vale lembrar que a LGPD (Lei 13.709/2018) prevê sanções administrativas de até 2% do faturamento no Brasil, limitadas a R$ 50 milhões por infração, e exige que o controlador demonstre a adoção de medidas de segurança. Demonstrar exige registro.

Como testar: peça ao time uma resposta documentada para “quem consultou a tabela de clientes na terça-feira passada”. Cronometre.

Camada 7: Detecção e resposta

Detecção é o que transforma um log arquivado em alerta acionável. Ela funciona a partir de uma linha de base: você define o comportamento normal do banco e é avisado quando algo foge dele.

Sinais que valem um alerta:

• Autenticação bem-sucedida fora do horário habitual ou de origem geográfica atípica.
• Volume de leitura muito acima do padrão da conta, indício clássico de exfiltração.
• Sequência de falhas de autenticação seguida de sucesso.
• Execução de comandos de estrutura (DROP, TRUNCATE, ALTER) em produção.
• Criação de usuário ou concessão de privilégio fora de janela de mudança.
• Queda abrupta no tempo de resposta acompanhada de consultas atípicas.

Além do alerta, é preciso ter o plano. Quem é acionado, em quanto tempo, com que autoridade para desconectar sessões, isolar a instância ou revogar credenciais. Portanto, um plano de resposta que precisa de aprovação de diretoria às 3h da manhã não é um plano.

Como testar: faça um exercício controlado. Extraia um volume anormal de dados de uma tabela de teste com uma conta de relatório e cronometre quanto tempo leva até alguém ser avisado.

Camada 8: Hardening e ciclo de vida

Hardening é reduzir a superfície do próprio banco: remover o que não é usado, corrigir o que está vulnerável e impedir que dado de produção circule onde não deveria. É a camada mais rotineira e a mais adiada.

Controles mínimos:

• Remover contas e bancos de exemplo criados pela instalação padrão.
• Desativar funções e extensões não utilizadas, especialmente as que permitem execução de comando no sistema operacional.
• Ciclo de correção definido. Prazo máximo para aplicar correção crítica, com janela de manutenção acordada.
• Configuração revisada. Parâmetros de conexão, limite de sessões, tempo de espera, tamanho de log.
• Mascaramento de dados em ambientes não produtivos. Restaurar produção em homologação sem anonimizar é copiar o risco para um ambiente com menos controle. Inclusive, é um dos erros mais comuns e mais fáceis de corrigir.
• Descomissionamento com destruição de dado. Instância desligada com volume preservado continua sendo um banco de dados exposto.

Como testar: liste os ambientes que contêm dados pessoais reais. Se homologação, desenvolvimento ou a máquina de um analista estiverem na lista, comece por aí.

Tabela-resumo das 8 camadas

Se você só puder fazer três coisas este mês

Em ambientes de PME, com equipe reduzida, a ordem que produz mais redução de risco por hora investida é esta:

1. Tirar o banco da internet. Camada 1. É a correção com maior efeito e menor custo.
2. Retirar o perfil de administrador da conta da aplicação. Camada 3. Limita o estrago de qualquer credencial vazada.
3. Ativar log de autenticação e mandar para fora do servidor. Camada 6. Sem isso, você não saberá se algo aconteceu.

Depois disso, siga pelo checklist técnico de proteção de banco de dados e trate as camadas restantes em ciclos mensais.

Como a Prodb ajuda na segurança do banco de dados

A Prodb Tecnologia opera infraestrutura em nuvem no Brasil há 15 anos, com mais de 550 clientes. Vale dizer que segurança de banco de dados, no nosso trabalho, não é um produto separado. É como o ambiente é montado.

Na prática, isso significa:

• Rede desenhada com o banco em sub-rede privada por padrão. Acesso administrativo por caminho controlado, não por IP público.
• Monitoramento contínuo do ambiente, com acompanhamento de comportamento e não apenas de disponibilidade.
• Arquitetura sob medida por ambiente. Segregação entre produção, homologação e desenvolvimento definida junto com o cliente, e não herdada de um template.
• Infraestrutura no Brasil com certificações internacionais de nuvem, o que simplifica o tratamento de dado pessoal sob a LGPD e reduz latência. Conheça os servidores cloud.
• Suporte técnico dedicado. Quando um alerta dispara às 2h, você fala com alguém que conhece a topologia do seu ambiente.

Não existe banco de dados invulnerável, e desconfie de quem disser o contrário. Por outro lado, existe banco de dados em que o atacante precisa vencer oito obstáculos em vez de um, e em que você percebe a tentativa antes do terceiro.

Perguntas frequentes

O post Segurança do banco de dados: as 8 camadas que a sua empresa precisa ter apareceu primeiro em Prodb.

Se você busca previsibilidade de custos, suporte mais próximo e melhor performance, usar um servidor no Brasil pode ser a melhor escolha para o seu negócio.

Veja abaixo os principais motivos.

1. Cobrança em real: mais previsibilidade, menos dor de cabeça

Serviços pagos em dólar estão diretamente expostos à volatilidade cambial. Basta acompanhar o mercado para ver como o dólar varia com frequência, trazendo incerteza para empresas que têm custos fixos em moeda estrangeira.

Com um servidor brasileiro, você paga em real, o que evita surpresas na fatura no fim do mês. Isso facilita o planejamento financeiro, mantém a previsibilidade do orçamento de TI e protege seu caixa contra variações externas.

👉 Saiba mais: Como escolher um bom provedor para hospedar seu site

2. Taxas extras e impostos sobre serviços internacionais

Contratar serviços fora do Brasil não significa apenas converter o valor do dólar. É preciso considerar também:

• IOF sobre transações internacionais (6,38%)
• Taxas bancárias sobre câmbio
• Possível incidência de impostos como ISS e IRRF
• Regras e tarifas do governo americano que podem impactar contratos

Ou seja, além do valor do plano, você acaba pagando um acréscimo que muitas vezes não aparece na propaganda inicial. Com servidores no Brasil, esses custos extras desaparecem.

3. Latência: desempenho melhor com servidores no Brasil

Você sabia que usar servidores localizados no Brasil pode reduzir a latência pela metade?

Latência é o tempo que leva para uma informação viajar do usuário até o servidor. Quando a hospedagem está nos EUA, essa resposta pode levar de 140 ms a 200 ms. Já com servidores nacionais, esse número pode cair para menos de 60 ms.

Menor latência significa:

• Sites mais rápidos
• Menos queda de performance em horários de pico
• Melhor experiência para o usuário final
• Impacto positivo no SEO e conversão

👉 Entenda melhor: Servidores Cloud: O futuro da infraestrutura digital

4. Data center no Brasil x EUA: nem sempre “lá fora” é melhor

O Brasil já conta com data centers de altíssimo nível, com certificações internacionais, infraestrutura redundante e protocolos avançados de segurança e disponibilidade. Empresas como a Prodb oferecem soluções que se equiparam às maiores do mundo, mas com a vantagem de estarem alinhadas à realidade do mercado brasileiro.

Ter um data center nacional traz benefícios práticos como:

• Suporte técnico no mesmo fuso horário
• Atendimento em português
• Conformidade com leis locais, como a LGPD
• Contratos e questões jurídicas simplificadas

5. Mais foco no que importa: seu negócio

Ao escolher um servidor no Brasil, você reduz riscos, melhora a performance e economiza. Em vez de lidar com burocracias internacionais, variações cambiais e barreiras de suporte, sua empresa pode focar no que realmente importa: crescer com estabilidade e eficiência.

A Prodb é especialista em infraestrutura nacional de alta performance

Com data center próprio no Brasil, atendimento técnico especializado e soluções em nuvem sob medida, a Prodb entrega alta disponibilidade, segurança e desempenho, com cobrança em real e sem sustos no fim do mês.

Seja para hospedar seu site, rodar aplicações críticas ou modernizar seu ambiente digital, fale com a Prodb e descubra como a infraestrutura certa pode melhorar os resultados da sua empresa.

O post Por que escolher um servidor brasileiro faz mais sentido para sua empresa apareceu primeiro em Prodb.