Configuration d’OCSP¶
Cette rubrique fournit une vue d’ensemble d’OCSP, son utilisation dans Snowflake et des informations pour diagnostiquer les problèmes de OCSP.
Dans ce chapitre :
Aperçu¶
Snowflake utilise le protocole de certificat en ligne (OCSP) pour fournir une sécurité maximale afin de déterminer si un certificat est révoqué lorsque les clients Snowflake tentent de se connecter à un point de terminaison via HTTPS.
Snowflake utilise OCSP pour évaluer chaque certificat de la chaîne de confiance jusqu’au certificat intermédiaire émis par l’autorité de certification racine (CA). S’assurer que chaque certificat n’est pas révoqué aide Snowflake à établir des connexions sécurisées avec des acteurs de confiance lors du processus de vérification de l’identité.
Selon la version de votre client ou de votre pilote et la configuration décrite sur cette page, il est possible de désactiver OCSP et d’ajuster l’action qui se produit lorsque OCSP détermine qu’un certificat est révoqué.
Comportements Fail-Open ou Fail-Close¶
Actuellement, les utilisateurs peuvent choisir entre deux comportements en ce qui concerne la réponse des clients ou des pilotes Snowflake lors d’un événement OCSP.
Fail-Open
Fail-Close
Fail-Open¶
Snowflake prend en charge une approche Fail-Open par défaut pour évaluer la réponse OCSP CA. L’approche Fail-Open présente les caractéristiques suivantes :
Une réponse indiquant qu’un certificat révoqué entraîne l’échec de la connexion.
Une réponse avec toute autre erreur ou statut de certificat permet la connexion, mais indique le message dans les journaux au niveau
WARNING
avec les détails pertinents au format JSON.
Les utilisateurs peuvent surveiller les journaux du pilote ou du connecteur spécifique afin de déterminer la fréquence des événements de journal Fail-Open.
Ces journaux d’événements peuvent être combinés à la page de statut de Snowflake pour déterminer la meilleure marche à suivre, telle que la restriction temporaire de l’accès client ou le basculement vers le comportement Fail-Close.
Actuellement, l’approche par défaut Fail-Open s’applique aux versions de client et de pilote suivantes.
Client/Pilote |
Version |
---|---|
SnowSQL |
v1.1.79 ou supérieure |
Connecteur Python |
v1.8.0 ou supérieure |
Pilote JDBC |
v3.8.0 ou supérieure |
Pilote ODBC |
v2.19.0 ou supérieure |
SQL Alchemy |
Mettre à niveau le connecteur Python vers la v1.8.0 ou une version supérieure |
Spark |
v2.4.14 ou une version supérieure si vous utilisez Maven ou SBT pour générer l’application Spark. . JDBC v3.8.0 ou une version supérieure si vous attachez des fichiers JAR à un cluster Spark. . Demandez à Databricks de mettre à niveau son connecteur Spark s’il utilise le connecteur intégré Spark de Databricks. |
Pilote Go |
v1.2.0 ou supérieure |
Node.js |
v1.2.0 ou supérieure |
Note
Snowflake ne prend pas en charge la vérification OCSP du pilote .NET. À la place, .NET utilise son propre framework pour vérifier la validité du certificat HTTPS.
Fail-Close¶
Le comportement Fail-Close est plus restrictif pour interpréter la réponse OCSP CA. Si le client ou le pilote ne reçoit pas une réponse de CA OCSP valide pour une raison quelconque, la connexion échoue.
Étant donné que ce comportement n’est pas basé par défaut sur les versions répertoriées dans la section Fail-Open, Fail-Close doit être configuré manuellement dans chaque pilote ou connecteur.
Pour préserver le comportement Fail-Close, définissez le paramètre ocsp_fail_open
correspondant sur false
.
Client/Pilote |
Réglage |
---|---|
SnowSQL |
|
Connecteur Python |
Pour plus de détails, voir Choix du mode Fail-Open ou Fail-Close dans la documentation du connecteur Python. |
Pilote JDBC |
Pour plus d’informations, voir Choix du mode Fail-Open ou Fail-Close dans la documentation du pilote JDBC. |
Pilote ODBC |
Choisissez l’une des options suivantes : . Définissez le paramètre de connexion sur |
SQL Alchemy |
Voir les paramètres du pilote JDBC |
Spark |
Le connecteur Spark n’a pas de paramètre |
Pilote Go |
Effectuez l’une des opérations suivantes : . - Définissez le paramètre de connexion |
Node.js |
Définissez le paramètre global |
Versions client et pilote existantes¶
Si la version de votre client ou de votre pilote est plus ancienne que celle indiquée dans la section relative à Fail-Open, le comportement Fail-Open n’est pas une option. Par conséquent, le comportement Fail-Close est le comportement par défaut.
Les déploiements Snowflake utilisant des versions de client et de pilote existantes en ce qui concerne OCSP présentent trois options :
Mettez à niveau leur client ou pilote vers sa dernière version (meilleure option).
Continuez à utiliser le comportement Fail-Close.
Désactivez la surveillance OCSP (c’est-à-dire en mode non sécurisé) comme décrit dans cet article de la base de connaissances (dans la communauté Snowflake).
Meilleures pratiques¶
Afin de limiter les risques, Snowflake recommande les meilleures pratiques suivantes pour sécuriser les communications.
Utilisez une connectivité privée au service Snowflake et bloquer l’accès public à Snowflake.
Autorisez les pilotes clients à s’exécuter uniquement sur les ordinateurs de bureau et les serveurs gérés.
Envoyez les journaux du pilote client à un système de gestion ou téléchargez-les sur Snowflake. Surveillez les connexions effectuées sans vérification OCSP.
Note
La prise en charge de la connectivité privée au service Snowflake nécessite Business Critical (ou supérieur). Pour en savoir plus sur la mise à niveau, veuillez contacter le support Snowflake.
Hôtes de site CA et de répondeur OCSP utilisés par Snowflake (par plateforme Cloud et région)¶
Snowflake utilise les hôtes suivants pour les contrôles de certification OCSP. Notez que les hôtes peuvent varier selon la Snowflake Region de la plate-forme Cloud donnée.
Important
Il s’agit ici un exemple des hôtes les plus fréquemment utilisés. Pour chaque région (ou compte individuel), Snowflake peut utiliser un certificat émis par une CA différente, ce qui donne des hôtes et URLs différents. Par exemple :
Pour la plupart des comptes dans US Ouest (sur AWS), Snowflake utilise actuellement des certificats signés Digicert de Network Solutions.
Pour les autres régions (sur AWS), Snowflake utilise principalement des certificats de la CA Amazon.
De plus, Snowflake peut changer les certificats lorsqu’ils expirent ou nécessitent des améliorations, ce qui créera des hôtes et URLs différents.
Pour une liste complète des hôtes et URLs pour votre compte, veuillez contacter l’assistance Snowflake.
Snowflake sur AWS¶
Hôte |
US Ouest |
Autres régions |
Remarques |
---|---|---|---|
|
✔ |
✔ |
Serveur de cache de réponse OCSP de Snowflake. Notez que le nom d’hôte est différent si AWS PrivateLink est activé. |
|
✔ |
✔ |
|
|
✔ |
✔ |
|
|
✔ |
||
|
✔ |
✔ |
|
|
✔ |
Snowflake sur Microsoft Azure¶
Hôte |
US Est 2 |
Remarques |
---|---|---|
|
✔ |
Serveur de cache de réponse OCSP de Snowflake. Notez que le nom d’hôte est différent si Azure Private Link est activé. |
|
✔ |
|
|
✔ |
Snowflake sur Google Cloud Platform¶
Hôte |
us-central1 |
Remarques |
---|---|---|
|
✔ |
Serveur de cache de réponse OCSP de Snowflake. |
|
✔ |
|
|
✔ |
Les contrôles de certification OCSP nécessitent le port 80.¶
Toute communication avec Snowflake se fait par le port 443. Cependant, les contrôles de certification OCSP sont transmis via le port 80. Si votre poste de travail se trouve derrière un pare-feu, assurez-vous que l’administrateur réseau de votre entreprise a ouvert le pare-feu au trafic sur les ports 443 et 80.
Les pilotes JDBC et ODBC n’utilisent plus CRL¶
Une CRL (liste de révocation de certificats) spécifie les certificats qui ont été explicitement révoqués par une CA donnée. Les anciennes versions des pilotes JDBC et ODBC utilisaient CRL ou OCSP pour vérifier les certificats TLS. À partir des versions suivantes, les pilotes n’utilisent que OCSP pour toutes les vérifications de certificat :
JDBC 3.5.0 (ou supérieur)
ODBC 2.15.0 (ou supérieur)