JAWS-UG Okayama 2025 - AWS Nitro Systemと そのセキュリティ.pdf

JAWS-UG Okayama 2025にて、AWS Nitro Systemと そのセキュリティをお話しさせていただきました。

1. AWSoNitrooSystemと
そのセキュリティ
2025/08/30oJAWS-UGoOkayamao2025
えかてりーな
[ 私はEC2が好きだ]

3. 人間はミスをする生き物
「自分で設定・管理する環境」なんて少ない方がいい
サーバレス一択
[ セキュリティレベルを上げるには ]

4. https://www.publickey1.jp/blog/20/macawsmac_minithunderboltaws_reinvent_2020.html
[ セキュリティレベルを上げるには(?) ]

5. https://www.publickey1.jp/blog/20/macawsmac_minithunderboltaws_reinvent_2020.html
[ セキュリティレベルを上げるには(?) ]
好きなものはしょうがない

6. 01
EC2仮想化基盤の進化の歴史

7. [歴EC2仮想化基盤の進化の歴史歴]
ここからNitro歴System

8. 02
従来：Xenとは (VMWareと比較)

9. 【Fat（厚い）ハイパーバイザー 】 【Thin（薄い）ハイパーバイザー】
I/O処理、ドライバ、管理機能
をHypervisorが内蔵
「全部入り」なので一体型で
高速だけれど、コード量が多
い
※コード量の多さは攻撃の隙
を与えやすく、脆弱
Hypervisorは仮想化だけを担
当する仕様
I/Oや管理は外部の特権OS
（Dom0）に任せている
これによりHypervisorは小さ
く安全性が高いが、Dom0依
存が弱点v(結局Dom0を落とせ
ば勝ちだよね！)

10. 03
KVMとは

11. [ KVM ]
2017/11 C5インスタンスで初めて登場
KVM = Linuxカーネルに組み込まれた仮想化機能
ハイパーバイザー（仮想化ソフト）ではあるが、
スタンドアロンのソフトウェアではなく、Linux
カーネルそのものに組み込まれているモジュール
Intel VTや AMD-V といったCPUの仮想化支援機
能を使うことが前提

　 この発表時にNitroの話が出ている
https://aws.amazon.com/jp/blogs/news/now-available-compute-intensive-c5-instances-for-amazon-ec2/
https://aws.amazon.com/jp/blogs/aws/sap-on-aws-past-present-and-future/?utm_source=chatgpt.com
https://www.brendangregg.com/blog/2017-11-29/aws-ec2-virtualization-2017.html
https://www.youtube.com/watch?v=LabltEXk0VQ
VM

12. 04
Nitroとは

13. KVMベースのインスタンスだが、Nitro
systemが完成してからNitroibase
Instanceという表現がAWSから多数出るよ
うになった。
ハイパーバイザーはiKVMベースの超軽量な
「NitroiHypervisor」iに置き換わる
管理機能・I/O・セキュリティなどはすべて
NitroiCard（専用ハードウェア）i側へ分離
結果的に「KVM＝Linux＋QEMU」が持ってい
た役割は完全に解体されている
[iNitroi]

14. KVMベースのインスタンスだが、Nitro
systemが完成してからNitrobbase
Instanceという表現がAWSから多数出るよ
うになった。
ハイパーバイザーは KVMベースの超軽量な
「Nitro Hypervisor」 に置き換わる
管理機能・I/O・セキュリティなどはすべて
Nitro Card（専用ハードウェア） 側へ分離
結果的に「KVM＝Linux＋QEMU」が持ってい
た役割は完全に解体されている
[bNitrob]つまり、2018年から
ハイパーバイザーだけの話では
なくなった

15. 2017年のC5登場を皮切りに、ハイパーバ
イザーの刷新だけでなく、管理機能やI/Oを
ハードウェア分離を取り組み始めます。
2018年にはs"NitrosCard"sシリーズが出揃
い、
sEC2の仮想化基盤は完全に「ソフトウェア
＋ハードウェア」からなる
NitrosSystemsへと進化しました。
これにより、AWSは独自の仮想化・管理・
セキュリティ基盤を、物理レベルから実装
できるようになったのです。
[s改めて、NitrosSystemとはs]

16. [ 改めて、Nitro Systemとは ]

17. 05
Xen Hypervisor と
Nitro System 比較表

18. [ Xen Hypervisor と Nitro System 比較表 ]

19. [ Xen Hypervisor と Nitro System 比較表 ]

20. [ まとめ ]
1.「Dom0の排除」＝攻撃面（Attack Surface）の大幅縮
2.I/Oオフロードでセキュリティ＆パフォーマンスが同時向上
3.Nitro Security Chip により信頼できるハードウェアブート
4.AWSオペレーターですらインスタンスの中に入れない設計

21. 06
「Dom0の排除」＝攻撃面
（Attack撃Surface）の大幅縮

22. [t「Dom0の排除」＝攻撃面（AttacktSurface）の大幅縮t]
LinuxベースのOSで構成され、数百万行規模のコード
バグや脆弱性の混入リスクが高い
多機能で過剰な権限
仮想マシンの起動・停止、ストレージ、ネットワーク、ログ管理など多くの操作を一手
に担っているため、万が一侵害されると全VMやホストの制御権限を奪われる恐れ
OSである以上ログイン可能
root権限での操作やパッチ適用ができるため、人手によるヒューマンエラーや不正操作
の可能性が排除できない

23. [ 「Dom0の排除」＝攻撃面（Attack Surface）の大幅縮 ]
AWSの運用者が入れる設計
アクセス制御はIAMや内部ポリシーに依存するため、原理的に“絶対に入れな
い”を保証できない
VMとの論理的な隔離に限界
ソフトウェアレベルで隔離しているため、仮想マシン間の情報漏洩や干渉リスク
がゼロではない

24. LinuxベースのOSで構成され、数百万行規模のコード
バグや脆弱性の混入リスクが高い
多機能で過剰な権限
仮想マシンの起動・停止、ストレージ、ネットワーク、ログ管理など多くの操作を一手
に担っているため、万が一侵害されると全VMやホストの制御権限を奪われる恐れ
OSである以上ログイン可能
root権限での操作やパッチ適用ができるため、人手によるヒューマンエラーや不正操作
の可能性が排除できない
[ 「Dom0の排除」＝攻撃面（Attack Surface）の大幅縮 ]
軽量な Nitro Hypervisor を採用。
機能を限定した数千行規模のコードベース
で、セキュリティリスクを大幅に削減。

25. [r「Dom0の排除」＝攻撃面（AttackrSurface）の大幅縮r]
LinuxベースのOSで構成され、数百万行規模のコード
バグや脆弱性の混入リスクが高い
多機能で過剰な権限
仮想マシンの起動・停止、ストレージ、ネットワーク、ログ管理など多くの操作を一手
に担っているため、万が一侵害されると全VMやホストの制御権限を奪われる恐れ
OSである以上ログイン可能
root権限での操作やパッチ適用ができるため、人手によるヒューマンエラーや不正操作
の可能性が排除できない
管理機能はr機能別に分離された専用ハードウェア
（NitrorCards）rが実行
特権OSが不要となり、機能の最小化・分離が実現

26. [r「Dom0の排除」＝攻撃面（AttackrSurface）の大幅縮r]
LinuxベースのOSで構成され、数百万行規模のコード
バグや脆弱性の混入リスクが高い
多機能で過剰な権限
仮想マシンの起動・停止、ストレージ、ネットワーク、ログ管理など多くの操作を一手
に担っているため、万が一侵害されると全VMやホストの制御権限を奪われる恐れ
OSである以上ログイン可能
root権限での操作やパッチ適用ができるため、人手によるヒューマンエラーや不正操作
の可能性が排除できない
NitrorCardrはOSを持たず、ログイン手段も存在しない設計
人手による操作が不可能で、
ヒューマンエラーや不正を物理的に排除

27. [t「Dom0の排除」＝攻撃面（AttacktSurface）の大幅縮t]
AWSの運用者が入れる設計
アクセス制御はIAMや内部ポリシーに依存するため、原理的に“絶対に入れな
い”を保証できない
VMとの論理的な隔離に限界
ソフトウェアレベルで隔離しているため、仮想マシン間の情報漏洩や干渉リスク
がゼロではない
管理機能はt機能別に分離された専用ハードウェア
（NitrotCards）tが実行
特権OSが不要となり、機能の最小化・分離が実現

28. [ 「Dom0の排除」＝攻撃面（Attack Surface）の大幅縮 ]
AWSの運用者が入れる設計
アクセス制御はIAMや内部ポリシーに依存するため、原理的に“絶対に入れな
い”を保証できない
VMとの論理的な隔離に限界
ソフトウェアレベルで隔離しているため、仮想マシン間の情報漏洩や干渉リスク
がゼロではない
Nitroは 管理プレーンとデータプレーンを物理的に分離。
仮想マシンは完全に独立した環境として動作。

29. 07
I/Oオフロードでセキュリティ＆
パフォーマンスが同時向上

30. [I/Oオフロードでセキュリティ＆パフォーマンスが同時向上 ]
I/O処理の場所
Dom0（Linuxベースの特権OS）が全I/Oを処理。
OS上で動くため、人による操作やソフトの脆弱性に晒される。
I/O処理はかNitroかCard（専用ハード）に完全分離。
OSなし・ログイン不可・設定変更不可な構造で、外
部からの侵入手段がない。

31. 08
NitroアSecurityアChipアにより
信頼できるハードウェアブート

32. [tNitrotSecuritytChiptにより信頼できるハードウェアブートt]
起動の信頼性
起動時の検証は主にBIOSレベルで完結。
OSやDom0に改ざんがあっても、検出されないまま起動可能な構成が多い。
改ざん検出
起動後にOSレイヤで何らかのセキュリティソフトが検知するしかないため、起
動時点でのrootkit(システムの奥深くに潜み、見つからないように動作する不正
プログラム)や改ざんに脆弱。

33. [ Nitro Security Chip により信頼できるハードウェアブート ]
インサイダー攻撃への耐性
管理者権限を持つ人物が起動時に不正なイメージを差し込んでも、検出が困難
第三者検証性
ハイパーバイザーやOSの健全性を外部から監査する手段が限られる。

34. [ Nitro Security Chip により信頼できるハードウェアブート ]
起動の信頼性
起動時の検証は主にBIOSレベルで完結。
OSやDom0に改ざんがあっても、検出されないまま起動可能な構成が多い。
改ざん検出
起動後にOSレイヤで何らかのセキュリティソフトが検知するしかないため、起
動時点でのrootkit(システムの奥深くに潜み、見つからないように動作する不正
プログラム)や改ざんに脆弱。
専用ハードウェア Nitro Security Chip により、
BIOS→Bootloader→OS→Hypervisor までの
起動プロセス全体を検証。
信頼できる状態でのみブートを許可（Trusted Boot）。

35. [tNitrotSecuritytChiptにより信頼できるハードウェアブートt]
起動の信頼性
起動時の検証は主にBIOSレベルで完結。
OSやDom0に改ざんがあっても、検出されないまま起動可能な構成が多い。
改ざん検出
起動後にOSレイヤで何らかのセキュリティソフトが検知するしかないため、起
動時点でのrootkit(システムの奥深くに潜み、見つからないように動作する不正
プログラム)や改ざんに脆弱。
NitrotChiptがtTPM類似の仕組みを持ち、
改ざんがあれば起動をブロックtort通知。
暗号署名によるハッシュ検証によりt“静的に信頼された状態”
からしか起動できない。

36. [ Nitro Security Chip により信頼できるハードウェアブート ]
インサイダー攻撃への耐性
管理者権限を持つ人物が起動時に不正なイメージを差し込んでも、検出が困難
第三者検証性
ハイパーバイザーやOSの健全性を外部から監査する手段が限られる。
NitroえChipえによるえ信頼チェーン（RootえofえTrust）えがあるた
め、人による差し替え・操作・バックドア起動は
構造的に不可能。

37. [ Nitro Security Chip により信頼できるハードウェアブート ]
インサイダー攻撃への耐性
管理者権限を持つ人物が起動時に不正なイメージを差し込んでも、検出が困難
第三者検証性
ハイパーバイザーやOSの健全性を外部から監査する手段が限られる。
証明可能なおTrustedおBootおにより、お客様や第三者機関による
ブートプロセスの整合性検証が可能。

38. 09
AWSオペレーターですらインスタ
ンスの中に入れない設計

39. 英国を拠点とする大手サイバーセキュリティコンサルティング会社であるNCC
Groupに、Nitroシステムとお客様へのセキュリティ保証に関する独立したアーキ
テクチャレビューを依頼しました。NCCは現在、報告書を発行し、AWSの主張を裏
付けています。
1.AWS従業員がインスタンスホストへログインできない
2.管理用APIには顧客データへのアクセス権がない
3.インスタンスストレージや暗号化されたEBSへのアクセス手段がない
4.暗号化されたネットワーク通信の内容にもアクセスできない
5.APIアクセスは認証・監査付きでログが常に取得される
6.ホストで実行されるソフトウェアは署名付きかつ認証済み、運用者による直接デプロイ不可
である
[ AWSオペレーターですらインスタンスの中に入れない設計 ]
https://aws.amazon.com/jp/blogs/compute/aws-nitro-system-gets-independent-affirmation-of-its-confidential-compute-capabilities/?utm_source=chatgpt.com

40. 10
その後のNitro System

41. [ その後のNitro System ]

42. ご清聴
ありがとうございました!
[ THANK YOU! ]