Ako chrániť dva mikro-frontendy s rôznymi potrebami prístupu na backende AWS

Vyváženie bezpečnosti a dostupnosti v architektúre AWS Micro-Frontend

Návrh bezpečných a škálovateľných cloudových architektúr často zahŕňa vyváženie dostupnosti a obmedzeného prístupu. Vo vašom nastavení AWS máte dva mikro-frontendy s jedinečnými požiadavkami na prístup. FE-A je potrebné obmedziť na konkrétnu statickú IP, zatiaľ čo FE-B by mala byť verejne prístupná. Súčasné riešenie týchto potrieb môže predstavovať problém. 😅

Problém vzniká pri konfigurácii bezpečnostných skupín v EC2. Ak povolíte prístup k 0.0.0.0, obe rozhrania sa stanú verejne prístupnými, čo ohrozí bezpečnosť FE-A. Na druhej strane, obmedzenie prístupu k jedinej statickej IP popiera verejnú dostupnosť pre FE-B. To vytvára komplexnú rovnováhu medzi otvorenosťou a bezpečnosťou.

Aj keď sa funkcia Lambda na dynamickú aktualizáciu rozsahov IP môže zdať životaschopná, predstavuje ďalšiu réžiu a nie je optimálnym dlhodobým riešením. Časom to môže napríklad zvýšiť náklady a zložitosť. Správa častých aktualizácií bezpečnostných skupín môže byť navyše ťažkopádna a náchylná na chyby.

Rozhodujúce je nájsť cenovo efektívne riešenie, ktoré spĺňa tieto požiadavky. Cieľom je chrániť FE-A a zároveň zabezpečiť, aby FE-B zostal celosvetovo dostupný bez zavádzania zbytočných komplikácií. Poďme preskúmať, ako to dosiahnuť pomocou osvedčených postupov AWS. 🚀

Stratégie na zabezpečenie mikro-frontend s AWS

Prvý skript využíva možnosti AWS Web Application Firewall (WAF) na presadzovanie odlišných prístupových politík pre dva mikrofrontendy. Vytvorením WebACL sa na FE-A aplikujú špecifické pravidlá IP, ktoré povolia iba prenos z určeného statická IP, čím sa zabezpečí, že zostane uzavretým systémom. Pre FE-B povoľuje prístup verejnosti samostatné pravidlo. Tento prístup centralizuje riadenie prístupu na aplikačnej vrstve, vďaka čomu je ideálny na efektívne riadenie prevádzky bez úpravy základných bezpečnostných skupín EC2. Môžete napríklad obmedziť FE-A na kancelársku sieť a zároveň umožniť, aby FE-B zostalo globálne dostupné, čím sa zabezpečí firemná bezpečnosť aj pohodlie používateľa. 🌍

WebACL sa potom priradí k ALB (Application Load Balancer), čím sa zabezpečí, že všetka prevádzka prechádzajúca cez ALB bude filtrovaná podľa týchto pravidiel. Príkaz waf_client.create_web_acl je kľúčová pri definovaní pravidiel, pričom waf_client.associate_web_acl prepojí WebACL so zdrojom. Toto nastavenie je vysoko škálovateľné a umožňuje budúce úpravy, ako je pridávanie nových IP adries alebo úprava prístupových politík, s minimálnym úsilím. Funkcie monitorovania, ako sú metriky CloudWatch, môžu tiež sledovať účinnosť pravidiel a poskytujú cenné informácie o vzorcoch návštevnosti.

Na rozdiel od toho riešenie založené na Lambda dynamicky aktualizuje pravidlá bezpečnostnej skupiny EC2. Tento skript načíta rozsahy IP špecifické pre vašu oblasť AWS a nakonfiguruje ich ako pravidlá vstupu v skupine zabezpečenia. Funkcia ec2.authorize_security_group_ingress pridáva alebo aktualizuje povolené rozsahy IP, čím umožňuje, aby bol FE-B verejne prístupný pri zachovaní prísnej kontroly pre FE-A. Tento prístup je užitočný najmä v prostrediach s často sa meniacimi požiadavkami na IP, ako sú napríklad cloudové vývojové nastavenia alebo meniace sa podnikové kancelárie. Napríklad, ak je zriadená nová pobočka, môžete automaticky pridať jej IP do zoznamu povolených bez manuálneho zásahu. 🏢

Funkcia Lambda v kombinácii s naplánovanou udalosťou CloudWatch automatizuje tieto aktualizácie denne, čím znižuje administratívnu réžiu. Aj keď tento prístup zvyšuje zložitosť, poskytuje jemnú kontrolu nad premávkou. Testy jednotiek zahrnuté v skripte overujú funkčnosť a zabezpečujú správne uplatňovanie bezpečnostných pravidiel bez zavádzania chýb. Či už si vyberiete WAF alebo Lambda, obe metódy uprednostňujú nákladovú efektívnosť a flexibilitu, pričom vyvažujú potrebu verejného a obmedzeného prístupu. V konečnom dôsledku tieto riešenia demonštrujú všestrannosť AWS pri plnení rôznych požiadaviek pri zachovaní robustnej bezpečnosti. 🔒

# 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()

Optimalizácia zabezpečenia a dostupnosti pre aplikácie Micro-Frontend v AWS

Ďalším efektívnym spôsobom, ako vyriešiť problém vyváženia obmedzeného a verejného prístupu vo vašej mikrofrontendovej architektúre, je využitie integrovaných funkcií AWS Amplify. Amplify zjednodušuje hosťovanie a nasadenie a zároveň poskytuje nástroje na bezpečnú konfiguráciu backendových API. Pre FE-A môžete implementovať riadenie prístupu k sieti obmedzením koncových bodov koncového rozhrania API na konkrétne adresy IP pomocou brány AWS API. Toto nastavenie zaisťuje, že s backendom môžu interagovať iba preddefinované statické adresy IP, zatiaľ čo koncové body FE-B môžu zostať neobmedzené pre verejný prístup. To nielen zvyšuje bezpečnosť, ale tiež sa bezproblémovo integruje s pracovnými postupmi CI/CD Amplify. 🌐

Ďalšou úvahou je použitie Amazon CloudFront s vlastnými pravidlami prístupu k pôvodu. CloudFront dokáže nasmerovať návštevnosť do príslušného backendu na základe cesty URL a slúži ako strážca pre vaše mikrofrontendy. Prenos FE-A je možné filtrovať cez CloudFront pomocou zásady požiadavky na pôvod, ktorá kontroluje obmedzenia IP alebo špecifické hlavičky. Napríklad podnik nasadzujúci interný nástroj prostredníctvom FE-A môže pridať filter rozsahu IP a zároveň sprístupniť FE-B koncovým používateľom globálne. Tento prístup optimalizuje škálovateľnosť aj výkon, najmä pre aplikácie vyžadujúce globálnu distribúciu. 🚀

A napokon, implementácia AWS Cognito na autentifikáciu používateľov pridáva ďalšiu vrstvu zabezpečenia. FE-A môže byť uzamknutý za prihlasovacím systémom vyžadujúcim autentifikáciu používateľa so špecifickými rolami alebo skupinami, zatiaľ čo FE-B môže použiť ľahší autentifikačný mechanizmus alebo vôbec žiadny pre verejný prístup. Kombináciou obmedzení autentifikácie a prístupu k sieti dosiahnete robustný bezpečnostný model prispôsobený potrebám každého mikrofrontendu. Táto stratégia je obzvlášť účinná pre začínajúce podniky a MSP, ktoré hľadajú cenovo dostupné, škálovateľné a bezpečné cloudové riešenia. 🔐