Sécurisation d’une fonction externe

Cette rubrique décrit les détails indépendants de la plate-forme liés à la sécurisation des fonctions externes.

Dans ce chapitre :

Contrôle d’accès

Fonctions externes

Les fonctions externes, comme toutes les fonctions définies par l’utilisateur (UDFs), suivent les règles de contrôle d’accès:

  • Les fonctions externes ont un propriétaire.

  • Le propriétaire doit accorder aux appelants (autres que le propriétaire) les privilèges appropriés sur la fonction.

Cependant, les fonctions externes ont des exigences de privilège supplémentaires :

  • Etant donné qu’une fonction externe nécessite une intégration API, l’auteur de la fonction externe doit disposer du privilège USAGE sur l’intégration API.

Pour plus d’informations sur les UDFs et le contrôle d’accès, voir Privilèges de contrôle d’accès.

Intégrations API

Privilèges et intégrations API

Une intégration API est un objet de base de données. Pour créer une intégration API, vous avez besoin de privilèges ACCOUNTADMIN ou d’un rôle Snowflake avec le privilège CREATE INTEGRATION. Les administrateurs de compte peuvent accorder et révoquer des privilèges de propriété et d’utilisation sur chaque intégration API.

Utilisation de l’option API_KEY dans CREATE API INTEGRATION

Certains services proxy (API Gateways) demandent aux utilisateurs de fournir des informations sur l’abonnement (ou d’autres informations relatives au produit) lorsqu’ils appellent le service proxy. Les informations relatives à l’abonnement peuvent être utilisées pour authentifier que l’utilisateur est un client payant, appliquer des quotas d’utilisation, etc.

Snowflake prend désormais en charge les clés API, également appelées clés d’abonnement (terme utilisé par Microsoft Azure), qui sont des valeurs de chaînes qu’un développeur peut distribuer aux utilisateurs qui doivent fournir des informations sur leur abonnement.

Les utilisateurs peuvent fournir ces clés à Snowflake en utilisant la clause API_KEY de l’instruction CREATE API INTEGRATION ou l’instruction ALTER API INTEGRATION. La clause API_KEY est facultative ; vous pouvez l’omettre si le service n’a pas besoin de clé.

Une API_KEY s’ajoute à un IAM et ne le remplace pas (Gestion des identités et des accès).

Les clés API sont sensibles. Elles ne sont pas affichées dans :

  • Commandes de l’historique des requêtes.

  • Commandes DESCRIBE INTEGRATION.

  • Commandes DESCRIBE APIINTEGRATION.

Le développeur du service choisit le format de la clé. La clé est opaque pour Snowflake, et Snowflake ne la valide pas.

Vous pouvez en savoir plus sur les clés API sur des plateformes spécifiques en suivant les liens ci-dessous :

Sécuriser le service proxy

À moins que votre fonction externe ne soit destinée à être accessible au public, Snowflake recommande fortement de sécuriser vos points de terminaison de service proxy.

Snowflake utilise des objets d’intégration API sans informations d’identification pour s’authentifier auprès du point de terminaison du service proxy. Les intégrations API sans informations d’identification séparent les responsabilités entre les administrateurs et les utilisateurs. Une intégration API permet à un administrateur de créer une politique de confiance entre Snowflake et le fournisseur Cloud à l’aide du mécanisme d’authentification et d’autorisation natif du fournisseur Cloud. Lorsque Snowflake se connecte au fournisseur Cloud, le fournisseur Cloud authentifie et autorise l’accès via cette politique de confiance. A l’aide d’une intégration API spécifique, l’administrateur peut également spécifier une liste autorisée de points de terminaison auxquels l’objet d’intégration API peut accéder ; cela limite les services proxy et les ressources que Snowflake peut utiliser, ce qui permet à l’administrateur d’appliquer des politiques organisationnelles pour la sortie et l’entrée de données.

Des instructions plus détaillées pour sécuriser des points de terminaison de service proxy spécifiques, tels qu’une Amazon API Gateway, figurent dans les instructions spécifiques à la plate-forme.

Sécurisez le service distant

Si vous avez créé votre propre service distant, n’oubliez pas de le sécuriser.

Les détails dépendent de l’implémentation du service distant et sortent du cadre de ce document.

Dans la plupart des cas, le service distant doit utiliser HTTPS, pas HTTP.

Informations de sécurité supplémentaires

  • Les communications entre Snowflake et le serveur proxy sont chiffrées à l’aide de HTTPS.

Informations de sécurité spécifiques à la plate-forme

AWS

Langage: Français