Bonnes pratiques concernant l'activation de 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 de prévoir suffisamment de temps pour regrouper des données, effectuer des tests et analyser les journaux des cas de non-respect. 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.

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

Coordonner la communication

C'est souvent l'équipe chargée de la sécurité réseau ou de l'activation du cloud qui effectue le processus d'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 aux APIGoogle Cloud
  • Identification des cas de non-respect par périmètre de service
  • Autorisation de l'accès au périmètre

Comme pour les pare-feu de réseau classiques, l'objectif est d'identifier et d'autoriser les flux nécessaires au bon fonctionnement des charges de travail professionnelles légitimes.

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 consoleGoogle Cloud .
    • Les outils ou services tiers gèrent et accèdent aux ressources situées dans le 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 situées dans le périmètre.

Après avoir identifié les modèles d'accès d'une charge de travail, identifiez vos cas d'utilisation et classez-les dans l'une des catégories de modèles d'accès figurant dans 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 qu'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.
  • Les services de surveillance et d'application de la sécurité tels que Forseti ou SIEM, qui résident en dehors du périmètre, consomment des données ou appliquent les règles de sécurité sur une ressource située à l'intérieur du périmètre.

Pour chaque cas d'utilisation, consignez 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é ou non
  • 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 stratégiques.

  • 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 pouvoir analyser entièrement et 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 ?

  • Prévoyez-vous d'apporter à cette charge de travail des modifications majeures 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 un dry run (test à blanc)

Le mode dry run réduit la complexité du test de l'application de VPC Service Controls en identifiant les cas de non-respect sans interrompre les applications. Vous pouvez configurer un test dry run en tant que périmètre distinct qui consigne tous les cas de non-respect, 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 dry run et générer des journaux de cas de non-respect à analyser.

Pour préparer l'environnement de dry run, 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 dry run 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 pour chaque projet un récepteur de journaux qui envoie les journaux de dry run à un ensemble de données BigQuery commun. Pour interroger ces messages de journal et identifier les cas de non-respect 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 optimiser la sécurité, refusez l'accès aux services non compatibles. Configurez votre périmètre de sorte que seuls les services restreints fonctionnent dans ce 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 vérifiés, de projets ou de réseaux VPC autorisés, ajoutez-les à une règle d'entrée ou à un niveau d'accès, selon le cas, dans le périmètre de dry run. Autoriser les flux légitimes connus permet de réduire le nombre de journaux de cas de non-respect et 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 de DNS *.googleapis.com contient "restricted.googleapis.com" dans le champ "Données".

Exécuter des cas d'utilisation

À un moment convenu, demandez à votre équipe chargée des application d'exécuter sa charge de travail sur le projet du périmètre de dry run. Assurez-vous de disposer d'une couverture complète de tout le code pouvant appeler les API Google. Une fois le test dry run effectué, votre équipe dédiée à la vérification peut analyser les journaux de cas de non-respect.

Analyser les cas de non-respect

Les journaux de cas de non-respect liés au test dry run contiennent la plupart des informations nécessaires pour déterminer si un cas de 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 des cas 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 cas de non-respect :

  • Le service protégé et la méthode API qui 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
  • L'adresse IP de l'appelant
  • Le type de cas de non-respect

L'exemple suivant est une requête BigQuery qui renvoie toutes les informations sur les cas de non-respect :

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 cas de non-respect pertinents

Les stratégies suivantes peuvent vous aider à identifier les cas de non-respect pertinents :

  • Ajoutez un qualificatif d'horodatage pour la période durant laquelle 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 identités de charges de travail ou des projets :

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

Consulter les journaux des cas de non-respect

Lorsque vous consultez les journaux des cas de non-respect, 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 une adresse IP private. Cela indique que l'appel provient du réseau Google, soit par ses propres services, soit par le VPC d'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'autorisation.

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 insuffisantes. 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 effectué par un utilisateur extérieur à votre organisation. Par exemple, un utilisateur qui saisit mal le nom d'un bucket.

Si vous constatez un cas de non-respect 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 entraîné ce type de cas de non-respect, 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 cas de non-respect. Pour en savoir plus, consultez la section Surveiller les cas de non-respect de VPC Service Controls dans votre organisation Google Cloud avec Looker Studio. Looker Studio s'appelait auparavant Data Studio.

Étapes suivantes