Kako zaščititi dve mikro fronti z različnimi potrebami po dostopu na zaledju AWS

Uravnoteženje varnosti in dostopnosti v arhitekturi AWS Micro-Frontend

Oblikovanje varnih in razširljivih arhitektur v oblaku pogosto vključuje ravnotežje med dostopnostjo in omejenim dostopom. V vaši nastavitvi AWS imate dve mikrovtičnici z edinstvenimi zahtevami za dostop. FE-A mora biti omejen na določen statični IP, medtem ko mora biti FE-B javno dostopen. Obravnavanje teh potreb hkrati lahko predstavlja izziv. 😅

Izziv nastane pri konfiguriranju varnostnih skupin v EC2. Če dovolite dostop do 0.0.0.0, postaneta obe sprednji strani javno dostopni, kar ogroža varnost FE-A. Po drugi strani pa omejitev dostopa na en sam statični IP zavrne javno dostopnost za FE-B. To ustvarja kompleksno ravnotežje med odprtostjo in varnostjo.

Medtem ko se funkcija Lambda za dinamično posodabljanje obsegov IP morda zdi izvedljiva, uvaja dodatne stroške in ni optimalna dolgoročna rešitev. Na primer, sčasoma lahko poveča stroške in kompleksnost. Poleg tega je lahko upravljanje pogostih posodobitev varnostnih skupin okorno in nagnjeno k napakam.

Najti stroškovno učinkovito rešitev, ki izpolnjuje te zahteve, je ključnega pomena. Cilj je zaščititi FE-A, hkrati pa zagotoviti, da FE-B ostane dostopen po vsem svetu brez uvajanja nepotrebnih zapletov. Raziščimo, kako to doseči z uporabo najboljših praks AWS. 🚀

Strategije za zaščito mikro front z AWS

Prvi skript izkorišča zmožnosti požarnega zidu spletne aplikacije AWS (WAF) za uveljavljanje različnih politik dostopa za dve mikrosprednji strani. Z ustvarjanjem WebACL se za FE-A uporabijo posebna pravila IP, ki dovoljujejo samo promet iz določenega statični IP, ki zagotavlja, da ostane zaprt sistem. Za FE-B ločeno pravilo dovoljuje javni dostop. Ta pristop centralizira nadzor dostopa na ravni aplikacije, zaradi česar je idealen za učinkovito upravljanje prometa brez spreminjanja osnovnih varnostnih skupin EC2. Na primer, FE-A lahko omejite na pisarniško omrežje, hkrati pa dovolite, da FE-B ostane globalno dostopen, kar skrbi tako za varnost podjetja kot za udobje uporabnika. 🌍

WebACL je nato povezan z izravnalnikom obremenitve aplikacij (ALB), kar zagotavlja, da je ves promet, ki poteka skozi ALB, filtriran v skladu s temi pravili. Ukaz waf_client.create_web_acl je ključnega pomena pri določanju pravil, medtem ko waf_client.associate_web_acl povezuje WebACL z virom. Ta nastavitev je zelo razširljiva in omogoča prihodnje prilagoditve, kot je dodajanje novih naslovov IP ali spreminjanje politik dostopa, z minimalnim naporom. Funkcije spremljanja, kot so meritve CloudWatch, lahko prav tako sledijo učinkovitosti pravil in zagotavljajo dragocen vpogled v vzorce prometa.

Nasprotno pa rešitev, ki temelji na Lambda, dinamično posodablja pravila varnostne skupine EC2. Ta skript pridobi obsege IP, specifične za vašo regijo AWS, in jih konfigurira kot pravila za vstop v varnostni skupini. Funkcija ec2.authorize_security_group_ingress dodaja ali posodablja dovoljene obsege IP, kar omogoča, da je FE-B javno dostopen, hkrati pa ohranja strog nadzor za FE-A. Ta pristop je še posebej uporaben v okoljih s pogosto spreminjajočimi se zahtevami IP, kot so razvojne nastavitve v oblaku ali premikanje poslovnih pisarn. Na primer, če je ustanovljena nova podružnica, lahko njen IP samodejno dodate na seznam dovoljenih brez ročnega posredovanja. 🏢

Funkcija Lambda v kombinaciji z načrtovanim dogodkom CloudWatch samodejno avtomatizira te posodobitve dnevno in tako zmanjša administrativne stroške. Čeprav ta pristop dodatno zaplete, zagotavlja natančen nadzor nad prometom. Preizkusi enot, vključeni v skript, potrdijo funkcionalnost in zagotovijo pravilno uporabo varnostnih pravil brez vnašanja napak. Ne glede na to, ali izberete WAF ali Lambda, obe metodi dajeta prednost stroškovni učinkovitosti in prilagodljivosti ter uravnotežita potrebo po javnem in omejenem dostopu. Navsezadnje te rešitve dokazujejo vsestranskost AWS pri izpolnjevanju različnih zahtev ob ohranjanju robustne varnosti. 🔒

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

Optimizacija varnosti in dostopnosti za aplikacije Micro-Frontend v AWS

Drug učinkovit način za reševanje izziva uravnoteženja omejenega in javnega dostopa v vaši arhitekturi mikro-frontenda je izkoriščanje integriranih funkcij AWS Amplify. Amplify poenostavlja gostovanje in uvajanje, hkrati pa zagotavlja orodja za varno konfiguriranje zalednih API-jev. Za FE-A lahko implementirate nadzor dostopa do omrežja tako, da omejite njegove zaledne končne točke API-ja na določene IP-je z uporabo prehoda AWS API. Ta nastavitev zagotavlja, da lahko samo vnaprej določeni statični IP-ji komunicirajo z zaledjem, medtem ko lahko končne točke FE-B ostanejo neomejene za javni dostop. To ne le poveča varnost, ampak se tudi brezhibno integrira z delovnimi tokovi Amplify CI/CD. 🌐

Drug premislek je uporaba Amazon CloudFront s pravilniki o izvornem dostopu po meri. CloudFront lahko usmeri promet v ustrezno zaledje na podlagi poti URL in služi kot vratar za vaše mikrosprednje strani. Promet FE-A je mogoče filtrirati prek CloudFront z uporabo pravilnika izvorne zahteve, ki preverja omejitve IP ali posebne glave. Na primer, podjetje, ki uvaja interno orodje prek FE-A, lahko doda filter obsega IP, hkrati pa naredi FE-B globalno na voljo končnim uporabnikom. Ta pristop optimizira tako razširljivost kot zmogljivost, zlasti za aplikacije, ki zahtevajo globalno distribucijo. 🚀

Nazadnje, implementacija AWS Cognito za preverjanje pristnosti uporabnikov dodaja dodatno raven varnosti. FE-A je mogoče zakleniti za sistem za prijavo, ki zahteva avtentikacijo uporabnika s posebnimi vlogami ali skupinami, medtem ko lahko FE-B za javni dostop uporablja lažji mehanizem za avtentikacijo ali pa ga sploh ne uporablja. S kombiniranjem avtentikacije in omejitev omrežnega dostopa dosežete robusten varnostni model, prilagojen potrebam vsakega mikro vmesnika. Ta strategija je še posebej učinkovita za novoustanovljena in mala in srednja podjetja, ki iščejo cenovno dostopne, razširljive in varne rešitve v oblaku. 🔐