Category: Uncategorized

  • Controle onde seus agentes de IA navegam com políticas Chrome Enterprise no Amazon Bedrock AgentCore

    O problema: agentes de IA com acesso irrestrito à web

    Agentes de IA que navegam pela web sem restrições representam um risco real para organizações. Sem controles adequados, um agente pode acessar domínios não autorizados, armazenar credenciais no gerenciador de senhas do navegador ou baixar arquivos fora dos fluxos aprovados. Para empresas que operam serviços internos com uma Autoridade Certificadora (CA) privada, há ainda outro obstáculo: toda conexão HTTPS com esses serviços falha com erros de validação de certificado.

    Para endereçar esses cenários, a AWS anunciou que o Amazon Bedrock AgentCore Browser agora oferece suporte a políticas Chrome Enterprise e certificados CA raiz personalizados. Com isso, as organizações ganham controle granular sobre o comportamento de navegação dos agentes — e podem conectá-los a infraestrutura interna com segurança.

    O que muda com esse suporte

    As políticas Chrome Enterprise permitem configurar mais de 450 configurações do navegador, incluindo filtragem de URLs, restrições de download e controle do gerenciador de senhas, tudo via configuração JSON padrão do Chrome Enterprise. Já o suporte a certificados CA raiz personalizados permite que os agentes se conectem a serviços internos e trabalhem com proxies corporativos que interceptam SSL, sem precisar desabilitar a validação de certificados.

    Para referência completa das configurações disponíveis, a AWS disponibiliza a lista de políticas Chrome Enterprise.

    Por que aplicar políticas de navegador em agentes de IA

    As políticas Chrome Enterprise atendem a três necessidades organizacionais quando aplicadas a agentes de navegação:

    • Restringir o escopo do agente a domínios aprovados: listas de permissão e bloqueio de URLs limitam onde os agentes podem navegar. Um agente responsável por processar faturas em um portal específico não precisa de acesso a redes sociais ou mecanismos de busca. As políticas impõem esses limites no nível do navegador, independentemente do prompt ou do raciocínio do agente.
    • Desabilitar recursos arriscados do navegador: é possível desligar o gerenciador de senhas, bloquear downloads de arquivos, desativar o preenchimento automático e controlar dezenas de outras capacidades do navegador. Para agentes que interagem com sistemas sensíveis, esses controles reduzem o risco de armazenamento ou exfiltração não intencional de dados.
    • Separar o gerenciamento de políticas do desenvolvimento do agente: as políticas gerenciadas são configuradas no nível do navegador via API do plano de controle e se aplicam a todas as sessões criadas a partir daquele navegador. Isso permite que a equipe de segurança defina configurações aprovadas enquanto a equipe de desenvolvimento foca na lógica do agente, sem embutir decisões de política no código da aplicação.

    Como as políticas e certificados CA raiz são aplicados

    A integração funciona em duas camadas de aplicação de políticas, com uma configuração opcional de confiança de certificados:

    • Políticas gerenciadas operam no nível do navegador. Os arquivos JSON de política Chrome Enterprise são armazenados no Amazon Simple Storage Service (Amazon S3) e fornecidos ao criar um navegador via API do plano de controle. Essas políticas são armazenadas pelo serviço e aplicadas em todas as sessões. Elas mapeiam para o diretório /etc/chromium/policies/managed/ do Chrome e não podem ser substituídas por configurações de nível de sessão.
    • Políticas recomendadas operam no nível da sessão. Podem ser fornecidas ao iniciar uma sessão via API do plano de dados. Mapeiam para o diretório /etc/chromium/policies/recommended/ e funcionam como preferências do usuário. Se houver conflito entre uma política gerenciada e uma recomendada, a gerenciada tem precedência — comportamento padrão do Chrome.
    • Certificados CA raiz personalizados são armazenados no AWS Secrets Manager e referenciados ao criar um navegador ou um AgentCore Code Interpreter. O serviço importa o certificado para o repositório de confiança de certificados, fazendo com que conexões a serviços internos e proxies que interceptam SSL funcionem sem desabilitar a validação.

    Arquitetura da solução

    O diagrama abaixo ilustra como os arquivos JSON de política Chrome e os certificados CA raiz fluem do ambiente da organização pelo plano de controle e plano de dados do Amazon Bedrock AgentCore até a sessão de navegador isolada.

    Imagem original — fonte: Aws

    No ambiente da organização, os arquivos JSON de política ficam armazenados no Amazon S3, e os certificados CA raiz opcionais ficam no AWS Secrets Manager. O plano de controle busca a política no S3 ao chamar CreateBrowser (seta 1) e busca o certificado CA raiz no Secrets Manager, se configurado (seta 2, tracejada para indicar que é opcional). A aplicação chama a API CreateBrowser (seta 3) e depois a API StartBrowserSession (seta 4). O plano de controle passa os metadados de configuração do navegador para o plano de dados (seta 5). O plano de dados implanta políticas gerenciadas, recomendadas e certificados CA raiz na sessão isolada do navegador (seta 6). O Chrome lê a configuração mesclada na inicialização e aplica as políticas durante toda a sessão.

    Pré-requisitos

    Para seguir o tutorial, é necessário ter:

    • Python 3.10 ou superior
    • Uma conta AWS com acesso ao Amazon Bedrock AgentCore habilitado
    • Credenciais AWS configuradas (verificável com aws sts get-caller-identity)
    • Uma região AWS onde o Amazon Bedrock AgentCore esteja disponível (veja as regiões suportadas na documentação do AgentCore)
    • Acesso a um modelo de IA para conduzir o agente. O tutorial utiliza o Anthropic Claude via Amazon Bedrock. O AgentCore é agnóstico de modelo — outros provedores e frameworks de agentes podem ser substituídos. Para detalhes sobre configuração de diferentes modelos com o framework Strands Agents, veja Provedores de Modelos na documentação do Strands Agents.

    O notebook cria automaticamente os recursos AWS necessários, incluindo o bucket S3, a função de execução do Gerenciamento de Identidade e Acesso (IAM), o AgentCore Browser e o AgentCore Code Interpreter. Esse provisionamento automático é voltado para demonstração. Implantações em produção devem usar recursos pré-existentes com políticas IAM de menor privilégio revisadas pela equipe de segurança. Consulte o README do repositório de exemplos para detalhes completos sobre as políticas IAM.

    Importante: use credenciais temporárias do AWS IAM Identity Center ou do AWS Security Token Service (AWS STS). Não use chaves de acesso de longa duração. Siga o princípio do menor privilégio ao configurar permissões IAM.

    Configurando o ambiente

    O código completo do tutorial está disponível como um Jupyter notebook no repositório de exemplos. Clone e execute as células em sequência:

    git clone https://github.com/awslabs/amazon-bedrock-agentcore-samples.git
    cd amazon-bedrock-agentcore-samples/01-tutorials/05-AgentCore-tools/02-Agent-Core-browser-tool/13-browser-chrome-policies
    python3 -m venv .venv
    source .venv/bin/activate # On Windows: .venv\Scripts\activate
    pip install -r requirements.txt
    export AWS_REGION=us-west-2
    jupyter notebook browser-chrome-policies.ipynb

    Execute as células em sequência. A Parte 1 cobre as políticas Chrome Enterprise. A Parte 2 cobre os certificados CA raiz personalizados.

    Walkthrough: políticas Chrome Enterprise na prática

    Definindo a política Chrome Enterprise

    As primeiras células do notebook definem uma política Chrome Enterprise que restringe o navegador à documentação da AWS e desabilita recursos desnecessários para o agente:

    policy = {
        "URLBlocklist": ["*"],
        "URLAllowlist": [
            "docs.aws.amazon.com",
            ".aws.amazon.com",
            ".amazonaws.com",
        ],
        "PasswordManagerEnabled": False,
        "DownloadRestrictions": 3,
        "DeveloperToolsAvailability": 0,
        "BookmarkBarEnabled": False,
        "AutofillAddressEnabled": False,
        "AutofillCreditCardEnabled": False,
    }

    Cada configuração tem um propósito claro: URLBlocklist: ["*"] bloqueia todas as URLs por padrão; URLAllowlist libera apenas os domínios da AWS; PasswordManagerEnabled: false impede o armazenamento de credenciais; DownloadRestrictions: 3 bloqueia downloads; e as demais configurações desabilitam ferramentas de desenvolvimento, barra de favoritos e preenchimento automático.

    Vale destacar: o URLAllowlist usa o formato de padrão de filtro de URL do Chrome, que difere dos padrões glob típicos. Padrões como docs.aws.amazon.com correspondem ao domínio exato. Um ponto inicial, como .aws.amazon.com, corresponde a subdomínios. Para a sintaxe completa de padrões, consulte a documentação da política URLAllowlist.

    Atenção: o DeveloperToolsAvailability deve ser definido como 0 (ou omitido) para navegadores usados com Playwright ou outra automação baseada em CDP (Chrome DevTools Protocol). Definir esse valor como 2 desabilita o CDP no nível do Chrome, o que quebra silenciosamente a automação.

    Criando um navegador com políticas gerenciadas

    As próximas células criam um navegador personalizado que aplica a política em todas as sessões. O parâmetro-chave é o enterprise_policies com o tipo definido como MANAGED. A gravação de sessão também é habilitada para revisão posterior:

    from bedrock_agentcore.tools import BrowserClient
    
    client = BrowserClient(REGION)
    response = client.create_browser(
        name="docs_research_browser",
        execution_role_arn=EXECUTION_ROLE_ARN,
        network_configuration={"networkMode": "PUBLIC"},
        enterprise_policies=[
            {
                "location": {
                    "s3": {
                        "bucket": BUCKET_NAME,
                        "prefix": POLICY_KEY,
                    }
                },
                "type": "MANAGED",
            }
        ],
        recording={
            "enabled": True,
            "s3Location": {
                "bucket": BUCKET_NAME,
                "prefix": "policy-demo",
            },
        },
    )

    Demonstrando a aplicação da política com Playwright

    O notebook inicia uma sessão de navegador e usa o Playwright para navegar para duas URLs. A primeira, docs.aws.amazon.com, é permitida pela política e carrega com sucesso. A segunda, www.wikipedia.org, é bloqueada e o Chrome exibe uma página de erro. A saída esperada é:

    TEST 1: Navigate to docs.aws.amazon.com (ALLOWED)
    Page title: Overview - Amazon Bedrock AgentCore
    Page text preview: Amazon Bedrock AgentCore ...
    Result: PAGE LOADED SUCCESSFULLY
    
    TEST 2: Navigate to www.wikipedia.org (BLOCKED)
    Page title:
    Result: CHROME POLICY BLOCKED THIS URL

    Esse é o valor central das políticas Chrome: a restrição acontece no nível do navegador, independentemente do raciocínio ou das instruções de prompt do agente. Enquanto a célula é executada, é possível acompanhar o navegador ao vivo no console do Amazon Bedrock AgentCore.

    Como a gravação de sessão foi habilitada, também é possível reproduzir a sessão depois para observar a aplicação das políticas — com linha do tempo interativa, ações do usuário com timestamp e eventos de rede confirmando que apenas o tráfego permitido teve sucesso.

    Consulte o notebook de exemplo para o código completo.

    Parte 2: Certificados CA raiz personalizados

    Organizações que executam serviços internos com CAs privadas, ou roteiam tráfego por proxies corporativos que interceptam SSL, precisam que os agentes confiem nesses certificados não públicos. O AgentCore Browser e o AgentCore Code Interpreter suportam certificados CA raiz personalizados para esse propósito.

    Para demonstração, o tutorial usa https://untrusted-root.badssl.com, um site público que intencionalmente apresenta um certificado assinado por uma CA raiz não confiável. Conexões HTTPS a esse site falham com erros de validação de certificado — exatamente como ocorreria com serviços internos sem o CA raiz correto.

    O notebook executa três etapas:

    1. Armazenar o certificado CA raiz no AWS Secrets Manager: o certificado CA raiz não confiável do BadSSL está disponível publicamente (fonte: badssl.com/certs/ca-untrusted-root.crt). O notebook o salva no AWS Secrets Manager para que o Amazon Bedrock AgentCore possa importá-lo para o repositório de confiança de certificados.
    2. Demonstrar a falha sem o CA raiz: o notebook cria uma sessão padrão do AgentCore Code Interpreter e executa código Python que chama urllib.request.urlopen() contra o site não confiável. A conexão falha com um SSLCertVerificationError.
    3. Demonstrar o sucesso com o CA raiz: o notebook cria um AgentCore Code Interpreter personalizado que confia no certificado CA raiz do BadSSL usando o parâmetro certificates:
    from bedrock_agentcore.tools import CodeInterpreter, Certificate
    
    ci_client_with_ca = CodeInterpreter(REGION)
    response = ci_client_with_ca.create_code_interpreter(
        name="demo_rootca_interpreter",
        execution_role_arn=EXECUTION_ROLE_ARN,
        network_configuration={"networkMode": "PUBLIC"},
        certificates=[Certificate.from_secret_arn(secret_arn)],
    )

    Após executar o mesmo código urlopen() contra o interpretador personalizado, a saída mostra Status: 200. A conexão é bem-sucedida porque o CA raiz do BadSSL agora é confiável. Nenhuma alteração de código foi necessária — a confiança foi configurada no nível da infraestrutura.

    Consulte o notebook de exemplo para o código completo.

    Aplicando ao seu ambiente corporativo

    A demonstração com o badssl.com espelha dois cenários reais:

    • Serviços corporativos internos: armazene o certificado CA raiz da organização (aquele que assina certificados para o portal de RH, Jira, Artifactory e serviços similares) no AWS Secrets Manager e referencie o ARN do secret em certificates ao criar um navegador ou AgentCore Code Interpreter.
    • Proxies corporativos que interceptam SSL: armazene o certificado CA raiz do proxy (usado por Zscaler, Palo Alto Networks ou similares) no AWS Secrets Manager e referencie o ARN em certificates, combinando com as configurações de proxy.

    Os certificados CA raiz personalizados funcionam tanto com o AgentCore Browser quanto com o AgentCore Code Interpreter. No navegador, o certificado é importado para o repositório de confiança do Chrome. No interpretador, o serviço configura variáveis de ambiente como REQUESTS_CA_BUNDLE e SSL_CERT_FILE para que bibliotecas Python confiem na CA personalizada sem contornos no nível do código.

    É possível combinar certificados CA raiz com políticas Chrome em um único navegador. O exemplo a seguir cria um navegador conectado a uma Nuvem Privada Virtual (VPC) que confia em uma CA interna e restringe a navegação a uma intranet corporativa:

    from bedrock_agentcore.tools import BrowserClient, Certificate
    
    response = client.create_browser(
        name="internal_locked_down_browser",
        execution_role_arn=EXECUTION_ROLE_ARN,
        network_configuration={
            "networkMode": "VPC",
            "vpcConfig": {
                "securityGroups": ["sg-0123456789abcdef0"],
                "subnets": ["subnet-0123456789abcdef0"],
            }
        },
        enterprise_policies=[
            {
                "location": {
                    "s3": {
                        "bucket": "org-policies",
                        "prefix": "intranet-only-policy.json",
                    }
                },
                "type": "MANAGED",
            }
        ],
        certificates=[
            Certificate.from_secret_arn(
                "arn:aws:secretsmanager:us-west-2:123456789012:secret:corp-root-ca"
            )
        ],
    )

    Limpeza de recursos

    Para evitar cobranças, execute as células de limpeza ao final do notebook. Elas encerram as sessões de navegador ativas e excluem o navegador personalizado, o AgentCore Code Interpreter, a função IAM, o secret do Secrets Manager e o arquivo de política no S3. Sessões do Amazon Bedrock AgentCore Browser geram cobranças enquanto estão ativas. Para detalhes de preços, consulte a página de preços do Amazon Bedrock AgentCore.

    Próximos passos

    Para começar, crie um navegador com uma lista de permissão de URLs adaptada ao seu caso de uso. A lista de políticas Chrome Enterprise documenta mais de 450 configurações. Para agentes de entrada de dados que interagem com formulários sensíveis, considere desabilitar o preenchimento automático e o gerenciador de senhas. Para agentes que processam documentos em um portal específico, restrinja downloads e limite a navegação ao domínio desse portal.

    Se a organização usa infraestrutura de chave pública (PKI) privada, configure certificados CA raiz e teste a conectividade com os serviços internos. Para agentes que operam atrás de proxies que interceptam SSL, combine a configuração de CA raiz com o recurso de configuração de proxy para rotear o tráfego pelo proxy corporativo enquanto confia no seu certificado.

    Para mais informações sobre as capacidades do Amazon Bedrock AgentCore Browser, consulte a documentação do Amazon Bedrock AgentCore Browser. Para feedback, abra uma issue no repositório do Amazon Bedrock AgentCore Python SDK.

    Importante: o código de exemplo é destinado a desenvolvimento e demonstração. Para implantações em produção, siga o princípio do menor privilégio para permissões IAM, restrinja as políticas de bucket do Amazon S3 a entidades autorizadas, faça a rotação dos certificados do AWS Secrets Manager antes do vencimento e siga o pilar de segurança do AWS Well-Architected Framework.

    Fonte

    Control where your AI agents can browse with Chrome enterprise policies on Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/control-where-your-ai-agents-can-browse-with-chrome-enterprise-policies-on-amazon-bedrock-agentcore/)

  • De dados isolados a insights unificados: acesso cross-account ao Athena pelo Amazon QuickSight

    O problema dos dados em silos

    Grandes empresas raramente concentram todos os seus dados em uma única conta AWS. O cenário mais comum é justamente o oposto: uma instituição financeira, por exemplo, pode manter dados de banco de varejo em uma conta, investimentos em outra e gestão de riscos em uma terceira. Ao mesmo tempo, a área de BI (Business Intelligence) costuma operar de forma centralizada.

    Até agora, quem usava o Amazon Quick nesse tipo de ambiente tinha duas opções ruins: gerenciar múltiplas assinaturas do serviço — uma por conta de dados — ou absorver todos os custos de consulta na conta central, perdendo a visibilidade de gastos por unidade de negócio. A AWS acaba de resolver esse impasse com o lançamento do acesso cross-account ao Amazon Athena para o Amazon Quick.

    O que é o Amazon Quick e o papel do Athena

    O Amazon Quick é um serviço unificado de inteligência com IA que reúne dados estruturados e conteúdo corporativo não estruturado — documentos, e-mails, bases de conhecimento — em um único ambiente onde qualquer pessoa pode explorar, analisar e agir sobre as informações. Ele conta com mais de 40 integrações com aplicações e inclui o Amazon QuickSight, sua camada de BI com dashboards interativos, consultas em linguagem natural, relatórios e insights com ML (Machine Learning).

    O Amazon Athena, por sua vez, é um serviço de consulta interativa e serverless que analisa dados diretamente no Amazon Simple Storage Service (Amazon S3) usando SQL padrão, sem necessidade de gerenciar infraestrutura ou carregar dados previamente. Basta apontar o Athena para os dados no S3, definir o esquema via AWS Glue Data Catalog e começar a consultar.

    O novo recurso: acesso cross-account ao Athena

    Com o novo recurso anunciado pela AWS, é possível consultar dados do Athena em outras contas AWS diretamente a partir de uma implantação centralizada do Amazon Quick, usando encadeamento de funções IAM (Identity and Access Management). Os custos de consulta são cobrados na conta onde os dados residem — não na conta central.

    O mecanismo central é o role chaining (encadeamento de funções): o Amazon Quick, operando na conta central, assume uma primeira função IAM (Função A), que por sua vez assume uma segunda função IAM (Função B) na conta consumidora. É a Função B que executa as consultas no Athena e no AWS Glue Data Catalog, sem que credenciais de longo prazo sejam compartilhadas entre contas.

    Definições importantes

    • Conta Central do Quick (Source Account): conta AWS onde o Amazon Quick está implantado.
    • Conta Consumidora (Consumer Account): conta AWS onde residem os dados do Athena (bancos de dados, tabelas, dados no S3).
    • RunAsRole (Função A): função IAM na conta central que o Quick assume primeiro; não tem permissões de dados, apenas permissão para encadear na Função B.
    • Consumer Account Role (Função B): função IAM em cada conta consumidora que concede acesso ao Athena, AWS Glue e S3; confia na Função A.
    • Role Chaining: processo de credenciais em dois passos — o Quick assume a Função A, depois usa essas credenciais para assumir a Função B.
    • ExternalId: condição de segurança (definida como o ARN do DataSource) usada nas trust policies para prevenir ataques do tipo confused deputy.
    • Scope-Down Policy: política IAM inline aplicada em tempo de execução para restringir as credenciais encadeadas a assumir apenas a função consumidora específica.
    • Athena Workgroup: ambiente de execução do Athena na conta consumidora onde as consultas são executadas e os custos são rastreados.

    Arquitetura e padrões de implantação

    A AWS descreve três padrões arquiteturais que evoluem conforme a maturidade da organização.

    Padrão 1: Configuração básica com duas contas

    A configuração mais simples conecta uma conta central do Quick a uma única conta consumidora. É o ponto de partida ideal para validar o encadeamento de funções de ponta a ponta. A Função A, na conta central, encadeia na Função B via sts:AssumeRole, e o Athena executa a consulta com as credenciais da Função B.

    Padrão 2: Hub and Spoke

    A maioria das empresas centraliza o Quick em uma única conta (o hub) enquanto os dados ficam distribuídos por múltiplas contas de unidades de negócio (os spokes). Nesse modelo, a política de permissões da Função A lista os ARNs de múltiplas funções consumidoras, e uma fonte de dados separada é criada no Quick para cada conta.

    A grande vantagem desse padrão é a independência entre os spokes. Adicionar uma nova unidade de negócio exige apenas criar uma nova Função B na conta dessa unidade e registrar uma nova fonte de dados no Quick — sem alterar os spokes existentes. Cada spoke controla suas próprias permissões, definindo quais tabelas e prefixos S3 ficam visíveis para a conta central de BI. Os custos de consulta são atribuídos automaticamente a cada conta consumidora.

    Para escalar além de alguns poucos spokes, a AWS recomenda usar templates de AWS CloudFormation ou CDK para a configuração do lado consumidor, permitindo que equipes de unidades de negócio façam o onboarding de forma autônoma.

    Padrão 3: Data Mesh

    Em uma arquitetura de data mesh, produtores e consumidores são contas distintas. Uma conta produtora gerencia seus dados brutos e os disponibiliza para contas consumidoras — por exemplo, usando AWS Lake Formation com AWS RAM (Resource Access Manager) para compartilhar tabelas entre contas. A conta consumidora, contendo a Função B, o AWS Glue Data Catalog e o Athena workgroup, é o ponto ao qual o Amazon Quick se conecta via encadeamento de funções.

    Nesse modelo, um autor de BI no Quick pode consultar múltiplas contas consumidoras em um único dashboard, com custos atribuídos por conta consumidora. Em escala enterprise, uma única implantação do Amazon Quick pode se conectar a centenas de contas consumidoras.

    Como escolher o padrão certo

    A AWS recomenda começar com a configuração básica de duas contas para validar o encadeamento. A maioria das empresas evoluirá para o hub-and-spoke ao integrar novas unidades de negócio, pela simplicidade na atribuição de custos e na gestão de trust policies. Organizações com fortes limites de propriedade de dados e equipes de domínio dedicadas naturalmente migrarão para o data mesh.

    Passo a passo: configuração técnica

    Pré-requisitos

    • Amazon Quick Enterprise Edition ativo na conta central.
    • Acesso administrativo IAM em ambas as contas.
    • AWS CLI instalada e configurada com credenciais para ambas as contas, ou acesso ao Console de Gerenciamento AWS.
    • Familiaridade com conceitos IAM: trust policies, permission policies e assunção de funções (sts:AssumeRole).
    • Athena workgroup configurado na conta consumidora.
    • Bucket S3 na conta consumidora para resultados de consultas do Athena (geralmente com prefixo aws-athena-query-results-*).

    Etapa 1: Criar a Função A (RunAsRole) na conta central

    A Função A vive na conta central. O Amazon Quick a assume quando um usuário inicia uma consulta. Ela não tem permissões de dados — sua única função é encadear na conta consumidora. São necessários dois elementos: uma trust policy que permite ao serviço Quick assumi-la, e uma permission policy que permite assumir a Função B.

    Crie o arquivo role-a-trust-policy.json:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Service": "quicksight.amazonaws.com"
          },
          "Action": "sts:AssumeRole",
          "Condition": {
            "StringLike": {
              "aws:SourceAccount": "<Quick-account-id>",
              "aws:SourceArn": "arn:aws:quicksight:*:<Quick-account-id>:datasource/*"
            }
          }
        }
      ]
    }

    Crie a função via AWS CLI:

    aws iam create-role \
      --role-name qs-athena-cross-account-role-a \
      --assume-role-policy-document file://role-a-trust-policy.json" \
      --description "Quick Athena Cross Account - RunAsRole"

    Crie o arquivo role-a-permission-policy.json:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": "sts:AssumeRole",
          "Resource": "arn:aws:iam::<consumer-account-id>:role/<consumer-role-name>",
          "Condition": {
            "StringLike": {
              "sts:ExternalId": "arn:aws:quicksight:*:<Quick-account-id>:datasource/*"
            }
          }
        }
      ]
    }

    Anexe a política inline via AWS CLI:

    aws iam put-role-policy \
      --role-name qs-athena-cross-account-role-a \
      --policy-name AssumeConsumerRolePolicy \
      --policy-document file://role-a-permission-policy.json

    O principal IAM que criar a fonte de dados no Quick também precisa da permissão iam:PassRole sobre a Função A.

    Etapa 2: Criar a Função B na conta consumidora

    A Função B vive na conta consumidora, onde estão as tabelas do Athena, o AWS Glue Data Catalog e os dados no S3. A Função A a assume para executar as consultas.

    Crie o arquivo role-b-trust-policy.json:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "AWS": "arn:aws:iam::<Quick-account-id>:root"
          },
          "Action": "sts:AssumeRole",
          "Condition": {
            "StringLike": {
              "sts:ExternalId": "arn:aws:quicksight:*:<Quick-account-id>:datasource/*"
            }
          }
        }
      ]
    }

    Crie a função via AWS CLI:

    aws iam create-role \
      --role-name qs-athena-consumer-role \
      --assume-role-policy-document file://role-b-trust-policy.json \
      --description "Quick Athena Cross Account - Consumer Account Role"

    Crie o arquivo role-b-permission-policy.json com permissões para Athena, AWS Glue e S3. A AWS recomenda escopo para recursos específicos, não wildcards genéricos:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "athena:BatchGetQueryExecution",
            "athena:CancelQueryExecution",
            "athena:GetCatalogs",
            "athena:GetExecutionEngine",
            "athena:GetExecutionEngines",
            "athena:GetNamespace",
            "athena:GetNamespaces",
            "athena:GetQueryExecution",
            "athena:GetQueryExecutions",
            "athena:GetQueryResults",
            "athena:GetQueryResultsStream",
            "athena:GetTable",
            "athena:GetTables",
            "athena:ListQueryExecutions",
            "athena:RunQuery",
            "athena:StartQueryExecution",
            "athena:StopQueryExecution",
            "athena:ListWorkGroups",
            "athena:ListEngineVersions",
            "athena:GetWorkGroup",
            "athena:GetDataCatalog",
            "athena:GetDatabase",
            "athena:GetTableMetadata",
            "athena:ListDataCatalogs",
            "athena:ListDatabases",
            "athena:ListTableMetadata"
          ],
          "Resource": [
            "arn:aws:athena:<region>:<account-id>:workgroup/<your-workgroup>",
            "arn:aws:athena:<region>:<account-id>:datacatalog/<your-catalog>"
          ]
        },
        {
          "Effect": "Allow",
          "Action": [
            "glue:GetCatalog",
            "glue:GetCatalogs",
            "glue:GetDatabase",
            "glue:GetDatabases",
            "glue:GetTable",
            "glue:GetTables",
            "glue:GetPartition",
            "glue:GetPartitions",
            "glue:BatchGetPartition"
          ],
          "Resource": [
            "arn:aws:glue:<region>:<account-id>:catalog",
            "arn:aws:glue:<region>:<account-id>:database/<your-database>",
            "arn:aws:glue:<region>:<account-id>:table/<your-database>/*"
          ]
        },
        {
          "Effect": "Allow",
          "Action": [
            "s3:GetBucketLocation",
            "s3:GetObject",
            "s3:PutObject",
            "s3:AbortMultipartUpload",
            "s3:ListBucket",
            "s3:ListBucketMultipartUploads",
            "s3:ListMultipartUploadParts"
          ],
          "Resource": [
            "arn:aws:s3:::<your-data-bucket>",
            "arn:aws:s3:::<your-data-bucket>/*",
            "arn:aws:s3:::aws-athena-query-results-*",
            "arn:aws:s3:::aws-athena-query-results-*/*"
          ]
        }
      ]
    }

    Anexe a política inline via AWS CLI:

    aws iam put-role-policy \
      --role-name qs-athena-consumer-role \
      --policy-name AthenaGlueS3Access \
      --policy-document file://role-b-permission-policy.json

    Etapa 3: Criar a fonte de dados cross-account no Quick

    Com as funções configuradas, o próximo passo é criar a fonte de dados no Amazon Quick, na conta central. Isso pode ser feito via AWS CLI:

    aws quicksight create-data-source \
      --aws-account-id <Quick-account-id> \
      --data-source-id "athena-cross-account" \
      --name "Athena Cross Account - Consumer Data" \
      --type ATHENA \
      --data-source-parameters '{
        "AthenaParameters": {
          "WorkGroup": "primary",
          "RoleArn": "arn:aws:iam::<Quick-account-id>:role/qs-athena-cross-account-role-a",
          "ConsumerAccountRoleArn": "arn:aws:iam::<consumer-account-id>:role/qs-athena-consumer-role"
        }
      }' \
      --permissions '[{
        "Principal": "arn:aws:quicksight:<region>:<Quick-account-id>:user/default/<your-user>",
        "Actions": [
          "quicksight:DescribeDataSource",
          "quicksight:DescribeDataSourcePermissions",
          "quicksight:PassDataSource",
          "quicksight:UpdateDataSource",
          "quicksight:DeleteDataSource",
          "quicksight:UpdateDataSourcePermissions"
        ]
      }]' \
      --region <region>

    Ou via Python (Boto3):

    import boto3
    
    client = boto3.client('quicksight', region_name='us-east-1')
    
    response = client.create_data_source(
        AwsAccountId='<Quick-account-id>',
        DataSourceId='athena-cross-account',
        Name='Athena Cross Account - Consumer Data',
        Type='ATHENA',
        DataSourceParameters={
            'AthenaParameters': {
                'WorkGroup': 'primary',
                'RoleArn': 'arn:aws:iam::<Quick-account-id>:role/qs-athena-cross-account-role-a',
                'ConsumerAccountRoleArn': 'arn:aws:iam::<consumer-account-id>:role/qs-athena-consumer-role'
            }
        }
    )
    
    print(response['CreationStatus'])

    Para verificar se a fonte de dados foi criada com sucesso:

    aws quicksight describe-data-source \
      --aws-account-id <Quick-account-id> \
      --data-source-id "athena-cross-account" \
      --region <region> \
      --query 'DataSource.{Name:Name,Status:Status,Type:Type}'

    A saída esperada é:

    {
      "Name": "Athena Cross Account - Consumer Data",
      "Status": "CREATION_SUCCESSFUL",
      "Type": "ATHENA"
    }

    Etapa 4: Compartilhar a fonte de dados e criar datasets

    Com a fonte de dados ativa, ela pode ser compartilhada com autores do Quick usando o seguinte comando:

    aws quicksight update-data-source-permissions \
      --aws-account-id <Quick-account-id> \
      --data-source-id "athena-cross-account" \
      --grant-permissions '{
        "Principal": "arn:aws:quicksight:<region>:<Quick-account-id>:user/default/<author-user>",
        "Actions": [
          "quicksight:DescribeDataSource",
          "quicksight:DescribeDataSourcePermissions",
          "quicksight:PassDataSource"
        ]
      }' \
      --region <region>

    A partir daí, os autores podem acessar o Quick, navegar até Datasets, criar um novo dataset selecionando a fonte de dados cross-account e navegar pelos bancos de dados e tabelas AWS Glue da conta consumidora — tudo a partir da conta central, com os custos de consulta cobrados na conta consumidora.

    Conectando múltiplas contas consumidoras

    Para conectar contas consumidoras adicionais, basta repetir o processo de criação de funções para cada conta, atualizar a política de permissões da Função A para incluir o ARN da nova função consumidora, criar a Função B na nova conta com as políticas de trust e acesso a dados apropriadas, e criar uma nova fonte de dados no Quick com o novo ConsumerAccountRoleArn. Cada fonte de dados mapeia para uma conta consumidora.

    Segurança e atribuição de custos

    O modelo de segurança é construído em camadas. A condição ExternalId na trust policy da Função B previne ataques do tipo confused deputy — somente fontes de dados Quick da conta central autorizada conseguem completar o encadeamento. Além disso, o Quick aplica uma scope-down policy inline cada vez que assume a Função A, restringindo cada sessão a uma única função consumidora, mesmo quando a Função A tem permissões para múltiplas contas.

    A cadeia completa de funções é registrada no AWS CloudTrail em ambas as contas — desde o AssumeRole inicial na conta central até as consultas no Athena na conta consumidora. Isso fornece uma trilha de auditoria completa e suporta alertas sobre padrões anômalos.

    Quanto à atribuição de custos: como as consultas do Athena são executadas sob as credenciais da Função B na conta consumidora, todos os custos associados aparecem na fatura dessa conta. A conta central do Quick incorre apenas nos custos de sessão do Quick e armazenamento SPICE. Antes desse recurso, as organizações precisavam absorver todos os custos centralmente ou operar assinaturas separadas do Quick por unidade de negócio — o novo recurso elimina esse trade-off.

    O que isso significa para o futuro com IA agêntica

    À medida que capacidades de IA agêntica amadurecem, a habilidade de acessar dados onde eles residem — com governança, atribuição de custos e auditabilidade — se torna fundamental. O acesso cross-account ao Athena é um bloco de construção para esse futuro. O mesmo mecanismo de encadeamento de funções IAM pode ser estendido para agentes de IA que consultam o Athena em nome de usuários de negócio, aplicam regras de governança em tempo real e roteiam custos de computação para o proprietário dos dados — sem centralizar dados em uma única conta.

    Conclusão

    O acesso cross-account ao Athena para o Amazon Quick permite que empresas mantenham uma conta central de BI enquanto respeitam os limites de governança de dados e custos em ambientes multi-account. A abordagem de role chaining garante atribuição correta de custos, mantém a soberania de dados por unidade de negócio e se integra aos controles de segurança IAM existentes.

    Para começar, basta criar as funções IAM nas contas do Quick e consumidoras conforme descrito neste guia, e então criar a fonte de dados usando o parâmetro ConsumerAccountRoleArn. Mais detalhes estão disponíveis no Guia do Usuário do Amazon Quick.

    Fonte

    From siloed data to unified insights: Cross-account Athena Access for Amazon Quick (https://aws.amazon.com/blogs/machine-learning/from-siloed-data-to-unified-insights-cross-account-athena-access-for-amazon-quick/)

  • Roteamento regional para portais de acesso AWS: como implementar domínios personalizados no IAM Identity Center

    O problema: múltiplas URLs para um único portal

    O AWS IAM Identity Center oferece um portal de acesso web que centraliza o acesso dos colaboradores às contas AWS e aplicações corporativas. Com o lançamento da replicação multi-região do IAM Identity Center, as organizações passaram a ter instâncias do serviço em múltiplas regiões AWS — o que é ótimo para resiliência e latência, mas cria um desafio prático: cada região gera sua própria URL de acesso ao portal.

    Gerenciar uma lista crescente de URLs regionais, comunicar aos usuários qual delas usar e ainda garantir failover em caso de incidente regional é uma dor de cabeça operacional real. A AWS publicou um guia técnico que resolve exatamente isso: criar um domínio personalizado único (por exemplo, aws.minhaempresa.com) que funciona como ponto de entrada consistente, redirecionando automaticamente cada usuário para o endpoint regional mais saudável e de menor latência.

    Formatos de URL suportados pelo IAM Identity Center

    Antes de entender a solução, vale conhecer os formatos de URL disponíveis na partição padrão da AWS. O formato recomendado pela AWS é https://{idcInstanceId}.portal.{region}.app.aws — ele suporta dual-stack (IPv4 e IPv6) e é compatível com replicação multi-região. Os formatos baseados em awsapps.com não estão sempre disponíveis em regiões mais novas e não suportam as capacidades multi-região. Em regiões replicadas adicionais, o alias personalizado não é suportado e o domínio pai awsapps.com não está disponível.

    Um ponto importante: cada URL regional resolve apenas para a instância daquela região específica — não há failover automático entre regiões pelo próprio serviço. Para rotear usuários entre regiões de forma dinâmica, é necessário implementar a abordagem de domínio personalizado descrita no guia.

    A solução: uma camada de roteamento e redirecionamento

    A arquitetura proposta constrói uma camada leve de roteamento na frente dos endpoints regionais do IAM Identity Center. Os componentes envolvidos são:

    O fluxo de funcionamento é direto: quando um usuário acessa aws.minhaempresa.com, o Route 53 avalia os registros de latência e encaminha o tráfego para o ALB na região saudável de menor latência. O ALB encerra o TLS usando um certificado gerenciado pelo ACM e emite um redirecionamento 302 para a URL do portal do Identity Center naquela região. O navegador do usuário segue o redirecionamento e carrega o portal diretamente — o ALB não fica no caminho do tráfego de autenticação subsequente.

    Vale destacar: o domínio personalizado em si não aparece na barra de endereços do navegador após o redirecionamento. A solução opera fora do Identity Center — na camada de DNS e balanceador de carga.

    Três fases progressivas de implementação

    O guia é estruturado em três fases independentes, que podem ser adotadas de acordo com a maturidade e necessidade de cada organização.

    Fase 1: Redirecionamento para um único endpoint regional

    A primeira fase estabelece a infraestrutura base: uma zona hospedada no Route 53, um certificado TLS gerenciado pelo ACM e um ALB voltado para a internet que emite redirecionamentos 302 para a URL do portal regional do Identity Center.

    Os passos principais são: criar uma zona hospedada pública no Route 53 para o domínio personalizado (ex: aws.minhaempresa.com); delegar o subdomínio a partir do domínio pai adicionando um registro NS; solicitar um certificado ACM para o domínio na região primária do IAM Identity Center; criar um grupo de segurança para o ALB permitindo tráfego HTTP e HTTPS de entrada em IPv4 e IPv6; criar o ALB com listeners nas portas 80 e 443, configurando redirecionamentos 302 — sendo o listener HTTPS apontando para a URL do portal regional do Identity Center; e por fim criar registros DNS no Route 53 apontando para o ALB com política de roteamento por latência.

    Um detalhe técnico importante destacado no guia: é obrigatório usar o código de status 302 – Found (e não 301). Usar 301 faz com que o navegador armazene em cache a URL de redirecionamento, o que impediria que failovers funcionassem corretamente até o cache expirar.

    Para validar a configuração, basta executar:

    curl -I https://aws.minhaempresa.com

    A resposta esperada é um HTTP/2 302 com o cabeçalho location apontando para a URL do portal do Identity Center na região configurada.

    Fase 2: Roteamento automático para o endpoint regional mais próximo

    A segunda fase estende a solução para suportar a replicação multi-região do IAM Identity Center. O objetivo é que usuários em diferentes partes do mundo sejam automaticamente direcionados ao portal da região com menor latência de rede a partir de sua localização.

    Para isso, é necessário repetir os passos da Fase 1 em cada região adicional onde o IAM Identity Center foi replicado: solicitar um certificado ACM na nova região, criar o grupo de segurança e o ALB (com a regra de redirecionamento apontando para o endpoint daquela região específica) e criar os registros DNS regionais e de roteamento por latência no Route 53 para cada região adicional.

    Com isso, o Route 53 passa a ter registros de latência para todas as regiões ativas, e cada usuário é automaticamente direcionado ao ALB mais próximo, que por sua vez redireciona para o portal do Identity Center correspondente.

    Fase 3: Failover regional gerenciado com ARC Region switch

    A terceira fase introduz o Controlador de Recuperação de Aplicações da Amazon (ARC) para orquestrar failovers regionais de forma gerenciada, ensaiável e controlada. Sem essa fase, uma impairment regional exigiria atualizações manuais de DNS para redirecionar o tráfego.

    O ARC Region switch fornece health checks do Route 53 diretamente como parte de um plano de Region switch. Esses health checks gerados são associados aos registros de latência do Route 53, e o ARC controla o estado (saudável ou não saudável) deles durante a execução do plano.

    O processo envolve: criar um plano de Region switch no console do ARC com abordagem de recuperação ativa-ativa, selecionando as regiões onde o IAM Identity Center está replicado; configurar os workflows de Ativação e Desativação para cada região, associando os registros DNS do Route 53 com seus respectivos identificadores; e por fim associar os health checks gerados pelo ARC aos registros de latência A e AAAA no Route 53.

    Para validar o setup, o guia orienta a executar um failover controlado: desativar a região primária via ARC e confirmar via curl que o redirecionamento passou a apontar para a região secundária. Para o failback, basta ativar novamente a região primária no plano do ARC.

    Deploy automatizado com CloudFormation

    Como alternativa aos passos manuais, a AWS disponibiliza templates do CloudFormation para cada fase, além de um script bash (deploy.sh) que automatiza o deploy das três fases em sequência. Os templates estão disponíveis para download:

    Para usar o script de deploy unificado, o pacote de deployment deve ser baixado e descompactado. Antes de executar, é necessário configurar os parâmetros do ambiente no arquivo deploy.sh: domínio de nível superior (TLD), ID da zona hospedada do TLD, subdomínio do Identity Center, ID da instância do IAM Identity Center, região primária e regiões adicionais.

    wget https://aws-security-blog-content.s3.us-east-1.amazonaws.com/public/sample/3536-regional-routing-for-aws-access-portals/Vanity-domains-cfn.zip
    unzip Vanity-domains-cfn.zip
    cd Vanity-domains-cfn
    ./deploy.sh

    Integração com provedores de identidade externos

    Após a configuração, o domínio personalizado pode ser integrado diretamente ao provedor de identidade da organização — como Okta ou Microsoft Entra ID — como uma aplicação de bookmark ou URL de chiclet. Dessa forma, usuários que acessam o painel do provedor de identidade são sempre redirecionados ao endpoint do IAM Identity Center mais próximo via roteamento por latência. Em caso de impairment regional, administradores executam um Region switch no ARC e os usuários são automaticamente redirecionados ao endpoint ativo, sem nenhuma alteração na URL do bookmark ou na experiência do usuário final.

    Pré-requisitos para implementação

    Antes de iniciar, a AWS lista os seguintes requisitos: um domínio de nível superior existente (ex: minhaempresa.com); uma instância organizacional do AWS IAM Identity Center configurada; para as Fases 2 e 3, a replicação multi-região do IAM Identity Center configurada com pelo menos duas regiões; e permissões de Gerenciamento de Identidade e Acesso da AWS (IAM) em uma conta de rede dedicada ou de serviços compartilhados para gerenciar Route 53, ACM, Amazon EC2, ALB e ARC.

    Recursos adicionais

    Fonte

    Regional routing for AWS access portals: Implementing custom vanity domains for IAM Identity Center (https://aws.amazon.com/blogs/security/regional-routing-for-aws-access-portals-implementing-custom-vanity-domains-for-iam-identity-center/)

  • Detectando e prevenindo crypto mining no seu ambiente AWS

    O problema do crypto mining não autorizado na nuvem

    Quando alguém obtém acesso indevido a recursos de nuvem para minerar criptomoedas, o impacto vai muito além do desperdício de processamento. A Amazon Web Services (AWS) detalha em um guia recente que organizações afetadas podem enfrentar aumentos de custo que vão de centenas a milhares de dólares, degradação de performance em workloads legítimas e, em casos mais graves, incidentes de segurança como exposição de dados ou implantação de ransomware.

    O que torna esse problema ainda mais preocupante é que as técnicas usadas pelos atacantes evoluem constantemente, dificultando a detecção. Muitas organizações só descobrem a invasão depois de receberem uma fatura inesperada ou quando a degradação de recursos começa a afetar as operações. E quando um atacante entra pela porta do crypto mining, ele pode instalar backdoors, comprometer credenciais e se mover lateralmente pela infraestrutura AWS.

    Sinais que indicam atividade de mineração

    A AWS aponta alguns indicadores que as equipes de segurança devem monitorar ativamente:

    • Conexões com endereços IP desconhecidos ou uso de portas associadas a pools de mineração, como a porta 3333
    • Uso elevado e sustentado de CPU ou GPU sem justificativa nas operações normais do negócio
    • Padrões de tráfego de rede incomuns, especialmente picos de saída para IPs não reconhecidos
    • Processos ou aplicações não autorizadas rodando nos recursos

    Como o Amazon GuardDuty detecta mineração de criptomoedas

    O Amazon GuardDuty é o serviço central para detecção desse tipo de ameaça. Ele usa algoritmos de aprendizado de máquina (Machine Learning) alimentados por dados globais de ameaças coletados pela AWS, detecção de anomalias baseada em linhas de base comportamentais e inteligência de ameaças integrada com parceiros de segurança.

    Tipos de alertas específicos para crypto mining

    As capacidades de detecção de crypto mining do GuardDuty incluem os seguintes tipos de findings:

    O GuardDuty também monitora os Flow Logs da Amazon Virtual Private Cloud (Amazon VPC) em busca de padrões suspeitos de rede, analisa consultas DNS para domínios relacionados à mineração e examina eventos do AWS CloudTrail para identificar chamadas de API suspeitas.

    Quando o recurso de Runtime Monitoring está ativado, o GuardDuty implanta agentes leves que oferecem visibilidade mais profunda sobre processos em execução e comportamento do sistema. Isso habilita findings como CryptoCurrency:Runtime/BitcoinTool.B e Impact:Runtime/CryptoMinerExecuted, que detectam software de mineração operando dentro dos workloads.

    A cobertura se estende a instâncias Amazon EC2, clusters do Amazon Elastic Container Service (Amazon ECS), ambientes Kubernetes e containers standalone. Para ambientes containerizados, findings do Amazon Elastic Kubernetes Service (Amazon EKS) podem indicar quando acessos não autorizados estão sendo usados para operações de mineração.

    Construindo uma proteção em múltiplas camadas

    A AWS reforça que a proteção contra crypto mining se beneficia de várias camadas de segurança — o GuardDuty é um componente importante, mas não o único. Veja o que a AWS recomenda para complementar as capacidades de detecção:

    • Ative o GuardDuty em todas as contas e regiões via AWS Organizations, habilitando também o Runtime Monitoring e a proteção para Amazon EKS.
    • Amazon CloudWatch: configure métricas de uso de recursos e alarmes para picos incomuns de CPU, rede ou GPU que possam indicar mineração.
    • AWS Config: implemente regras para verificar conformidade de configurações de segurança, garantindo que grupos de segurança não permitam acesso amplo à internet e que o IMDSv2 esteja aplicado.
    • AWS Network Firewall: habilite filtragem granular de tráfego de saída, permitindo apenas conectividade necessária e bloqueando acesso à infraestrutura de mineração.
    • AWS Systems Manager: mantenha visibilidade sobre configurações de instâncias. O recurso Inventory rastreia aplicações instaladas para detectar software de mineração; Run Command e State Manager aplicam políticas de segurança em toda a frota.
    • Automação de resposta: crie workflows automáticos usando Amazon EventBridge e Lambda para reagir imediatamente quando o GuardDuty detectar atividades de mineração.

    Boas práticas para proteção abrangente

    Gestão de acesso e autenticação

    A AWS recomenda implementar o princípio do menor privilégio com o Gerenciamento de Identidade e Acesso da AWS (IAM). Para casos de uso de software, use IAM roles dentro da AWS e IAM Roles Anywhere fora da AWS, em vez de chaves de acesso de longa duração. Para identidades humanas, centralize o gerenciamento de usuários pelo AWS IAM Identity Center com Autenticação Multifator (MFA) e controle de acesso baseado em atributos.

    Se não for possível eliminar o uso de chaves de acesso de longa duração, implemente políticas de rotação regular e aplique o menor privilégio em todas as políticas do IAM. Audite permissões regularmente para identificar e remover acessos excessivos.

    Manutenção de sistemas e configurações

    Use o Patch Manager, recurso do Systems Manager, para automatizar a aplicação de patches e manter as Imagens de Máquina da Amazon (AMIs) sempre atualizadas. Estabeleça um ciclo regular de patching, testando em ambientes de não-produção antes de implantar.

    Implemente regras rígidas de entrada em grupos de segurança, permitindo apenas o tráfego necessário. Use filtragem de saída para impedir conexões não autorizadas com pools de mineração e audite regularmente as configurações de grupos de segurança.

    Proteção de dados

    Use o Serviço de Gerenciamento de Chaves da AWS (AWS KMS) para habilitar criptografia de todos os dados em repouso e implemente TLS para dados em trânsito. O AWS KMS utiliza criptografia em envelope por padrão, protegendo as chaves de dados com chaves mestras. Rotacione as chaves de criptografia regularmente.

    Benefícios de uma proteção abrangente

    A AWS descreve os ganhos concretos que organizações podem obter ao implementar esse conjunto de medidas:

    • Redução do tempo de detecção: de dias ou semanas para minutos, permitindo contenção rápida antes que danos significativos ocorram.
    • Respostas automatizadas: workflows automáticos reduzem a necessidade de intervenção manual, liberando as equipes de segurança para iniciativas estratégicas.
    • Controle de custos: identificação e encerramento de consumo não autorizado de recursos, prevenindo aumentos inesperados na fatura.
    • Estabilidade de performance: processos de mineração deixam de monopolizar CPU, memória e rede, mantendo a performance das aplicações legítimas.
    • Visibilidade ampliada: a abordagem de monitoramento ajuda a identificar não só crypto mining, mas outras ameaças de segurança que poderiam passar despercebidas.
    • Confiança da equipe: monitoramento contínuo e alertas automatizados garantem que tentativas de mineração sejam detectadas e tratadas prontamente.

    Mineração de criptomoedas autorizada na AWS

    Um ponto importante destacado pela AWS: mineração de criptomoedas na plataforma requer aprovação prévia por escrito, conforme os Termos de Serviço da AWS (Seção 1.25). Essa exigência existe para proteger tanto os recursos dos clientes quanto a infraestrutura geral da AWS.

    Para solicitar aprovação, o AWS Trust & Safety avalia os pedidos para evitar que atividades de mineração afetem negativamente a performance ou a segurança dos serviços. A solicitação deve incluir:

    • Descrição do propósito da mineração e do caso de negócio
    • Planejamento de infraestrutura e abordagem de gestão de custos
    • Detalhamento das medidas de segurança para prevenir acessos não autorizados
    • Contatos de emergência para comunicação rápida em caso de problemas
    • Número de instâncias e tipo de mineração pretendida

    Operações aprovadas devem seguir diretrizes específicas. A AWS monitora as atividades para verificar que não geram relatórios de abuso, não afetam a performance dos serviços e não desviam da arquitetura e das práticas de segurança definidas. Vale lembrar: créditos AWS e recursos do Free Tier não podem ser usados para mineração.

    Conclusão

    A AWS recomenda uma abordagem abrangente que combine detecção avançada de ameaças com medidas preventivas proativas. O GuardDuty fornece a base de detecção, enquanto os serviços complementares formam um ecossistema robusto de segurança. A segurança é uma responsabilidade compartilhada: a AWS fornece as ferramentas, mas a implementação das práticas e controles de segurança por parte da organização é o que determina o nível real de proteção. Revisão regular das medidas de segurança e treinamento das equipes são essenciais para manter uma defesa eficaz contra crypto mining e outras ameaças no ambiente AWS.

    Fonte

    Detecting and preventing crypto mining in your AWS environment (https://aws.amazon.com/blogs/security/detecting-and-preventing-crypto-mining-in-your-aws-environment/)

  • Pacotes de Conformidade PCI PIN e P2PE já estão disponíveis para o AWS Payment Cryptography

    A AWS expande conformidade de pagamentos com PCI PIN e PCI P2PE

    A Amazon Web Services (AWS) anunciou a conclusão bem-sucedida das avaliações de conformidade com os padrões Número de Identificação Pessoal da Indústria de Cartões de Pagamento (PCI PIN) e Criptografia Ponto a Ponto da Indústria de Cartões de Pagamento (PCI P2PE) para o serviço AWS Payment Cryptography. Essa conquista representa um avanço significativo no portfólio de conformidade do serviço e traz implicações diretas para empresas brasileiras que processam pagamentos eletrônicos na nuvem.

    O que mudou no portfólio de conformidade

    Com essa nova validação, a AWS passa a ser reconhecida como provedora de componentes em três categorias distintas dentro do ecossistema PCI:

    • Gerenciamento de Chaves (KMCP — Key Management Component Provider)
    • Carregamento de Chaves (KLCP — Key Loading Component Provider)
    • Gerenciamento de Descriptografia (DMCP — Decryption Management Component Provider) — já existente anteriormente

    Além do escopo ampliado de categorias, a cobertura PCI PIN e PCI P2PE foi estendida para duas novas regiões: América do Sul (São Paulo) e Ásia-Pacífico (Sydney). Para o mercado brasileiro, isso é especialmente relevante: significa que workloads de pagamento podem ser operadas diretamente na região de São Paulo com respaldo formal de conformidade PCI.

    O que é o AWS Payment Cryptography

    O AWS Payment Cryptography é um serviço que permite que aplicações de processamento de pagamentos utilizem módulos de segurança de hardware (HSMs — Hardware Security Modules) para pagamentos. Esses HSMs são certificados pelo padrão Segurança de Transações HSM PTS (PCI PIN Transaction Security) e são totalmente gerenciados pela AWS, com gerenciamento de chaves em conformidade com PCI PIN e PCI P2PE.

    Na prática, isso significa que empresas que desenvolvem ou operam soluções de pagamento podem delegar à AWS a responsabilidade pela infraestrutura criptográfica regulada, reduzindo consideravelmente a carga operacional de manter essa conformidade internamente.

    Para quais casos de uso essas certificações são relevantes

    Cada certificação cobre um cenário específico dentro do ecossistema de pagamentos:

    • PCI P2PE — Componente de Descriptografia: permite que aplicações de pagamento utilizem a AWS para descriptografar transações de cartão de crédito provenientes de terminais de pagamento.
    • PCI PIN: obrigatório para aplicações que processam transações de débito baseadas em PIN (senha numérica do cartão).
    • PCI P2PE — Componentes de Gerenciamento e Carregamento de Chaves: habilitam o uso da AWS para troca física de chaves criptográficas e para casos de uso de gerenciamento de chaves, incluindo injeção de chaves.

    Para saber mais sobre o novo recurso de Troca Física de Chaves, a AWS publicou um anúncio no AWS What’s New com detalhes adicionais.

    Documentos incluídos nos pacotes de conformidade

    Os pacotes de conformidade PCI PIN e PCI P2PE para o AWS Payment Cryptography incluem um conjunto abrangente de documentos técnicos e regulatórios:

    • Atestado de Conformidade PCI PIN (AOC — Attestation of Compliance): demonstra que o AWS Payment Cryptography foi validado com êxito contra o padrão PCI PIN, sem nenhuma não-conformidade identificada.
    • Resumo de Responsabilidades PCI PIN: orienta os clientes da AWS sobre suas responsabilidades ao desenvolver e operar ambientes seguros para transações baseadas em PIN.
    • Atestado de Validação PCI P2PE DMCP (AOV — Attestation of Validation): comprova a validação do serviço como Sistema de Gerenciamento de Descriptografia PCI P2PE, sem não-conformidades.
    • Atestado de Validação PCI P2PE KMCP (AOV): comprova a validação como Provedor de Componente de Gerenciamento de Chaves PCI P2PE, sem não-conformidades.
    • Atestado de Validação PCI P2PE KLCP (AOV): comprova a validação como Provedor de Componente de Carregamento de Chaves PCI P2PE, sem não-conformidades.
    • Guia do Usuário do Componente P2PE e Relatório Anual do Componente: descreve o escopo de avaliação do serviço como Componente de Descriptografia, Componente de Carregamento de Chaves e Componente de Gerenciamento de Chaves PCI P2PE, além de ilustrar as responsabilidades de conformidade tanto do serviço quanto dos clientes que o utilizam para processamento de criptografia ponto a ponto.

    Como acessar os documentos de conformidade

    Todos os relatórios — incluindo o Atestado de Conformidade PCI PIN, o Resumo de Responsabilidades Compartilhadas PCI PIN, o Atestado de Validação PCI P2PE e o Guia do Usuário do Componente de Descriptografia P2PE — estão disponíveis para os clientes diretamente pelo AWS Artifact, o repositório centralizado de documentos de conformidade da AWS.

    A avaliação foi conduzida pela Coalfire, uma Avaliadora de Segurança Qualificada (QSA — Qualified Security Assessor) terceirizada e independente, o que reforça a credibilidade das validações obtidas.

    Contexto para equipes de conformidade e segurança

    Para profissionais que lidam com conformidade regulatória em ambientes de pagamento, essa expansão do portfólio PCI do AWS Payment Cryptography representa uma oportunidade concreta de reduzir a complexidade operacional. Ao utilizar componentes já validados pela AWS, as equipes podem concentrar esforços nas responsabilidades que permanecem sob seu controle, em vez de precisar manter e auditar toda a infraestrutura criptográfica de ponta a ponta.

    Para conhecer mais sobre os programas PCI e outros programas de conformidade e segurança disponíveis, a AWS disponibiliza informações na página de Programas de Conformidade da AWS. Dúvidas específicas sobre conformidade podem ser encaminhadas à equipe de Compliance da AWS pela página de Suporte de Conformidade, e questões técnicas podem ser tratadas diretamente pelo AWS Support.

    Fonte

    PCI PIN and P2PE compliance packages for AWS Payment Cryptography are now available (https://aws.amazon.com/blogs/security/pci-pin-and-p2pe-compliance-packages-for-aws-payment-cryptography-are-now-available/)

  • Segurança em agentes de IA: como AWS e Cisco AI Defense protegem implantações MCP e A2A em escala

    O crescimento acelerado dos agentes de IA criou lacunas sérias de segurança

    Desde novembro de 2024, a adoção do Protocolo de Contexto de Modelo (MCP) cresceu de forma expressiva. Empresas passaram a gerenciar dezenas — às vezes centenas — de servidores MCP: ferramentas que ampliam as capacidades de agentes de IA conectando-os a fontes de dados externas e APIs. Em abril de 2025, surgiu o Protocolo Agente-para-Agente (A2A), que permite que agentes autônomos se comuniquem diretamente entre si, sem intervenção humana. Mais recentemente, as Agent Skills (habilidades de agente) passaram a aparecer em toda a infraestrutura corporativa.

    Esse crescimento gerou três lacunas críticas de segurança:

    • As equipes não têm visibilidade sobre quais ferramentas e agentes estão em execução;
    • Revisões manuais de segurança não conseguem acompanhar o ritmo das implantações;
    • Frameworks de conformidade exigem trilhas de auditoria que simplesmente não existem para agentes de IA autônomos.

    Os riscos são concretos: acesso inadvertido a sistemas com dados sensíveis, violações de conformidade sob frameworks como SOX e GDPR — com potencial de penalidades regulatórias — e interrupções operacionais quando ferramentas vulneráveis ou agentes maliciosos são descobertos apenas após a implantação. Equipes de segurança relatam que processos de revisão manual podem adicionar várias semanas a cada implantação de aplicação de IA, criando um backlog que cresce conforme a adoção de IA acelera.

    A parceria entre AWS e Cisco AI Defense

    Para endereçar esses desafios, a AWS e a Cisco AI Defense firmaram uma colaboração estratégica que oferece varredura de segurança automatizada e abrangente para cada servidor MCP, agente de IA e Agent Skill no ambiente corporativo. O centro dessa solução é o AI Registry, projeto open-source apoiado pela AWS, que se integra ao Cisco AI Defense para resolver três problemas centrais.

    Visibilidade e controle do espalhamento de ferramentas

    Organizações que implantam servidores MCP e agentes de IA enfrentam um desafio fundamental de visibilidade. Equipes costumam adicionar servidores e agentes de forma ad-hoc em infraestruturas de nuvem e on-premises, tornando praticamente impossível para as equipes de segurança manter controle sobre o que está disponível, quais agentes se comunicam entre si, quem os utiliza e se representam riscos de segurança.

    O AI Registry resolve isso por meio de registro e descoberta unificados. Cada servidor MCP, agente de IA e Skill é registrado em um único plano de controle, proporcionando visibilidade completa. Além disso, a integração com o Cisco AI Defense adiciona uma camada de proteção ativa sobre essa visibilidade.

    Segurança da cadeia de suprimentos em escala

    Servidores MCP de terceiros e agentes A2A podem conter vulnerabilidades, código malicioso ou padrões inseguros que revisões manuais não conseguem detectar em escala. Quando um novo servidor ou agente é adicionado ao registro, a varredura de segurança acontece automaticamente, antes que o componente possa ser acessado.

    O scanner analisa cada ferramenta MCP, card de agente A2A e Agent Skill, gerando relatórios de segurança detalhados. Se problemas forem encontrados, o componente é automaticamente marcado como desabilitado com uma tag security-pending, exigindo revisão do administrador antes de liberar o acesso. Isso vale tanto para um servidor MCP que fornece acesso a banco de dados quanto para um agente A2A que orquestra fluxos de trabalho em múltiplas etapas pela infraestrutura.

    Eliminando gargalos de revisão de conformidade

    Revisões de segurança tradicionais criam gargalos no processo de implantação. A varredura automatizada — com revisão humana apenas nos casos em que vulnerabilidades são encontradas — viabiliza o onboarding self-service com guardrails de segurança embutidos. O processo que antes era lento e manual passa a ser automatizado, acelerando a incorporação de novos servidores MCP, agentes e Skills, ao mesmo tempo em que mantém o histórico completo de auditoria de segurança para requisitos regulatórios como SOX e GDPR.

    Como o processo de varredura funciona na prática

    O AI Registry atua como plano de controle central onde servidores MCP, agentes de IA e Skills são registrados e descobertos, oferecendo visibilidade completa da infraestrutura de IA. Ao registrar um servidor MCP, o Cisco AI Defense MCP Scanner realiza análise profunda das descrições de ferramentas e esquemas. Ao registrar agentes A2A, o Cisco AI Defense A2A Scanner analisa declarações de capacidade, definições de habilidades e padrões de comunicação. Capacidades similares existem para Agent Skills, por meio de um Skills Scanner que detecta injeção de prompt, exfiltração de dados e padrões de código malicioso.

    O diagrama abaixo ilustra o fluxo completo do processo de registro e varredura de segurança:

    Imagem original — fonte: Aws

    A varredura pode ser iniciada sob demanda para analisar servidores MCP e agentes individualmente, ou para varrer todo o Registry de uma vez. Organizações tipicamente configuram um job Cron independente que usa a API do Registry para varrer periodicamente todo o ambiente e rastrear vulnerabilidades pelos sistemas de gestão de tickets existentes. Os resultados ficam armazenados no datastore do Registry e podem ser visualizados pela interface do Registry ou recuperados via API.

    Múltiplas abordagens de varredura

    A postura de segurança de uma organização é reforçada por múltiplas abordagens de varredura que se aplicam uniformemente a MCP, agentes A2A e Skills:

    • YARA Analyzer: detecção rápida baseada em padrões para ameaças conhecidas como injeção SQL, injeção de comandos e credenciais hardcoded;
    • LLM Analyzer: análise semântica com IA usando modelos de fronteira disponíveis pelo Amazon Bedrock, que examina lógica de ferramentas, comportamento de agentes e declarações de capacidade para identificar ameaças sofisticadas e inéditas;
    • Scanners proprietários da Cisco AI Defense: incluindo o MCP Scanner, A2A Scanner e Skills Scanner, para detecção avançada de ameaças combinando inteligência de ameaças extensiva com análise profunda de código.

    O A2A Scanner analisa especificamente os metadados dos cards de agente para detectar ameaças de cadeia de suprimentos como falsificação de identidade, injeção de prompt em campos de metadados, credenciais hardcoded, endpoints de exfiltração de dados e padrões de SSRF (Server-Side Request Forgery). Ele também verifica violações de conformidade com a especificação A2A e mapeia os achados para níveis de severidade de BAIXO a CRÍTICO.

    Quando problemas são detectados, o sistema desabilita automaticamente os ativos vulneráveis com relatórios de segurança detalhados, exigindo revisão do administrador antes de liberar o acesso. A varredura se integra aos fluxos de desenvolvimento (Integração Contínua/Entrega Contínua — CI/CD) como parte do registro de novos servidores e agentes no AI Registry.

    Arquitetura aberta e integração com fluxos corporativos

    O AI Registry é construído sobre padrões e APIs abertas. Clientes da Cisco AI Defense e da AWS podem consultar o AI Registry via API REST para descobrir servidores MCP e agentes disponíveis, suportando detecção de ameaças programática em escala. O registro usa a mesma especificação de API REST do MCP Registry oficial da Anthropic, garantindo ampla compatibilidade entre ambientes MCP e suporte a federação com outras implantações MCP.

    A integração com fluxos de trabalho corporativos existentes também é suportada:

    • Criação automática de tickets no ServiceNow para servidores ou agentes com problemas;
    • Notificações em tempo real no Slack quando achados de alta severidade são detectados;
    • Encaminhamento de dados de incidentes para sistemas de Gerenciamento de Eventos e Informações de Segurança (SIEM) como Splunk ou Datadog;
    • Relatórios consolidados em dashboards de conformidade para prontidão de auditoria.

    Como começar

    Para clientes AWS

    Clientes AWS podem implantar o AI Registry e configurar a integração com o Cisco AI Defense MCP Scanner para adicionar varredura de segurança ao fluxo de onboarding de ativos de IA. O guia completo de configuração do Security Scanner está disponível no GitHub.

    Além da integração com o AI Registry open-source, é possível usar o Cisco AI Defense em fluxos CI/CD para avaliar ativos de IA antes de registrá-los no AWS Agent Registry — um serviço gerenciado de descoberta que fornece um catálogo centralizado para organizar, curar e descobrir recursos em toda a organização. Essa abordagem permite que equipes avaliem servidores MCP, ferramentas, agentes, agent skills e recursos customizados antes da publicação no registry. Um exemplo de código com a integração do Cisco AI Defense (versão OSS) com o AWS Agent Registry está disponível no repositório oficial do AWS Labs.

    Para clientes Cisco AI Defense

    Clientes da Cisco AI Defense podem configurar o MCP Scanner para apontar para o registry da organização, descobrir servidores MCP e agentes disponíveis pela API do registry, gerar relatórios de segurança abrangentes e integrar os achados aos fluxos de segurança existentes. Os scanners open-source estão disponíveis publicamente:

    Para as capacidades completas do produto, consulte a documentação do Cisco AI Defense.

    Conclusão

    A parceria entre AWS e Cisco AI Defense representa uma resposta concreta a um problema que cresce junto com a adoção de IA nas empresas: como manter visibilidade, segurança e conformidade quando dezenas ou centenas de agentes e servidores são implantados em ritmo acelerado. A combinação do AI Registry com os scanners automatizados da Cisco endereça os três pilares do problema — visibilidade centralizada, varredura de segurança em escala e trilhas de auditoria para conformidade regulatória — sem criar novos gargalos no processo de desenvolvimento.

    Fonte

    Securing AI agents: How AWS and Cisco AI Defense scale MCP and A2A deployments (https://aws.amazon.com/blogs/machine-learning/securing-ai-agents-how-aws-and-cisco-ai-defense-scale-mcp-and-a2a-deployments/)

  • AWS Security Agent ganha varredura completa de repositório de código em prévia

    Análise de segurança que raciocina como um pesquisador humano

    A AWS anunciou a disponibilidade em prévia de uma nova capacidade do AWS Security Agent: a revisão completa de repositório de código. A funcionalidade realiza uma análise de segurança profunda e contextual de toda a base de código de uma aplicação, indo muito além do que as ferramentas tradicionais de Teste Estático de Segurança de Aplicação (SAST) conseguem fazer.

    O diferencial central está na abordagem: em vez de simplesmente comparar trechos de código contra uma lista de padrões conhecidos de vulnerabilidade, o sistema constrói um modelo de segurança da aplicação inteira — mapeando pontos de entrada, fronteiras de confiança, fluxos de dados e lógica de autorização — e raciocina sobre o comportamento real do sistema, da mesma forma que um pesquisador de segurança experiente faria, mas operando na velocidade de uma máquina.

    O problema que a ferramenta resolve

    Times de desenvolvimento enfrentam uma tensão constante: as ferramentas SAST tradicionais são rápidas e confiáveis para capturar padrões conhecidos — como uma injeção de SQL, uma saída sem escape ou uma credencial codificada diretamente no código. Mas aplicações modernas são sistemas complexos, compostos por serviços, APIs, fronteiras de confiança e lógica de autorização distribuída.

    As vulnerabilidades mais perigosas raramente são violações de uma única linha. Elas costumam ser lacunas sistêmicas: uma função de validação que cobre quatro de cinco casos, um endpoint que não tem a anotação de autorização que todos os seus vizinhos têm, ou uma codificação aplicada em um contexto mas esquecida em outro. Revisões manuais de segurança conseguem encontrar esses problemas, mas são caras, lentas e não acompanham o ritmo do desenvolvimento moderno.

    A revisão completa de repositório foi construída exatamente para fechar essa lacuna — funcionando como um pesquisador de segurança automatizado que lê e raciocina sobre todo o repositório, e não apenas sobre linhas ou arquivos isolados.

    Como funciona: quatro etapas de análise

    A funcionalidade opera em quatro estágios que espelham a forma como um engenheiro de segurança experiente conduz uma avaliação.

    1. Criação do perfil da aplicação

    O scanner começa lendo o repositório completo e construindo um modelo de segurança da aplicação. Esse modelo inclui pontos de entrada, fronteiras de confiança, fluxos de dados, invariantes de autorização e as defesas já existentes. Todos os arquivos-fonte são considerados, tornando as decisões de cobertura explícitas em vez de implícitas. O resultado é uma compreensão estruturada do que a aplicação faz e onde está sua superfície de ataque.

    2. Busca por vulnerabilidades

    Um orquestrador lê o perfil de segurança, raciocina sobre a superfície de ataque e despacha agentes especializados para os componentes de maior risco. Cada agente recebe uma missão com escopo definido — módulos específicos, contexto de ameaça e perguntas adversariais. Os agentes têm liberdade para seguir importações e chamadores além do escopo inicial quando uma pista os leva nessa direção.

    3. Triagem e deduplicação

    Os candidatos a vulnerabilidade são deduplicados (mesmo ponto de injeção, mesma causa raiz) e o ruído de baixa confiança é filtrado antes da fase de validação.

    4. Validação independente

    Para cada candidato, um validador independente relê o código-fonte e traça a cadeia de ataque completa. O validador argumenta nos dois sentidos: busca razões pelas quais o achado pode não ser uma vulnerabilidade (controles compensatórios, design intencional) e razões pelas quais é uma (caminhos alternativos de ataque, casos extremos). Um achado só é descartado quando as evidências contra ele são tão sólidas quanto as que o promoveram.

    Esse processo gera achados com seções estruturadas de Verificado e Não foi possível verificar, para que o time saiba exatamente o que o scanner confirmou no código e o que depende do ambiente de implantação.

    O que torna essa abordagem diferente

    A revisão completa de repositório se diferencia da análise estática tradicional em dois aspectos fundamentais: ela raciocina sobre o comportamento real da aplicação em vez de comparar padrões conhecidos, e apresenta os achados com evidências estruturadas que tornam a incerteza explícita — não escondida.

    Raciocínio contextual, não correspondência de padrões

    Como o scanner constrói um modelo de segurança antes de buscar vulnerabilidades, ele raciocina sobre o comportamento real da aplicação. Um exemplo concreto citado pela AWS ilustra bem isso: havia uma vulnerabilidade de injeção de SQL em uma stored procedure. Uma ferramenta SAST tradicional sinalizaria a chamada específica de EXECUTE IMMEDIATE. O scanner foi mais fundo — identificou que a função central de validação não bloqueia aspas simples em nenhum dos cinco perfis de regex, listou todos os cinco perfis pelo nome, explicou por que aspas simples importam para o banco de dados específico, e apontou que outra stored procedure ignora completamente a função de validação. Em vez de uma correção pontual em um único local, o achado levou a uma remediação abrangente da lacuna sistêmica.

    Em outro caso, o scanner encontrou uma vulnerabilidade de XSS (Cross-Site Scripting) onde um valor era adicionado a um campo sem codificação HTML. O mesmo valor era corretamente codificado com Encode.forHtml() em um contexto diferente dentro do mesmo arquivo. Ferramentas de correspondência de padrões não percebem isso porque a função de codificação está presente — mas a vulnerabilidade é a inconsistência, e detectá-la exige compreender o comportamento da aplicação em diferentes caminhos de código.

    Achados validados com incerteza transparente

    Cada achado é estruturado para facilitar a triagem pelo time de desenvolvimento:

    • Problema: O que o código faz de errado, com referências específicas de arquivo e linha.
    • Impacto: O que um atacante ganha, com detalhes sobre o contexto de implantação.
    • Verificado e não foi possível verificar: O que o scanner confirmou diretamente no código versus o que depende do ambiente (segmentação de rede, comportamento em tempo de execução).
    • Remediação: Sugestões concretas de correção com mudanças específicas de código, não orientações genéricas.
    • Severidade e confiança: Calibrados de forma independente. A severidade reflete o impacto se a vulnerabilidade for explorável; a confiança reflete quanto da cadeia de ataque foi verificada no código.

    Como se encaixa no fluxo de trabalho de segurança

    A revisão completa de repositório foi projetada para complementar — não substituir — as ferramentas de segurança já existentes. A AWS sugere três cenários de uso principais:

    • Antes de revisões de segurança: Executar a análise antes de agendar um teste de penetração ou revisão de segurança. Isso faz com que os problemas óbvios e semi-óbvios já sejam resolvidos, liberando o time de segurança para focar nas questões sutis de design que exigem julgamento humano.
    • Ao integrar código adquirido ou open source: A funcionalidade é especialmente valiosa quando o time herda código por meio de aquisições, dependências de fornecedores ou componentes open source. O scanner constrói um modelo de segurança do zero, sem precisar de conhecimento institucional da base de código.
    • Durante revisões de arquitetura: Como o scanner raciocina sobre fronteiras de confiança, fluxos de dados e invariantes de autorização, seus achados frequentemente revelam problemas arquiteturais — não apenas bugs de implementação. Revisar os resultados junto com os modelos de ameaça ajuda a validar suposições sobre como os componentes interagem.

    Para quem quiser começar, a AWS disponibilizou um guia de início rápido para configurar e executar a revisão completa de repositório com o AWS Security Agent.

    Disponibilidade e preço

    A revisão completa de repositório está disponível hoje em prévia, sem custo adicional para clientes do AWS Security Agent. Durante o período de prévia, a AWS está priorizando o acesso antecipado gratuito para que os times possam fortalecer suas bases de código e compartilhar aprendizados que beneficiem toda a indústria.

    Para habilitar a funcionalidade e executar a primeira varredura, acesse o console do AWS Security Agent. Mais detalhes técnicos estão disponíveis na documentação oficial do AWS Security Agent.

    Fonte

    AWS Security Agent full repository code scanning feature now available in preview (https://aws.amazon.com/blogs/security/aws-security-agent-full-repository-code-scanning-feature-now-available-in-preview/)

  • AWS Security Agent agora suporta revisão de código em repositórios completos

    O que foi anunciado

    A AWS anunciou a disponibilidade da revisão de código em repositório completo, uma nova capacidade do AWS Security Agent. O recurso realiza uma análise de segurança profunda e sensível ao contexto de toda a base de código de uma aplicação — e representa uma mudança significativa em relação às abordagens tradicionais de análise estática.

    Por que isso é diferente das ferramentas tradicionais

    Ferramentas convencionais de análise estática funcionam comparando o código contra padrões conhecidos de vulnerabilidades. O novo recurso do AWS Security Agent vai além: ele raciocina sobre a arquitetura da aplicação, os limites de confiança e os fluxos de dados para identificar vulnerabilidades sistêmicas que ferramentas baseadas em padrões simplesmente não conseguem detectar.

    Em termos práticos, isso significa que o scanner consegue enxergar problemas que só aparecem quando se analisa o sistema como um todo — e não apenas trechos isolados de código.

    Correções vinculadas ao arquivo e à linha exata

    Quando uma vulnerabilidade é identificada, o AWS Security Agent não apenas aponta o problema: ele gera uma correção de código específica, vinculada ao arquivo e à linha exata onde o problema foi encontrado. Isso permite que as equipes identifiquem e corrijam vulnerabilidades de segurança com muito mais agilidade do que antes.

    Disponibilidade e custo durante o preview

    O recurso está disponível em todas as regiões da AWS onde o AWS Security Agent já opera. Durante o período de preview, ele está disponível sem custo adicional para clientes existentes do AWS Security Agent.

    A AWS destaca que está priorizando o acesso antecipado gratuito para clientes, com o objetivo de dar aos defensores a oportunidade de fortalecer suas bases de código e compartilhar aprendizados que beneficiem toda a indústria.

    O contexto mais amplo: IA e cibersegurança

    A própria AWS reconhece que as capacidades de cibersegurança baseadas em IA estão evoluindo rapidamente. O AWS Security Agent já é capaz de encontrar vulnerabilidades e construir exploits funcionais em uma escala e velocidade sem precedentes. Esse cenário reforça a importância de colocar essas ferramentas nas mãos dos defensores antes que agentes maliciosos as utilizem.

    Como começar

    Para habilitar a revisão de repositório completo e executar a primeira análise, basta acessar o console do AWS Security Agent. Para mais detalhes sobre o funcionamento do recurso, a documentação oficial do AWS Security Agent traz o passo a passo completo.

    Fonte

    AWS Security Agent now supports full repository code reviews (https://aws.amazon.com/about-aws/whats-new/2026/05/aws-security-agent-full-repository-code-review/)

  • Treinamento virtual gratuito: pratique com os serviços de segurança da AWS

    Workshops gratuitos de segurança na AWS

    Para quem quer fortalecer a postura de segurança da organização na Amazon Web Services (AWS), mas não sabe por onde começar, a AWS disponibiliza os Security Activation Days — workshops virtuais gratuitos e práticos, pensados para que os participantes saiam de cada sessão com experiência real nos serviços de segurança da plataforma.

    O que esperar dos eventos

    Cada Security Activation Day é um workshop virtual com duração de 3 a 6 horas. Durante a sessão, os participantes trabalham diretamente com os serviços de segurança da AWS em cenários do mundo real. A dinâmica combina apresentações, demonstrações e atividades práticas guiadas por especialistas de segurança da AWS — seja no próprio ambiente do participante ou em um sandbox (ambiente isolado de testes) fornecido pela AWS.

    Os temas variam e cobrem o espectro completo de serviços de segurança, identidade e governança da AWS, incluindo:

    • Detecção de ameaças e resposta a incidentes
    • Gerenciamento de identidade e acesso
    • Proteção de rede e aplicações
    • Proteção de dados
    • Governança e conformidade

    O objetivo é que cada participante saia com conhecimento aplicável imediatamente às suas cargas de trabalho — não com uma lista de tarefas para pesquisar depois.

    Para quem é indicado

    Os Security Activation Days são voltados para quem constrói e opera ambientes na nuvem: engenheiros de segurança, arquitetos de nuvem e times de DevOps que querem se aprofundar em capacidades específicas de segurança da AWS. Tanto quem está avaliando um serviço pela primeira vez quanto quem já o implantou e quer operacionalizá-lo melhor encontra valor nessas sessões.

    O que os participantes dizem

    Com mais de 6.400 participantes em mais de 90 eventos realizados até agora em 2026, os Security Activation Days mantêm uma avaliação média de 4,8 em 5. O formato prático é o principal diferencial apontado pelos participantes: não há substituto para configurar um serviço de verdade e ver os resultados em tempo real.

    Como se inscrever

    Os eventos acontecem ao longo do ano, em todos os fusos horários, com novas sessões sendo adicionadas regularmente. Para encontrar uma sessão e começar a aprender na prática, acesse a página de inscrições e comece a construir hoje mesmo.

    Fonte

    Complimentary virtual training: Get hands-on with AWS Security Services (https://aws.amazon.com/blogs/security/complimentary-virtual-training-get-hands-on-with-aws-security-services/)

  • AWS Client VPN passa a suportar Ubuntu 26.04 LTS

    Suporte ao Ubuntu 26.04 LTS chega ao AWS Client VPN

    A AWS expandiu a compatibilidade do seu cliente de Rede Privada Virtual (VPN) para desktop: o AWS Client VPN agora oferece suporte ao Ubuntu 26.04 LTS, a versão mais recente com suporte de longo prazo (LTS — Long-Term Support) do Ubuntu Linux.

    Com essa atualização, equipes que utilizam Linux no dia a dia — especialmente em ambientes corporativos que adotam o Ubuntu como sistema padrão — podem conectar suas máquinas com a versão mais atual do sistema operacional diretamente às redes da AWS ou a redes locais (on-premises), sem precisar recorrer a versões mais antigas do Ubuntu.

    O que é o AWS Client VPN?

    Para quem ainda não conhece o serviço: o AWS Client VPN é um serviço gerenciado da AWS que permite conectar com segurança trabalhadores remotos tanto a recursos hospedados na AWS quanto a redes corporativas locais. É uma solução voltada para o acesso remoto seguro de equipes distribuídas.

    O cliente de desktop é gratuito e pode ser baixado diretamente pelo site da AWS.

    Quais sistemas operacionais são suportados?

    Com a inclusão do Ubuntu 26.04 LTS, o AWS Client VPN passa a cobrir um conjunto bastante amplo de plataformas. Veja o panorama atual de compatibilidade:

    • Linux (Ubuntu): versões 22.04 LTS, 24.04 LTS e agora 26.04 LTS
    • macOS: Sonoma 14.0, Sequoia 15.0 e Tahoe 26.0
    • Windows: Windows 11

    Vale destacar também que o cliente já oferece suporte à arquitetura ARM64 para macOS e Windows, o que é especialmente relevante para quem utiliza Macs com chip Apple Silicon.

    Disponibilidade e custos

    A nova versão do cliente com suporte ao Ubuntu 26.04 LTS está disponível em todas as regiões onde o AWS Client VPN já está em disponibilidade geral (generally available), sem qualquer custo adicional.

    Saiba mais

    Para quem quiser se aprofundar no serviço, a AWS disponibiliza recursos oficiais:

    Fonte

    AWS Client VPN now supports Ubuntu OS version 26.04 LTS (https://aws.amazon.com/about-aws/whats-new/2026/05/aws-client-vpn-ubuntu-26/)