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 :

Vue d’ensemble d’OCSP

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.

  1. Fail-Open

  2. 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

snowsql -o ocsp_fail_open=false

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 OCSP_FAIL_OPEN=false .. Utilisez la variable d’environnement $SIMBAINI pour localiser le fichier correspondant. Puis réglez OCSPFailOpen=false

SQL Alchemy

Voir les paramètres du pilote JDBC

Spark

Le connecteur Spark n’a pas de paramètre ocsp_fail_open. . Fail-close ne peut être conservé avec Spark que si vous utilisez le pilote JDBC.

Pilote Go

Effectuez l’une des opérations suivantes : . - Définissez le paramètre de connexion OCSPFailOpen dans Config sur ocspFailOpenTrue ou ocspFailOpenFalse, par exemple : . import ( ... sf "github.com/snowflakedb/gosnowflake ... ") . config: &Config{ Account: "xy12345", ...,  OCSPFailOpen: sf.ocspFailOpenFalse, ... } . - Définissez le paramètre de connexion ocspFailOpen dans la chaîne de connexion sur true ou false, par exemple, . user:pass@account/db/s?ocspFailOpen=false. . Notez les différences de casse (majuscules /minuscules). . Pour plus d’informations sur les paramètres de connexion Go, reportez-vous à la documentation gosnowflake GoDoc .

Node.js

Définissez le paramètre global ocspFailOpen=false. Pour plus de détails, voir Utilisation du pilote Node.js.

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 :

  1. Mettez à niveau leur client ou pilote vers sa dernière version (meilleure option).

  2. Continuez à utiliser le comportement Fail-Close.

  3. Désactivez la surveillance OCSP (c’est-à-dire en mode non sécurisé) comme décrit ici.

Meilleures pratiques

Afin de limiter les risques, Snowflake recommande les meilleures pratiques suivantes pour sécuriser les communications.

  1. Utilisez AWS PrivateLink et bloquez l’accès public à Snowflake.

  2. Autorisez les pilotes clients à s’exécuter uniquement sur les ordinateurs de bureau et les serveurs gérés.

  3. 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 AWS PrivateLink nécessite Business Critical (ou une version supérieure). Pour en savoir plus sur la mise à niveau, veuillez contacter le support de Snowflake.

Vérification de la communication avec votre site CA ou répondeur OCSP

Pour vérifier que la communication n’est pas bloquée :

Étape 1 : récupération de l’URL de votre certificat

Récupérez l’URL utilisée par Snowflake pour les vérifications OCSP sur votre certificat Snowflake signé :

  1. Dans Google Chrome, connectez-vous à l’interface Web Snowflake.

  2. Dans le coin supérieur droit de la fenêtre du navigateur, cliquez sur l’icône (« Personnaliser et contrôler Google Chrome »). Cliquez ensuite sur More Tools » Developer Tools.

  3. Le cadre Outils de développement apparaît. Dans le cadre, cliquez sur l’onglet Security.

  4. Cliquez sur le bouton View certificate, puis développez la section Details.

  5. Faites défiler les détails jusqu’à ce que vous trouviez l’extension correspondante et notez l’URL pour :

    Online Certificate Status Protocol (p. ex. http://ocsp.netsolssl.com)

    Par exemple :

    Viewing OCSP URL for certificate in Developer Tools

Ensuite, testez votre capacité à accéder à l’URL (voir Étape 2). Divers problèmes réseau pourraient empêcher le client Snowflake d’accéder à l’URL. Par exemple, votre pare-feu peut bloquer l’accès aux sites utilisés par Snowflake.

Étape 2 : testez l’URL

Effectuez les étapes spécifiques au système d’exploitation pour vérifier si vous pouvez atteindre l’URL (<url_ocsp>) que vous avez récupérée à l’étape 1 :

Windows
  1. Ouvrir une fenêtre PowerShell sur l’hôte où le problème de connectivité persiste.

  2. Exécutez la commande suivante :

    Invoke-WebRequest <ocsp_url>
    

    La commande Invoke-WebRequest envoie une requête HTTP à une page Web ou un service Web, et renvoie une réponse.

Linux / macOS
  1. Ouvrez un terminal sur l’hôte où le problème de connectivité persiste.

  2. Exécutez la commande suivante :

    curl -I <ocsp_url>
    

En cas de succès, la commande retournera des résultats similaires à :

HTTP/1.1 200 OK
Server: Apache
X-OCSP-Responder-ID: dwdccaocsp27
Content-Length: 5
Content-Type: application/ocsp-response
Date: Thu, 09 Aug 2018 19:19:20 GMT
Connection: keep-alive

Si la commande renvoie une erreur, signalez le problème à votre administrateur réseau pour un diagnostic plus approfondi. Il sera peut-être nécessaire de mettre explicitement l’hôte OCSP sur une liste blanche pour vérifier votre certificat.

Si la commande renvoie un code de statut autre que 200, contactez l’assistance 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 région Snowflake 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

ocsp.snowflakecomputing.com:80

Serveur de cache de réponse OCSP de Snowflake. Notez que le nom d’hôte est différent si AWS PrivateLink est activé.

*.amazontrust.com:80

*.digicert.com:80

*.netsolssl.com:80

*.ss2.us:80

*.usertrust.com:80

Snowflake sur Microsoft Azure

Hôte

US Est 2

Remarques

ocsp.snowflakecomputing.com:80

Serveur de cache de réponse OCSP de Snowflake.

*.digicert.com:80

*.msocsp.com:80

Snowflake sur Google Cloud Platform

Hôte

us-central1

Remarques

ocsp.snowflakecomputing.com:80

Serveur de cache de réponse OCSP de Snowflake.

ocsp.digicert.com:80

ocsp.pki.goog:80

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/SSL. À 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)