Category: Uncategorized

O que mudou no CloudWatch Centralization

A AWS anunciou uma atualização importante no Amazon CloudWatch Centralization: a funcionalidade agora copia automaticamente as tags dos grupos de log das contas de origem para os grupos de log criados nas contas de destino pelas regras de centralização.

Para quem não está familiarizado com o recurso, o CloudWatch Centralization permite agregar dados de log de múltiplas contas e regiões em uma única conta de destino — o que simplifica bastante o monitoramento em ambientes com múltiplas contas AWS.

Por que a propagação de tags faz diferença

Antes dessa atualização, as tags que as equipes mantinham nos grupos de log das contas de origem — como tags de custo, propriedade e conformidade — não acompanhavam os logs ao serem centralizados. Isso criava uma lacuna: os dados chegavam na conta central, mas sem o contexto de governança que as tags carregam.

Com a propagação de tags, as tags do grupo de log de origem passam a ser aplicadas ao grupo de log correspondente na conta de destino, e ficam sincronizadas de acordo com o comportamento de propagação definido durante a configuração da regra de centralização.

Exemplo prático de uso

Um caso de uso direto mencionado pela AWS: uma equipe de plataforma pode preservar tags como Application e CostCenter nos grupos de log centralizados. Com isso, é possível:

• Usar essas tags para definir escopo de acesso via condições do Gerenciamento de Identidade e Acesso (IAM);
• Gerar relatórios de gasto centralizado de logs por equipe diretamente no AWS Cost Explorer.

Ou seja, a atualização conecta dois pontos que antes exigiam trabalho manual: centralizar logs e manter a rastreabilidade de custos e responsabilidades por equipe.

Disponibilidade e como ativar

A propagação de tags está disponível em todas as regiões AWS onde o CloudWatch Centralization já está habilitado. Para verificar a lista de regiões suportadas, consulte a tabela de regiões AWS.

Para ativar o recurso, basta habilitar a propagação de tags em uma regra de centralização existente pelo console do Amazon CloudWatch, ou via Interface de Linha de Comando (AWS CLI) ou SDKs da AWS.

Para se aprofundar no funcionamento da centralização de logs com preservação de tags, a AWS disponibiliza o Guia do usuário de centralização de logs. Informações sobre preços estão na página de preços do Amazon CloudWatch.

Fonte

Amazon CloudWatch log Centralization now supports log group tag propagation (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-cloudwatch-centralization-tag-propogation/)

O que foi anunciado

Em 18 de agosto de 2026, a AWS publicou uma Atualização Crítica de Patch de Segurança — em inglês, Critical Security Patch Update (CSPU) — para o Amazon Corretto. O pacote de correções abrange tanto as versões de Suporte de Longo Prazo (Long-Term Support, LTS) quanto as versões de Lançamento de Funcionalidades (Feature Release, FR) do OpenJDK distribuídas pelo Corretto.

Versões corrigidas

As seguintes versões já estão disponíveis para download:

• Corretto 26.0.2.11.1
• Corretto 25.0.4.8.1
• Corretto 21.0.12.9.1
• Corretto 17.0.20.10.1
• Corretto 11.0.32.10.1
• Corretto 8u504

Ou seja, toda a família de versões ativamente mantidas pelo Corretto recebeu correções neste ciclo — do Corretto 8, ainda amplamente usado em sistemas legados, até o Corretto 26, a versão mais recente disponível.

O que é o Amazon Corretto

Para quem ainda não conhece: o Amazon Corretto é uma distribuição do OpenJDK sem custo, multiplataforma e pronta para uso em ambientes de produção. A AWS mantém o Corretto como uma alternativa robusta ao JDK padrão, com suporte de longo prazo e patches de segurança regulares — exatamente como este anunciado agora.

Por ser baseado no OpenJDK, o Corretto é compatível com aplicações Java existentes sem necessidade de modificações, o que o torna uma escolha popular em workloads corporativas na nuvem e on-premises.

Como obter as atualizações

Há duas formas principais de aplicar as correções:

• Download direto: acesse a página oficial do Corretto e baixe o instalador correspondente à sua versão — estão disponíveis o Corretto 26, 25, 21, 17, 11 e 8.
• Via repositório Linux: para sistemas Linux, é possível receber as atualizações configurando um repositório Corretto via Apt, Yum ou Apk, dependendo da distribuição utilizada. Essa abordagem facilita a gestão de atualizações em ambientes automatizados e pipelines de CI/CD.

Por que aplicar agora

Atualizações classificadas como críticas de segurança merecem atenção imediata. Vulnerabilidades no runtime Java podem expor aplicações a riscos sérios, especialmente em ambientes que processam dados sensíveis ou ficam expostos à internet. A recomendação para equipes que utilizam o Corretto em produção é priorizar a atualização para as versões corrigidas o quanto antes.

Contribuições e feedback

A AWS convida a comunidade a enviar feedback e contribuições pelo repositório oficial do Corretto no GitHub.

Fonte

Amazon Corretto August 2026 Critical Security Patch Updates (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-corretto-august-2026-security-updates)

O desafio: agentes modernos, ferramentas legadas

Ao implantar agentes de IA com o Amazon Bedrock AgentCore, as organizações contam com suporte nativo a mecanismos modernos de autenticação — OAuth 2.0, Gerenciamento de Identidade e Acesso da AWS (IAM) e autenticação por chave de API — diretamente pelo Amazon Bedrock AgentCore Gateway. O problema é que muitos ambientes corporativos ainda operam com mecanismos legados, como a Autenticação Básica HTTP (Basic Auth), definida na RFC 7617.

Para cobrir esse gap, a arquitetura extensível do AgentCore Gateway permite o uso de um interceptor Lambda de requisição — um código customizado executado toda vez que um agente chama uma ferramenta. A AWS publicou um guia detalhado mostrando como usar esse recurso para autenticar em APIs de ferramentas legadas com credenciais de sistema, sem expor essas credenciais ao agente.

Aviso importante antes de começar

A AWS é bastante direta no artigo: Basic Auth é uma tecnologia ultrapassada. Ela transmite credenciais como texto codificado em Base64 — o que não equivale à criptografia — e não deve ser adotada como estratégia de autenticação de longo prazo. A recomendação oficial é modernizar para OAuth 2.0, SAML, OpenID Connect ou IAM sempre que possível.

No entanto, a realidade de muitas empresas é que a modernização da autenticação e a adoção de IA agêntica são projetos com cronogramas independentes. A solução apresentada existe como medida temporária para quem precisa integrar agentes a sistemas legados agora, sem esperar a modernização completa. Se esse for o seu caso, a AWS recomenda consultar um Arquiteto de Soluções para avaliar os riscos antes de avançar.

Visão geral da solução

A solução utiliza um interceptor Lambda de requisição no AgentCore Gateway para recuperar credenciais de sistema e construir o cabeçalho Basic Auth necessário para a API da ferramenta de destino. O fluxo completo funciona assim:

• O agente de IA inicia uma chamada de ferramenta via Protocolo de Contexto de Modelo (MCP) para o gateway, acompanhada de um Token Web JSON (JWT) emitido por um provedor de identidade (IdP) configurado.
• A camada de autenticação de entrada do gateway valida o token contra o IdP especificado na configuração do autorizador de entrada.
• Após a autenticação de entrada ser bem-sucedida, o gateway invoca o interceptor Lambda de requisição, passando o payload original e os cabeçalhos da requisição — incluindo o JWT validado e seus atributos.
• O interceptor revalida o JWT como medida de defesa em profundidade e, em seguida, recupera a credencial da conta de serviço do AWS Secrets Manager.
• Com a credencial em mãos, o interceptor constrói um cabeçalho Basic Auth compatível e o adiciona à requisição de saída.
• O AgentCore Gateway encaminha a requisição ajustada para a ferramenta de destino, que autentica, processa e retorna a resposta ao agente.

Um ponto importante: como o Basic Auth transmite credenciais como texto Base64 (sem criptografia), é obrigatório garantir que toda comunicação com a API da ferramenta de destino ocorra sobre TLS. Além disso, alterações no código Lambda devem passar por revisão de duas pessoas como controle compensatório.

Gerenciamento do ciclo de vida da credencial

A credencial de sistema armazenada no Secrets Manager corresponde a uma conta de serviço no Active Directory (AD). O ciclo de vida exige uma semeadura manual única: um administrador cria a conta de serviço no AD e armazena a credencial inicial no Secrets Manager. Como o Secrets Manager não consegue ler uma senha diretamente do AD, esse passo inicial é necessário.

Como boa prática de segurança, a AWS recomenda acionar uma rotação imediata após a semeadura, para descartar a senha conhecida por humanos. A partir daí, o Secrets Manager automatiza o processo: gera periodicamente uma nova senha e atualiza tanto o Secrets Manager quanto o AD de forma simultânea, eliminando o gerenciamento manual de credenciais em ambos os sistemas.

Em tempo de execução, o interceptor Lambda recupera a credencial atual do Secrets Manager e a apresenta à ferramenta de destino, que a valida contra o AD. Para detalhes sobre como manter os dois repositórios sincronizados, a AWS disponibiliza documentação específica sobre rotação de credenciais do Active Directory armazenadas no AWS Secrets Manager.

Implementação passo a passo

O código de exemplo completo está disponível no repositório Implementando autenticação customizada para integração de ferramentas usando o Interceptor Lambda de Requisição. Os passos a seguir cobrem a configuração do interceptor e a lógica central de transformação de autenticação.

Passo 1: Vincular o interceptor Lambda de requisição ao AgentCore Gateway

O primeiro passo é configurar o AgentCore Gateway para invocar o interceptor Lambda antes de encaminhar a requisição à ferramenta de destino. Um detalhe crítico: é obrigatório habilitar a configuração passRequestHeaders. Sem ela, o interceptor não recebe o cabeçalho com o JWT de entrada, e todo o padrão de autenticação descrito aqui deixa de funcionar.

import boto3

bedrock_client = boto3.client('bedrock-agentcore-control', region_name='<your-region>')
# e.g., region_name='us-west-2'

bedrock_client.update_gateway(
    gatewayIdentifier='<your-gateway-id>',
    interceptorConfigurations=[
        {
            'interceptor': {
                'lambda': {
                    'arn': 'arn:aws:lambda:<region>:<account-id>:function:<YourInterceptorFunction>'
                }
            },
            'interceptionPoints': ['REQUEST'],
            'inputConfiguration': {
                'passRequestHeaders': True
            }
        }
    ]
)

Passo 2: Validar o JWT de entrada

O interceptor valida de forma independente a assinatura do JWT como medida de defesa em profundidade — protegendo contra cenários em que o interceptor poderia ser invocado por um caminho que contornasse a validação do gateway. Ele busca o Conjunto de Chaves Web JSON (JWKS) do provedor de identidade (com cache entre invocações Lambda aquecidas para evitar chamadas de rede repetidas), verifica a assinatura, expiração e emissor do token, e retorna os atributos decodificados.

import jwt
from jwt import PyJWKClient

COGNITO_ISSUER = f"https://cognito-idp.{COGNITO_REGION}.amazonaws.com/{YOUR_COGNITO_USER_POOL_ID}"

jwk_client = PyJWKClient(f"{COGNITO_ISSUER}/.well-known/jwks.json")

def validate_jwt(token):
    """Validate JWT signature and return decoded claims."""
    signing_key = jwk_client.get_signing_key_from_jwt(token)
    return jwt.decode(token, signing_key.key, algorithms=["RS256"], issuer=COGNITO_ISSUER)

Passo 3: Recuperar as credenciais de sistema do Secrets Manager

O interceptor recupera a credencial da conta de serviço do Secrets Manager. Essa credencial é usada para autenticar o agente de IA na ferramenta de destino. O segredo é criptografado com uma chave gerenciada pelo cliente no Serviço de Gerenciamento de Chaves da AWS (AWS KMS) e armazenado em cache na memória pelo tempo de vida (TTL) configurado, minimizando chamadas à API enquanto garante que credenciais rotacionadas sejam capturadas rapidamente.

import boto3

secrets_client = boto3.client('secretsmanager')

def get_system_credentials():
    """Retrieve the system service account credential from Secrets Manager."""
    response = secrets_client.get_secret_value(
        SecretId=os.environ['SYSTEM_CREDS_SECRET_NAME']
    )
    return json.loads(response['SecretString'])

Em relação às permissões do IAM: a função de execução do interceptor precisa de secretsmanager:GetSecretValue com escopo para o Nome de Recurso Amazon (ARN) específico do segredo, e kms:Decrypt com escopo para a chave KMS usada na criptografia. O princípio do menor privilégio deve ser aplicado restringindo o ARN do recurso em vez de usar curingas.

Vale destacar um ponto importante de segurança: o agente não tem acesso ao Secrets Manager. Apenas o interceptor Lambda de requisição — uma função determinística não influenciada pelo comportamento do modelo — recupera as credenciais. Esse isolamento é projetado para mitigar o risco de prompts adversariais instruindo o modelo a acessar ou exfiltrar segredos de autenticação, mesmo que o agente seja comprometido.

Passo 4: Construir o cabeçalho Basic Auth

Com o JWT validado e as credenciais em mãos, o interceptor constrói o cabeçalho Basic Auth para a ferramenta de destino.

def build_system_auth_header(headers):
    """Validate JWT and construct Basic Auth header with system credential."""
    auth_header = headers.get('Authorization', '')
    if not auth_header.startswith('Bearer '):
        return _error_response(401, "No Bearer token found in request.")

    # Validate JWT (defense-in-depth)
    claims = validate_jwt(auth_header[7:])
    if not claims:
        return _error_response(401, "JWT validation failed.")

    # Retrieve system credential from Secrets Manager
    creds = get_system_credentials()

    # Construct Basic Auth header (RFC 7617)
    basic_auth_encoded = base64.b64encode(
        f"{creds['username']}:{creds['password']}".encode()
    ).decode()
    headers['Authorization'] = f"Basic {basic_auth_encoded}"
    return headers

Conclusão

O interceptor Lambda de requisição no Amazon Bedrock AgentCore Gateway oferece uma ponte entre os padrões de autenticação suportados nativamente pelo gateway e os requisitos de autenticação de APIs de ferramentas legadas que ainda não migraram para padrões modernos. Como demonstrado, o interceptor valida o JWT de entrada, recupera credenciais de sistema do Secrets Manager e constrói o cabeçalho Basic Auth para a ferramenta de destino — sem modificar os esquemas das ferramentas nem a implementação do agente.

É importante reforçar: essa abordagem é um padrão de integração temporário, não uma arquitetura-alvo. Ela introduz uma credencial que precisa ser sincronizada entre o Secrets Manager e o repositório de identidades da ferramenta (como o Active Directory), adicionando sobrecarga operacional para rotação, detecção de desvios e gerenciamento de ciclo de vida. O caminho recomendado é modernizar a ferramenta de destino para aceitar OAuth 2.0, SAML ou OpenID Connect, eliminando completamente as credenciais armazenadas. Até que essa modernização seja concluída, o interceptor isola o tratamento de credenciais do runtime do agente, ajudando a garantir que o agente — um sistema não determinístico influenciado por prompts de usuários — não tenha acesso a segredos de autenticação.

Fonte

Implement custom authentication for tools integration using request Lambda interceptor in AgentCore Gateway (https://aws.amazon.com/blogs/security/implement-custom-authentication-for-tools-integration-using-request-lambda-interceptor-in-agentcore-gateway/)

Security Hub Extended chega à décima categoria

Desde fevereiro, a AWS expandiu o Security Hub Extended de 14 parceiros curados em 9 categorias para 23 parceiros distribuídos em 10 categorias. A novidade mais recente — e a mais pedida pelos clientes — é a chegada da categoria de Segurança da Cadeia de Suprimentos (Supply Chain Security), com Chainguard e Socket como os parceiros curados.

Na Black Hat deste mês, 14 desses parceiros estiveram presentes no estande da Amazon Web Services (AWS) com demonstrações ao vivo. Quatro deles realizaram apresentações no palco e dez foram destaque na transmissão ao vivo do SecurityLive. O evento também contou com uma recepção exclusiva para parceiros, reunindo lideranças da AWS com executivos dessas empresas para alinhar os próximos passos.

Por que Supply Chain Security virou prioridade de boardroom

O risco na cadeia de suprimentos de software deixou de ser uma preocupação restrita às equipes de segurança e passou a ser pauta de diretoria. Três casos recentes ilustram bem a dimensão do problema:

• SolarWinds mostrou o que acontece quando um sistema de build é comprometido.
• Log4j expôs o impacto global que uma única vulnerabilidade em dependência transitiva pode causar.
• xz utils revelou a paciência de um ataque de comprometimento de mantenedor executado ao longo de anos.

Cada um desses incidentes demonstrou uma dimensão diferente do mesmo problema — e o ritmo está se acelerando. Atacantes sabem que uma rota rápida para dentro de uma empresa é justamente pelos pacotes open source que ela confia sem perceber.

Na Black Hat, praticamente todos os clientes com quem a AWS conversou tinham esse risco no seu registro de ameaças. A maioria, porém, ainda não havia operacionalizado uma solução — porque fazer isso significava uma implantação isolada, um novo contrato, um novo console e trabalho de integração que a equipe de segurança simplesmente não conseguia priorizar. É exatamente essa fricção que o Security Hub Extended se propõe a eliminar.

Chainguard e Socket: os parceiros curados para Supply Chain

A nova categoria de Supply Chain Security segue o mesmo modelo já consolidado no Security Hub Extended: precificação por uso, uma única fatura, sem compromisso de longo prazo obrigatório. Para empresas que preferem o processo de compras tradicional, também estão disponíveis as Private Offers do Security Hub Extended — acordos com prazo definido, descontos maiores, possibilidade de consolidar gastos com múltiplos parceiros em uma única fatura AWS e opções de pagamento mensal ou anual.

O que o Chainguard faz

O Chainguard oferece dependências open source reconstruídas a partir do código-fonte em um processo de build verificado e reforçado. O resultado é que o que entra no seu ambiente é resistente a malware e tem proveniência rastreável. A pesquisa da própria empresa indica que reconstruir a partir do código-fonte teria bloqueado 98% dos pacotes maliciosos conhecidos antes de chegarem à produção. Se a origem não pode ser verificada, o pacote simplesmente não aparece no repositório do Chainguard — funcionando como um filtro entre o registro público e os desenvolvedores.

O que o Socket faz

O Socket analisa o comportamento real dos pacotes open source para bloquear dependências maliciosas no momento da instalação — não depois que uma Vulnerabilidade e Exposição Comum (CVE) é publicada dias ou semanas depois. No instante em que um pacote tenta entrar no ambiente, o Socket o sinaliza com base no que ele faz, não no que um banco de dados diz sobre ele. Além disso, a análise de alcançabilidade (reachability analysis) da ferramenta indica quais vulnerabilidades são de fato exploráveis a partir do seu código, em vez de afogar a equipe em alertas irrelevantes. A cobrança é feita pelos pacotes distintos verificados, não pela quantidade de vezes que os builds são executados.

Por que as duas ferramentas funcionam juntas

Juntos, Chainguard e Socket respondem às duas perguntas que realmente importam:

• Posso confiar no que estou baixando?
• Consigo bloquear componentes maliciosos antes que sejam incorporados às minhas aplicações?

O Chainguard protege a base sobre a qual o código é construído. O Socket protege os pacotes que são incorporados a essa base. Ambos atuam independentemente de onde você faz o deploy — em múltiplas nuvens ou on-premises.

Ao ativar os dois pelo Security Hub Extended, os alertas gerados fluem para o Security Hub no formato OCSF (Estrutura Aberta de Esquema de Cibersegurança — Open Cybersecurity Schema Framework), ao lado de todos os outros sinais. Assim, um risco na cadeia de suprimentos é correlacionado e priorizado junto com os alertas de endpoint, identidade e nuvem — e encaminhado para as ferramentas downstream já integradas ao pipeline existente.

23 parceiros, 10 categorias — construídos a partir do que os clientes pediram

Cada parceiro do Security Hub Extended está lá porque clientes sinalizaram que precisavam daquela capacidade e que aquela solução específica já funcionava para eles. As categorias evoluem conforme o cenário de ameaças muda, e novos parceiros entram quando os próprios clientes os indicam como referência.

O conjunto completo hoje abrange: endpoint, identidade, e-mail, rede, dados, browser, nuvem, IA, operações de segurança e, agora, cadeia de suprimentos. Os 23 parceiros curados são: 7AI, Britive, Chainguard, CrowdStrike, Cyera, Island, LayerX, Native Security, Noma, Okta, Oligo, Opti, Palo Alto Networks, Proofpoint, SailPoint, SentinelOne, Socket, Splunk, Sublime, Upwind, Varonis, Zenity e Zscaler.

O que vem a seguir

O foco atual da AWS é aprofundar as integrações e reduzir a fricção de ativação para que essas soluções trabalhem de forma conjunta, e não isolada. A integração mais prioritária é a correlação entre parceiros — transformar sinais de uma solução de endpoint, uma de identidade e uma de nuvem em uma única exposição e um único caminho de ataque, em vez de três alertas desconexos. Em paralelo, a AWS está reduzindo drasticamente o tempo entre a assinatura e a geração de valor: o objetivo é que clientes passem de “acabei de assinar” para “já estou vendo resultados” em horas, não semanas.

Mais novidades devem ser anunciadas antes do re:Invent.

Como começar

Se você já roda open source em produção e ainda não tem visibilidade sobre a cadeia de suprimentos, esse é o ponto de partida. É possível ativar o Chainguard e o Socket diretamente pelo console do Security Hub. Para quem gerencia múltiplos relacionamentos com fornecedores de segurança e quer entender como seria a consolidação com o Security Hub Extended, o caminho é conversar com o time de contas da AWS. A precificação de todos os parceiros está publicada na página de preços — sem necessidade de contato comercial prévio. E para quem já usa o Security Hub para gerenciamento de postura e detecção de ameaças, o plano Extended está disponível no mesmo console.

Fonte

Security Hub Extended adds Supply Chain Security as its tenth category (https://aws.amazon.com/blogs/security/security-hub-extended-adds-supply-chain-security-as-its-tenth-category/)

Federação de Identidade de Saída agora disponível na Nuvem Soberana Europeia

A AWS anunciou uma expansão importante para clientes que operam na AWS European Sovereign Cloud (Alemanha): o serviço de Gerenciamento de Identidade e Acesso (IAM) agora suporta federação de identidade de saída para serviços externos. O recurso utiliza Tokens Web JSON (JWT) de curta duração para autenticar workloads de forma segura, sem depender de credenciais de longo prazo.

O que é a AWS European Sovereign Cloud?

A AWS European Sovereign Cloud é uma nuvem independente voltada exclusivamente para a Europa, com toda a infraestrutura localizada dentro da União Europeia (UE). Ela foi projetada para ajudar organizações a atenderem requisitos regulatórios e de soberania de dados cada vez mais rigorosos — uma preocupação crescente especialmente para empresas e órgãos públicos europeus.

Como funciona a federação de identidade de saída?

Com esse recurso, workloads que rodam na AWS European Sovereign Cloud podem se autenticar com segurança em:

• Provedores de nuvem terceiros
• Provedores de SaaS
• Aplicações auto-hospedadas

O mecanismo funciona da seguinte forma: as credenciais IAM da AWS são trocadas por JWTs assinados criptograficamente e de curta duração. Esses tokens carregam informações contextuais ricas sobre o workload, o que permite que os serviços externos apliquem controles de acesso mais granulares e precisos.

O grande benefício prático é eliminar a necessidade de gerenciar credenciais de longo prazo ou implementar soluções alternativas complexas para integrar sistemas externos — um ponto de atrito comum em arquiteturas híbridas e multi-cloud.

Controle e auditoria para administradores

A AWS também garante que os times de segurança e compliance tenham controle total sobre o uso dos tokens. Os administradores podem:

• Controlar o acesso à geração de tokens por meio de políticas IAM
• Definir propriedades dos tokens, como tempo de vida, audiência e algoritmos de assinatura
• Auditar o uso dos tokens utilizando os logs do CloudTrail

Essa combinação de controles permite que as organizações atendam aos seus requisitos internos de segurança e conformidade regulatória sem abrir mão da praticidade da integração com serviços externos.

Saiba mais

Para quem quiser se aprofundar no tema, a AWS disponibilizou diferentes recursos de consulta: a página do produto de federação de identidade de saída, o guia do usuário do IAM e um post no AWS News Blog com mais detalhes sobre o funcionamento do recurso.

Fonte

AWS IAM identity federation to external services is now available in AWS European Sovereign Cloud Region (https://aws.amazon.com/about-aws/whats-new/2026/08/aws-iam-european-sovereign-cloud/)

A AWS está renovando a experiência de login

A Amazon Web Services (AWS) anunciou que está introduzindo gradualmente atualizações na experiência de login e cadastro da plataforma. Por enquanto, as mudanças estão sendo disponibilizadas para um número limitado de clientes, com expansão progressiva para todos os usuários.

O objetivo dessas atualizações é oferecer uma experiência mais consistente e moderna, com novas opções de criação e acesso a contas AWS. Para quem já é cliente, a boa notícia é direta: nada muda nas suas credenciais ou no método de autenticação que você usa hoje.

O que mudou na página de login

A mudança mais visível é na própria tela de entrada. No modelo atual, o usuário precisa escolher entre Root user (usuário raiz) e IAM user (usuário IAM) antes de digitar qualquer informação. Na versão redesenhada, essa escolha inicial desaparece: a nova página apresenta um campo único de e-mail como ponto de entrada.

O funcionamento é simples: o usuário digita seu endereço de e-mail e clica em “Continue”. A AWS então determina automaticamente qual fluxo de autenticação deve ser aplicado com base no e-mail informado — seja para usuário raiz ou para o novo método de login baseado em e-mail disponível nas contas criadas com a experiência de cadastro atualizada.

Para quem precisa acessar como usuário IAM, o caminho continua disponível: basta selecionar a opção “IAM User” na nova tela. A partir daí, o processo segue o mesmo de sempre — ID ou alias da conta, nome de usuário do AWS Identity and Access Management (IAM) e senha.

Suporte a provedores de identidade externos

Outra novidade relevante é o suporte a provedores de identidade externos na página de login. Contas AWS criadas com um provedor suportado — como Google, GitHub, Apple ou uma conta Amazon.com — agora poderão acessar a AWS diretamente por esse provedor.

É importante entender a limitação aqui: o login via provedor de identidade externo só está disponível para contas que foram criadas usando aquele provedor específico. Não é possível vincular um provedor externo a uma conta AWS existente que foi criada de outra forma.

Para organizações que utilizam o AWS IAM Identity Center ou federação IAM para acesso à AWS, o processo não muda. O login continua sendo feito pelo portal de acesso da organização ou pela URL de federação configurada — exatamente como é hoje.

Como testar a nova experiência antes do lançamento oficial

Antes de a nova interface se tornar o padrão para todos, a AWS exibirá um banner na página de login atual convidando os usuários a experimentar a versão atualizada. Ao aceitar, o usuário será direcionado para o novo fluxo naquele navegador.

A experiência anterior continuará disponível enquanto a transição não for concluída. Caso queira voltar para a interface antiga após ter optado pela nova, basta limpar os cookies do navegador.

Sessões múltiplas: tela de seleção também foi redesenhada

Além da página de login, a AWS também redesenhou a tela de seleção de sessões. Quem trabalha com múltiplas contas e roles simultaneamente vai perceber a diferença: a nova tela centraliza todas as sessões ativas em um único lugar, exibindo a conta, o role e as informações do último acesso para facilitar a identificação.

A partir dessa tela, é possível selecionar uma sessão existente, encerrar uma ou todas as sessões ativas, ou adicionar uma nova sessão para acessar outra conta AWS sem sair das sessões em andamento.

Atenção para automações e workflows com o login

Um ponto de atenção importante: se a sua organização depende da interface atual de login para automações de browser ou fluxos de trabalho com scripts, vale revisar essas configurações. As mudanças visuais e estruturais na página podem impactar esse tipo de integração.

A recomendação da AWS é usar as opções de acesso programático suportadas oficialmente para conceder acesso programático aos usuários — essa abordagem garante mais estabilidade e não depende da interface visual de login.

Resumo: o que muda e o que não muda

• Muda: o visual da página de login, com entrada unificada por e-mail e opções de provedores de identidade externos.
• Muda: a tela de seleção de sessões múltiplas, com layout mais claro e organizado.
• Não muda: as credenciais dos clientes existentes — nenhuma ação é necessária para continuar acessando a conta normalmente.
• Não muda: o fluxo de login para usuários IAM, organizações com IAM Identity Center ou federação IAM.
• Atenção: automações que interagem com a interface de login podem precisar de ajustes.

Para mais detalhes sobre a nova experiência, a AWS disponibiliza o Guia do Usuário do AWS Sign-In. Dúvidas e feedbacks podem ser enviados pelo IAM re:Post ou diretamente pelo AWS Support.

Fonte

Updates to your AWS Sign-In experience (https://aws.amazon.com/blogs/security/updates-to-your-aws-sign-in-experience/)

O que está mudando no ACM

A AWS anunciou que o AWS Certificate Manager (ACM) vai encerrar o suporte à validação de certificados públicos por e-mail. O prazo final para essa descontinuação é 30 de setembro de 2027. Quem ainda utiliza esse método de validação precisa migrar para a validação via DNS antes dessa data.

A decisão não é isolada: ela acompanha uma mudança de padrão em toda a indústria, liderada pelo Fórum de Autoridades Certificadoras e Navegadores (CA/B). Em novembro de 2025, o fórum votou pelo encerramento da validação por e-mail a partir de 15 de março de 2028. Após essa data, certificados validados por e-mail simplesmente deixarão de ser reconhecidos pelos navegadores — independentemente de qual autoridade certificadora os emitiu. A AWS está se antecipando um ano a esse prazo para dar mais tempo de adaptação às equipes.

Por que esse prazo importa

O Fórum CA/B é o organismo que define os padrões que navegadores e autoridades certificadoras devem seguir para emitir certificados publicamente confiáveis. Quando esse fórum toma uma decisão, ela afeta toda a cadeia de confiança da web. Ou seja: não se trata de uma escolha da AWS, mas de uma exigência da indústria que a AWS está incorporando ao seu serviço com antecedência.

Certificados emitidos antes de março de 2028 continuam válidos até o vencimento normal — mas não serão mais renováveis por e-mail após os prazos estabelecidos.

Cronograma completo das mudanças

Para quem usa validação por e-mail no ACM, estes são os marcos que precisam estar no radar:

• 1º de janeiro de 2027: o ACM deixa de oferecer validação por e-mail em novas regiões AWS.
• 31 de março de 2027: o ACM deixa de aceitar novos pedidos de certificado com validação por e-mail em qualquer região.
• 30 de setembro de 2027: o ACM deixa de renovar certificados existentes que ainda usam validação por e-mail em qualquer região.
• 15 de março de 2028: prazo do Fórum CA/B — nenhuma autoridade certificadora pública pode mais emitir ou renovar certificados com validação por e-mail.

Como identificar certificados validados por e-mail

O primeiro passo é saber quais certificados na sua conta ainda usam esse método. A AWS disponibiliza duas formas para isso.

Pelo console do ACM

No console do ACM, basta aplicar os filtros Método de validação = E-mail e Tipo = Emitido pela Amazon. Qualquer certificado listado precisa ser migrado antes de 30 de setembro de 2027.

Pela AWS CLI

Para quem prefere automatizar ou verificar em múltiplas regiões, a Interface de Linha de Comando da AWS (AWS CLI) também resolve. O script abaixo lista todos os certificados públicos emitidos pela Amazon que ainda utilizam validação por e-mail em uma determinada região:

# Discover email validated public certificates
region="${1:-us-east-1}"
aws acm list-certificates --region "$region" \
  --query "CertificateSummaryList[?Type=='AMAZON_ISSUED'].CertificateArn" --output text | tr '\t' '\n' | while read -r arn; do
  aws acm describe-certificate --region "$region" --certificate-arn "$arn" \
    --query 'Certificate.[DomainName,Type,DomainValidationOptions[0].ValidationMethod]' \
    --output text
done | awk -F'\t' '$3 == "EMAIL"' | column -t

Usage:
chmod +x list-email-validated-certs.sh
./list-email-validated-certs.sh           # default region, us-east-1
./list-email-validated-certs.sh us-west-2 # another region

Como migrar para validação DNS

A AWS atualizou a API UpdateCertificateOptions para permitir a troca do método de validação de e-mail para DNS diretamente no certificado existente. O ponto mais importante aqui: o ARN (Nome de Recurso Amazon) do certificado não muda. Isso significa que nenhum recurso AWS que referencia esse certificado — como um load balancer ou distribuição CloudFront — precisará ser reconfigurado.

Ao iniciar a atualização, o ACM fornece um registro CNAME que deve ser adicionado à configuração de DNS do domínio. Há uma janela de 72 horas para adicionar esse registro. Durante esse período, o certificado continua funcionando normalmente via validação por e-mail. Se as 72 horas expirarem sem que o registro DNS tenha sido adicionado, o certificado permanece ativo na validação por e-mail e a migração pode ser tentada novamente quando conveniente.

Após a conclusão da validação DNS, o ACM passa a renovar o certificado automaticamente, sem necessidade de intervenção manual — desde que o registro CNAME permaneça na configuração de DNS.

Migrando pelo console

Ao abrir um certificado com validação por e-mail no console do ACM, a opção Atualizar método de validação estará disponível no topo da página. Após acionar a atualização, o console exibe um aviso com a opção de visualizar e baixar os registros CNAME em formato CSV para importar em outros provedores de DNS.

Para quem usa o Amazon Route 53, há uma opção de criação automática dos registros de validação com um único clique.

Migrando pela AWS CLI

Para a migração via linha de comando, a AWS disponibiliza um guia detalhado na documentação oficial. Consulte o guia de migração de e-mail para DNS para instruções completas.

Alternativas disponíveis após o encerramento da validação por e-mail

Com o fim da validação por e-mail, o ACM passa a suportar dois métodos para novos certificados:

• Validação DNS: adicione um registro CNAME à configuração de DNS do domínio. O ACM renova automaticamente os certificados enquanto o registro estiver presente. Este é o método recomendado para a maioria dos casos de uso.
• Validação HTTP para CloudFront: o ACM fornece um token exclusivo que deve ser hospedado em um caminho de URL específico no domínio. Este método está disponível exclusivamente para certificados usados com o Amazon CloudFront.

Ambos os métodos eliminam a etapa de aprovação manual que a validação por e-mail exigia, permitindo que o ACM cuide das renovações de forma totalmente automática.

Conclusão

A descontinuação da validação por e-mail no ACM é uma consequência direta das novas exigências da indústria de certificados digitais. A AWS está se movendo com antecedência em relação ao prazo do Fórum CA/B, o que dá às equipes tempo suficiente para planejar e executar a migração sem pressão de última hora.

O caminho recomendado é claro: identificar os certificados com validação por e-mail, usar a API UpdateCertificateOptions para migrar para DNS em cada um deles, adicionar o registro CNAME no DNS, e deixar o ACM cuidar das renovações automaticamente a partir daí. Dúvidas ou dificuldades durante o processo podem ser direcionadas ao AWS Support ou ao Fórum ACM no AWS re:Post.

Fonte

AWS Certificate Manager will discontinue email validation to prove domain validation for certificates (https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-email-validation-to-prove-domain-validation-for-certificates/)

O que mudou no AWS Client VPN

A AWS anunciou uma versão completamente reconstruída do seu cliente VPN: o AWS VPN Client v6.0.x. A atualização traz três melhorias principais que vinham sendo esperadas por equipes de infraestrutura: suporte a Interface de Linha de Comando (CLI), controles administrativos centralizados e tempo de estabelecimento de conexão mais rápido.

Suporte a CLI: automação sem gambiarras

Até agora, quem precisava integrar a conectividade VPN a fluxos automatizados dependia de ferramentas de terceiros ou de intervenção manual — o que criava fricção em pipelines de infraestrutura como código e ambientes de automação. Com o novo suporte à CLI, esse problema deixa de existir.

A CLI do AWS VPN Client oferece paridade completa de recursos com a interface gráfica (GUI). Isso significa que é possível incluir conexões VPN diretamente em scripts de automação e em deployments de infraestrutura como código, com operações rodando em segundo plano sem depender da interface visual.

Vale destacar: a GUI e a CLI podem ser usadas simultaneamente, e as conexões VPN persistem independentemente de qual interface esteja ativa no momento.

Controles administrativos: gestão centralizada de perfis

Outro ponto relevante desta atualização é a chegada dos controles administrativos no cliente. Antes, os perfis de VPN precisavam ser distribuídos para todos os usuários da organização — e qualquer usuário podia gerenciá-los sem restrições de permissão.

Agora, com os controles administrativos, as equipes de TI e segurança ganham mais governança sobre o ambiente:

• É possível centralizar a aplicação de políticas de VPN, vinculando perfis a usuários específicos;
• Perfis globais podem ser gerenciados para todos os usuários de um dispositivo;
• Configurações aprovadas de VPN podem ser aplicadas de forma padronizada em toda a organização.

Conexões mais rápidas com OpenVPN3

O cliente foi reconstruído com base no OpenVPN3, o que resulta em um estabelecimento de conexão mais rápido em todos os sistemas operacionais suportados. A mudança é transparente para o usuário final, mas representa uma melhoria real na experiência do dia a dia.

Compatibilidade e disponibilidade

A versão 6.0 em diante mantém compatibilidade retroativa completa com os endpoints existentes do AWS Client VPN — ou seja, não é necessário fazer nenhuma alteração nos endpoints já configurados.

O cliente atualizado já está disponível para download nas seguintes plataformas:

• Windows (x64/ARM)
• macOS (x64/ARM)
• Linux (x64)

Não há cobranças adicionais além da precificação padrão do AWS Client VPN. Para se aprofundar, a AWS disponibiliza a documentação oficial com todos os detalhes técnicos da atualização.

Fonte

AWS Client VPN now supports CLI, administration controls, and faster connections (https://aws.amazon.com/about-aws/whats-new/2026/08/aws-client-vpn-cli/)

O problema clássico de começar com IAM

Quem já montou uma aplicação na Amazon Web Services (AWS) sabe bem como é: você quer focar no que está construindo, mas antes de qualquer coisa precisa parar e configurar o Gerenciamento de Identidade e Acesso (IAM). Praticamente todo serviço AWS que age em seu nome precisa de uma função IAM — uma identidade que o serviço assume para acessar seus recursos com um conjunto definido de permissões.

Isso significa escrever uma política de confiança, escolher as permissões certas para a carga de trabalho e anexar tudo ao recurso. Para padrões comuns e repetitivos, esse processo é previsível — mas ainda assim consome tempo e exige conhecimento prévio de IAM, especialmente para quem está começando.

Foi exatamente esse atrito que a AWS quis eliminar com o lançamento do IAM Role Manager.

O que é o IAM Role Manager

O IAM Role Manager é um recurso que, quando habilitado, faz com que a AWS crie e configure automaticamente as funções IAM necessárias enquanto você constrói recursos nos consoles de serviços suportados. Em vez de interromper o fluxo de trabalho para configurar permissões manualmente, o Role Manager provisiona e anexa a função adequada como parte do mesmo processo de criação do recurso.

O resultado prático é direto: você cria o recurso que precisa, e a função IAM já vem configurada e pronta. Isso reduz o tempo de início para minutos e elimina a necessidade de experiência prévia com IAM para dar os primeiros passos.

Um exemplo concreto: ao criar uma função AWS Lambda, a função de execução já é criada e anexada automaticamente, sem que seja necessário sair do fluxo de criação para configurá-la separadamente.

Vale destacar que as funções criadas pelo Role Manager são funções IAM comuns. Elas podem ser visualizadas, editadas ou excluídas da mesma forma que qualquer outra função criada manualmente. O controle permanece totalmente nas mãos do time.

Como habilitar o Role Manager

O Role Manager opera em dois estados: habilitado e desabilitado. Quando habilitado em uma conta, ele autoriza a AWS a criar funções nessa conta conforme necessário.

Para ativá-lo, o processo é simples:

• Abra o console do IAM e acesse Configurações da conta (Account settings).
• Na seção do Role Manager, selecione Habilitar (Enable).

Em ambientes com múltiplas contas organizadas no AWS Organizations, administradores podem usar uma Política de Controle de Serviço (SCP — Service Control Policy) para controlar se as contas-membro podem habilitar ou usar o Role Manager.

Um ponto importante: o Role Manager não interfere nos serviços que já criam funções automaticamente ao provisionar recursos. Esses serviços continuam funcionando como antes, e as funções já existentes seguem ativas normalmente. O que o Role Manager acrescenta é um controle centralizado em nível de conta e cobertura para casos que os fluxos nativos não conseguem resolver — como tarefas cujas permissões não podem ser determinadas antecipadamente pela AWS, por exemplo, a execução de código próprio.

Exemplo prático: regra no Amazon EventBridge

Para ilustrar o funcionamento, considere uma tarefa comum: criar uma regra no Amazon EventBridge que aciona um destino, como uma fila do Serviço de Fila Simples da Amazon (Amazon SQS) ou um tópico do Serviço de Notificação Simples da Amazon (Amazon SNS).

Sem o Role Manager, o fluxo seria interrompido nesse ponto para criar manualmente uma função que permita ao EventBridge invocar o destino — o que envolve escrever a política de confiança, definir as permissões e só então retornar à criação da regra.

Com o Role Manager habilitado, basta definir a regra e seu destino e clicar em Criar. O Role Manager provisiona e anexa a função automaticamente. O console do EventBridge exibe a regra criada e pronta para uso, sem que o fluxo de criação tenha sido interrompido em nenhum momento.

Tecnicamente, isso funciona por meio de um template de função gerenciado pela AWS — uma definição que a AWS constrói e mantém para uma tarefa específica, com a política de confiança e as permissões já definidas. O console chama uma nova API do IAM chamada AcquireRole, que localiza o template correspondente, provisiona a função a partir dele e a retorna ao serviço solicitante. Dependendo do contexto, o AcquireRole pode criar uma nova função ou reutilizar uma já existente que se encaixe no perfil, evitando que a conta acumule funções duplicadas para a mesma finalidade.

O Role Manager cria a função usando as permissões IAM do próprio usuário, não de um papel separado do gerenciador. Para provisionar uma nova função, são necessárias permissões mínimas de criação e anexação de funções. Quando o AcquireRole reutiliza uma função existente, ele precisa apenas de iam:GetRole e iam:GetRoleTemplateVersion. Se alguma permissão estiver faltando, o console informa qual é necessária.

Executando código que acessa outros serviços AWS

Nem todo caso tem um conjunto de permissões que a AWS consegue definir antecipadamente. Quando uma função executa código próprio — como uma função Lambda — a AWS não tem como saber quais serviços esse código vai chamar.

O Role Manager também cobre esse cenário: ao criar uma função Lambda com o Role Manager habilitado, ele anexa uma função de execução que o código pode usar imediatamente. Essa função pode ser refinada depois, quando as chamadas reais forem conhecidas.

Como as permissões necessárias não são conhecidas de antemão, o Role Manager anexa a política gerenciada PowerUserAccess à função. Essa política concede acesso amplo aos serviços AWS, permitindo que a função chame o que precisar. Por design, ela não concede permissão para gerenciar o IAM, o AWS Organizations ou as configurações da conta. O template também configura a função para confiar apenas no serviço Lambda.

Com isso, a função Lambda fica pronta para execução imediatamente após a criação, com a função de execução já anexada e visível na aba de configurações. É possível abrir essa função no console do IAM para revisar suas permissões a qualquer momento.

Toda função criada pelo Role Manager registra o template de origem. Tanto o GetRole quanto o ListRoles retornam essa referência, permitindo identificar facilmente quais funções foram criadas pelo gerenciador. As políticas de confiança e permissões são lidas da mesma forma que em qualquer outra função, e cada criação é registrada pelo AWS CloudTrail.

Refinando as permissões conforme a carga de trabalho amadurece

O Role Manager foi pensado para acelerar o início — mas a recomendação é clara: à medida que as cargas de trabalho amadurecem, as funções criadas por ele devem ser refinadas para seguir o princípio do menor privilégio.

Quando chegar esse momento, é possível desabilitar o Role Manager e utilizar gratuitamente a análise de acesso não utilizado do AWS IAM Access Analyzer por 90 dias sem custo adicional. O Access Analyzer analisa como cada função foi utilizada e recomenda uma política que mantém apenas as permissões realmente necessárias. A sugestão é começar pelas funções anexadas às cargas de trabalho mais críticas e ir ampliando o escopo gradualmente.

Desabilitar o Role Manager não interrompe nada que já esteja em execução: os recursos mantêm as funções que têm, essas funções permanecem na conta até que sejam alteradas, e a partir desse ponto novas funções são criadas manualmente, como sempre foi.

Se a preferência for ajustar apenas uma função específica sem desabilitar o Role Manager para toda a conta, basta editar essa função. Ao fazer isso, ela sai do controle do Role Manager e passa a ser uma função gerenciada pelo cliente, com as alterações preservadas.

A recomendação geral da AWS é manter o Role Manager habilitado em contas de sandbox e desenvolvimento para ganhar agilidade. Para cargas de trabalho em produção, a orientação é desabilitá-lo e refinar as funções criadas para o menor privilégio antes de ir ao ar.

Conclusão

O IAM Role Manager representa uma mudança significativa no ponto de partida para trabalhar com IAM na AWS. Ao automatizar a criação e configuração de funções durante o processo de construção de recursos, a AWS reduz uma das principais barreiras de entrada para quem está começando — e elimina trabalho repetitivo para quem já tem experiência.

O recurso não remove o controle do desenvolvedor: as funções criadas são funções IAM comuns, totalmente visíveis e editáveis. A proposta é acelerar o início e permitir que o refinamento de permissões aconteça de forma progressiva, conforme a carga de trabalho evolui.

Para começar, basta habilitar o Role Manager nas configurações de conta do console IAM e criar um recurso em um serviço suportado. Mais detalhes sobre a criação de funções IAM e a lista de serviços suportados estão disponíveis no Guia do Usuário do IAM.

Fonte

How AWS IAM role manager rethinks the starting point for IAM roles (https://aws.amazon.com/blogs/security/how-aws-iam-role-manager-rethinks-the-starting-point-for-iam-roles/)

O que foi anunciado

A AWS anunciou a disponibilidade geral do role manager, uma nova funcionalidade dentro do Gerenciamento de Identidade e Acesso (IAM) da AWS que automatiza a criação das roles necessárias para os serviços da plataforma. A novidade foi disponibilizada em 12 de agosto de 2026.

Como funciona o role manager

A ideia central é simples: ao configurar um serviço compatível pelo console da AWS, o role manager cuida automaticamente da criação da role necessária — ou reutiliza uma já existente na conta, caso ela já tenha as permissões adequadas. Isso elimina aquele passo manual de criar e configurar roles do zero toda vez que um novo serviço é habilitado.

A funcionalidade pode ser ativada ou desativada a qualquer momento. Além disso, é possível inspecionar os templates gerenciados pela AWS que o role manager utiliza para criar as roles, garantindo transparência sobre o que está sendo provisionado.

Serviços suportados no lançamento

No lançamento, o role manager oferece suporte a 6 consoles de serviços da AWS, incluindo AWS Lambda e Amazon EventBridge. Por exemplo, ao criar uma função Lambda, o role manager aplica automaticamente o template gerenciado pela AWS correspondente a esse fluxo de trabalho.

Visibilidade e controle total

As roles criadas pelo role manager aparecem no console do IAM como roles padrão — ou seja, o usuário mantém controle total sobre elas. É possível identificar facilmente quais roles foram criadas por essa funcionalidade, o que facilita a auditoria e o gerenciamento.

Quando chegar o momento de restringir permissões com mais precisão, basta desativar o role manager e utilizar o IAM Access Analyzer para refinar cada role, deixando apenas as permissões estritamente necessárias para cada caso.

Disponibilidade

O role manager está disponível em todas as regiões da AWS, com exceção das regiões AWS GovCloud (US) e das regiões da China.

Saiba mais

Para se aprofundar no tema, a AWS disponibilizou dois recursos de referência: o post Como o gerenciador de roles do AWS IAM repensa o ponto de partida para roles IAM no AWS Security Blog, e a documentação Crie roles automaticamente com o role manager no Guia do Usuário do IAM.

Fonte

AWS IAM now provides role manager to set up IAM roles automatically (https://aws.amazon.com/about-aws/whats-new/2026/08/aws-iam-role-manager)