AWS アカウント ID の 12 桁に隠された構造 - なぜ 12 桁なのか、何が読み取れるのか
AWS アカウント ID が 12 桁の数字である理由、ARN の構造に埋め込まれた設計意図、アカウント ID から推測できる情報とセキュリティ上の注意点を雑学的に解説します。
なぜ 12 桁の数字なのか
AWS アカウント ID は 12 桁の数字 (例: 123456789012) です。この桁数は、AWS が将来にわたって十分な数のアカウントを発行できるよう設計されたものです。12 桁の数字は 10^12 = 1 兆通りの組み合わせを持ちます。2024 年時点で AWS のアクティブアカウント数は公表されていませんが、数千万〜数億と推定されています。1 兆通りの空間があれば、現在のペースでアカウントが増加しても数百年は枯渇しません。アカウント ID が数字のみで構成されている理由は、互換性と可読性です。数字のみであれば、あらゆるシステムやプログラミング言語で問題なく処理でき、電話で口頭伝達する際にも誤解が生じにくいです。ただし、先頭がゼロのアカウント ID (例: 012345678901) が存在するため、プログラムでアカウント ID を扱う際は文字列型で保持する必要があります。整数型で保持すると先頭のゼロが失われ、11 桁の数字になってしまいます。この落とし穴は、AWS を使い始めた開発者が最初に踏むバグの一つです。
ARN の構造 - AWS リソースの住所体系
AWS のすべてのリソースは ARN (Amazon Resource Name) で一意に識別されます。ARN の形式は arn:partition:service:region:account-id:resource-type/resource-id です。この構造には、AWS のアーキテクチャが反映されています。partition はほとんどの場合 aws ですが、中国リージョンは aws-cn、GovCloud は aws-us-gov と分離されています。これは、中国と GovCloud が他のリージョンとは完全に独立したインフラで運用されていることを示しています。service はサービス名 (s3、ec2、lambda など) で、region はリージョンコード (ap-northeast-1 など) です。グローバルサービス (IAM、Route 53、CloudFront など) の場合、region は空になります。account-id は 12 桁のアカウント ID で、リソースの所有者を特定します。S3 バケットの ARN (arn:aws:s3:::my-bucket) にはアカウント ID が含まれません。これは S3 バケット名がグローバルに一意であるため、アカウント ID なしでもリソースを特定できるからです。この設計は S3 の初期に決定されたもので、後発のサービスではアカウント ID が必ず含まれます。
アカウント ID は秘密情報なのか
AWS アカウント ID は、厳密には秘密情報ではありませんが、不必要に公開すべきでもありません。アカウント ID 自体を知っただけでは、そのアカウントのリソースにアクセスすることはできません。アクセスには IAM 認証情報 (アクセスキーまたはロールの AssumeRole) が必要です。しかし、アカウント ID が知られると、いくつかのリスクが生じます。第 1 に、ソーシャルエンジニアリングの材料になります。AWS サポートへの問い合わせ時にアカウント ID が本人確認の一部として使用されるため、攻撃者がアカウント ID を知っていると、なりすましの成功率が上がります。第 2 に、リソースベースポリシーの設定ミスを突かれるリスクがあります。S3 バケットポリシーで Principal にアカウント ID を指定している場合、攻撃者がそのアカウント ID を知っていれば、自分のアカウントから AssumeRole を試みることができます。第 3 に、AMI やスナップショットの共有設定ミスを突かれるリスクがあります。AMI を特定のアカウント ID に共有する設定にしている場合、そのアカウント ID が漏洩すると、意図しないアカウントに共有してしまう可能性があります。
アカウント ID が意図せず漏洩する経路
アカウント ID は、開発者が意識しないうちに外部に漏洩していることがあります。最も多い経路は、IAM ロールやユーザーの ARN がログやエラーメッセージに含まれるケースです。CloudTrail のログを外部のログ分析サービスに送信する際、ログ内のアカウント ID がそのまま送信されます。GitHub にプッシュされた CloudFormation テンプレートや Terraform コードに、アカウント ID がハードコードされているケースも頻繁に見られます。S3 バケットの URL (https://my-bucket.s3.amazonaws.com) からはアカウント ID は直接わかりませんが、バケットポリシーのエラーメッセージにアカウント ID が含まれることがあります。EC2 のメタデータサービス (http://169.254.169.254/latest/meta-data/identity-credentials/ec2/info) からもアカウント ID を取得できるため、SSRF (Server-Side Request Forgery) 脆弱性がある場合にアカウント ID が漏洩します。IMDSv2 (Instance Metadata Service Version 2) を強制することで、SSRF 経由のメタデータ取得を防止できます。
マルチアカウント戦略とアカウント ID の管理
現代の AWS 運用では、1 つの組織が数十〜数百のアカウントを持つマルチアカウント戦略が標準です。AWS Organizations を使用すると、組織のルートアカウントの下に OU (Organizational Unit) を作成し、アカウントを階層的に管理できます。各アカウントには固有の 12 桁の ID が割り当てられ、アカウント間のリソース共有は RAM (Resource Access Manager) やリソースベースポリシーで制御します。マルチアカウント戦略では、アカウント ID の管理が運用上の課題になります。数百のアカウントがあると、どのアカウント ID がどの環境 (本番、ステージング、開発) に対応するのかを把握するのが困難です。AWS Organizations のタグ機能でアカウントにメタデータを付与し、アカウント ID とアカウント名の対応表を維持することが推奨されます。Control Tower を使用すれば、アカウントの作成時に自動的にタグが付与され、ガードレール (SCP) が適用される標準化されたワークフローが利用できます。AWS のアカウント管理とセキュリティ設計を体系的に学ぶには、専門書籍 (Amazon)が参考になります。