Bonnes pratiques pour l'activation de VPC Service Controls

Ce document décrit le processus recommandé pour configurer et appliquer la protection de VPC Service Controls dans votre organisation Google Cloud.

L'activation négligente de VPC Service Controls peut entraîner des problèmes avec les applications existantes et potentiellement une panne. Nous vous recommandons de planifier soigneusement l'activation et de prévoir suffisamment de temps pour rassembler les données, effectuer des tests et analyser les journaux de non-conformité. Assurez-vous que les personnes concernées au sein de votre équipe chargée des opérations VPC Service Controls et de votre équipe Applications sont disponibles pour cette 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

Souvent, l'équipe chargée de la sécurité du réseau ou de l'activation du cloud gère les efforts d'activation de VPC Service Controls. Nous vous recommandons de faire appel à une personne dédiée qui crée et suit les réunions pluridisciplinaires et documente les tâches. Vos équipes collaborent sur les points suivants:

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

Comme pour les pare-feu réseau traditionnels, 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 situés en dehors du périmètre stockent ou récupèrent les données qui y résident.
  • 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 les 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 considérer 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 critiques de votre entreprise.

  • 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 de simulation simplifie le test de l'application de VPC Service Controls en identifiant les cas de non-respect 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és qui envoie tous les journaux à BigQuery, ou créez un récepteur de journaux pour chaque projet qui envoie les journaux de simulation vers 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 incluant 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é maximale, interdisez l'accès aux services non compatibles. Configurez votre périmètre de sorte que seuls les services restreints fonctionnent dans celui-ci. Pour ce faire, configurez la liste des services accessibles sur RESTRICTED-SERVICES.

  6. Si vous disposez déjà d'une liste d'adresses IP publiques, d'identités, d'appareils de confiance, 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 simulation. Autoriser les flux légitimes connus permet de réduire le nombre de journaux de non-conformité et permet 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, l'équipe d'examen désignée peut analyser le journal des cas de non-conformité.

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 ?

En fonction des critères ci-dessus, 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 le résultat d'un accès accidentel d'un utilisateur extérieur à votre organisation. C'est par exemple le cas si un utilisateur saisit un bucket dont le nom est similaire.

Si vous constatez un type de violation 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 est à l'origine d'un tel cas de non-conformité, 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 cas de non-respect des règles VPC Service Controls dans votre organisation Google Cloud avec Looker Studio. Looker Studio était auparavant appelé Data Studio.

Étapes suivantes