Ce document décrit les implémentations de niveau d'accès et fournit des recommandations pour lancer l'application d'un 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 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 :
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 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 situées dans le périmètre sont accessibles via des VM situées dans le périmètre, à partir de réseaux sur site de confiance ou d'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 concernant l'appareil sont utiles pour établir la confiance de l'appareil:
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.
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.
É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 l'identité du numéro de série. Nous vous recommandons de n'utiliser cette condition que comme contrôle 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'autorisation supplémentaires, si nécessaire.
- Assurez-vous que l'équipe de réponse aux situations 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 détecter les cas de non-respect bloqués, configurez un récepteur de journaux agrégés qui envoie à BigQuery les journaux d'audit pour 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.