【AWS re:Inforce 2025】AWS はいかにして最も安全なクラウドとしてデザインされるのか (SEC201)

マネージドサービス部佐竹です。
AWS re:Inforce 2025 に現地参加してきましたので、そのログを順番に記述しています。

はじめに
SEC201 Security foundations: How AWS designs the cloud to be the most secure for your business 解説
関連記事等
- セッションの動画
まとめ

はじめに

reinforce.awsevents.com

2025年6月16日から18日にかけて、ペンシルベニア州フィラデルフィアで AWS のセキュリティに特化したカンファレンス「AWS re:Inforce 2025」が開催されました。

参加したセッションのレポートを「1日のまとめ」に書いていこうとしたらあまりにも文章量が増えすぎてしまったので小分けにしています。

本ブログは「【AWS re:Inforce 2025】現地参加レポート 2日目 6月17日(火) 佐竹版」より SEC201 Security foundations: How AWS designs the cloud to be the most secure for your business の解説です。

私の感想やコメントは解説の邪魔になると感じたので「脚注」として記載しています。

また画像ですが、今回一番前の席に座ったために、画像が非常に使いにくい写真になってしまっており、都合 YouTube 動画からの画面キャプチャで代用してます。

SEC201 Security foundations: How AWS designs the cloud to be the most secure for your business 解説

翻訳すると「セキュリティ基盤: AWS はどのようにして最も安全なクラウドとなるよう設計されているのか」となります。

なお本セッションは re:Inforce 2日目の 12:00 から行われましたイノベーショントークの1つです。このセッションは1時間枠のため少々セッション自体が長いので、全てを網羅せず私が重要と感じたポイントに絞って記載します。

概要

最高のセキュリティは、組織がより迅速に行動し、自信を持ってイノベーションを推進することを可能にするものです。

クラウドにおけるセキュリティはまさに「差別化されていない重労働 (undifferentiated heavy lifting)」となっています。AWS はセキュリティを非常に重要視しており、セキュリティへの多大な投資を行っていることが本セッションで語られました。

このセッションから AWS がセキュリティに投資し続ける熱意と、その自信が垣間見えます。

導入：信頼を問う2つの質問

セッションは、クラウドプロバイダーの「信頼性」という、根本的な問いから始まりました。

How do we know? (AWS は、自らの安全性をどう知るのか？)
How do you know? (お客様は、AWS の安全性をどう知るのか？)

これは、本セッション全体に渡る問いかけです。

1つ目の質問は「AWS が内部においていかに徹底的にセキュリティを実践しているか？」、2つ目の質問は「その主張が真実であることを、お客様はどのようにして外部から客観的に検証できるか？（これを「約束」と称しています）」を問うものです。

AWS が「内部での実践」と「外部への透明性」の両輪で信頼を構築しようとしている姿勢がここから見て取れます。

客観性とバイアス

プレゼンターは「私は AWS の人間なので、この話にはバイアスがかかっています。だからこそ、皆さんは証拠を要求すべきです」と述べていました。これは先の2つ目の質問にも通ずるコメントとなっています*1。

セキュリティを重視する文化

まず語られたのは AWS のセキュリティに関する「文化」でした。その象徴として紹介されたのが、2009年の「Pizza Attack」についてです。

これは社内で低リスクと分析された脆弱性に対し、EC サイトの最繁忙期である感謝祭の週にもかかわらず、CEO が直接関与して全社を挙げて修正対応を行ったというエピソードが、AWS にとってセキュリティがいかなるビジネス上の都合よりも優先される「コアバリュー」であることの証明として語られました。

また、この文化が単なる精神論で終わらない仕組みも紹介されました。

統合され、かつ独立したセキュリティ (Security is integrated and independent)
リーダーによる当事者意識 (Leaders look around)
セキュリティはオプションではない (Security isn't optional)

特に3つ目は「新しいサービスや機能を、設定されたセキュリティ基準を満たさない限り、決して出荷しない」というポリシーも合わせて述べられました*2。

技術による「約束」の証明

セッションの中盤から終盤にかけて、前述の文化と原則が、いかにして具体的なテクノロジーに落とし込まれているかが、数々の実例と共に説明されました。今回、私が特に注目した点をいくつかご紹介します。

耐量子コンピュータ暗号 (Post-Quantum Cryptography) ※Quantum Ready

セッションでは、将来の脅威である量子コンピュータへの対策が、暗号化のロジックの話を含めて具体的に語られていました。

さて、そもそも「なぜ耐量子暗号が必要なのか？」です。必要性の理解が重要です。

まず、現在の一般的なネットワーク暗号化プロトコル（TLS/SSLなど）の構造が説明されました。通信は大きく以下の2つのフェーズに分かれています。

ハンドシェイクフェーズ: 通信相手を認証し、データを暗号化するための「共通鍵」を生成・交換する段階。ECDH や RSA といったアルゴリズムが使われます。
データ暗号化フェーズ: ハンドシェイクで交換した共通鍵を使い、AES256-GCM などのアルゴリズムで実際のデータを暗号化する段階。

課題は前段となるハンドシェイクフェーズ側にあります。

データ暗号化フェーズで使われる AES256-GCM などのアルゴリズムは、現時点では量子コンピュータに対しても安全と考えられています。ただし、その前段のハンドシェイクフェーズの鍵交換アルゴリズム（ECDH, RSA）は、将来の高性能な量子コンピュータによって破られる危険性があります*3。

これがスライド内では「!Quantum-Safe」と「Quantum-Safe」とで表されていました*4。

これが脅威となるのは「今日、暗号化された通信を全て保存しておき、将来、量子コンピュータでハンドシェイク部分を解読して鍵を割り出し、過去の通信内容を全て復号する」という攻撃です*5。

この長期的なリスクに対処するため、AWS は多層的な PQC (Post-Quantum Cryptography) 対策を講じています。

AWS の PQC 対策①：VPC Encryption

EC2 インスタンス間の通信を保護する VPC 暗号化では、脆弱な鍵交換アルゴリズムを利用していません。

本スライドの通り、ハンドシェイク部分をPSK (Pre-Shared Key)、つまり事前に共有された鍵を用いる方式に置き換え済です。

これにより、プロトコル全体が量子コンピュータに対して安全（Quantum-Safe）になります。この PSK は、AWS 内のコントロールプレーンによって常に配布＆ローテーションされている点についても言及されました。

AWS の PQC 対策②：物理リンク暗号化 (lever) とバッチ処理

データセンター間を結ぶ物理的なネットワークリンクでは、より優れたアプローチが取られています。ここでは、従来の鍵交換アルゴリズム（ECDH）と PSK を組み合わせたハイブリッドアプローチ（ECDH-PSK）を採用しているとのことです。

これに加え、「バッチ処理 (Batching)」という入れ子のような防御メカニズムが実装されています。

最初のハンドシェイクで1つ目の共通鍵を確立し、データの暗号化を開始します。
しばらくして2回目のハンドシェイクを行う際、その通信自体を1つ目の共通鍵で暗号化します。
3回目のハンドシェイクは、2つ目の共通鍵で暗号化...というように、鍵交換のプロセスが連鎖していきます。

この結果、もし攻撃者が特定の時点の通信を解読しようとするなら、そのリンクが開設された最初からの全ての通信記録を保存し、鍵を全て遡って順に解読していく必要があります。データセンター間の膨大なトラフィック量を考えると、これは事実上不可能となります。

AWS の PQC 対策③：TLS/SSL へのネイティブ実装

加えて AWS は、私たちが日常的に利用する TLS/SSL レイヤーにも PQC を導入済と述べていました。

本スライドの通り、従来の鍵交換アルゴリズムを、耐量子性を備えた新しいアルゴリズムである ML-KEM とのハイブリッド方式に置き換えています。これにより、AWS KMS や Secrets Manager などのサービスでは、すでにネイティブに PQC による保護が提供されています*6。

なお、これら全ての PQC に関する取り組みは、暗号ライブラリAWS-LCとしてオープンソースで開発されています。誰もがコードをレビューでき、第三者による検証も受けることで、その安全性が担保されています*7。

徹底されたアクセス管理①：ゼロオペレーターアクセス

セッションでは、「人間とデータは混ざるべきではない」という思想に基づく「ゼロオペレーターアクセス」が紹介されました。その代表例としてAWS KMSとNitro Systemについて述べられました。ここでは簡単に KMS について説明します。

KMS では、HSM（ハードウェアセキュリティモジュール）という物理的な専用ハードウェアによって、AWS のオペレーターですら暗号鍵にアクセスできない仕組みが実現されています。この堅牢性は、スライドの通り複数 AZ にまたがる可用性の高いアーキテクチャによって支えられています。

徹底されたアクセス管理②：オペレーターの監視と統制

「ゼロオペレーターアクセス」は理想ですが、やむを得ず人間がシステムを操作する場合の対策も講じられています。その目的は、リスクの高い「フルアクセス権を持つシェルでのログイン」を、より安全な仕組みに置き換えることです。ここでも多層的な防御が紹介されました。

この「Contingent authorization（条件付き認可）」と題されたスライドの流れは以下の通りです。

ステップ1：認可

まずオペレーターは、サーバーに直接ログインする代わりに、「認可システム」に対して「何を（例：『プロセス再起動』という定型操作=Verb）」、「なぜ（例：障害チケット番号XXXのため）」実行したいのかを申請します。
認可システムはそのリクエストを検証し、正当であれば、その特定の操作を実行するためだけの一時的な鍵を発行します。

ステップ2：実行

オペレーターは、ステップ1で得た一時的な鍵を使い、サーバーに対して許可された操作（Verb）のみを実行します。
これにより、オペレーターは強力な権限を持つ汎用的なシェル（コマンド入力画面）にアクセスすることなく、目的の作業だけを安全に行えます。これが「Constrained operations（制約付き操作）」です。
では、まだ Verb 化されていない未知の操作や、緊急対応が必要な場合はどうするのでしょうか。その場合、オペレーターは「任意のコマンド実行」という、リスクが高い特別な権限を申請できます。これには、通常よりもはるかに厳格な承認プロセス（例：複数人やマネージャーの承認）が必須となります。

ステップ3と4：監視と記録

オペレーターが操作を実行している間、サーバー側ではeBPFなどのカーネル機能を用いた「Operator monitoring（オペレーター監視）」が常に稼働しています。
特に重要なのは、ステップ2の「任意のコマンド実行」のような未知の操作・定型外の操作が行われた際の活動です。eBPF は、その際に実行された全てのコマンドやプロセスの詳細な挙動まで、完全に記録し、Log storage に保存します。

ステップ5：分析と改善

保管されたログ、特に「任意のコマンド実行」の際に行われた手動操作のログを「Analytics system（分析システム）」で分析することで、「次に自動化すべき操作は何か？」が明らかになります。
その分析結果を基に新たな「Verb」を開発し、危険な「任意のコマンド実行」の必要性を一つずつなくしていきます。これが、アクセスが減るほど安全性が向上する「好循環（virtuous cycle）」を生み出す理由です。

徹底されたアクセス管理③：IAMと"証明可能な"正しさ

セッションの終盤では、AWS セキュリティの要である IAM (Identity and Access Management) に焦点が移りました。ここでのテーマは、IAM のポリシーがいかにして「正しい」と証明されるか、です。

Cedar

AWS は、IAM の基盤となるポリシー言語そのものを、長年にわたり進化させてきました。

このスライドは、その進化の歴史をAspen、Balsa、そして最新のCedarという実在する三種の樹木で表現しています*8。

最新のポリシー言語である Cedar は、アプリケーションの権限ポリシーを記述するためのオープンソース言語です*9。利点として、ポリシーをアプリケーションのコードから分離できるため、互いに影響を与えることなく、それぞれを安全に更新できます。

この Cedar の強力な特徴の一つが、アクセスを明確に禁止する forbid（禁止）ポリシーです。もし、あるリクエストが permit と forbid の両方に該当した場合、常に forbid（禁止）が優先されます*10。

この「禁止が常に優先される」というような、言語の基本的な安全性が、設計当初から「形式検証（Formal Verification）」によって数学的に証明されています*11。

これにより、開発者は意図しない許可が生まれる曖昧さを原理的に排除し権限管理を実装できるようになります。

IAM Access Analyzer

そして、この高度な検証技術は、私たち顧客が使える具体的なサービスとして提供されています。それがIAM Access Analyzerです。

IAM Access Analyzer は、自動推論を用いて、IAM ポリシーを大規模に分析し、意図しない外部アクセスや未使用のロールなどを検出してくれます。本スライドが示すように、私たちは「アナライザーを作成」し、「検出結果を確認」し、「アクションを取る」という簡単なステップで検証機能の恩恵を受けることができます。

まとめ

本セッションを通じて明らかになったのは、AWS のセキュリティが想像以上に厳格であり、かつ組織的にも文化的にも非常に洗練されているということです。「油断がない」とも言えるでしょう。

また、前半にご紹介したこのスライドは AWS のスタンスを的確に表していると感じます。

スピーカーが最後に話したまとめは以下の通りです。

「我々 AWS が提供しているのは、あくまでインフラという土台や配管。その上に素晴らしい家や城を建て、世界を変えるような体験を届けるのは、最終的にはお客様自身です」と。

加えて、AWS 土台で実践しているセキュリティの考え方やパターンを、お客様が構築するアプリケーションにも適用してほしい、と呼びかけられました。これはつまり、「多層防御とその運用の徹底」ではないかと私は感じました。

また私は特にこのセッションレポートにおいて、耐量子コンピュータ暗号 (Post-Quantum Cryptography/Quantum Ready) の重要性を鑑み、特に焦点を当てて解説しました。少々難解な内容になってしまったとは思いますが、本内容が AWS セキュリティの技術的なバックグラウンドに対して少しでも理解の助けになれば幸いです。

では、またお会いしましょう。

*1:つまり、徹底的に外部から検証され、また批評されることをむしろ期待しているということでしょう

*2:なお過去品質保証 ※QA をやっていた経験から補足すると、いくらセキュリティ基準やポリシーがあろうと、その基準自体に穴があるとあまり意味がありません。そういう点で、AWS はこのセキュリティの標準化と徹底のどちらもがうまくワークしていると思わされます

*3:ハンドシェイクで使われる ECDH や RSA といった公開鍵暗号は、「ある種の数学的問題を解くのが（現在のコンピュータでは）事実上不可能に近いほど難しい」という性質に安全性の根拠を置いているためで、これが量子コンピュータの登場によって解決されてしまう可能性があります。具体的には、ピーター・ショアが1994年に開発した「ショアのアルゴリズム」を使うと可能と言われています

*4:！は論理演算子の NOT です

*5:今は中身が見れないけれど、将来的に中身が見れるようになる可能性が高いので、隠し持っておこうとなるわけです

*6:FIPS 203, Module-Lattice-based Key-Encapsulation Mechanism Standard(ML-KEM) については、ブログ「AWS ポスト量子暗号への移行計画」にも記載があります https://aws.amazon.com/jp/blogs/news/aws-post-quantum-cryptography-migration-plan/。なお、これは前述の「ショアのアルゴリズム」では効率的に解読できない数学問題に基づいているため、耐量子性を持つとされています

*7:https://github.com/aws/aws-lc

*8:この名称は、A,B,C... で始まる樹種の名称を順につけたようです

*9:https://aws.amazon.com/jp/blogs/opensource/lean-into-verified-software-development/

*10:この動作は我々にも馴染み深い、「明示的な拒否」の話になりますね https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.html

*11:形式検証とは、システムの正しさを数学的に証明する技術です。一般的なテストが『特定の入力パターンで問題ないか』を試すのに対し、形式検証は、数式や論理を用いて『あらゆる場合で絶対に問題ないか』を証明します。これにより、テスト漏れによるバグを原理的に防ぎ、極めて高い品質を保証します。