Aller au contenu

Sécurité sans serveur Meilleures pratiques : Guide complet pour les technologies Cloud

Le 18 juillet 2025: Temps de lecture: 13 minutes 37 secondes

*Master sécurité sans serveur avec ce guide complet conçu pour les ingénieurs DevOps et les professionnels du cloud. Des principes fondamentaux de sécurité aux techniques avancées d'atténuation des menaces, ce guide technique détaillé fournit les connaissances essentielles et les stratégies pratiques nécessaires pour sécuriser les applications sans serveur sur les plateformes AWS, Azure et Google Cloud. *

Introduction: L'importance critique de la sécurité sans serveur

L'informatique sans serveur a révolutionné le développement d'applications modernes en éliminant les frais généraux de gestion des serveurs et en permettant une évolutivité et une rentabilité sans précédent. Toutefois, ce changement de paradigme introduit des défis uniques en matière de sécurité qui exigent des connaissances et des approches spécialisées. Alors que les fournisseurs de cloud gèrent la sécurité de l'infrastructure, les vulnérabilités au niveau de l'application restent la responsabilité des développeurs et des équipes DevOps, rendant les pratiques de sécurité globales plus critiques que jamais.

Le paysage de sécurité sans serveur diffère considérablement des modèles traditionnels de sécurité des applications. La nature éphémère des fonctions sans serveur, les modèles de responsabilité partagée et les architectures axées sur les événements créent de nouveaux vecteurs d'attaque et des considérations de sécurité. Les applications modernes sans serveur s'intègrent souvent à de multiples services cloud, traitent les données sensibles à travers les systèmes distribués et fonctionnent dans des environnements multi-tenus, amplifiant l'impact potentiel des vulnérabilités de sécurité.

Ce guide complet aborde les défis les plus critiques en matière de sécurité sans serveur auxquels les organisations sont confrontées aujourd'hui, en fournissant des stratégies pratiques et des techniques de mise en œuvre pour sécuriser les applications sans serveur sur les grandes plateformes cloud. La compréhension et la mise en œuvre de ces meilleures pratiques de sécurité sont essentielles pour maintenir des architectures robustes, conformes et résistantes sans serveur dans les environnements de production.

Principes fondamentaux de sécurité sans serveur

Comprendre le modèle de responsabilité partagée

Le modèle de responsabilité partagée sans serveur modifie fondamentalement la façon dont les organisations abordent la sécurité. Les fournisseurs de cloud comme AWS, Microsoft Azure et Google Cloud Platform gèrent la sécurité de l'infrastructure, y compris la sécurité physique, les contrôles réseau, le patching du système d'exploitation hôte et la sécurité hyperviseur. Cependant, les clients restent responsables de la sécurité au niveau de l'application, y compris la sécurité du code, la protection des données, la gestion de l'identité et de l'accès, et la sécurité de la configuration.

Cette division des responsabilités oblige les organisations à élaborer de nouvelles stratégies de sécurité axées sur les protections des couches d'application tout en tirant parti des capacités de sécurité des fournisseurs de services de cloud. Il est essentiel de comprendre exactement les limites des responsabilités pour élaborer des programmes de sécurité efficaces. Par exemple, alors qu'AWS gère l'environnement d'exécution Lambda sous-jacent, les clients doivent sécuriser leur code de fonction, gérer les autorisations IAM et protéger les données sensibles dans leurs applications.

Le modèle de responsabilité partagée s'étend également aux exigences de conformité. Les organisations doivent s'assurer que leurs applications sans serveur répondent aux normes réglementaires comme SOC 2, PCI DSS, HIPAA et GDPR, même si elles ne contrôlent pas l'infrastructure sous-jacente. Pour cela, il faut mettre en place des contrôles appropriés au niveau de l'application et comprendre comment les caractéristiques de sécurité des fournisseurs de cloud soutiennent les objectifs de conformité.

Architecture de confiance zéro pour sans serveur

La mise en œuvre de principes de confiance zéro dans des environnements sans serveur nécessite de traiter chaque invocation de fonction comme potentiellement méfiante, quelle que soit sa source. Cette approche suppose que les menaces peuvent provenir de n'importe où, y compris les systèmes internes compromis, les initiés malveillants ou les attaquants externes qui ont accès aux réseaux internes. Zero confiance architectures sans serveur implémentent la vérification continue, l'accès le moins privilégié, et la surveillance complète à chaque point d'interaction.

Les implémentations sans serveur de confiance zéro comprennent généralement une authentification et une autorisation solides pour chaque invocation de fonction, le chiffrement de toutes les données en transit et au repos, l'enregistrement et le suivi complets de toutes les activités, et l'application dynamique des politiques fondées sur le contexte et l'évaluation des risques. Ces principes doivent être appliqués de manière cohérente à toutes les fonctions sans serveur, indépendamment de leur sensibilité perçue ou de leur exposition interne ou externe.

La nature apatride des fonctions sans serveur soutient effectivement les principes de confiance zéro en éliminant les connexions persistantes et en exigeant une authentification explicite pour chaque invocation. Toutefois, cela signifie également que les contrôles de sécurité traditionnels basés sur le réseau sont moins efficaces, obligeant les organisations à mettre en place des contrôles de sécurité aux niveaux des applications et des données.

Stratégie de défense en profondeur

La sécurité sans serveur nécessite la mise en place de multiples couches de contrôles de sécurité pour protéger contre divers vecteurs d'attaque. Une stratégie globale de défense en profondeur comprend la sécurité du périmètre par des passerelles API et des pare-feu d'application Web, la sécurité des applications par des pratiques de codage sécurisées et la validation des entrées, la sécurité des données par le cryptage et les contrôles d'accès, et la sécurité opérationnelle par des capacités de surveillance et d'intervention en cas d'incident.

Chaque couche de sécurité sert un objectif précis et offre une protection contre différents types de menaces. Les passerelles API fournissent la première ligne de défense en filtrant les requêtes malveillantes et en limitant le taux d'exécution. Les contrôles au niveau de l'application protègent contre les attaques par injection et les vulnérabilités de la logique commerciale. Le cryptage des données protège les informations sensibles même si d'autres contrôles échouent. La surveillance et l'exploitation forestière donnent une visibilité aux incidents de sécurité potentiels et appuient l'analyse médico-légale.

La nature éphémère des fonctions sans serveur nécessite une attention particulière dans les stratégies de défense en profondeur. Les contrôles de sécurité traditionnels basés sur l'hôte ne s'appliquent pas, de sorte que les organisations doivent compter davantage sur les contrôles au niveau des applications et les services de sécurité cloud-native. Cela inclut la mise à profit des services de sécurité des fournisseurs de cloud comme AWS GuardDuty, Azure Security Center et Google Cloud Security Command Center pour la détection et la réponse aux menaces.

Sécurité de la gestion de l'identité et de l'accès

Mise en œuvre de l'accès le moins privilégié

Le principe du moindre privilège est fondamental pour la sécurité sans serveur, exigeant que chaque fonction ne reçoive que les autorisations minimales nécessaires à l'exécution des opérations prévues. Cette approche réduit considérablement l'impact potentiel des atteintes à la sécurité en limitant l'accès des attaquants s'ils compromettent une fonction. La mise en oeuvre du moins de privilèges dans les environnements sans serveur nécessite une analyse minutieuse des exigences de chaque fonction et un examen régulier des autorisations pour s'assurer qu'elles demeurent appropriées.

La mise en oeuvre effective des privilèges les moins importants commence par comprendre exactement les ressources dont chaque fonction a besoin pour accéder aux ressources et les opérations qu'elle doit effectuer. Cela comprend l'identification de bases de données spécifiques, de seaux de stockage, d'API externes et d'autres services cloud avec lesquels la fonction interagit. Plutôt que d'accorder des autorisations générales, les organisations devraient élaborer des politiques précises qui ne permettent l'accès qu'aux ressources nécessaires et aux opérations nécessaires.

La vérification régulière de l'autorisation est essentielle pour maintenir l'accès le moins privilégié au fil du temps. À mesure que les demandes évoluent et que les exigences changent, les autorisations qui étaient autrefois nécessaires peuvent devenir excessives. Les outils automatisés peuvent aider à identifier les autorisations inutilisées et les politiques trop générales, ce qui permet aux organisations d'affiner continuellement leurs contrôles d'accès. De nombreux fournisseurs de cloud offrent des outils d'analyse d'accès qui peuvent identifier les risques potentiels de sécurité dans les configurations IAM.

Fonctions spécifiques IAM Rôles

La création de rôles IAM dédiés pour chaque fonction sans serveur ou groupe de fonctions étroitement lié permet un contrôle granulaire des autorisations et améliore la posture de sécurité. Cette approche empêche les fonctions d'accéder aux ressources dont elles n'ont pas besoin et facilite le suivi et l'audit des modèles d'accès. Les rôles spécifiques à la fonction simplifient également le dépannage et réduisent le risque d'attaques à l'escalade des privilèges.

Lors de la conception des rôles propres à une fonction, les organisations devraient tenir compte de l'objectif de la fonction, des données qu'elle traite et des services externes avec lesquels elle interagit. Par exemple, une fonction qui traite les données de paiement devrait avoir des permissions différentes de celles qui génèrent des rapports. Même les fonctions d'une même application peuvent nécessiter des niveaux d'accès différents en fonction de leurs responsabilités spécifiques.

Les rôles propres à chaque fonction favorisent également de meilleures capacités de surveillance et de vérification. Lorsque chaque fonction a son propre rôle, les équipes de sécurité peuvent plus facilement suivre quelles fonctions accèdent aux ressources et identifier les schémas d'accès inhabituels qui pourraient indiquer un incident de sécurité. Cette visibilité granulaire est essentielle pour une surveillance de sécurité efficace et une réponse incidente dans des environnements sans serveur.

Contrôles d'accès intercomptes et interservices

De nombreuses applications sans serveur couvrent plusieurs comptes AWS, abonnements Azure ou projets Google Cloud, nécessitant une gestion soigneuse des contrôles d'accès intercomptes. Ces scénarios introduisent des facteurs de complexité et de sécurité supplémentaires, car les organisations doivent concilier les besoins opérationnels et les pratiques exemplaires en matière de sécurité. Des contrôles d'accès croisés appropriés empêchent l'accès non autorisé tout en permettant des opérations commerciales légitimes.

L'accès aux comptes croisés devrait être mis en œuvre au moyen de pouvoirs temporaires et assumer des mécanismes de rôle plutôt que des clés d'accès à long terme. Cette approche offre une meilleure sécurité en limitant la durée de vie des références et en permettant un contrôle plus granulaire des autorisations d'accès. Les organisations devraient également mettre en place de solides exigences d'authentification pour l'accès aux comptes croisés, y compris l'authentification multifacteurs dans la mesure du possible.

Un examen régulier des autorisations d'accès aux comptes croisés est essentiel au maintien de la sécurité au fil du temps. À mesure que les relations d'affaires changent et que les applications évoluent, les exigences en matière d'accès aux comptes croisés peuvent également changer. Les organisations devraient mettre en place des processus pour examiner et mettre à jour régulièrement les autorisations réciproques afin de s'assurer qu'elles demeurent appropriées et nécessaires.

Secrets et gestion de la configuration

Secure Secrets Stockage et récupération

Entreposer des secrets directement dans le code de fonction ou les variables d'environnement représente l'une des erreurs de sécurité les plus courantes et les plus dangereuses sans serveur. Les secrets, y compris les clés API, les mots de passe de base de données, les clés de chiffrement et les identifiants de service tiers, doivent être stockés dans des services de gestion des secrets dédiés et récupérés en toute sécurité à l'exécution. Cette approche protège les secrets de l'exposition dans les dépôts de code, les artefacts de déploiement et les configurations de fonction.

Les plateformes cloud modernes offrent des services robustes de gestion des secrets spécialement conçus pour les applications sans serveur. AWS Secrets Manager et Systems Manager Parameter Store, Azure Key Vault et Google Secret Manager offrent des contrôles de stockage sécurisés, de rotation automatique et d'accès aux informations sensibles. Ces services s'intègrent parfaitement aux fonctions sans serveur et fournissent des pistes d'audit pour un accès secret.

La mise en œuvre de la recherche de secrets sécurisés nécessite un examen attentif des performances et des compromis en matière de sécurité. La récupération de secrets sur chaque invocation de fonction fournit la plus haute sécurité, mais peut avoir une incidence sur la performance et augmenter les coûts. Cacher des secrets en mémoire pendant l'exécution des fonctions améliore les performances, mais nécessite une gestion soigneuse de la rotation secrète et l'invalidation du cache. Les organisations devraient mettre en œuvre des stratégies de mise en cache appropriées en fonction de leurs besoins en matière de sécurité et de rendement.

Sécurité variable de l'environnement

Bien que les variables d'environnement ne devraient pas stocker des secrets sensibles, elles jouent un rôle important dans la gestion de la configuration sans serveur et exigent des considérations de sécurité appropriées. Les variables d'environnement contiennent souvent des informations de configuration qui, bien qu'elles ne soient pas directement sensibles, pourraient fournir des informations précieuses aux attaquants ou permettre une escalade des privilèges en cas de compromis. La bonne gestion des variables environnementales comprend la validation, l'assainissement et la surveillance.

La validation des variables d'environnement garantit que les valeurs de configuration répondent aux formats et aux contraintes attendus avant que les fonctions ne commencent à être traitées. Cela empêche les attaques basées sur la configuration et aide à identifier les problèmes de sécurité potentiels au début du processus de déploiement. La validation devrait comprendre la vérification des types de données, des plages de valeurs et des exigences de format pour tous les paramètres de configuration.

Les organisations devraient mettre en place une surveillance des changements et des modes d'accès variables. Des changements imprévus aux variables d'environnement pourraient indiquer un incident de sécurité ou une dérive de configuration qui pourrait avoir une incidence sur la sécurité. La surveillance automatisée peut alerter les équipes de sécurité sur les problèmes potentiels et appuyer les efforts d'intervention en cas d'incident.

Prévention de la dérive de configuration

La dérive de configuration dans les environnements sans serveur peut introduire des vulnérabilités de sécurité lorsque les fonctions s'écartent de leurs configurations de sécurité prévues au fil du temps. Cette dérive peut se produire par des changements manuels, des déploiements automatisés avec des configurations incorrectes ou une accumulation progressive de modifications de configuration qui n'ont pas été correctement examinées. La prévention de la dérive de configuration nécessite la mise en place d'une infrastructure comme pratiques de code et de surveillance continue.

L'infrastructure en tant qu'outils de code comme les modèles AWS CloudFormation, Azure Resource Manager et Google Cloud Deployment Manager permet aux organisations de définir et de maintenir des configurations cohérentes pour toutes les fonctions sans serveur. Ces outils permettent de contrôler les versions, de suivre les changements et de déployer des capacités automatisées qui aident à prévenir les changements de configuration non autorisés ou imprévus.

La surveillance continue de la configuration compare les configurations réelles des fonctions aux niveaux de référence approuvés et alerte les équipes à tout écart. Cette surveillance devrait inclure les permissions IAM, les configurations réseau, les variables d'environnement et d'autres paramètres liés à la sécurité. L'assainissement automatisé peut aider à rétablir rapidement les configurations appropriées lorsque la dérive est détectée.

Validation des entrées et prévention des attaques par injection

Sanitation globale des intrants

La validation d'entrée représente la première ligne de défense contre les attaques d'injection dans les applications sans serveur. Chaque élément de données entrant dans une fonction sans serveur, qu'il s'agisse de requêtes API, de déclencheurs d'événements ou d'intégrations externes, doit être soigneusement validé et nettoyé avant le traitement. Cela comprend non seulement les entrées directes de l'utilisateur, mais aussi les données provenant de sources fiables, car ces sources peuvent elles-mêmes être compromises ou contenir du contenu malveillant.

La validation efficace des entrées implémente les approches de la liste blanche et de la liste noire, la validation de la liste blanche étant préférée pour les applications critiques en matière de sécurité. La validation de la liste blanche définit exactement quels formats et valeurs d'entrée sont acceptables, rejetant tout le reste. Cette approche est plus sûre que la validation de la liste noire, qui tente d'identifier et de bloquer les entrées malveillantes, mais peut manquer de nouveaux vecteurs d'attaque ou de vecteurs inconnus.

La validation des entrées doit se faire à plusieurs niveaux dans les applications sans serveur. Les passerelles API peuvent fournir la validation initiale des formats de requête et la vérification des paramètres de base. La validation au niveau de l'application devrait mettre en œuvre des contraintes de logique opérationnelle et une vérification détaillée du format. La validation de la base de données et de la couche de stockage fournit une vérification finale avant la persistance des données. Cette approche multicouche garantit que les entrées malveillantes sont prises même si elles contournent les étapes de validation antérieures.

Prévention de l'injection SQL

Les attaques d'injection SQL demeurent l'une des menaces les plus courantes et les plus dangereuses pour les applications sans serveur qui interagissent avec les bases de données. Ces attaques se produisent lorsque l'entrée de l'utilisateur est directement intégrée dans les requêtes SQL sans sanitisation appropriée, permettant aux attaquants d'exécuter des commandes de base de données arbitraires. Prévenir l'injection SQL nécessite la mise en œuvre de requêtes paramétrées, des procédures stockées et une validation d'entrée appropriée tout au long de l'application.

Les requêtes paramétrées, aussi appelées instructions préparées, séparent le code SQL des données utilisateur, rendant impossible pour les attaquants d'injecter des commandes SQL malveillantes. Les pilotes de bases de données modernes et les frameworks ORM fournissent un support intégré pour les requêtes paramétrées, ce qui en fait l'approche privilégiée pour prévenir l'injection SQL. Les organisations devraient établir des normes de codage qui exigent des requêtes paramétrées pour toutes les interactions de bases de données.

Les contrôles d'accès aux bases de données offrent une protection supplémentaire contre les attaques d'injection SQL en limitant les opérations que les fonctions compromises peuvent effectuer. Même si un attaquant injecte avec succès des commandes SQL, les permissions de base de données appropriées peuvent les empêcher d'accéder à des données sensibles ou d'effectuer des opérations destructrices. Cela comprend la mise en place d'utilisateurs de bases de données distincts pour différentes fonctions avec des restrictions d'autorisation appropriées.

Atténuation de l'injection sans LQS

Les bases de données NoSQL, bien que différentes des bases de données SQL traditionnelles, sont également vulnérables aux attaques par injection qui peuvent compromettre l'intégrité et la confidentialité des données. Les attaques d'injection NoSQL impliquent généralement la manipulation de paramètres de requête ou de structures de documents pour contourner l'authentification, accéder à des données non autorisées ou effectuer des opérations imprévues. Pour prévenir l'injection de NoSQL, il faut comprendre les vecteurs d'attaque spécifiques pour chaque type de base de données et mettre en œuvre des contre-mesures appropriées.

Mongo Les attaques d'injection DB impliquent souvent la manipulation d'opérateurs de requêtes ou l'exploitation de contextes d'exécution JavaScript dans la base de données. Les stratégies de prévention comprennent la validation des entrées pour s'assurer que les paramètres de requête correspondent aux types et formats attendus, en évitant l'exécution de JavaScript dans les requêtes de base de données, et en mettant en œuvre des contrôles d'authentification et d'autorisation appropriés. Organisations utilisant Mongo DB devrait également envisager de permettre l'enregistrement et la surveillance des requêtes suspectes.

DynamoDB et d'autres magasins à valeur clé font face à différents risques d'injection, principalement autour de la clé de partition et trier la manipulation de clé. Les attaquants peuvent tenter d'accéder à des données non autorisées en manipulant des valeurs clés ou en exploitant des modèles d'accès mal conçus. La prévention exige une conception minutieuse des modèles d'accès aux données, une validation adéquate des entrées pour toutes les valeurs clés et la mise en oeuvre de contrôles d'accès à grain fin à l'aide des politiques de MAI.

Protection contre l'injection de commandement

Des vulnérabilités d'injection de commandes se produisent lorsque les fonctions sans serveur exécutent des commandes système en utilisant l'entrée fournie par l'utilisateur sans sanitisation appropriée. Ces vulnérabilités peuvent permettre aux attaquants d'exécuter des commandes arbitraires sur l'environnement d'exécution sous-jacent, ce qui pourrait conduire à un vol de données, à un compromis système ou à un mouvement latéral dans les environnements nuageux. Prévenir l'injection de commande nécessite d'éviter l'exécution de commande système lorsque c'est possible et d'appliquer une validation d'entrée stricte quand c'est nécessaire.

La meilleure approche pour prévenir l'injection de commandes est d'éviter d'exécuter les commandes système, au lieu d'utiliser les bibliothèques de langues natives et les API de service cloud pour accomplir les tâches requises. Par exemple, plutôt que d'utiliser des outils en ligne de commande pour manipuler des fichiers, les applications devraient utiliser des bibliothèques de gestion de fichiers intégrées. Lorsque l'exécution de la commande système est inévitable, les organisations devraient mettre en œuvre une validation d'entrée stricte et utiliser des méthodes d'exécution de commande sûres.

L'exécution sécuritaire des commandes comprend l'utilisation de méthodes paramétrées d'exécution des commandes qui séparent les commandes des arguments, la mise en œuvre d'une validation d'entrée stricte qui ne permet que les caractères et formats attendus, et l'exécution de commandes avec des privilèges minimes dans des environnements isolés. Les organisations devraient également mettre en place une surveillance des activités d'exécution des commandements et établir des procédures d'intervention en cas d'attaques présumées par injection de commandement.

Authentification et autorisation

Mise en œuvre de l'authentification multi-facteurs

L'authentification multifactorielle offre une protection essentielle pour les applications sans serveur en exigeant des utilisateurs qu'ils fournissent plusieurs formes de vérification avant d'y accéder. Cette approche réduit considérablement le risque d'accès non autorisé, même si les mots de passe sont compromis par le phishing, les violations de données ou d'autres méthodes d'attaque. La mise en œuvre de MFA dans des environnements sans serveur nécessite un examen attentif de l'expérience utilisateur, des performances et de l'intégration avec les systèmes d'identité existants.

Les applications modernes sans serveur implémentent généralement MFA par l'intégration avec des fournisseurs d'identité comme AWS Cognito, Azure Active Directory ou Google Identity Platform. Ces services fournissent des capacités MFA intégrées, y compris des SMS, des courriels, des applications d'authentification et des jetons matériels. Les organisations devraient choisir des méthodes d'AMF en fonction de leurs besoins en matière de sécurité, de la base d'utilisateurs et des contraintes opérationnelles.

La mise en œuvre du MFA devrait tenir compte de l'impact de l'expérience utilisateur et fournir des mécanismes de recul appropriés aux utilisateurs qui perdent l'accès à leurs dispositifs d'authentification. Cela comprend la mise en oeuvre de procédures de recouvrement des comptes, l'offre de multiples options de MFA et la garantie que les exigences de MFA ne créent pas d'obstacles pour les utilisateurs légitimes. Les organisations devraient également mettre en place une surveillance des tentatives de contournement du MFA et des modèles d'authentification inhabituels.

Authentification par jeton

L'authentification basée sur les jetons fournit une authentification sécurisée et évolutive pour les applications sans serveur en utilisant des jetons cryptographiquement signés pour vérifier l'identité de l'utilisateur et les autorisations. Cette approche élimine la nécessité d'une gestion par l'État de session dans les fonctions sans serveur apatrides tout en offrant de solides garanties de sécurité. La mise en oeuvre de l'authentification basée sur les jetons exige un examen attentif de la gestion du cycle de vie des jetons, des procédures de validation et des contrôles de sécurité.

JSON Web Tokens (JWT) représente le format de jeton le plus commun pour les applications sans serveur, fournissant une façon normalisée d'encoder l'identité de l'utilisateur et les permissions dans un format cryptographique signé. Les jetons JWT peuvent être validés localement par des fonctions sans serveur sans nécessiter d'appels de service d'authentification externe, améliorant les performances et réduisant les dépendances. Cependant, la mise en oeuvre du TJT exige une attention particulière à l'expiration des jetons, à la validation de la signature et à la vérification des réclamations.

La gestion du cycle de vie des jetons comprend la mise en oeuvre de délais d'expiration appropriés, la mise en place de mécanismes de recyclage des jetons et le maintien de capacités de révocation des jetons. Les jetons à courte durée de vie réduisent l'impact du compromis sur les jetons, mais nécessitent des opérations de rafraîchissement plus fréquentes. Les organisations devraient établir un équilibre entre les exigences en matière de sécurité et les considérations liées à l'expérience des utilisateurs lorsqu'elles élaborent des politiques relatives au cycle de vie des jetons.

Contrôle d'accès axé sur les rôles (CARAR)

Le contrôle d'accès basé sur les rôles offre une approche évolutive de la gestion des permissions dans les applications sans serveur en regroupant les utilisateurs dans les rôles et en attribuant les permissions aux rôles plutôt qu'aux utilisateurs individuels. Cette approche simplifie la gestion des autorisations, améliore la cohérence en matière de sécurité et appuie les exigences de conformité. La mise en œuvre du RBAC dans des environnements sans serveur nécessite une conception prudente des rôles, une cartographie des permissions et une gestion continue des rôles.

La mise en œuvre efficace du CCRA commence par identifier les différents types d'utilisateurs et leurs exigences en matière d'accès. Cela comprend la compréhension des rôles opérationnels, des responsabilités techniques et des besoins en matière d'accès aux données. Les organisations devraient concevoir des rôles qui cadrent avec les fonctions opérationnelles tout en maintenant une séparation appropriée des fonctions et des principes de moindre privilège. Les hiérarchies de rôles peuvent aider à gérer des structures de permission complexes tout en maintenant la clarté et la maniabilité.

La mise en oeuvre du CCRA devrait comprendre des examens réguliers des rôles et des vérifications des autorisations pour s'assurer que les rôles demeurent appropriés et que les utilisateurs n'ont que l'accès dont ils ont besoin. À mesure que les organisations évoluent et que les exigences opérationnelles changent, il faudra peut-être mettre à jour les définitions de rôles pour maintenir la sécurité et l'efficacité opérationnelle. Les outils automatisés peuvent aider à identifier les conflits de rôles, les autorisations excessives et les rôles inutilisés.

Sécurité de la passerelle d'API

Les passerelles API servent de point d'entrée principal pour de nombreuses applications sans serveur et fournissent des capacités de sécurité essentielles, y compris l'authentification, l'autorisation, la limitation des tarifs et la validation des demandes. Une bonne configuration de passerelle API est essentielle pour protéger les fonctions sans serveur contre les accès non autorisés et les requêtes malveillantes. Il s'agit notamment de mettre en place des mécanismes d'authentification appropriés, de configurer les politiques de limitation des taux et de permettre une exploitation et une surveillance exhaustives.

L'authentification par passerelle de l'API devrait s'intégrer aux systèmes d'identité organisationnelle et prendre en charge plusieurs méthodes d'authentification en fonction des besoins des clients. Cela peut inclure les clés API pour la communication service-service, OAuth 2.0 pour l'authentification des utilisateurs, et TLS mutuelle pour les scénarios de haute sécurité. Les organisations devraient mettre en place des méthodes d'authentification appropriées pour chaque paramètre de l'API en fonction des exigences de sensibilité et d'accès.

Limitation des taux et étranglement protègent les fonctions sans serveur contre les attaques de déni de service et aident à contrôler les coûts en empêchant les invocations excessives de fonctions. Les passerelles API devraient mettre en place des limites tarifaires par client et par mondial en fonction des modes d'utilisation prévus et des contraintes de capacité. Les organisations devraient surveiller l'efficacité des mesures de limitation des taux et adapter les politiques en fonction des modes d'utilisation réels et des incidents de sécurité.

Surveillance, exploitation forestière et observation

Logage de sécurité complet

L'enregistrement efficace de la sécurité dans les environnements sans serveur nécessite la saisie d'informations détaillées sur les exécutions de fonctions, les schémas d'accès et les événements de sécurité tout en gérant le volume et le coût des données de journal. Les applications sans serveur génèrent des quantités importantes de données log en raison de leur nature événementielle et de leur modèle d'exécution à grain fin. Les organisations doivent mettre en œuvre des méthodes stratégiques d'exploitation forestière qui tiennent compte de l'information relative à la sécurité sans avoir recours à des systèmes de surveillance accablants ou sans dépasser les contraintes budgétaires.

L'enregistrement de sécurité devrait saisir les événements d'authentification et d'autorisation, y compris les tentatives de connexion réussies et ratées, les changements de permission et l'accès aux ressources sensibles. Les journaux d'exécution des fonctions devraient comprendre les résultats de validation des entrées, les conditions d'erreur et les modèles d'exécution inhabituels qui pourraient indiquer des problèmes de sécurité. Les journaux d'accès au réseau devraient saisir les demandes de passerelles API, les connexions de bases de données et les interactions de services externes afin de fournir une visibilité sur les flux de données et les vecteurs d'attaque potentiels.

La structure des données du registre et la cohérence des formats sont essentielles pour assurer une surveillance et une analyse efficaces de la sécurité. Les organisations devraient mettre en place des formats d'enregistrement normalisés qui comprennent des métadonnées de sécurité essentielles telles que les horodatages, les identifiants d'utilisateur, les adresses IP source et les identifiants de demande. L'enregistrement structuré utilisant des formats JSON ou similaires permet une analyse automatisée et une corrélation entre plusieurs fonctions et services.

Surveillance de la sécurité en temps réel

La surveillance de la sécurité en temps réel permet aux organisations de détecter et d'intervenir en cas d'incidents de sécurité à mesure qu'ils se produisent, en minimisant les dommages potentiels et en réduisant le temps de récupération. Les environnements sans serveur nécessitent des approches de surveillance spécialisées en raison de leur nature répartie et de leurs caractéristiques d'échelle rapide. Les outils traditionnels de surveillance basés sur l'hôte ne sont pas applicables, ce qui oblige les organisations à mettre en œuvre des solutions de surveillance au niveau de l'application et du cloud-native.

Une surveillance efficace en temps réel comprend la détection d'anomalies pour les modes inhabituels d'exécution des fonctions, la surveillance d'authentification pour les activités suspectes de connexion et la surveillance des performances pour les attaques potentielles de déni de service. Les outils de surveillance basés sur l'apprentissage automatique peuvent aider à identifier des modèles d'attaque subtils qui pourraient ne pas déclencher des alertes traditionnelles fondées sur des règles. Les organisations devraient mettre en place des tableaux de bord de surveillance qui fournissent une visibilité en temps réel dans les paramètres de sécurité et permettent une intervention rapide en cas d'incident.

La gestion des alertes est essentielle pour une surveillance efficace en temps réel, car les applications sans serveur peuvent générer de grandes quantités d'alertes qui peuvent surcharger les équipes de sécurité. Les organisations devraient mettre en place des alertes intelligentes qui priorisent les incidents de haute gravité, corrélent les événements connexes et réduisent les faux positifs. La fatigue de l'alerte peut avoir une incidence importante sur l'efficacité de la sécurité, ce qui rend essentiel un réglage d'alerte approprié pour maintenir l'efficacité de l'équipe de sécurité.

Réponse aux incidents et criminalistique

La réponse aux incidents dans des environnements sans serveur nécessite des procédures et des outils spécialisés en raison de la nature éphémère des exécutions de fonctions et de l'architecture distribuée des applications sans serveur. Les approches traditionnelles d'intervention en cas d'incidents qui reposent sur la médecine légale basée sur l'hôte et l'état du système persistant ne s'appliquent pas aux environnements sans serveur. Les organisations doivent mettre au point de nouvelles capacités d'intervention en cas d'incident qui tirent parti des outils natifs du cloud et des techniques médico-légales spécifiques sans serveur.

Les procédures d'intervention en cas d'incident sans serveur devraient comprendre des capacités d'isolement de fonctions rapides pour prévenir d'autres dommages, des outils complets de collecte de journaux et d'analyse pour comprendre la portée et les méthodes d'attaque et des capacités d'intervention automatisées pour contenir et réparer les incidents de sécurité. Les organisations devraient également mettre en œuvre des procédures de sauvegarde et de récupération qui peuvent rapidement restaurer les fonctions et les données compromises.

L'analyse médico-légale dans les environnements sans serveur repose en grande partie sur des données log et des pistes d'audit de services en nuage, car il n'est pas possible d'effectuer des analyses médico-légales traditionnelles sur disque et mémoire. Les organisations devraient mettre en place une collection exhaustive de sentiers d'exploitation forestière et de vérification qui recueille suffisamment de détails pour l'analyse médico-légale. Cela inclut les journaux d'exécution de fonctions, les journaux d'accès aux passerelles d'API, les journaux d'audit de bases de données et les pistes d'audit de services cloud de services comme AWS CloudTrail, Azure Activity Log et Google Cloud Audit Logs.

Corrélation performance et sécurité

La surveillance des performances et la surveillance de la sécurité sont étroitement liées dans les environnements sans serveur, car les incidents de sécurité sont souvent des anomalies de performance. Les attaques de déni de service peuvent apparaître comme des temps d'exécution de fonction accrus ou des taux d'erreur plus élevés. Les attaques d'épuisement des ressources peuvent entraîner l'interruption ou l'échec des fonctions. Les organisations devraient mettre en place une surveillance qui établit des corrélations entre les performances et les mesures de sécurité afin d'assurer une visibilité complète sur la santé et la sécurité des applications.

La surveillance de la sécurité fondée sur la performance comprend le suivi des délais d'exécution des fonctions pour les modèles inhabituels qui pourraient indiquer des attaques d'injection de code ou d'épuisement des ressources, le suivi des taux d'erreurs pour les pics qui pourraient indiquer des tentatives d'attaque et l'analyse des modèles d'utilisation des ressources pour les signes d'exploitation de cryptomonnaie ou d'autres activités non autorisées. Ces paramètres devraient être corrélés aux événements de sécurité afin de fournir un contexte pour l'analyse des incidents.

La surveillance des coûts peut également fournir des informations sur la sécurité, car de nombreuses attaques entraînent une augmentation de la consommation de ressources et des coûts du service cloud. Des augmentations de coûts imprévues peuvent indiquer des attaques de déni de service, des abus de ressources ou des fonctions compromises exécutant des activités non autorisées. Les organisations devraient mettre en œuvre le suivi des coûts et l'alerte dans le cadre de leur stratégie globale de surveillance de la sécurité.

Protection des données et chiffrement

Chiffrement au repos et en transit

Le cryptage des données fournit une protection essentielle pour les informations sensibles dans les applications sans serveur en veillant à ce que les données restent protégées même si d'autres contrôles de sécurité échouent. Des stratégies de cryptage complètes doivent traiter de la protection des données au repos et en transit, en utilisant des algorithmes de cryptage appropriés et des pratiques de gestion des clés. Les applications sans serveur gèrent souvent des données sur plusieurs services cloud, nécessitant des approches de chiffrement cohérentes pour tous les points de stockage et de transmission de données.

Le chiffrement au repos protège les données stockées dans les bases de données, les systèmes de fichiers et d'autres services de stockage persistants. Les plateformes cloud modernes offrent des capacités de chiffrement intégrées pour la plupart des services de stockage, y compris la gestion et la rotation automatiques des clés de chiffrement. Les organisations devraient permettre le cryptage de tous les services de stockage de données et mettre en œuvre un cryptage supplémentaire au niveau des applications pour les données hautement sensibles qui nécessite une protection supplémentaire au-delà du cryptage des fournisseurs de cloud.

Le chiffrement en transit protège les données lorsqu'il se déplace entre les fonctions sans serveur, les services externes et les applications clientes. Cela comprend la mise en oeuvre du chiffrement TLS pour toutes les communications API, l'utilisation de connexions cryptées pour l'accès à la base de données et la garantie que les communications de service interne utilisent des protocoles de chiffrement appropriés. Les organisations devraient mettre en œuvre des procédures de gestion des certificats qui garantissent que les certificats de chiffrement demeurent valides et correctement configurés.

Gestion des clés Meilleures pratiques

La gestion des clés de chiffrement représente l'un des aspects les plus critiques de la protection des données dans les environnements sans serveur. Une mauvaise gestion des clés peut saper même les implémentations de cryptage les plus fortes, ce qui rend la bonne gestion du cycle de vie des clés essentielle au maintien de la sécurité des données. Les organisations doivent mettre en oeuvre des stratégies globales de gestion clés qui traitent de la production, de la distribution, de la rotation et de la destruction de toutes les applications et de tous les services sans serveur.

Les services de gestion de clés numériques comme AWS Key Management Service (KMS), Azure Key Vault et Google Cloud Key Management offrent des fonctionnalités de gestion de clés robustes spécialement conçues pour les applications cloud. Ces services offrent une protection du module de sécurité matérielle (HSM), une rotation automatique des clés et des contrôles d'accès à grain fin qui s'intègrent parfaitement aux fonctions sans serveur. Les organisations devraient tirer parti de ces services plutôt que de mettre en oeuvre des solutions de gestion clés personnalisées.

Les principales politiques de rotation devraient concilier les exigences de sécurité et la complexité opérationnelle, en mettant en œuvre la rotation automatique pour la plupart des clés tout en fournissant des capacités de rotation manuelle pour des circonstances particulières. Les organisations devraient mettre en place une surveillance des principaux modes d'utilisation et établir des procédures pour la rotation d'urgence en cas de compromis présumé. Les principales procédures de sauvegarde et de récupération sont également essentielles au maintien de la continuité des opérations.

Classification et traitement des données

La classification des données constitue le fondement de la mise en oeuvre de contrôles de sécurité appropriés fondés sur la sensibilité aux données et les exigences réglementaires. Les applications sans serveur traitent souvent des données avec des niveaux de sensibilité variables, nécessitant des mesures de protection différentes pour différents types de données. Les organisations devraient mettre en place des systèmes complets de classification des données qui permettent d ' identifier les données sensibles et de préciser les conditions de traitement appropriées pour chaque niveau de classification.

La classification des données devrait tenir compte des exigences réglementaires telles que le PCI DSS pour les données de paiement, le HIPAA pour les informations de santé et le RGPD pour les données personnelles. Chaque niveau de classification devrait préciser les exigences de chiffrement, les contrôles d'accès, les politiques de conservation et les procédures de manutention. Les organisations devraient mettre en place des outils automatisés de découverte et de classification des données qui permettent d'identifier les données sensibles et d'appliquer automatiquement des protections appropriées.

Les procédures de traitement des données devraient porter sur la collecte, le traitement, le stockage et l'élimination des données tout au long du cycle de vie. Cela comprend la mise en œuvre de principes de minimisation des données qui ne recueillent que les données nécessaires, des politiques de conservation des données qui précisent la durée de conservation des données et des procédures d'élimination des données sécurisées qui garantissent que les données sensibles sont correctement détruites lorsqu'elles ne sont plus nécessaires. Les organisations devraient également mettre en place des outils de prévention des pertes de données (DLP) qui surveillent l'accès ou la transmission de données non autorisées.

Considérations relatives à la protection de la vie privée et à la conformité

Les règlements relatifs à la protection de la vie privée comme le RGPD, le CCPA et d'autres lois semblables imposent des exigences spécifiques sur la façon dont les organisations recueillent, traitent et protègent les données personnelles. Les applications sans serveur doivent mettre en place des contrôles de protection de la vie privée appropriés pour assurer la conformité aux règlements applicables. Cela comprend la mise en oeuvre des droits des personnes concernées comme l'accès, la rectification et la suppression, ainsi que des principes de protection de la vie privée par conception qui intègrent la protection de la vie privée dans l'architecture des applications.

Les exigences de conformité précisent souvent les contrôles de sécurité et les procédures de vérification que les organisations doivent mettre en oeuvre. Les applications sans serveur devraient être conçues pour répondre aux exigences de conformité au moyen d'un enregistrement approprié, de contrôles d'accès et de mesures de protection des données. Les organisations devraient mettre en oeuvre une surveillance de la conformité qui permet de suivre le respect des exigences réglementaires et de cerner les éventuelles lacunes en matière de conformité.

Des évaluations de l'impact sur la vie privée devraient être effectuées pour les applications sans serveur qui traitent des données personnelles, identifient les risques potentiels pour la vie privée et précisent les mesures d'atténuation appropriées. Ces évaluations devraient tenir compte de la nature distribuée des applications sans serveur et du potentiel de traitement des données dans plusieurs services cloud et régions géographiques. Les organisations devraient également mettre en oeuvre une formation sur la protection de la vie privée à l'intention des équipes de perfectionnement pour s'assurer qu'elles comprennent les exigences en matière de protection de la vie privée et mettent en oeuvre des mesures de protection appropriées.

Sécurité du réseau et isolement

Configuration du cloud privé virtuel (VPC)

Virtuel Privé La configuration en nuage fournit des contrôles d'isolement et de sécurité au niveau du réseau pour les fonctions sans serveur qui nécessitent un accès à des ressources privées ou une posture de sécurité améliorée. Alors que de nombreuses fonctions sans serveur peuvent fonctionner efficacement dans l'environnement de réseau géré par le fournisseur de cloud, les applications qui traitent des données sensibles ou nécessitent un accès à des bases de données et services privés bénéficient du déploiement VPC. Une configuration VPC adéquate nécessite un examen attentif de l'architecture du réseau, des groupes de sécurité et des politiques de routage.

Les fonctions VPC déployées sans serveur ont accès à des sous-réseaux privés, à des interfaces réseau dédiées et à des contrôles de sécurité réseau améliorés. Ce modèle de déploiement permet aux fonctions d'accéder à des bases de données privées, des API internes et d'autres ressources qui ne sont pas exposées à Internet public. Cependant, le déploiement de VPC introduit également une complexité supplémentaire, y compris les impacts de performance au démarrage à froid et les exigences de configuration du réseau qui doivent être gérées correctement.

Les groupes de sécurité réseau et les listes de contrôle d'accès assurent un contrôle fin du trafic réseau vers et depuis les fonctions sans serveur. Ces contrôles devraient mettre en œuvre les principes de moindre privilège, ne permettant que les communications réseau nécessaires et bloquant tout autre trafic. Les organisations devraient examiner et vérifier régulièrement les configurations de sécurité du réseau pour s'assurer qu'elles demeurent appropriées à mesure que les applications évoluent et que les besoins changent.

API Gateway et l'application Web Pare-feu

Les passerelles API servent de point d'entrée principal du réseau pour la plupart des applications sans serveur et fournissent des capacités de sécurité essentielles, y compris le filtrage des demandes, la limitation des tarifs et l'application du protocole. Une bonne configuration de passerelle de l'API est essentielle pour protéger les fonctions sans serveur contre les attaques basées sur le réseau et garantir que seules les requêtes légitimes atteignent le code de fonction. Cela comprend la mise en place de mécanismes d'authentification appropriés, la validation des demandes et les en-têtes de sécurité.

Web Application Firewalls (WAF) fournit une protection supplémentaire contre les attaques d'applications web courantes, y compris l'injection SQL, le script intersite et d'autres vulnérabilités OWASP Top 10. Les services Cloud-native WAF comme AWS WAF, Azure Web Application Firewall et Google Cloud Armor s'intègrent parfaitement aux passerelles API et fournissent des ensembles de règles gérés qui protègent contre les modèles d'attaque connus. Les organisations devraient mettre en place une protection WAF pour toutes les API publiques sans serveur.

La configuration de la WAF devrait comprendre à la fois des ensembles de règles gérés qui protègent contre les attaques communes et des règles personnalisées qui répondent aux exigences de sécurité spécifiques aux applications. Les organisations devraient examiner régulièrement les registres et les mesures de la FAA pour comprendre les schémas d'attaque et ajuster les règles en conséquence. La fausse gestion positive est importante pour maintenir la disponibilité des applications tout en assurant une protection de sécurité efficace.

Segmentation des réseaux et microsegmentation

La segmentation du réseau dans des environnements sans serveur implique l'isolement de différents composants d'application et flux de données pour limiter l'impact potentiel des failles de sécurité. Bien que la segmentation traditionnelle du réseau repose sur des frontières physiques ou virtuelles du réseau, la segmentation sans serveur utilise généralement des contrôles natifs du cloud comme les groupes de sécurité, les politiques IAM et l'authentification du service au service. Une segmentation efficace nécessite une compréhension de l'architecture des applications et des flux de données pour mettre en place des limites d'isolement appropriées.

La microsegmentation étend les concepts traditionnels de segmentation afin d'assurer un isolement fin entre les fonctions individuelles ou de petits groupes de fonctions connexes. Cette approche limite les possibilités de déplacement latéral des attaquants et permet de mieux maîtriser les incidents de sécurité. La micro-segmentation dans les environnements sans serveur utilise généralement les politiques IAM, les groupes de sécurité du réseau et les technologies de maillage de service pour contrôler les communications entre les fonctions.

Les stratégies de segmentation devraient tenir compte à la fois des exigences de sécurité et des exigences opérationnelles, en mettant en place un isolement approprié sans créer une complexité opérationnelle excessive. Les organisations devraient documenter les politiques de segmentation et mettre en oeuvre un suivi pour s'assurer que les contrôles de segmentation demeurent efficaces au fil du temps. Des tests réguliers de l'efficacité de la segmentation aident à identifier les méthodes de contournement possibles et les problèmes de configuration.

Sécurité du réseau de livraison de contenu (CDN)

Les réseaux de livraison de contenu offrent des avantages en termes de performance et de sécurité pour les applications sans serveur en cachant du contenu plus près des utilisateurs et en fournissant des contrôles de sécurité supplémentaires au bord du réseau. Les fonctions de sécurité du CDN comprennent la protection DDoS, le blocage géographique et le filtrage des requêtes qui peuvent protéger les applications sans serveur de différents types d'attaque. Une configuration CDN adéquate est essentielle pour maximiser ces avantages en matière de sécurité tout en maintenant la fonctionnalité de l'application.

Les configurations de sécurité du CDN devraient comprendre des politiques de mise en cache appropriées qui équilibrent les performances avec les exigences de sécurité, la protection de l'origine qui empêche l'accès direct aux API sans serveur et les restrictions géographiques qui bloquent le trafic des régions à haut risque, le cas échéant. Les organisations devraient également mettre en oeuvre la surveillance et l'enregistrement du RNC pour donner une visibilité aux modèles d'attaque et à l'efficacité du RNC.

Les capacités de sécurité de bord fournies par les CDN modernes comprennent l'exécution de fonctions sans serveur aux emplacements de bord, qui peuvent fournir un traitement de sécurité supplémentaire plus près des utilisateurs. Ces fonctions de bord peuvent implémenter des contrôles de sécurité comme la validation des demandes, l'authentification et la détection des robots avant que les demandes atteignent les fonctions sans serveur d'origine. Les organisations devraient tenir compte des capacités de sécurité de pointe lors de la conception d'architectures d'applications sans serveur.

Sécurité de la dépendance et de la chaîne d'approvisionnement

Gestion de la bibliothèque par des tiers

Les bibliothèques et dépendances tierces représentent un risque important pour la sécurité des applications sans serveur, car les vulnérabilités de ces composants peuvent compromettre la sécurité des applications même si le code personnalisé est sécurisé. Les applications sans serveur utilisent souvent de nombreuses bibliothèques tierces pour implémenter la fonctionnalité rapidement, créant ainsi une grande surface d'attaque qui nécessite une gestion soigneuse. Les organisations doivent mettre en oeuvre des pratiques globales de gestion de la dépendance qui comprennent l'analyse de vulnérabilité, la conformité aux licences et des mises à jour régulières.

L'analyse de la vulnérabilité à la dépendance devrait être intégrée au pipeline de développement et de déploiement afin d'identifier les vulnérabilités connues avant qu'elles n'atteignent les environnements de production. Les outils modernes de numérisation peuvent identifier les vulnérabilités tant dans les dépendances directes que dans les dépendances transitoires, offrant une visibilité complète sur les risques potentiels pour la sécurité. Les organisations devraient établir des politiques pour remédier aux vulnérabilités identifiées en fonction des niveaux de gravité et de l'impact potentiel.

La gestion de la mise à jour de la bibliothèque exige un équilibre entre les exigences de sécurité et la stabilité de l'application et les préoccupations de compatibilité. Les organisations devraient mettre en oeuvre des procédures d'essai qui valident la fonctionnalité de l'application après les mises à jour relatives aux dépendances et établir des procédures de retour pour les mises à jour qui posent problème. Des outils automatisés de mise à jour des dépendances peuvent aider à maintenir les versions actuelles tout en offrant des capacités de test et de validation appropriées.

Sécurité de l'image du conteneur

De nombreuses plateformes sans serveur supportent des modèles de déploiement basés sur des conteneurs qui offrent une flexibilité et un contrôle supplémentaires sur l'environnement d'exécution. La sécurité de l'image de conteneur est cruciale pour ces modèles de déploiement, car les vulnérabilités dans les images de base ou les configurations de conteneur peuvent compromettre la sécurité des fonctions sans serveur. Les organisations doivent mettre en place des pratiques complètes de sécurité des conteneurs qui traitent de la numérisation d'images, de la gestion de la configuration et de la sécurité d'exécution.

La numérisation de l'image du conteneur devrait identifier les vulnérabilités dans les composants du système d'exploitation de base, les environnements d'exécution et les dépendances des applications. La numérisation devrait se faire à la fois pendant le processus de construction et en continu en production pour identifier les vulnérabilités nouvellement découvertes. Les organisations devraient mettre en œuvre des politiques pour remédier aux vulnérabilités identifiées et établir des procédures pour mettre à jour et redéployer les images des conteneurs au besoin.

La sécurité de configuration du conteneur comprend la mise en oeuvre des autorisations d'utilisation appropriées, des protections du système de fichiers et des configurations réseau. Les conteneurs devraient fonctionner avec des privilèges minimes et inclure seulement les composants nécessaires pour réduire la surface d'attaque. Les organisations devraient mettre en place des critères de sécurité pour les conteneurs comme le repère Docker de l'ECI afin d'assurer des configurations de sécurité uniformes pour tous les déploiements de conteneurs.

Logiciel Bill of Materials (SBOM)

Le logiciel Bill of Materials offre une visibilité complète sur tous les composants inclus dans les applications sans serveur, y compris les bibliothèques tierces, les images de base de conteneurs et d'autres dépendances. La production et la gestion du SBOM prennent de plus en plus d'importance à des fins de sécurité et de conformité, car les organisations doivent comprendre les risques liés à la chaîne d'approvisionnement des logiciels et réagir rapidement aux vulnérabilités nouvellement découvertes.

La production de SBOM devrait être automatisée dans le cadre du processus de construction et de déploiement afin d'assurer l'exactitude et l'exhaustivité. Les outils de construction modernes et les plateformes de conteneur offrent des capacités de génération SBOM intégrées qui permettent d'identifier tous les composants et leurs versions. Les organisations devraient mettre en place des systèmes de stockage et de gestion SBOM qui permettent des recherches rapides et une corrélation de vulnérabilité entre toutes les applications et déploiements.

L'utilisation du SBOM comprend des processus de gestion de la vulnérabilité qui peuvent rapidement identifier les applications touchées lorsque de nouvelles vulnérabilités sont découvertes, des rapports de conformité qui démontrent la visibilité des composants logiciels et des procédures d'intervention en cas d'incident qui peuvent rapidement évaluer la portée des problèmes de sécurité potentiels. Les organisations devraient intégrer les données du SBOM à leurs systèmes de surveillance de la sécurité et d'intervention en cas d'incident afin d'en maximiser la valeur.

Prévention des attaques de la chaîne d'approvisionnement

Les attaques de la chaîne d'approvisionnement ciblent le pipeline de développement et de déploiement du logiciel pour injecter du code malveillant ou compromettre l'intégrité du logiciel. Ces attaques peuvent être particulièrement dangereuses dans les environnements sans serveur en raison de la nature distribuée des applications sans serveur et de la dépendance à l'égard des services et composants tiers. Les organisations doivent mettre en œuvre des mesures globales de sécurité de la chaîne d'approvisionnement qui protègent contre divers vecteurs d'attaque tout au long du cycle de vie du développement.

La vérification de l'intégrité du code comprend la mise en oeuvre de la signature de code pour les applications personnalisées, la vérification des signatures pour les composants tiers et l'utilisation de dépôts fiables pour la gestion de la dépendance. Les organisations devraient mettre en place une sécurité de l'environnement qui protège les systèmes de développement et de déploiement contre les compromis et veiller à ce que seul le personnel autorisé puisse modifier le code d'application et les configurations.

La sûreté des pipelines de déploiement comprend la mise en place de contrôles d'accès appropriés pour les systèmes de déploiement, l'utilisation de voies de communication sécurisées pour toutes les activités de déploiement, et la mise en place d'un système complet d'enregistrement et de surveillance des processus de déploiement. Les organisations devraient également mettre en oeuvre des procédures de vérification du déploiement qui valident l'intégrité et la fonctionnalité de l'application avant le déploiement de la production.

Techniques de sécurité avancées

Autoprotection des applications d'exécution (RASP)

Application d'exécution L'autoprotection représente une approche de sécurité émergente qui intègre les contrôles de sécurité directement dans les applications sans serveur pour fournir des capacités de détection et de réponse en temps réel. Les solutions RASP surveillent le comportement de l'application pendant l'exécution et peuvent bloquer ou atténuer automatiquement les attaques à mesure qu'elles se produisent. Cette approche est particulièrement utile dans les environnements sans serveur où les contrôles de sécurité traditionnels basés sur le réseau peuvent être moins efficaces.

L'implémentation du RASP dans les environnements sans serveur implique généralement l'intégration de bibliothèques ou d'agents de sécurité dans le code de fonction qui surveille les activités suspectes comme les tentatives d'injection SQL, l'injection de commandes et les modèles d'accès inhabituels aux données. Ces solutions peuvent fournir des capacités d'intervention immédiate sans nécessiter une infrastructure de sécurité externe ou une gestion de configuration complexe. Les solutions modernes RASP sont conçues pour minimiser l'impact sur le rendement tout en offrant une couverture de sécurité complète.

L'efficacité du RASP dépend de la configuration et du réglage appropriés pour minimiser les faux positifs tout en maintenant la couverture de sécurité. Les organisations devraient mettre en œuvre les solutions RASP progressivement, en commençant par le mode de surveillance pour comprendre le comportement de l'application avant de permettre des capacités de blocage. L'examen et l'adaptation réguliers des politiques du RASP font en sorte que la protection demeure efficace à mesure que les applications évoluent et que de nouvelles menaces apparaissent.

Analyse comportementale et détection des anomalies

L'analyse comportementale fournit des capacités avancées de détection de la menace en établissant des lignes de base du comportement normal de l'application et en identifiant les écarts qui peuvent indiquer des incidents de sécurité. Cette approche est particulièrement utile dans les environnements sans serveur où les méthodes traditionnelles de détection par signature peuvent être moins efficaces en raison de la nature dynamique et distribuée des applications sans serveur.

L'analyse comportementale basée sur l'apprentissage automatique peut identifier des modèles d'attaque subtils qui pourraient ne pas déclencher des contrôles de sécurité traditionnels. Ces systèmes analysent les modèles dans les temps d'exécution des fonctions, l'utilisation des ressources, les modèles d'appels API et les comportements d'accès aux données pour identifier les incidents de sécurité potentiels. L'analyse avancée peut également corréler les comportements entre plusieurs fonctions et services pour identifier des campagnes d'attaque complexes.

La mise en oeuvre de l'analyse comportementale exige un examen attentif des périodes d'établissement de base, de la gestion faussement positive et des priorités d'alerte. Les organisations devraient mettre en place des systèmes d'analyse qui peuvent s'adapter à l'évolution des comportements des applications tout en restant sensibles aux menaces à la sécurité. L'intégration aux systèmes d'intervention en cas d'incident permet de réagir rapidement aux menaces identifiées.

Vulnérabilité zéro jour Protection

Les vulnérabilités de zéro jour représentent l'une des menaces les plus difficiles pour la sécurité, car elles exploitent des vulnérabilités précédemment inconnues pour lesquelles il n'existe pas de correctifs ou de signatures. Les applications sans serveur nécessitent des approches spécialisées pour une protection à jour zéro en raison de leur nature distribuée et de leur dépendance à l'égard de l'infrastructure du fournisseur de cloud. Les organisations doivent mettre en place de multiples couches de protection qui peuvent détecter et atténuer les menaces inconnues.

Les stratégies de protection à jour zéro comprennent la mise en oeuvre d'une validation complète des entrées qui peut bloquer de nombreuses tentatives d'attaque indépendamment de la vulnérabilité spécifique exploitée, l'utilisation de techniques de sablage et d'isolement d'applications qui limitent l'impact des exploits réussis, et la mise en oeuvre d'une surveillance comportementale qui peut détecter des activités inhabituelles qui peuvent indiquer une exploitation à jour zéro.

L'intégration avancée du renseignement sur les menaces peut fournir un avertissement rapide des menaces émergentes et des techniques d'attaque qui peuvent cibler des applications sans serveur. Les organisations devraient mettre en place des sources de renseignements sur les menaces qui fournissent des renseignements sur les nouvelles méthodes d'attaque et les indicateurs de compromis. Ce renseignement devrait être intégré aux systèmes de surveillance de la sécurité afin de permettre une détection et une réaction rapides aux nouvelles menaces.

Automatisation et orchestre de sécurité

L'automatisation et l'orchestration de la sécurité permettent aux organisations d'intervenir plus rapidement et de façon plus cohérente en cas d'incidents de sécurité, tout en réduisant le fardeau des équipes de sécurité. Les environnements sans serveur sont particulièrement adaptés à l'automatisation de la sécurité en raison de leur nature événementielle et de leur intégration aux services cloud-native. Les organisations devraient mettre en oeuvre des mesures de sécurité automatisées qui peuvent contenir des menaces, recueillir des preuves et mettre en place des procédures d'assainissement sans intervention humaine.

L'intervention automatisée en cas d'incident comprend la mise en oeuvre de capacités automatisées d'isolement des fonctions qui peuvent rapidement désactiver les fonctions compromises, la collecte et l'analyse automatisées de registres qui peuvent rapidement évaluer la portée et l'impact des incidents, et des systèmes automatisés de notification qui alertent les équipes de sécurité aux incidents critiques. Ces capacités devraient être intégrées aux outils de sécurité existants et aux procédures d'intervention en cas d'incident.

Les plates-formes d'orchestration de sécurité peuvent coordonner des activités d'intervention complexes entre plusieurs systèmes et services. Ces plateformes peuvent mettre en place des playbooks qui définissent des procédures de réponse étape par étape pour différents types d'incidents de sécurité. Les capacités d'orchestration devraient inclure l'intégration avec les API du fournisseur de cloud, les outils de sécurité et les systèmes de communication pour permettre une réponse globale aux incidents.

Conformité et considérations réglementaires

Exigences de conformité spécifiques à l'industrie

Différentes industries font face à des exigences réglementaires spécifiques qui ont une incidence sur la conception et la mise en oeuvre de la sécurité des applications sans serveur. Les organismes de soins de santé doivent se conformer aux exigences de l'HIPAA en matière de protection de l'information sur la santé des patients, les organismes de services financiers doivent satisfaire aux exigences du PCI DSS en matière de protection des données par carte de paiement, et les entrepreneurs gouvernementaux doivent mettre en place des contrôles FedRAMP pour les services en nuage. La compréhension et la mise en oeuvre de contrôles de conformité appropriés sont essentielles pour les organisations qui exercent des activités dans les industries réglementées.

La mise en œuvre de la conformité dans les environnements sans serveur nécessite la mise en correspondance des exigences réglementaires avec des contrôles techniques spécifiques et la garantie que ces contrôles sont correctement mis en œuvre et maintenus. Cela comprend la mise en oeuvre d'un cryptage approprié des données, des contrôles d'accès, de l'enregistrement des vérifications et des capacités d'intervention en cas d'incident qui répondent aux normes réglementaires. Les organisations devraient travailler avec les experts de la conformité pour s'assurer que les implémentations sans serveur répondent à toutes les exigences applicables.

La surveillance et l'établissement de rapports sur la conformité exigent une évaluation continue de l'efficacité du contrôle et de la documentation sur l'état de conformité. Les organisations devraient mettre en place une surveillance automatisée de la conformité qui puisse évaluer en permanence la mise en oeuvre du contrôle et identifier les lacunes éventuelles en matière de conformité. Des vérifications et des évaluations régulières de la conformité permettent de s'assurer que les applications sans serveur maintiennent la conformité au fil du temps à mesure que les exigences et les implémentations évoluent.

Résidence et souveraineté des données

Les exigences relatives à la résidence et à la souveraineté des données précisent où les données peuvent être stockées et traitées, ce qui exige souvent que certains types de données demeurent dans des limites géographiques précises. Ces exigences peuvent avoir une incidence significative sur l'architecture des applications sans serveur, car les fournisseurs de cloud exploitent des centres de données dans plusieurs régions et peuvent déplacer des données entre régions à des fins opérationnelles. Les organisations doivent tenir compte des exigences de résidence des données lors de la conception d'applications sans serveur.

La mise en œuvre de la résidence sans serveur consiste généralement à configurer les services cloud pour fonctionner dans des régions précises, à mettre en œuvre des procédures de classification et de traitement des données qui garantissent que les données sensibles demeurent dans des endroits appropriés et à établir des capacités de surveillance et de vérification qui permettent de vérifier la conformité aux exigences de résidence. Les organisations devraient également examiner les incidences des exigences de résidence des données sur la sauvegarde et la reprise après sinistre.

Les règlements relatifs au transfert transfrontalier de données, comme le RGPD, imposent des exigences supplémentaires sur la manière dont les données à caractère personnel peuvent être transférées entre différentes juridictions. Les organisations doivent mettre en place des garanties appropriées pour les transferts internationaux de données et veiller à ce que les applications sans serveur respectent les restrictions de transfert applicables. Cela peut nécessiter la mise en œuvre d'accords supplémentaires de cryptage, de contrôle d'accès ou de traitement de données avec les fournisseurs de cloud.

Vérification et documentation

La conformité réglementaire exige généralement une documentation exhaustive des contrôles, des politiques et des procédures de sécurité. Les applications sans serveur doivent conserver la documentation appropriée qui démontre la conformité aux exigences applicables et appuie les activités de vérification. Il s'agit notamment de documenter les architectures de sécurité, les mises en oeuvre des contrôles et les procédures opérationnelles qui appuient les objectifs de conformité.

Les exigences relatives aux pistes de vérification précisent quelles activités doivent être enregistrées et combien de temps les dossiers de vérification doivent être conservés. Les applications sans serveur devraient mettre en place un enregistrement complet qui capte toutes les activités liées à la sécurité et maintient des pistes de vérification conformément aux exigences réglementaires. Les organisations devraient mettre en place des systèmes de gestion des registres qui peuvent préserver les pistes de vérification pendant les périodes de conservation requises et fournir des contrôles d'accès appropriés pour les données de vérification.

La gestion de la documentation comprend la tenue de documents à jour et exacts sur les contrôles de sécurité, la mise en oeuvre de procédures de gestion du changement qui mettent à jour la documentation lorsque les systèmes changent et l'accès approprié à la documentation pour les vérificateurs et les évaluateurs de conformité. Les organisations devraient mettre en place des systèmes de gestion de la documentation qui appuient les exigences de conformité tout en protégeant les renseignements sensibles.

Conclusion : Créer des applications sans serveur sécurisées

La sécurité sans serveur nécessite une approche globale qui répond aux défis et opportunités uniques de l'informatique sans serveur tout en mettant en œuvre les principes fondamentaux de sécurité. La nature distribuée des applications sans serveur, des modèles de responsabilité partagée et des cycles de développement rapide créent de nouvelles considérations de sécurité que les organisations doivent aborder au moyen de connaissances, d'outils et de procédures spécialisés.

Le succès de la sécurité sans serveur dépend de la mise en place de contrôles de sécurité tout au long du cycle de vie du développement, de la conception initiale au déploiement et aux opérations en cours. Cela comprend l'établissement de pratiques de développement sécuritaires, la mise en oeuvre de procédures d'essai et de validation exhaustives et le maintien des capacités de surveillance et d'intervention en cas d'incident. Les organisations doivent également rester à l'affût de l'évolution des menaces et des pratiques exemplaires en matière de sécurité à mesure que le paysage sans serveur se développe.

La clé d'une sécurité efficace sans serveur réside dans la compréhension que la sécurité n'est pas une mise en œuvre ponctuelle mais un processus continu qui nécessite une attention et une amélioration continues. Les organisations devraient établir des programmes de sécurité qui comprennent des évaluations régulières, de la formation et des mises à jour afin de s'assurer que les applications sans serveur demeurent sécuritaires à mesure qu'elles évoluent et que de nouvelles menaces surgissent. En appliquant les pratiques de sécurité détaillées décrites dans le présent guide, les organisations peuvent tirer parti des avantages de l'informatique sans serveur tout en maintenant de solides postures de sécurité.

La sécurité sans serveur moderne exige également la collaboration entre les équipes de développement, d'exploitation et de sécurité pour garantir que les considérations de sécurité sont correctement intégrées dans tous les aspects du développement et du déploiement des applications sans serveur. Cette approche collaborative, souvent appelée DevSecOps, garantit que la sécurité est intégrée dans les applications dès le début plutôt que d'être ajoutée comme une réflexion.

L'avenir de la sécurité sans serveur comprendra probablement une plus grande automatisation, une meilleure intégration entre les outils de sécurité et les plates-formes sans serveur, et des capacités de détection de menaces renforcées spécialement conçues pour les environnements sans serveur. Les organisations qui investissent aujourd'hui dans des programmes complets de sécurité sans serveur seront mieux placées pour tirer parti de ces progrès tout en maintenant de solides postures de sécurité.

Références et lectures complémentaires

*Ce guide complet fournit la base pour la mise en œuvre de pratiques de sécurité robustes sans serveur à travers AWS Lambda, Azure Functions, Google Cloud Functions et d'autres plateformes sans serveur. Pour des ressources supplémentaires et des sujets avancés, consultez la documentation de sécurité des fournisseurs de cloud, les cadres de sécurité de l'industrie et les programmes spécialisés de formation en sécurité sans serveur qui peuvent améliorer votre expertise en sécurité sans serveur. *

[1] Pratiques exemplaires en matière de sécurité AWS Lambda - https://docs.aws.amazon.com/lambda/latest/dg/lambda-security.html [2] Projet Top 10 sans serveur OWASP - https://owasp.org/www-project-serverless-top-10/ [3] Lignes directrices sur la sécurité des fonctions d'azur - https://docs.microsoft.com/en-us/azure/azure-functions/security-concepts [4] Aperçu de la sécurité des fonctions Google Cloud - https://cloud.google.com/functions/docs/securing [5] Cloud Security Alliance Guide de sécurité sans serveur - https://cloudsecurityalliance.org/research/topics/serverless [6] Cadre de cybersécurité du NIST - https://www.nist.gov/cyberframework [7] Pilier de sécurité bien architecturé AWS - https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/ [8] Microsoft Azure Security Benchmark - https://docs.microsoft.com/en-us/security/benchmark/azure/ [9] Pratiques exemplaires de sécurité Google Cloud - https://cloud.google.com/security/best-practices [10] Recherche sur la sécurité sans serveur et pratiques exemplaires - https://github.com/puresec/awesome-serverless-security