Les microservices sont souvent déployés dans des sous-réseaux privés au sein d'un Amazon Virtual Private Cloud (VPC) afin d'assurer leur isolation et de les protéger de tout accès direct depuis Internet. Deux approches sont couramment utilisées pour configurer leur accès externe :
- Private Link : une fonctionnalité réseau qui s'appuie sur des points de terminaison d'interface pour exposer en toute sécurité des ressources VPC privées à API Gateway, sans les rendre accessibles depuis Internet. Le trafic reste ainsi cantonné au réseau AWS.
- HTTP Integration (exposée sur Internet) : permet à API Gateway d'acheminer les requêtes vers des points de terminaison HTTP publics, comme un Application Load Balancer (ALB) exposé sur Internet, rendant ainsi les services accessibles via une adresse publique.
Nous nous concentrerons ici sur la sécurisation de la seconde approche — un ALB exposé sur Internet placé derrière une API Gateway. Plus précisément, nous verrons comment restreindre l'accès direct à l'ALB public, tout en permettant aux clients de confiance d'interagir avec l'application uniquement via l'API Gateway.
Présentation du problème
Lorsqu'un ALB exposé sur Internet est placé derrière une API Gateway via une intégration HTTP, il devient publiquement accessible. Si les clients de confiance se connectent bien à l'application via l'API Gateway, cette configuration introduit un risque de sécurité majeur : le point de terminaison public de l'ALB peut être atteint directement, contournant ainsi les fonctionnalités de sécurité de l'API Gateway.
Cette absence de restriction ouvre la porte à plusieurs vulnérabilités. Pour préserver la sécurité et l'intégrité de votre application, il est essentiel d'empêcher tout accès direct à l'ALB. En faisant transiter l'ensemble du trafic par l'API Gateway, vous pouvez appliquer des mécanismes de sécurité essentiels : validation des requêtes, throttling, authentification et autorisation. Sans ces protections, des attaquants peuvent exploiter des failles, contourner les mécanismes d'authentification et saturer les services backend, ouvrant la voie à des attaques par déni de service (DoS).
AWS propose une solution reposant sur REST API Gateway et AWS Web Application Firewall (WAF) pour bloquer les requêtes dépourvues d'un en-tête unique, mais cette approche augmente la complexité et les coûts. À noter que pour les cas d'usage nécessitant des mesures de sécurité avancées telles que la protection contre les injections SQL, le cross-site scripting (XSS) ou la mitigation des bots, AWS WAF reste un outil incontournable.
Dans cet article, nous présentons une alternative plus simple et économique. En combinant en-têtes personnalisés et conditions de règles ALB, on obtient le même niveau de sécurité sans recourir à AWS WAF. Cette méthode fonctionne aussi bien avec les API Gateway REST qu'avec les API Gateway HTTP, et réduit considérablement la charge opérationnelle.
**Solution proposée**
Cette approche s'affranchit d'AWS WAF en exploitant les capacités de routage par contenu de l'ALB. Elle repose sur les étapes suivantes :
- Ajouter un en-tête personnalisé et sa valeur aux requêtes HTTP dans API Gateway.
- Configurer les règles de l'ALB pour valider cet en-tête. Seules les requêtes contenant l'en-tête et la valeur attendus correspondront aux règles ALB ciblées ; toutes les autres seront prises en charge par la règle par défaut.
- Paramétrer la règle par défaut de l'ALB pour qu'elle retourne un code d'erreur HTTP, par exemple 403 Forbidden.
Voici une vue d'ensemble de l'architecture :
Flux des requêtes HTTP.
**Étapes détaillées de mise en œuvre**
Étape 1 : Définir un en-tête personnalisé dans API Gateway
Pour une API Gateway HTTP, utilisez les mappings de paramètres pour modifier les requêtes envoyées à l'intégration ALB.
- Accédez à la console API Gateway.
- Sélectionnez votre API HTTP.
- Dans la section Integrations, ouvrez Manage Integrations.
- Créez un mapping de paramètres pour ajouter l'en-tête personnalisé et sa valeur.
Configuration du mapping de paramètres.
Si votre API Gateway est de type REST, suivez ce lien pour ajouter un en-tête HTTP personnalisé.
Étape 2 : Configurer les règles de l'ALB
- Ouvrez la configuration de l'ALB dans la console EC2.
- Pour chaque règle de listener (à l'exception de la règle par défaut) :
- Ajoutez une condition AND.
- Choisissez HTTP header comme type de condition.
- Saisissez le nom de l'en-tête et la valeur attendue.
3. Paramétrez la règle par défaut pour qu'elle retourne une réponse d'erreur HTTP (par exemple, 403 Forbidden).
Conditions et actions des règles ALB.
Pour en savoir plus sur le routage par contenu avec l'ALB, consultez cet article du blog AWS.
Étape 3 : Tester la configuration
- Envoyez une requête à l'ALB sans l'en-tête personnalisé. Vérifiez qu'elle déclenche la règle par défaut de l'ALB et renvoie la réponse d'erreur.
- Envoyez une requête via l'API Gateway. Vérifiez qu'elle est bien acheminée vers l'application.
**Conclusion**
Cette solution simplifie l'architecture en supprimant la dépendance à AWS WAF. En tirant parti des capacités de routage par contenu intégrées à l'ALB, elle offre un moyen sûr et efficace de restreindre l'accès direct à votre Application Load Balancer.
Pour en savoir plus ou découvrir nos services, n'hésitez pas à nous contacter ici.