Sécuriser votre fonction Cloud

Cette page offre une présentation générale de la façon dont vous pouvez contrôler les interactions à l'aide des ressources Cloud Functions.

Contrôle des accès

Le contrôle des accès à Cloud Functions peut s'effectuer selon deux approches différentes :

Sécuriser l'accès avec l'identité

Pour contrôler l'accès à une fonction, vous pouvez exiger que l'entité à l'origine de la requête s'identifie à l'aide d'un identifiant. Un identifiant est un "nom" sécurisé par un secret que l'entité connaît ou auquel elle a accès, comme un mot de passe ou un dongle matériel. Par défaut, les fonctions sont déployées en mode privé et nécessitent de tels identifiants. Il est toutefois possible de les déployer en mode public, c'est-à-dire sans identifiants.

La première étape du processus consiste à valider l'identifiant afin de s'assurer que le demandeur est bien celui qu'il prétend être en présentant la bonne combinaison nom/secret. Cette étape est appelée (Authentication).

Une fois l'identité du demandeur authentifiée, son niveau d'accès, soit les autorisations accordées à l'identité, peut être évalué. Cette étape est appelée (Authorization).

Authentification

Cloud Functions accepte deux types d'identités différents, également appelés comptes principaux :

  • Comptes de service : il s'agit de comptes spéciaux qui constituent l'identité d'une entité autre qu'un utilisateur humain, par exemple, une fonction, une application ou une VM. Ils vous permettent d'authentifier ces entités non humaines.
  • Comptes utilisateur : ces comptes représentent de véritables utilisateurs, qu'il s'agisse de titulaires d'un compte Google individuel ou de membres d'une entité contrôlée par Google, comme un groupe Google.

Pour les comptes de service et les comptes utilisateur, la partie nom de l'identifiant est généralement une adresse e-mail associée au compte. Le secret d'un compte utilisateur est généralement un mot de passe. Pour un compte de service, il s'agit généralement de la clé privée de la paire de clés créée avec le compte.

Cependant, les mots de passe utilisateur et les clés de compte de service sont très puissants. Ils fournissent un accès étendu aux données et aux fonctionnalités, et restent efficaces jusqu'à ce qu'ils soient révoqués ou modifiés activement. Pour limiter les dommages potentiels pouvant survenir si les identifiants ont été piratés, dans Google Cloud, ces identifiants principaux sont remplacés par des identifiants à court terme basés sur ceux-ci, des jetons à durée de vie limitée et créés à la volée dans le cadre de la séquence de requêtes. Le jeton est transmis avec la requête et sert à authentifier le compte en toute sécurité.

Il existe deux types de jetons utilisés dans Cloud Functions : les jetons d'accès et les jetons d'ID. Les jetons d'accès sont généralement utilisés pour authentifier les appels d'API, et les jetons d'ID pour authentifier les appels de code créé par le développeur, par exemple lorsqu'une fonction appelle une autre fonction. Les jetons eux-mêmes sont créés à l'aide du framework OAuth 2 et de son extension, Open Identity Connect. Cependant, la séquence étant complexe et sujette aux erreurs, il est vivement recommandé d'utiliser les bibliothèques clientes Cloud pour gérer le processus.

Autorisation

Une fois l'identité de l'entité à l'origine de la demande confirmée, il convient d'évaluer ce que le demandeur est autorisé à effectuer. Cette évaluation dépend des autorisations accordées au compte authentifié lors de sa configuration. Cloud Functions utilise IAM (Identity and Access Management) pour ce faire. Les rôles, qui sont des ensembles d'autorisations individuelles regroupées pour plus de commodité, sont attribués au compte, soit directement, soit via une configuration appelée stratégie. Chaque autorisation individuelle de l'ensemble de rôles correspond généralement à un seul appel d'API REST exposé par le service demandé. Pour plus d'informations sur ce processus, consultez la section Autoriser l'accès via IAM.

Contrôle des accès basé sur le réseau

Vous pouvez également limiter les accès en spécifiant des paramètres réseau pour chaque fonction. Cela permet un contrôle plus précis sur l'entrée et la sortie réseau vers et depuis vos fonctions.

Isolation et bac à sable

Les instances de fonction sont isolées les unes des autres en interne à l'aide de la plate-forme d'isolation gVisor. De par sa conception, une fonction ne peut pas accéder aux environnements d'exploitation d'autres fonctions.

Mises à jour de l'environnement d'exécution

Google met à disposition des correctifs de sécurité et des mises à jour de maintenance après une période de tests de stabilité. De même, Cloud Functions peut appliquer des mises à jour à d'autres aspects de l'environnement d'exécution, tels que le système d'exploitation ou les packages inclus. Ces mises à jour permettent de sécuriser l'environnement d'exécution de votre fonction.

Mises à jour de sécurité Cloud Functions

Cloud Functions propose deux règles de mise à jour de sécurité :

  • Mises à jour automatiques : les mises à jour et les correctifs de sécurité de l'environnement d'exécution sont publiés dans de nouvelles versions de l'image d'exécution. Après une période de tests de stabilité et de fiabilité, l'environnement d'exécution mis à jour est déployé sur toutes les fonctions, ce qui évite les temps d'arrêt. Les mises à jour de sécurité automatiques ne sont disponibles qu'avec Cloud Functions (1re génération).

  • Lors des mises à jour de déploiement : les mises à jour et les correctifs de sécurité ne sont appliqués aux environnements d'exécution que lorsque des fonctions sont déployées ou redéployées, sauf indication contraire. Les mises à jour sur déploiement sont disponibles à la fois sur Cloud Functions (1st gen) et sur Cloud Functions (2nd gen).

Pour en savoir plus sur les mises à jour de sécurité de l'environnement d'exécution, consultez la page Règles de mise à jour de sécurité.