Query Service les options SSL

Dernière mise à jour : 4 avril 2025

Créé pour :

  • Utilisateur ou utilisatrice
  • Développeur

Pour une sécurité renforcée, Adobe Experience Platform Query Service fournit une prise en charge native des connexions SSL pour chiffrer les communications client/serveur. Ce document couvre les options SSL disponibles pour les connexions clientes tierces à Query Service et comment se connecter à l’aide de la valeur du paramètre SSL verify-full.

Conditions préalables

Ce document suppose que vous avez déjà téléchargé une application cliente de bureau tierce à utiliser avec vos données Experience Platform. Vous trouverez des instructions spécifiques sur la manière d’incorporer la sécurité SSL lors de la connexion à un client tiers dans la documentation de leur guide de connexion respectif. Pour obtenir la liste de tous Query Service clients pris en charge, reportez-vous à la présentation des connexions client.

Options SSL disponibles

Experience Platform prend en charge différentes options SSL pour répondre à vos besoins en matière de sécurité des données et équilibrer la charge de traitement du chiffrement et de l’échange de clés.

Les différentes valeurs de paramètre sslmode fournissent différents niveaux de protection. En chiffrant vos données en mouvement à l’aide de certificats SSL, il contribue à empêcher les attaques « man-in-the-middle » (MITM), les écoutes et l’emprunt d’identité. Le tableau ci-dessous présente une répartition des différents modes SSL disponibles et le niveau de protection qu’ils offrent.

NOTE
La valeur SSL disable n’est pas prise en charge par Adobe Experience Platform en raison de la conformité en matière de protection des données.
sslmode
Protection contre les écoutes
Protection MITM
Description
allow
Oui
Non
Le chiffrement est requis pour toutes les communications. Le réseau est approuvé pour se connecter au serveur approprié.
prefer
Oui
Non
Le chiffrement est requis pour toutes les communications. Le réseau est approuvé pour se connecter au serveur approprié.
require
Oui
Non
Le chiffrement est requis pour toutes les communications. Le réseau est approuvé pour se connecter au serveur approprié. La validation du certificat SSL du serveur n’est pas requise.
verify-ca
Oui
Dépend de la politique de l’autorité de certification
Le chiffrement est requis pour toutes les communications. La validation du serveur est requise avant le partage des données. Pour ce faire, vous devez configurer un certificat racine dans votre répertoire racine PostgreSQL. Des détails sont fournis ci-dessous
verify-full
Oui
Oui
Le chiffrement est requis pour toutes les communications. La validation du serveur est requise avant le partage des données. Pour ce faire, vous devez configurer un certificat racine dans votre répertoire racine PostgreSQL. Des détails sont fournis ci-dessous.
NOTE
La différence entre verify-ca et verify-full dépend de la politique de l’autorité de certification racine (CA). Si vous avez créé votre propre autorité de certification locale pour émettre des certificats privés pour vos applications, l’utilisation de verify-ca offre souvent une protection suffisante. Si vous utilisez une autorité de certification publique, verify-ca autorise les connexions à un serveur que quelqu’un d’autre a peut-être enregistré auprès de l’autorité de certification. verify-full doit toujours être utilisé avec une autorité de certification racine publique.

Lors de l’établissement d’une connexion tierce à une base de données Experience Platform, il est recommandé d’utiliser au minimum sslmode=require pour assurer une connexion sécurisée à vos données en mouvement. Le mode SSL verify-full est recommandé pour une utilisation dans la plupart des environnements sensibles à la sécurité.

Configurer un certificat racine pour la vérification du serveur

IMPORTANT
Les certificats TLS/SSL sur les environnements de production pour l’API Interactive Postgres de Query Service ont été actualisés le mercredi 24 janvier 2024.
Bien qu’il s’agisse d’une exigence annuelle, le certificat racine de la chaîne a également changé cette fois-ci, car le fournisseur de certificats TLS/SSL d’Adobe a mis à jour sa hiérarchie de certificats. Cela peut avoir un impact sur certains clients Postgres si leur liste d’autorités de certification ne dispose pas du certificat racine. Par exemple, un client de ligne de commande PSQL peut avoir besoin que les certificats racines soient ajoutés à une ~/postgresql/root.crt de fichier explicite, sinon cela peut entraîner une erreur. Par exemple : psql: error: SSL error: certificate verify failed. Voir la documentation officielle de PostgreSQL pour plus d’informations sur ce problème.
Le certificat racine à ajouter peut être téléchargé depuis https://cacerts.digicert.com/DigiCertGlobalRootG2.crt.pem.

Pour garantir une connexion sécurisée, l’utilisation de SSL doit être configurée à la fois sur le client et le serveur avant que la connexion ne soit établie. Si le protocole SSL est uniquement configuré sur le serveur, le client peut envoyer des informations sensibles telles que des mots de passe avant qu’il ne soit établi que le serveur requiert une sécurité élevée.

Par défaut, PostgreSQL n’effectue aucune vérification du certificat du serveur. Pour vérifier l’identité du serveur et garantir une connexion sécurisée avant l’envoi de données sensibles (dans le cadre du mode de verify-full SSL), vous devez placer un certificat racine (autosigné) sur votre ordinateur local (root.crt) et un certificat feuille signé par le certificat racine sur le serveur.

Si le paramètre sslmode est défini sur verify-full, libpq vérifie que le serveur est fiable en vérifiant la chaîne de certificats jusqu’au certificat racine stocké sur le client. Il vérifie ensuite que le nom d’hôte correspond au nom stocké dans le certificat du serveur.

Pour permettre la vérification du certificat du serveur, vous devez placer un ou plusieurs certificats racine (root.crt) dans le fichier PostgreSQL de votre répertoire personnel. Le chemin d’accès au fichier serait similaire à ~/.postgresql/root.crt.