Conformité avec la loi HIPAA sur Cloud de Confiance et Google Workspace

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. Le contenu client est chiffré au repos sur Cloud de Confiance. Si vous avez des exigences de chiffrement supplémentaires, utilisez Cloud KMS.

Suivez les bonnes pratiques IAM lorsque vous configurez les accès à votre projet. En particulier, étant donné que les comptes de service peuvent être utilisés pour accéder aux ressources, contrôlez étroitement l'accès à ces comptes de service et à leurs clés.

• Ne stockez que le minimum de données nécessaires pour fournir l'authentification et l'autorisation pour votre application ou service. Lorsque vous créez un utilisateur dans Identity Platform, le seul attribut obligatoire est une adresse e-mail ou un numéro de téléphone. Si vous devez stocker des données de santé protégées, utilisez une solution de base de données à usage général dans Cloud de Confiance.
• Ne stockez pas de données de santé protégées dans des attributs facultatifs ou personnalisés, tels que des noms à afficher ou des URL de photos. Si vous devez stocker des données de santé protégées, utilisez une solution de base de données à usage général dans Cloud de Confiance.
• Ne transmettez pas de données de santé protégées de fournisseurs d'identité externes fédérés à Identity Platform dans des jetons, des revendications, des assertions ou par tout autre mécanisme.
• Ne synchronisez pas les données de santé protégées provenant de systèmes d'identité externes vers Identity Platform. Google n'émet aucune assertion ni garantie quant à leur sécurité lors du transfert ou à réception par la tierce partie.
• N'utilisez pas de comptes anonymes lors de l'interaction, de la gestion ou du stockage des données de santé protégées.
• N'utilisez pas les SDK et les bibliothèques clientes Identity Platform lorsque vous interagissez avec des données de santé protégées, les gérez ou les stockez. Comme ce code s'exécute en dehors d'Identity Platform, Google n'émet aucune assertion ni garantie quant à la sécurité des informations en dehors du service Identity Platform, par exemple sur l'appareil d'un utilisateur final.

Lorsque vous stockez des secrets dans Secret Manager, consultez et suivez les bonnes pratiques de Secret Manager.

• Configurez les destinations d'exportation des journaux d'audit. Exportez les journaux d'audit vers Cloud Storage pour un archivage à long terme et vers BigQuery pour répondre à vos besoins d'analyse, de surveillance et d'investigation. Configurez les contrôles d'accès appropriés pour ces destinations.
• Configurez les contrôles d'accès aux journaux. Les utilisateurs disposant du rôle Visionneuse de journaux (roles/logging.viewer) peuvent accéder aux journaux d'audit des activités d'administration, et les utilisateurs disposant du rôle Visionneuse de journaux privés (roles/logging.privateLogViewer) peuvent accéder aux journaux d'audit des accès aux données.
• Examinez régulièrement les journaux d'audit pour garantir la sécurité et la conformité aux exigences. Pour l'analyse de journaux à grande échelle, utilisez BigQuery ou une plate-forme SIEM pour démontrer la conformité via l'analyse de journaux.

• Ne stockez pas de données de santé protégées dans les métadonnées telles que les étiquettes de métriques, les étiquettes de VM, les annotations de ressources GKE, ou les titres ou contenus des tableaux de bord. Toute personne disposant des autorisations IAM appropriées peut consulter votre console de surveillance ou utiliser l'API Cloud Monitoring pour voir ces données.
• Ne placez pas de données de santé protégées dans des configurations d'alerte (par exemple, dans les noms à afficher ou la documentation) qui peuvent être envoyées aux destinataires de l'alerte.

N'utilisez pas les services ou fonctionnalités suivants :

• Services tiers autres que ceux fournis par un affilié Google ou un fournisseur d'infrastructure dans le cloud.
• Assistance d'analystes à la demande.
• Services, logiciels ou matériel non Google fournis au personnel de Google dans le cadre d'un engagement Mandiant Consulting Services.
• Outils d'intégration d'API non sécurisés.

Lorsque vous configurez des jobs Sensitive Data Protection, 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é.

Activez la gestion des versions d'objets pour conserver les archives historiques et récupérer les objets après une suppression accidentelle.

Utilisez des méthodes de connectivité IP privée pour éviter d'exposer sur Internet une base de données contenant des données de santé protégées.

• 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.
• Utilisez les sauvegardes Filestore pour récupérer des données après une suppression accidentelle.

Lorsque vous créez ou configurez des index, chiffrez les données de santé protégées, les identifiants de sécurité ou d'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 en savoir plus, consultez Index Datastore.

Vous devez accepter que Data Studio soit régi par votre contrat Cloud de Confiance .

N'incluez pas de données de santé protégées ni d'informations permettant d'identifier personnellement l'utilisateur dans les valeurs des champs google.cloud.datacatalog.lineage.v1.Process.attributes et google.cloud.datacatalog.lineage.v1.Run.attributes.

• Assurez-vous que les administrateurs examinent les configurations de sécurité des applications et intégrations tierces, ainsi que toute documentation correspondante sur la sécurité et la confidentialité de l'application tierce.
• Lorsque vous créez des requêtes structurées, évitez d'inclure ou de stocker des données de santé protégées dans la logique métier qui configure ces requêtes.

Utilisez les API régionales et les emplacements de ressources pour les données de santé protégées.

N'incluez pas de données de santé protégées ni d'identifiants de sécurité dans la définition de votre agent, y compris dans les intents, les phrases d'entraînement et les entités.

Si 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, n'activez pas la journalisation des données.

N'incluez pas de données de santé protégées ni d'informations permettant d'identifier personnellement l'utilisateur dans les en-têtes.

• 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 IntegrationParameter, le champ de nom dans projects.locations.connections ou les paramètres de configuration de la ressource Connection. 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.

N'incluez pas de 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.

Ne demandez pas la mise en cache des données de santé protégées. Pour empêcher la mise en cache, consultez Empêcher la mise en cache.

N'incluez pas de données de santé protégées dans les URI ou les actions.

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 compte utilisateur disposant du rôle Lecteur Artifact Registry (roles/artifactregistry.reader) ou du rôle Lecteur Artifact Registry (roles/artifactregistry.viewer). Pour empêcher tout accès non autorisé aux données de santé protégées, consultez Contrôler l'accès et protéger les artefacts.

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. Pour empêcher tout accès non autorisé aux données de santé protégées, consultez Bonnes pratiques pour sécuriser les conteneurs.

Conservez les journaux d'accès au niveau de l'application pendant une période appropriée afin de répondre aux exigences de la loi HIPAA.

Lorsque vous déployez Distributed Cloud connecté, vous êtes responsable de certains aspects de la sécurité, en particulier de la sécurité physique. Pour sécuriser votre déploiement, consultez Bonnes pratiques de sécurité physique.

N'utilisez pas les services suivants, qui ne sont pas couverts par l'avenant relatif à la conformité avec la loi HIPAA :

• Tout service tiers (y compris les services exclus) autre que les services fournis par une société affiliée de Google ou un fournisseur d'infrastructure cloud.
• Tout outil d'intégration d'API qui n'est pas sécurisé.

Tenez compte des points suivants lorsque vous implémentez des contrôles d'accès :

• Utilisez le paramètre access filter avec des attributs utilisateur pour appliquer la sécurité des données au niveau des lignes, des colonnes ou des champs par utilisateur ou groupe d'utilisateurs.
• Minimisez l'accès aux données pour vos utilisateurs en limitant les droits d'accès des administrateurs, des développeurs et de l'exécuteur SQL.
• Créez un processus qui permet d'empêcher le partage de PHI avec les services exclus et le personnel Google, y compris les équipes d'assistance technique utilisant l'accès à l'assistance ou les équipes de services professionnels lors d'un engagement.
• Configurez l'utilisation des API entre Google et votre fournisseur ou d'autres tiers de manière sécurisée.

Tenez compte des points suivants lorsque vous partagez des données :

• Ne partagez pas de données de santé protégées et ne demandez pas à Google de les partager avec un tiers, sauf si un accord de partenariat est en place avec ce tiers.
• Ne partagez pas de données de santé protégées par e-mail. Configurez Looker pour rediriger les destinataires des e-mails vers l'instance Looker où ils doivent se connecter pour accéder aux données de santé protégées ou aux contenus sensibles associés.
• Créez des processus permettant de s'assurer que les données de santé protégées ne sont pas jointes ni envoyées à l'aide d'une fonctionnalité de chat d'assistance technique.
• Ne stockez les résultats des requêtes en cache que pendant la durée minimale nécessaire pour les ensembles de données et les cas d'utilisation.
• Limitez les moments où les utilisateurs peuvent créer des liens publics.
• Créez et tenez à jour des journaux lorsque vous autorisez un tiers à utiliser des données de santé protégées agrégées.

Tenez compte des points suivants lorsque vous configurez la sécurité :

• Mettez en œuvre des méthodes d'authentification des utilisateurs conformes aux normes du secteur, telles que l'authentification à deux facteurs ou l'authentification unique compatible avec SAML. Si un utilisateur utilise l'authentification unique, limitez l'autorisation login_special_email à deux utilisateurs au maximum.
• Appliquer la sécurité de l'ensemble de données dans le modèle Looker.
• Au moins une fois par trimestre, auditez l'ensemble des utilisateurs, groupes, autorisations, rôles, clés API, liens publics, ainsi que les autres contrôles d'accès, partages et configurations de sécurité.

Tenez compte des points suivants lorsque vous configurez les contrôles de sécurité de la base de données :

• Lorsque vous accordez l'accès à vos bases de données, suivez le principe du moindre privilège pour la base de données et ses informations.
• Assurez-vous que toutes les connexions à la base de données sont chiffrées en transit et utilisez un serveur de tunnel pour toute connexion par tunnel SSH.
• Utilisez une liste d'autorisation pour limiter l'accès externe aux seules adresses IP spécifiques à Google.
• Configurez les droits de votre base de données de sorte que Google ne dispose pas d'un accès en écriture ni d'un accès administrateur à vos bases de données.