Chris Travers's questions

Estou analisando a possibilidade de ter que armazenar senhas de root para máquinas virtuais em formato criptografado reversivelmente em um banco de dados. O motivo é que, às vezes, os logins locais serão necessários para as máquinas, tanto quanto são desencorajados e precisamos ser capazes de procurar senhas de root. O acesso, é claro, seria fortemente restrito a alguns administradores. Eles não seriam usados, exceto quando a vm estiver inacessível pela rede. A sincronização de usuários e senhas a esse respeito apresenta problemas semelhantes, ou seja, se a rede estiver inativa, como o sudoer faz login com a senha mais recente garantida?

Qual é a melhor maneira de planejar a rotação das chaves? Devo usar apenas uma frase secreta que todo administrador possui? Isso levanta algumas bandeiras vermelhas em minha mente. Existe uma maneira de gerenciar com segurança as chaves de forma que os administradores possam definir suas próprias senhas? Talvez use criptografia de chave pública e criptografe uma chave simétrica com a chave pública de cada administrador?

Aqui, estou procurando apenas esboços gerais de uma solução em relação ao gerenciamento de chaves de dados confidenciais criptografados. Se eu não conseguir descobrir como implementar a partir desse nível, posso fazer mais perguntas.

Abaixo está uma versão muito resumida de um projeto no qual estou trabalhando.

CREATE TABLE cidr_block (
    id serial not null unique,
    block_def cidr primary key,
    dhcp_server_id int not null references computer_system (id),
    ...
);
CREATE TABLE ip_addr (
    computer_id int not null references computer_system (id),
    mac_addr macaddr not null unique,
    ip_addr inet not null unique,
);

Este é um banco de dados de configuração de rede. Agora, espera-se que a maioria, mas não todos, os registros ip_addr.ip_addr estejam em blocos cidr_block.block_def. Outros, que podem ser interfaces vpn vinculadas externamente a locais de clientes, podem não ser. Não há uma maneira simples e declarativa de garantir uma fkey para as linhas aplicáveis ​​entre as duas tabelas. Então eu me pergunto:

1. É preferível usar gatilhos para criar links fkey quando apropriado?

2. É suficiente apenas entrar onde esperado? Se um computador receber um endereço IP inválido, ele simplesmente não receberá um do servidor dhcp, e saberemos disso rapidamente. (grava notificações de acionamento que acionam atualizações em servidores dhcp relevantes)

3. Existe outra maneira melhor?

Primeiro alguns antecedentes.

O projeto LedgerSMB é um projeto de software de contabilidade financeira de código aberto executado no PostgreSQL. Implementamos uma quantidade muito grande de lógica de negócios em funções definidas pelo usuário, que atuam como a principal ferramenta de mapeamento entre os métodos de objeto do programa e o comportamento do banco de dados. Atualmente, usamos usuários de banco de dados como usuários de autenticação, em parte por opção (isso permite uma lógica de segurança centralizada, para que outras ferramentas possam ser escritas e reutilizar as permissões dadas aos usuários) e em parte por necessidade (depois que bifurcamos do SQL-Ledger, há não havia muitas opções para atualizar a segurança nessa base de código).

Isso nos dá acesso a um número razoável de opções de conexão única às quais o PostgreSQL tem acesso, do LDAP ao Kerberos 5. Podemos até usar o PAM no que diz respeito às senhas. Também nos permite reutilizar permissões ao integrar com outros aplicativos ou permitir outras interfaces de cliente. Para um aplicativo de contabilidade financeira, isso parece uma vitória líquida.

Há custos óbvios envolvidos. Para o aplicativo da web, estamos muito limitados aos tipos de autenticação http que podem ser suportados. DIGEST, por exemplo, está totalmente fora. O BASIC funciona e poderíamos implementar o KRB5 com bastante facilidade (pretendo ter isso suportado e funcionando imediatamente para 1.4). Medidas de autenticação muito fortes não podem ser gerenciadas adequadamente diretamente, embora provavelmente possamos corrigi-las, se necessário (por exemplo, BASIC + certificado SSL do lado do cliente com um cn correspondente ao nome do usuário e uma raiz específica ca).

Ao mesmo tempo, recebemos muitas críticas, principalmente do pessoal do desenvolvimento e, mais ocasionalmente, de dba's que me dizem que o aplicativo deve ser a barreira de segurança, não o banco de dados. Minha opinião ainda é que um perímetro de segurança menor geralmente é melhor, que a reutilização da lógica de negócios e da lógica de segurança andam juntas e que me parece perigoso reutilizar a lógica de negócios sem reutilizar a lógica de segurança no mesmo nível do programa.

Estou perdendo alguma compensação importante aqui? Existem pegadinhas que não estou considerando?

Estou usando o PostgreSQL, mas acho que a maioria dos bancos de dados de ponta deve ter alguns recursos semelhantes e, além disso, que as soluções para eles podem inspirar soluções para mim, portanto, não considere isso específico do PostgreSQL.

Sei que não sou o primeiro a tentar resolver esse problema, então acho que vale a pena perguntar aqui, mas estou tentando avaliar os custos de modelar dados contábeis de forma que cada transação seja fundamentalmente equilibrada. Os dados contábeis são apenas anexos. A restrição geral (escrita em pseudo-código) aqui pode ser mais ou menos assim:

CREATE TABLE journal_entry (
    id bigserial not null unique, --artificial candidate key
    journal_type_id int references  journal_type(id),
    reference text, -- source document identifier, unique per journal
    date_posted date not null,
    PRIMARY KEY (journal_type_id, reference)
);

CREATE TABLE journal_line (
    entry_id bigint references journal_entry(id),
    account_id int not null references account(id),
    amount numeric not null,
    line_id bigserial not null unique,
    CHECK ((sum(amount) over (partition by entry_id) = 0) -- this won't work
);

Obviamente, tal restrição de verificação nunca funcionará. Ele opera por linha e pode verificar todo o banco de dados. Portanto, sempre falhará e será lento ao fazê-lo.

Então, minha pergunta é qual é a melhor maneira de modelar essa restrição? Eu basicamente olhei para duas ideias até agora. Querendo saber se estes são os únicos, ou se alguém tem uma maneira melhor (além de deixá-lo no nível do aplicativo ou em um procedimento armazenado).

1. Eu poderia pegar emprestado uma página do conceito do mundo da contabilidade sobre a diferença entre um livro de entrada original e um livro de entrada final (diário geral versus razão geral). A esse respeito, eu poderia modelar isso como uma matriz de linhas de diário anexadas à entrada do diário, impor a restrição na matriz (em termos do PostgreSQL, selecione sum(amount) = 0 de unnest(je.line_items). Um gatilho pode expandir e salve-os em uma tabela de itens de linha, onde as restrições de colunas individuais podem ser aplicadas com mais facilidade e onde os índices, etc., podem ser mais úteis. Essa é a direção em que estou inclinado.
2. Eu poderia tentar codificar um gatilho de restrição que aplicaria isso por transação com a ideia de que a soma de uma série de 0s sempre será 0.

Estou pesando isso contra a abordagem atual de impor a lógica em um procedimento armazenado. O custo da complexidade está sendo pesado contra a ideia de que a prova matemática de restrições é superior aos testes de unidade. A principal desvantagem do nº 1 acima é que os tipos como tuplas são uma daquelas áreas no PostgreSQL em que se depara com comportamento inconsistente e mudanças nas suposições regularmente e, portanto, espero que o comportamento nessa área mude com o tempo. Projetar uma futura versão segura não é tão fácil.

Existem outras maneiras de resolver esse problema que serão dimensionados para milhões de registros em cada tabela? Estou esquecendo de algo? Existe uma troca que eu perdi?

Em resposta ao ponto de Craig abaixo sobre as versões, no mínimo, isso terá que ser executado no PostgreSQL 9.2 e superior (talvez 9.1 e superior, mas provavelmente podemos usar o 9.2 direto).