Como proteger dois microfrontends com diferentes necessidades de acesso em um backend AWS

Equilibrando segurança e acessibilidade na arquitetura micro-frontend da AWS

Projetar arquiteturas de nuvem seguras e escaláveis ​​geralmente envolve equilibrar acessibilidade e acesso restrito. Na configuração da AWS, você tem dois microfrontends com requisitos de acesso exclusivos. FE-A precisa ser limitada a um IP estático específico, enquanto FE-B deve ser acessível publicamente. Atender a essas necessidades simultaneamente pode representar um desafio. 😅

O desafio surge ao configurar os grupos de segurança no EC2. Se você permitir o acesso a 0.0.0.0, ambos os frontends se tornarão acessíveis publicamente, comprometendo a segurança da FE-A. Por outro lado, restringir o acesso a um único IP estático nega a disponibilidade pública do FE-B. Isto cria um equilíbrio complexo entre abertura e segurança.

Embora uma função Lambda para atualizar dinamicamente intervalos de IP possa parecer viável, ela introduz sobrecarga adicional e não é uma solução ideal a longo prazo. Por exemplo, pode aumentar os custos e a complexidade ao longo do tempo. Além disso, gerenciar atualizações frequentes de grupos de segurança pode ser complicado e sujeito a erros.

Encontrar uma solução econômica que atenda a esses requisitos é fundamental. O objetivo é proteger a FE-A e, ao mesmo tempo, garantir que a FE-B permaneça acessível globalmente sem introduzir complexidades desnecessárias. Vamos explorar como conseguir isso usando as práticas recomendadas da AWS. 🚀

Estratégias para proteger microfrontends com AWS

O primeiro script aproveita os recursos do AWS Web Application Firewall (WAF) para impor políticas de acesso distintas para dois micro-frontends. Ao criar uma WebACL, regras de IP específicas são aplicadas à FE-A para permitir apenas o tráfego de um local designado. IP estático, garantindo que permaneça um sistema fechado. Para a FE-B, uma regra separada permite o acesso público. Essa abordagem centraliza o controle de acesso na camada de aplicação, tornando-a ideal para gerenciar o tráfego de forma eficiente, sem modificar os grupos de segurança EC2 subjacentes. Por exemplo, você pode restringir a FE-A a uma rede de escritório e ao mesmo tempo permitir que a FE-B permaneça acessível globalmente, atendendo tanto à segurança corporativa quanto à conveniência do usuário. 🌍

O WebACL é então associado a um Application Load Balancer (ALB), garantindo que todo o tráfego que passa pelo ALB seja filtrado de acordo com essas regras. O comando waf_client.create_web_acl é fundamental na definição das regras, enquanto waf_client.associate_web_acl vincula o WebACL ao recurso. Esta configuração é altamente escalável e permite ajustes futuros, como adição de novos IPs ou modificação de políticas de acesso, com mínimo esforço. Recursos de monitoramento como métricas do CloudWatch também podem monitorar a eficácia das regras, fornecendo insights valiosos sobre os padrões de tráfego.

Por outro lado, a solução baseada em Lambda atualiza dinamicamente as regras do grupo de segurança EC2. Este script busca intervalos de IP específicos para sua região da AWS e os configura como regras de entrada no grupo de segurança. A função ec2.authorize_security_group_ingress adiciona ou atualiza os intervalos de IP permitidos, permitindo que o FE-B seja acessível publicamente, mantendo ao mesmo tempo um controle rigoroso para o FE-A. Essa abordagem é particularmente útil em ambientes com requisitos de IP que mudam frequentemente, como configurações de desenvolvimento baseadas em nuvem ou mudanças de escritórios corporativos. Por exemplo, se uma nova filial for estabelecida, você poderá adicionar automaticamente seu IP à lista de permissões sem intervenção manual. 🏢

A função Lambda, combinada com um evento agendado do CloudWatch, automatiza essas atualizações diariamente, reduzindo a sobrecarga administrativa. Embora essa abordagem acrescente complexidade, ela fornece controle refinado sobre o tráfego. Os testes unitários incluídos no script validam a funcionalidade, garantindo que as regras de segurança sejam aplicadas corretamente sem introduzir erros. Quer você escolha WAF ou Lambda, ambos os métodos priorizam a economia e a flexibilidade, equilibrando a necessidade de acesso público e restrito. Em última análise, essas soluções demonstram a versatilidade da AWS em atender a diversos requisitos e, ao mesmo tempo, manter uma segurança robusta. 🔒

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

Otimizando segurança e acessibilidade para aplicativos micro-frontend na AWS

Outra maneira eficaz de enfrentar o desafio de equilibrar o acesso restrito e público em sua arquitetura de microfrontend é aproveitar os recursos integrados do AWS Amplify. O Amplify simplifica a hospedagem e a implantação, ao mesmo tempo que fornece ferramentas para configurar APIs de back-end com segurança. Para FE-A, você pode implementar o controle de acesso à rede restringindo seus endpoints de API de back-end a IPs específicos usando um AWS API Gateway. Esta configuração garante que apenas IPs estáticos predefinidos possam interagir com o backend, enquanto os endpoints da FE-B podem permanecer irrestritos para acesso público. Isso não apenas aumenta a segurança, mas também se integra perfeitamente aos fluxos de trabalho de CI/CD do Amplify. 🌐

Outra consideração é usar o Amazon CloudFront com políticas personalizadas de acesso à origem. O CloudFront pode rotear o tráfego para o back-end apropriado com base no caminho do URL, servindo como um gatekeeper para seus micro-front-ends. O tráfego FE-A pode ser filtrado por meio do CloudFront usando uma política de solicitação de origem que verifica restrições de IP ou cabeçalhos específicos. Por exemplo, uma empresa que implementa uma ferramenta interna através do FE-A pode adicionar um filtro de intervalo de IP e, ao mesmo tempo, disponibilizar o FE-B globalmente para os usuários finais. Esta abordagem otimiza a escalabilidade e o desempenho, especialmente para aplicações que exigem distribuição global. 🚀

Por último, a implementação do AWS Cognito para autenticação de usuários adiciona uma camada extra de segurança. FE-A pode ser bloqueada por um sistema de login que requer autenticação de usuário com funções ou grupos específicos, enquanto FE-B pode usar um mecanismo de autenticação mais leve ou nenhum para acesso público. Ao combinar autenticação e restrições de acesso à rede, você obtém um modelo de segurança robusto, adaptado às necessidades de cada microfrontend. Esta estratégia é particularmente eficaz para startups e PME que procuram soluções em nuvem acessíveis, escaláveis ​​e seguras. 🔐