TLS, a entrada de rede e os privilexios SQL responden a preguntas distintas
Cifrar unha conexión, admitir unha orixe e conceder unha táboa son tres decisións. Percórraas en orde antes de preguntar se TLS pode substituír unha VPN.
Alguén propón entregar a un cliente un inicio de sesión de PostgreSQL para que unha solicitude de gastos viaxe cifrada de extremo a extremo. Un administrador de bases de datos necesita unha sesión SQL real, e outra persoa propón no seu lugar un formulario web. Ambas propostas resolven o problema equivocado, porque ningunha partiu da operación que o cliente realiza realmente. Percorra as tres decisións en orde e a pregunta sobre se TLS pode substituír unha VPN respóndese soa.
Comece pola operación que necesita o cliente
Anote que debe acadar o cliente. Enviar unha solicitude, ler unha fila dun informe e executar unha consulta ad hoc son tres operacións distintas con tres perfís de risco distintos.
Despois anote quen fai a petición. Un cliente, un axente de soporte e un administrador non son intercambiables aínda que toquen a mesma táboa. A diferenza decide canto da linguaxe de consultas debería ver algunha vez o cliente.
O par de respostas decide a interface. Todo o posterior é implementación, e a maioría das discusións sobre cifrado son en realidade discusións sobre que interface se escolleu.
Tres controis, tres decisións
TLS autenticado protexe a conexión e decide que identidades TLS se aceptan. A entrada de rede decide que orixes poden chegar sequera ao proceso que escoita. A autorización da base de datos decide que obxectos e accións pode usar un rol.
Ningún dos tres substitúe os demais, o que a táboa fai 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 |
Lea a fila na que se apoia antes de quitar outra. A maioría destes deseños fallan porque un control se supuxo en lugar de configurarse.
O SQL directo mantén ao mando a política da base de datos
Cunha conexión directa aprobada, conserve tanto a verificación da identidade do servizo como a política de acceso prevista. Activar TLS pon á disposición as conexións cifradas; non rexeita as non cifradas salvo que a configuración de acceso o esixa mediante entradas hostssl.
Esa distinción merece comprobarse na configuración en execución e non nun modelo. Un servidor que ofrece TLS e acepta texto simple non é o deseño que a maioría cre pensar que despregou. Lea as regras de acceso e vexa que entradas o esixen realmente. Esa única comprobación separa un servidor capaz de cifrar dun só cifrado.
Use roles só cos privilexios que o traballo necesita, e revise a propiedade, a pertenza herdada e os permisos concedidos de forma ampla. O modelo de privilexios de PostgreSQL é o límite de autoridade para os obxectos da base de datos.
Unha VPN pode restrinxir que dispositivos chegan ao servizo antes de que ocorra a autenticación da base de datos, e unha pasarela de acceso pode facer algo semellante. Ningunha das dúas elimina a necesidade de manter o compoñente exposto, xestionar credenciais e limitar o uso de recursos.
Os certificados de cliente son unha credencial, non unha ACL
Un certificado de cliente pode engadir un requisito no momento da conexión. O parámetro clientcert pode esixir un certificado de confianza e, no modo máis estrito, unha relación entre o nome do certificado e o usuario da base de datos.
Iso é unha credencial máis forte. Non é unha lista de autorización, e non fai invisible o servidor, porque o compoñente que acepta a conexión segue procesando tráfico de rede e un saúdo. Tratar un certificado como unha lista de acceso deixa intactos os permisos reais. Tamén tende a ampliar a distribución de certificados, o que crea o problema seguinte.
Un certificado forte unido a un rol con privilexios excesivos produce un administrador ben autenticado. Revise o rol antes de celebrar o certificado.
Escolla a interface máis estreita cando encaixe
Para unha solicitude de gastos, un punto final de aplicación que acepta a solicitude, aplica as regras de negocio e devolve o resultado permitido dese usuario representa a operación mellor ca unha conta SQL xeral.
A aplicación usa despois a súa propia identidade restrinxida na base de datos, e o cliente nunca recibe unha linguaxe de consultas como funcionalidade. Esa é unha superficie máis pequena con menos formas de equivocarse.
Esta é unha opción de deseño e non a afirmación de que o código de aplicación sexa automaticamente máis seguro. Ese código ten que autenticar as súas chamadas, autorizar cada acción e validar a súa entrada, e os seus propios permisos na base de datos seguen importando.
O SQL directo segue sendo correcto para persoas e ferramentas cuxo traballo aprobado o require. Cualifique ese deseño con roles, alcance de rede e límites operativos, e deixe que os demais clientes manteñan a interface máis estreita. Mesturar as dúas poboacións nun só rol é onde comezan as discusións.