Configurer un projet en conformité avec la loi HIPAA

Ce guide décrit un framework d'automatisation pour le déploiement de ressources Google Cloud Platform (GCP) afin de stocker et de traiter des données de santé, y compris des données de santé protégées, telles que définies par la loi américaine HIPAA (Health Insurance Portability and Accountability Act).

Clause de non-responsabilité

  • Ce guide présente une mise en œuvre de référence et ne constitue pas un avis juridique sur les mesures de protection administratives, techniques et physiques appropriées que vous devez appliquer pour vous conformer à la loi HIPAA ou à toute autre législation en matière de confidentialité des données.
  • Le champ d'application de ce guide se limite à la protection et à la surveillance des données conservées par les ressources couvertes. Les éléments de données dérivés stockés ou traités par d'autres services de stockage GCP dans le cadre de cette mise en œuvre ne sont pas automatiquement couverts. Vous devez appliquer des mesures de protection semblables aux éléments de données dérivés.
  • La mise en œuvre décrite dans ce guide n'est pas un produit Google officiel. Elle est uniquement destinée à être employée comme support de référence. Le code Open Source est disponible sur GitHub dans l'utilitaire d'automatisation du déploiement Google Cloud Healthcare, sous la licence Apache, version 2.0. Vous pouvez utiliser le framework comme point de départ et le configurer pour répondre à vos cas d'utilisation. Vous devez vous assurer que l'environnement et les applications que vous créez sur GCP sont configurés et sécurisés de manière adéquate conformément aux exigences de la loi HIPAA.
  • Ce guide vous présente un instantané du code dans GitHub, qui peut être mis à jour ou modifié au fil du temps. Outre les éléments abordés dans le guide, vous trouverez peut-être d'autres types de ressources (telles que des instances Compute Engine ou des clusters Kubernetes) inclus dans la mise en œuvre de référence. Pour découvrir le champ d'application le plus récent, consultez le fichier README.

Présentation

Ce guide est destiné aux organisations du secteur de la santé qui débutent avec GCP et qui recherchent un exemple de configuration de projet GCP pour des cas d'utilisation liés au stockage ou à l'analyse de données. Cette configuration comprend une grande partie des contrôles de sécurité et de confidentialité recommandés pour les données de santé, tels que la configuration de l'accès approprié, la conservation des journaux d'audit et la surveillance des activités suspectes.

Bien que le guide couvre plusieurs services GCP capables de stocker et de traiter des données de santé, il ne traite pas l'ensemble des types de ressources et cas d'utilisation GCP. Il se concentre plutôt sur un sous-ensemble de types de ressources. Pour obtenir la liste des services GCP conformes à la loi HIPAA conformément à l'accord de partenariat de Google, reportez-vous à la page Conformité avec la loi HIPAA sur Google Cloud Platform. Vous pouvez également consulter la documentation de GCP sur la sécurité, la confidentialité et la conformité.

Objectifs

Ce guide vise à fournir une mise en œuvre de référence de type infrastructure as code (IaC) pour la création d'un projet GCP en conformité avec la loi HIPAA. Cette stratégie de mise en œuvre automatise les processus suivants :

Coûts

GCP offre à ses clients un essai gratuit pendant une durée limitée ainsi qu'un niveau d'utilisation gratuit permanent qui s'appliquent à plusieurs des services utilisés dans ce tutoriel. Pour en savoir plus, consultez la page relative à la version gratuite de GCP.

En fonction de la quantité de données et de journaux accumulés lors de l'exécution de cette mise en œuvre, vous pourrez peut-être effectuer celle-ci sans dépasser les limites de l'essai gratuit ou de la version gratuite. Vous pouvez utiliser le Simulateur de coût pour générer une estimation du coût en fonction de votre utilisation prévue.

Une fois que vous aurez terminé cette mise en œuvre, vous pourrez éviter de continuer à payer des frais en supprimant les ressources créées. Consultez la section Nettoyer pour en savoir plus.

Avant de commencer

  1. Consultez la page Conformité avec la loi HIPAA sur Google Cloud Platform.
  2. Assurez-vous de disposer d'un compte GCP valide, ou créez-en un.
  3. Si vous utilisez des services GCP en lien avec des données de santé protégées, concluez un accord de partenariat avec GCP.
  4. Assurez-vous de disposer des groupes d'utilisateurs recommandés :

    Pour en savoir plus, consultez la section Groupes d'utilisateurs recommandés.

  5. Déterminez si vous souhaitez utiliser des journaux d'audit locaux ou distants.

Initialiser l'environnement

  1. Dans votre interface système, téléchargez l'utilitaire d'automatisation du déploiement Google Cloud et installez les dépendances Python :

    pip install -r requirements.txt
    
  2. Installez les outils et les services de dépendance :

    • Bazel : outil Open Source de création et de test
    • Pip : gestionnaire de packages pour les packages Python
    • SDK Cloud : ensemble d'outils pour la gestion des ressources et des applications hébergées sur GCP
    • Git : système de contrôle des versions distribué
  3. Configurez l'authentification :

    gcloud auth login
    

Définitions et concepts

Bonnes pratiques

La mise en œuvre de référence se base sur les bonnes pratiques suivantes pour la gestion des données de santé :

Ressources couvertes

La mise en œuvre de référence de ce guide vous explique comment protéger les données de vos buckets Cloud Storage, de vos ensembles de données BigQuery et de vos sujets Cloud Pub/Sub. Aucun autre type de ressource n'est couvert.

Vous pouvez spécifier des ressources dans votre configuration de déploiement.

Activités suspectes

Ce guide considère toutes les activités suivantes comme suspectes :

  • Modification des stratégies Cloud IAM
  • Modification des autorisations concernant les ressources couvertes
  • Accès aux ressources couvertes par toute personne autre que les utilisateurs définis dans la collection expected_users, comme spécifié dans la configuration de déploiement

Il est conseillé d'utiliser les quatre types de groupes ou de rôles suivants : propriétaires, auditeurs, accès en lecture/écriture aux données et accès en lecture seule aux données. Vous pouvez spécifier les groupes d'utilisateurs de chaque type de groupe via la configuration de déploiement.

Nous vous recommandons d'appliquer une convention d'attribution de noms cohérente pour nommer les groupes d'utilisateurs. Ce guide utilise la convention project_ID-group_type@domain. Pour project-id=hipaa-sample-project et domain=google.com, le groupe des propriétaires correspondrait à hipaa-sample-project-owners@google.com.

Le tableau suivant récapitule les rôles Cloud IAM associés à chaque type de groupe. Pour en savoir plus sur les rôles Cloud IAM répertoriés, consultez les pages Contrôle des accès aux projets, Rôles Cloud IAM pour Cloud Storage, Contrôle des accès dans BigQuery et Contrôle des accès dans Cloud Pub/Sub.

Tableau 1 : Groupes et droits d'accès recommandés

Groupe Projet Bucket de journaux (dans Cloud Storage) Journaux dans BigQuery Buckets de données (dans Cloud Storage) Données dans BigQuery Sujets Cloud Pub/Sub
owners_group owner storage.admin bigquery.dataOwner storage.admin bigquery.dataOwner owner
auditors_group iam.securityReviewer storage.objectViewer bigquery.dataViewer - - -
data_readwrite_groups - - - storage.objectAdmin bigquery.dataEditor pubsub.editor
data_readonly_groups - - - storage.objectViewer bigquery.dataViewer -

Emplacement de stockage pour les journaux d'audit : local ou distant

Deux options sont disponibles pour le stockage des fichiers d'audit :

  • Mode distant : les journaux sont stockés dans un projet GCP distinct, indépendant du projet où les données principales sont stockées. Cette configuration permet de centraliser tous les journaux d'audit dans un seul projet et de définir des règles d'accès communes dans l'ensemble de votre organisation.
  • Mode local : les journaux sont stockés dans le même projet GCP que les données principales qu'ils suivent. Cette configuration permet de gérer des dépôts de journaux d'audit distincts pour chaque projet.

Le mode distant est un choix naturel pour les grandes organisations disposant de plusieurs équipes et programmes, ainsi que d'une équipe centrale de gouvernance des données. Pour les petites entreprises, ou pour les grandes organisations ayant délégué la gouvernance des données, le mode local convient davantage.

Exécuter le script

Dans ce guide, le script d'aide fait référence à create_project.py. Ce script crée des projets GCP en fonction de votre configuration de déploiement. La section Comprendre le code ci-dessous décrit en détail le fonctionnement du code en coulisses, mais l'exécution du script d'aide est simple.

Dans votre environnement, accédez au dossier dans lequel vous avez cloné l'utilitaire d'automatisation du déploiement Google Cloud. Vous devriez voir les fichiers create_project.py et BUILD, parmi d'autres éléments. Vous devez spécifier quelques paramètres pour exécuter le script dans l'un des trois modes suivants : simulation, standard ou reprise :

bazel run :create_project -- \
    --project_yaml=config \
    --projects=project_list \
    --output_yaml_path=output_resume_config \
    --output_cleanup_path=output_cleanup_script \
    [--nodry_run|--dry_run] \
    --verbosity=verbosity_level

Les paramètres sont définis comme suit :

--project_yaml=config
Chemin relatif ou absolu de la configuration de déploiement.
--projects=project_list
Liste des ID de projet de la configuration de déploiement. Vous pouvez utiliser * pour indiquer tous les projets répertoriés dans la configuration de déploiement.
--output_yaml_path=output_resume_config
Chemin où le script de déploiement génère une configuration de déploiement modifiée. La configuration de déploiement obtenue contient la configuration d'origine, ainsi que d'autres champs générés lors du processus de déploiement, tels que les numéros de projet et les informations requises pour reprendre le script en cas d'échec.
--output_cleanup_path=output_cleanup_script

Chemin où le script de déploiement génère un script de nettoyage. Le script obtenu contient des commandes d'interface système qui permettent de nettoyer les configurations et ressources de vos projets que vous n'avez pas demandées dans la configuration de déploiement, mais qui ont été détectées lors du déploiement. Ces commandes d'interface système sont commentées par défaut pour éviter les actions accidentelles. Après avoir examiné les commandes, vous pouvez annuler leur mise en commentaire et exécuter le script pour obtenir un déploiement nettoyé. Voici un exemple de commande de nettoyage qui désactive l'API Container Registry si celle-ci est jugée inutile :

gcloud services disable containerregistry.googleapis.com --project hipaa-sample-project
--nodry_run

Option qui spécifie une exécution standard.

--dry_run

Option par défaut qui spécifie une simulation. Si vous omettez à la fois --nodry_run et --dry_run, l'action par défaut est définie sur ‑‑dry_run.

--verbosity=verbosity_level

Niveau de détail allant de -3 à 1. Plus la valeur est élevée, plus le nombre d'informations générées est grand :

  • -3 : journaux FATAL uniquement. Il s'agit du niveau de détail le plus faible.
  • -2 : journaux ERROR et FATAL.
  • -1 : journaux WARNING, ERROR et FATAL.
  • 0 : journaux INFO, WARNING, ERROR et FATAL. Il s'agit du niveau par défaut.
  • 1 : DEBUG, INFO, WARNING, ERROR et FATAL. Il s'agit du niveau de détail le plus élevé.

Mode de simulation

Le mode de simulation et le mode par défaut d'exécution du script create_project.py. Ce mode exécute la logique du script, mais ne crée et ne met à jour aucune ressource. L'exécution d'une simulation vous permet de prévisualiser votre configuration de déploiement. Par exemple, si vous utilisez des journaux d'audit locaux, vous pouvez exécuter la commande Bash suivante à l'aide de l'exemple de configuration de déploiement :

bazel run :create_project -- \
    --project_yaml=./samples/project_with_local_audit_logs.yaml \
    --output_yaml_path=/tmp/output.yaml \
    --dry_run

Mode standard

Après avoir examiné les commandes dans une exécution avec simulation, lancez le script avec le paramètre --nodry_run lorsque vous êtes prêt à effectuer le déploiement :

bazel run :create_project -- \
    --project_yaml=config \
    --output_yaml_path=/tmp/output.yaml \
    --nodry_run

Mode de reprise

Si le script échoue, résolvez le problème sous-jacent, puis reprenez l'exécution depuis l'étape ayant échoué en spécifiant les paramètres --resume_from_project et --resume_from_step :

bazel run :create_project -- \
    --project_yaml=config \
    --output_yaml_path=/tmp/output.yaml \
    --nodry_run \
    --resume_from_project=project_ID \
    --resume_from_step=step_number

Pour obtenir la liste des étapes, consultez la section _SETUP_STEPS du fichier create_project.py.

Vérifier les résultats

Le script d'aide encapsule de nombreuses commandes. Techniquement, vous pouvez obtenir les mêmes résultats en exécutant les commandes sur la ligne de commande ou de manière interactive via la console GCP. Si vous appliquez déjà les principes IaC (Infrastructure as Code), vous savez sans doute pourquoi il est judicieux d'automatiser le processus. Cette section décrit ce à quoi vous pouvez vous attendre dans la console GCP après avoir exécuté le script avec succès.

Console GCP

  • Vérifiez que la console GCP affiche bien votre projet ou vos projets :

    projets répertoriés dans la console GCP

Console Cloud IAM

  • Pour chaque projet, vérifiez dans la console IAM que OWNERS_GROUP est bien associé au rôle de propriétaire du projet, et AUDITORS_GROUP au rôle d'examinateur de sécurité pour le propriétaire du projet.

    Autorisations associées à votre projet dans la console

    Bien que la capture d'écran ci-dessus montre uniquement qui détient les groupes OWNERS_GROUP et AUDITORS_GROUP, vous pouvez sans doute voir plusieurs comptes de service avec un accès au niveau du projet en raison des API que vous avez activées. Les comptes de service les plus courants sont les suivants :

Navigateur de stockage

Recherchez les informations suivantes dans le navigateur de stockage :

  • Pour les buckets qui stockent les journaux, vérifiez que les valeurs associées à Name (Nom), Default storage class (Classe de stockage par défaut) et Location (Emplacement) suivent la configuration de déploiement. La capture d'écran ci-dessous montre un stockage local des journaux. Avec un stockage distant, ce bucket se trouve dans un projet différent des données et consolide les journaux de tous les projets de données. En mode de journalisation locale, chaque projet dispose de son propre bucket de journaux.

    Consolider les journaux pour tous les projets de données en mode de journalisation locale

  • Vérifiez que la gestion du cycle de vie des objets est activée pour le bucket de journaux. Recherchez une action Delete (Supprimer) correspondant à la valeur spécifiée par ttl_days dans la configuration de déploiement.

    Afficher les règles relatives au cycle de vie

  • Revenez à la page principale du navigateur de stockage et, dans l'angle supérieur droit, cliquez sur Afficher le panneau d'informations. À l'exception de cloud-storage-analytics@google.com, vérifiez que les autorisations correspondent à celles répertoriées dans le tableau 1. Pour comprendre pourquoi cloud-storage-analytics@google.com doit disposer d'un accès en écriture au bucket, consultez la documentation du produit.

    Groupes disposant d'autorisations en écriture

  • Pour les buckets qui stockent les journaux de données, vérifiez que les valeurs associées à Name (Nom), Default storage class (Classe de stockage par défaut) et Location (Emplacement) correspondent aux spécifications de la configuration de déploiement.

    Buckets nouvellement créés

  • Vérifiez que les objets de chaque bucket de données comprennent bien des versions gérées. Pour cela, exécutez la commande suivante en remplaçant bucket_name par le nom de votre bucket :

    gsutil versioning get gs://bucket_name
    
  • Vérifiez que les journaux d'accès et de stockage des buckets de données sont bien consignés et stockés dans le bucket de journaux. La journalisation a commencé lors de la création du bucket de données. Exécutez la commande suivante pour effectuer cette vérification :

    gsutil logging get gs://bucket_name
    
  • Vérifiez que les autorisations associées à chaque bucket sont définies conformément au tableau 1.

    Groupes disposant d'autorisations en écriture sur le bucket

Console d'administration

Console d'API

  • Dans la console d'API, vérifiez que l'API BigQuery est bien activée.

    API BigQuery activée dans la console d'API

Console Logging

  • Dans la console Logging, vérifiez qu'un nouveau récepteur d'exportation s'affiche. Notez les valeurs associées à Destination et Writer Identity (Identité du rédacteur), puis comparez-les à ce que vous obtiendrez ensuite dans la console BigQuery.

    Console Logging affichant un nouveau récepteur d'exportation

  • Vérifiez que les métriques basées sur les journaux sont configurées de façon à consigner les incidents liés aux activités suspectes dans les journaux d'audit.

    La console Stackdriver Logging montre comment les métriques basées sur les journaux sont configurées de façon à consigner les incidents liés aux activités suspectes.

Console BigQuery

  • Dans la console BigQuery, vérifiez que l'ensemble de données vers lequel Stackdriver exporte les journaux d'audit Cloud s'affiche. Vérifiez également que les valeurs associées à Description, Dataset ID (ID de l'ensemble de données) et Data location (Emplacement des données) correspondent aux spécifications de la configuration de déploiement et du récepteur d'exportation de journaux précédemment examiné.

    La console BigQuery affiche l'ensemble de données vers lequel Stackdriver exporte les journaux d'audit Cloud

  • Vérifiez que l'accès à l'ensemble de données est défini conformément au tableau 1. Vérifiez également que le compte de service qui transmet les journaux Stackdriver à BigQuery dispose de droits de modification sur l'ensemble de données.

    Autorisations d'accès aux données BigQuery

  • Vérifiez que les ensembles de données nouvellement créés pour stocker les données s'affichent et que les valeurs associées à Description, Dataset ID (ID de l'ensemble de données) et Data location (Emplacement des données), ainsi que les étiquettes de chaque ensemble de données, correspondent bien aux spécifications de la configuration de déploiement.

    La console BigQuery affiche les ensembles de données nouvellement créés

  • Vérifiez que l'accès à l'ensemble de données est défini conformément au tableau 1. En fonction des API que vous avez activées dans votre projet, vous verrez sans doute d'autres comptes de service avec des autorisations héritées.

    Autorisations BigQuery pour le stockage de données

Console Cloud Pub/Sub

  • Vérifiez que la console Cloud Pub/Sub affiche le sujet nouvellement créé et que le nom du sujet, la liste des abonnements et les détails de chaque abonnement (par exemple, les valeurs Delivery type [Type de distribution] et Acknowledgement deadline [Délai de confirmation]) correspondent aux spécifications de la configuration de déploiement.

    Vérifiez également que les droits d'accès au sujet correspondent bien à la configuration de déploiement. Par exemple, la capture d'écran ci-dessous montre que le groupe OWNERS_GROUP hérite de la propriété du sujet et que READ_WRITE_GROUP détient le rôle d'éditeur de sujets. En fonction des API que vous avez activées dans votre projet, vous verrez sans doute d'autres comptes de service avec des autorisations héritées.

    La console Cloud Pub/Sub affiche le sujet nouvellement créé

Console d'alerte Stackdriver

  • Dans la console d'alerte Stackdriver, vérifiez que les règles d'alerte affichées se déclenchent en fonction des métriques basées sur les journaux correspondantes.

    La console d'alerte Stackdriver affiche les règles d'alerte qui se déclenchent en fonction des métriques basées sur les journaux correspondantes

Journaux de requête

  • Comme les journaux d'audit sont transmis à BigQuery, vous pouvez exécuter la requête SQL suivante pour organiser l'historique des journaux dans l'ordre chronologique par type d'activité suspecte. Saisissez cette requête dans l'éditeur BigQuery ou via l'interface de ligne de commande BQ comme point de départ pour définir les requêtes que vous devez écrire pour répondre à vos besoins.

    SELECT timestamp,
           resource.labels.project_id                              AS project,
           protopayload_auditlog.authenticationinfo.principalemail AS offender,
           'IAM Policy Tampering'                                  AS offenseType
    FROM   `hipaa-sample-project.cloudlogs.cloudaudit_googleapis_com_activity_*`
    WHERE  resource.type = "project"
           AND protopayload_auditlog.servicename =
               "cloudresourcemanager.googleapis.com"
           AND protopayload_auditlog.methodname = "setiampolicy"
    UNION DISTINCT
    SELECT timestamp,
           resource.labels.project_id                              AS project,
           protopayload_auditlog.authenticationinfo.principalemail AS offender,
           'Bucket Permission Tampering'                           AS offenseType
    FROM   `hipaa-sample-project.cloudlogs.cloudaudit_googleapis_com_activity_*`
    WHERE  resource.type = "gcs_bucket"
           AND protopayload_auditlog.servicename = "storage.googleapis.com"
           AND ( protopayload_auditlog.methodname = "storage.setiampermissions"
                  OR protopayload_auditlog.methodname = "storage.objects.update" )
    UNION DISTINCT
    SELECT timestamp,
           resource.labels.project_id                              AS project,
           protopayload_auditlog.authenticationinfo.principalemail AS offender,
           'Unexpected Bucket Access'                              AS offenseType
    FROM   `hipaa-sample-project.cloudlogs.cloudaudit_googleapis_com_data_access_*`
    WHERE  resource.type = 'gcs_bucket'
           AND ( protopayload_auditlog.resourcename LIKE
                 '%hipaa-sample-project-logs'
                  OR protopayload_auditlog.resourcename LIKE
                     '%hipaa-sample-project-bio-medical-data' )
           AND protopayload_auditlog.authenticationinfo.principalemail NOT IN(
               'user1@google.com', 'user2@google.com' )
    

    L'image suivante présente un exemple de résultat lorsque la requête est exécutée à l'aide de l'interface de ligne de commande de BigQuery.

    Exemple de résultat lorsque la requête est exécutée à l'aide de l'interface de ligne de commande de BigQuery

Comprendre le code

Dans le cadre d'une utilisation générale, l'utilitaire d'automatisation du déploiement Google Cloud exploite Cloud Deployment Manager pour provisionner certaines ressources et configurer IAM et la journalisation conformément aux bonnes pratiques. Cette section décrit la structure du dépôt de code GitHub pour vous aider à comprendre le fonctionnement du code en coulisses.

Structure du dépôt de code

De haut en bas :

  • Le dossier samples contient des exemples de configurations de déploiement.
  • Le dossier templates contient des modèles de déploiement réutilisables.
  • Le dossier utils comprend diverses fonctions utilitaires employées par le script d'aide.
  • BUILD est un fichier de build Bazel.
  • README.md est une version allégée de ce guide.
  • create_project.py correspond au script d'aide qui simplifie l'exécution. Consultez la section Exécuter le script pour en savoir plus.
  • create_project_test.py contient les tests unitaires, qui ne sont pas abordés dans ce guide.
  • project_config.yaml.schema définit le schéma des configurations de déploiement (fichiers .yaml ) du dossier samples.
  • Requirements.txt est un package pip figé des fichiers requis.

Script d'aide : create_project.py

Le script d'aide create_project.py lit ses configurations à partir d'un fichier YAML et crée ou modifie les projets répertoriés dans ce fichier de configuration. Il génère un projet de journaux d'audit si audit_logs_project est fourni, puis crée un projet d'hébergement de données pour chaque projet répertorié sous projects. Le script effectue les opérations suivantes pour chaque projet répertorié :

  • Si le projet n'existe pas déjà, le script le crée.
  • Il active la facturation sur le projet.
  • Il active l'API Deployment Manager et exécute le modèle data_project.py pour déployer des ressources dans le projet. Le script attribue des autorisations de propriétaire temporaires au compte de service Deployment Manager lors de l'exécution du modèle.
  • Si vous stockez les journaux d'audit à distance, le script crée les journaux d'audit dans le projet de journaux d'audit à l'aide du modèle remote_audit_logs.py.
  • Il vous invite à créer ou à sélectionner un espace de travail Stackdriver. Vous devez effectuer cette action depuis l'interface utilisateur Stackdriver. Pour en savoir plus, consultez le guide de Stackdriver.
  • Si elles n'existent pas déjà, le script crée des métriques basées sur les journaux et des alertes Stackdriver pour surveiller les activités suspectes.

Exemples de configurations de déploiement

Dans Deployment Manager, vous devez utiliser une configuration pour décrire toutes les ressources souhaitées pour un déploiement. Un fichier de configuration est au format YAML et répertorie chacune des ressources que vous souhaitez créer et leurs propriétés respectives. Par exemple :

  • Les buckets Cloud Storage sont spécifiés à l'aide du champ data_buckets.
  • Les ensembles de données BigQuery sont spécifiés à l'aide du champ bigquery_datasets.
  • Le sujet Cloud Pub/Sub est spécifié à l'aide du champ pubsub.

Un nombre croissant d'exemples de fichiers de configuration est à votre disposition. Selon que vous avez choisi de stocker les journaux d'audit localement ou à distance, vous commencez à partir du fichier project_with_local_audit_logs.yaml ou project_with_remote_audit_logs.yaml. Avant d'utiliser l'un des exemples, passez en revue et personnalisez les valeurs afin de refléter la configuration souhaitée.

Le schéma de ces fichiers YAML est défini dans project_config.yaml.schema :

  • La section overall contient des informations sur l'organisation (organization) et la facturation (billing) qui s'appliquent à tous les projets. Si vous ne déployez pas vos projets dans une organisation GCP, vous pouvez omettre l'ID organization_id. Veillez néanmoins à surveiller l'ensemble des projets de votre organisation.
  • Si vous utilisez des journaux d'audit distants, définissez le projet qui les hébergera dans la section audit_logs_project.
  • Répertoriez tous les projets d'hébergement de données requis sous projects.

Modèles de déploiement

Un modèle Deployment Manager correspond essentiellement à différentes parties d'un fichier de configuration qui ont été converties en un composant fondamental réutilisable. Le dossier templates contient un nombre croissant de modèles, deux d'entre eux étant abordés en détail dans ce guide. Outre les fichiers .py, vous constaterez des fichiers .schema correspondants dans le dossier "templates". Ces fichiers de schéma valident les champs des modèles. Par exemple, data_project.py.schema et remote_audit_logs.py.schema appliquent respectivement le schéma adéquat aux fichiers data_project.py et remote_audit_logs.py.

Le fichier data_project.py configure un nouveau projet pour l'hébergement de données et éventuellement pour les journaux d'audit. Il effectue les opérations suivantes :

  • Il attribue la propriété exclusive du projet à owners_group.
  • Il crée des ensembles de données BigQuery pour stocker les données, avec les contrôles des accès recommandés conformément au tableau 1.
  • Il crée des buckets Cloud Storage pour stocker les données, avec le contrôle des accès recommandé conformément au tableau 1. Il active également la gestion des versions des objets ainsi que les journaux d'accès et de stockage pour le bucket.
  • Il crée un sujet Cloud Pub/Sub et un abonnement avec les contrôles des accès définis conformément au tableau 1.
  • Si vous stockez les journaux d'audit localement, le fichier :
    • crée un ensemble de données BigQuery pour stocker les journaux d'audit, avec le contrôle des accès défini conformément au tableau 1.
    • crée un bucket Cloud Storage pour stocker les journaux d'accès et de stockage, avec le contrôle des accès défini conformément au tableau 1 et la durée de vie conformément à la valeur ttl_days spécifiée dans le fichier de configuration.
  • Il crée un récepteur de journaux pour exporter en continu tous les journaux d'audit vers BigQuery.
  • Il crée des métriques basées sur les journaux pour consigner le nombre d'incidents lorsque :
    • les stratégies IAM au niveau du projet sont modifiées. Cela inclut les stratégies IAM associées aux sujets Cloud Pub/Sub.
    • les autorisations relatives aux buckets Cloud Storage ou à leurs objets individuels sont modifiées.
    • les autorisations associées aux ensembles de données BigQuery sont modifiées.
    • toute personne autre que les utilisateurs définis dans la collection expected_users, spécifiée dans la configuration de déploiement, accède aux ressources couvertes. À l'heure actuelle, cela ne concerne que les buckets Cloud Storage.
  • Il active la journalisation de l'accès aux données sur tous les services.

Le fichier remote_audit_logs.py configure les ressources pour qu'elles stockent les journaux dans un projet distinct de celui où les données se trouvent. Il effectue les opérations suivantes :

  • logs_bigquery_dataset spécifie le nom de l'ensemble de données BigQuery pour stocker les journaux d'audit Cloud. L'accès à cet ensemble de données est défini conformément au tableau 1.
  • logs_gcs_bucket spécifie un bucket Cloud Storage pour stocker les journaux d'accès et de stockage. L'accès à ce bucket est défini conformément au tableau 1. La durée de vie est spécifiée conformément à la valeur ttl_days du fichier de configuration.

Nettoyer

  1. Dans la console GCP, accédez à la page "Projets".

    Accéder à la page Projets

  2. Dans la liste des projets, sélectionnez celui que vous souhaitez supprimer, puis cliquez sur Supprimer.
  3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Étape suivante

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…