Bonnes pratiques pour l'activation de VPC Service Controls

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

Une activation néfaste de VPC Service Controls peut entraîner des problèmes avec les applications et pourrait provoquer une panne. Nous vous recommandons de planifier cette habilitation, en laissant suffisamment de temps pour recueillir des données, effectuer des tests et analyser les journaux des cas de non-conformité. 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 personne qui crée et suit les réunions pluridisciplinaires et documente les actions éléments. 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

Tout comme pour les pare-feu réseau conventionnels, l'objectif est d'identifier et permettre le fonctionnement efficace des activités légitimes charges de travail.

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: services situés en dehors du périmètre stockent ou récupèrent aux données situées 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 les projets qui font 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 charges de travail prioritaires pour l'activation initiale, et intégrer d'autres des charges de travail moins critiques après avoir protégé les ressources critiques de l'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 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éer un périmètre de simulation et ajouter 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 récepteur de journaux pour chaque projet qui envoie les journaux de simulation ensemble de données. Pour interroger ces messages de journal et identifier les non-respects de VPC Service Controls, vous pouvez utiliser une requête SQL.

    Créer un récepteur de journaux qui inclut tous les journaux VPC Service Controls pertinents messages, 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. Configurer de sorte que seuls les services restreints fonctionnent dans le périmètre. Pour ce faire, configurez la liste des services accessibles pour RESTRICTED-SERVICES.

  6. Si vous disposez déjà d'une liste d'adresses IP publiques, d'identités, d'adresses IP approuvées des appareils, des projets ou des réseaux VPC, les ajouter à une règle d'entrée dans le périmètre de simulation. Autoriser la légitimité connue permet de réduire le nombre de journaux de violations et permet aux réviseurs de se concentrer des é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, 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 ?

Sur la base des critères précédents, déterminez si vous devez autoriser l'identité, appareil, adresse IP, plage CIDR, projet ou réseau pour 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 doivent avoir lieu pour la raison suivante : Masquage des journaux Cloud Audit Logs pour les opérations en lecture seule refusées en raison de l'absence d'IAM autorisations. 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 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 un type de non-conformité SERVICE_NOT_ALLOWED_FROM_VPC, la charge de travail utilise peut-être un service compatible avec VPC Service Controls, mais qui n'est pas ajouté à la liste des API protégées. Par exemple, si IAM à l'origine d'une telle violation, l'administrateur doit ajouter IAM 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 plus pour en savoir plus, consultez Surveillez les cas de non-respect des règles VPC Service Controls dans votre organisation Google Cloud à l'aide de Looker Studio. Looker Studio était auparavant connu sous le nom de Data Studio.

Étape suivante