AWSで過ごした20年、「それは自分の仕事ではない」と一度も言わなかった
(daemonology.net)- FreeBSDのセキュリティ責任者でありTarsnap創業者でもあるColin Percivalが、2006年のAWS最初のアカウント作成から現在まで20年にわたり、公式な社員ではない外部貢献者という立場で、FreeBSDのEC2対応構築、セキュリティ脆弱性の先回りした発見・報告、サービス設計へのフィードバックまで、AWSの発展に幅広く関わってきた過程を時系列で回顧した文章
- 初期のAWSではサービスごとに個別の有効化が必要で、最初から有効だったサービスは Amazon SQS と、ほとんど知られていないAmazon E-Commerce Serviceだった
- FreeBSDをEC2で動かすために、Xenのバージョン互換性、PAE対応、HVMへの移行 など、数年にわたる技術的難関を解決する必要があり、2010年にt1.microで初めて稼働に成功
- AWSリクエスト署名方式の 正規化衝突脆弱性、IMDS経由の認証情報露出リスク（2019年のCapital One侵害事故で現実化）、Seekable OCIのセキュリティ問題など、多数のセキュリティ課題を先回りして発見・報告
- 2024年からAmazonの GitHub Sponsors 支援を受けてFreeBSD/EC2の保守を継続しており、外部貢献者として内部システムへのアクセスなしでも、Amazonエンジニアとの協力を通じて成果を上げた事例
AWSアカウント作成と初期サービス
- 2006年4月10日、Amazon S3の発表を見て最初のAWSアカウントを作成。オンラインストレージサービスへの関心がきっかけで、それ以前から1998年より HTTPベースのWebサービス を構築してきた経験を持っていた
- 初期のAWSでは各サービスを個別にアカウントへ有効化してもらう必要があり、標準提供されていたのは Amazon SQS とAmazon E-Commerce Service（Amazon提携向けの商品カタログAPI）だけだった
- Amazon E-Commerce Serviceは事実上最初のAWSサービスだったが、ほとんど知られておらず、AWSの歴史からもひっそり削除された
セキュリティへの初期の関心とフィードバック
- FreeBSD Security Officerとしての経験を背景に、AWSのセキュリティ構造にすぐ関心を持ち、AWSリクエストは APIキーで署名 されて認証と完全性を保証する一方、レスポンスには署名がない点を指摘
- 当時はHTTP経由のAWSリクエストが一般的だったため、レスポンス改ざんの可能性 は現実的なリスクであり、TLS移行後もエンドツーエンド署名はトランスポート層のセキュリティより優れているという立場を維持
FreeBSD on EC2 — 初期の挑戦
- Amazon EC2の公開直後、FreeBSDの稼働を目標にJeff Barrを通じてAmazon内部の担当者とつながり、2007年初めに最初の Amazon NDA を締結
- 当時のAmazonはファクスを使っていたが、ファクスを持っていなかったため署名原本を郵送することになり、最初のブリーフィングが遅れた
- EC2は当初 カスタムカーネル 対応なしで提供されており（現在のAWS Lambdaに近い方式）、2007年11月にRed Hat対応とともにこの機能が有効化されると、FreeBSDアカウントにも内部の「Amazon Kernel Images公開」APIへのアクセスが許可された
Xenのセキュリティ監査とサイドチャネル攻撃への警告
- 2007年3月、Amazon担当者に Xenのセキュリティ監査 の必要性を提起し、適切な監査者が分からない場合はTavis Ormandyを推薦
- 同年、TavisがXenの脆弱性2件（CVE-2007-1320、CVE-2007-1321）を報告したが、この推薦との関係は不明
- Jeff Barrの Second Life 内AWSユーザー会で、読み取り専用ルートディスクと再起動時のメモリ初期化保証機能を要望。信頼できないコードを実行する（FreeBSDパッケージビルド）シナリオ向けであり、EC2 Instance Attestation は18年後に登場
- 2012年のre:Inventでは、HyperThreadingを利用したRSA鍵の窃取 研究をEC2 Principal Engineerに説明し、同じコア上の2スレッドでEC2インスタンスを並行実行しないよう強く勧告
- この勧告が、多くのEC2インスタンスファミリーで「medium」サイズを飛ばし、いきなり2 vCPUの「large」から始まった理由だと伝えられている
Eventual Consistencyと理論的提案
- 2007年末、Amazon内部で広く読まれたブログ投稿で Eventual Consistency の問題を指摘し、Eventually Known Consistency というやや強いモデルを提唱
- CAP定理で「A」（可用性）の経路を維持しつつ内部状態を公開し、正常系では「C」（一貫性）も確保できるモデル
- Amazon S3はその後、可用性最適化から 一貫性最適化 へ転換し、DynamoDBはEventual/Strongly Consistent読み取りの選択肢を提供
Xen互換性問題とFreeBSDの起動失敗
- 2008年初頭、Kip Macyが Xen PAE対応 FreeBSDカーネルを作成し、内部AMIツールをFreeBSDへ移植するのに数週間を要した
- Rubyスクリプトがbashスクリプトを生成・実行する構造について、言語選択を再考すべきだと述べている
- FreeBSD AMIはEC2で起動せず、EC2で使われていた Xen 3.0 に、FreeBSD VMコードの再帰ページテーブルをサポートしないバグがあったのが原因
- Xen 3.1で修正されたが、安定ABI が提供されていなかったため、既存AMIとの互換性維持を優先してAmazonはXen 3.0の継続を選択
AWS署名脆弱性の発見と修正
- 2008年4月、TarsnapベータのためAmazon SimpleDBを利用する中で、署名方式の正規化衝突 を発見
- 当時はAmazonにセキュリティ課題の報告窓口がなく、Jeff Barr経由で伝達した
- Amazonは Signature Version 2 の設計レビューを依頼し、文書の曖昧さ修正、設計判断の是正、アカウント許可リストの追加などを経て、12月に修正が完了
SimpleDB NextTokenのセキュリティ衛生上の問題
- 2008年6月、SimpleDBの NextToken値 が単なるbase64エンコードされたJavaシリアライズオブジェクトであることを発見
- 内部情報漏えい防止のための暗号化と、改ざん防止のための署名が必要だと報告したが、返答はなかった
- 6か月後、別のエンジニア経由で再報告して内部チケット化されたが、その後も公式な返答はなかった
EBSアルファテストと設計フィードバックのタイミング
- 2008年3月、EC2チームのMatt Garmanが Elastic Block Storage（現Elastic Block Store）の非公開アルファへ招待
- 新サービスに最も有用なフィードバックを与えられる時点は 構築前の設計段階 であり、数学・理論のバックグラウンドから、アルファテストより設計文書レビューの方が効果的だという立場
Amazon入社面接のエピソード
- 2008年、Jeff Barrの勧めでAmazon入社を検討し、Al Vermeulenとの電話面接では45分のうち30分を 例外処理（exceptions）の長所と短所 の議論に費やした
- 例外処理は、気軽なコードレビューでは見つけにくいバグを生みやすい 本質的に不適切なエラー処理方式 だという立場を維持
IAMと制限付きアクセスキー — SigV4までの道のり
- 2008年11月、Seattle AWS Start-up TourでAmazonエンジニアと直接会い、制限付きAWSアクセスキー の必要性を議論
- マスターシークレットからサービスごとに鍵をハッシュ導出する 暗号学的導出鍵 方式を主張したが、Amazon側はルールベース設計を好んだ
- 2010年1月、IAM の非公開ベータに招待され、2012年にSigV4が登場した際には導出鍵方式が採用された
EC2ファイアウォール問題とPath MTU Discovery
- 2009年、EC2のデフォルトファイアウォールルールが ICMP Destination Unreachable (Fragmentation Required) メッセージを遮断し、Path MTU Discoveryが動作しない問題を発見・報告
- 2009年12月にEC2マネージャーが解決策へ同意したが、実際の修正は 2012年に公に問題提起 した後に実施された
NetBSD経由の迂回とHVMへの移行
- 2010年初頭、EC2がなお旧版Xenを維持していたため、NetBSD への切り替えを試み、1週間で起動・ファイルシステムのマウント・ネットワーク設定・sshd起動まで成功
- 2010年7月、Cluster Compute インスタンスがHVMをサポートしたことでFreeBSDにも希望が生まれ、PV（準仮想化）が 技術的な行き止まり であることが明確になった
FreeBSD/EC2初稼働 — t1.micro
- 2010年9月に登場した t1.micro インスタンスファミリーは内部的にXen 3.4.2を実行しており、FreeBSDの起動を妨げていたバグが解消
- 2010年11月中旬、FreeBSD/EC2 t1.microインスタンスへのSSH接続に成功し、12月13日に FreeBSD EC2 t1.micro対応を正式発表
インスタンスタイプ拡大と「defenestration」の抜け道
- Amazon Solutions Architectが、より大きなインスタンスを求めるFreeBSDユーザーをつないでくれたことで、Cluster Computeインスタンス 対応を実装
- EC2が実際にどのOSが動いているかを把握していない点を利用し、defenestration（Windowsインスタンス偽装）によってすべての64ビットインスタンスタイプでFreeBSDを利用可能にした
- 「Windows税」を支払う必要があり、Amazon側も不満だったが、顧客需要を満たすのに不可欠で、2014年7月に T2インスタンス がHVM「Linux」対応を完備したことでこの抜け道は不要になった
S3ルーターハードウェア障害の診断
- 2012年4月、特定のS3エンドポイントで SignatureDoesNotMatch エラーなど多数のリクエスト失敗が発生
- エラーレスポンスのStringToSign値が送信値と一致しないパターンから stuck bit（固定ビット）を特定し、tracerouteと数百万件のpingで経路上の特定ルーターの ハードウェア障害 を突き止めた
- AWS Developer Forumsに報告後、Amazonは数日以内に障害を確認してハードウェアを交換
re:Invent 2012とサイドチャネル攻撃への警告
- 初回のre:Inventは技術コンテンツが少なくスーツ姿も多かったが、多くのAmazonエンジニアと対面で交流する機会を提供した
- Intelの「仮想マシンセキュリティ」発表者であるVPが サイドチャネル攻撃 を知らないと答えた後、EC2ブースでPrincipal Engineerに関連研究を直接説明
FreeBSD/EC2の公式化とリリースエンジニアリング
- 2015年4月、FreeBSD/EC2の AMIビルドプロセスをFreeBSD srcツリーへ統合 し、イメージビルドをFreeBSD Release Engineeringチームへ移管して、個人プロジェクトから 公式FreeBSD プロジェクトへ移行
- 2020年9月、FreeBSD Release Engineering LeadのGlen Barberからの要請で Deputy Release Engineer の役割を引き受けた
- 2022年末にGlenが肺炎で入院し、長期後遺症で復帰が難しくなったため、2023年11月17日に FreeBSD Release Engineering Lead を正式に引き継いだ
- 毎週のスナップショットビルド、スケジュール強化、予測可能で速いリリースサイクルの確立により、年4回のリリースを管理
IMDSのセキュリティ警告とCapital One侵害事故
- 2016年10月、IAM Roles for Amazon EC2 を分析し、認証されていないHTTPで動作し、「機密データを保存しないこと」と文書で警告される IMDS経由の認証情報露出 が危険だとブログに投稿
- 2019年7月、Capital Oneがまさにこのリスクを悪用されて 1億600万件の顧客情報が流出。同年11月にAmazonと通話した2週間後、IMDSv2 がリリースされた
- IMDSv2は特定の攻撃経路の緩和策ではあるが、認証情報が不適切なインターフェース経由で露出するという根本問題の解決ではないという立場
AWS Heroesプログラム
- 2019年5月、Amazon社員ではない立場でAWSへ重要な貢献をした人物を認定する AWS Heroes プログラムに招待
- プログラムは主に開発者教育（ブログ、YouTube、ワークショップ）への貢献者が中心で、その中では異例の選出であり、Distinguished EngineerとSenior Principal Engineerの推薦で承認された
UEFIブートとBootMode=uefi-preferred
- 2021年3月、EC2がx86インスタンスの UEFIブート 対応を追加し、FreeBSDではUEFI移行により16ビットモードI/Oが不要になって 起動時間が7秒短縮 された
- すべてのインスタンスタイプがUEFIをサポートしているわけではないため、レガシーBIOSとUEFIの両方で起動可能なイメージ向けに BootMode=polyglot 設定を要望
- 2023年3月、BootMode=uefi-preferred という名前で実装された
Seekable OCIのセキュリティ問題発見と修正遅延
- 2023年8月のHeroes Summitで Seekable OCI の設計を見て、特定のユースケースではセキュリティ上の主張が成り立たない問題を発見し、AWS Securityチームへ報告
- 内部修正の約束を受けたものの実際には進展がなく、2024年のre:Inventで再確認を求め、2025年1月に再報告した結果、2023年のコミットは 偶発的なデータ破損のみを防ぎ、意図的な攻撃は防げていないことが判明
- 指摘後は迅速に対応が進み、2025年2月末までに当該機能は大半の顧客向けに 無効化 され、「major revision」を待つ状態となった
Amazonの支援と協力モデル
- 2024年4月、FreeBSD/EC2保守に十分な時間を割けていないことをAmazon側へ伝え、資金支援を要請。数週間以内に GitHub Sponsors経由で週10時間・1年間の支援 が決定
- 多数の未解決課題を処理した後、6か月の休止期間（大半は無償でFreeBSD 15.0のリリースエンジニアリングに専念）を経て、2回目の12か月支援 が開始
- 20年にわたる貢献は一人だけの成果ではないと強調し、内部AWSシステムへのアクセス権がなくても、Amazonエンジニアがチケット作成、内部連絡先の探索、APIログ調査、技術文書の確保など、「遠隔の手」 として機能した
1件のコメント
Hacker Newsのコメント
筆者は「Heroes は実質的に無給の Amazon 社員だ」という冗談を言っていたが、それは冗談ではなく現実だ
私は自分の個人的な研究を公開しない。すでに十分効率的な価値抽出マシンに無料の R&D を提供したくないからだ
Amazon はオープンソースの経済的前提を壊し、その結果として多くのプロジェクトがBusiness Source Licenseへ移行している
こうした開発者たちは Amazon がどれほど強欲かを知っている。結局、コミュニティの貢献は超巨大企業への無給労働に帰着し、Amazon はマネージドサービスでユーザーを取り込み、元プロジェクトの支援とコミュニティを弱体化させる
「Amazon を除く誰でも自由に使える」と書けば、Amazon は法的リスクのため使わない
ただし必要だと判断すれば、Amazon は独自版を新たに作る可能性がある
Redis の事例のように、API 表面に対する法的保護は明確ではない
以前、Google v. Oracleの判例がそうした保護を確立しようとして見送られたと記憶している
実際、BSL を選ぶ企業は、本当のオープンソース精神というより、イメージ管理や開発者からの好感度確保のためだけに公開していた可能性が高い
それでも全面的に同意する。これから私が公開するコードは、完全なオープンソースか完全非公開のどちらかだ
誰かがそれで金を稼ぐ可能性があるなら公開しない
大企業に時間を与えたくないという見方は理解できるが、私は別の観点を示したい
2006 年に私が作ったプロジェクト名を、2012 年に別の開発者が使いたいと言ってきたので快く譲った
そのプロジェクトこそが scrypt で、開発者は Colin だった
こうしたコミュニティへの親切は、商業的な期待がなくても積み上がる良いカルマになる
「Jeff Barr の AWS ユーザーミートアップが Second Life で開かれた」という話は実に興味深い
Second Life は AWS の初期ユーザーであり、Jeff Bezos が 2005 年の投資ラウンドに直接参加していた
そのおかげで Jeff Barr が Second Life 内で AWS ミートアップを開き、当時はReuters や Jonathan Coultonのようなグループも仮想空間に進出していた時期だった
私たちはEvolution Roboticsのブースを出し、ER1 ロボットを実演していたが、Second Life は本当に印象的だった
良い思い出として残っている
もちろん、ノート PC の画面の中の Second Life と VR ヘッドセットはまったく別の体験だった
「Amazon のための無料労働」というフレームは核心を外している
Colin は慈善活動をしていたのではなく、Tarsnap が FreeBSD/EC2 に依存しているため、それを改善していたのだ
こうしたモデルこそオープンソースの最も健全な形だ — 自分の製品の土台を直し、その結果が皆の利益になる構造だ
Amazon が直接関心を持つまで待つのは、永遠に待つのと同じだ
Amazon が GitHub Sponsors を通じて週 10 時間、1 年間支援していたという話を見て驚いた
時給 300 ドルとは、Google L6 エンジニアの給与水準だ
今はもっと受け取っていてほしい
ドイツ語圏のヨーロッパでは 120 ユーロで優秀なエンジニアを確保できる。東欧はさらに安い
IAM Roles for EC2 に対する筆者の批判には同意しない
IAM は認証情報をポリシーベースで管理できるようにする中核機能だ
Outlook、Slack、Teams よりはるかに安全で、数学的にチームメンバーが署名鍵を見ることができないと証明することすらできる
Azure も似た概念を適用して MSSQL へのアクセスをきれいに処理している
昔は XenStore を通じてカーネルに認証情報を渡そうと提案したことがある。Nitro ベースなら今ならもっと簡単に実装できるはずだ
カーネルが認証情報を受け取り、所有権と権限を設定できる仮想ファイルシステムとして公開すればよい
CAP_NET_BIND_SERVICE 権限を持つプロセスだけがアクセスできる点が面白い
vsock(7) ソケットを使えば、ごまかしにくい接続方式になってさらに安全だ
さらに DMI データにブートストラップ認証情報を入れれば、root だけが読める sysfs ディレクトリに配置される
2007 年のメールを確認すると、初期には AWS サービスへのアクセスを個別に申請する必要があったのは事実だった
最初は「Amazon E-Commerce Service」だけ承認され、その後 S3、EC2 ベータの順でアクセス権を得た
当時の「Alexa Web Information Service」は音声アシスタントではなく、Web 検索 APIだった。あの時代は実に興味深い
本当に興味深い技術史的記録だ
Tavis Ormandy のような有名エンジニアでもインタビューで間違えることがある、という点が印象的だ
こういう体験談ブログ記事は本当に好きだ
20 年回顧にHetzner や OVHへの言及がないのは意味深だ
私は AWS、Hetzner、小規模クラウドを併用しているが、価格差は非常に大きい
AWS は月 350 ドル、Hetzner は 20〜25 ユーロで似たスペックに 20TB のトラフィック込みだ
AWS が売っているのは今やコンピュートではなく IAM モデル、グローバルインフラ、組織内の合意だ
「AWS を選べば誰もクビにならない」という認識こそが本当の製品だ
最近 AWS からワークロードを移した人たちに聞きたい — 予想以上につらかった部分は何だったのか