O que mudou no AWS STS
O Serviço de Token de Segurança da AWS (AWS STS) passou por uma atualização relevante para quem trabalha com credenciais temporárias na nuvem. A AWS simplificou os limites de tamanho dos tokens de sessão e passou a reportar essas métricas de forma muito mais transparente. Se você usa AssumeRole, federação com SAML ou WebIdentity, ou qualquer outro mecanismo baseado em credenciais temporárias, essa mudança afeta diretamente o seu ambiente.
Em resumo: o antigo modelo de dois limites separados foi substituído por um único limite de 4.096 bytes para o token de sessão montado. Além disso, o tamanho do token agora é reportado nas respostas de API, nos eventos do AWS CloudTrail e nas métricas do Amazon CloudWatch.
Entendendo o que era o problema antes
Antes dessa mudança, o AWS STS aplicava dois limites distintos sobre os tokens de sessão. O primeiro incidia sobre o que era chamado de packed policy — a representação serializada e comprimida das políticas de sessão e tags que você passa na chamada. O segundo era um limite geral sobre o token montado como um todo, que incluía o packed policy mais o contexto adicionado pela própria AWS.
O grande problema? Quando uma requisição falhava por exceder qualquer um dos dois limites, a exceção retornada era a mesma: PackedPolicyTooLargeException. Ou seja, você recebia o erro mas não sabia qual dos dois limites havia sido ultrapassado. Isso tornava o diagnóstico frustrante e os ajustes, no mínimo, baseados em tentativa e erro.
O que mudou de fato
A AWS realizou três alterações principais nesse comportamento:
1. Limite único
O modelo de dois limites foi descartado. Agora existe apenas um: o token de sessão montado não pode ultrapassar 4.096 bytes. O limite separado do packed policy, que tornava as falhas difíceis de prever, foi removido. Quando o token excede esse único limite, o STS ainda retorna PackedPolicyTooLargeException — mas agora a mensagem de erro informa o tamanho atual do token e o máximo permitido, em bytes. O código de tratamento de erros existente continua funcionando sem necessidade de atualização de SDK.
2. Visibilidade do tamanho do token
Cada resposta bem-sucedida das APIs de emissão de sessão do STS agora inclui dois novos campos:
SessionTokenSize: tamanho do token em bytes.SessionTokenUtilization: percentual do limite de 4.096 bytes que o token está consumindo.
Para garantir compatibilidade retroativa, o campo PackedPolicySize continua presente nas respostas, mas agora ele reporta o mesmo valor percentual que SessionTokenUtilization. Isso significa que aplicações que usam versões mais antigas do SDK conseguem monitorar a utilização sem precisar atualizar nada. Vale notar que os valores de PackedPolicySize podem parecer menores do que antes, mesmo sem mudança no conteúdo do token — isso é esperado e reflexo da mudança de semântica do campo.
Esses campos também são registrados nos eventos do CloudTrail. Um exemplo de resposta da API ficaria assim:
{
"Credentials": {
"AccessKeyId": "REDACTED",
"SecretAccessKey": "REDACTED",
"SessionToken": "REDACTED",
"Expiration": "2026-06-30T12:00:00Z"
},
"AssumedRoleUser": {
"...": "..."
},
"PackedPolicySize": 61,
"SessionTokenSize": 2532,
"SessionTokenUtilization": 61
}E no CloudTrail, o evento de AssumeRole passaria a registrar:
{
"eventName": "AssumeRole",
"responseElements": {
"credentials": {
"...": "..."
},
"assumedRoleUser": {
"...": "..."
},
"packedPolicySize": 61,
"sessionTokenUtilization": 61,
"sessionTokenSize": 2532
}
}No Amazon CloudWatch, o STS publica as métricas SessionTokenSize e SessionTokenMaxSize no namespace AWS/STS, permitindo a criação de dashboards e alarmes baseados no tamanho real dos tokens em circulação.
3. Novo parâmetro para testes: MinimumSessionTokenSize
A AWS adicionou o parâmetro opcional MinimumSessionTokenSize nas APIs de emissão de sessão do STS. Com ele, é possível forçar a geração de um token com pelo menos o tamanho especificado — até o máximo de 4.096 bytes. Isso torna os testes de infraestrutura muito mais diretos: em vez de tentar estimar o tamanho do token a partir do conteúdo das políticas e tags, você simplesmente solicita um token do tamanho que deseja testar.
O que essa mudança significa para você
O impacto varia de acordo com a situação de cada ambiente. A AWS descreve os cenários mais comuns:
Se você nunca enfrentou erro de tamanho de token
Provavelmente não vai notar diferença imediata. Os tokens permanecem do tamanho atual e ganham mais margem. Com o tempo, porém, eles podem crescer além do que seus sistemas já lidaram. A recomendação é usar MinimumSessionTokenSize para descobrir qual é o tamanho máximo que sua infraestrutura consegue suportar.
Se você já recebeu PackedPolicyTooLargeException
Algumas requisições que antes falhavam agora podem ter sucesso com o limite único. Vale revisar os contornos (workarounds) que foram implementados especificamente para evitar erros de tamanho e avaliar se ainda são necessários. As boas práticas gerais continuam válidas: usar casing consistente em tags e reutilizar valores de tags melhora a compressão, assim como manter as políticas de sessão mais concisas. Nenhuma mudança de código é necessária para o tratamento de erros.
Se seus sistemas têm limites próprios de tamanho para credenciais
Se a sua aplicação usa um SDK da AWS para obter credenciais temporárias e fazer chamadas de API, o SDK gerencia o token de sessão internamente — o tamanho não afeta o código da aplicação. O foco deve ser nos sistemas que armazenam ou repassam tokens de sessão: balanceadores de carga, proxies, caches e bancos de dados. Esses sistemas podem ter limites que tokens menores nunca alcançavam. Por exemplo, uma coluna de banco de dados definida como varchar(2048) não consegue armazenar um token de 4.096 bytes. Mapeie onde você persiste ou repassa tokens e identifique o tamanho máximo que cada sistema suporta.
O que fazer a seguir
A AWS recomenda três passos para preparar os ambientes para essa mudança:
1. Valide o tamanho máximo que seus sistemas suportam
Use MinimumSessionTokenSize para descobrir o limite de cada sistema na sua infraestrutura. O limite de 4.096 bytes reflete as necessidades atuais, mas não é um teto permanente — pode crescer conforme a AWS introduz novas capacidades, como chaves de contexto adicionais para novos serviços, metadados de auditoria mais ricos e assinaturas criptográficas maiores na transição para algoritmos pós-quânticos. Evite fixar o valor máximo atual no código e reavalie premissas de tamanho fixo caso o limite mude.
Um ponto importante: o STS serializa e comprime as políticas de sessão e tags ao montar o token. O resultado da compressão depende do conteúdo real, não apenas do seu comprimento. Dois conjuntos de tags com a mesma quantidade de caracteres podem gerar tokens de tamanhos diferentes. Por isso, MinimumSessionTokenSize é uma forma mais confiável de testar a infraestrutura do que estimar a partir do tamanho do conteúdo de entrada.
O comando abaixo, usando o AWS Command Line Interface (AWS CLI), permite iniciar os testes com o maior token possível:
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/MyRole \
--role-session-name validation-test \
--minimum-session-token-size 4096Se algum sistema truncar ou rejeitar o token, reduza o valor para encontrar o tamanho que a infraestrutura suporta e, onde possível, aumente esse limite. O parâmetro MinimumSessionTokenSize está disponível no SDK mais recente da AWS, no AWS CLI e nas ferramentas para PowerShell. Consulte a referência da API do STS para mais detalhes. Se o seu SDK ou CLI for anterior à adição desse parâmetro, atualize para utilizá-lo.
2. Monitore o tamanho dos tokens de sessão
Se a sua infraestrutura tem restrições de tamanho, o monitoramento permite identificar tokens que estão se aproximando do limite antes que uma requisição falhe. O STS reporta o tamanho por três canais:
- Na resposta da API: lendo
SessionTokenUtilizationeSessionTokenSizediretamente da resposta. Requer o SDK mais recente. Se o SDK expõeSessionTokenUtilization, use esse campo — o nome reflete melhor o significado atual. Se não, usePackedPolicySizepara monitorar o mesmo percentual de utilização sem precisar atualizar o SDK. - No CloudWatch: as métricas
SessionTokenSizeeSessionTokenMaxSizeficam disponíveis no namespaceAWS/STSpara dashboards e alarmes. Configure o alarme com base no limite que você encontrou durante os testes — não no máximo de 4.096 bytes, que é igual para todas as contas. O seu limite de infraestrutura é o que importa. - No CloudTrail: cada evento de emissão de sessão registra
SessionTokenUtilizationeSessionTokenSizepara chamadas bem-sucedidas.
A recomendação da AWS é monitorar SessionTokenSize para acompanhar o tamanho em bytes ao longo do tempo.
Conclusão
Com essa atualização, o AWS STS passa a oferecer mais espaço para tags de sessão, valores de tags e políticas de sessão, além de uma experiência de diagnóstico muito mais clara. A substituição dos dois limites por um único de 4.096 bytes elimina a ambiguidade nas falhas, e a visibilidade do tamanho do token via API, CloudWatch e CloudTrail permite agir de forma proativa antes que qualquer problema aconteça.
Para equipes que trabalham com credenciais de segurança temporárias e tags de sessão no AWS STS, o próximo passo prático é validar os sistemas com MinimumSessionTokenSize e configurar monitoramento com SessionTokenUtilization e SessionTokenSize. Consulte a referência da API do AWS STS para todos os detalhes técnicos.
Fonte
AWS STS simplifies session token size limits and adds session token size monitoring (https://aws.amazon.com/blogs/security/aws-sts-simplifies-session-token-size-limits-and-adds-session-token-size-monitoring/)
Leave a Reply