O quão seguro é um banco de dados PostgreSQL se o meu servidor é roubado?

Question

Se eu tiver um servidor com um banco de dados de top secret de dados em PostgreSQL e minha senha é praticamente impossível de adivinhar (128 cadeia de caracteres de todos os tipos de estranhos caracteres, gerado com a mão).A senha do servidor também é praticamente difícil de adivinhar.

Além de uma adivinhação de senha, como é que é fácil para obter dados do banco de dados?

Pressupostos:

1. Apenas as base de dados existe no servidor.Não há nenhuma senha em um script PHP ou qualquer coisa assim
2. A pessoa que roubou o servidor é um servidor / DB / da unidade de disco rígido de recuperação de especialista
3. Eu não estou usando qualquer rígido-criptografia de unidade de disco ou qualquer coisa fora do normal para a proteção de
4. Eu estou usando o Ubuntu Hardy (última versão estável)

Estou tentando entender os riscos envolvidos com alguém obtém acesso físico para meu servidor de disco rígido-unidades.

Answer 1

"O padrão de pensamento é quando alguém se senta no servidor, ele é comprometido, o fim da história.Tudo só piora se eles pegam a unidade de disco rígido e levá-lo para um laboratório para a abertura e análise."

Idem.

Uma vez que um atacante tem permanente acesso físico (i.e. ele saiu do edifício com o seu disco rígido em sua pasta), o gabarito é de assumir que, com o tempo o comprometimento dos dados.A partir daí, o cenário é o custo da tática de adiantamento vs.a capacidade de diminuir o atacante.

É um pouco diferente se o invasor é um "insider", ou só tinham acesso temporário.Nesses casos, você pode ser capaz de abrandar-lhe o suficiente, ou forçar a prestação de contas de tal forma que o ataque torna-se inviável.

A criptografia de unidade de disco rígido é uma tática de adiantamento ele vai dar a proteção que coincide com a força do algoritmo, a força da chave, e a força do bloqueio de senha de acesso à chave (ou a capacidade de se inserir de hardware com a chave armazenada separadamente).Mesmo com encriptação, o pressuposto é de que é uma tática de adiantamento.Mais cedo ou mais tarde, o atacante vai passar a tecla de espaço e descobrir a chave que descriptografa o sistema.

Tamperproofing é outra opção - encontrar uma forma electrónica de apagar a unidade de disco rígido sob determinadas condições (como fisicamente removê-lo do caso).

A figura que, uma vez que o acesso físico é concedido, o invasor pode contornar suas senhas no entanto fortes que são, sem recorrer à força bruta.O primeiro que vem à mente é usando o "corrigir a palavra-passe" técnicas que a maioria dos sistemas de ter construído para ajudar administradores de sistemas que têm bloqueado & senhas perdidas.

Qualquer e todas as proteções de vir com um preço - tamperproofing é caro, já que você precisa de especialidade de hardware.A criptografia pode ser mais barato, mas ele afeta o tempo de inicialização.Também, eu tenho visto algumas surpresas desagradáveis com a forma como a criptografia de peças com aplicações - você nunca sabe até que você tente usá-lo.

Answer 2

O pensamento padrão é quando alguém se senta no servidor, está comprometido, final da história. As coisas só pioram se agarrarem o disco rígido e levá -lo a um laboratório para abrir e analisar.

Eu poderia começar com criptografia de tração inteira, bem como criptografia por campo no banco de dados. Você pode olhar em volta para ver se há uma maneira de ter um acesso baseado em biométrico ao hardware do disco rígido instalado no servidor. Além disso, você deseja desenterrar um empreiteiro de segurança física e obter suas recomendações para configuração; também contrate guardas.

Quero dizer, se este é um cenário que pode razoavelmente acontecer ...

editar:

Se eu tivesse um arquivo Postgres DB em que eu queria entrar e tinha os recursos (ou seja, gastando 4K para alguns Dells baratos), eu usaria uma configuração Beowulf e realizava rachaduras de força bruta paralela. As coisas pioram se eu começar a ter mais dinheiro e pode configurar, digamos, várias dessas doces máquinas NVIDIA Supercomputer-on-Desktop conectadas para realmente começar a forçar uma senha.

Se o ladrão levar a sério o fato de entrar nele e você não tem segurança já planejada desde o dia 0, seu arquivo de banco de dados será aberto como uma lata de sardinha.

Answer 3

Se você não está criptografando o disco rígido/sistema de arquivos, está praticamente sem sorte, pois o Postgres não oferece criptografia nativa. E criptografar o disco rígido é o único método real de proteção para um servidor roubado.

Basicamente, o que você precisaria fazer é criptografar o disco rígido ou o sistema de arquivos, e você precisaria inserir a senha quando montar a unidade, manualmente, cada vez que a máquina inicia, antes de o Postgres acionar.

Answer 4

Este artigo parece ser especialmente relevante para sua pergunta:

Segurança total em um banco de dados PostgreSQL
http://www.ibm.com/developerworks/opensource/library/osposgresecurity/

Answer 5

Eu não acho que este seja um problema PostGresql ou qualquer outro endereço de banco de dados. Mesmo que o banco de dados seja protegido por senha, todos os dados estão em texto simples e é isso que realmente importa. Nada está impedindo o atacante de gato o arquivo de banco de dados RAW e tubá -lo por seqüências de caracteres. A melhor solução para esse tipo de ataque é usar um sistema de arquivos criptografado. Isso exigiria que você digite uma senha para montar a partição. Isso também aumenta a sobrecarga.

Answer 6

Para a pergunta específica publicada (e a que eu vim em busca de uma resposta), o PostgreSQL por padrão armazena os dados da tabela não criptografados. Olhando em volta nos arquivos em .../pgsql/9.2/dados/base/* Eu acho que essas mesas de loja em pedaços de 1,1 gigabyte, e consigo encontrar com sucesso strings ASCII nesses arquivos com grep. A partir da inspeção dos arquivos, parece que os dados são armazenados em colunas.

A partir dessas informações, acredito que poderia experimentar e escrever código para engenharia reversa das tabelas para criar uma cópia em um servidor para o qual não tenho a senha.

Portanto, confiar apenas em uma senha de banco de dados forte não atende ao seu dever de cuidado se você precisar proteger contra o risco de a mídia física ser roubada.

PostgreSQL Docs online Forneça algumas opções para criptografar dados em vários níveis, que para esse problema parecem ser limitados a um módulo para criptografar colunas específicas ou criptografar a mídia subjacente de alguma forma, como sugeriram outros entrevistados.

Answer 7

Um bom começo é ativar a criptografia completa do disco. Você também pode criptografar na camada de aplicativo. (por exemplo, dados criptografados antes de enviá -los para o banco de dados, armazenar a chave não acessível no servidor de banco de dados)