Introduction à la conformité sans serveur

L'informatique sans serveur a transformé la façon dont les organisations construisent et déploient des applications, offrant une évolutivité, réduisant les frais généraux d'exploitation et accélérant le marché. Toutefois, lorsque les données personnelles ou de santé sensibles sont traitées, les architectures sans serveur posent des défis uniques en matière de conformité. Deux des organismes réglementaires les plus exigeants sont la Health Insurance Portability and Accountability Act (HIPAA) aux États-Unis et le General Data Protection Regulation (RGPD) dans l'Union européenne.

Cet article fournit un guide faisant autorité pour construire des applications sans serveur conformes à HIPAA et au RGPD. Nous couvrons les fondations réglementaires, les stratégies architecturales, les normes de cryptage, les mécanismes de contrôle d'accès, l'enregistrement des audits, les exigences de résidence des données et la réponse incidente – le tout dans le contexte de services sans serveur comme AWS Lambda, Azure Functions et Google Cloud Functions.

Comprendre le paysage réglementaire

Aperçu général de l'HIPAA

La règle de confidentialité de la HIPAA définit les utilisations et les divulgations autorisées de l'ISP, tandis que la règle de sécurité prévoit des garanties administratives, physiques et techniques. Pour les applications sans serveur, les garanties techniques de la règle de sécurité – contrôle d'accès, contrôles d'audit, contrôles d'intégrité et sécurité de la transmission – sont primordiales. Tout service sans serveur qui crée, reçoit, maintient ou transmet l'ISP doit se conformer.

Aperçu du RGPD

Le RGPD est une loi globale sur la protection des données applicable à toute organisation qui traite des données à caractère personnel de personnes physiques dans l'Espace économique européen (EEE). Elle met l'accent sur des principes tels que la licéité, l'équité, la transparence, la minimisation des données, l'exactitude, la limitation du stockage, l'intégrité et la confidentialité.Les droits essentiels comprennent le droit d'accès, de rectification, d'effacement (droit à l'oubli) et la portabilité des données.

Responsabilité partagée dans les environnements sans serveur

Les fournisseurs de cloud fonctionnent selon un modèle de responsabilité partagée. Le fournisseur sécurise l'infrastructure sous-jacente (installations physiques, réseau, hyperviseur, calcul de l'exécution). Le client est responsable de la configuration, de la classification des données, de la gestion de l'identité et de l'accès (IAM), du chiffrement, du code d'application et de la conformité.

Principes de conformité clés pour les sans serveurs

Plusieurs principes s'appliquent à la fois à l'HIPAA et au RGPD:

  • – Collecte et traitement uniquement les données minimales nécessaires. Évitez de stocker des données personnelles ou PHI dans les journaux de fonctions, les messages d'erreur ou le stockage temporaire, sauf si cela est strictement nécessaire.
  • Limitation des fonctions[ – Les données de traitement uniquement pour l'objectif spécifique, explicite et légitime communiqué à la personne concernée.Les sources d'événements sans serveur (p. ex. événements S3, flux DynamoDB) doivent être configurées pour éviter une exposition non intentionnelle aux données.
  • Storage Limit – Définir l'expiration automatique sur les journaux, les fichiers temporaires dans les répertoires /tmp et les données mises en cache.
  • Intégrité et confidentialité[ – Chiffrer les données au repos et en transit, faire respecter l'accès le moins privilège et mettre en œuvre une authentification robuste.
  • Responsabilité – Maintenir des pistes de vérification de l'accès aux données et des changements au système, et documenter les décisions de conformité.

Stratégies architecturales pour des applications compatibles sans serveur

Chiffrement des données au repos et en transit

L'article 32 du RGPD prescrit également des mesures techniques appropriées, y compris le chiffrement.

  • Au repos: Utilisez des clés de chiffrement gérées (AWS KMS, Azure Key Vault, GCP Cloud KMS). Activez le chiffrement côté serveur sur tous les services de stockage (S3, RDS, DynamoDB, Cloud Storage).Pour les répertoires Lambda /tmp, envisagez de chiffrer les fichiers avant d'écrire – notez que /tmp est éphémère et non chiffré par défaut dans certains fournisseurs.
  • En transit: Appliquer TLS 1.2 ou plus pour tous les appels API, les connexions de base de données et la communication interservices. Utiliser les paramètres VPC avec IPs privés pour éviter toute traversée sur Internet public. Pour les intégrations axées sur les événements (p. ex. S3 -> Lambda), configurer les sources de notification d'événements pour utiliser HTTPS et valider les certificats.

Gestion de l'identité et de l'accès

Les fonctions sans serveur doivent fonctionner avec les autorisations minimales nécessaires. Implémenter le contrôle d'accès basé sur le rôle (RBAC) avec des politiques granulaires. Par exemple, un traitement de fonction AWS Lambda PHI devrait avoir un rôle dédié IAM qui permet seulement de lire/écrire des tables DynamoDB spécifiques et de déchiffrer en utilisant une clé KMS spécifique. N'utilisez jamais les autorisations wildcard.

  • Exiger une authentification multi-facteurs (MFA) pour tout accès administratif à l'environnement sans serveur.
  • Utilisez des identifiants de courte durée (p. ex., AWS STS, Azure Managed Identity) plutôt que des clés API de longue durée.
  • Restreindre l'exécution de fonctions à des sous-réseaux VPC spécifiques avec des ACL réseau et des groupes de sécurité qui contrôlent le trafic entrant/sortie.

Stockage et traitement sécurisés des données

Pour HIPAA, utilisez des services éligibles au BAA (par exemple, AWS DynamoDB avec chiffrement, Amazon RDS avec chiffrement, Azure SQL Database avec chiffrement transparent des données). Pour le RGPD, assurez-vous que le service stocke les données dans la région qui sont conformes aux exigences de résidence des données.

  • Évitez de stocker des données personnelles ou PHI dans des variables d'environnement de fonction. Utilisez des magasins de paramètres ou des gestionnaires de secrets avec cryptage (AWS Parameter Store, Azure App Configuration, GCP Secret Manager).
  • Utilisez des fonctions apatrides lorsque cela est possible; si l'état doit être maintenu, externalisez-le vers une datastore conforme avec des contrôles d'accès.
  • Mettre en œuvre le masquage ou la tokenisation des données pour les champs non essentiels. Par exemple, ne journaliser que les quatre derniers chiffres d'un numéro de sécurité sociale ou pseudonymeriser les données personnelles.

Vérification des sentiers et de l'exploitation forestière

Les applications HIPAA (Sécurité Rule) et GDPR (Article 30 – Enregistrements des activités de traitement) nécessitent une comptabilisation détaillée de l'accès aux données.

  • Qui a accédé aux données
  • Quand (timestamp)
  • D'où (source IP, service)
  • Quelle action (lire, écrire, supprimer)
  • Succès ou échec

Utilisez des services de logage gérés (AWS CloudTrail, Azure Monitor, GCP Cloud Audit Logs) pour enregistrer les événements de gestion (par exemple création de fonctions, modification des autorisations) et les événements de données (par exemple DynamoDB getItem). Configurez en outre la logage au niveau de l'application dans les fonctions, mais ne logez jamais les données brutes PHI ou personnelles. Utilisez la logage structurée pour respecter les politiques de conservation – définissez la rétention de log à 1 an ou selon les exigences de la réglementation, mais pas moins de 6 ans pour HIPAA. Intégrez la logage avec un SIEM pour la surveillance en temps réel.

Résidence et souveraineté des données

Le RGPD limite les transferts transfrontaliers de données vers les pays bénéficiant d'une protection adéquate. HIPAA n'interdit pas explicitement le stockage PHI en dehors des États-Unis, mais une entité couverte doit garantir l'accord d'association d'affaires (BAA) et les protections de sécurité s'étendent à l'échelle mondiale.

  • Fonctions de déploiement et stockage de données dans certaines régions (par exemple, «eu-west-1» pour les données personnelles de l'UE, «us-east-1» pour les IPP).
  • Utiliser des caractéristiques de résidence des données renforcées par le fournisseur (p. ex., la politique d'azure pour restreindre la région, les politiques de contrôle du service AWS).
  • Si les données doivent être traitées dans les régions (p. ex., reprise après sinistre), appliquer des garanties contractuelles, des accords de traitement des données et des clauses contractuelles types (CCN) en vertu du RGPD.
  • Évitez d'utiliser des paramètres globaux pour des services comme DynamoDB Global Tables à moins que vous n'ayez une base juridique explicite pour le traitement transfrontalier.

Ententes d'associés commerciaux (ABA) et ententes sur le traitement des données (ADP)

Pour se conformer à HIPAA, vous devez avoir un BAA signé avec votre fournisseur de cloud pour tous les services qui traitent PHI. Les principaux fournisseurs (AWS, Azure, GCP) offrent des BAA pour de nombreux services sans serveur. Vérifiez les services spécifiques couverts par chaque BAA – par exemple, AWS Lambda est couvert, mais certaines intégrations tierces ne le sont pas. Pour le RGPD, signez un accord de traitement des données (DPA) avec le fournisseur de cloud et tout sous-processeur. Documentez ces accords dans le cadre de votre programme de conformité.

Lignes directrices pratiques pour la mise en œuvre

Étape 1: Classification des données et cartographie des flux

Avant d'écrire le code, classifier toutes les données traitées par l'application sans serveur. Identifier les champs qui constituent PHI (sous HIPAA) ou données personnelles (sous GDPR). Carter le flux de données de l'ingestion (Pateway API, événement S3, Queues) par le traitement (fonctions Lambda, fonctions étape) au stockage (DynamoDB, RDS, S3).

Étape 2 : Configurer les services de sécurité des fournisseurs

Permettre les services de sécurité pour les fournisseurs :

  • AWS: Utilisez AWS Config pour faire respecter les règles de chiffrement, AWS GuardDuty pour la détection des menaces, et AWS Security Hub pour la posture de conformité. Activez les journaux de flux VPC et limitez les fonctions de Lambda aux sous-réseaux VPC avec une évacuation contrôlée par les passerelles NAT.
  • Azure: Utilisez la politique Azure pour faire appliquer la version TLS, activer Azure Security Center et utiliser Azure Sentinel pour SIEM. Déployez des fonctions dans un réseau virtuel VNet (Azure Virtual Network) avec des paramètres de service.
  • GCP: Utilisez les commandes de service VPC pour empêcher l'exfiltration de données, activez Cloud Armor pour la protection des API et utilisez les journaux d'audit Cloud avec conservation.

Étape 3 : Pratiques exemplaires au niveau du code

Utilisez le chiffrement variable d'environnement pour les chaînes de connexion et les clés. Évitez les secrets codés en dur – utilisez les gestionnaires de secrets. Par exemple, dans Node.js Lambda:

const { SecretsManager } = require('@aws-sdk/client-secrets-manager');
const secretsClient = new SecretsManager();
const secret = await secretsClient.getSecretValue({ SecretId: process.env.SECRET_ARN });

Assurez-vous que le traitement des erreurs ne fuit pas les données sensibles dans les journaux ou les messages de réponse.

Étape 4 : Surveillance continue et intervention en cas d'incident

Pour HIPAA, tenir un plan de réponse aux incidents documenté qui comprend des procédures de notification des manquements. Pour le RGPD, assurer la capacité d'aviser l'autorité de surveillance dans les 72 heures. Les fonctions sans serveur peuvent être intégrées avec les workflows de réponse aux incidents en utilisant des services tels que les fonctions AWS Step, Azure Logic Apps ou GCP Workflows pour orchestrer le confinement et l'investigation.

Pièges courants et comment les éviter

  • Rôles IAM trop permissives:[ Une facturation statique des permissions de fonction conduit à l'exposition aux données. Utilisez le moins de privilèges et examinez les permissions après chaque déploiement.
  • Ignorer les dépendances de tiers:[ Les applications sans serveur utilisent souvent des bibliothèques externes ou des produits SaaS. Assurez-vous que chaque composant a un BAA/DPA et est conforme.
  • Conservation de la documentation insuffisante : Les journaux supprimés automatiquement après 7 jours peuvent violer l'exigence de conservation de 6 ans de HIPAA. Configurer les politiques de conservation de la documentation et envisager l'archivage à un stockage à faible coût.
  • Si l'on suppose que VPC isole complètement le trafic:[ Les fonctions de Lambda dans un VPC peuvent encore atteindre Internet par une passerelle NAT si elle est autorisée, ce qui peut exposer les données en transit.
  • Ne pas traiter les droits de la personne concernée:[ Pour le RGPD, vous devez pouvoir supprimer ou exporter les données d'un utilisateur sur demande. Les systèmes sans serveur devraient avoir des fonctions qui, avec un identifiant utilisateur, peuvent localiser et effacer tous les enregistrements dans les bases de données, caches et sauvegardes.

Étude de cas : pipeline de données sur la santé sans serveur

Considérez une application sans serveur qui ingère les dossiers médicaux d'un portail fournisseur, les traite pour l'analyse et stocke les résultats. L'architecture utilise AWS API Gateway, Lambda, DynamoDB et S3.

  1. BAA signé avec AWS couvrant tous les services utilisés.
  2. Tout stockage (DynamoDB, S3) utilise un cryptage géré par KMS avec une clé dédiée.
  3. Les rôles Lambda sont strictement liés aux tables DynamoDB et à la clé KMS requises.
  4. API Gateway utilise TLS 1.2 et nécessite l'authentification IAM.
  5. Toutes les fonctions sont déployées dans un VPC sans accès Internet sortant – seuls les paramètres privés de DynamoDB et S3.
  6. CloudTrail et DynamoDB sont activés pour les journaux de vérification, conservés pendant 6 ans dans S3 avec verrouillage d'objets.
  7. Une fonction Lambda distincte implémente le droit à l'effacement : elle scanne DynamoDB, supprime les enregistrements de l'utilisateur et envoie une confirmation.

Cette conception répond aux exigences de la règle de sécurité de l'HIPAA et aux obligations en matière de droits et de responsabilité du RGPD.

Ressources externes pour une compréhension plus approfondie

Conclusion

En appliquant le chiffrement, l'accès le moins privilégié, les pistes d'audit, les contrôles de résidence des données et les accords juridiques appropriés, les organisations peuvent construire des systèmes sans serveur qui protègent les données sensibles tout en respectant les normes réglementaires les plus élevées. La flexibilité et l'évolutivité des services sans serveur ne doivent pas être incompatibles avec la conformité; avec les stratégies décrites ici, vous pouvez atteindre la sécurité et l'innovation. N'oubliez pas de traiter la conformité comme un processus continu – réévaluer votre environnement sans serveur avec chaque nouvelle fonctionnalité de service ou mise à jour réglementaire.