O que o DBMS é apropriado para manter um esquema privado, mesmo quando instalado 'na natureza'

Question

Eu tenho um servidor de aplicativos que se conecta a um servidor de banco de dados. Eu gostaria de poder fornecer aos usuários instaladores e, com um grau moderado de conforto, confie que o esquema do banco de dados é seguro.

Entendo que existem alguns riscos que terei que aceitar não controlar o computador no qual ele instalou - uma pessoa determinada com as ferramentas e o conhecimento certos podem olhar diretamente para a memória e extrair informações.

Inicialmente, pensei que minha área de foco seria simplesmente adicionar as credenciais ao instalador sem que elas fossem vistas trivialmente em um editor hexadecimente.

No entanto, quando comecei a pesquisar, aprendi que, no PostgreSQL, mesmo que eu instale o banco de dados silenciosamente e não forneça as credenciais ao usuário-elas podem simplesmente alterar um arquivo de configuração baseado em texto (pg_hba.conf) e Reinicie o servidor, permitindo acesso total ao banco de dados sem credenciais.

Este cenário é garantido em outros DBMs? Como a maioria dos produtos comerciais protege seus esquemas nesse cenário? A maioria dos produtos usaria bancos de dados incorporados?

---

EDIT: Presumo (talvez incorretamente) que alguns produtos dependem de bancos de dados que o usuário nunca toca diretamente. E, é claro, nunca os vejo porque eles o criaram de tal maneira que o usuário não precisa - provavelmente usando um banco de dados incorporado.

Answer 1

A maioria dos produtos comerciais não protege seus esquemas. Eles caem em um dos dois campos:

Eles estão usando um banco de dados de classe corporativa para um componente -chave do produto (como um sistema de folha de pagamento), caso em que não há nenhuma tentativa de ocultar o esquema/dados. Na maioria desses casos, o cliente precisa de controle sobre o banco de dados - para configurar como o banco de dados é apoiado, para poder fazer um ambiente em cluster, etc.

O outro caso é se o seu "banco de dados" não passa de um pequeno arquivo de configurações ou armazenamento para um aplicativo de desktop (por exemplo, os bancos de dados de histórico e marcador no Firefox). Nesse caso, você deve apenas usar um banco de dados incorporado (como o SQLite, o mesmo que o Firefox) e adicionar uma camada de criptografia de streaming (existe uma versão oficial disso chamada See), ou apenas use o banco de dados incorporado e esqueça a camada de criptografia, já que O usuário precisará instalar suas próprias ferramentas de banco de dados para ler o arquivo em primeiro lugar.

Answer 2

Tanto quanto me lembro, não há produtos comerciais que "proteger" seus esquemas. O que você deseja que o esquema seja protegido?

Considere os seguintes pontos:

• Afinal, a única pessoa que pode proteger qualquer coisa em um RDBMS é o administrador do servidor de banco de dados. E você quer que o esquema seja protegido contra essa pessoa?

• Se eu fosse um fantasor e tive meus dados Dentro do seu esquema, eu não apenas gostaria, mas espero poder vê -lo e consumi -lo diretamente.

• Você realmente precisa proteger seu design relacional? É realmente tão interessante? Você inventou algo que vale a pena esconder? Eu realmente não acho que não. E peço desculpas antecipadamente, se você tiver.

---

Editar: Comentário adicional:

Não me importo com a maioria dos internos do banco de dados para os produtos que uso. Essa é outra razão pela qual acho que a maioria deles não toma nenhuma ação para protegê -los. A maioria deles não é tão interessante.

Por um lado, acredito firmemente que os usuários não precisam saber ou se preocupar com os internos do banco de dados. Mas, no mesmo nível, como desenvolvedor, não acho que vale a pena tentar protegê -los. Escondendo -os do usuário, sim. Proteja -os contra o acesso direto, na maioria dos casos, não. E não porque acho que é errado proteger seu esquema. É porque acho que é uma coisa muito difícil de fazer, e não vale a pena o seu tempo como desenvolvedor.

Mas no final, como em qualquer tópico relacionado à segurança, a única resposta certa é sobre quais são os riscos envolvido vs o custos de implementar a medida de segurança.

Os mecanismos de banco de dados atuais, incorporados ou em estilo de servidor, não foram projetados para ocultar facilmente o esquema do banco de dados e, portanto, o custo de desenvolvimento de fazê-lo é muito maior que o risco envolvido para a maioria das pessoas.

Mas seu caso pode ser diferente.

Answer 3

Que problema você está tentando resolver? Nada pode impedir que o DBA* faça o que quiser para bancos de dados padrão e, como outros apontaram, é ativamente hostil interferir com necessidades específicas do site, como backups e atualizações de banco de dados. No máximo, você pode criptografar o conteúdo do seu banco de dados, mas mesmo assim você precisa fornecer uma chave de descriptografia para o seu aplicativo realmente executar e um DBA motivado e hostil provavelmente pode subvertê -lo.

As comunidades militares e de inteligência, sem dúvida, têm bancos de dados em que até o esquema é altamente classificado, mas não sei se eles são protegidos por meios técnicos ou apenas homens grandes com armas.

(*) DBA ou administrador do sistema capaz de modificar arquivos como pg_hba.conf.

Answer 4

Como a maioria dos produtos comerciais protege seus esquemas nesse cenário?

Não acredito que a maioria dos produtos comerciais faça qualquer coisa para proteger seus esquemas.

Answer 5

Como um DBMS incorporado pode impedir alguém para mexer com seu armazenamento (arquivos neste contexto de hardware não embutido) quando essa pessoa tem acesso físico à máquina onde esse DBMS está em execução? Segurança através da obscuridade é uma proposta arriscada.

Answer 6

Essa idéia sofrerá com os mesmos problemas que o DRM. Você não pode impedir o acesso pelos determinados e só causará dor e sofrimento geral para seus clientes. Só não faça isso.

O SQLite envolve todo o seu formato de banco de dados em um único arquivo e você pode criptografar e descriptografá-lo no local. A falha, é claro, é que os usuários precisam da chave para usar o banco de dados agora, e a única maneira de acontecer é se você der a eles, talvez codificando-o em tempo de compilação (segurança pela obscuridade) ou Um esquema de casas por telefone (todo o host de razões pelas quais essa é uma má idéia). Além disso, agora eles o odeiam porque você frustrou qualquer tentativa de um sistema de backup útil e eles têm um desempenho terrível para inicializar.

Além disso, ninguém realmente se importa com os esquemas. Odeio quebrar isso para você, mas o design do esquema não é um problema difícil, e certamente nunca é uma vantagem competitiva legítima (fora de talvez algumas áreas específicas, como representação de conhecimento e data warehousing). Os esquemas geralmente não valem a pena proteger em primeiro lugar.

Se for realmente tão importante para você, faça um aplicativo hospedado.