Nexity : Centralisation et sécurisation de l’accès aux API à l’échelle

Cet article a été rédigé par Christophe Liefooghe, Responsable du Centre de Compétence Cloud (CCoE) chez Nexity et en collaboration avec Abderrahim Benazza, Senior Solutions Architect pour le segment Financial Services d’AWS France.

Avec un chiffre d’affaires de 4,6 milliards d’euros en 2021, Nexity, premier groupe immobilier français intégré, est présent sur tout le territoire et intervient sur l’ensemble des métiers de la promotion et des services. Son organisation en plateforme de services permet de répondre à tous les besoins de ses clients, particuliers, entreprises, institutionnels et collectivités.

Nexity a débuté son histoire avec AWS en 2016, et après une série de nombreux projets réussies en quelques mois, elle décide d’entamer une migration importante de tout son patrimoine applicatif et ferme ainsi en 2019 ses deux datacenters.

Avec plus de 400 applications métiers qui ont été migrées en un an via une stratégie « Lift and Shift », les équipes en charge des Solutions Business et des Technologie ont depuis entamé une transformation importante dans le cloud en utilisant les services managés AWS pour accroitre l’agilité et améliorer l’efficacité opérationnelle. A titre d’exemple, les bases de données initialement sur des instances EC2 ont été migrées sur Amazon Relational Database Service, les bureaux virtuels (VDI : virtual desktop infrastructure) vers Amazon Appstream 2.0 et Amazon WorkSpaces, ainsi que le remplacement de ses appliances de sécurité en DMZ (Load Balancer, WAF, …) par des solutions cloud native : Amazon CloudFront, AWS WAF, Amazon API Gateway

Challenge

Pour donner accès aux différentes applications, Nexity a choisi une approche décentralisée, où chaque application et/ou compte AWS dispose de son propre mécanisme d’exposition publique via le couplage suivant dans cet exemple :

Cela apporte un avantage significatif en terme de cloisonnement des différentes ressources, facilite la délégation ainsi que refacturation interne, mais également la gestion des accès aux ressources à travers le service AWS Identity and Access Management (IAM).

Il est cependant nécessaire de prendre en compte toute la chaîne de sécurisation des applications de bout en bout. Notamment avec un nombre d’applications grandissant, d’environnement, de comptes AWS, et de demandes d’accès. Dans cette optique, et afin de faciliter la gouvernance et la sécurité de ces expositions publiques, Nexity a souhaité revoir la solution et avec l’aide des équipes AWS, a pu construire un nouveau modèle.

Solution

En effet, en opposition à une architecture décentralisée, les équipes de sécurité Nexity ont souhaité mettre en place une zone dédiée (DMZ) afin de centraliser les expositions publiques et ainsi renforcer la sécurité des ressources qui sont hébergées sur AWS en s’assurant que tout les flux entrants soient sécurisés, filtrés, et analysés (en utilisant le service AWS Network Firewall), mais également, par des règles de détection/prévention d’intrusion (IDS/IPS).

La nouvelle architecture est illustrée dans le diagramme suivant :

Nous détaillerons dans cet article deux exemples qui illustrent le pattern d’exposition d’API avec authentification par certificat x509 ou par jeton JWT / OAuth2.

Sécurisation des API avec CloudFront et Lambda@Edge

L’architecture ci-dessous permet de centraliser les flux entrants et sortants via un compte et VPC dédié. Dans cet exemple avec CloudFront et une API Gateway, celle-ci est déployée sur un compte dédié aux expositions, et le backend est hébergé sur un autre compte dédié aux environnements applicatifs.

Ce pattern est basé sur l’utilisation des services CloudFront et d’une fonction Lambda@Edge pour s’assurer que seules les requêtes avec un jeton JWT valide puissent appeler l’API. Ci-dessous la séquence des requêtes :

• La requête arrive sur la distribution CloudFront,
• La Lambda@Edge s’exécute et vérifie la validité du token JWT (Dans l’exemple, Amazon Cognito mais on pourrait utiliser un autre Identity Provider bien entendu),
• L’origine CloudFront surcharge la requête avec l’ajout d’un Header et forward celle-ci vers l’Application Load Balancer dans le VPC du compte DMZ,
• L’ALB limite les accès en provenance de CloudFront uniquement via les préfixes gérés par AWS et contrôle le header de la requête,
• Le flux transite via le service AWS Network Firewall,
• Il est ensuite redirigé vers Endpoint execute API,
• L’API Gateway, en mode privé, redirige ensuite le trafic vers le backend à l’aide du VPC Link,
• Via le processus de rotation de secrets de AWS Secrets Manager, périodiquement, la Lambda se charge de mettre à jour le custom header sur CloudFront et l’ALB.

Sécurisation des API avec authentification mutuelle (mTLS)

L’exemple ci-dessus est similaire au scénario précédent mais l’authentification OAuth 2 est remplacée par un certificat x509. Il est pour cela nécessaire d’utiliser la fonctionnalité « Mutual TLS Authentification » d’API Gateway.

• La requête arrive sur l’API Publique en utilisant le service API Gateway,
• Une authentification est faite en utilisant le mTLS,
• Le flux transite via le service AWS Network Firewall,
• Le flux est ensuite redirigé vers l’API,
• L’API Gateway, en mode privé, redirige ensuite le trafic vers le backend à l’aide du VPC Link.

Conclusion

La Landing Zone de Nexity a évoluée dans le temps afin de s’adapter à l’utilisation du cloud et la mise à l’échelle, nécessitant parfois des adaptations et des ajustements, d’une manière itérative, incrémentale et agile. Avec ces modèles décentralisés, Nexity s’appui aujourd’hui sur des patterns d’architectures sécurisées, scalables, réutilisables, et déployables sur l’ensemble des régions AWS. Cela se traduit par :

• Un gain de temps sur le design des solutions,
• Un gain de temps sur les déploiements puisque les patterns sont industrialisés et réutilisables sous forme de modules terraform,
• Une simplification des schémas d’architecture car les solutions sont assemblées à partir patterns déjà connus et documentés.

Lectures complémentaires :

• Whitepaper : Building a Scalable and Secure Multi-VPC AWS Network Architecture: Centralized egress to internet & Centralized access to VPC private endpoints
• Article (en anglais) : Authorization@Edge – How to Use Lambda@Edge and JSON Web Tokens to Enhance Web Application Security
• Témoignage : Nexity propulse sa Direction des Solutions et Innovations Numériques dans le cloud avec AWS