Kā aizsargāt divus mikropriekšpuses ar atšķirīgām piekļuves vajadzībām AWS aizmugursistēmā

Drošības un pieejamības līdzsvarošana AWS mikropriekšējā arhitektūrā

Drošu un mērogojamu mākoņu arhitektūru projektēšana bieži vien ir saistīta ar pieejamības un ierobežotas piekļuves līdzsvarošanu. AWS iestatījumos jums ir divas mikropriekšgaldas ar unikālām piekļuves prasībām. FE-A ir jāierobežo ar noteiktu statisku IP, savukārt FE-B jābūt publiski pieejamam. Šo vajadzību vienlaicīga risināšana var radīt izaicinājumu. 😅

Izaicinājums rodas, konfigurējot drošības grupas EC2. Ja atļausiet piekļuvi 0.0.0.0, abas saskarnes kļūst publiski pieejamas, tādējādi apdraudot FE-A drošību. No otras puses, piekļuves ierobežošana vienam statiskam IP liedz FE-B publisku pieejamību. Tas rada sarežģītu līdzsvaru starp atklātību un drošību.

Lai gan Lambda funkcija dinamiskai IP diapazonu atjaunināšanai varētu šķist dzīvotspējīga, tā rada papildu izmaksas un nav optimāls ilgtermiņa risinājums. Piemēram, laika gaitā tas var palielināt izmaksas un sarežģītību. Turklāt biežu drošības grupu atjauninājumu pārvaldība var būt apgrūtinoša un ar kļūdu iespējamību.

Ir ļoti svarīgi atrast rentablu risinājumu, kas atbilst šīm prasībām. Mērķis ir aizsargāt FE-A, vienlaikus nodrošinot, ka FE-B joprojām ir pieejams visā pasaulē, neradot nevajadzīgas sarežģītības. Izpētīsim, kā to panākt, izmantojot AWS paraugpraksi. 🚀

Stratēģijas mikropriekšējo daļu nodrošināšanai ar AWS

Pirmais skripts izmanto AWS tīmekļa lietojumprogrammu ugunsmūra iespējas (WAF), lai ieviestu atšķirīgas piekļuves politikas divām mikropriekšgaldām. Izveidojot WebACL, FE-A tiek piemēroti īpaši IP noteikumi, lai atļautu trafiku tikai no norādītā statiskā IP, nodrošinot, ka tā paliek slēgta sistēma. Attiecībā uz FE-B publisku piekļuvi nodrošina atsevišķs noteikums. Šī pieeja centralizē piekļuves kontroli lietojumprogrammas līmenī, padarot to ideāli piemērotu efektīvai trafika pārvaldībai, nemainot pamatā esošās EC2 drošības grupas. Piemēram, jūs varat ierobežot FE-A ar biroja tīklu, vienlaikus ļaujot FE-B palikt globāli pieejams, rūpējoties gan par korporatīvo drošību, gan lietotāju ērtībām. 🌍

Pēc tam WebACL tiek saistīts ar lietojumprogrammu slodzes līdzsvarotāju (ALB), nodrošinot, ka visa trafika, kas iet caur ALB, tiek filtrēta saskaņā ar šiem noteikumiem. Komanda waf_client.create_web_acl ir galvenais noteikumu definēšanā waf_client.associate_web_acl saista WebACL ar resursu. Šī iestatīšana ir ļoti mērogojama, un tā ļauj veikt turpmākas korekcijas, piemēram, pievienot jaunus IP vai mainīt piekļuves politikas ar minimālu piepūli. Uzraudzības funkcijas, piemēram, CloudWatch metrika, var arī izsekot noteikumu efektivitātei, sniedzot vērtīgu ieskatu satiksmes modeļos.

Turpretim uz Lambda balstītais risinājums dinamiski atjaunina EC2 drošības grupas noteikumus. Šis skripts ienes jūsu AWS reģionam raksturīgos IP diapazonus un konfigurē tos kā ieejas noteikumus drošības grupā. Funkcija ec2.authorize_security_group_ingress pievieno vai atjaunina atļautos IP diapazonus, ļaujot FE-B būt publiski pieejamam, vienlaikus saglabājot stingru FE-A kontroli. Šī pieeja ir īpaši noderīga vidēs ar bieži mainīgām IP prasībām, piemēram, mākoņdatošanas izstrādes iestatījumos vai korporatīvo biroju maiņu. Piemēram, ja tiek izveidots jauns filiāles birojs, varat automātiski pievienot tās IP baltajam sarakstam bez manuālas iejaukšanās. 🏢

Lambda funkcija apvienojumā ar ieplānotu CloudWatch notikumu katru dienu automatizē šos atjauninājumus, samazinot administratīvos izdevumus. Lai gan šī pieeja palielina sarežģītību, tā nodrošina precīzu trafika kontroli. Skriptā iekļautie vienību testi apstiprina funkcionalitāti, nodrošinot drošības noteikumu pareizu piemērošanu, neradot kļūdas. Neatkarīgi no tā, vai izvēlaties WAF vai Lambda, abās metodēs prioritāte ir izmaksu efektivitāte un elastība, līdzsvarojot vajadzību pēc publiskas un ierobežotas piekļuves. Galu galā šie risinājumi parāda AWS daudzpusību, apmierinot dažādas prasības, vienlaikus saglabājot stabilu drošību. 🔒

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

AWS mikropriekšējās lietojumprogrammu drošības un pieejamības optimizēšana

Vēl viens efektīvs veids, kā risināt problēmas, kas saistītas ar ierobežotas un publiskās piekļuves līdzsvarošanu jūsu mikropriekšgala arhitektūrā, ir AWS Amplify integrēto līdzekļu izmantošana. Amplify vienkāršo mitināšanu un izvietošanu, vienlaikus nodrošinot rīkus, lai droši konfigurētu aizmugursistēmas API. FE-A varat ieviest tīkla piekļuves kontroli, ierobežojot tā aizmugursistēmas API galapunktus līdz noteiktiem IP, izmantojot AWS API vārteju. Šī iestatīšana nodrošina, ka tikai iepriekš definētas statiskas IP var mijiedarboties ar aizmugursistēmu, savukārt FE-B galapunkti var palikt neierobežoti publiskai piekļuvei. Tas ne tikai uzlabo drošību, bet arī nemanāmi integrējas Amplify CI/CD darbplūsmās. 🌐

Vēl viens apsvērums ir Amazon CloudFront izmantošana ar pielāgotām izcelsmes piekļuves politikām. CloudFront var novirzīt trafiku uz atbilstošo aizmugursistēmu, pamatojoties uz URL ceļu, kalpojot kā vārteja jūsu mikropriekšgaldām. FE-A trafiku var filtrēt, izmantojot CloudFront, izmantojot izcelsmes pieprasījuma politiku, kas pārbauda IP ierobežojumus vai īpašas galvenes. Piemēram, uzņēmums, kas izvieto iekšējo rīku, izmantojot FE-A, var pievienot IP diapazona filtru, vienlaikus padarot FE-B globāli pieejamu galalietotājiem. Šī pieeja optimizē gan mērogojamību, gan veiktspēju, jo īpaši lietojumprogrammām, kurām nepieciešama globāla izplatīšana. 🚀

Visbeidzot, AWS Cognito ieviešana lietotāja autentifikācijai pievieno papildu drošības līmeni. FE-A var bloķēt aiz pieteikšanās sistēmas, kurai nepieciešama lietotāja autentifikācija ar noteiktām lomām vai grupām, savukārt FE-B publiskai piekļuvei var izmantot vieglāku autentifikācijas mehānismu vai to vispār neizmantot. Apvienojot autentifikācijas un tīkla piekļuves ierobežojumus, jūs iegūstat stabilu drošības modeli, kas pielāgots katras mikropriekšgala vajadzībām. Šī stratēģija ir īpaši efektīva jaunizveidotiem uzņēmumiem un MVU, kas meklē pieejamus, mērogojamus un drošus mākoņa risinājumus. 🔐