Bonnes pratiques pour activer VPC Service Controls

Ce document décrit la procédure recommandée pour configurer et appliquer la protection VPC Service Controls dans votre organisation Google Cloud.

Une activation négligente de VPC Service Controls peut entraîner des problèmes avec les applications existantes, ainsi qu'une interruption. Nous vous recommandons de planifier l'activation avec soin et d'allouer suffisamment de temps pour regrouper des données, effectuer des tests et analyser les journaux des violations. Assurez-vous que les membres de votre équipe chargée des opérations VPC Service Controls et de votre équipe dédiée aux applications sont disponibles pour effectuer la tâche.

Pour chaque charge de travail ou application que vous intégrez à VPC Service Controls, vous devez répéter le processus d'activation.

Coordonner la communication

L'équipe chargée de la sécurité réseau ou de l'activation du cloud dirige souvent l'activation de VPC Service Controls. Nous vous recommandons d'avoir une personne dédiée pour la création et le suivi des réunions, ainsi que pour la documentation des tâches. Vos équipes collaborent sur les points suivants:

  • Modèles d'accès des API Google Cloud
  • Identification des cas de non-respect du périmètre de service
  • Autoriser l'accès au périmètre

Tout comme avec les pare-feu réseau classiques, l'objectif est d'identifier et d'autoriser les flux nécessaires au fonctionnement efficace des charges de travail légitimes de l'entreprise.

Modèles d'accès aux documents et cas d'utilisation

Pour commencer le processus d'activation, identifiez et documentez clairement tous les modèles d'accès valides. Les modèles d'accès sont des types d'interactions reproductibles entre des éléments situés à l'extérieur et à l'intérieur du périmètre. Voici quelques modèles d'accès courants :

  • Modèles d'accès aux données: les services en dehors du périmètre stockent ou récupèrent les données qui résident dans le périmètre.
  • Modèles d'accès aux ressources :
    • Les utilisateurs accèdent aux projets du périmètre via la console Google Cloud.
    • Les outils ou services tiers gèrent et accèdent aux ressources au sein du périmètre.
    • Les services ou les ressources du périmètre accèdent aux API Google.
  • Modèles d'accès aux points de terminaison :
    • Les utilisateurs accèdent aux ressources du périmètre à partir d'un appareil géré par votre organisation.
    • Les ressources sur site communiquent avec des ressources au sein du périmètre.

Après avoir identifié les modèles d'accès d'une charge de travail, identifiez vos cas d'utilisation et classifiez-les sous l'un des formats d'accès de la liste précédente. Voici quelques cas d'utilisation courants :

  • Les administrateurs cloud gèrent des projets faisant partie d'un périmètre.
  • Les services d'automatisation tels que Terraform, Jenkins et Microsoft Azure DevOps résidant en dehors du périmètre gèrent le déploiement des ressources au sein du périmètre.
  • Les services de gestion de la configuration tels que Ansible, Chef ou Puppet, qui résident en dehors du périmètre, gèrent le déploiement et la configuration des logiciels sur les ressources situées à l'intérieur du périmètre.
  • La surveillance de la sécurité et l'application de services tels que Forseti ou SIEM résidant en dehors du périmètre consomment des données ou appliquent les règles de sécurité à une ressource située à l'intérieur du périmètre.

Pour chaque cas d'utilisation, documentez les points suivants :

  • Le modèle d'accès
  • Les acteurs pouvant déclencher le cas d'utilisation
  • Les conditions qui déclenchent le cas d'utilisation
  • Si le cas d'utilisation est un modèle d'accès valide et doit être autorisé
  • Toute hypothèse liée au cas d'utilisation

Pour obtenir un exemple de modèle d'accès et de suivi des cas d'utilisation, consultez la section Modèle d'intégration VPC Service Controls – Cas d'utilisation (PDF).

Mener des entretiens

Menez des entretiens avec vos équipes dédiées aux charges de travail pour discuter des modèles d'accès et des cas d'utilisation que vous collectez à partir des modèles de communication précédents. Vous trouverez ci-dessous des exemples de questions que vous pouvez poser lors de ces entretiens :

  • Vos cas d'utilisation sont-ils prioritaires pour l'activation de VPC Service Controls ? Nous vous recommandons de ne prendre en compte que les charges de travail prioritaires pour l'activation initiale et d'intégrer d'autres charges de travail moins critiques après avoir protégé les ressources essentielles à l'activité.

  • Pouvez-vous terminer l'exécution complète de tous les cas d'utilisation ? Vous déclenchez ainsi tous les scénarios de périmètre possibles pour vous permettre d'analyser entièrement et de vérifier que l'application fonctionne correctement après l'application du périmètre.

  • Combien de temps dure l'exécution du cas d'utilisation ?

  • Planifiez-vous des modifications majeures de cette charge de travail qui pourraient entrer en conflit avec l'activation de VPC Service Controls ? Les fonctionnalités de charge de travail doivent être dans un état stable avant d'activer VPC Service Controls.

Préparer une simulation

Le mode simulation réduit la complexité du test de l'application de VPC Service Controls en identifiant les violations sans interrompre les applications. Vous pouvez configurer une simulation en tant que périmètre distinct qui enregistre toutes les violations, mais qui n'effectue aucun blocage. Vous pouvez exécuter des charges de travail alors qu'elles se trouvent dans le périmètre de simulation et générer les journaux des violations à analyser.

Pour préparer l'environnement de simulation, procédez comme suit :

  1. Identifiez tous les projets qualifiés au sein du périmètre, puis terminez le cas d'utilisation et le processus d'entretien associés à ces projets.
  2. Créez un périmètre de simulation et ajoutez tous les projets.
  3. Dans le périmètre de service de VPC Service Controls, sous Services restreints > Services à protéger, ajoutez tous les services compatibles.

  4. Créez un récepteur de journaux agrégé qui envoie tous les journaux à BigQuery, ou créez un récepteur de journaux pour chaque projet qui envoie les journaux de simulation à un ensemble de données BigQuery commun. Pour interroger ces messages de journal et identifier les non-respects de VPC Service Controls, vous pouvez utiliser une requête SQL.

    Pour créer un récepteur de journaux qui inclut tous les messages de journal VPC Service Controls pertinents, utilisez le filtre suivant:

    logName="projects/$PROJECT/logs/cloudaudit.googleapis.com%2Fpolicy"

  5. Pour une sécurité optimale, interdisez l'accès aux services non compatibles. Configurez votre périmètre de sorte que seuls les services restreints fonctionnent dans le périmètre. Pour ce faire, configurez la liste de services accessibles sur RESTRICTED-SERVICES.

  6. Si vous disposez déjà d'une liste d'adresses IP publiques, d'identités, d'appareils approuvés, de projets ou de réseaux VPC autorisés, ajoutez-les à une règle d'entrée ou à un niveau d'accès, le cas échéant, dans le périmètre de simulation. Autoriser les flux légitimes connus permet de réduire le nombre de journaux des violations et de permettre aux examinateurs de se concentrer sur les événements exploitables.

  7. Vérifiez qu'aucun des VPC des projets ne dispose d'un chemin de sortie vers Internet ou l'adresse IP virtuelle privée.

  8. Vérifiez que le DNS *.googleapis.com pointe vers restricted.googleapis.com pour tous les VPC.

    Dans les détails de la zone, le nom DNS *.googleapis.com contient "restricted.googleapis.com" dans le champ "Data" (Données).

Exécuter des cas d'utilisation

À un moment convenu, demandez à votre équipe de développement d'exécuter sa charge de travail sur le projet dans le périmètre de la simulation. Assurez-vous de disposer d'une couverture complète de tout le code pouvant appeler les API Google. Une fois la simulation terminée, votre équipe d'examen désignée peut effectuer l'analyse des journaux de non-respect.

Analyser les non-respects

Les journaux de non-respect de simulation contiennent la plupart des informations nécessaires pour déterminer si un non-respect des applications nécessite une action, telle que l'ajout d'identités ou d'adresses IP à la liste blanche du périmètre. Les données de non-respect sont stockées dans la table BigQuery cloudaudit_googleapis_com_policy. Voici les principaux éléments qui vous permettront d'analyser le non-respect :

  • Le service protégé et la méthode API sont appelés.
  • Le projet du périmètre qui aurait bloqué la requête.
  • L'adresse e-mail de l'identité qui appelle l'API protégée.
  • Adresse IP de l'appelant
  • Le type de violation.

L'exemple suivant est une requête BigQuery qui renvoie tous les détails de la violation :

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') = "true" #ensure these are dry-run logs

Interroger les violations pertinentes

Les stratégies suivantes peuvent vous aider à identifier les violations pertinentes :

  • Ajoutez un qualificateur d'horodatage pour la fenêtre temporelle lorsque chaque application unique a exécuté son cas d'utilisation :

    WHERE receiveTimestamp >'2020-07-23 19:53:48.241317 UTC'

  • Ajoutez un filtre pour la convention d'attribution de noms des charges de travail ou des projets :

    WHERE where resource.labels.project_id like '%APPLICATION_NAME%'

Consulter les journaux des violations

Lorsque vous consultez les journaux de violation, déterminez si les conditions suivantes sont remplies :

  • L'identité (adresse e-mail) est-elle censée appeler les API protégées ?
  • L'appelant doit-il être autorisé à appeler l'API en dehors du périmètre ?

Sur la base des critères précédents, déterminez si vous devez autoriser l'identité, l'appareil, l'adresse IP, la plage CIDR, le projet ou le réseau à accéder au périmètre depuis l'extérieur.

Certaines entrées peuvent avoir l'adresse IP private. Cela indique que l'appel provient du réseau Google, soit par ses propres services, soit par un VPC dans un projet situé en dehors du périmètre. Pour les services Google, tels que les rédacteurs de récepteurs de journaux, vous devez ajouter le compte de service Google à une liste d'autorisations.

Les entrées sans adresse e-mail sont dues au masquage des journaux d'audit Cloud pour les opérations en lecture seule refusées en raison d'autorisations IAM. Dans ce cas, vous pouvez utiliser l'adresse IP et les noms des ressources pour comprendre l'origine de la tentative d'accès. Ce type de tentative d'accès peut être un accès accidentel par un utilisateur extérieur à votre organisation. Par exemple, un utilisateur qui saisit un bucket au nom similaire.

Si vous constatez une violation de type SERVICE_NOT_ALLOWED_FROM_VPC, il est possible que la charge de travail utilise un service compatible avec VPC Service Controls, mais qui n'a pas été ajouté à la liste des API protégées. Par exemple, si IAM a causé une telle violation, l'administrateur doit ajouter IAM à la liste des services accessibles en exécutant la commande Google Cloud CLI suivante:

gcloud access-context-manager perimeters update perimeter_test \
 --add-vpc-allowed-services=RESTRICTED-SERVICES,IAM.googleapis.com \
 --policy=1234567890

Vous pouvez créer un tableau de bord Looker Studio pour examiner les non-respects. Pour en savoir plus, consultez la page Surveiller les non-respects de VPC Service Controls dans votre organisation Google Cloud avec Looker Studio. Looker Studio s'appelait auparavant Data Studio.

Étape suivante