Kaip apsaugoti du mikropriekius su skirtingais prieigos poreikiais AWS foninėje sistemoje

Saugumo ir prieinamumo pusiausvyra naudojant AWS mikropriekio architektūrą

Kuriant saugias ir keičiamo dydžio debesų architektūras dažnai reikia suderinti prieinamumą ir ribotą prieigą. Savo AWS sąrankoje turite dvi mikro sąsajas su unikaliais prieigos reikalavimais. FE-A turi apsiriboti konkrečiu statiniu IP, o FE-B turėtų būti prieinamas viešai. Šių poreikių tenkinimas vienu metu gali būti iššūkis. 😅

Iššūkis kyla konfigūruojant saugumo grupes EC2. Jei leisite prieigą prie 0.0.0.0, abi sąsajos taps viešai prieinamos, o tai pakenks FE-A saugumui. Kita vertus, apribojus prieigą prie vieno statinio IP, FE-B nėra prieinamas viešai. Tai sukuria sudėtingą pusiausvyrą tarp atvirumo ir saugumo.

Nors Lambda funkcija, skirta dinamiškai atnaujinti IP diapazonus, gali atrodyti perspektyvi, ji sukelia papildomų išlaidų ir nėra optimalus ilgalaikis sprendimas. Pavyzdžiui, laikui bėgant tai gali padidinti išlaidas ir sudėtingumą. Be to, tvarkyti dažnus saugos grupių naujinimus gali būti sudėtinga ir gali kilti klaidų.

Labai svarbu rasti ekonomišką sprendimą, atitinkantį šiuos reikalavimus. Tikslas yra apsaugoti FE-A, kartu užtikrinant, kad FE-B būtų pasiekiamas visame pasaulyje, nesukeliant nereikalingų sunkumų. Panagrinėkime, kaip tai pasiekti naudojant AWS geriausią praktiką. 🚀

Mikrofrontų apsaugos naudojant AWS strategijos

Pirmasis scenarijus išnaudoja AWS žiniatinklio programos ugniasienės galimybes (WAF), kad būtų įgyvendintos skirtingos dviejų mikro sąsajų prieigos strategijos. Sukūrus WebACL, FE-A taikomos specifinės IP taisyklės, leidžiančios tik srautą iš nurodytos vietos statinis IP, užtikrinant, kad ji išliktų uždara sistema. FE-B atveju atskira taisyklė leidžia viešai naudotis. Šis metodas centralizuoja prieigos valdymą programos lygmenyje, todėl jis idealiai tinka efektyviam srauto valdymui nekeičiant pagrindinių EC2 saugos grupių. Pavyzdžiui, galite apriboti FE-A tik biuro tinklu, o FE-B išlikti pasiekiamas visame pasaulyje, kad būtų užtikrintas tiek įmonės saugumas, tiek naudotojo patogumas. 🌍

Tada WebACL susiejamas su taikomųjų programų apkrovos balansavimo priemone (ALB), užtikrinant, kad visas srautas, einantis per ALB, būtų filtruojamas pagal šias taisykles. Komanda waf_client.create_web_acl yra labai svarbus nustatant taisykles waf_client.associate_web_acl susieja WebACL su šaltiniu. Ši sąranka yra labai keičiamo dydžio ir leidžia ateityje koreguoti, pvz., pridėti naujų IP arba keisti prieigos politiką, be pastangų. Stebėjimo funkcijos, pvz., „CloudWatch“ metrika, taip pat gali stebėti taisyklių efektyvumą, suteikdamos vertingų įžvalgų apie srauto modelius.

Priešingai, Lambda pagrindu sukurtas sprendimas dinamiškai atnaujina EC2 saugos grupės taisykles. Šis scenarijus gauna IP diapazonus, būdingus jūsų AWS regionui, ir sukonfigūruoja juos kaip įėjimo taisykles saugos grupėje. Funkcija ec2.authorize_security_group_ingress prideda arba atnaujina leistinus IP diapazonus, kad FE-B būtų viešai prieinamas, išlaikant griežtą FE-A kontrolę. Šis metodas ypač naudingas aplinkoje, kurioje dažnai keičiasi IP reikalavimai, pvz., debesies pagrindu sukurtos kūrimo sąrankos arba keičiami įmonės biurai. Pavyzdžiui, jei įsteigiamas naujas filialas, galite automatiškai įtraukti jo IP į baltąjį sąrašą be rankinio įsikišimo. 🏢

„Lambda“ funkcija kartu su suplanuotu „CloudWatch“ įvykiu kasdien automatizuoja šiuos atnaujinimus, sumažindama administracines išlaidas. Nors šis metodas padidina sudėtingumą, jis užtikrina tikslią eismo kontrolę. Į scenarijų įtraukti vienetų testai patvirtina funkcionalumą, užtikrindami, kad saugos taisyklės būtų tinkamai pritaikytos, be klaidų. Nesvarbu, ar pasirinksite WAF, ar Lambda, abu metodai teikia pirmenybę sąnaudų efektyvumui ir lankstumui, suderinant viešosios ir ribotos prieigos poreikį. Galiausiai šie sprendimai parodo AWS universalumą, tenkinant įvairius reikalavimus ir išlaikant tvirtą saugumą. 🔒

# 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 mikropriekinių programų saugumo ir prieinamumo optimizavimas

Kitas veiksmingas būdas išspręsti ribotos ir viešosios prieigos pusiausvyrą jūsų mikro sąsajos architektūroje yra integruotų AWS Amplify funkcijų panaudojimas. Amplify supaprastina prieglobą ir diegimą, kartu suteikiant įrankius, leidžiančius saugiai konfigūruoti pagrindines API. Jei naudojate FE-A, galite įdiegti tinklo prieigos valdymą, apribodami jo galinius API galinius taškus iki konkrečių IP, naudodami AWS API šliuzą. Ši sąranka užtikrina, kad tik iš anksto nustatyti statiniai IP gali sąveikauti su pagrindine programa, o FE-B galinių taškų viešoji prieiga gali likti neapribota. Tai ne tik padidina saugumą, bet ir sklandžiai integruojasi su „Amplify“ CI / CD darbo eigomis. 🌐

Kitas aspektas yra „Amazon CloudFront“ naudojimas su pasirinktine kilmės prieigos politika. „CloudFront“ gali nukreipti srautą į atitinkamą užpakalinę programą pagal URL kelią ir tarnauti kaip jūsų mikro sąsajų vartų sargas. FE-A srautas gali būti filtruojamas per „CloudFront“, naudojant kilmės užklausos politiką, kuri tikrina, ar nėra IP apribojimų arba konkrečių antraščių. Pavyzdžiui, įmonė, diegianti vidinį įrankį per FE-A, gali pridėti IP diapazono filtrą, o FE-B bus prieinama galutiniams vartotojams visame pasaulyje. Šis metodas optimizuoja ir mastelį, ir našumą, ypač taikomoms programoms, kurioms reikalingas pasaulinis platinimas. 🚀

Galiausiai, įdiegus AWS Cognito vartotojo autentifikavimui, pridedamas papildomas saugumo sluoksnis. FE-A gali būti užrakintas už prisijungimo sistemos, kuriai reikalingas vartotojo autentifikavimas naudojant tam tikrus vaidmenis ar grupes, o FE-B gali naudoti lengvesnį autentifikavimo mechanizmą arba jo visai nenaudoti viešai prieigai. Derindami autentifikavimo ir prieigos prie tinklo apribojimus, pasieksite tvirtą saugos modelį, pritaikytą kiekvienos mikro sąsajos poreikiams. Ši strategija ypač efektyvi pradedantiesiems ir MVĮ, ieškančioms įperkamų, keičiamo dydžio ir saugių debesijos sprendimų. 🔐