Concevoir des niveaux d'accès

Ce document décrit les implémentations au niveau de l'accès et fournit des recommandations pour lancer l'application du périmètre de service en fonction des listes d'autorisation.

Lorsque vous exécutez une simulation des charges de travail, vous identifiez la liste des adresses IP et des identités à ajouter à une liste d'autorisation. Vous pouvez également constater que certaines charges de travail nécessitent une liste d'autorisation basée sur un appareil. Pour accorder un accès contrôlé aux ressources Google Cloud protégées, vous pouvez utiliser les niveaux d'accès de VPC Service Controls. Vous pouvez mettre en œuvre des niveaux d'accès en fonction de l'adresse IP, de l'identité ou de l'appareil.

Pour en savoir plus, consultez Accès contextuel avec des règles d'entrée.

Accorder un accès en fonction de l'adresse IP source

Vous ne pouvez utiliser que des plages CIDR d'adresses IP publiques dans les niveaux d'accès des listes d'autorisation basées sur l'adresse IP. Étant donné que cette méthode autorise toutes les API protégées de cette plage d'adresses IP, l'environnement derrière ces adresses IP doit être approuvé et contrôlé. Un scénario d'utilisation typique de cette liste d'autorisations consiste à autoriser l'accès au périmètre à partir de réseaux sur site. Le schéma suivant montre comment une liste d'autorisations basée sur les adresses IP bloque et autorise l'accès au périmètre :

Le réseau et le périmètre de service VPC Service Controls empêchent l'accès d'une identité valide sur un réseau non approuvé.

Dans le schéma précédent, une identité valide tente d'accéder au périmètre. Les tentatives d'accès sont refusées si elles proviennent d'une adresse IP Internet. Cependant, l'accès est autorisé lorsqu'il provient des adresses IP publiques de l'entreprise.

Une variante de ce scénario consiste à autoriser l'accès au périmètre à partir de ressources privées déployées dans un autre projet ou une autre organisation. Dans ce cas d'utilisation, une passerelle Cloud NAT est requise dans le projet source. Cloud NAT est intégré à l'accès privé à Google, ce qui active automatiquement l'accès privé à Google sur le sous-réseau de la ressource et maintient le trafic vers les API et services Google en interne, au lieu de le router vers Internet à l'aide de l'adresse IP externe de la passerelle Cloud NAT. Comme le trafic est acheminé dans le réseau interne de Google, le champ RequestMetadata.caller_ip de l'objet AuditLog est masqué en gce-internal-ip. Pour autoriser l'accès au périmètre dans ce cas, vous devez configurer une règle d'entrée pour autoriser l'accès en fonction d'autres attributs tels que le projet ou le compte de service, au lieu de configurer un niveau d'accès en fonction de l'adresse IP source externe.

Accorder un accès en fonction de l'identité de l'appelant

Pour mettre en œuvre une liste d'autorisation basée sur l'identité, vous ajoutez des comptes de service et des super-administrateurs d'organisation à une liste d'autorisation. Le périmètre est ouvert à ces identités à partir de n'importe quelle adresse IP. Vous devez donc vous assurer que les identités sont correctement protégées. Vous devez également veiller à éviter les clés de génération pour les comptes de service que vous avez ajoutés à une liste d'autorisation. Il est rare d'ajouter des identités d'utilisateur à une liste d'autorisations (les groupes ne peuvent pas être ajoutés à une liste d'autorisations) sur un périmètre.

Les ressources du périmètre sont accessibles via des VM au sein du périmètre, depuis des réseaux sur site approuvés ou depuis des appareils vérifiés. Nous vous recommandons d'utiliser Cloud Workstations pour accéder aux ressources dans les périmètres, car VPC Service Controls n'est pas compatible avec Cloud Shell.

Faire certifier l'accès en fonction des attributs des appareils appartenant à l'appelant

La confiance des appareils, également appelée point de terminaison de confiance, repose sur le fait qu'un utilisateur d'organisation valide soit connecté à un navigateur Chrome ou à un Chromebook. La confiance s'applique à la session connectée au système d'exploitation. Par exemple, un utilisateur Windows qui est connecté et exécute une session Chrome (le navigateur n'a pas besoin d'être ouvert) peut appeler les commandes de gcloud CLI sur les API de périmètre protégées. Toutefois, une autre session utilisateur Windows sur la même machine ne peut pas appeler des commandes sur les API de périmètre protégées.

Voici les conditions liées aux appareils nécessaires pour établir la confiance des appareils:

  • Chrome OS validé est une condition hautement sécurisée et cryptographique qui indique qu'un utilisateur d'organisation valide est connecté à un Chromebook démarré de manière sécurisée. Il s'agit d'une condition de confiance de niveau 1 recommandée.

    Stratégie du système d'exploitation avec l'option "Chrome OS validée" activée.

  • L'option Exiger l'approbation de l'administrateur pour accéder aux appareils permet aux administrateurs Cloud Identity d'approuver chaque appareil avant toute autorisation d'accès. Par défaut, les appareils sont approuvés automatiquement s'ils disposent d'un utilisateur valide de l'organisation. Toutefois, nous vous recommandons de désactiver l'option d'approbation automatique.

  • Exiger un appareil détenu par l'entreprise : s'appuie sur l'agent Chrome qui récupère le numéro de série du système d'exploitation, qui provient généralement du BIOS. Ce numéro doit correspondre aux numéros de série existants que vous avez saisis dans Cloud Identity.

    Comme le numéro de série ne fait pas autorité sur des appareils autres que ChromeOS, un utilisateur disposant de droits d'administrateur élevés peut éventuellement simuler le numéro de série. Nous vous recommandons de n'utiliser cette condition qu'en tant que vérification de niveau 2.

Pour accéder à un exemple d'outil de suivi permettant d'accorder un accès contrôlé selon les conditions décrites dans la liste précédente, consultez la page Modèle d'intégration de VPC Service Controls – liste d'autorisation (PDF).

Lancer l'application

Une fois que vous avez conçu la liste d'autorisations et mis à jour les niveaux d'accès, nous vous recommandons de réexécuter les charges de travail pour vérifier qu'il n'y a pas de non-respect. Si les charges de travail s'exécutent sans non-respect, vous pouvez lancer VPC Service Controls sans affecter les applications.

Lorsque vous prévoyez l'application, incluez les éléments suivants :

  • Choisissez une date d'application forcée et communiquez cette date à toutes les équipes pertinentes.
  • Assurez-vous que les équipes chargées des opérations de sécurité et de la gestion des incidents sont informées du déploiement. Assurez-vous également que les personnes disposant des autorisations appropriées inspectent les journaux et approuvent des listes d'autorisations supplémentaires, si nécessaire.
  • Assurez-vous que l'équipe de gestion des situations de crise peut ouvrir une demande d'assistance Google Cloud en cas de question ou de problème.
  • Créez ou modifiez les périmètres et les niveaux d'accès à l'aide d'outils d'automatisation tels que Terraform. Nous vous déconseillons d'effectuer ces tâches manuellement.

Lorsque vous lancez l'application forcée, commencez par déplacer les projets associés à une seule charge de travail du périmètre de simulation vers le périmètre actif. Veillez à laisser le temps à l'application de s'exécuter correctement pendant que vous observez les journaux de non-respects. Répétez le processus pour les charges de travail restantes une par une.

Pour identifier les cas de non-respect bloqués, configurez un récepteur de journaux agrégé qui envoie les journaux d'audit de tous les projets du périmètre à BigQuery. Exécutez ensuite la requête suivante:

SELECT
receiveTimestamp, #time of violation
Resource.labels.service, #protected Google Cloud service being blocked
protopayload_auditlog.methodName, #method name being called
resource.labels.project_id as PROJECT, #protected project blocking the call
protopayload_auditlog.authenticationInfo.principalEmail, #caller identity
protopayload_auditlog.requestMetadata.callerIp, #caller IP
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') as DRYRUN, #dry-run indicator
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.violationReason') as REASON, #reason for violation
protopayload_auditlog.metadataJson, #raw violation entry
FROM `BQ_DATASOURCE_NAME.cloudaudit_googleapis_com_policy_*`
WHERE JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') is null #exclude logs from a dry-run perimeter

Étape suivante