AWS Nitro Enclaves

解決する課題

クレジットカード番号や個人情報、暗号鍵といった機密データは、たとえ自社のサーバー上であっても「処理中のメモリを誰かに覗かれないか」が常に懸念になります。OS の管理者権限を持つ運用者、侵入した攻撃者、同居する別プロセスなど、リスクの源は多岐にわたります。AWS Nitro Enclaves は、EC2 インスタンスの一部を切り出して親インスタンスからすら隔離された実行環境を作り、こうした課題に応えます。

• 管理者からの隔離: 親インスタンスに SSH できる運用者でも、エンクレーブ内のメモリや CPU 状態にはアクセスできない
• 攻撃面の最小化: 外部ネットワーク・永続ストレージ・対話的アクセスをすべて持たないため、侵入経路が極端に少ない
• 証明付きの鍵管理: 「正しいコードが動く正しい環境」であることを暗号的に証明し、その環境にだけ機密を渡せる

金融取引の処理、PII のトークン化、暗号鍵やパスワードの取り扱い、複数当事者間で生データを見せずに計算するマルチパーティ計算などが代表的な用途です。

主要概念と用語

• エンクレーブ: 親 EC2 インスタンスから切り出された隔離環境。独立した CPU とメモリを持つが、外部 IO を持たない
• 親インスタンス: エンクレーブを起動する元の EC2 インスタンス。リソースを供出し、唯一の通信相手となる
• vsock: 親インスタンスとエンクレーブを結ぶローカルなセキュア通信チャネル。ネットワーク経由ではなく仮想ソケットで通信する
• エンクレーブイメージファイル（EIF）: エンクレーブで動かすアプリをパッケージしたイメージ。コンテナイメージから変換して作る
• アテステーション: エンクレーブが正規で改ざんされていないことを暗号的に証明する仕組み
• アテステーションドキュメント: Nitro 基盤が署名する証明書。環境の計測値を含む
• PCR（プラットフォーム構成レジスタ）: エンクレーブイメージや署名などのハッシュ計測値。同一性の判定に使う
• Nitro System: EC2 の基盤となる専用ハードウェア・ハイパーバイザー。エンクレーブの隔離はこの基盤が担保する

仕様・制限・クォータ

• エンクレーブは Nitro System ベースの EC2 インスタンスでのみ作成でき、起動時に有効化する。ベアメタルや一部の世代では非対応の場合がある
• エンクレーブに割り当てる vCPU とメモリは親インスタンスから確保され、親側はその分だけ使用可能リソースが減る
• エンクレーブは 外部ネットワークインターフェイス・永続ストレージ・対話的シェルを持たない。通信は vsock 経由の親インスタンスとのみ
• 1つの親インスタンスで動かせるエンクレーブ数や割り当て可能リソースには上限があり、インスタンスサイズに依存する
• エンクレーブ内で動かすアプリは EIF にパッケージしてから起動する
• 利用そのものに 追加料金はかからない（後述）。ただし切り出したリソース分の親インスタンス費用は通常どおり発生する

内部の仕組み

Nitro Enclaves の隔離は、EC2 を支える Nitro System によって実現されます。エンクレーブを起動すると、親インスタンスから指定した vCPU とメモリが切り離され、専用の隔離された仮想マシンとして再構成されます。この境界はハードウェアとハイパーバイザーのレベルで強制されるため、親 OS の管理者であっても内部を観測できません。

• エンクレーブには 永続ストレージも外部ネットワークも与えられないため、データを外に持ち出す経路自体が存在しない
• 親とエンクレーブは vsock のみでつながり、アプリはこのチャネル上に独自プロトコルを実装してデータを受け渡す
• 起動時に Nitro 基盤が アテステーションドキュメントに署名する。ここにはエンクレーブイメージや署名鍵の計測値（PCR）が含まれる

このアテステーションを AWS KMS が検証できる点が要です。KMS のキーポリシーに「特定の PCR 値を持つエンクレーブからの要求にだけ復号を許可する」という条件を書けば、想定どおりのコードが動く正規環境にのみ平文の鍵を渡せます。改ざんされたイメージは PCR が変わるため、条件を満たせず鍵を取得できません。

設計パターン / ベストプラクティス

• 機密処理だけをエンクレーブに置く: 鍵の利用・復号・署名・トークン化など、本当に守りたい最小限のロジックに絞る
• KMS のアテステーション条件を活用: キーポリシーに PCR 条件を付け、正規エンクレーブ以外には鍵を渡さない
• 親はプロキシに徹する: 外部通信は親側のプロキシが担い、エンクレーブは vsock の先で計算だけを行う構成にする
• EIF の再現性を確保: イメージのビルドを再現可能にし、期待する PCR 値を CI などで検証・固定する
• 平文の機密を親に渡さない: 復号結果や鍵がエンクレーブの外（親のメモリやログ）に出ない経路設計を徹底する

運用・監視

• エンクレーブの起動・終了や CPU・メモリの割り当て状況は、Nitro CLI やインスタンス上のツールで確認する
• エンクレーブ内には対話的にアクセスできないため、開発・デバッグ時は デバッグモードで起動してコンソール出力を確認する。本番ではデバッグモードを使わない
• 親インスタンスのリソースは事前にエンクレーブ分を予約しておく必要があり、確保失敗を監視・検知できるようにする
• アプリのログは vsock 経由で親側へ送る設計にし、機密が混ざらないようにフィルタする
• PCR 値の変化はイメージ変更を意味するため、デプロイ時に期待値との一致を必ず確認する

コスト

• Nitro Enclaves の機能自体には 追加料金がかからない。利用にあたって支払うのは、エンクレーブのために切り出した分も含めた親 EC2 インスタンスの通常料金です
• エンクレーブに vCPU とメモリを多く割り当てるほど親側で使える分が減るため、必要に応じて親インスタンスのサイズを上げる費用が間接的に発生し得る
• KMS など連携サービスの利用料は別途かかる

セキュリティ

• 運用者からの隔離が中核。親に SSH できる人でもエンクレーブ内のメモリ・CPU 状態を読めない
• 外部ネットワーク・永続ストレージ・対話的アクセスを持たないため、攻撃面が極小になる
• アテステーションにより、改ざんされていない正規のコードが動いていることを暗号的に証明できる
• KMS との連携で、正しい PCR を持つエンクレーブにのみ復号・署名を許可でき、鍵の使用を環境に縛れる
• 機密は可能な限りエンクレーブ内に留め、平文を親側のメモリやログに残さない設計にする

関連サービス・比較

鍵管理では AWS KMS と密接に連携します。一方、隔離されたコンピュート環境という観点では、専用ハードウェアで鍵そのものを保護する AWS CloudHSM とよく対比されます。

ハンズオン / CLI例

# コンテナイメージからエンクレーブイメージ（EIF）をビルドする
nitro-cli build-enclave \
  --docker-uri my-enclave-app:latest \
  --output-file my-enclave.eif

# エンクレーブを起動（vCPU とメモリを割り当てる）
# 本番ではデバッグモードを付けない
nitro-cli run-enclave \
  --eif-path my-enclave.eif \
  --cpu-count 2 \
  --memory 1024 \
  --enclave-cid 16

# 稼働中のエンクレーブと割り当て状況を確認
nitro-cli describe-enclaves