[レポート] Securing AWS: Building a library authorizing a billion requests/second #IAM432 #AWSreInforce

あしざわです。

米国東海岸で開催されているAWS re:Inforce 2025 に現地参加しています。

今回の記事では re:Inforce 2025 のChalk talkセッションの1つ、「Securing AWS: Building a library authorizing a billion requests/second」についてレポートします。

セッション概要

• セッションID：IAM432
• セッションタイプ：Chalk talk
• レベル：400 - Expert
• スピーカー情報
  • Khaled Sinno - Principal Engineer, Amazon
  • Sam Huang - Software Engineer, Amazon Web Services
• 概要
  • AWSサービスへのリクエストの認証・認可がどのように行われているか、毎秒10億件を超えるリクエストに対してアクセス制御をスケールさせる方法についての舞台裏を紹介

3行まとめ（キーポイント）

• IAMアーキテクチャの歴史：Sigv1から現在のアーキテクチャまでの進化
• Authorization Runtime Service（ARS）の登場による認証認可処理の集約化
• 条件キーの進化によるOrganizationsやデータペリメーター制御への対応

セッションの内容

このセッションは、IAMの成り立ちから現在のアーキテクチャまでを時系列で説明する形で進行されました。

IAM認証の歴史とマイルストーン

2006年〜2008年：初期のIAM設計

2006年のAWS初期においては、EC2、SQS、S3という最初の3つのサービスが登場したタイミングで、認証（Authentication）と認可（Authorization）の仕組みが必要となりました。当時のCPUパワーはまだ限られており、RSA暗号化は1秒間に300-500回程度の処理が限界だったため、ハッシュ関数を活用した軽量な認証方式としてHMAC-SHA1を採用したSignature v1が開発されました。

興味深いのは、この初期の設計段階で既にコントロールプレーンとデータプレーンの分離というアーキテクチャが確立されていたことです。コントロールプレーンでは、ユーザーやポリシー、認証情報の作成・管理を行い、データプレーンでは実際のAPIコール時の認証・認可処理を担当するという分離設計が採用されました。

2008年にはSignature v2が登場し、HMAC-SHA256への対応とセキュリティ強化が図られました。

2011年〜2015年：STSと一時認証情報

長期認証情報（Long-term credentials）のセキュリティリスクが課題となり、2011年にSTS（Security Token Service）が導入されました。STSによってロール（Role）の概念が導入され、最大12時間の一時認証情報を発行することで、セキュリティを大幅に向上させることができました。この変更により、従来の長期認証情報による過度な権限付与や、セキュリティインシデント発生時のローテーション困難といった問題が解決されました。

2013年〜現在：Signature v4とリージョン分離

2013年には現在も使われているSignature v4が登場しました。これは複数の鍵を階層的に利用する多層暗号化方式で、日付、リージョン、サービス名を組み合わせた階層的なHMACを実現しています。この仕組みにより、各リージョンや各サービスに固有の認証キーを配布することが可能となり、セキュリティの向上とキャッシュ効果による性能向上を両立できるようになりました。

さらに、2015年にはSTSのリージョナルエンドポイントが導入され、可用性が大幅に向上しました。また、Opt-inリージョンの概念により、地理的な分離とセキュリティの向上も実現されています。

Authorization Runtime Client（ARC）の役割

セッションの後半では、AWSサービス全体で共通利用されているAuthorization Runtime Client（ARC）について詳しく説明されました。

2011年頃、AWSサービスが10を超える規模になった際に、各サービスで個別に実装していた認証認可処理に重複が多いことが課題となりました。そこで、これらの処理を統一する共通ライブラリとしてARCが開発され、現在はすべてのAWSサービスで利用されています。

ARCでは、PARC Question（Principal, Action, Resource, Condition）という単位で認可判定を実行します。例えば、KMSのre-encrypt操作の場合、「Principal（呼び出し元）が、Action（KMS:ReEncryptFrom、KMS:ReEncryptTo）を、Resource（ソースキー、ターゲットキー）に対して、Condition（暗号化アルゴリズム等の条件）下で実行可能か」という2つのPARC Questionが評価されることになります。

スケーラビリティの仕組み

毎秒10億件というスケールを実現するための技術的要素として、キャッシュ機能が重要な役割を果たしています。認証結果や条件キーの値をキャッシュすることで高速化を実現していますが、認可の判定結果自体はキャッシュせず、毎回評価を行うことでセキュリティを確保しています。

また、ステートレス設計により必要に応じてホストを追加でき、効率的なポリシー評価により細かな制御を実現しています。条件キーの活用により、従来は細かく列挙する必要があったポリシーをより効率的に記述できるようになり、これもスケーラビリティの向上に寄与しています。

セッション内容の紹介はここまでです。

新しい学び・発見

このセッションを通じて、特に印象的だったのはIAMの初期設計の重要性です。

2006年の時点で、コントロールプレーンとデータプレーンを分離する設計思想が確立されており、これが現在の大規模なスケーラビリティの基盤となっていることが分かりました。技術的な進歩に伴い様々な機能が追加されてきたものの、基本的なアーキテクチャは変わらず、正しい初期設計がいかに重要かを痛感しました。

また、Authorization Runtime Client（ARC）による処理の統一化も興味深い点でした。各サービスで個別に実装していた認証認可処理を共通ライブラリとして集約したことで、開発効率の向上とスケーラビリティの実現を両立させている点は、マイクロサービス設計における重要な示唆だと感じました。

最後に

ここまでre:Inforce 2025のセッション「Securing AWS: Building a library authorizing a billion requests/second」についてレポートしました。

毎秒10億件という圧倒的なスケールを支える技術の裏側を知ることができ、AWSの設計思想の深さを改めて実感しました。

この記事が誰かの役に立てば幸いです。

以上です。