Sécuriser son application web sur AWS

Lorsque l’on déploie son application web sur AWS, il est nécessaire de sécuriser son utilisation.

On pense souvent qu’il s’agit de déployer tout dans AWS et que notre application est directement en ligne et sécurisée. Ce qui est faux. Si la protection DDOS au niveau 4 (TCP/UDP) est effectivement effectuée par Amazon Web Services, le niveau 7 doit quant à lui être géré par le client.

Je vous propose dans cet article de voir les différentes couches de sécurité que l’on peut mettre en place pour sécuriser son application web sur AWS.

J’ai décidé de partir d’une application 3 tiers classique, front/back/base de données, toutefois le modèle présenté reste valable pour des schémas applicatifs différents.

Sécurité de base

Avant de parler des services que l’on va pouvoir mettre en place pour améliorer la sécurité de son application web.

Différencier son réseau front et back

Comme dans un réseau classique en datacenter, dans AWS nous avons plusieurs zones réseau que nous pouvons configurer pour sécuriser au mieux son application.

Pour cela, il est possible de configurer différemment les subnets de ses VPC AWS pour différencier le réseau front/back.

De manière très simple, le réseau front aura une Internet Gateway directement connectée au VPC, permettant aux ressources déployées dedans d’utiliser des adresses IP publiques.

A contrario, en zone back, on déploiera une NAT Gateway, connectée la même Internet Gateway, ce qui permettra que les ressources déployées dans ces réseaux puissent accéder à Internet, mais ne seront pas accessibles depuis Internet, même si on leur assigne une adresse IP publique.

Restreindre les accès réseau

En plus des sous-réseaux, il est nécessaire de mettre en place des security groups les plus restreints possibles. Les security group permette de restreindre les protocoles disponibles ainsi que les adresses qui ont le droit d’y accéder (inbound) ou sont accessibles depuis la ressource (outbound).

De plus, il est aussi possible de mettre des limitations de protocoles et/ou d’adresse IP en utilisant les NACLs qui vont permettre de positionner ces accès au niveau du VPC.

Comme je le disais en introduction, au niveau de la couche 4 (transport), AWS pilote une protection DDOS de base : AWS Shield. Il est possible, moyennant un budget non négligeable de passer sur le Shield Advanced qui apporte des fonctionnalités supplémentaires.

Sécurité applicative

Nous avons vu la couche de sécurité native d’AWS, maintenant nous allons voir les couches que nous pouvons ajouter en amont de l’application.

AWS CloudFront

CloudFront est le CDN (Content Delivery Network) d’AWS.

Un CDN a deux rôles principaux :

• Délivrer la ressource depuis le serveur le plus rapide pour l’utilisateur
• Mettre en cache les ressources statiques

Contrairement aux ressources régionales, CloudFront exploite des réseaux en "edge locations" au lieu des régions. À l’heure où j’écris ces lignes, plus de 200 "edge location" sont disponibles.

CloudFront vous permet aussi d’augmenter le niveau de sécurité, car il vous permet :

• De découpler facilement la puissance, en cachant les ressources statiques, ce qui réduit l’efficacité de DDOS applicatif, CloudFront absorbant une grosse partie de la charge
• De mettre en place un WAF (dont je vous parle ensuite)
• De mettre en place des Lambda@Edge (dont je vous parle aussi ensuite)

Vous l’aurez compris, outre le découplage des ressources, CloudFront vous offre la possibilité d’augmenter le niveau de sécurité aisément.

AWS WAF

Un WAF (Web Application Firewall) est un composant que l’on peut retrouver régulièrement, y compris on premise.

Un WAF va se positionner en amont de vos ressources pour filtrer au niveau applicatif.

Par exemple, un WAF va permettre de bloquer les tentatives d’injections SQL ou le cross site scripting.

De même il est aussi possible de filtrer l’IP d’origine, pour par exemple faire du geoblocking (blocage géographique) ou empêcher l’accès aux ressources à travers d’un réseau VPN ou Tor.

Personnellement, je recommande la mise en place du Top 10 de l’OWASP (lien en anglais).

Dans le cas où vous ne voudriez pas gérer vous-même vos règles, il existe aussi des packages managés sur le marketplace, dont certains maintenus par des sociétés qui ont fait leurs preuves sur la sécurité web.

A noter que le WAF AWS peut tout aussi bien se connecter directement sur un ALB.

Lambda@Edge

AWS Lambda est un service permettant d’exécuter du code en mode serverless. Je ne présenterais pas ce service dans ce billet.

Toutefois, sachez qu’il existe une version @Edge de lambda, cette version permet, comme son nom l’indique, d’exécuter du code dans des fonctions lambda en edge locations.

L’intérêt est que l’on peut interfacer ces fonctions avec CloudFront pour altérer le fonctionnement normal du flux applicatif.

Ces ajouts permettent par exemple de faire du bot management aisément, que ce soit via des solutions internes ou en exploitant des solutions externes comme DataDome.

Combiner Lambda@Edge et AWS WAF pour créer un honeypot

Il est aussi possible de combiner les deux services mentionnés précédemment pour créer un mini honeypot.

Le principe d’un honeypot (ou pot de miel dans sa traduction française) est comme son nom l’indique d’attirer les bots ou malwares.

L’idée dans le modèle que j’ai en tête est de se baser sur la présence d’un entête ou d’un champ par exemple. On peut imaginer un champ de formulaire "hidden", avec un identifiant qui fait qu’un bot va essayer de le remplir, mais qui nous est en réalité inutile.

Par exemple un champ "civilité". Ce dernier étant caché pour un utilisateur humain, il ne tentera pas de le remplir. Néanmoins, un robot tentera régulièrement de remplir ces champs "standard".

À l’aide d’une Lambda@Edge, si ce champ est rempli, il suffit de bloquer l’adresse IP associée sur le WAF.

Ainsi vous avez attiré et bloqué un bot aussitôt : un honeypot.

En conclusion

Ce billet n’a pas pour but de faire de vous des experts en sécurité, mais simplement de vous exposer les solutions disponibles pour protéger une application standard sur Internet.

Comme nous avons pu le voir, il existe de multiples solutions disponibles, que ce soit sur la couche 4 ou la couche 7 du modèle OSI.

Il faut garder en tête que chaque application est unique, et qu’il est parfois nécessaire d’adapter les protections en place en fonction du comportement attendu.