[レポート]セッション『10億リクエストのある日』 #reinvent #SEC404

『A day in the life of a billion requests (SEC404)』を見よう
2022.12.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、AWS事業本部@福岡オフィスのべこみん(@beco_minn)です。

もう年末ですね。みなさんはどういう風に年末を過ごしてますか?

先日開催されたAWS re:Invent 2022の各セッションのオンデマンド動画がYouTubeで配信されているのはご存知でしょうか?しかもジャンルごとにプレイリストも作成されています。各プレイリストはYouTubeの公式チャンネルページから確認することが出来ます。

僕はそれらのプレイリストの中でもセキュリティ系ブレイクアウトセッションのプレイリスト↓ から気になった動画を漁りながら年末を過ごしています。

AWS re:Invent 2022 - Security, Compliance, & Identity

この記事では、セキュリティ系ブレイクアウトセッションのプレイリストの中で最も再生回数の多いセッション『A day in the life of a billion requests (SEC404)』のレポートをします。ただ、このセッションはみなさんに見てもらいたいのでセッション内容をあまり細かく記載しません。是非セッションを見てみてください。レポートというよりは所感レベルです。

オンデマンド動画はこちら↓

セッション概要

Every day, sites around the world authenticate their callers. That is, they verify cryptographically that the requests are actually coming from who they claim to come from. In this session, learn about unique AWS requirements for scale and security that have led to some interesting and innovative solutions to this need. How did solutions evolve as AWS scaled multiple orders of magnitude and spread into many AWS Regions around the globe? Hear about some of the recent enhancements that have been launched to support new AWS features, and walk through some of the mechanisms that help ensure that AWS systems operate with minimal privileges.

毎日、世界中のサイトが発信者を認証しています。つまり、そのリクエストが実際に誰からのものであるかを暗号的に検証しているのです。本セッションでは、AWSのスケールとセキュリティに関するユニークな要件が、このニーズに対する興味深く革新的なソリューションにつながっていることを学びます。AWSが何桁もスケールし、世界中の多くのAWSリージョンに広がる中で、ソリューションはどのように進化してきたのでしょうか?AWSの新機能をサポートするために導入された最近の機能拡張について、またAWSのシステムが最小限の権限で動作することを保証するためのメカニズムについて説明します。

登壇者

  • Eric Brandwine : Vice President & Distinguished Engineer at AWS

レポート

タイトルだけを見た時、膨大なリクエストを捌くためのセキュリティの話なのかな?WAFとか関係ある話なのかな?と思っていました。

このセッションはAWSにおける認証の歴史のようなお話です。

暗号の世界ではお馴染みのアリス(とボブ)が主人公として分かりやすい図とともに話が展開するので、英語のセッションでも内容が分かりやすいです。YouTubeなら自動翻訳の日本語字幕を表示することも出来ます。

セッション内容はまず暗号プロトコルの話から始まります。

時は遡って2006年、みなさんご存知のTLSは既に開発されていたものの世間一般的には利用されていなかったそうです。理由は"サーバー側とクライアント側の両方で、暗号化の計算コストが高すぎるから"。

そこでハッシュを使ったHMACが登場します。

「HMACは26年間使われ続けているが、誰も問題点を見つけていない」とエリック氏は言っています。

これだけ最高なHMACですが、やっぱり欠点はありました。。。それは、対称キーを持つこと。

それらを踏まえてAWSが導き出した答えが SigV4(署名バージョン4) という認証プロセスです。AWSを利用したことがある方であれば必ずお世話になっています。

SigV4について詳しく知りたい方は下記公式ドキュメントをご参照ください。

ここから話は短期(一時)鍵に移ります。短期鍵とはいわゆるセッションのことです。

AWSではセッションはIDフェデレーションやRole Assumption、EC2などのサービスに役割を付与するPassRoleで使われています。

しかし、AWSのように膨大な通信が行われるサービスでセッションを管理し続けるのは非常に複雑で困難。。。

ということで出来たのがSecure Token Service(STS)です。みなさんも見たことありますよね。

STSの詳細は下記公式ドキュメントにてご参照ください。

STSの検証(トークンの復号)は実際にはARS(Auth Runtime Service)が行なっているので、AWSはデータベースにアクセスキーIDを保存したりしているわけではないらしい。

テンペスターが10億ものセッションを作成しても、STSは無事に耐え切ったそうです。ここがタイトルに繋がっているんですね。

まとめのスライドにはこんなことが書かれていました。

  • Scale and Customer requirements lead us to an interesting design
  • Scale and growth broke out design
    • Innovation and careful cryptography gave us even greater scale
  • Short-lived keys and SigV4 allow us to support new use cases
  • Scale cost us simplicity, but not elegance

(日本語訳)

  • スケールやユーザーの要望から、興味深い設計が生まれた
  • スケールし、成長することで設計を破壊することが出来た
    • 技術革新と入念な暗号化により、さらに大きなスケールを手に入れた
  • 短期鍵やSigV4によって、私たちは新たなユースケースをサポートすることが出来る
  • スケールはシンプルさを犠牲にしたが、エレガンスさは犠牲にしなかった

まとめ

タイトルからは再生回数が多い理由が分からないセッションでしたが、良い意味で予想を裏切られたセッションでした。

2006年、自分はまだ小学生か中学生です。普段自分が当たり前のように利用している技術がその当時ではどうだったのか、またそこからどのような変遷を経て現在使われている技術になっているのか、ついつい聞き込んでしまいました。

この記事を読んで下さったみなさんも是非視聴してみてはいかがでしょうか。

以上、べこみんでした。