Ce document décrit les implémentations de niveau d'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 la section 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 pour les listes d'autorisation basées sur les adresses 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 :
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.
Accorder un accès en fonction de l'identité de l'appelant
Pour implémenter une liste d'autorisation basée sur l'identité, vous devez ajouter des comptes de service et des super-administrateurs de l'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 situées dans le périmètre sont accessibles via des VM situées dans le périmètre, depuis des réseaux sur site de confiance ou depuis des appareils vérifiés. Nous vous recommandons d'utiliser Cloud Workstations pour accéder aux ressources situées 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.
Les conditions suivantes sont utiles pour établir l'approbation d'un appareil:
La condition Chrome OS validé est une condition hautement sécurisée validée par cryptomonnaie, qui indique qu'un utilisateur valide de l'entreprise est connecté à un Chromebook qui a démarré de manière sécurisée. Il s'agit d'une condition de confiance de niveau 1 recommandée.
L'option Exiger l'approbation de l'administrateur pour l'accès aux appareils permet aux administrateurs Cloud Identity d'approuver chaque appareil avant d'accorder un 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.
Étant donné que le numéro de série ne fait pas autorité sur les appareils non-ChromeOS, un utilisateur disposant de droits d'administrateur élevés peut être en mesure d'usurper le numéro de série. Nous vous recommandons de n'utiliser cette condition que pour une 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 gestion des incidents sont au courant du déploiement. Assurez-vous également que les personnes disposant des autorisations appropriées inspectent les journaux et approuvent les listes d'autorisation supplémentaires, si nécessaire.
- Assurez-vous que l'équipe de gestion de la situation peut ouvrir une demande d'assistance Google Cloud si des questions ou des problèmes surviennent.
- 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és qui envoie à BigQuery les journaux d'audit de tous les projets du périmètre. 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
Étapes suivantes
- Découvrez comment autoriser l'accès aux ressources protégées depuis l'extérieur du périmètre.
- Découvrez comment répertorier, mettre à jour et supprimer des périmètres de service.