Amazon Quick et HIPAA : les réglages à décider avant le déploiement

Pour préparer Amazon Quick à des flux contenant des informations de santé protégées (PHI), définissez le périmètre du compte et les responsabilités, puis arrêtez les choix de chiffrement et d’identité avant de créer les ressources. AWS décrit Amazon Quick comme éligible à HIPAA, mais cette éligibilité ne rend pas à elle seule l’environnement du client conforme. HIPAA est le cadre juridique américain traité ici.

Avant de commencer : le compte et les responsabilités

AWS indique que l’accord de partenariat commercial (Business Associate Agreement, ou BAA) se valide dans AWS Artifact pour un compte AWS précis. Il ne couvre ni les autres comptes, ni les services non éligibles, ni la configuration du client. Celui-ci doit aussi choisir des services éligibles et maintenir ses propres mesures de protection, sa gouvernance et ses contrôles.

AWS présente Amazon Quick comme éligible à HIPAA sur ses clients web, ordinateur et mobile. Son guide de déploiement publié le 22 octobre 2026 détaille la configuration de la version web.

Les décisions à prendre avant la création des ressources

La clé de chiffrement, le fournisseur d’identité et les autorisations documentaires ne se règlent pas tous au même moment. AWS indique que certains choix sont définitifs une fois les données ou la base de connaissances créées.

1. Validez le BAA pour le compte concerné

Acceptez le BAA dans AWS Artifact pour le compte AWS qui utilisera Amazon Quick. Ce périmètre compte : l’accord ne s’étend pas automatiquement aux autres comptes de l’organisation.

2. Choisissez la clé de chiffrement du compte

AWS indique que le chiffrement au repos est activé par défaut avec des clés détenues ou gérées par AWS. Une clé gérée par le client est facultative et nécessite un abonnement Enterprise. Si vous en avez besoin, choisissez-la avant la première création de données Amazon Quick : AWS indique que la clé du compte ne peut plus être modifiée ensuite. AWS avertit aussi que la suppression de cette clé peut entraîner la perte définitive des données lors du désabonnement puis du réabonnement.

3. Arrêtez le modèle d’identité avant le déploiement

AWS cite quatre options : IAM Identity Center, Active Directory, la fédération IAM et les utilisateurs locaux Quick. Le fournisseur d’identité peut être changé, mais AWS indique qu’il faut alors recréer les autorisations des utilisateurs et leurs appartenances aux espaces. La détection des utilisateurs inactifs est décrite comme disponible avec IAM Identity Center ou Active Directory.

4. Activez les ACL au moment de créer la base de connaissances

Pour les sources compatibles, choisissez la prise en charge des ACL par document lors de la création de la base de connaissances. Ces listes relient les documents aux droits d’accès des utilisateurs. AWS avertit qu’une correspondance erronée entre identités et ACL peut exposer des documents sans déclencher d’erreur ni d’alerte.

AWS indique que le cycle d’actualisation par défaut de la base de connaissances est de 24 heures. Si une modification des droits doit se répercuter plus vite, le guide recommande de raccourcir ce cycle.

Séparez les documents des données structurées

Les documents non structurés et les données structurées ne suivent pas le même chemin de contrôle. Pour les premiers, les ACL au niveau du document limitent ce que la base de connaissances peut restituer. Pour les données analytiques, AWS décrit des contrôles au niveau des lignes et des colonnes dans Amazon Quick Sight, ainsi que des permissions en amont dans le lac de données.

Dans son exemple fictif, AWS place des documents Amazon S3 dans une base de connaissances protégée par ACL. Les données de sinistres suivent un autre parcours : elles sont préparées et désidentifiées en amont avec AWS Glue et AWS Glue DataBrew, gouvernées par AWS Lake Formation, puis interrogées avec Amazon Athena et Amazon Quick Sight. Il s’agit d’une architecture illustrative, pas d’un déploiement client.

Configurez les journaux d’audit avant l’usage de PHI

AWS distingue AWS CloudTrail, qui enregistre les opérations API prises en charge et certains événements non liés aux API, des journaux Amazon CloudWatch fournis par le service pour ses activités propres. Selon AWS, CloudTrail ne contient pas le corps des messages de chat ni le contenu des réponses.

AWS nomme cinq types de journaux CloudWatch : CHAT_LOGS, FEEDBACK_LOGS, AGENT_HOURS_LOGS, INDEX_USAGE_LOGS et KB_FILE_SYNC_LOGS. Les journaux de chat consignent les interactions; ceux de retours peuvent aussi contenir des PHI. Ces flux méritent donc d’être pris en compte dans les choix d’accès et de conservation avant l’arrivée de données sensibles.

La règle des six ans ne couvre pas automatiquement chaque journal brut

Le texte de 45 CFR §164.316 prévoit six ans de conservation pour les politiques et procédures écrites, ainsi que pour les traces d’actions, d’activités ou d’évaluations que la Security Rule exige de documenter. Le délai court à partir de la création du document ou de la date à laquelle il a été en vigueur pour la dernière fois, selon la date la plus tardive.

La recommandation d’AWS sur les journaux et le délai réglementaire pour la documentation visée sont deux règles de périmètre différent. La disposition citée ne fixe pas, à elle seule, une durée générale de six ans pour chaque journal brut.

Validez les contrôles avant d’élargir les usages

AWS recommande de commencer par des flux sans PHI, puis de vérifier la gouvernance, les correspondances entre identités et ACL et la journalisation avant d’élargir l’usage aux données sensibles. Ses garde-fous sont probabilistes; AWS recommande de les compléter par des contrôles déterministes, comme les politiques IAM, les ACL et les limites réseau.

AWS décrit Amazon Quick comme un service mono-région sans basculement interrégional. Une architecture de reprise peut reposer sur un déploiement distinct et des données prises en charge dans une autre région.