Dernières modifications apportées à la façon dont Snowflake gère OCSP

Dernières modifications apportées à la façon dont Snowflake gère OCSP

Les pilotes clients Snowflake (JDBC, ODBC, Python et autres) se connectent à divers points de terminaison via HTTPS, notamment le service Snowflake, AWS S3, Azure Blob Storage et Okta (lors de l’utilisation d’Okta pour l’authentification). Lorsqu’un pilote client Snowflake reçoit un certificat par l’un des points de terminaison dans le cadre d’une connexion HTTPS, il vérifie si le certificat HTTPS a été révoqué à l’aide OCSP (Protocole d’état de certificat en ligne).

Vous pouvez en savoir plus sur l’importance de la vérification de la révocation des certificats et sur la raison pour laquelle nous utilisons OCSP à cette fin. article de blog précédent. Pour une sécurité maximale, le pilote effectue la vérification OCSP non seulement pour le certificat du point de terminaison (c’est-à-dire le certificat feuille), mais également pour tous les certificats du chaîne de confiance jusqu’au certificat intermédiaire délivré par l’autorité de certification racine. Le pilote échoue la connexion si a) il reçoit un statut révoqué pour l’un des certificats de la chaîne, b) est incapable d’obtenir la réponse OCSP, ou c) reçoit une réponse OCSP non valide (telle qu’une réponse expirée ou une réponse avec une signature invalide). Le comportement caractérisé par (b) et (c) est appelé comportement de fermeture en cas d’échec dans ce blog.

Défis

La disponibilité de Snowflake dépend de la capacité de l’autorité de certification à être disponible et à produire des réponses OCSP correctes. Normalement, nous supposerions que les autorités de certification prendraient en charge un tel comportement attendu, mais au cours de l’année écoulée, nous avons rencontré de nombreux cas où les pilotes clients Snowflake n’ont pas réussi à se connecter aux points de terminaison parce que le répondeur CA OCSP est tombé en panne, a produit des réponses expirées ou a autorisé la signature. certificat expire sans les renouveler à temps.

Qu’est-ce qui change ?

Beaucoup d’entre vous ont créé des applications critiques sur Snowflake, et la disponibilité de votre application dépend de la disponibilité de Snowflake. Pour fournir une connectivité plus fiable à partir des pilotes Snowflake, nous modifions le comportement par défaut de la vérification de la révocation des certificats de fermeture en cas d’échec à ouverture en cas d’échec. Avec le comportement d’ouverture en cas d’échec, nous « enregistrons et continuons » au lieu d’échouer la connexion HTTPS dans les cas où l’autorité de certification n’est pas en mesure de nous fournir une réponse valide. Nous continuerons à échouer la connexion lorsque nous recevrons une réponse OCSP avec un statut révoqué. Il y aura une ligne de connexion avec le niveau de journalisation par défaut inclus avec chaque connexion établie sans vérification OCSP. La nouvelle option d’ouverture en cas de panne (par défaut) s’ajoute à l’option existante pour désactiver la vérification ocsp. Si vous ne voulez pas assumer le risque d’échec d’ouverture, configurez le comportement d’échec de fermeture en vous référant à la FAQ ci-dessous.

Vous pouvez surveiller les journaux du pilote client pour détecter le moment où des connexions en cas d’échec sont établies. La ligne de connexion contiendra des informations détaillées, notamment l’URL du point de terminaison, les détails du certificat et la raison pour laquelle la vérification OCSP est ignorée. Vous pouvez utiliser ces informations pour faire correspondre les mises à jour de problèmes connus publiées sur le Page d’état du flocon de neige. Si votre équipe de sécurité détecte une activité inhabituelle, vous pouvez désactiver temporairement cet accès client jusqu’à ce que l’enquête de votre équipe de sécurité soit terminée ou activer le comportement de fermeture en cas d’échec selon le processus indiqué dans la section FAQ ci-dessous.

Exemple de ligne de connexion

« ATTENTION!!! Utilisation de l’ouverture en cas de panne pour se connecter. Le pilote se connecte à un point de terminaison HTTPS sans vérification de révocation de certificat basée sur OCSP, car il n’a pas pu obtenir de réponse OCSP valide à utiliser auprès du répondeur CA OCSP. Détails  »

Le nouveau changement de comportement est disponible dans les dernières versions de :

  • Flocon de neige SnowSQL
  • Pilote JDBC flocon de neige
  • Pilote ODBC flocon de neige
  • Connecteur flocon de neige pour Python
  • SQL Alchemy (mise à niveau du connecteur Python sous-jacent vers la dernière version)
  • Connecteur d’étincelle de flocon de neige
  • Pilote Snowflake NodeJS

Remarque : Snowflake n’effectue pas de vérification OCSP pour le pilote .NET qui utilise le framework .NET sous-jacent pour vérifier la validité du certificat HTTPS.

De plus, Snowflake travaille en étroite collaboration avec les fournisseurs de CA et les plates-formes cloud (AWS et Azure) pour fournir un plus infrastructure fiable pour la vérification OCSP. Nous continuerons à chercher à améliorer la robustesse de la vérification de la révocation des certificats tout en nous assurant que l’infrastructure offre le plus haut niveau de disponibilité exigé par nos clients.

Appel à l’action

  1. Mettez à niveau les pilotes clients Snowflake vers la dernière version.
  2. Si vous ne pouvez pas mettre à niveau le pilote client pour une raison quelconque, alors désactiver la vérification OCSP (comme pour les applications partenaires BI et ETL/ELT).
  3. Surveillez les journaux du pilote client.
  4. Voir FAQ ci-dessous.

FAQ

Que fait Snowflake pour s’assurer que les applications partenaires récupèrent la dernière version du pilote ?

L’équipe Snowflake Partner Ecosystem travaille en étroite collaboration avec tous nos partenaires pour s’assurer qu’ils récupèrent les dernières versions de pilotes dès que possible.

Je souhaite conserver le comportement ocsp_fail_open actuel pour tous les pilotes lors de la mise à niveau vers la dernière version du pilote. Que devrais-je faire?

Suivez les instructions ci-dessous pour définir le paramètre en fonction du type de pilote afin de préserver le comportement de fermeture en cas d’échec :

SnowSQL

Passer le paramètre de connexion, snowsql -o ocsp_fail_open=false

(ou)

définissez ocsp_fail_open=false dans le fichier de configuration SnowSQL

Python

définir le paramètre de connexion ocsp_fail_open=false

JDBCName

définir la propriété de connexion « ocspFailOpen » sur false

(ou)

définissez la propriété système « net.snowflake.jdbc.ocspFailOpen » sur false

ODBC

Définissez le paramètre de connexion « OCSP_FAIL_OPEN » sur faux

(ou)

Définissez le paramètre de configuration OCSPFailOpen sur false dans le fichier pointé par la variable d’environnement $SIMBAINI

Quelles sont certaines des meilleures pratiques recommandées pour assurer la sécurité de mes communications ?

Voici quelques bonnes pratiques que vous pouvez utiliser pour assurer la sécurité des communications.

  1. Utilisez AWS PrivateLink pour maintenir la communication avec le service Snowflake hors de l’Internet public et désactiver l’accès public à Snowflake. Faire référence à Documentation PrivateLink pour plus de détails.
  2. Autoriser les pilotes clients à s’exécuter uniquement sur les postes de travail et les serveurs gérés.
  3. Envoyez les journaux des pilotes clients à un système de gestion des journaux ou téléchargez-les dans une base de données Snowflake, et surveillez les connexions établies sans vérification ocsp.

Conclusion

La vérification de la révocation des certificats est une étape importante pour assurer la sécurité des connexions HTTPS, et OCSP est le bon protocole pour effectuer une telle vérification. Snowflake continuera à travailler avec l’industrie (autorités de certification et plates-formes cloud) pour s’assurer qu’elles offrent une disponibilité maximale de leur infrastructure pour OCSP. Pendant ce temps, pour minimiser les interruptions lors de l’accès à Snowflake, mettez à jour les pilotes Snowflake dans vos applications clientes vers la dernière version à partir du 10 mai 2019, où le comportement de vérification OCSP passe à l’ouverture en cas d’échec. Si vous ne pouvez pas accepter le risque de connexions en cas d’échec, vous pouvez conserver le comportement actuel de fermeture en cas d’échec (qui peut entraîner des perturbations), en vous référant à la FAQ ci-dessus.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.