Jak chronić dwa mikro-frontendy o różnych potrzebach dostępu na backendzie AWS

Równowaga między bezpieczeństwem i dostępnością w architekturze AWS Micro-Frontend

Projektowanie bezpiecznych i skalowalnych architektur chmurowych często wymaga zrównoważenia dostępności i ograniczonego dostępu. W konfiguracji AWS masz dwa mikro-frontendy z unikalnymi wymaganiami dostępu. FE-A musi być ograniczone do określonego statycznego adresu IP, natomiast FE-B powinno być dostępne publicznie. Jednoczesne zaspokojenie tych potrzeb może stanowić wyzwanie. 😅

Wyzwanie pojawia się podczas konfigurowania grup zabezpieczeń w EC2. Jeśli zezwolisz na dostęp do wersji 0.0.0.0, oba interfejsy staną się publicznie dostępne, co zagrozi bezpieczeństwu FE-A. Z drugiej strony ograniczenie dostępu do jednego statycznego adresu IP uniemożliwia publiczną dostępność FE-B. Stwarza to złożoną równowagę między otwartością a bezpieczeństwem.

Chociaż funkcja Lambda do dynamicznej aktualizacji zakresów adresów IP może wydawać się opłacalna, wprowadza ona dodatkowe obciążenie i nie jest optymalnym rozwiązaniem długoterminowym. Na przykład może z czasem zwiększyć koszty i złożoność. Co więcej, zarządzanie częstymi aktualizacjami grup zabezpieczeń może być kłopotliwe i podatne na błędy.

Znalezienie opłacalnego rozwiązania spełniającego te wymagania ma kluczowe znaczenie. Celem jest ochrona FE-A przy jednoczesnym zapewnieniu globalnej dostępności FE-B bez wprowadzania niepotrzebnych komplikacji. Przyjrzyjmy się, jak to osiągnąć, korzystając z najlepszych praktyk AWS. 🚀

Strategie zabezpieczania mikro-frontendów za pomocą AWS

Pierwszy skrypt wykorzystuje możliwości zapory aplikacji internetowej AWS (WAF) w celu wymuszenia odrębnych zasad dostępu dla dwóch mikro-frontendów. Tworząc WebACL, do FE-A stosowane są określone reguły IP, aby zezwalać tylko na ruch z wyznaczonego miejsca statyczny adres IP, zapewniając, że pozostanie to system zamknięty. W przypadku FE-B odrębna zasada zezwala na publiczny dostęp. Podejście to centralizuje kontrolę dostępu w warstwie aplikacji, dzięki czemu idealnie nadaje się do wydajnego zarządzania ruchem bez modyfikowania podstawowych grup zabezpieczeń EC2. Na przykład można ograniczyć FE-A do sieci biurowej, jednocześnie pozwalając FE-B pozostać globalnie dostępnym, zapewniając zarówno bezpieczeństwo korporacyjne, jak i wygodę użytkownika. 🌍

Lista WebACL jest następnie kojarzona z modułem równoważenia obciążenia aplikacji (ALB), co gwarantuje, że cały ruch przechodzący przez tę listę jest filtrowany zgodnie z tymi regułami. Polecenie waf_client.create_web_acl ma kluczowe znaczenie przy definiowaniu zasad, podczas gdy waf_client.associate_web_acl łączy WebACL z zasobem. Taka konfiguracja jest wysoce skalowalna i umożliwia przyszłe dostosowania, takie jak dodawanie nowych adresów IP lub modyfikowanie zasad dostępu, przy minimalnym wysiłku. Funkcje monitorowania, takie jak metryki CloudWatch, mogą również śledzić skuteczność reguł, zapewniając cenny wgląd w wzorce ruchu.

Natomiast rozwiązanie oparte na Lambdzie dynamicznie aktualizuje reguły grupy bezpieczeństwa EC2. Ten skrypt pobiera zakresy adresów IP specyficzne dla regionu AWS i konfiguruje je jako reguły ruchu przychodzącego w grupie zabezpieczeń. Funkcja ec2.authorize_security_group_ingress dodaje lub aktualizuje dozwolone zakresy adresów IP, umożliwiając publiczny dostęp do FE-B przy jednoczesnym zachowaniu ścisłej kontroli nad FE-A. Takie podejście jest szczególnie przydatne w środowiskach o często zmieniających się wymaganiach dotyczących własności intelektualnej, takich jak konfiguracje programistyczne w chmurze lub zmieniające się biura korporacyjne. Na przykład, jeśli zostanie utworzony nowy oddział, możesz automatycznie dodać jego adres IP do białej listy bez ręcznej interwencji. 🏢

Funkcja Lambda w połączeniu z zaplanowanym wydarzeniem CloudWatch automatyzuje te codzienne aktualizacje, zmniejszając obciążenie administracyjne. Chociaż takie podejście zwiększa złożoność, zapewnia precyzyjną kontrolę nad ruchem. Zawarte w skrypcie testy jednostkowe weryfikują funkcjonalność, zapewniając prawidłowe zastosowanie reguł bezpieczeństwa bez wprowadzania błędów. Niezależnie od tego, czy wybierzesz WAF, czy Lambda, w obu metodach priorytetem jest efektywność kosztowa i elastyczność, równoważąc potrzebę dostępu publicznego i ograniczonego. Ostatecznie rozwiązania te demonstrują wszechstronność AWS w spełnianiu różnorodnych wymagań przy jednoczesnym zachowaniu solidnego bezpieczeństwa. 🔒

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

Optymalizacja bezpieczeństwa i dostępności aplikacji Micro-Frontend w AWS

Innym skutecznym sposobem sprostania wyzwaniu polegającemu na zrównoważeniu dostępu ograniczonego i publicznego w architekturze mikrofrontendu jest wykorzystanie zintegrowanych funkcji AWS Amplify. Amplify upraszcza hosting i wdrażanie, zapewniając jednocześnie narzędzia do bezpiecznej konfiguracji interfejsów API zaplecza. W przypadku FE-A można wdrożyć kontrolę dostępu do sieci, ograniczając punkty końcowe API zaplecza do określonych adresów IP za pomocą bramy API AWS. Taka konfiguracja zapewnia, że ​​tylko predefiniowane statyczne adresy IP mogą wchodzić w interakcję z backendem, podczas gdy punkty końcowe FE-B mogą pozostać nieograniczone w zakresie dostępu publicznego. To nie tylko zwiększa bezpieczeństwo, ale także bezproblemowo integruje się z przepływami pracy CI/CD Amplify. 🌐

Inną kwestią jest użycie Amazon CloudFront z niestandardowymi zasadami dostępu do źródła. CloudFront może kierować ruch do odpowiedniego backendu na podstawie ścieżki URL, pełniąc funkcję strażnika Twoich mikro-frontendów. Ruch FE-A można filtrować przez CloudFront przy użyciu zasad żądań pochodzenia, które sprawdzają ograniczenia IP lub określone nagłówki. Na przykład przedsiębiorstwo wdrażające narzędzie wewnętrzne za pośrednictwem FE-A może dodać filtr zakresu adresów IP, jednocześnie udostępniając FE-B użytkownikom końcowym na całym świecie. Takie podejście optymalizuje zarówno skalowalność, jak i wydajność, szczególnie w przypadku aplikacji wymagających globalnej dystrybucji. 🚀

Wreszcie wdrożenie AWS Cognito do uwierzytelniania użytkowników dodaje dodatkową warstwę bezpieczeństwa. FE-A można zablokować za systemem logowania wymagającym uwierzytelnienia użytkownika z określonymi rolami lub grupami, podczas gdy FE-B może używać lżejszego mechanizmu uwierzytelniania lub w ogóle go nie stosować w przypadku dostępu publicznego. Łącząc ograniczenia uwierzytelniania i dostępu do sieci, uzyskujesz solidny model bezpieczeństwa dostosowany do potrzeb każdego mikro-frontendu. Strategia ta jest szczególnie skuteczna w przypadku start-upów i MŚP poszukujących niedrogich, skalowalnych i bezpiecznych rozwiązań chmurowych. 🔐