Category: Uncategorized

  • AWS Management Console Private Access agora funciona sem conexão com a internet

    O que mudou no Console Private Access

    A AWS anunciou uma atualização significativa para o AWS Management Console Private Access: a funcionalidade agora opera sem qualquer necessidade de conexão com a internet. Antes dessa mudança, mesmo que o acesso ao console fosse restrito a contas e redes corporativas autorizadas, ainda havia uma dependência de conectividade com a internet. Esse requisito foi eliminado.

    A partir de agora, o tráfego do AWS Console pode fluir inteiramente por meio de endpoints de Nuvem Privada Virtual (VPC), sem que nenhum pacote precise sair para a internet pública. Para equipes de segurança e conformidade, isso representa um avanço importante na construção de ambientes verdadeiramente isolados.

    Por que isso importa: ambientes air-gapped

    Ambientes air-gapped — ou seja, redes completamente desconectadas da internet — são uma exigência comum em setores altamente regulados. Serviços financeiros, governo, defesa e saúde frequentemente precisam garantir que dados sensíveis só sejam acessados a partir de ambientes controlados, sem qualquer rota para a internet pública.

    Com essa atualização, a AWS permite que essas organizações utilizem o Console de Gerenciamento normalmente, mesmo em redes classificadas ou sem conectividade externa. O gerenciamento da infraestrutura na nuvem deixa de exigir uma exceção nas políticas de isolamento de rede.

    Como funciona tecnicamente

    A solução utiliza o AWS PrivateLink para estabelecer caminhos de rede seguros entre as VPCs dos clientes e o Console da AWS. O PrivateLink é o serviço da AWS que permite conectar serviços de forma privada, sem exposição à internet pública.

    Além disso, os clientes podem aplicar políticas de endpoint de VPC para restringir o acesso a contas e organizações específicas da AWS. Para um controle ainda mais granular, é possível combinar essa configuração com políticas de Gerenciamento de Identidade e Acesso (IAM), Controle de Serviço (SCP) e Controle de Recursos (RCP), exigindo que colaboradores acessem recursos apenas a partir de redes autorizadas.

    Disponibilidade e custos

    O recurso está disponível em todas as regiões comerciais da AWS. Em termos de cobrança, não há taxa adicional específica para o Console Private Access sem internet: o cliente paga apenas pelo uso dos endpoints de VPC do AWS PrivateLink e pelo processamento de dados correspondente.

    Para conhecer os serviços de console suportados e começar a configurar o acesso privado sem internet, a AWS disponibiliza a documentação oficial do Management Console Private Access.

    Fonte

    AWS Management Console Private Access now works without internet connectivity (https://aws.amazon.com/about-aws/whats-new/2026/06/aws-management-console-private/)

  • Instâncias EC2 M9g e M9gd com Graviton5 já estão disponíveis

    A AWS lança instâncias EC2 M9g e M9gd com processadores Graviton5

    A AWS anunciou, a partir de 10 de junho de 2026, a disponibilidade geral das instâncias M9g e M9gd do Amazon EC2 (Elastic Compute Cloud). Essas instâncias são movidas pelos processadores AWS Graviton5 — a quinta geração de processadores customizados da AWS — projetados para entregar a melhor relação custo-desempenho em workloads de uso geral rodando no EC2.

    Para quais workloads cada instância se destina?

    As duas variantes atendem a perfis de uso distintos:

    • M9g: voltada para uma ampla gama de workloads de uso geral, como servidores de aplicação, microsserviços, jogos, caching e contêineres. Além disso, a instância entrega o desempenho necessário para casos de uso de IA agêntica, como raciocínio em tempo real, geração de código e orquestração de múltiplos passos.
    • M9gd: indicada para quem precisa de armazenamento local de alta velocidade e baixa latência. Oferece armazenamento em bloco SSD baseado em NVMe localmente, sendo ideal para processamento de mídia, processamento em lote e de logs, além de aplicações que necessitam de armazenamento temporário, como caches e arquivos de trabalho (scratch files).

    Ganhos de desempenho em relação à geração anterior

    Comparadas às instâncias M8g e M8gd baseadas no Graviton4, as novas M9g e M9gd apresentam melhorias expressivas:

    • Até 25% mais desempenho de computação em geral
    • Até 30% mais rápidas para bancos de dados
    • Até 35% mais rápidas para aplicações web
    • Até 35% mais rápidas para machine learning

    Segurança com garantia matemática: o Nitro Isolation Engine

    Um dos destaques dessas instâncias vai além do desempenho. Elas são construídas sobre a sexta geração do AWS Nitro System e são as primeiras a incorporar o Nitro Isolation Engine. Esse componente utiliza verificação formal — uma técnica matemática rigorosa — para garantir que os workloads dos clientes estejam isolados entre si e dos próprios operadores da AWS. Trata-se de um novo padrão de segurança em nuvem com comprovação matemática, algo inédito no setor.

    Disponibilidade e opções de compra

    As instâncias M9g e M9gd já estão disponíveis nas seguintes regiões:

    • Leste dos EUA (Norte da Virgínia e Ohio)
    • Oeste dos EUA (Oregon)
    • Europa (Frankfurt)

    Em relação às opções de aquisição, a AWS disponibiliza essas instâncias via Savings Plans, On-Demand, Spot, Dedicated Instances e Dedicated Hosts.

    Para quem quer evoluir sua infraestrutura de computação, a AWS convida a elevar sua computação com o AWS Graviton e começar agora mesmo.

    Fonte

    Amazon EC2 M9g and M9gd general purpose instances are now available (https://aws.amazon.com/about-aws/whats-new/2026/06/ec2-m9g-m9gd-instances-graviton5-processors-available)

  • 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 (111111111111 → 222222222222). 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/)

  • 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/)