Table of Contents

Présentation

L'informatique sans serveur est devenue un paradigme dominant pour la construction et le déploiement d'applications cloud-native. En abstractionnant la gestion des infrastructures, les plateformes sans serveur telles que AWS Lambda, Azure Functions et Google Cloud Functions permettent aux équipes de se concentrer sur le code plutôt que sur les serveurs. Cependant, pour les organisations opérant dans les secteurs réglementés – soins de santé, finances, assurances, produits pharmaceutiques et gouvernement – le passage à l'architecture sans serveur pose des défis de conformité uniques.

Exigences fondamentales en matière de conformité

Avant d'élaborer une solution sans serveur, les organisations doivent identifier les réglementations spécifiques qui s'appliquent à leurs données et à leurs opérations.Chaque norme définit son propre ensemble de contrôles, mais les thèmes communs incluent le chiffrement, la gestion des accès, l'enregistrement, la minimisation des données et la notification des manquements.

HIPAA pour les soins de santé

Les applications sans serveur qui stockent, traitent ou transmettent l'ISPA doivent respecter la règle de sécurité HIPAA, qui exige des garanties administratives, physiques et techniques. Les contrôles techniques clés comprennent le chiffrement de l'ISPA au repos et en transit, l'identification unique des utilisateurs, la déconnection automatique et les contrôles d'audit. Les fournisseurs de cloud comme AWS offrent des addenda d'associés commerciaux (BAA) pour leurs services admissibles à l'IPAA, mais les clients doivent encore configurer des services pour répondre aux normes HIPAA. Les fonctions sans serveur ne doivent pas enregistrer l'ISPA dans des journaux en texte clair, et toutes les données doivent traverser des canaux chiffrés (TLS 1.2+).

PCI DSS pour les données de carte de paiement

La norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS) s'applique à toute organisation qui stocke, traite ou transmet des données de détenteur de carte.Les fonctions sans serveur qui interagissent avec les passerelles de paiement ou qui traitent les numéros de compte primaires (PAN) doivent satisfaire aux exigences de segmentation du réseau, de contrôle d'accès, de chiffrement et de test régulier.

RGPD pour la protection des données

Le règlement général sur la protection des données (RGPD) s'applique à toute organisation qui traite des données personnelles des résidents de l'UE, quel que soit le lieu où l'organisation est basée. Le RGPD met l'accent sur les droits des personnes concernées (accès, rectification, effacement), la protection des données par la conception et par défaut, et la notification de violation dans les 72 heures. Les architectures sans serveur doivent prendre en charge les demandes de portabilité et de suppression des données, ce qui peut être difficile lorsque les données sont réparties entre les fonctions, les files d'attente et les magasins d'objets.

FedRAMP et autres normes gouvernementales

Pour les charges de travail du gouvernement fédéral américain, le Programme fédéral de gestion des risques et des autorisations (FedRAMP) offre une approche normalisée de l'évaluation de la sécurité, de l'autorisation et de la surveillance continue.Les services sans serveur doivent être déployés dans des environnements nuageux autorisés par FedRAMP (p. ex., AWS GovCloud, Azure Government).

Le modèle de responsabilité partagée sans serveur

L'un des concepts les plus critiques pour la conformité en sans serveur est le modèle de responsabilité partagée . Les fournisseurs de cloud sécurisent l'infrastructure sous-jacente – hyperviseurs, réseau, centres de données physiques – tandis que les clients sont responsables de la sécurisation de leurs données, codes, configurations d'identité et contrôles de niveau d'application.

Responsabilités des fournisseurs de services en nuage

Le fournisseur de cloud est responsable de la sécurité de l'exécution sans serveur, y compris l'isolement entre locataires, le patchage de l'environnement d'exécution, et la protection des paramètres API qui déclenchent les fonctions. Les fournisseurs gèrent également l'infrastructure de calcul sous-jacente et veillent à ce que le stockage éphémère (par exemple /tmp dans AWS Lambda) soit nettoyé en toute sécurité entre les exécutions.

Responsabilités des clients

Les clients doivent s'assurer que leur code d'application sans serveur n'introduise pas de vulnérabilités, que les données sont chiffrées et que l'accès est contrôlé, et que toutes les sources d'événements (comme les seaux S3, les flux de Kinesis ou les paramètres HTTP) sont configurées en toute sécurité.

  • Les rôles et les politiques de l'IAM qui accordent le moins de privilèges à chaque fonction.
  • Chiffrement des variables d'environnement à l'aide de KMS ou d'autres variables similaires.
  • Gestion sécurisée des secrets à l'aide d'un service de coffre (AWS Secrets Manager, Azure Key Vault).
  • Validation de tous les intrants pour protéger contre les crises d'injection.
  • Enregistrement et surveillance complets (CloudWatch, Azure Monitor) avec des contrôles de conservation et d'accès appropriés.

L'incapacité de configurer l'un de ces éléments peut conduire à une exposition aux données et à une non-conformité, même si l'infrastructure du fournisseur est certifiée.

Pratiques de sécurité fondamentales pour la conformité

La sécurité est le fondement de la conformité. Les pratiques suivantes ne sont pas négociables lors du déploiement d'applications sans serveur dans des environnements réglementés.

Chiffrement partout

Toutes les données sensibles doivent être chiffrées au repos et en transit.

  • Chiffrement des données stockées dans les magasins d'objets (S3, Azure Blob, GCS) à l'aide de clés AES-256 ou gérées par le client.
  • Cryptage des données en transit entre les fonctions, les bases de données et les services externes utilisant la norme TLS 1.2 ou plus.
  • Chiffrer les variables d'environnement, la configuration de la fonction et toutes les données mises en cache.
  • Utilisation du chiffrement de l'enveloppe où les clés sont pivotées périodiquement.

Les règlements comme HIPAA et PCI DSS exigent explicitement le chiffrement comme une sauvegarde. De nombreux fournisseurs de cloud intègrent le chiffrement de manière transparente, mais les clients doivent activer et valider ces paramètres.

Gestion de l'identité et de l'accès (IAM)

Les fonctions sans serveur fonctionnent avec des rôles d'exécution spécifiques. L'octroi de permissions excessives – comme une fonction qui nécessite seulement un accès en lecture à un seau S3 mais qui est donné un accès complet à l'administrateur – crée des risques de conformité et de sécurité. Adoptez le principe du moins de privilèges pour chaque fonction. Utilisez des rôles de service qui sont couverts par des ressources et des actions spécifiques.

Sécurité du réseau

Pour les charges de travail réglementées, les fonctions doivent être déployées à l'intérieur d'un VPC avec des groupes de sécurité qui ne permettent que le trafic nécessaire. Utilisez AWS PrivateLink, Azure Private Endpoint ou GCP Private Service Connect[ pour accéder aux bases de données et aux services sans traverser l'internet public. API Gateway peut être configuré avec WAF (Web Application Firewall) pour bloquer les attaques communes et imposer des limites de vitesse. La segmentation du réseau aide à réduire le rayon de bouffée et simplifie la conformité aux contrôles de sécurité du réseau.

Gestion des secrets

Les secrets de codage rigide (mots de passe de base de données, clés API, clés de chiffrement) dans les variables de code ou d'environnement sont une violation de conformité courante. Utilisez un gestionnaire de secrets dédié: AWS Secrets Manager, Azure Key Vault, ou HashiCorp Vault. Récupérez des secrets à l'exécution via des appels SDK sécurisés. Assurez-vous que la rotation secrète est automatisée et que l'accès aux secrets est enregistré et vérifié.

Réalisation de la vérification dans les architectures sans serveur

La plupart des règlements exigent des pistes de vérification détaillées qui saisissent qui a fait quoi, quand et d'où. Les environnements sans serveur peuvent être éphémères, rendant l'enregistrement et la vérification encore plus critiques.

Exploitation forestière centralisée

Aggregate logs from all functions, event sources, and API calls into a centralized platform (p. ex., Amazon CloudWatch Logs, Azure Log Analytics, Google Cloud Log Logging). Assurez-vous que les logs sont immuables et inviolables – utilisez des politiques de groupe de log qui empêchent leur suppression ou leur modification. Pour PCI et HIPAA, les périodes de conservation des logs sont généralement obligatoires (souvent de 1 à 3 ans). Activer CloudTrail[ ou Log d'activité d'Azure[ pour saisir l'activité utilisateur et les appels d'API.

Trails de vérification immuables

Pour éviter toute manipulation de log, écrivez des journaux dans le stockage qui est write-once-read-many (WORM). Les services comme AWS S3 avec Object Lock en mode de conformité, Azure Storage avec des politiques de blob immuables, ou GCP Object holds peuvent imposer la rétention. Combinez ceci avec le streaming en temps réel vers un SIEM (par exemple, Spunk, Sumo Logic) pour alerter.

Surveillance et alerte en temps réel

La conformité n'est pas un événement ponctuel. Configurez des alarmes de surveillance pour les comportements anormaux : invocations inattendues, pics dans les taux d'erreur, tentatives d'accès à des ressources restreintes ou tentatives d'authentification ratées. Utilisez AWS Security Hub, Azure Security Center ou Google Cloud Security Command Center pour agréger les résultats. Intégrez les flux de travail de réponse aux incidents. Par exemple, si une fonction essaie soudainement de lire une table de base de données sensible en dehors de son champ d'application, une alerte devrait déclencher une enquête automatisée.

Choix de la conformité - Outils et services amis

Les grands fournisseurs de services en nuage offrent une série de services conçus pour aider les clients à maintenir leur conformité.

AWS Config et règles de conformité

Vous pouvez définir Règles de confiance qui vérifient automatiquement les ressources par rapport aux états de conformité souhaités – par exemple, s'assurer que les fonctions de Lambda ont activés ou que les seaux S3 ne sont pas accessibles au public. Lorsqu'une violation survient, AWS Config peut déclencher une réparation automatique via l'automatisation du gestionnaire de systèmes. Ces règles peuvent être cartographiées sur des contrôles spécifiques dans des cadres comme CIS Benchmarks, PCI DSS et HIPAA. Combinés avec CloudTrail et Security Hub, AWS Config fournit un tableau de bord de conformité robuste.

Politique d'azur et plans directeurs

Pour les charges de travail sans serveur, vous pouvez appliquer des politiques telles que -Les applications -Function doivent utiliser l'identité gérée - ou -Les paramètres d'application doivent être chiffrés. - Les plans d'utilisation d'Azure peuvent déployer un environnement entièrement prêt à la conformité avec des politiques préconfigurées, des attributions de rôles et des modèles de ressources.

Google Cloud , charges de travail assurées

Google Cloud , HIPAA et la résidence de données. Pour les fonctions Cloud, vous pouvez déployer dans un dossier de Workloads Assurés qui limite l'utilisation des services, les options de cryptage et l'emplacement des données. Google offre également Sécurity Command Center pour la numérisation de vulnérabilité et la surveillance de la conformité. Ces outils réduisent le fardeau de la configuration manuelle et fournissent des pistes d'audit claires.

Vérifications de conformité automatique

Les contrôles manuels de conformité sont sujets à des erreurs, prennent du temps et ne peuvent pas suivre le rythme des déploiements rapides sans serveur. L'automatisation est essentielle pour une conformité continue.

Infrastructure comme code (IaC) avec balayage de conformité

Définir des ressources sans serveur à l'aide d'outils IaC comme AWS CloudFormation, Terraform, AWS CDK, Azure Bicep ou Google Deployment Manager. Intégrer des règles de conformité dans le pipeline IaC à l'aide d'outils comme Checkov, tfsec, ou Cloud Custodian[. Ces outils analysent des modèles pour détecter les erreurs de configuration avant le déploiement. Par exemple, ils peuvent signaler une fonction Lambda sans configuration VPC ou une table DynamoDB sans chiffrement. En saisissant des problèmes dans CI/CD, vous empêchez la création de ressources non conformes.

Portes de conformité des pipelines CI/CD

Une fois qu'une nouvelle version d'une fonction sans serveur est construite, exécutez une analyse statique (SAST) sur le code, la numérisation de dépendance (SCA) pour les vulnérabilités connues et les tests dynamiques (DAST) si les paramètres sont exposés. Utilisez des outils comme Snyk, SonarQube ou Bridgepuck. Ne promouvoir le code à la production que si toutes les vérifications de conformité passent.

Déclaration automatisée de conformité

Remplacer la génération manuelle de rapports par des pipelines automatisés qui recueillent des preuves à partir de journaux, de configurations et de dossiers de déploiement. Des services comme AWS Audit Manager[ ou Azure Compliance Manager peuvent évaluer en permanence les contrôles et produire des rapports à la demande pour les auditeurs.

Résidence et souveraineté des données

Dans les architectures sans serveur, les données peuvent se déplacer dans les régions par le biais de sources d'événements, de files d'attente ou de réplication de stockage. Les organisations doivent contrôler où les données sont stockées et traitées.

Déploiements régionaux

Utiliser Politiques organisationnelles (GCP) ou Politiques de contrôle des services[ (AWS) pour limiter la création de ressources aux régions autorisées. Pour les architectures axées sur les événements, assurez-vous que les sources d'événements (comme Kinesis ou EventBridge) résident également dans la région prévue. Soyez prudent de la réplication trans-régionale pour les sauvegardes—utiliser Lire les réplica[ seulement si votre politique le permet.

Classification et traitement des données

Utilisez des balises ou des métadonnées pour indiquer la sensibilité des données et des fonctions sans serveur se comportent différemment selon la classification. Par exemple, un traitement de fonction PII devrait toujours se connecter à un groupe de log dédié et chiffré avec un accès limité et ne jamais écrire de données dans une région non conforme. Des outils de classification automatisés comme Amazon Macie (pour S3) ou Azure Purview[ peuvent scanner des magasins de données pour découvrir et classer des données sensibles.

Gestion des risques des fournisseurs et des tiers

Les applications sans serveur dépendent souvent de dépendances tierces – bibliothèques, API SaaS et services gérés. Chaque dépendance introduit des risques de conformité qui doivent être évalués et gérés.

Diligence raisonnable sur les fournisseurs de cloud

Votre fournisseur de cloud doit offrir des certifications de conformité pertinentes pour votre industrie. Vérifiez que votre fournisseur choisi possède les certifications SOC 2 Type II, ISO 27001, PCI DSS Niveau 1, FedRAMP ou HITRUST. Passez en revue leur Matrice de responsabilité partagée pour comprendre quels contrôles sont hérités. Pour plus d'assurance, envisagez d'utiliser une plateforme de gestion de la conformité qui suit les attestations de fournisseur (p. ex. Whistler, JupiterOne).

Risque de bibliothèque et de service de tiers

Pour les environnements réglementés, préférez les bibliothèques ayant une provenance connue et maintenez une liste approuvée de licences. Les API SaaS doivent être évaluées à l'aide d'évaluations des risques des fournisseurs – examiner leurs procédures de traitement des données, de certification et de réponse aux manquements. Si un service tiers traite des données sensibles, assurez-vous qu'ils sont prêts à signer un DPA ou un BAA au besoin.

Surveillance continue de la conformité des fournisseurs

La conformité n'est pas statique. Configurez des alertes automatisées pour les changements dans les certifications des fournisseurs (p. ex., si un fournisseur perd une attestation PCI DSS). Des services comme ]OneTrust Vendorpedia[ ou Bitsight[ peuvent surveiller la posture de tiers.

Intervention en cas d'incident et reprise après sinistre

Les règlements exigent que les organisations disposent d'un plan d'intervention en cas d'incident documenté et qu'elles soient en mesure de se remettre des catastrophes tout en préservant les preuves et l'intégrité.

Playbooks de réponse aux incidents spécifiques sans serveur

Créer des livres de lecture qui isolent immédiatement une fonction compromise (p. ex., révoquer son rôle de MAI, détacher les déclencheurs) et préserver les journaux avant qu'ils ne soient écrasés. Utiliser AWS GuardDuty[ ou Azure Sentinel[ pour détecter le comportement de la fonction anormale. Veiller à ce que les équipes de réponse incidente aient accès aux journaux vivants en quelques minutes.

Stratégies de sauvegarde et de restauration

Les architectures sans serveur utilisent souvent des services de base de données gérés (DynamoDB, Cosmos DB, Firestore). Assurez-vous que ces services ont une récupération ponctuelle (PITR) activée avec une conservation qui répond aux exigences de conformité. Pour les données d'événements, utilisez des files d'attente rejouables (archives SQS, EventBridge) pour retraiter les événements après une panne.

État de préparation de la notification de violation

Le RGPD et de nombreuses lois d'État exigent la notification des infractions dans les 72 heures. Préparer un modèle de notification et automatiser la collecte de données médico-légales. Utilisez des fonctions sans serveur pour recueillir des preuves de journaux, des instantanés de configuration et des historiques d'identité immédiatement après la détection.

Conclusion : Construire un programme de conformité pour les sans-serveur

Le modèle de responsabilité partagée exige que vous sécurisez votre couche d'application, même lorsque le fournisseur de cloud assure la sécurité de l'exécution. Les pratiques de base comme le chiffrement, le moins privilège IAM, la segmentation du réseau et la gestion des secrets forment la fondation. L'audit exige une exploitation exhaustive, un stockage immuable et une surveillance en temps réel appuyée par des outils axés sur la conformité tels que AWS Config, Azure Policy et Google Cloud Assured Workloads. L'automatisation – grâce à la numérisation IaC, les portes CI/CD et les rapports automatisés – réduit les erreurs humaines et accélère la collecte de données pour les vérificateurs. Enfin, la gestion des risques des fournisseurs, les contrôles de résidence des données et la préparation aux interventions en cas d'incident garantissent que votre infrastructure sans serveur peut résister à la fois à l'examen réglementaire et aux menaces réelles.

En intégrant la conformité à toutes les étapes du cycle de vie sans serveur – conception, déploiement, fonctionnement et déclassement – les organisations réglementées peuvent en toute confiance tirer parti de l'agilité, de l'évolutivité et des économies de coûts qu'offre sans serveur. La clé est de traiter la conformité non pas comme une contrainte mais comme un principe de conception qui améliore la posture de sécurité et l'excellence opérationnelle.