Як захистити два мікро-інтерфейси з різними потребами доступу на серверній частині AWS

Баланс безпеки та доступності в архітектурі AWS Micro-Frontend

Розробка безпечних і масштабованих хмарних архітектур часто передбачає збалансування доступності та обмеженого доступу. У вашому налаштуванні AWS є два мікроінтерфейси з унікальними вимогами до доступу. FE-A потрібно обмежити певним статичним IP, тоді як FE-B має бути загальнодоступним. Одночасне задоволення цих потреб може стати проблемою. 😅

Проблема виникає під час налаштування груп безпеки в EC2. Якщо ви дозволите доступ до 0.0.0.0, обидва інтерфейси стають загальнодоступними, що ставить під загрозу безпеку FE-A. З іншого боку, обмеження доступу до однієї статичної IP-адреси позбавляє публічної доступності для FE-B. Це створює складний баланс між відкритістю та безпекою.

Хоча функція Lambda для динамічного оновлення діапазонів IP-адрес може здатися життєздатною, вона створює додаткові накладні витрати та не є оптимальним довгостроковим рішенням. Наприклад, це може збільшити витрати та складність з часом. Крім того, керування частими оновленнями груп безпеки може бути громіздким і спричиняти помилки.

Важливо знайти економічно ефективне рішення, яке відповідає цим вимогам. Мета полягає в тому, щоб захистити FE-A, одночасно гарантуючи, що FE-B залишається доступним у всьому світі без зайвих ускладнень. Давайте дослідимо, як цього досягти, використовуючи найкращі практики AWS. 🚀

Стратегії захисту мікрофронтендів за допомогою AWS

Перший сценарій використовує можливості брандмауера веб-додатків AWS (WAF), щоб застосувати різні політики доступу для двох мікроінтерфейсів. Створюючи WebACL, спеціальні правила IP застосовуються до FE-A, щоб дозволити лише трафік із визначеного статичний IP, гарантуючи, що вона залишається закритою системою. Для FE-B окреме правило дозволяє відкритий доступ. Цей підхід централізує контроль доступу на прикладному рівні, що робить його ідеальним для ефективного керування трафіком без зміни основних груп безпеки EC2. Наприклад, ви можете обмежити FE-A мережею офісу, дозволивши FE-B залишатися глобально доступним, задовольняючи як корпоративну безпеку, так і зручність користувача. 🌍

Потім WebACL пов’язується з балансувальником навантаження програми (ALB), гарантуючи, що весь трафік, що проходить через ALB, фільтрується відповідно до цих правил. Команда waf_client.create_web_acl є ключовим у визначенні правил, хоча waf_client.associate_web_acl зв’язує WebACL із ресурсом. Це налаштування має високу масштабованість і дозволяє в майбутньому коригувати, наприклад додавати нові IP-адреси або змінювати політики доступу, з мінімальними зусиллями. Такі функції моніторингу, як показники CloudWatch, також можуть відстежувати ефективність правил, надаючи цінну інформацію про моделі трафіку.

Навпаки, рішення на основі Lambda динамічно оновлює правила групи безпеки EC2. Цей сценарій отримує діапазони IP-адрес, специфічні для вашого регіону AWS, і налаштовує їх як правила входу в групу безпеки. Функція ec2.authorize_security_group_ingress додає або оновлює дозволені діапазони IP-адрес, уможливлюючи FE-B бути загальнодоступним, зберігаючи суворий контроль для FE-A. Цей підхід особливо корисний у середовищах із часто змінюваними вимогами до IP, наприклад у хмарних налаштуваннях розробки чи зміні корпоративних офісів. Наприклад, якщо створено нову філію, ви можете автоматично додати її IP-адресу до білого списку без ручного втручання. 🏢

Функція Lambda в поєднанні з запланованою подією CloudWatch автоматизує ці оновлення щодня, зменшуючи адміністративні витрати. Незважаючи на те, що цей підхід ускладнює, він забезпечує точний контроль над трафіком. Модульні тести, включені в сценарій, перевіряють функціональність, забезпечуючи правильне застосування правил безпеки без внесення помилок. Незалежно від того, чи ви обираєте WAF чи Lambda, обидва методи надають перевагу економічній ефективності та гнучкості, збалансовуючи потребу у публічному та обмеженому доступі. Зрештою, ці рішення демонструють універсальність AWS у задоволенні різноманітних вимог, зберігаючи надійну безпеку. 🔒

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

Оптимізація безпеки та доступності для програм Micro-Frontend в AWS

Ще один ефективний спосіб вирішення проблеми збалансування обмеженого та загальнодоступного доступу у вашій мікроінтерфейсній архітектурі — це використання інтегрованих функцій AWS Amplify. Amplify спрощує розміщення та розгортання, надаючи інструменти для безпечного налаштування серверних API. Для FE-A ви можете реалізувати контроль доступу до мережі, обмеживши кінцеві точки API серверної частини певними IP-адресами за допомогою шлюзу AWS API. Це налаштування гарантує, що лише попередньо визначені статичні IP-адреси можуть взаємодіяти з серверною частиною, тоді як кінцеві точки FE-B можуть залишатися необмеженими для загального доступу. Це не тільки покращує безпеку, але й ідеально інтегрується з робочими процесами Amplify CI/CD. 🌐

Ще одна міркування – використання Amazon CloudFront із спеціальними політиками доступу джерела. CloudFront може скеровувати трафік на відповідну серверну частину на основі URL-шляху, служачи воротарем для ваших мікроінтерфейсів. Трафік FE-A можна відфільтрувати через CloudFront за допомогою політики запиту джерела, яка перевіряє обмеження IP або певні заголовки. Наприклад, підприємство, яке розгортає внутрішній інструмент через FE-A, може додати фільтр діапазону IP-адрес, зроблячи FE-B глобально доступним для кінцевих користувачів. Цей підхід оптимізує як масштабованість, так і продуктивність, особливо для програм, які вимагають глобального поширення. 🚀

Нарешті, впровадження AWS Cognito для автентифікації користувачів додає додатковий рівень безпеки. FE-A може бути заблоковано за системою входу, що вимагає автентифікації користувача з певними ролями чи групами, тоді як FE-B може використовувати легший механізм автентифікації або взагалі не використовувати для публічного доступу. Поєднуючи автентифікацію та обмеження доступу до мережі, ви досягаєте надійної моделі безпеки, адаптованої до потреб кожного мікроінтерфейсу. Ця стратегія особливо ефективна для стартапів і малих і середніх підприємств, які шукають доступні, масштабовані та безпечні хмарні рішення. 🔐