AWSが、一時的な認証情報を発行する仕組み「STS(Security Token Service)」のセッショントークンについて、サイズの制限を整理し、サイズを監視できる機能を追加しました。トークンが大きすぎると認証のリクエストが失敗する、という運用上の落とし穴に関わる変更です。
何が変わったのか
AWSの発表によると、これまでSTSのトークンには、ポリシーの制限と、組み立て後のトークン全体の制限という2種類のサイズ制限がありました。今回、これらが廃止され、組み立て後のセッショントークンに対する単一の「4,096バイト」の制限に整理されました。AWSは、この4,096バイトは現時点の上限で、恒久的なものではないとしています。
あわせて、トークンの実際のサイズが分かるようになりました。成功時のレスポンスに SessionTokenSize(バイト)と SessionTokenUtilization(上限に対する使用率)が含まれ、CloudTrailやCloudWatch(AWS/STSの名前空間の SessionTokenSize・SessionTokenMaxSize)でも確認できます。制限を超えたときのエラーは従来どおり PackedPolicyTooLargeException ですが、メッセージにトークンのサイズと上限がバイト単位で示されるようになりました。
AWSの発表「STSのセッショントークンのサイズ制限を簡素化」出典: Amazon Web Services(引用)
影響を受けるのはどんな環境か
関係するのは、AWSでSTSの一時的な認証情報を使っている組織です。対象となるのは、AssumeRole、AssumeRoleWithSAML、AssumeRoleWithWebIdentity、GetSessionToken、GetFederationToken などのAPIです。とくに、セッションポリシーやセッションタグを多く使っていると、トークンのサイズが大きくなりやすく、上限に近づくことがあります。
また、発行したトークンを、ロードバランサーやプロキシ、キャッシュ、データベースなどで保存・転送している場合は、それぞれの仕組みの桁数の制限にも注意が要ります。AWSは、文字数を決めた列(例として varchar(2048))を挙げ、トークンがそこに収まらなくなる可能性を説明しています。
クラウド管理者が今日やること
- 各システムが扱えるサイズを検証する: 新しいオプション
MinimumSessionTokenSize(例: --minimum-session-token-size 4096)を使うと、トークンを指定サイズまで大きくしてテストできます。ロードバランサーやDBなど、トークンを扱う各所が最大サイズでも処理できるかを確かめます。上限の数値を、システムに直接書き込まない(ハードコードしない)ようにします。
- サイズを監視する:
SessionTokenSize と SessionTokenUtilization を監視します。アラームのしきい値は、一律の4,096バイトではなく、自社で検証した各システムの限界に合わせて設定します。
- トークンを小さく保つ: セッションタグの大文字・小文字をそろえる、タグの値を使い回す、セッションポリシーを簡潔にする、といった工夫で、トークンを小さく抑えられます。
- ツールを最新にする: 必要に応じて、AWS SDK、AWS CLI、Tools for PowerShell を最新版に更新します。古いSDKでは、新しいフィールド(
SessionTokenUtilization)に対応していない場合があります。
一時的な認証情報は、権限を絞って安全に使うための仕組みですが、トークンのサイズという見落としやすい制約があります。今回の整理と監視機能を使い、自社のシステムがどこまで扱えるかを確かめておくと、「ある日突然、認証が通らなくなる」といったトラブルを防ぎやすくなります。
