Comment protéger deux micro-frontends avec des besoins d'accès différents sur un backend AWS

Équilibrer la sécurité et l'accessibilité dans l'architecture micro-frontend AWS

La conception d'architectures cloud sécurisées et évolutives implique souvent de trouver un équilibre entre accessibilité et accès restreint. Dans votre configuration AWS, vous disposez de deux micro-frontends avec des exigences d'accès uniques. FE-A doit être limité à une adresse IP statique spécifique, tandis que FE-B doit être accessible publiquement. Répondre simultanément à ces besoins peut constituer un défi. 😅

Le défi se pose lors de la configuration des groupes de sécurité dans EC2. Si vous autorisez l’accès à 0.0.0.0, les deux interfaces deviennent accessibles au public, compromettant la sécurité de FE-A. D'un autre côté, restreindre l'accès à une seule adresse IP statique refuse la disponibilité publique de FE-B. Cela crée un équilibre complexe entre ouverture et sécurité.

Bien qu'une fonction Lambda permettant de mettre à jour dynamiquement les plages IP puisse sembler viable, elle introduit une surcharge supplémentaire et ne constitue pas une solution optimale à long terme. Par exemple, cela peut augmenter les coûts et la complexité au fil du temps. De plus, la gestion des mises à jour fréquentes des groupes de sécurité peut s'avérer fastidieuse et sujette aux erreurs.

Il est essentiel de trouver une solution rentable qui réponde à ces exigences. L’objectif est de protéger FE-A tout en garantissant que FE-B reste accessible à l’échelle mondiale sans introduire de complexités inutiles. Voyons comment y parvenir en utilisant les meilleures pratiques AWS. 🚀

Stratégies pour sécuriser les micro-frontends avec AWS

Le premier script exploite les capacités d'AWS Web Application Firewall (WAF) pour appliquer des politiques d'accès distinctes pour deux micro-frontends. En créant une WebACL, des règles IP spécifiques sont appliquées à FE-A pour autoriser uniquement le trafic provenant d'un IP statique, garantissant qu’il reste un système fermé. Pour FE-B, une règle distincte autorise l’accès du public. Cette approche centralise le contrôle d'accès au niveau de la couche application, ce qui la rend idéale pour gérer efficacement le trafic sans modifier les groupes de sécurité EC2 sous-jacents. Par exemple, vous pouvez limiter FE-A à un réseau de bureau tout en permettant à FE-B de rester accessible à l'échelle mondiale, garantissant à la fois la sécurité de l'entreprise et le confort de l'utilisateur. 🌍

Le WebACL est ensuite associé à un Application Load Balancer (ALB), garantissant que tout le trafic passant par l'ALB est filtré selon ces règles. La commande waf_client.create_web_acl est essentiel dans la définition des règles, tandis que waf_client.associate_web_acl relie la WebACL à la ressource. Cette configuration est hautement évolutive et permet des ajustements futurs, tels que l'ajout de nouvelles adresses IP ou la modification des politiques d'accès, avec un minimum d'effort. Les fonctionnalités de surveillance telles que les métriques CloudWatch peuvent également suivre l'efficacité des règles, fournissant ainsi des informations précieuses sur les modèles de trafic.

En revanche, la solution basée sur Lambda met à jour dynamiquement les règles du groupe de sécurité EC2. Ce script récupère les plages IP spécifiques à votre région AWS et les configure en tant que règles d'entrée dans le groupe de sécurité. La fonction ec2.authorize_security_group_ingress ajoute ou met à jour les plages IP autorisées, permettant à FE-B d'être accessible au public tout en maintenant un contrôle strict pour FE-A. Cette approche est particulièrement utile dans les environnements où les exigences IP changent fréquemment, comme les configurations de développement basées sur le cloud ou les bureaux d'entreprise changeants. Par exemple, si une nouvelle succursale est créée, vous pouvez automatiquement ajouter son adresse IP à la liste blanche sans intervention manuelle. 🏢

La fonction Lambda, combinée à un événement CloudWatch planifié, automatise ces mises à jour quotidiennement, réduisant ainsi les frais administratifs. Même si cette approche ajoute de la complexité, elle permet un contrôle précis du trafic. Les tests unitaires inclus dans le script valident la fonctionnalité, garantissant que les règles de sécurité sont appliquées correctement sans introduire d'erreurs. Que vous choisissiez WAF ou Lambda, les deux méthodes privilégient la rentabilité et la flexibilité, équilibrant le besoin d'accès public et restreint. En fin de compte, ces solutions démontrent la polyvalence d'AWS pour répondre à diverses exigences tout en maintenant une sécurité robuste. 🔒

# Step 1: Define IP restrictions in AWS WAF
# Create a WebACL to allow only specific IP ranges for FE-A and public access for FE-B.
import boto3
waf_client = boto3.client('wafv2')
response = waf_client.create_web_acl(    Name='MicroFrontendAccessControl',    Scope='REGIONAL',    DefaultAction={'Allow': {}},    Rules=[        {            'Name': 'AllowSpecificIPForFEA',            'Priority': 1,            'Action': {'Allow': {}},            'Statement': {                'IPSetReferenceStatement': {                    'ARN': 'arn:aws:wafv2:region:account-id:ipset/ipset-id'                }            },            'VisibilityConfig': {                'SampledRequestsEnabled': True,                'CloudWatchMetricsEnabled': True,                'MetricName': 'AllowSpecificIPForFEA'            }        },        {            'Name': 'AllowPublicAccessForFEB',            'Priority': 2,            'Action': {'Allow': {}},            'Statement': {'IPSetReferenceStatement': {'ARN': 'arn:aws:wafv2:region:account-id:ipset/ipset-id-for-public'}},            'VisibilityConfig': {                'SampledRequestsEnabled': True,                'CloudWatchMetricsEnabled': True,                'MetricName': 'AllowPublicAccessForFEB'            }        }    ],    VisibilityConfig={        'SampledRequestsEnabled': True,        'CloudWatchMetricsEnabled': True,        'MetricName': 'MicroFrontendAccessControl'    })
print("WebACL created:", response)
# Step 2: Associate the WebACL with your Application Load Balancer
response = waf_client.associate_web_acl(    WebACLArn='arn:aws:wafv2:region:account-id:webacl/webacl-id',    ResourceArn='arn:aws:elasticloadbalancing:region:account-id:loadbalancer/app/load-balancer-name')
print("WebACL associated with Load Balancer:", response)

# Import required modules
import boto3
import requests
# Step 1: Fetch public IP ranges for your region
def get_ip_ranges(region):
    response = requests.get("https://ip-ranges.amazonaws.com/ip-ranges.json")
    ip_ranges = response.json()["prefixes"]
    return [prefix["ip_prefix"] for prefix in ip_ranges if prefix["region"] == region]
# Step 2: Update the security group
def update_security_group(security_group_id, ip_ranges):
    ec2 = boto3.client('ec2')
    permissions = [{"IpProtocol": "tcp", "FromPort": 80, "ToPort": 80, "IpRanges": [{"CidrIp": ip} for ip in ip_ranges]}]
    ec2.authorize_security_group_ingress(GroupId=security_group_id, IpPermissions=permissions)
# Step 3: Lambda handler
def lambda_handler(event, context):
    region = "us-west-2"
    security_group_id = "sg-0123456789abcdef0"
    ip_ranges = get_ip_ranges(region)
    update_security_group(security_group_id, ip_ranges)
    return {"statusCode": 200, "body": "Security group updated successfully"}

import unittest
from unittest.mock import patch
class TestSecurityConfigurations(unittest.TestCase):
    @patch("boto3.client")
    def test_update_security_group(self, mock_boto3):
        mock_ec2 = mock_boto3.return_value
        ip_ranges = ["192.168.0.0/24", "203.0.113.0/24"]
        update_security_group("sg-0123456789abcdef0", ip_ranges)
        mock_ec2.authorize_security_group_ingress.assert_called()
    def test_get_ip_ranges(self):
        region = "us-west-2"
        ip_ranges = get_ip_ranges(region)
        self.assertIsInstance(ip_ranges, list)
if __name__ == "__main__":
    unittest.main()

Optimisation de la sécurité et de l'accessibilité pour les applications micro-frontend dans AWS

Un autre moyen efficace de relever le défi de l'équilibre entre l'accès restreint et public dans votre architecture micro-frontend consiste à tirer parti des fonctionnalités intégrées d'AWS Amplify. Amplify simplifie l'hébergement et le déploiement tout en fournissant des outils pour configurer les API backend en toute sécurité. Pour FE-A, vous pouvez mettre en œuvre un contrôle d'accès au réseau en limitant ses points de terminaison d'API back-end à des adresses IP spécifiques à l'aide d'une passerelle API AWS. Cette configuration garantit que seules les adresses IP statiques prédéfinies peuvent interagir avec le backend, tandis que les points de terminaison de FE-B peuvent rester sans restriction pour l'accès public. Cela améliore non seulement la sécurité, mais s’intègre également de manière transparente aux flux de travail CI/CD d’Amplify. 🌐

Une autre considération consiste à utiliser Amazon CloudFront avec des stratégies d'accès à l'origine personnalisées. CloudFront peut acheminer le trafic vers le backend approprié en fonction du chemin de l'URL, servant ainsi de gardien pour vos micro-frontends. Le trafic FE-A peut être filtré via CloudFront à l'aide d'une stratégie de demande d'origine qui vérifie les restrictions IP ou les en-têtes spécifiques. Par exemple, une entreprise déployant un outil interne via FE-A peut ajouter un filtre de plage IP tout en rendant FE-B disponible à l'échelle mondiale pour les utilisateurs finaux. Cette approche optimise à la fois l'évolutivité et les performances, en particulier pour les applications nécessitant une distribution mondiale. 🚀

Enfin, la mise en œuvre d'AWS Cognito pour l'authentification des utilisateurs ajoute une couche de sécurité supplémentaire. FE-A peut être verrouillé derrière un système de connexion nécessitant une authentification de l'utilisateur avec des rôles ou des groupes spécifiques, tandis que FE-B peut utiliser un mécanisme d'authentification plus léger, voire aucun, pour l'accès public. En combinant l'authentification et les restrictions d'accès au réseau, vous obtenez un modèle de sécurité robuste adapté aux besoins de chaque micro-frontend. Cette stratégie est particulièrement efficace pour les startups et les PME à la recherche de solutions cloud abordables, évolutives et sécurisées. 🔐