5 bonnes pratiques pour concevoir un contrôle d’accès moderne pour les applications cloud

Récemment, j’ai rencontré Or Weis, ambassadeur Snyk, pour discuter du contrôle d’accès dans le cloud. Entrepreneur installé à Tel Aviv, Or a fondé Permit.io, une solution qui permet aux développeurs d’intégrer en quelques minutes des autorisations et un contrôle d’accès à n’importe quel produit, sans avoir à les reconstruire sans cesse.

Au cours de notre échange, nous avons abordé différents sujets, notamment :

• Pourquoi il est si important d’utiliser systématiquement des contrôles d’accès modernes dans le cloud

• Pourquoi le RBAC ne suffit pas

• La sécurité et la conformité

• Les différentes couches de contrôle d’accès dans le cloud

• La cascade IAM

• Réduire votre surface d’attaque lors de la mise en place du contrôle d’accès

Nous avons également parlé des bonnes pratiques en matière de contrôle d’accès que vous pouvez commencer à appliquer à vos applications cloud. Dans cet article, nous allons les récapituler en nous appuyant directement sur notre longue conversation. Pour en savoir plus, je vous recommande de regarder l’échange dans son intégralité :

Play Video: Building Modern Access-Control for Cloud Applications with Or Weis | SnykLIVE Recording

5 bonnes pratiques pour un contrôle d’accès moderne dans le cloud

Que vous souhaitiez concevoir votre propre contrôle d’accès, en vous appuyant sur l’open source ou sur des outils propriétaires, voici cinq bonnes pratiques pour créer une solution à la fois pérenne et fiable, qui établira des garde-fous pour stabiliser et protéger votre système.

1. Dissocier le code des politiques

2. Concevoir des mises à jour événementielles (dissocier les données du code)

3. Concevoir un back-office pour les parties prenantes

4. Créer une interface pour les clients

5. Mettre en œuvre GitOps

1. Dissocier le code des politiques

La première bonne pratique, et probablement la plus importante, consiste à dissocier les politiques du code. On voit souvent des équipes intégrer la logique d’autorisation directement à la logique de l’application. Résultat : du code spaghetti, avec des conditions « if » qui interrogent à la fois la base de données et d’autres sources pour la logique d’autorisation, tout en interrogeant en parallèle les éléments nécessaires à la logique de l’application. Avec le temps, les deux finissent généralement par s’entremêler. À mesure que les développeurs ajoutent de nouvelles conditions, il devient presque impossible de distinguer, dans une condition « if », ce qui relève de l’autorisation et ce qui relève de l’application.

Ainsi, lorsque vous voulez mettre à niveau votre couche d’autorisation ou l’application elle-même, vous devez examiner le code ligne par ligne et le remanier. C’est là que commence le cauchemar du refactoring. Pour éviter cela, dissociez les politiques du code. Passez à la politique en tant que code (PaC) et gérez ce code séparément, idéalement dans un microservice distinct que les autres composants de l’application pourront interroger pour obtenir la logique dont ils ont besoin.

Les développeurs qui découvrent ce domaine peuvent naturellement se poser les questions suivantes :

1. Qui contrôle l’accès à ce service ?

2. Qu’est-ce qui vient en premier : l’authentification ou l’application ?

Pour être franc, il s’agit d’un vaste domaine d’une grande complexité, aux ramifications multiples, appelé autorisation de l’autorisation. En résumé, vous pouvez limiter le contrôle d’accès de la couche suivante et, bien souvent, le réduire à la seule authentification. Ainsi, vos microservices peuvent se connecter au microservice d’autorisation simplement en présentant une identité que celui-ci vérifie. Les différentes couches complexifient les choses, mais la plupart des outils tentent de résoudre ce problème à votre place ou, à tout le moins, d’en prendre en charge une grande partie.

N’oublions pas que, dans l’idéal, nous voulons créer un microservice dédié à l’autorisation. Ce microservice n’a pas besoin d’être parfait. Au départ, il peut être aussi simple qu’une fonction qui renvoie toujours « true ». Nous ne voulons pas tout construire dès le premier jour, mais nous devons prévoir des emplacements bien connectés que nous pourrons améliorer progressivement à mesure que de nouveaux besoins apparaissent. Qu’il s’agisse d’une fonction Lambda, d’un petit conteneur ou de tout autre composant, il doit pouvoir évoluer indépendamment et être facile à remanier lorsque de nouvelles exigences se présentent.

2. Concevoir des mises à jour événementielles (dissocier les données du code)

La deuxième bonne pratique consiste à adopter une approche événementielle. Les systèmes complexes s’appuient sur des politiques complexes qui évoluent avec l’application elle-même. Si votre application est conçue dès le départ pour fonctionner par événements, il sera plus facile de gérer les mises à jour à venir.

Prenons un exemple. Imaginez que vous vouliez appliquer une règle simple : seuls les utilisateurs qui ont payé pour une fonctionnalité peuvent l’utiliser. Cette information ne se trouve plus dans votre base de données, ni même dans votre application. Elle provient d’un service tiers comme Stripe, Chargebee ou PayPal. Nous devons donc pouvoir propager en temps réel les changements provenant de ces services, afin qu’ils soient pris en compte par notre couche d’autorisation.

Pour ce faire, la meilleure approche consiste à adopter un modèle événementiel. En pratique, cela signifie être en mesure de recevoir des webhooks de ces services ou composants externes et de les propager jusqu’à notre couche d’autorisation. C’est ce qu’on appelle « dissocier les données du code » ; c’est aussi important que de dissocier les politiques du code.

3. Un back-office pour les parties prenantes et 4. Une interface pour les clients

Nous savons que nous aurons des clients et d’autres parties prenantes (comme un chef de produit, des entreprises de sécurité, etc.) et que ces personnes voudront disposer d’interfaces pour gérer le contrôle d’accès. Même si nous n’avons pas à les créer dès le premier jour, nous devons être prêts à les développer et à les fournir lorsque les besoins se présenteront.

Nous voulons donc disposer d’un back-office permettant aux différentes parties prenantes de gérer l’application, ainsi que d’interfaces à proposer aux clients pour qu’ils puissent inviter eux-mêmes des utilisateurs, attribuer des rôles et même configurer des politiques. Comme la plupart des ingénieurs en conviendront, le meilleur service est celui qui permet aux utilisateurs de se débrouiller en toute autonomie.

5. Mettre en œuvre GitOps

Enfin, revenons à la politique en tant que code : simplifiez la sécurité avec GitOps. Il s’agit de gérer des règles et des instructions complexes dans un environnement en constante évolution et impliquant de nombreuses parties prenantes. Le meilleur moyen d’y parvenir est de passer par le code. Tout comme nous avons l’infrastructure en tant que code et la sécurité en tant que code, nous devrions aussi adopter la politique en tant que code.

En gérant vos politiques sous forme de code distinct, idéalement dans un framework adapté, au sein d’un dépôt Git, vous pouvez gérer efficacement les versions, les tests, les benchmarks et les revues de code. Vous évitez ainsi de réinventer la roue pour gérer vos politiques et les connecter à votre système.

Misez toujours sur la modernité

Gardez ces cinq bonnes pratiques à l’esprit lorsque vous commencez à concevoir votre solution. En anticipant ces besoins, vous vous épargnerez des mois de refactoring par la suite.

Enfin, un grand merci à Or Weis d’avoir échangé avec moi et partagé son expertise sur le sujet. Pour toute question, nous vous conseillons de contacter Or Weis sur Twitter ou LinkedIn, ou de rejoindre le serveur Discord de la communauté DevSecCon pour lui poser directement vos questions.