Category: Uncategorized

  • Amazon ECS Managed Daemons agora suportam visibilidade e comunicação entre tarefas

    O que mudou nos ECS Managed Daemons

    A AWS anunciou uma atualização relevante para equipes que utilizam o Amazon ECS com ECS Managed Instances: os ECS Managed Daemons agora suportam visibilidade e comunicação entre tarefas. Isso abre caminho para implantar agentes de rastreamento, profiling e segurança que precisam acessar processos da aplicação e recursos compartilhados de Comunicação entre Processos (IPC) diretamente na instância gerenciada.

    Dois novos parâmetros nas definições de daemon

    Com esse lançamento, é possível configurar dois novos campos nas definições de daemon do ECS:

    • pidMode: controla se o daemon pode enxergar todos os processos em execução na instância.
    • ipcMode: controla se o daemon compartilha o namespace IPC com os demais contêineres da instância.

    Em ambos os casos, definir o valor como "shared" concede ao daemon acesso ao namespace correspondente. O valor padrão é "none", que mantém o daemon isolado dos contêineres de aplicação e das demais tarefas — comportamento já existente e preservado por padrão.

    Por que isso importa na prática

    Antes dessa atualização, agentes que precisavam de visibilidade sobre processos ou acesso a recursos IPC precisavam ser incorporados como sidecars dentro das definições de tarefas das aplicações. Isso criava acoplamento entre a plataforma e os times de produto, dificultando atualizações independentes dos agentes.

    Com os novos parâmetros, equipes de plataforma podem implantar e atualizar esses agentes de forma independente, como daemons dedicados. O ECS já garante que exatamente uma tarefa daemon seja executada por instância gerenciada e que os daemons sejam iniciados antes das tarefas de aplicação — o que assegura cobertura consistente em todas as cargas de trabalho do cluster.

    Como começar a usar

    Para habilitar o recurso, basta registrar uma definição de tarefa daemon especificando pidMode ou ipcMode com o valor "shared". Essa configuração pode ser feita pelo Console da AWS, pela CLI, via CloudFormation ou pelos SDKs da AWS. Em seguida, é necessário criar ou atualizar um daemon associando-o aos provedores de capacidade do ECS Managed Instances no cluster desejado.

    Disponibilidade e custo

    O recurso já está disponível em todas as regiões da AWS e não tem custo adicional. Para mais detalhes técnicos, a AWS disponibiliza a documentação oficial com os parâmetros suportados nas definições de daemon.

    Fonte

    Amazon ECS Managed Daemons now support inter-task visibility and communication (https://aws.amazon.com/about-aws/whats-new/2026/06/ecs-managed-daemons-pid-ipc-modes/)

  • AWS Backup agora suporta Amazon EKS na Região Soberana Europeia da AWS (Alemanha)

    Proteção de clusters Kubernetes chega à Nuvem Soberana Europeia

    A AWS anunciou a disponibilidade do suporte do AWS Backup para o Serviço Elástico de Kubernetes da Amazon (Amazon EKS) na Região da Nuvem Soberana Europeia da AWS (Alemanha). A expansão leva proteção e recuperação de dados gerenciada, baseada em políticas, para clusters EKS nessa região — um passo importante para organizações europeias com requisitos rigorosos de conformidade e soberania de dados.

    O que está disponível

    Com essa expansão, os recursos já conhecidos do AWS Backup passam a estar disponíveis para workloads Kubernetes na Região Soberana Europeia. Entre as capacidades incluídas estão:

    • Agendamento automatizado de backups, sem necessidade de scripts manuais
    • Gerenciamento de retenção de dados com controle centralizado
    • Cofres imutáveis (immutable vaults) para proteção contra exclusão ou alteração indevida
    • Cópias entre regiões e entre contas (cross-Region e cross-account)

    A solução é totalmente sem agente (agent-free), o que significa que não é preciso instalar nenhum componente adicional nos clusters para que o backup funcione.

    O que pode ser protegido

    O AWS Backup para Amazon EKS permite proteger diferentes granularidades do ambiente Kubernetes:

    • Clusters EKS inteiros
    • Namespaces específicos
    • Volumes persistentes individuais

    Essa flexibilidade permite que as equipes adaptem a estratégia de backup conforme a criticidade de cada parte do ambiente, sem depender de ferramentas de terceiros ou scripts customizados.

    Casos de uso principais

    A AWS destaca três cenários principais onde o recurso agrega valor direto:

    • Recuperação de desastres: garantir que os clusters possam ser restaurados rapidamente em caso de falhas
    • Conformidade regulatória: atender requisitos de retenção e proteção de dados exigidos por normas europeias e setoriais
    • Antes de atualizações do cluster EKS: criar um ponto de restauração seguro antes de realizar upgrades, reduzindo o risco operacional

    Como começar

    Para utilizar o AWS Backup com Amazon EKS na Região Soberana Europeia, é possível acessar o console do AWS Backup, consultar a documentação oficial do AWS Backup ou acompanhar os detalhes técnicos no AWS News Blog.

    Fonte

    AWS Backup support for Amazon EKS is now available in the AWS European Sovereign Cloud (Germany) Region (https://aws.amazon.com/about-aws/whats-new/2026/06/aws-backup-amazon-eks-aws-european-sovereign-cloud/)

  • Amazon S3 Access Grants agora disponível na Região Soberana Europeia da AWS (Alemanha)

    Novidade na Nuvem Soberana Europeia

    A AWS anunciou que o Amazon S3 Access Grants está agora disponível na região AWS European Sovereign Cloud (Alemanha). Para equipes que operam nessa região com requisitos elevados de soberania de dados, essa é uma expansão relevante de capacidade de controle de acesso.

    O que é o Amazon S3 Access Grants?

    O S3 Access Grants é um recurso do Amazon S3 que permite mapear identidades corporativas — como usuários e grupos gerenciados no Microsoft Entra ID ou em Identidade e Gerenciamento de Acesso da AWS (IAM) — diretamente a conjuntos de dados armazenados no S3.

    Na prática, isso significa que uma organização pode conceder acesso a buckets e prefixos do S3 com base na identidade corporativa do usuário final, sem precisar criar e manter políticas individuais para cada pessoa. O controle de permissões acontece de forma automatizada e em escala, refletindo a estrutura de diretórios já existente na empresa.

    Por que isso importa para quem usa a Nuvem Soberana?

    A AWS European Sovereign Cloud foi desenvolvida para atender organizações europeias com requisitos rigorosos de residência de dados, conformidade regulatória e controle operacional — especialmente relevante para setores como governo, saúde e serviços financeiros na Europa.

    Com a chegada do S3 Access Grants a essa região, as equipes que já utilizam a Nuvem Soberana da AWS na Alemanha passam a contar com uma forma mais escalável de gerenciar permissões de dados no S3, integrada às suas identidades corporativas existentes — sem abrir mão dos controles de soberania que motivaram a escolha dessa região.

    Disponibilidade e recursos adicionais

    Para verificar a disponibilidade completa do S3 Access Grants por região, a AWS disponibiliza a tabela de regiões da AWS. Quem quiser se aprofundar no funcionamento do recurso pode acessar a página oficial do produto com detalhes técnicos e casos de uso.

    Fonte

    Amazon S3 Access Grants are now available in the AWS European Sovereign Cloud (Germany) Region (https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-s3-access-grants-european-sovereign-cloud-germany-region)

  • Amazon Quick ARNs: Migração Entre Contas e Permissões por Namespace

    O problema que todo administrador do Amazon Quick já enfrentou

    Você migra dashboards do ambiente de desenvolvimento para produção — e as permissões simplesmente somem. Você compartilha um painel com o time de Finanças e eles continuam recebendo “acesso negado”. Você configura namespaces para isolamento multi-tenant e o mesmo nome de usuário funciona em um namespace, mas não em outro.

    Esses são cenários reais que administradores do Amazon Quick enfrentam com frequência. Resolver esses problemas exige entender como os Nomes de Recursos da Amazon (ARNs — Amazon Resource Names) funcionam dentro do serviço. A AWS publicou um guia técnico detalhado sobre esse tema, e a CloudTroop traz aqui uma leitura comentada para o público brasileiro.

    Uma nota importante sobre nomenclatura

    O Amazon Quick é o nome atual do serviço, mas os ARNs e endpoints de API ainda utilizam quicksight como identificador de serviço. Isso foi mantido para garantir compatibilidade com políticas existentes do Serviço de Gerenciamento de Identidade e Acesso (IAM — Identity and Access Management), automações e integrações já em produção. Portanto, você continuará vendo ARNs no formato:

    arn:aws:quicksight:us-east-1:123456789012:dashboard/...

    O trecho quicksight refere-se à capacidade Quick Sight dentro do Amazon Quick. Códigos, políticas IAM e comandos de interface de linha de comando (CLI — Command Line Interface) existentes continuam funcionando sem modificação. Para mais detalhes, consulte a documentação de ARNs de Recursos do Amazon Quick Sight.

    ARNs como endereços postais

    Uma forma simples de entender ARNs: pense neles como endereços postais. Assim como “Rua Principal, 123, São Paulo, SP” identifica um local único, um ARN identifica de forma única um recurso dentro da AWS. Veja como os componentes se mapeiam:

    • aws → Partição da AWS (aws / aws-cn / aws-gov-us)
    • quicksight → O serviço dentro da partição
    • us-east-1 → Região da AWS
    • 111111111111 → ID da conta AWS
    • dashboard → Tipo de recurso
    • 04f736b4-bd1b-… → ID único do recurso

    O ponto mais importante aqui: o ID da conta faz parte do endereço. Se você muda de conta, o endereço muda — mesmo que o ID do recurso seja idêntico. Migrar um dashboard de desenvolvimento para produção gera um ARN diferente, porque o ID da conta é diferente.

    Migração entre contas: o que muda e o que permanece

    Imagine uma empresa com três contas AWS para seu ambiente Amazon Quick: Desenvolvimento (conta 111111111111), Qualidade/Testes (conta 222222222222) e Produção (conta 333333333333).

    Uma analista cria um dashboard de vendas em Desenvolvimento:

    arn:aws:quicksight:us-east-1:111111111111:dashboard/sales-dash-001

    Ao usar as APIs de Asset Bundle para migrar para Qualidade/Testes, o dashboard recebe um novo ARN:

    arn:aws:quicksight:us-east-1:222222222222:dashboard/sales-dash-001

    O que mudou: o ID da conta (111111111111222222222222). O que permaneceu: o ID do recurso (sales-dash-001) e a região (us-east-1). O dashboard em Qualidade/Testes é um recurso diferente do original, mesmo compartilhando o mesmo ID de recurso.

    Por que permissões não migram automaticamente

    O Amazon Quick armazena permissões como relacionamentos entre ARNs de recursos e ARNs de principais (usuários ou grupos). Uma permissão concedida em Desenvolvimento diz, essencialmente: “o grupo DataAnalysts da conta 111111111111 pode visualizar este dashboard.”

    Após a migração para Qualidade/Testes, três coisas mudam:

    • O dashboard tem um novo ARN (conta diferente).
    • O grupo DataAnalysts da conta 111111111111 não existe na conta 222222222222.
    • Um grupo DataAnalysts em Qualidade/Testes teria um ARN diferente, referenciando o ID da conta de destino.

    Conclusão: permissões precisam ser reestabelecidas em cada ambiente de destino, seja durante a importação ou logo após.

    A cadeia de dependências e a transformação automática de ARNs

    Um dashboard não existe de forma isolada. Ele depende de datasets, que por sua vez dependem de fontes de dados (data sources). Cada um tem seu próprio ARN, e o dashboard referencia todos eles internamente.

    Quando as APIs de Asset Bundle importam um bundle para a conta de destino, elas atualizam automaticamente essas referências internas de ARN para refletir o novo ID de conta. Porém, essa transformação funciona apenas para os ativos incluídos no bundle. Se você importar somente o dashboard sem seus datasets e fontes de dados, ele ficará referenciando recursos que não existem na conta de destino.

    A recomendação da AWS é clara: sempre inclua todas as dependências na exportação, usando IncludeAllDependencies=True.

    Reutilizando recursos existentes com OverrideParameters

    Um cenário comum: o ambiente de Qualidade/Testes já tem uma fonte de dados configurada para o banco de dados de QA. Você não quer criar uma duplicata — quer que o dashboard importado use a conexão existente.

    O parâmetro OverrideParameters na API StartAssetBundleImportJob resolve isso. Ele permite sobrescrever parâmetros de conexão, credenciais e comportamento de IDs de recursos durante a importação:

    response = qs.start_asset_bundle_import_job(
        AwsAccountId='222222222222',
        AssetBundleImportJobId='import-sales-dash-to-qa',
        AssetBundleImportSource={'Body': bundle_bytes},
        OverrideParameters={
            'ResourceIdOverrideConfiguration': {
                'PrefixForAllResources': False
            },
            'DataSources': [{
                'DataSourceId': 'sales-db-connection',
                'DataSourceParameters': {
                    'AthenaParameters': {
                        'WorkGroup': 'qa-workgroup'
                    }
                },
                'Credentials': {
                    'CredentialPair': {
                        'Username': 'qa_service_user',
                        'Password': '{{resolve:secretsmanager:qa-db-creds:SecretString:password}}'
                    }
                }
            }]
        }
    )

    Para credenciais, há três métodos disponíveis: CredentialPair (usuário e senha), CopySourceArn (copiar de uma fonte de dados existente) ou SecretArn (referenciar diretamente um segredo no AWS Secrets Manager). A AWS recomenda o uso de SecretArn quando a organização gerencia credenciais no Secrets Manager:

    'Credentials': {
        'SecretArn': 'arn:aws:secretsmanager:us-east-1:222222222222:secret:qa-db-creds'
    }

    Namespaces: como a identidade funciona em ambientes multi-tenant

    Os namespaces do Amazon Quick oferecem isolamento multi-tenant dentro de uma única conta AWS. São amplamente usados por provedores de Software como Serviço (SaaS — Software as a Service) que embarcam analytics para múltiplos clientes, empresas com fronteiras departamentais rígidas e companhias que precisam isolar populações de usuários.

    O conceito mais importante aqui: namespaces afetam ARNs de principais (usuários e grupos), não ARNs de ativos (dashboards, datasets).

    Mesmo nome de usuário, pessoas diferentes

    Considere dois namespaces na mesma conta: HR e Marketing. Ambos têm um usuário chamado nikki_wolf:

    HR nikki_wolf:        arn:aws:quicksight:us-east-1:444444444444:user/HR/nikki_wolf
    Marketing nikki_wolf: arn:aws:quicksight:us-east-1:444444444444:user/Marketing/nikki_wolf

    São dois principais completamente diferentes. Compartilham o nome de usuário, mas seus ARNs são distintos porque o namespace é diferente. Conceder acesso a um dashboard para o nikki_wolf do HR não dá acesso ao nikki_wolf do Marketing. Sempre use o ARN completo do principal, incluindo o namespace, ao conceder ou depurar permissões.

    Ativos vivem fora dos namespaces; principais vivem dentro

    Os ARNs de ativos não contêm namespace:

    Dashboard ARN (sem namespace): arn:aws:quicksight:us-east-1:444444444444:dashboard/shared-metrics
    User ARN (com namespace):      arn:aws:quicksight:us-east-1:444444444444:user/HR/alice

    Isso é o que viabiliza o compartilhamento entre namespaces: um único dashboard pode ser compartilhado com usuários de múltiplos namespaces, desde que as permissões sejam concedidas com os ARNs completos de cada principal.

    Compartilhamento entre namespaces

    Para compartilhar um dashboard de anúncios com todos os clientes, basta conceder permissões a grupos de diferentes namespaces:

    qs.update_dashboard_permissions(
        AwsAccountId='444444444444',
        DashboardId='platform-announcements',
        GrantPermissions=[
            {
                'Principal': 'arn:aws:quicksight:us-east-1:444444444444:group/HR/Executives',
                'Actions': ['quicksight:DescribeDashboard', 'quicksight:QueryDashboard']
            },
            {
                'Principal': 'arn:aws:quicksight:us-east-1:444444444444:group/Marketing/Executives',
                'Actions': ['quicksight:DescribeDashboard', 'quicksight:QueryDashboard']
            },
            {
                'Principal': 'arn:aws:quicksight:us-east-1:444444444444:group/default/PlatformTeam',
                'Actions': ['quicksight:DescribeDashboard', 'quicksight:QueryDashboard', 'quicksight:UpdateDashboard']
            }
        ]
    )

    Permissões com wildcard por namespace

    O Amazon Quick suporta ARNs com wildcard para concessões de acesso amplas dentro de um namespace:

    arn:aws:quicksight:us-east-1:444444444444:user/HR/*

    Isso concede acesso a todos os usuários atuais e futuros do namespace HR. O wildcard se aplica apenas ao namespace especificado — usuários do Marketing não ganham acesso. Wildcards também funcionam no OverridePermissions durante a importação de asset bundles. A AWS recomenda usá-los com cuidado para permissões de escrita ou administração; para acesso somente leitura, são uma boa opção.

    Fluxo completo: migração de ponta a ponta

    Aqui está um exemplo completo combinando todos os conceitos anteriores. O cenário: uma empresa migrando sua suíte de Analytics de Vendas do ambiente de Desenvolvimento para Produção, com três dashboards, cinco datasets, duas fontes de dados (Amazon Athena e Amazon Redshift) e usuários em dois namespaces (SalesTeam e Executives).

    Passo 1: Exportar do ambiente de desenvolvimento

    export_response = qs.start_asset_bundle_export_job(
        AwsAccountId='111111111111',
        AssetBundleExportJobId='sales-analytics-export',
        ResourceArns=[
            'arn:aws:quicksight:us-east-1:111111111111:dashboard/sales-overview',
            'arn:aws:quicksight:us-east-1:111111111111:dashboard/sales-details',
            'arn:aws:quicksight:us-east-1:111111111111:dashboard/sales-trends'
        ],
        IncludeAllDependencies=True,
        ExportFormat='QUICKSIGHT_JSON'
    )

    Passo 2: Importar para produção com overrides

    import_response = qs.start_asset_bundle_import_job(
        AwsAccountId='333333333333',
        AssetBundleImportJobId='sales-analytics-import',
        AssetBundleImportSource={'Body': bundle_bytes},
        OverrideParameters={
            'ResourceIdOverrideConfiguration': {
                'PrefixForAllResources': False
            },
            'DataSources': [
                {
                    'DataSourceId': 'dev-athena-source',
                    'Name': 'Production Athena',
                    'DataSourceParameters': {
                        'AthenaParameters': {'WorkGroup': 'prod-workgroup'}
                    }
                },
                {
                    'DataSourceId': 'dev-redshift-source',
                    'Name': 'Production Redshift',
                    'DataSourceParameters': {
                        'RedshiftParameters': {
                            'Host': 'prod-cluster.xxxxx.us-east-1.redshift.amazonaws.com',
                            'Database': 'analytics',
                            'Port': 5439
                        }
                    },
                    'Credentials': {
                        'SecretArn': 'arn:aws:secretsmanager:us-east-1:333333333333:secret:prod-db-creds'
                    }
                }
            ]
        },
        OverridePermissions={
            'Dashboards': [{
                'DashboardIds': ['sales-overview', 'sales-details', 'sales-trends'],
                'Permissions': {
                    'Principals': [
                        'arn:aws:quicksight:us-east-1:333333333333:user/SalesTeam/*'
                    ],
                    'Actions': ['quicksight:DescribeDashboard', 'quicksight:QueryDashboard']
                }
            }]
        }
    )

    Usar OverridePermissions junto com OverrideParameters define as permissões durante a importação, reduzindo a janela em que recursos existem sem controles de acesso adequados.

    Passo 3: Conceder permissões granulares adicionais

    qs.update_dashboard_permissions(
        AwsAccountId='333333333333',
        DashboardId='sales-trends',
        GrantPermissions=[{
            'Principal': 'arn:aws:quicksight:us-east-1:333333333333:group/Executives/Leadership',
            'Actions': ['quicksight:DescribeDashboard', 'quicksight:QueryDashboard']
        }]
    )

    Referência rápida: formatos de ARN

    ARNs de ativos (sem namespace):

    • Dashboard: arn:aws:quicksight:{region}:{account}:dashboard/{id}
    • Analysis: arn:aws:quicksight:{region}:{account}:analysis/{id}
    • Dataset: arn:aws:quicksight:{region}:{account}:dataset/{id}
    • Data Source: arn:aws:quicksight:{region}:{account}:datasource/{id}
    • Theme: arn:aws:quicksight:{region}:{account}:theme/{id}
    • Folder: arn:aws:quicksight:{region}:{account}:folder/{id}
    • Topic: arn:aws:quicksight:{region}:{account}:topic/{id}

    ARNs de principais (com namespace):

    • Usuário: arn:aws:quicksight:{region}:{account}:user/{namespace}/{username}
    • Grupo: arn:aws:quicksight:{region}:{account}:group/{namespace}/{groupname}
    • Wildcard (todos os usuários do namespace): arn:aws:quicksight:{region}:{account}:user/{namespace}/*

    Funções utilitárias para scripts de migração

    A AWS disponibiliza funções Python para facilitar a manipulação de ARNs em scripts e pipelines de Integração e Entrega Contínua (CI/CD — Continuous Integration/Continuous Delivery):

    def parse_asset_arn(arn: str) -> dict:
        """Parse an Amazon Quick asset ARN into components."""
        parts = arn.split(':')
        resource_parts = parts[5].split('/', 1)
        return {
            'region': parts[3],
            'account_id': parts[4],
            'resource_type': resource_parts[0],
            'resource_id': resource_parts[1]
        }
    
    def parse_principal_arn(arn: str) -> dict:
        """Parse an Amazon Quick principal ARN into components."""
        parts = arn.split(':')
        resource_parts = parts[5].split('/')
        return {
            'region': parts[3],
            'account_id': parts[4],
            'principal_type': resource_parts[0],
            'namespace': resource_parts[1],
            'principal_name': resource_parts[2]
        }
    
    def transform_arn_for_account(source_arn: str, target_account: str) -> str:
        """Transform an ARN to a different account."""
        parsed = parse_asset_arn(source_arn)
        return f"arn:aws:quicksight:{parsed['region']}:{target_account}:{parsed['resource_type']}/{parsed['resource_id']}"
    
    def build_principal_arn(account: str, namespace: str, principal_type: str, name: str, region: str = 'us-east-1') -> str:
        """Build a principal ARN."""
        return f"arn:aws:quicksight:{region}:{account}:{principal_type}/{namespace}/{name}"

    Guia de troubleshooting para problemas comuns

    “Resource not found” após migração

    Sintoma: Dashboard carrega, mas exibe erros de “Dataset not found”. Causa: O dashboard referencia um ARN de dataset da conta de origem, ou as dependências não foram incluídas no bundle. Solução: Verifique se todas as dependências foram exportadas com IncludeAllDependencies=True e confirme que o job de importação foi concluído com sucesso via DescribeAssetBundleImportJob.

    “Access denied” para usuário que deveria ter acesso

    Sintoma: Usuário não consegue ver um dashboard compartilhado com ele. Diagnóstico: Verifique em qual namespace o usuário está e se o ARN do principal no grant corresponde exatamente ao ARN real do usuário:

    # Check what permissions exist
    perms = qs.describe_dashboard_permissions(
        AwsAccountId=account_id,
        DashboardId='the-dashboard'
    )
    print("Granted to:", [p['Principal'] for p in perms['Permissions']])
    
    # Check the user's actual ARN
    user = qs.describe_user(
        AwsAccountId=account_id,
        Namespace='Finance',
        UserName='nikki_wolf'
    )
    print("User ARN:", user['User']['Arn'])

    Atenção: Se o recurso estiver em uma pasta restrita, não é possível compartilhá-lo diretamente, independentemente da correção do ARN. O acesso a recursos em pastas restritas só ocorre por meio das permissões do container da hierarquia da pasta restrita.

    “Invalid principal” ao conceder permissões

    Sintoma: A API retorna erro ao tentar conceder permissões. Causa: O ARN do principal está malformado, ou o usuário/grupo não existe no namespace especificado. Solução: Verifique se o principal existe antes de conceder permissões:

    try:
        qs.describe_user(
            AwsAccountId=account_id,
            Namespace='Finance',
            UserName='nikki_wolf'
        )
        print("User exists, safe to grant permissions")
    except qs.exceptions.ResourceNotFoundException:
        print("User does not exist in this namespace")

    Os quatro pontos fundamentais sobre ARNs no Amazon Quick

    O guia da AWS resume o entendimento de ARNs no Amazon Quick em quatro conceitos-chave:

    • ARNs são vinculados à conta. Ao migrar entre contas, o endereço muda mesmo que o ID do recurso permaneça igual.
    • Permissões referenciam ARNs completos, não nomes. Conceder acesso a um usuário exige especificar conta e namespace — você sempre está concedendo a um ARN específico.
    • Ativos vivem fora dos namespaces; principais vivem dentro. Isso viabiliza o compartilhamento entre namespaces, mas exige ARNs completos de principais em toda operação.
    • O mesmo nome de usuário em namespaces diferentes representa pessoas diferentes. A migração muda ARNs mas preserva IDs de recursos; as APIs de Asset Bundle cuidam das atualizações de referências internas.

    Próximos passos

    Para começar a aplicar esses conceitos no seu ambiente, a AWS recomenda:

    Fonte

    Amazon Quick ARNs: Cross-account migration and namespace permissions (https://aws.amazon.com/blogs/machine-learning/amazon-quick-arns-cross-account-migration-and-namespace-permissions/)

  • Operacionalizando a segurança AWS: um roteiro de maturidade em 6 fases

    Habilitar não é o mesmo que operar

    Ativar ferramentas de segurança é apenas o começo. O verdadeiro desafio — onde a maioria das organizações trava — é fazer com que essas ferramentas dirijam decisões reais: tempos de resposta mensuráveis, postura de segurança melhorando semana a semana, e alertas que chegam às pessoas certas na hora certa.

    A AWS publicou um roteiro de maturidade operacional voltado para organizações que já habilitaram o AWS Security Hub e o Amazon GuardDuty. Esses dois serviços formam a base de uma operação de segurança centrada na nuvem: o Security Hub centraliza o gerenciamento de postura e agrega alertas de múltiplos serviços, enquanto o GuardDuty monitora continuamente atividades maliciosas e comportamentos não autorizados.

    Se você ainda não habilitou esses serviços, a documentação do Security Hub e a documentação do GuardDuty cobrem a configuração inicial, incluindo implantação multi-conta com o AWS Organizations.

    O roteiro a seguir não explica como cada funcionalidade trabalha — a documentação já faz isso bem. O foco aqui é quando e por que usar cada capacidade, e como construir os hábitos organizacionais que tornam tudo isso efetivo.

    Fase 0: Avalie o estado atual

    Objetivo: entender o que está funcionando antes de mudar qualquer coisa.
    Prazo estimado: 1 a 2 semanas.

    Antes de introduzir novos processos ou automações, é essencial ter uma visão clara do ambiente. Essa avaliação orienta todas as decisões seguintes. Os pontos a verificar são:

    • Inventário de alertas: quantos alertas ativos do GuardDuty existem, qual a distribuição por severidade e qual é o mais antigo. Um backlog grande de alertas CRÍTICOS ou ALTOS sem revisão há semanas é um sinal claro de onde focar.
    • Baseline do Security Hub: qual é o score atual contra as Práticas de Segurança Fundamentais da AWS (FSBP) e o CIS AWS Foundations Benchmark. Verificar quais padrões estão habilitados e se há sobreposições criando ruído.
    • Cobertura multi-conta e multi-região: o GuardDuty está habilitado em todas as contas e regiões? Agentes de ameaça frequentemente operam em regiões que as organizações não monitoram ativamente. Verificar também se o Security Hub está configurado com uma conta de administrador delegado.
    • Integrações: os alertas do GuardDuty estão fluindo para o Security Hub? O Amazon Inspector e o Amazon Macie estão habilitados e alimentando alertas?
    • Notificações: existe uma regra de Amazon EventBridge configurada? Os alertas estão sendo roteados para algum canal — seja um tópico do Amazon Simple Notification Service (Amazon SNS) ou uma integração de chat? Sem esse fluxo, alertas se acumulam silenciosamente no console sem que ninguém olhe.

    Entregável: uma avaliação de uma página identificando o que está habilitado, o que está fluindo para onde, quem está revisando e qual é o backlog existente.

    Fase 1: Reduza o ruído

    Objetivo: tornar o sinal significativo antes de pedir que alguém aja sobre ele.
    Prazo estimado: 2 a 3 semanas.

    Esta é a fase mais importante de todo o roteiro. Pular essa etapa em favor de automação resulta em caos automatizado. A fadiga de alertas é o principal motivo pelo qual ferramentas de segurança são ignoradas.

    Ajuste fino do GuardDuty

    Crie regras de supressão para alertas sabidamente benignos — como tráfego esperado de IPs corporativos (usando listas de IPs confiáveis), ferramentas internas que disparam alertas de DNS, ou recursos expostos à internet que recebem varreduras de porta naturalmente. Se você investigou um alerta e ele é esperado, suprima-o.

    Triar todos os alertas ALTOS e CRÍTICOS ativos em três categorias: (1) precisa de investigação imediata, (2) verdadeiro positivo já endereçado (arquivar via status de fluxo de trabalho), ou (3) falso positivo ou comportamento esperado (criar regra de supressão).

    Revisar também os planos de proteção do GuardDuty. Organizações que habilitaram o serviço há anos podem não ter ativado planos lançados depois, como Runtime Monitoring, Malware Protection, RDS Protection e Lambda Protection.

    Ajuste fino do Security Hub

    Desabilitar controles irrelevantes para o ambiente é o ganho rápido de maior valor. Um score de 47% onde metade das falhas são irrelevantes treina as equipes a ignorar o painel completamente. Consulte a referência de controles do Security Hub para a lista completa.

    Escolher um padrão primário: o FSBP é uma boa escolha padrão. O CIS Benchmark agrega valor quando há mandato de conformidade específico. Evitar habilitar PCI DSS ou NIST 800-53 sem requisito de reporte — eles adicionam volume sem sinal proporcional.

    Configurar a agregação entre regiões para a conta de administrador delegado, eliminando a necessidade de verificar alertas em múltiplos consoles regionais.

    Usar o campo de status de fluxo de trabalho operacionalmente: alertas devem progredir de NOVO para NOTIFICADO para RESOLVIDO ou SUPRIMIDO. Se tudo permanece em NOVO indefinidamente, o sistema não tem significado operacional.

    Fase 2: Construa a camada de notificação e roteamento

    Objetivo: levar os alertas certos às pessoas certas no momento certo.
    Prazo estimado: 2 a 3 semanas.

    A arquitetura recomendada é: Security Hub → regra do EventBridge → lógica de roteamento → destino. A estratégia de notificação deve ser em camadas por severidade:

    • CRÍTICO: acionar on-call imediatamente (PagerDuty ou Opsgenie) — SLA de 15 minutos.
    • ALTO: alertar canal da equipe de segurança e criar ticket (Slack/Teams + Jira/ServiceNow) — SLA de 4 horas.
    • MÉDIO: criar ticket para revisão — SLA de 48 horas.
    • BAIXO/INFORMACIONAL: digest semanal ou revisão por dashboard.

    Decisões de design importantes: rotear a partir do Security Hub, não dos serviços individuais, pois todos os alertas agregam lá. Criar um caminho rápido para tipos de alertas mais perigosos — especialmente os do GuardDuty envolvendo exfiltração de credenciais, atividade de criptomoedas, trojans e comprometimentos ativos — consultando a referência de tipos de alertas do GuardDuty.

    Enriquecer notificações antes da entrega usando uma função do AWS Lambda para formatar alertas com alias da conta, região, Nome de Recurso da Amazon (ARN), tipo de alerta, severidade, link direto para o console e descrição em linguagem simples. O guia de integração do Security Hub com CloudWatch Events descreve o formato do evento.

    Fase 3: Construa remediação automatizada para alertas de alta confiança

    Objetivo: para alertas onde a resposta correta é determinística, remover o humano do loop.
    Prazo estimado: 3 a 4 semanas.

    O princípio orientador: auto-remediar apenas quando três condições são atendidas simultaneamente — o alerta é de alta confiança, a resposta é determinística, e o raio de impacto da ação automatizada é limitado.

    Categorias comuns de auto-remediação:

    • Isolamento de instância para comprometimentos confirmados (mineração de criptomoeda, malware, trojans): substituir o grupo de segurança, tirar snapshot dos volumes para forense e notificar.
    • Revogação de credenciais para comprometimento confirmado: anexar políticas de negação total, revogar sessões e desativar chaves de acesso.
    • Correção de desvio de conformidade para configurações incorretas determinísticas: reabilitar o bloqueio de acesso público do Amazon Simple Storage Service (Amazon S3), revogar regras de grupo de segurança excessivamente permissivas, reabilitar o AWS CloudTrail.
    • Escalação apenas por notificação para alertas que exigem julgamento humano: lacunas de criptografia no Amazon Elastic Block Store (Amazon EBS) e rotação de chaves de acesso.

    Para implementação, a AWS disponibiliza o Security Hub Automated Response and Remediation (SHARR), uma solução com playbooks de remediação pré-construídos implantados como workflows do AWS Step Functions acionados pelo EventBridge. Para alertas recorrentes por falta de controles preventivos, a melhor resposta de longo prazo costuma ser uma política de controle de serviço (SCP) que impede a configuração incorreta de ocorrer.

    Fase 4: Construa o ritmo operacional

    Objetivo: transformar o gerenciamento de alertas em uma prática organizacional sustentada, não uma limpeza pontual.
    Prazo estimado: 4 a 6 semanas para estabelecer, depois contínuo.

    Esta é a fase onde a maioria das organizações trava — e a mais importante de todo o roteiro. A tecnologia está funcionando, as notificações estão fluindo, as remediações automáticas estão disparando, mas não há hábito organizacional construído em torno disso. Sem esta fase, tudo que foi construído nas fases anteriores vai gradualmente se deteriorar.

    Revisão semanal de segurança (30 minutos)

    Participantes: líder da equipe de segurança, representante da equipe de plataforma de nuvem e um líder de engenharia rotativo de uma equipe de aplicação. A rotatividade do representante de engenharia é fundamental: ela constrói consciência de segurança em toda a organização, garante que alertas cheguem a quem tem contexto para resolvê-los, e cria responsabilidade além da equipe de segurança.

    Pauta sugerida:

    • 5 min — Tendência do score de conformidade: está melhorando, caindo ou estagnado?
    • 5 min — Revisão de alertas CRÍTICOS e ALTOS: algum precisa de escalação imediata?
    • 10 min — Top 5 controles com mais falhas: atribuir dono e data-alvo para cada.
    • 5 min — Revisão de automações: alguma disparou esta semana? Funcionou corretamente?
    • 5 min — Decisões de ajuste: novas regras de supressão necessárias? Novos candidatos à auto-remediação?

    Métricas mensais

    As métricas a acompanhar mensalmente incluem: Tempo Médio para Reconhecimento (MTTA) de alertas CRÍTICOS, Tempo Médio para Resolução (MTTR) de alertas CRÍTICOS e ALTOS, score de conformidade do Security Hub por padrão e por conta, número de alertas ativos do GuardDuty por severidade, proporção de alertas auto-remediados versus resolvidos manualmente, e taxa de adesão aos Acordos de Nível de Serviço (SLAs) por severidade.

    Para visualização, a AWS sugere usar dashboards do Amazon CloudWatch para visibilidade operacional em tempo real, ou o Amazon QuickSight conectado ao Security Hub via Amazon Security Lake para análise histórica e relatórios executivos.

    Revisões trimestrais

    A revisão trimestral é uma inspeção mais profunda do sistema em si — não apenas dos alertas, mas da maquinaria que os processa. O checklist inclui: auditoria de regras de supressão (a condição subjacente ainda existe?), auditoria de controles desabilitados (a justificativa ainda é válida?), revisão de funções do AWS Identity and Access Management (IAM) usadas por funções de remediação, e avaliação de novos planos de proteção e controles lançados no trimestre.

    Rubrica de maturidade operacional

    A AWS propõe pontuar seis dimensões de 1 a 3 para avaliar a maturidade do ritmo operacional: cadência de revisão, rastreamento de métricas, propriedade de alertas, gestão de automação, ciclo de vida de ajuste e engajamento entre equipes. A pontuação total classifica a organização em: Iniciando (6–9), Estabelecida (10–14) ou Otimizada (15–18).

    Entregável: uma cadência operacional documentada com propriedade clara (considere uma matriz RACI), dashboards de métricas, procedimentos de escalação e um ciclo de melhoria contínua. A cadência deve sobreviver à rotatividade da equipe — se depende de uma pessoa lembrar de executá-la, ainda não é operacional.

    Fase 5: Amadureça a arquitetura

    Objetivo: preencher lacunas remanescentes e construir em direção a uma capacidade abrangente de operações de segurança.
    Prazo estimado: contínuo, priorizado pelo perfil de risco organizacional.

    • Amazon Inspector: habilitar para instâncias EC2, funções Lambda e imagens de container no Amazon Elastic Container Registry (Amazon ECR). Os alertas fluem automaticamente para o Security Hub, adicionando gerenciamento de vulnerabilidades.
    • Amazon Macie: habilitar para buckets S3 com dados potencialmente sensíveis. Especialmente importante para organizações com requisitos de conformidade em torno de Informações de Identificação Pessoal (PII), informações de saúde protegidas (PHI) ou dados de Payment Card Industry (PCI). Configurar a descoberta automatizada de dados sensíveis.
    • Amazon Security Lake: centraliza logs relevantes de segurança no formato OCSF para retenção de longo prazo, investigação forense e caça a ameaças.
    • Camada de controles preventivos: converter alertas detectivos recorrentes em políticas preventivas usando SCPs para impedir desabilitar GuardDuty, Security Hub e CloudTrail; limites de permissão IAM em papéis de desenvolvedores; AWS WAF em endpoints públicos; e AWS Network Firewall para inspeção de tráfego de VPC.
    • Expansão de controles detectivos: AWS IAM Access Analyzer para alertas de acesso externo e acesso não utilizado; AWS CloudTrail Lake para logs de auditoria consultáveis de longo prazo; e regras customizadas do AWS Config para verificações de conformidade específicas da organização.
    • Prontidão para resposta a incidentes: playbooks referenciando tipos específicos de alertas do GuardDuty, infraestrutura forense pré-construída, exercícios de simulação regulares e templates do AWS CloudFormation para implantar infraestrutura de isolamento sob demanda. O Guia de Resposta a Incidentes de Segurança da AWS oferece um framework abrangente.

    Por onde começar agora

    O roteiro completo não precisa ser executado de uma vez. As fases 0 e 1 podem ser concluídas em 3 a 5 semanas e entregam clareza imediata. As fases 2 e 3 constroem a infraestrutura de resposta nas 5 a 7 semanas seguintes. A fase 4 é o que torna tudo sustentável — e merece a maior atenção.

    Se você pudesse fazer uma coisa agora: execute a avaliação da Fase 0 esta semana. Esse único entregável diz exatamente onde focar a seguir. Um ambiente ajustado com notificações funcionando e uma cadência semanal de revisão é dramaticamente mais efetivo do que um deployment repleto de recursos, mas negligenciado.

    Para aprofundar, a AWS disponibiliza o Guia do Usuário do AWS Security Hub, o Guia do Usuário do Amazon GuardDuty e o Guia de Resposta a Incidentes de Segurança da AWS.

    Fonte

    Operationalizing AWS security: A maturity roadmap (https://aws.amazon.com/blogs/security/operationalizing-aws-security-a-maturity-roadmap/)

  • Resumo de Segurança AWS: Maio de 2026

    O que aconteceu na segurança AWS em maio de 2026

    Todo mês a AWS publica um digest consolidando as principais novidades de segurança: posts técnicos, recursos novos, repositórios de código e boletins de vulnerabilidades. O de maio de 2026 chegou com um tema central bem claro: a segurança de IA deixou de ser algo pontual e passou a exigir proteção em toda a pilha — do modelo ao fluxo agêntico, passando por políticas de autorização e conformidade regulatória.

    A seguir, a CloudTroop comenta cada bloco de conteúdo publicado pela AWS neste mês.

    Posts do Blog de Segurança AWS

    Segurança de IA

    Quatro posts abordaram o tema de segurança em ambientes de inteligência artificial, cobrindo desde fundamentos até frameworks estruturados.

    Segurança de Infraestrutura

    Quatro posts cobriram proteção de rede, análise de tráfego e migração de arquitetura de firewall.

    Gerenciamento de Identidade

    Dois posts abordaram roteamento regional e automação do ciclo de vida de identidades.

    Governança e Conformidade

    Cinco posts cobriram novos guias de conformidade, governança de infraestrutura como código e importação de dados históricos de auditoria.

    Proteção de Dados

    Detecção e Resposta a Ameaças

    Três posts cobriram mineração de criptomoedas, segurança da cadeia de suprimentos de software e o AWS Security Hub Extended.

    Segurança de Aplicações

    Treinamento e Capacitação

    Boletins de Segurança de Maio

    A AWS publicou investigações sobre vulnerabilidades de segurança reportadas em serviços, softwares e produtos Amazon e AWS. Abaixo estão os boletins do mês:

    AWS Samples: novos repositórios do mês

    Maio trouxe 8 novos repositórios no AWS Samples, cobrindo segurança de aplicações, proteção de dados, segurança de infraestrutura, governança e segurança de IA.

    Segurança de Aplicações

    Proteção de Dados

    • Auditoria de acesso ao KMS — Resolve e reporta quem pode usar suas chaves do AWS Key Management Service (KMS) em políticas do IAM, políticas de chave e concessões, com resolução do IAM Identity Center para identificar as pessoas por trás de roles de SSO.

    Segurança de Infraestrutura

    Governança

    Segurança de IA

    AWS Labs: novo repositório de governança

    Maio trouxe também 1 novo repositório no AWS Labs, focado em governança para instituições de pesquisa.

    O que maio de 2026 sinaliza

    O digest de maio mostra que a segurança de IA está amadurecendo: saiu do nível de controles de modelo e avançou para proteção de pilha completa em fluxos agênticos. Os posts e amostras trazem padrões para autorização baseada em políticas com Cedar, filtragem de tráfego de rede por categoria e monitoramento de conformidade entre contas. Os boletins de segurança endereçam vulnerabilidades em SDKs, drivers e ferramentas para desenvolvedores. Cada recurso inclui passos de implantação ou código executável para que as equipes possam validar em seus próprios ambientes antes de adotar.

    Para acompanhar as atualizações conforme são publicadas, a AWS disponibiliza o feed RSS do Blog de Segurança AWS.

    Fonte

    ICYMI: May 2026 @AWS Security (https://aws.amazon.com/blogs/security/icymi-may-2026-aws-security/)

  • Inferência de Machine Learning com Criptografia Ponta a Ponta no Amazon SageMaker AI e FHE

    O problema: como processar dados sensíveis na nuvem sem expô-los?

    Inferência de aprendizado de máquina (ML) frequentemente envolve informações altamente sensíveis — prontuários médicos, dados corporativos proprietários ou comunicações pessoais. A grande questão é: como aproveitar a escalabilidade da nuvem sem entregar esses dados a terceiros?

    A AWS publicou uma abordagem técnica que responde exatamente a isso: usar o Amazon SageMaker AI combinado com Criptografia Totalmente Homomórfica (FHE — Fully Homomorphic Encryption) para executar inferência de ML com os dados permanecendo criptografados durante todo o processo — inclusive enquanto o modelo está processando a consulta. Nem o próprio SageMaker AI tem acesso ao conteúdo em texto simples.

    O que é Criptografia Totalmente Homomórfica (FHE)?

    FHE é uma forma de criptografia que permite realizar operações matemáticas diretamente sobre dados criptografados, sem precisar descriptografá-los. No contexto de ML, isso significa que um modelo pode receber uma consulta cifrada, processá-la e devolver uma predição também cifrada — sem jamais ver o conteúdo original. Apenas o cliente, que possui a chave privada, consegue descriptografar o resultado.

    Essa abordagem é diferente — e complementar — a ambientes de computação confidencial como o Nitro System da AWS no Amazon EC2. Com o AWS Nitro Enclaves, os dados são descriptografados e processados em ambientes isolados de hardware. Com FHE, os dados nunca são descriptografados: a segurança é garantida pela matemática, não pelo hardware.

    Casos de uso práticos

    A AWS ilustra três cenários onde essa capacidade é especialmente valiosa:

    • Saúde: uma operadora de plano de saúde quer oferecer a médicos um modelo que prediz resultados de procedimentos com base em dados diagnósticos. Publicar o modelo na nuvem simplifica a operação, mas regulações de privacidade impedem expor dados de pacientes a terceiros.
    • Setor de energia: uma empresa de petróleo e gás usa ML para avaliar fotos de satélite de possíveis locais de perfuração. Hospedar o modelo na nuvem reduz custos, mas as imagens envolvem locais politicamente sensíveis.
    • Telecomunicações: uma operadora quer processar e-mails de clientes para detectar spam e phishing. A escala exige ML na nuvem, mas regulações de proteção de dados exigem que as mensagens permaneçam criptografadas em terceiros.

    A biblioteca concrete-ml: uma abordagem de alto nível

    Um post anterior no blog da AWS já havia abordado FHE para inferência no SageMaker, mostrando como implementar um algoritmo de regressão linear do zero usando a biblioteca de baixo nível SEAL. Desta vez, a abordagem é mais flexível: usa a concrete-ml, uma biblioteca de alto nível desenvolvida especificamente para inferência com FHE, compatível com a API do scikit-learn e que suporta vários tipos de modelos prontos para uso.

    Vale destacar: a concrete-ml é disponibilizada pela Zama para prototipagem ou uso não comercial sem licença paga. Para uso comercial, pode ser necessária uma licença comercial.

    Visão geral da solução

    O fluxo completo da solução funciona da seguinte forma:

    • O dono do modelo prepara e normaliza os dados de treinamento (por exemplo, para a escala [-1, 1]).
    • O modelo é treinado em uma versão habilitada para FHE — projetada para operar sobre dados criptografados.
    • O modelo é hospedado no SageMaker AI.
    • Clientes criptografam suas consultas usando o esquema FHE compatível com o modelo.
    • As consultas criptografadas são enviadas ao endpoint, que as processa sem descriptografar nenhum valor.
    • O endpoint retorna a predição criptografada ao cliente, que a descriptografa localmente.

    Pré-requisitos

    Para implementar essa solução, são necessários:

    Políticas de IAM para essas roles, junto com um exemplo funcional usando o corpus MNIST de dígitos manuscritos, estão disponíveis no repositório de código de exemplo.

    Treinamento

    Container de treinamento

    O container de treinamento é construído a partir de uma imagem python:3.12, com as dependências sagemaker_training, concrete-ml, concrete-python e torch instaladas. A atenção à paridade de versões entre Python, concrete-ml e concrete-python é obrigatória — a biblioteca exige consistência em todo o sistema.

    O Dockerfile.training tem o seguinte conteúdo:

    FROM python:3.12
    RUN apt-get update && apt-get upgrade -y && apt-get clean
    RUN apt-get -y install --no-install-recommends cmake
    RUN pip install sagemaker_training==5.1.1 concrete-ml==1.9.0 concrete-python==2.10.0 torch==2.3.1

    Após construir a imagem localmente, ela deve ser enviada ao Amazon ECR com os comandos de autenticação, tag e push padrão.

    Script de treinamento

    O treinamento com concrete-ml não difere de qualquer outro framework de ML — e o container de treinamento funciona como qualquer outro container de treinamento customizado. O treinamento ocorre sobre dados em texto simples; a concrete-ml não exige pré-processamento além da normalização. O training_script.py segue este template:

    import argparse
    import os
    import numpy
    from concrete.ml.sklearn import <Model class to train>
    from concrete.ml.deployment import FHEModelDev
    
    def do_training(model_dir, train):
        # Load your data from the train directory
        # Train your model instance, then save it
        # with the following line.
        FHEModelDev(model_dir, model).save()
    
    def model_fn(model_dir):
        # SageMaker AI requires this function exist but doesn't use it
        raise NotImplementedError
    
    if __name__ == '__main__':
        parser = argparse.ArgumentParser()
        parser.add_argument('--model-dir', type=str, default=os.environ['SM_MODEL_DIR'])
        parser.add_argument('--train', type=str, default=os.environ['SM_CHANNEL_TRAINING'])
        args = parser.parse_args()
        do_training(args.model_dir, args.train)

    Framework customizado e execução do job

    Para integrar o container ao SageMaker AI, a AWS recomenda criar um framework customizado. O framework.py encapsula as configurações do container e simplifica o lançamento do job de treinamento.

    O job é iniciado com o start_training.py, que usa a instância ml.m5.xlarge para modelos pequenos ou ml.m5.4xlarge para modelos maiores. Após a conclusão, dois arquivos são salvos no bucket S3: server.zip (usado pelo endpoint de inferência) e client.zip (usado pelos clientes para criptografar consultas).

    Inferência

    Desafios técnicos específicos do FHE

    A inferência baseada em FHE traz algumas restrições técnicas novas em relação à inferência padrão:

    • Clientes precisam do client.zip para gerar chaves criptográficas.
    • Textos cifrados FHE podem ultrapassar os limites de tamanho de requisição do SageMaker AI — portanto, cliente e serviço precisam trocá-los via Amazon S3.
    • A avaliação FHE pode demorar mais do que os timeouts padrão do SageMaker AI, exigindo o uso de inferência assíncrona.
    • O endpoint precisa de uma chave de avaliação (um tipo de chave pública) fornecida pelo cliente para executar a avaliação FHE.

    Predictor do endpoint

    O predictor.py é um servidor Flask que recebe um JSON com dois URIs do S3 — um para a consulta criptografada e outro para a chave de avaliação. Ele baixa esses arquivos, executa o modelo FHE sobre eles e retorna a predição criptografada. O container de inferência inclui ainda os arquivos de boilerplate (nginx.conf, serve e wsgi.py) necessários para containers de inferência customizados no SageMaker. É importante aumentar o valor de timeout no nginx.conf para permitir que a avaliação FHE seja concluída.

    O Dockerfile.inference instala nginx, Flask, gunicorn, sagemaker, concrete-ml e concrete-python sobre a imagem base python:3.12.

    Deploy do endpoint

    O endpoint é implantado com configuração de inferência assíncrona. O start_inference_endpoint.py configura o modelo com a URI da imagem ECR, o caminho do modelo no S3 e a role IAM do endpoint. A instância mínima recomendada é ml.m5.xlarge; para melhor desempenho, ml.m5.24xlarge. Atenção: endpoints geram cobranças contínuas até serem excluídos. Consulte a tabela de preços do Amazon SageMaker AI e lembre-se de deletar o endpoint ao final dos testes.

    Cliente de inferência

    O client.py abstrai todos os detalhes de FHE do usuário final. Seu fluxo é:

    • Baixar o client.zip do S3.
    • Gerar as chaves privada e de avaliação.
    • Criptografar a consulta e fazer upload da consulta cifrada e da chave de avaliação para o S3.
    • Enviar os URIs ao endpoint e aguardar a resposta assíncrona.
    • Baixar a predição criptografada e descriptografá-la localmente.

    Uma observação de design: cliente e endpoint tratam consultas e respostas de forma diferente. A resposta criptografada é uma sequência de bytes que o SageMaker AI gerencia naturalmente. Já a consulta do cliente é uma estrutura JSON que precisa conter o URI da chave de avaliação — embutir a consulta criptografada nesse JSON exigiria codificação (como Base64), adicionando processamento desnecessário. Por isso, o código de exemplo gerencia o upload da consulta criptografada diretamente no S3.

    Desempenho e considerações de segurança

    FHE oferece proteção criptográfica robusta, mas com um custo de desempenho significativo. A sobrecarga pode chegar a 100.000x em relação à inferência em texto simples. Algumas formas de reduzir esse impacto:

    • Aumentar o número de vCPUs da instância.
    • Quantização: técnica de ML que reduz a precisão numérica usada na inferência. Como o tempo de execução do concrete-ml cresce com a precisão, a quantização tem impacto ainda maior aqui do que em ML convencional. A quantização pode reduzir a acurácia do modelo, mas não é afetada pela conversão para FHE. Nos testes descritos, a quantização no código do modelo reduziu a sobrecarga para 2800x (de 67ms para 187s em uma instância ml.m5.xlarge) sem perda observável de acurácia. Aumentando os vCPUs, é possível chegar a 500x (46s em uma ml.m5.24xlarge).

    Por isso, FHE ainda não é adequado para aplicações interativas sensíveis à latência. No entanto, é prático para cargas de trabalho assíncronas ou em lote, onde os requisitos de privacidade superam as preocupações com latência — exatamente o perfil dos três casos de uso apresentados.

    Limitações de segurança importantes

    • É fundamental que os clientes mantenham em segredo as consultas descriptografadas e as predições, pois a combinação de um texto cifrado com seu texto simples pode revelar informações sobre a chave secreta.
    • Esta solução não protege o sigilo do modelo. As consultas e respostas ficam opacas ao SageMaker AI, mas o modelo em si pode ser visível ao serviço. O modelo também pode ser vulnerável a ataques de “roubo de modelo” por quem tiver acesso a consultas e respostas em texto simples.
    • O concrete-ml não fornece privacidade de circuito: informações sobre o modelo podem ser reveladas pelos textos cifrados.

    A segurança é uma responsabilidade compartilhada entre a AWS e cada cliente. As boas práticas incluem: aplicar o princípio do menor privilégio nas roles IAM; habilitar criptografia padrão nos buckets S3 para valores que não sejam textos cifrados FHE; e restringir permissões dos buckets ao mínimo necessário.

    Limpeza de recursos

    Para evitar cobranças desnecessárias após os testes, é necessário excluir: o endpoint de inferência, a configuração do endpoint, o modelo no SageMaker AI, os artefatos no S3 (modelo, consultas cifradas, respostas cifradas e chaves de avaliação) e as imagens de container no ECR.

    Problemas comuns

    • TimeoutError durante inferência: aumente o max_attempts no WaiterConfig ou use um tipo de instância maior.
    • Erros de AccessDenied: verifique se as roles IAM têm as permissões corretas para S3 e SageMaker AI.
    • Falhas na construção do container: verifique se o Docker tem memória suficiente (acima de 8 GB).
    • Erros de servidor durante inferência: verifique a paridade de versões dos pacotes concrete-ml.

    Conclusão

    A combinação de SageMaker AI com FHE via concrete-ml permite realizar inferência sobre dados que permanecem criptografados do início ao fim do processo. Essa abordagem une a agilidade, escala e infraestrutura gerenciada do SageMaker AI com proteção criptográfica que vai da consulta até a resposta. Para cenários onde a privacidade dos dados é inegociável — saúde, energia, telecomunicações — essa arquitetura oferece um caminho concreto e implementável.

    Para aprofundamento, a AWS disponibiliza recursos adicionais:

    Fonte

    End-to-end encrypted ML inference with Amazon SageMaker AI and FHE (https://aws.amazon.com/blogs/machine-learning/end-to-end-encrypted-ml-inference-with-amazon-sagemaker-ai-and-fhe/)

  • Permissões simplificadas para Amazon S3 Tables e views materializadas Iceberg chegam às regiões AWS GovCloud (US)

    O que foi anunciado

    A AWS anunciou que as permissões simplificadas para o Amazon S3 Tables e para as views materializadas do Apache Iceberg agora estão disponíveis nas regiões AWS GovCloud (US). A novidade envolve o suporte do AWS Glue Data Catalog à autorização baseada em IAM (Gerenciamento de Identidade e Acesso), trazendo uma forma mais direta de controlar quem acessa o quê em pipelines analíticos que utilizam esses recursos.

    O que muda na prática

    Antes dessa atualização, configurar permissões para trabalhar com S3 Tables ou views materializadas Iceberg exigia lidar com controles de acesso em camadas diferentes — armazenamento, catálogo e mecanismo de consulta — de forma separada. Com a autorização baseada em IAM agora suportada pelo Glue Data Catalog, é possível definir todas as permissões necessárias em uma única política IAM, cobrindo as três camadas de uma só vez.

    Essa consolidação simplifica a integração do S3 Tables e das views materializadas com os principais serviços de analytics da AWS, incluindo:

    • Amazon Athena
    • Amazon EMR
    • Amazon Redshift
    • AWS Glue

    Controle granular com AWS Lake Formation

    Para equipes que precisam de controles de acesso mais refinados, a AWS manteve a opção de adotar o AWS Lake Formation a qualquer momento. A adesão pode ser feita pelo Console de Gerenciamento da AWS, pela CLI, por API ou via AWS CloudFormation, permitindo definir permissões em nível mais granular sobre os dados.

    Disponibilidade nas regiões GovCloud

    Esse recurso está agora disponível nas regiões AWS GovCloud (US-East) e AWS GovCloud (US-West), ampliando o acesso a organizações governamentais e reguladas que operam nessas regiões com requisitos específicos de conformidade e soberania de dados.

    Saiba mais

    Para aprofundar o entendimento sobre como configurar e utilizar esses recursos, a AWS disponibiliza a documentação do S3 Tables e a documentação do AWS Glue Data Catalog.

    Fonte

    Simplified permissions for Amazon S3 Tables and Iceberg materialized views are now available in AWS GovCloud (US) Regions (https://aws.amazon.com/about-aws/whats-new/2026/06/gdc-s3tables-simplified-permissions-in-aws-govcloud/)

  • Controle de acesso granular em aplicações B2C com Amazon Cognito e Amazon Verified Permissions

    Por que autenticação e autorização precisam andar juntas

    Aplicações web modernas precisam responder duas perguntas fundamentais de segurança: quem é você? e o que você pode fazer? Implementar esses controles corretamente é um dos maiores desafios para equipes de desenvolvimento — especialmente quando se trabalha com frameworks orientados a dados como o Streamlit (um framework Python de código aberto para criação de aplicações web interativas) ou quando a aplicação exige controles de acesso muito granulares.

    A AWS publicou um guia técnico mostrando como combinar o Amazon Cognito e o Amazon Verified Permissions com políticas Cedar para resolver exatamente esse problema — entregando segurança de nível empresarial com esforço de desenvolvimento reduzido.

    Visão geral da arquitetura de segurança

    A arquitetura de referência proposta segue um design de segurança em camadas com quatro componentes principais, cada um com responsabilidade bem definida:

    • Camada de autenticação: O Amazon Cognito cuida da verificação de identidade do usuário com validação segura de credenciais e Tokens Web JSON (JWT — JSON Web Tokens). Inclui políticas de senha integradas, proteção contra bloqueio de conta e gerenciamento de sessão.
    • Camada de autorização: O Verified Permissions usa o motor de políticas Cedar para avaliar requisições de acesso granulares com base em políticas armazenadas centralmente.
    • Camada de aplicação: O frontend em Streamlit integra ambos os serviços, gerenciando sessões de usuário e aplicando os controles de acesso na interface.
    • Fronteiras de segurança: Múltiplas camadas de controle protegem contra acesso não autorizado, escalada de privilégios, falhas de autenticação e validação de entradas.

    Essa separação de responsabilidades permite que autenticação e autorização funcionem como controles complementares, seguindo os princípios de defesa em profundidade.

    Como o fluxo de trabalho funciona na prática

    O fluxo completo de autenticação e autorização envolve três camadas trabalhando em sequência:

    • O usuário envia uma requisição de login pelo Streamlit
    • A requisição é autenticada pelo Amazon Cognito
    • Um token de acesso é retornado ao Streamlit
    • Uma requisição de autorização é enviada ao Verified Permissions
    • O motor de políticas Cedar avalia a requisição
    • Uma decisão é retornada pelo motor de políticas
    • A instrução de permitir ou negar é enviada de volta ao Streamlit
    • Se a instrução for de permissão, o acesso é concedido

    Entendendo a autorização com Cedar

    Enquanto a autenticação estabelece a identidade do usuário, a autorização determina quais ações ele pode executar. O Verified Permissions oferece um serviço de autorização escalável baseado no Cedar, uma linguagem de políticas projetada especificamente para controle de acesso granular.

    As políticas Cedar seguem um formato estruturado que define quem pode executar quais ações em quais recursos. Os componentes de uma política são:

    • Efeito: permit ou forbid — define se a política permite ou nega o acesso
    • Principal: A entidade (usuário) que faz a requisição, representada por ?principal como variável
    • Action: A operação sendo executada, com escopo no namespace da aplicação
    • Resource: O alvo da ação, também representado como variável
    • Condições: A cláusula when contém expressões lógicas que precisam ser verdadeiras

    Padrões avançados de políticas Cedar

    O artigo original descreve padrões de políticas Cedar amplamente utilizados para implementar autorização granular com o Amazon Verified Permissions. Os exemplos ilustram como modelar propriedade de recursos, acesso baseado em papéis, permissões hierárquicas e controles administrativos.

    Controle de propriedade de recurso

    Este padrão garante que usuários só acessem recursos que lhes pertencem. No exemplo acadêmico apresentado, um estudante só pode visualizar suas próprias notas:

    permit(
      principal == ?principal,
      action == application::Action::"ViewGrade",
      resource == ?resource
    )
    when {
      principal has role == "Student" &&
      resource.student == principal.entityId
    };

    A política verifica se o usuário tem o papel de Student e confirma que o atributo student do recurso corresponde ao entityId do estudante — impedindo que um aluno acesse as notas de outro.

    Acesso baseado em papel e tipo de recurso

    Este padrão concede acesso com base no papel do usuário e no tipo do recurso. No exemplo, um professor só pode editar cursos que ele mesmo leciona:

    permit(
      principal == ?principal,
      action == application::Action::"EditCourse",
      resource == ?resource
    )
    when {
      principal has role == "Faculty" &&
      resource has resourceType == "Course" &&
      resource.instructor == principal.entityId
    };

    Autorização hierárquica

    Este padrão permite que chefes de departamento gerenciem professores dentro do seu departamento:

    permit(
      principal == ?principal,
      action == application::Action::"ManageFaculty",
      resource == ?resource
    )
    when {
      principal has role == "DepartmentHead" &&
      resource has role == "Faculty" &&
      resource.department == principal.department
    };

    Acesso administrativo de emergência

    Este padrão fornece acesso emergencial com justificativa obrigatória:

    permit(
      principal == ?principal,
      action == ?action,
      resource == ?resource
    )
    when {
      principal has role == "Administrator" &&
      context has emergencyAccess == true &&
      context has justification
    };

    A política exige que a flag de acesso emergencial esteja definida como true e que uma justificativa seja fornecida — garantindo rastreabilidade sem bloquear operações críticas. Vale destacar que isso não é uma substituição automática: o contexto precisa ser explicitamente configurado.

    Como o Cedar avalia as políticas

    Entender o fluxo de avaliação de políticas ajuda a projetar sistemas de autorização mais eficazes. O processo segue estas etapas:

    • O usuário tenta acessar um recurso protegido
    • A aplicação envia uma requisição de autorização ao Verified Permissions
    • O Verified Permissions recupera as políticas Cedar aplicáveis do repositório de políticas
    • O motor Cedar avalia cada política contra a requisição
    • Se qualquer política forbid corresponder, o acesso é negado imediatamente
    • Se alguma política permit corresponder e nenhuma forbid corresponder, o acesso é permitido
    • Se nenhuma política corresponder, o acesso é negado por padrão
    • O resultado (ALLOW ou DENY) é retornado à aplicação

    Um ponto importante: políticas forbid têm precedência sobre políticas permit. Se qualquer política de negação corresponder, o acesso é bloqueado independentemente das permissões existentes.

    Aplicação prática: sistema acadêmico

    O artigo usa um sistema acadêmico como exemplo concreto, com diferentes papéis de usuário e suas permissões correspondentes:

    • Estudante: Visualiza apenas as próprias notas. A política verifica o papel e faz a correspondência entre o dono do recurso e o entityId do principal.
    • Professor (Faculty): Edita conteúdo de cursos que leciona e gerencia notas dos alunos nesses cursos.
    • Assistente de ensino (TA — Teaching Assistant): Gerencia notas dos cursos aos quais está vinculado, com acesso restrito aos cursos atribuídos.
    • Chefe de departamento (Department Head): Gerencia atribuições de professores dentro do seu departamento, com escopo hierárquico.
    • Administrador: Acesso amplo ao sistema com justificativa obrigatória, com todas as ações registradas e auditadas.

    Dicas de otimização de políticas

    O artigo traz duas recomendações práticas para melhorar a performance das avaliações:

    • Ordene as condições pela probabilidade de sucesso: Coloque as condições mais frequentemente verdadeiras primeiro na cláusula when para habilitar avaliação em curto-circuito. Por exemplo, verifique o papel antes da propriedade do recurso, pois incompatibilidades de papel são detectadas mais cedo. Veja as boas práticas do Cedar.
    • Use atributos indexados para buscas mais rápidas: Utilize atributos de entidade que o Verified Permissions indexa nativamente (entityId, role, tipo de recurso) como condições primárias. Consulte as boas práticas para design de modelo de autorização.

    Pré-requisitos e como executar o exemplo

    Para implementar o sistema acadêmico de exemplo, são necessários: uma conta AWS ativa, Python 3.8 ou superior, conhecimento básico de Streamlit e permissões de Gerenciamento de Identidade e Acesso da AWS (IAM — AWS Identity and Access Management) para o Amazon Cognito e o Verified Permissions.

    Os passos para executar o ambiente de demonstração são:

    • Baixe o código-base: Acesse o repositório de exemplos avp-streamlit no GitHub.
    • Configure o ambiente de desenvolvimento: Instale o SDK da AWS para Python (boto3) e configure suas credenciais AWS.
      pip install boto3

      Faça login na sua conta AWS:

      aws login --region $REGION

      Verifique se a Interface de Linha de Comando da AWS (AWS CLI), o Python e as dependências estão corretamente configurados:

      ./verify-setup.sh
    • Crie os recursos AWS: Use o Console de Gerenciamento da AWS ou ferramentas de Infraestrutura como Código (IaC — Infrastructure as Code) para provisionar o user pool do Amazon Cognito e o repositório de políticas do Verified Permissions.
      ./deploy-demo-environment.sh
      Do you want to start the demo now? (Y/N): Y

      Esse script provisiona o user pool do Amazon Cognito, o repositório de políticas do Verified Permissions e os recursos de amostra necessários para a demonstração.

    • Demonstração e encerramento: Interaja com a demo e teste as políticas e funcionalidades. Quando quiser sair, pressione Ctrl+C para encerrar.

    Boas práticas de segurança

    O artigo reúne um conjunto de recomendações para quem for implementar essa arquitetura:

    • Aplique controles em camadas: Use autenticação e autorização como controles complementares, nunca dependa de um único mecanismo.
    • Siga o princípio do menor privilégio: Conceda apenas as permissões necessárias para cada papel. Comece com permissões mínimas e adicione conforme necessário.
    • Implemente gerenciamento adequado de sessão: Configure expiração e renovação de tokens com base nos requisitos de segurança da aplicação. O Amazon Cognito lida com grande parte disso automaticamente.
    • Valide todas as entradas: Sanitize entradas do usuário para prevenir ataques de injeção. Não confie apenas na validação do lado do cliente.
    • Monitore eventos de autenticação: Configure logging com AWS CloudTrail e alarmes no Amazon CloudWatch para atividades suspeitas, como tentativas repetidas de login ou padrões de acesso incomuns.
    • Faça revisões regulares de segurança: Audite periodicamente suas políticas e configurações para garantir que ainda atendem aos requisitos.
    • Implemente tratamento seguro de erros: Evite revelar detalhes internos do sistema nas mensagens de erro. Forneça feedback útil ao usuário sem expor informações que possam auxiliar atacantes.

    Conclusão

    A combinação de Amazon Cognito e Amazon Verified Permissions permite construir controles de segurança robustos sem a necessidade de código personalizado complexo. A arquitetura descrita pela AWS entrega autenticação de nível empresarial com esforço mínimo, políticas de autorização granulares centralizadas, escalabilidade conforme a base de usuários cresce e auditoria centralizada das políticas de segurança.

    Para quem quiser se aprofundar, a AWS disponibiliza a documentação do Amazon Cognito e a documentação do Amazon Verified Permissions como recursos adicionais.

    Fonte

    Building secure B2C applications with fine-grained access control using Amazon Cognito and Amazon Verified Permissions (https://aws.amazon.com/blogs/security/building-secure-b2c-applications-with-fine-grained-access-control-using-amazon-cognito-and-amazon-verified-permissions/)

  • Visibilidade total em ataques DDoS com flow logs no AWS Shield Advanced

    O problema que os flow logs resolvem

    Reconstruir o tráfego de um ataque de negação de serviço distribuído — Distributed Denial of Service (DDoS) — costumava ser um trabalho de arqueologia: você combinava dados de múltiplas fontes depois que o estrago já havia acontecido. A AWS mudou essa dinâmica com os attack flow logs do Shield Advanced, que capturam metadados de tráfego durante os ataques, permitindo identificar origens, confirmar se as mitigações funcionaram e alimentar os pipelines de análise que você já usa.

    Os logs são publicados no Amazon Simple Storage Service (Amazon S3), no Amazon CloudWatch Logs ou no Amazon Data Firehose, usando a mesma infraestrutura de entrega do CloudWatch Logs que outros flow logs da AWS já utilizam. Isso significa que eles se encaixam diretamente nas ferramentas de monitoramento e análise que você já tem em operação.

    Como ataques DDoS afetam suas aplicações

    Um ataque DDoS inunda uma aplicação com tráfego até torná-la indisponível para os usuários. Ataques na camada de infraestrutura saturam a banda disponível e esgotam as tabelas de conexão — o resultado prático são perdas de pacotes e timeouts.

    O AWS Shield Advanced é um serviço gerenciado de proteção contra DDoS que detecta e mitiga ataques para os seguintes recursos: distribuições do Amazon CloudFront, balanceadores de carga do Elastic Load Balancing, zonas hospedadas do Amazon Route 53, aceleradores padrão do AWS Global Accelerator e endereços Elastic IP (EIP). Consulte a documentação do AWS Shield Advanced para ver a lista completa de recursos suportados.

    Inicialmente, a AWS disponibilizou os flow logs de ataques na camada de infraestrutura para proteções de EIP, com suporte a outros tipos de recursos previsto para o futuro.

    Principais benefícios dos flow logs

    Os flow logs ajudam as equipes de segurança de várias formas práticas:

    • Reconstruir padrões de tráfego: é possível consultar os logs após um ataque para analisar volume, distribuição de origens e mix de protocolos, sem depender apenas das métricas agregadas do CloudWatch.
    • Identificar origens dos ataques: os campos srccountry e location mostram de onde o tráfego se originou e por qual localização de borda da AWS ele entrou.
    • Verificar o comportamento de mitigação: o campo action registra o que o Shield fez com cada fluxo de tráfego.

    Os logs podem ser enviados para o Amazon S3, CloudWatch Logs ou Data Firehose. A partir daí, você pode consultá-los com o Amazon Athena (serviço serverless de consulta de dados no S3), encaminhá-los para plataformas de Gerenciamento de Informações e Eventos de Segurança — Security Information and Event Management (SIEM) de terceiros — ou criar consultas no CloudWatch Logs Insights, tudo isso sem precisar implantar nenhuma infraestrutura nova.

    O que os attack flow logs capturam

    Cada registro de log captura endereços IP de origem e destino, portas, protocolo, contagem de pacotes e bytes, a ação tomada pelo Shield Advanced, flags TCP, a localização de entrada na AWS e um código de país de duas letras para a origem do tráfego (quando disponível).

    Os logs são gravados em intervalos de 5 minutos e ficam disponíveis tanto durante um ataque ativo quanto após sua conclusão. O tamanho máximo de cada arquivo é 75 MB. Se esse limite for atingido dentro da janela de 5 minutos, o arquivo é fechado, publicado e um novo arquivo começa a ser gravado.

    Os flow logs suportam os formatos de saída JSON, texto simples, W3C e Parquet. Os campos disponíveis em cada registro são:

    • protection_arn — Nome de Recurso da Amazon (ARN) da proteção do Shield
    • event_timestamp — Timestamp de geração do log
    • version — Versão do flow log
    • srcaddr — Endereço IP de origem
    • dstaddr — Endereço IP de destino
    • srcport — Porta de origem
    • dstport — Porta de destino
    • protocol — Número do protocolo IP
    • packets — Contagem de pacotes na janela de agregação
    • bytes — Contagem de bytes na janela de agregação
    • starttime — Início da janela de agregação
    • endtime — Fim da janela de agregação
    • action — Ação tomada pelo Shield
    • location — Localização de entrada na AWS
    • sampling_rate — Taxa de amostragem usada no processamento de pacotes
    • tcp_flags — Flags TCP do pacote
    • srccountry — Código de país de duas letras para a origem do tráfego

    Como configurar os flow logs para proteções do Shield Advanced

    A seguir, o passo a passo para criar os recursos de entrega do CloudWatch Logs que conectam uma proteção do Shield Advanced ao destino de log de sua preferência.

    Pré-requisitos

    Antes de configurar os flow logs, certifique-se de ter:

    Os flow logs incorrem nas cobranças padrão de vended logs do CloudWatch Logs, e os recursos de destino (armazenamento em bucket S3, grupo de logs do CloudWatch Logs ou processamento de dados no Firehose) têm cobranças separadas. Revise a entrada de Vended Logs na página de preços do CloudWatch e os preços do serviço de destino escolhido antes de habilitar os flow logs em recursos de alto tráfego.

    Como funciona a entrega de logs

    A entrega de logs requer três objetos:

    • DeliverySource — Representa a proteção do Shield Advanced que produz os logs
    • DeliveryDestination — Representa para onde os logs devem ser enviados (Amazon S3, CloudWatch Logs ou Amazon Data Firehose)
    • Delivery — Conecta a origem ao destino

    Esse modelo de três objetos permite reutilizar destinos em múltiplas origens e gerenciar pipelines de entrega de forma independente. Por exemplo, é possível enviar logs de múltiplas proteções do Shield para o mesmo bucket S3 criando múltiplos objetos DeliverySource que referenciam o mesmo DeliveryDestination.

    Como os attack flow logs do Shield Advanced usam a infraestrutura de entrega do CloudWatch Logs, eles podem ser agregados entre contas e regiões assim como outros vended logs. É possível entregar diretamente para um bucket S3 centralizado com política cross-account, replicar grupos de logs do CloudWatch usando regras de centralização cross-account e cross-Region, ou transmitir para um stream compartilhado do Firehose usando assinaturas cross-account.

    Passo 1: Criar o recurso de destino

    Escolha um destino:

    Passo 2: Configurar a política do recurso de destino (se necessário)

    O recurso de destino precisa de uma política que conceda permissões de escrita ao serviço de entrega do CloudWatch Logs. A política varia conforme o tipo de destino. Para mais informações, consulte Logs enviados ao Amazon S3, Logs enviados ao CloudWatch Logs ou Logs enviados ao Firehose.

    Para destinos no Amazon S3, há duas opções: criação automática de política (se o bucket não tiver política de recurso existente e você tiver as permissões s3:GetBucketPolicy e s3:PutBucketPolicy, a AWS cria a política necessária automaticamente ao criar a entrega no passo 6) ou atualização manual da política (se precisar customizá-la ou se sua organização exigir políticas pré-aprovadas, siga as instruções em Logs enviados ao Amazon S3).

    Passo 3: Obter o ARN da proteção

    O Shield Advanced é um serviço global e usa a região us-east-1 para gerenciamento. Execute o comando abaixo para listar suas proteções do Shield Advanced:

    aws shield list-protections \
    --region us-east-1

    Na saída, copie o valor de ProtectionArn da proteção que você deseja registrar.

    Passo 4: Criar a origem de entrega (DeliverySource)

    Execute o comando abaixo para criar a origem de entrega, substituindo <protection-arn> pelo valor de ProtectionArn obtido no passo 3:

    aws logs put-delivery-source \
    --name my-shield-delivery-source \
    --resource-arn <protection-arn> \
    --log-type FLOW_LOGS \
    --region us-east-1

    O parâmetro --resource-arn é o ARN da proteção do Shield Advanced — não o do recurso protegido em si. O Shield Advanced cria um objeto de proteção separado que envolve seu recurso, e os flow logs são gerados por essa camada de proteção, não pelo recurso subjacente.

    Passo 5: Criar o destino de entrega (DeliveryDestination)

    Execute o comando abaixo para criar o destino de entrega, substituindo <resource-arn> pelo ARN do recurso de destino criado no passo 1:

    aws logs put-delivery-destination \
    --name my-shield-delivery-destination \
    --output-format plain \
    --delivery-destination-configuration '{"destinationResourceArn":"<resource-arn>"}' \
    --region us-east-1

    O parâmetro --delivery-destination-configuration recebe um objeto JSON com a chave destinationResourceArn, cujo valor é o ARN do seu bucket S3, grupo de logs ou stream do Firehose. Na saída, copie o valor do campo ARN de nível superior — este é o ARN do destino de entrega (diferente do ARN do bucket). Você usará esse valor no passo 6.

    Passo 6: Criar a entrega (Delivery)

    Execute o comando abaixo para conectar a origem ao destino, substituindo <delivery-destination-arn> pelo ARN do destino de entrega obtido no passo 5:

    aws logs create-delivery \
    --delivery-source-name my-shield-delivery-source \
    --delivery-destination-arn <delivery-destination-arn> \
    --region us-east-1

    Passo 7: Verificar a entrega

    Execute o comando abaixo para confirmar que a entrega está ativa:

    aws logs describe-deliveries \
    --region us-east-1

    Após a entrega estar ativa, o Shield Advanced publica registros de flow logs no seu destino durante eventos de DDoS.

    Limpeza dos recursos

    Para evitar cobranças contínuas, exclua os recursos criados seguindo a ordem abaixo.

    Exclua a entrega:

    aws logs delete-delivery \
    --id <delivery-id> \
    --region us-east-1

    Exclua a origem de entrega:

    aws logs delete-delivery-source \
    --name my-shield-delivery-source \
    --region us-east-1

    Exclua o destino de entrega:

    aws logs delete-delivery-destination \
    --name my-shield-delivery-destination \
    --region us-east-1

    Opcionalmente, faça backup dos dados de flow log se precisar retê-los para conformidade ou análise. Em seguida, exclua o recurso de destino.

    Atenção: excluir o recurso de destino apagará permanentemente todos os dados de flow log.

    Para um bucket S3:

    aws s3 rb s3://<bucket-name> \
    --force \
    --region <region>

    Para um grupo de logs do CloudWatch Logs:

    aws logs delete-log-group \
    --log-group-name <log-group-name> \
    --region <region>

    Para um stream do Firehose:

    aws firehose delete-delivery-stream \
    --delivery-stream-name <stream-name> \
    --region <region>

    Próximos passos

    Com os flow logs habilitados nas proteções do Shield Advanced, a AWS recomenda explorar as seguintes possibilidades para aprofundar a análise:

    Para a referência completa sobre configuração de flow logs, consulte a documentação do AWS Shield Advanced.

    Fonte

    Gain visibility into DDoS attacks with flow logs in AWS Shield Advanced (https://aws.amazon.com/blogs/security/gain-visibility-into-ddos-attacks-with-flow-logs-in-aws-shield-advanced/)