En abstractionnant la gestion de l'infrastructure, il permet aux développeurs de se concentrer sur le code pendant que le fournisseur de cloud gère l'échelle, le patching et la disponibilité. Cependant, ce changement introduit de nouveaux défis de sécurité, en particulier autour du contrôle d'accès. Dans un environnement sans serveur, les fonctions sont éphémères, granulaires et souvent invoquées par divers déclencheurs – requêtes HTP, files d'attente de messages ou événements programmés. Sans un modèle robuste de contrôle d'accès, le risque d'accès non autorisé ou de fuite de données augmente de façon significative.

Qu'est-ce que le contrôle d'accès fondé sur le rôle (CACAR)?

Le contrôle d'accès basé sur les rôles est un paradigme de sécurité qui attribue les permissions aux rôles plutôt qu'aux utilisateurs individuels.Les utilisateurs sont ensuite regroupés en rôles en fonction de leurs fonctions professionnelles, et ces rôles déterminent les actions qu'ils peuvent effectuer sur quelles ressources. Par exemple, dans un système de traitement de documents sans serveur, un rôle d'administrateur pourrait avoir la permission d'invoquer n'importe quelle fonction et d'accéder à tous les seaux S3, tandis qu'un rôle d'éditeur ne peut invoquer la fonction et de lire depuis un seaux spécifique.

Le RBAC est défini par trois règles fondamentales:

  • Offre de propriété : Un sujet ne peut exercer une permission que si un rôle lui a été assigné, y compris cette autorisation.
  • Autorisation de rôle:[ Le rôle actif d'un sujet doit être autorisé pour eux. Cela garantit que même si un utilisateur a plusieurs rôles, un seul rôle peut être actif à la fois (ou un sous-ensemble).
  • Autorisation de permis:[ Un sujet ne peut exercer une autorisation que si la permission est autorisée pour le rôle actif du sujet.

Pourquoi amplifier les défis de contrôle d'accès sans serveur

Les applications monolithiques traditionnelles ont souvent un point d'entrée unique, ce qui rend simple l'application de l'authentification et de l'autorisation basées sur le middleware. Les applications sans serveur, par contre, sont composées de dizaines ou de centaines de petites fonctions apatrides, dont chacune peut être directement invoquée.

  • Gestion décentralisée des permissions:[ Chaque fonction peut exiger ses propres permissions pour interagir avec des bases de données, des files d'attente ou des API externes. La gestion manuelle de ces fonctions entre les fonctions devient impossible à l'échelle.
  • Accès dynamique aux ressources:[ Les fonctions peuvent avoir besoin d'accéder à différentes ressources selon la charge utile de l'événement ou le contexte utilisateur.
  • Visibilité limitée: Les architectures sans serveur permettent d'absorber l'infrastructure sous-jacente, ce qui rend difficile l'audit de ceux qui ont accédé à quoi et quand.
  • Effets de démarrage à froid:[ La logique d'autorisation qui nécessite la récupération de rôles dans une base de données peut augmenter la latence sur les démarrages à froid de fonction, potentiellement dégradante expérience utilisateur.

Ces défis font une mise en œuvre bien planifiée de RBAC non seulement une pratique exemplaire, mais une nécessité pour des applications sans serveur de qualité de production.

Composantes essentielles d'un système RBAC

Avant de plonger dans les stratégies de mise en oeuvre, il est utile de comprendre les éléments constitutifs de tout système RBAC :

  • Usagers:[ Les identités humaines ou de service qui ont besoin d'accès.
  • Roles:[ Catégories désignées (p. ex., Admin, Viewer, Contributeur) qui agrége les permissions.
  • Permissions:[ La capacité d'effectuer une action spécifique sur une ressource spécifique (p. ex., sur la fonction .
  • Politiques:[ Documents qui définissent un ensemble de permissions et qui sont attachés aux rôles.
  • Contexte de session:[ Informations sur l'utilisateur, ses rôles et la requête courante (p. ex., temps, IP, ressource accessible).

Dans les systèmes sans serveur, ces composants sont souvent exprimés par le biais des systèmes IAM du fournisseur de cloud (AWS IAM, Azure RBAC, GCP IAM) mais peuvent également être mis en œuvre sur la couche d'application en utilisant un service d'autorisation personnalisé.

Stratégies pour la mise en œuvre du RBAC dans les applications sans serveur

Il n'y a pas d'approche unique. La bonne stratégie dépend de votre fournisseur de cloud, de la complexité de vos permissions et de votre tolérance à la latence. Voici des méthodes éprouvées.

1. Tirer parti des services IAM Cloud comme la Fondation

La plupart des grands fournisseurs de cloud offrent des IAM intégrés qui peuvent être utilisés pour définir les rôles et attacher des politiques au niveau du compte ou de la ressource. Par exemple, AWS IAM vous permet de créer des rôles d'exécution pour les fonctions Lambda. Si une fonction doit être lue depuis DynamoDB, vous ajoutez une politique d'octroi de la politique IAM sur cette table spécifique. C'est la forme la plus simple de RBAC : le rôle est lié au contexte d'exécution de la fonction, et non à l'utilisateur final. Cependant, parce que toutes les invocations de cette fonction partagent le même rôle d'exécution, les permissions par utilisateur à grain fin nécessitent une logique supplémentaire à l'intérieur de la fonction elle-même.

Pour Azure, Azure RBAC s'intègre avec Azure Functions et App Service. Vous pouvez assigner des rôles à des identités gérées ou à des groupes AD Azure, et ces rôles dictent l'accès à des ressources Azure comme Blob Storage ou Cosmos DB. De même, GCP IAM[ fonctionne avec Cloud Functions et d'autres services.

2. Mettre en œuvre le contrôle d'accès par gradation fine avec des politiques personnalisées

Lorsque les permissions dépendent des attributs de la requête (par exemple, l'identifiant d'utilisateur, le propriétaire du document ou l'action en cours), le cloud IAM seul est insuffisant. C'est là que le contrôle d'accès par attribut (ABAC) est mis en jeu. Vous pouvez combiner les politiques IAM avec les touches de condition. Par exemple, dans AWS, vous pouvez écrire une politique qui accorde seulement si la balise objet identifie le département user. Cela soulève une grande partie du fardeau du code de fonction.

Pour des règles plus complexes, vous devrez peut-être faire respecter l'autorisation à la couche d'application. Après que la fonction reçoit l'événement d'invocation, elle interroge un magasin de permission de rôle (par exemple, dans DynamoDB ou Redis) pour déterminer si l'appelant a le droit d'exécuter l'action demandée. Ceci est souvent appelé contrôle d'accès basé sur la politique (PBAC) et est populaire dans les applications SaaS multi-tenues.

3. Utilisez les autoriseurs personnalisés de passerelle API

Pour les fonctions exposées via HTTP (par exemple, REST ou GraphQL), la passerelle API est le point d'application naturel. AWS API Gateway personnalisation authors (Lambda authors) peut valider un jeton porteur (JWT, OAuth) et retourner une politique IAM qui dicte les paramètres et méthodes API auxquels l'appelant est autorisé à accéder. Cette politique est ensuite mise en cache et appliquée aux requêtes ultérieures, réduisant ainsi la latence.

Les autorisants personnalisés sont idéaux car ils centralisent la logique d'autorisation en une seule fonction, plutôt que de la diffuser dans chaque fonction de backend. L'autorisant reçoit le jeton, extrait les rôles de l'utilisateur, recherche les permissions et retourne une politique.

4. Maintenir la cartographie des rôles dans une Datastore sécurisée

Les rôles et les attributions des utilisateurs doivent être stockés et récupérables à l'exécution.

  • Gérer les services de répertoires :[ Azure AD, AWS Cognito ou Auth0 peuvent stocker des informations sur les rôles comme attributs ou groupes personnalisés.
  • Bases de données relationnelles ou non-SQL:[ Conservez une table avec une colonne ou une table de correspondance séparée . Récupérez-la via une requête en cache.
  • Caches distribuées:[ Amazon ElastiCache (Redis) ou DAX peuvent servir des données de rôle avec une faible latence, critique pour les démarrages à froid.

Assurez-vous que le datastore lui-même est sécurisé par des politiques IAM strictes. N'exposez jamais les données de rôle à des paramètres non authentifiés.

Étapes de mise en oeuvre : De la conception au déploiement

Suivez ces étapes pour concevoir et mettre en œuvre RBAC dans une application sans serveur:

  1. Identifiez les ressources et les actions:[ Listez toutes les fonctions, API, seaux de stockage, files d'attente et tables sans serveur. Pour chacune, définissez les actions qui peuvent être exécutées (invoquez, lisez, écrivez, supprimez).
  2. Définir les rôles :[ Interroger les intervenants pour comprendre les fonctions du travail (p. ex. client, agent de soutien, administrateur).
  3. Design IAM policies:[ Pour les ressources en nuage, créez des politiques IAM qui accordent les actions minimales requises.
  4. Authentification de l'exécution: Assurez-vous que chaque paramètre HTTP nécessite un jeton vérifiable (JWT, OAuth2). Utilisez un fournisseur d'identité comme Cognito, Auth0 ou Firebase.
  5. Construisez un autorisant personnalisé:[ Écrire une fonction Lambda qui décode le jeton, extrait le rôle de l'utilisateur, interroge un magasin de permission et retourne un document de politique IAM.
  6. L'autorisation enmbed dans les déclencheurs non-HTTP : Pour les événements SQS, S3 ou les flux DynamoDB, inclure le contexte de rôle dans la charge utile de l'événement ou utiliser une recherche à l'intérieur de la fonction.
  7. Cache agressivement:[ Entreposez des cartes de rôle à autorisation dans un cache Redis avec un TTL pour réduire la charge de la base de données et améliorer la latence.
  8. Testez attentivement:[ Écrire des tests d'intégration qui simulent différents rôles et vérifient que les actions non autorisées sont bloquées. Utilisez des outils comme AWS IAM Access Analyzer pour valider les politiques.
  9. Moniteur et audit: Activer CloudTrail (AWS) ou les journaux d'activités (Azure) pour enregistrer toutes les tentatives d'accès.

Pièges courants et comment les éviter

  • Rôles d'exécution excessivement permissives:[ Les développeurs peuvent être tentés d'attacher un seul rôle IAM "poweruser" à toutes les fonctions. Cela viole le moindre privilège et augmente le rayon de blast. Utilisez des rôles séparés par fonction ou groupe de fonctions ayant des besoins similaires.
  • Ignorer le démarrage du froid:[ Le chargement des données de rôle d'une base de données sur chaque invocation peut ajouter une latence de 200 à 500ms. Précharger la décision d'autorisation dans l'autorisateur API Gateway et la mettre en cache.
  • Autorisations de codage à l'arrêt:[ Les autorisations doivent être faciles à mettre à jour sans redéployer de fonction.
  • Négligence des identités de service : Le RBAC devrait couvrir les acteurs non humains (p. ex., un événement programmé qui déclenche une fonction).
  • Lasse de tests pour l'autorisation:[ Il est facile de tester des scénarios de «chemin heureux».

Exemple du monde réel : Traitement sécurisé de documents multi-tenants

Considérez une plateforme SaaS où les locataires téléchargent des documents pour le traitement. Chaque locataire a son propre dossier dans un seau S3. Le workflow utilise API Gateway, une fonction Lambda pour le téléchargement de documents, une autre pour le traitement (démarré par l'événement S3) et une troisième pour la requête des résultats de stockage dans DynamoDB.

Rôles:

  • Tenant Admin:[ peut télécharger des documents, afficher les résultats et supprimer leurs propres fichiers traités.
  • Viewer: Ne peut afficher que les résultats (lisez DynamoDB) mais pas télécharger ou supprimer.
  • Admin système: Accès complet à tous les locataires pour le débogage (seulement pour une équipe d'opérations de confiance).

Mise en œuvre:

  • L'identité du locataire est conservée dans un TJT émis par Cognito, contenant des revendications et .
  • API Gateway utilise un Lambda autorisant personnalisé qui décode le JWT, interroge une table DynamoDB pour obtenir les permissions du rôle, et renvoie une politique qui incluait l'accès aux ressources avec le préfixe ID du locataire (par exemple, .
  • La fonction de téléchargement reçoit l'ID du locataire dans le contexte de la demande; elle utilise cela pour s'assurer que le fichier est placé dans le dossier correct. La fonction de traitement lit l'étiquette du dossier pour associer les résultats au locataire.
  • Toutes les requêtes DynamoDB incluent l'ID du locataire dans la clé primaire, et la politique IAM fait en sorte que la fonction ne peut lire/écrire que des éléments avec cette clé de partition.

Cette architecture garantit qu'un locataire ne peut pas accéder à une autre donnée de locataire, et que les utilisateurs de Viewer ne peuvent pas invoquer la fonction de téléchargement. Les rôles et les permissions sont gérés centralement, et les changements prennent effet immédiatement sans redéployer aucune fonction.

Outils et cadres pour simplifier le CCRA

Plusieurs outils commerciaux et open-source peuvent accélérer la mise en œuvre du RBAC :

  • Open Policy Agent (OPA):[ Un moteur générique de politique qui peut être déployé comme sidecar ou microservice pour faire respecter des règles d'autorisation complexes. Il s'intègre bien avec les sidecars HTTP ou les runtimes Go/Rust sans serveur.
  • Casbin: Une bibliothèque de permissions pour Go, Java, Node.js et Python. Prend en charge RBAC, ABAC et des modèles personnalisés. Peut fonctionner à l'intérieur d'une fonction Lambda pour évaluer les permissions avec faible latence.
  • Auth0 / Firebase Auth: Tous deux fournissent des RBAC intégrés par des revendications et des rôles personnalisés. Ils s'intègrent parfaitement avec API Gateway et les fonctions Cloud.
  • AWS Autorisations vérifiées :[ Un service de politique Cedar géré qui peut être utilisé pour centraliser les décisions d'autorisation en dehors de Lambda.

Vérification et conformité

Pour satisfaire aux exigences de conformité (SOC 2, HIPAA, RGPD), vous devez mettre en œuvre l'audit :

  • Activer cloud trail log[ pour toutes les actions de l'IAM et l'accès aux ressources.
  • Enregistrez chaque décision d'autorisation (autorisation/délai) avec l'identité de l'utilisateur, la ressource et l'horodatage. Utilisez une approche de logage structurée (JSON) et expédiez les journaux vers un SIEM comme Spunk ou ELK.
  • Annexer les examens réguliers d'accès[ où les affectations de rôles sont confirmées ou révoquées.
  • Utilisez outils de simulation de politiques (p. ex., AWS IAM Access Analyzer) pour valider que les politiques n'accordent que les autorisations prévues.

Conclusion

La mise en œuvre du contrôle d'accès basé sur les rôles dans les applications sans serveur ne consiste pas seulement à joindre une politique d'IAM. Il faut concevoir soigneusement les rôles, les stratégies de permission à grain fin et les points d'application centralisés tels que les autorisants API Gateway. En combinant IAM cloud-native avec l'autorisation de la couche d'application et le cache, vous pouvez obtenir à la fois la sécurité et les performances.