TLS, entrada de rede e privilégios SQL respondem a perguntas diferentes
Cifrar uma conexão, admitir uma origem e conceder uma tabela são três decisões. Percorra-as em ordem antes de perguntar se o TLS pode substituir uma VPN.
Alguém propõe entregar a um cliente um início de sessão PostgreSQL para que um pedido de despesas viaje cifrado de ponta a ponta. Um administrador de bases de dados precisa de uma sessão SQL real, e outra pessoa propõe em vez disso um formulário web. Ambas as propostas resolvem o problema errado, porque nenhuma partiu da operação que o cliente executa de facto. Percorra as três decisões em ordem e a pergunta sobre se o TLS pode substituir uma VPN responde-se sozinha.
Comece pela operação de que o cliente precisa
Anote o que o cliente tem de alcançar. Submeter um pedido, ler uma linha de um relatório e executar uma consulta ad hoc são três operações diferentes com três perfis de risco diferentes.
Depois anote quem faz o pedido. Um cliente, um agente de suporte e um administrador não são intermutáveis mesmo quando tocam na mesma tabela. A diferença decide quanto da linguagem de consulta o cliente deveria alguma vez ver.
O par de respostas decide a interface. Tudo o que vem depois é implementação, e a maioria das discussões sobre cifra são na realidade discussões sobre que interface foi escolhida.
Três controlos, três decisões
O TLS autenticado protege a ligação e decide que identidades TLS são aceites. A entrada de rede decide que origens podem sequer chegar ao ouvinte. A autorização da base de dados decide que objetos e ações um papel pode usar.
Nenhum dos três substitui os outros, o que a tabela torna explícito.
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
Leia a linha em que se apoia antes de remover outra. A maioria destes desenhos falha porque um controlo foi assumido em vez de configurado.
O SQL direto mantém a política da base de dados responsável
Com uma ligação direta aprovada, mantenha tanto a verificação da identidade do serviço como a política de acesso pretendida. Ativar o TLS torna as ligações cifradas disponíveis; não rejeita as não cifradas, a menos que a configuração de acesso o exija através de entradas hostssl.
Vale a pena verificar essa distinção na configuração em execução e não num modelo. Um servidor que oferece TLS e aceita texto simples não é o desenho que a maioria pensa ter implementado. Leia as regras de acesso e veja que entradas o exigem realmente. Essa única verificação separa um servidor capaz de cifrar de um servidor apenas cifrado.
Use papéis apenas com os privilégios de que o trabalho precisa, e reveja a propriedade, a pertença herdada e as permissões concedidas de forma ampla. O modelo de privilégios do PostgreSQL é o limite de autoridade para os objetos da base de dados.
Uma VPN pode restringir que dispositivos chegam ao serviço antes de a autenticação da base de dados acontecer, e um gateway de acesso pode fazer algo semelhante. Nenhum dos dois elimina a necessidade de manter o componente exposto, gerir credenciais e limitar o uso de recursos.
Os certificados de cliente são uma credencial, não uma ACL
Um certificado de cliente pode acrescentar um requisito no momento da ligação. O parâmetro clientcert pode exigir um certificado de confiança e, no modo mais rigoroso, uma relação entre o nome do certificado e o utilizador da base de dados.
Isso é uma credencial mais forte. Não é uma lista de autorização, e não torna o servidor invisível, porque o componente que aceita a ligação continua a processar tráfego de rede e um aperto de mão. Tratar um certificado como uma lista de acesso deixa as permissões reais intactas. Também tende a alargar a distribuição de certificados, o que cria o problema seguinte.
Um certificado forte ligado a um papel com privilégios excessivos produz um administrador bem autenticado. Verifique o papel antes de celebrar o certificado.
Escolha a interface mais estreita quando se adequar
Para um pedido de despesas, um endpoint de aplicação que aceita o pedido, aplica as regras de negócio e devolve o resultado permitido desse utilizador representa a operação melhor do que uma conta SQL genérica.
A aplicação usa depois a sua própria identidade restrita na base de dados, e o cliente nunca recebe uma linguagem de consulta como funcionalidade. É uma superfície mais pequena com menos formas de errar.
Esta é uma opção de desenho e não a afirmação de que o código da aplicação é automaticamente mais seguro. Esse código tem de autenticar os seus chamadores, autorizar cada ação e validar a sua entrada, e as suas próprias permissões na base de dados continuam a contar.
O SQL direto continua correto para pessoas e ferramentas cujo trabalho aprovado o exige. Qualifique esse desenho com papéis, alcance de rede e limites operacionais, e deixe os outros clientes ficar com a interface mais estreita. Misturar as duas populações num único papel é onde começam as discussões.