TLS, l’accès réseau et les privilèges SQL répondent à des questions différentes
Chiffrer une connexion, admettre une source et accorder une table sont trois décisions. Parcourez-les dans l’ordre avant de demander si TLS peut remplacer un VPN.
Quelqu’un propose de remettre à un client un identifiant PostgreSQL afin qu’une note de frais circule chiffrée de bout en bout. Un administrateur de bases de données a besoin d’une véritable session SQL, et quelqu’un d’autre propose à la place un formulaire web. Les deux propositions résolvent le mauvais problème, car aucune n’est partie de l’opération que le client effectue réellement. Parcourez les trois décisions dans l’ordre et la question de savoir si TLS peut remplacer un VPN se répond d’elle-même.
Partez de l’opération dont le client a besoin
Notez ce que le client doit accomplir. Déposer une note de frais, lire une ligne d’un rapport et exécuter une requête ponctuelle sont trois opérations différentes avec trois profils de risque différents.
Notez ensuite qui fait la demande. Un client, un agent de support et un administrateur ne sont pas interchangeables même lorsqu’ils touchent la même table. La différence décide de la part du langage de requête que le client devrait un jour voir.
La paire de réponses décide de l’interface. Tout ce qui suit relève de la mise en œuvre, et la plupart des débats sur le chiffrement sont en réalité des débats sur l’interface choisie.
Trois contrôles, trois décisions
TLS authentifié protège la connexion et décide quelles identités TLS sont acceptées. L’accès réseau décide quelles sources peuvent atteindre l’écouteur. L’autorisation de la base de données décide quels objets et quelles actions un rôle peut utiliser.
Aucun des trois ne remplace les autres, ce que le tableau rend explicite.
| 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 |
Lisez la ligne sur laquelle vous comptez avant d’en retirer une autre. La plupart de ces conceptions échouent parce qu’un contrôle a été supposé plutôt que configuré.
Le SQL direct laisse la politique de la base de données aux commandes
Avec une connexion directe approuvée, conservez à la fois la vérification de l’identité du service et la politique d’accès prévue. Activer TLS rend les connexions chiffrées disponibles ; il ne rejette pas les connexions non chiffrées, sauf si la configuration d’accès l’exige par des entrées hostssl.
Cette distinction mérite d’être vérifiée dans la configuration en cours plutôt que dans un modèle. Un serveur qui propose TLS et accepte du texte en clair n’est pas la conception que la plupart des gens croient avoir déployée. Lisez les règles d’accès et voyez quelles entrées l’exigent réellement. Cette seule vérification sépare un serveur capable de chiffrer d’un serveur seulement chiffré.
Utilisez des rôles dotés uniquement des privilèges nécessaires au travail, et examinez la propriété, l’appartenance héritée et les permissions accordées largement. Le modèle de privilèges de PostgreSQL est la limite d’autorité des objets de la base de données.
Un VPN peut restreindre quels appareils atteignent le service avant que l’authentification de la base de données n’ait lieu, et une passerelle d’accès peut faire quelque chose de similaire. Ni l’un ni l’autre ne supprime le besoin de maintenir le composant exposé, de gérer les identifiants et de limiter l’usage des ressources.
Les certificats clients sont un identifiant, pas une ACL
Un certificat client peut ajouter une exigence au moment de la connexion. Le paramètre clientcert peut exiger un certificat de confiance et, dans le mode le plus strict, une relation entre le nom du certificat et l’utilisateur de la base de données.
C’est un identifiant plus fort. Ce n’est pas une liste d’autorisation, et cela ne rend pas le serveur invisible, car le composant qui accepte la connexion traite toujours du trafic réseau et une poignée de main. Traiter un certificat comme une liste d’accès laisse les permissions réelles intactes. Cela tend aussi à élargir la distribution des certificats, ce qui crée le problème suivant.
Un certificat fort attaché à un rôle sur-privilégié produit un administrateur bien authentifié. Vérifiez le rôle avant de célébrer le certificat.
Choisissez l’interface la plus étroite quand elle convient
Pour une note de frais, un point de terminaison applicatif qui accepte la note, applique les règles métier et renvoie le résultat autorisé de cet utilisateur représente l’opération mieux qu’un compte SQL général.
L’application utilise ensuite sa propre identité restreinte dans la base de données, et le client ne reçoit jamais un langage de requête comme fonctionnalité. C’est une surface plus petite avec moins de façons de se tromper.
C’est une option de conception et non l’affirmation que le code applicatif serait automatiquement plus sûr. Ce code doit authentifier ses appelants, autoriser chaque action et valider ses entrées, et ses propres permissions dans la base de données comptent toujours.
Le SQL direct reste correct pour les personnes et les outils dont le travail approuvé l’exige. Qualifiez cette conception par des rôles, un périmètre réseau et des limites d’exploitation, et laissez les autres clients garder l’interface plus étroite. Mélanger les deux populations dans un seul rôle est là où les débats commencent.