Conformité avec la loi HIPAA sur Google Cloud

Ce guide traite de la conformité avec la loi HIPAA sur Google Cloud. La conformité avec la loi HIPAA pour Google Workspace est traitée séparément.

Clause de non-responsabilité

Le présent guide est fourni à titre informatif uniquement. Les informations ou recommandations qui y sont mentionnées n'ont pas vocation à constituer des conseils juridiques. Il appartient à chaque client d'évaluer indépendamment sa propre utilisation des services de manière appropriée afin de s'acquitter de ses obligations légales en termes de conformité.

Audience cible

Google Cloud permet aux clients soumis aux exigences de la loi américaine HIPAA (Health Insurance Portability and Accountability Act, telle qu'elle a été amendée, y compris par la loi HITECH, Health Information Technology for Economic and Clinical Health Act) de s'y conformer. Ce guide est destiné aux responsables de la sécurité, aux responsables de la conformité, aux administrateurs informatiques, et aux autres employés responsables de la mise en œuvre de la loi HIPAA et de la conformité avec ladite loi sur Google Cloud. Après avoir lu ce guide, vous aurez compris comment Google peut vous permettre d'être en conformité avec la loi HIPAA et comment configurer les projets Google Cloud de façon à respecter vos responsabilités dans le cadre de cette loi.

Définitions

Tout terme commençant par une majuscule non défini dans le présent document a la même signification que dans la loi HIPAA. En outre, aux fins du présent document, les Données de santé protégées désignent les Données de santé protégées que Google reçoit d'une Entité soumise à la loi HIPAA.

Présentation

Il est important de noter qu'il n'existe aucune certification reconnue par le département de la Santé et des Services sociaux (HHS) des États-Unis en ce qui concerne la conformité avec la loi HIPAA, et que ladite conformité relève de la responsabilité partagée du client et de Google. La loi HIPAA exige par exemple la conformité avec la Security Rule (Règle de sécurité), la Privacy Rule (Règle de confidentialité) et la Breach Notification Rule (Règle de notification en cas de violation). Dans le cadre d'un Accord de partenariat, Google Cloud rend possible la conformité avec la loi HIPAA, mais il appartient aux clients d'évaluer leur propre conformité avec ladite loi.

Google conclura des Accords de partenariat avec les clients lorsque la loi HIPAA l'exige. Google Cloud a été conçu sous la direction d'une équipe de plus de 700 ingénieurs de sécurité, plus grande que la plupart des équipes de sécurité sur site. Vous trouverez des informations spécifiques sur notre approche de la sécurité et de la protection des données, y compris sur les contrôles organisationnels et techniques pour la protection de vos données mis en place par Google, dans le livre blanc sur la sécurité de Google et la présentation de la sécurité sur l'infrastructure de Google.

Outre l'exposé de son approche en matière de sécurité et de prise en compte de la confidentialité, Google se soumet régulièrement à différents audits réalisés par des tiers indépendants, afin de fournir aux clients une validation externe (des liens vers les rapports et les certificats sont disponibles ci-dessous). Cela signifie qu'un auditeur indépendant examine les dispositifs de contrôle de nos centres de données, de notre infrastructure et de nos opérations. Google réalise chaque année des audits portant sur les normes suivantes :

SSAE 16/ISAE 3402 Type II : le rapport SOC 3 public associé peut être consulté à cette adresse. Le rapport SOC 2 peut être obtenu dans le cadre d'un NDA.
ISO 27001 : Google a obtenu cette certification pour les systèmes, les applications, les personnes, la technologie, les processus et les centres de données qui fournissent les services Google Cloud. Notre certificat ISO 27001 est disponible dans la section de notre site Web portant sur la conformité.
ISO 27017, sécurité dans le cloud. il s'agit d'une norme internationale sur les bonnes pratiques de contrôle de la sécurité des informations. Elle est basée sur la norme ISO/IEC 27002 et est spécifiquement adaptée aux services cloud. Notre certificat ISO 27017 est disponible dans la section de notre site Web portant sur la conformité.
ISO 27018, protection des données à caractère personnel dans le cloud. Il s'agit d'une norme internationale sur les bonnes pratiques pour la protection des informations personnelles dans les services cloud publics. Notre certificat ISO 27018 est disponible dans la section de notre site Web portant sur la conformité.
FedRAMP ATO
PCI DSS v3.2.1

Ce système complet d'audits tiers permet à Google de garantir la confidentialité, l'intégrité et la disponibilité de son environnement, mais aussi de fournir l'assurance de son engagement en faveur d'une sécurité optimale des informations. Les clients peuvent se référer à ces rapports d'audit tiers pour évaluer dans quelle mesure les produits Google peuvent répondre à leurs besoins en matière de conformité avec la loi HIPAA.

Responsabilités du client

L'une des principales responsabilités du client est de déterminer s'il constitue une Entité soumise à la loi HIPAA ou un Partenaire d'une Entité soumise à la loi HIPAA (Business Associate of a Covered Entity) et, le cas échéant, si ses interactions avec Google requièrent la conclusion d'un Accord de partenariat avec Google.

Google fournit une infrastructure sécurisée et conforme (décrite ci-dessus) pour le stockage et le traitement des Données de santé protégées, mais il incombe au client de veiller à ce que l'environnement et les applications qu'il crée sur Google Cloud soient configurés et sécurisés de manière adéquate conformément aux exigences de la loi HIPAA, ce que l'on appelle généralement un modèle de sécurité partagé dans le cloud.

Bonnes pratiques essentielles :

Mettez en place un Accord de partenariat Google Cloud. Vous pouvez le solliciter directement auprès de votre responsable de compte.
Lorsque vous travaillez avec des Données de santé protégées, désactivez les produits Google Cloud qui ne sont pas explicitement couverts par l'Accord de partenariat (consultez la section Produits couverts) ou assurez-vous ne pas les utiliser.
N'utilisez pas d'offres pré-DG (produits ou services proposés dans le cadre du programme de prédisponibilité Google Cloud ou d'autres offres pré-DG telles que définies dans les Conditions spécifiques des services de Google) en lien avec des Données de santé protégées, sauf indication contraire expresse dans un avis ou d'autres conditions de l'offre.

Bonnes pratiques techniques recommandées :

Utilisez les bonnes pratiques IAM lors de la configuration de l'accès à votre projet. Les comptes de service pouvant être utilisés pour accéder aux ressources, assurez-vous notamment que l'accès à ces comptes de service et aux clés de compte de service est étroitement contrôlé.
Déterminez si votre organisation a des exigences de chiffrement différentes de celles requises par la règle de sécurité de la loi HIPAA. Tous les contenus client sont chiffrés au repos sur Google Cloud. Consultez notre livre blanc sur le chiffrement pour plus d'informations, y compris en ce qui concerne les exceptions éventuelles.
Si vous utilisez Cloud Storage, il est recommandé d'activer la gestion des versions des objets afin de permettre l'archivage de ces données et de pouvoir annuler leur éventuelle suppression accidentelle.
Configurez les destinations des exportations des journaux d'audit. Nous vous encourageons fortement à exporter les journaux d'audit vers Cloud Storage pour l'archivage à long terme, ainsi que vers BigQuery pour tout besoin d'analyse, de surveillance et/ou d'examen. Veillez à configurer le contrôle d'accès pour les destinations appropriées dans le cadre de votre organisation.
Configurez un contrôle des accès aux journaux adapté à votre organisation. Les utilisateurs dotés du rôle "Lecteur de journaux" peuvent accéder aux journaux d'audit relatifs aux activités d'administration, et les utilisateurs dotés du rôle "Lecteur des journaux privés" peuvent accéder aux journaux d'audit relatifs à l'accès aux données.
Examinez régulièrement les journaux d'audit afin de garantir la sécurité et la conformité aux exigences. Comme indiqué ci-dessus, BigQuery est une excellente plate-forme pour l'analyse de journaux à grande échelle. Vous pouvez également utiliser les plates-formes SIEM de nos intégrations tierces pour démontrer la conformité par le biais de l'analyse des journaux.
Lors de la création ou de la configuration des index dans Cloud Datastore, chiffrez les Données de santé protégées, les identifiants de sécurité et les autres données sensibles avant de les utiliser comme clé d'entité, clé de propriété indexée ou valeur de propriété indexée pour l'index. Consultez la documentation Cloud Datastore pour plus d'informations sur la création et/ou la configuration des index.
Lors de la création ou de la mise à jour de Dialogflow, veillez à ne pas inclure de Données de santé protégées ni d'identifiants de sécurité dans la définition de l'agent, y compris dans les Intents, les Phrases d'entraînement et les Entités.
Lors de la création ou de la mise à jour de ressources, veillez à ne pas inclure de Données de santé protégées ni d'identifiants de sécurité lorsque vous spécifiez les métadonnées, car ces informations peuvent être enregistrées dans les journaux. Les journaux d'audit n'incluent jamais le contenu des données d'une ressource ni les résultats d'une requête effectuée dans les journaux, mais les métadonnées des ressources peuvent être recueillies.
Adoptez les pratiques Identity Platform lorsque vous utilisez ce service pour votre projet.
Lorsque vous utilisez les services Cloud Build pour le développement ou l'intégration continus, évitez d'inclure ou de stocker des Données de santé protégées dans les fichiers de configuration de compilation, les fichiers de contrôle sources ou autres artefacts de compilation.
Si vous utilisez Looker (Google Cloud Core), les personnes désignées par le Client pour administrer les instances ou les ressources doivent examiner les configurations de sécurité des applications et intégrations tierces, ainsi que toute documentation correspondante sur la sécurité et la confidentialité fournie par l'application tierce.
Si vous utilisez Looker (Google Cloud Core) pour structurer les requêtes, évitez d'inclure ou de stocker des données de santé protégées dans la logique métier utilisée pour configurer ces requêtes. Consultez la documentation pour en savoir plus sur la structuration des requêtes.
Si vous utilisez Cloud CDN, assurez-vous d'avoir désactivé la mise en cache des Données de santé protégées. Consultez la documentation Cloud CDN pour en savoir plus sur les façons d'empêcher la mise en cache.
Si vous utilisez Cloud Speech-to-Text, et que vous avez conclu un Accord de partenariat avec Google couvrant les obligations liées aux Données de santé protégées en vertu de la loi HIPAA, vous ne devriez pas activer le programme de journalisation des données.
Si vous utilisez Google Cloud VMware Engine, il vous incombe de conserver les journaux d'accès au niveau de l'application pour une période appropriée, si nécessaire, afin de répondre aux exigences de la loi HIPAA.
Lorsque vous configurez des tâches de protection des données sensibles, assurez-vous que toutes les données de sortie sont écrites sur les cibles de stockage configurées dans le cadre de votre environnement sécurisé.
Consultez et suivez les instructions fournies dans les Bonnes pratiques de Secret Manager concernant le stockage de secrets dans Secret Manager.
Artifact Registry chiffre les données dans les dépôts à l'aide du chiffrement par défaut de Google ou de clés de chiffrement gérées par le client (CMEK). Les métadonnées, telles que les noms d'artefacts, sont chiffrées à l'aide du chiffrement par défaut de Google. Ces métadonnées peuvent apparaître dans les journaux et sont visibles par tout utilisateur disposant des autorisations du rôle Lecteur Artifact Registry ou Lecteur. Suivez les instructions de la section Sécuriser les artefacts pour éviter tout accès non autorisé aux données de santé protégées.
Container Registry chiffre les données dans les buckets de stockage de vos registres à l'aide du chiffrement par défaut de Google ou de CMEK. Suivez les bonnes pratiques concernant les conteneurs pour empêcher tout accès non autorisé aux données de santé protégées.
Si vous utilisez Filestore, utilisez le contrôle des accès basé sur les adresses IP pour limiter les VM Compute Engine et les clusters GKE autorisés à accéder à l'instance Filestore. Pensez à utiliser des sauvegardes pour permettre la récupération des données en cas de suppression accidentelle de données.
Si vous utilisez Cloud Monitoring, ne stockez pas de données de santé protégées dans les métadonnées de Google Cloud, y compris les étiquettes de métriques, les étiquettes de VM, les annotations de ressources GKE, ou les titres/contenus des tableaux de bord. Toute personne autorisée via IAM à consulter votre console de surveillance ou à utiliser l'API Cloud Monitoring peut voir ces données. Ne placez pas de données de santé protégées dans des configurations d'alerte (par exemple, le nom à afficher ou la documentation) qui pourraient être envoyées aux destinataires de l'alerte.
Lorsque vous utilisez reCAPTCHA Enterprise, évitez d'inclure des données de santé protégées dans les URI ou les actions.
Si vous utilisez API Gateway, les en-têtes ne doivent pas contenir de données de santé protégées ni d'informations permettant d'identifier personnellement l'utilisateur.
Pour Database Migration Service, utilisez des méthodes de connectivité IP privée afin d'éviter d'avoir à exposer sur Internet une base de données contenant des données de santé protégées.
Si vous utilisez Dataplex, les valeurs des champs google.cloud.datacatalog.lineage.v1.Process.attributes et google.cloud.datacatalog.lineage.v1.Run.attributes ne doivent pas contenir de données de santé protégées ni d'informations permettant d'identifier personnellement l'utilisateur.
Lorsque vous utilisez Vertex AI Search, utilisez les API régionales et les emplacements de ressources pour les données de santé protégées.
Lorsque vous utilisez Application Integration et les connecteurs d'intégration, n'incluez pas d'informations permettant d'identifier personnellement l'utilisateur, de données de santé protégées ni d'autres informations sensibles dans le paramètre d'intégration, le nom de la connexion ou la configuration de la connexion, car ces informations peuvent être consignées. Configurez le contrôle des accès aux journaux si la charge utile demandée contient des données sensibles. Certains connecteurs basés sur des fichiers et événements basés sur des webhooks proposés par Integration Connectors stockent les données de manière temporaire. Les clients peuvent chiffrer ces données avec la clé de leur choix à l'aide de CMEK.

Produits couverts

L'Accord de partenariat Google Cloud couvre l'intégralité de l'infrastructure de Google Cloud (l'ensemble des régions, zones, chemins réseau et points de présence), ainsi que les produits suivants :

Access Approval
Access Context Manager
Access Transparency
AI Platform Data Labeling
AI Platform Training et AI Platform Prediction
AlloyDB pour PostgreSQL
API Gateway
Apigee
App Engine
Application Integration
Artifact Registry
Assured Workloads
AutoML Natural Language
AutoML Tables
AutoML Translation
AutoML Video
AutoML Vision
Solution Bare Metal
Lot
BigQuery
Service de transfert de données BigQuery
BigQuery Omni
Bigtable
Autorisation binaire
Inventaire des éléments cloud
Sauvegarde dans le cloud et reprise après sinistre
Cloud Build
Cloud CDN
Cloud Composer
console Cloud
Cloud Data Fusion
Cloud Deploy
Cloud Deployment Manager
Cloud DNS
Cloud Endpoints
Cloud Filestore
Cloud Functions
API Cloud Healthcare
Cloud HSM
Cloud Identity
Cloud IDS
Cloud Interconnect
Cloud Key Management Service
Cloud Life Sciences (anciennement Google Genomics)
Cloud Load Balancing
Cloud Logging
Cloud Monitoring
Cloud NAT (traduction d'adresses réseau)
API Cloud Natural Language
Cloud Profiler
Cloud Router
Cloud Run (entièrement géré)
Cloud Run for Anthos
Cloud Scheduler
Cloud Shell
Cloud Source Repositories
Cloud SQL
Cloud Storage
Cloud Tasks
Cloud Trace
Cloud Translation
Cloud Vision
Cloud VPN
Colab Enterprise
Compute Engine
Config Management
Connecter
Contact Center AI
Contact Center AI Insights
Contact Center AI Agent Assist
Container Registry
Database Migration Service
Data Catalog
Dataflow
Dataform
Datalab
Dataplex
Dataproc
Datastore
Datastream
Dialogflow
Document AI
Document AI Warehouse
Eventarc
Firestore
IA générative sur Vertex AI
GKE Hub
Application Google Cloud
Google Cloud Armor
Google Cloud Identity-Aware Proxy
Google Cloud VMware Engine (GCVE)
Google Kubernetes Engine
Healthcare Data Engine
Looker (Google Cloud Core)
Looker Studio*
Identity and Access Management (IAM)
Identity Platform
Integration Connectors
IoT Core
Key Access Justifications (KAJ)
Service géré pour Microsoft Active Directory (AD)
Memorystore
Niveaux de service réseau
Persistent Disk
Pub/Sub
Risk Manager
reCAPTCHA Enterprise
API Resource Manager
Secret Manager
Security Command Center
Protection des données sensibles
Service Consumer Management
Service Control
Annuaire des services
Gestion du service
Service Mesh
Spanner
Speech-to-Text
Service de transfert de stockage
Text-to-Speech
Traffic Director
Transfer Appliance
Vertex AI Platform (anciennement Vertex AI)
Vertex AI Search
API Video Intelligence
Cloud privé virtuel
VPC Service Controls
Web Security Scanner
Instances Vertex AI Workbench
Workflows

* À condition que le Client ait choisi que Looker Studio soit régi par son contrat Google Cloud.

Cette liste est mise à jour à mesure que de nouveaux produits deviennent disponibles dans le programme HIPAA.

Fonctionnalités uniques

Les pratiques de sécurité de Google Cloud nous permettent de disposer d'un accord de partenariat lié à la loi HIPAA couvrant l'ensemble de l'infrastructure de Google Cloud, et non une partie distincte de notre cloud. Par conséquent, vous n'êtes pas limité à une région spécifique, ce qui présente des avantages en termes d'évolutivité, d'opération et d'architecture. Vous pouvez également bénéficier d'une redondance multirégionale des services ainsi que de la possibilité d'utiliser des machines virtuelles préemptives pour réduire les coûts.

Les mesures de sécurité et de conformité qui nous permettent de rendre possible la conformité avec la loi HIPAA sont profondément enracinées dans notre infrastructure, notre conception de la sécurité et nos produits. Ainsi, nous pouvons offrir aux clients soumis à la loi HIPAA les mêmes produits aux mêmes prix que ceux proposés à tous les clients, y compris les remises automatiques proportionnelles à une utilisation soutenue. D'autres clouds publics surfacturent l'utilisation de leur cloud HIPAA, mais pas Google.

Conclusion

Google Cloud est l'infrastructure cloud dans laquelle les clients peuvent stocker les informations de santé, les analyser et en tirer des insights en toute sécurité, sans avoir à se soucier de l'infrastructure sous-jacente.