Category: Uncategorized

  • Autenticação customizada para integração de ferramentas com o interceptor Lambda no AgentCore Gateway

    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 adiciona Segurança da Cadeia de Suprimentos como sua décima categoria

    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 do AWS IAM para Serviços Externos Chega à Região AWS European Sovereign Cloud

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

  • Novidades na Página de Login da AWS: O Que Mudou e o Que Você Precisa Saber

    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.

    Imagem original — fonte: Aws

    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.

    Imagem original — fonte: Aws

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

  • AWS Certificate Manager vai encerrar a validação de domínio por e-mail

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

  • AWS Client VPN agora suporta CLI, controles administrativos e conexões mais rápidas

    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:

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

  • Como o AWS IAM Role Manager repensa o ponto de partida para funções IAM

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

  • AWS IAM agora oferece gerenciador de roles para configuração automática

    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)

  • Relatório de Avaliação Independente do Landing Zone Accelerator para C5:2020 já está disponível no AWS Artifact

    O que é o C5:2020 e por que isso importa para empresas na Europa

    Organizações que operam na Alemanha e em outros países europeus enfrentam uma exigência crescente: precisam comprovar que seus ambientes de nuvem estão em conformidade com o Catálogo de Critérios de Conformidade para Computação em Nuvem (C5:2020), um padrão publicado pelo Escritório Federal de Segurança da Informação da Alemanha (BSI — Bundesamt für Sicherheit in der Informationstechnik). Trata-se de um dos marcos regulatórios mais rigorosos da Europa para uso de nuvem pública, e atender a ele exige esforço considerável de arquitetura, documentação e evidências técnicas.

    É nesse contexto que a AWS fez um anúncio relevante: a disponibilização de um novo relatório de avaliação independente no AWS Artifact, que analisa como o Landing Zone Accelerator (LZA) cobre os requisitos do C5:2020 por meio da implementação de quase 200 controles de segurança nativos.

    O que é o Landing Zone Accelerator (LZA)

    O Landing Zone Accelerator (LZA) é uma solução da AWS que automatiza a criação de um ambiente de nuvem seguro e bem arquitetado desde o início. Ele define uma linha de base de arquitetura de segurança e provisiona automaticamente o ambiente AWS de forma que ele escale conforme a organização cresce.

    O LZA pode ser utilizado em duas configurações: a configuração padrão com múltiplas contas (multi-account) ou como uma opção de implantação baseada em contêiner no AWS European Sovereign Cloud. Essa segunda opção é especialmente importante para clientes com requisitos de residência de dados, pois permite usar a mesma linha de base de configuração de segurança em um ambiente soberano europeu.

    No ano passado, a AWS já havia introduzido suporte do LZA para soberania digital. Agora, o passo seguinte é a publicação desse relatório de avaliação independente voltado ao C5:2020.

    O que traz o novo relatório de avaliação independente

    O novo relatório de avaliação independente foi produzido pela Schellman, uma empresa parceira da AWS especializada em avaliações de conformidade de terceiros. A Schellman analisou a arquitetura de Configuração Universal do LZA e a linha de base de controles de segurança, verificando como essa infraestrutura se alinha aos requisitos técnicos do C5:2020.

    As principais conclusões do relatório são:

    • O LZA pode ajudar a implementar 325 controles de segurança no total, distribuídos em oito áreas de controle do C5:2020.
    • O documento descreve o design da arquitetura do LZA, as melhores práticas de segurança e as considerações de escopo para avaliações C5:2020.
    • Este é o primeiro relatório C5 independente para o LZA — e está prevista uma atualização em 2027 para cobrir a revisão C5:2026, que ainda está pendente.

    Como isso acelera a jornada de conformidade

    É importante entender a diferença entre o que a AWS já oferecia e o que esse novo relatório acrescenta. A AWS já disponibiliza os relatórios de atestação C5 Tipo 2, que cobrem a “segurança da nuvem” — ou seja, a responsabilidade da própria AWS como provedora de infraestrutura. O novo relatório do LZA, por sua vez, oferece uma opinião independente sobre como a linha de base de segurança provisionada pelo LZA se alinha aos critérios de “segurança na nuvem” — a parte que é responsabilidade do cliente.

    Essa distinção é fundamental dentro do modelo de responsabilidade compartilhada. O LZA assume parte dessa responsabilidade do lado do cliente, definindo uma arquitetura de segurança e automatizando o provisionamento do ambiente. Com o relatório em mãos, as organizações podem:

    • Implantar o LZA já com uma cobertura de controles documentada e avaliada de forma independente;
    • Usar o relatório para entender o escopo de cobertura existente e identificar o que ainda precisa ser customizado;
    • Utilizar o LZA Compliance Workbook para construir e adaptar a documentação de conformidade para os casos de uso específicos da organização.

    O resultado prático é uma redução significativa no tempo gasto com design de arquitetura, coleta de evidências e preparação para avaliações C5:2020.

    Recursos disponíveis: Workbook, repositório e agente de conformidade com IA

    Além do relatório de avaliação, a AWS também disponibilizou no AWS Artifact o LZA Compliance Workbook gratuitamente. Esse documento mapeia os identificadores de requisitos do C5:2020 para declarações de implementação de segurança, oferecendo um ponto de partida para que as equipes possam customizar e aprimorar a documentação de conformidade após implantar o LZA.

    O repositório de Configuração Universal do LZA no GitHub também é um recurso de código aberto valioso. Tanto o Workbook quanto o repositório podem ser usados como base de conhecimento para criar um agente de chat de conformidade de segurança com o Amazon Bedrock, capaz de apoiar equipes de governança e garantia de conformidade no dia a dia.

    Como começar

    Para acessar os recursos, é necessário estar autenticado em uma conta AWS. A partir daí, é possível:

    Por que isso é relevante para o público brasileiro

    Embora o C5:2020 seja um padrão alemão, ele é cada vez mais adotado como referência de conformidade em toda a Europa — e empresas brasileiras com operações no continente europeu ou que atendem clientes europeus precisam estar atentas a esse tipo de exigência regulatória. Além disso, a abordagem do LZA — automatizar uma linha de base de segurança documentada e avaliada de forma independente — é um modelo que pode inspirar práticas de conformidade em outros contextos regulatórios.

    A disponibilização desse relatório no AWS Artifact representa um avanço concreto para reduzir a carga de trabalho de equipes de segurança e conformidade que precisam demonstrar aderência a padrões rigorosos sem partir do zero.

    Fonte

    Landing Zone Accelerator Independent Assessment Report for C5:2020 now available on AWS Artifact (https://aws.amazon.com/blogs/security/landing-zone-accelerator-independent-assessment-report-for-c52020-now-available-on-aws-artifact/)

  • AWS conclui com êxito a avaliação NHS DSPT 2025-26

    AWS atinge nível máximo na avaliação NHS DSPT 2025-26

    A Amazon Web Services (AWS) anunciou a conclusão bem-sucedida da avaliação do Kit de Ferramentas de Segurança e Proteção de Dados do NHS (NHS DSPT) referente ao ciclo 2025-26, alcançando o status Standards Exceeded — o nível mais alto possível dentro dessa certificação.

    O que é o NHS DSPT?

    O NHS DSPT é uma ferramenta de avaliação que permite às organizações medir seu desempenho em relação aos 10 padrões de segurança de dados do Guardião Nacional de Dados (National Data Guardian). Todas as organizações que acessam dados de pacientes e sistemas do NHS — o sistema nacional de saúde do Reino Unido — são obrigadas a utilizar esse toolkit para demonstrar conformidade com os padrões exigidos de segurança de dados.

    Entre os temas cobertos pela avaliação estão:

    • Dados Pessoais Confidenciais
    • Planejamento de Continuidade
    • Proteção de TI
    • Outros padrões relacionados à proteção de dados no setor de saúde

    Por que a AWS passa por essa avaliação?

    A AWS submete-se ao NHS DSPT para oferecer garantias concretas aos seus clientes de que a empresa adota boas práticas de segurança de dados. Trata-se de um compromisso importante para organizações do setor de saúde no Reino Unido que utilizam a nuvem AWS para armazenar ou processar informações sensíveis de pacientes.

    A certificação obtida neste ciclo é válida até 30 de junho de 2027. O certificado que confirma a conformidade está disponível tanto no site do NHS England quanto no AWS Artifact.

    O que é o AWS Artifact?

    O AWS Artifact é um portal de autoatendimento que oferece acesso sob demanda a relatórios de conformidade da AWS. Por meio dele, clientes conseguem acessar documentos de auditoria e certificações relevantes para suas necessidades regulatórias. Para utilizá-lo, basta acessar o AWS Artifact no Console de Gerenciamento da AWS ou consultar o guia de Introdução ao AWS Artifact.

    Responsabilidade Compartilhada

    Vale reforçar um conceito fundamental para qualquer cliente AWS: segurança e conformidade na nuvem são uma responsabilidade compartilhada entre a AWS e o próprio cliente. Quando uma organização migra seus sistemas e dados para a nuvem, as responsabilidades de segurança são divididas entre o cliente e o provedor de serviços. Para entender melhor essa divisão, a AWS disponibiliza o Modelo de Responsabilidade Compartilhada de Segurança da AWS.

    Para conhecer todos os programas de conformidade da AWS, acesse a página de Programas de Conformidade da AWS.

    Fonte

    AWS successfully completed its 2025-26 NHS DSPT assessment (https://aws.amazon.com/blogs/security/aws-successfully-completed-its-2025-26-nhs-dspt-assessment/)