Azure コンフィデンシャル仮想マシンに関するよくあるご質問

機密 VM は、セキュリティと機密性の要件が特に高いテナント向けの IaaS ソリューションです。 機密 VM は次のものを提供します。

• プロセッサの状態や仮想マシンのメモリなど、"使用中のデータ" の暗号化。 プロセッサによってキーが生成されます。放置しないでください。
• ホスト構成証明は、データ処理を開始する前に、サーバーの完全な正常性とコンプライアンスを確認するのに役立ちます。
• ハードウェア セキュリティ モジュール (HSM) を接続して、テナントが排他的に所有する機密 VM ディスクのキーを保護できます。
• セキュリティの設定と機能を強化するためのゲスト OS をサポートする新しい UEFI ブート アーキテクチャ。
• 専用の仮想トラステッド プラットフォーム モジュール (TPM) は、VM の正常性を認定し、強化されたキー管理を提供し、BitLocker などのユース ケースをサポートします。

コンフィデンシャル VM を使用すると、オフプレミスの機密性の高いワークロードをクラウドに移行することに関するお客様の懸念が解消されます。 機密 VM により、基盤となるインフラストラクチャおよびクラウド オペレーターからの顧客データに対して強化された保護が提供されます。 他のアプローチやソリューションとは異なり、プラットフォームの技術的なニーズに合わせて既存のワークロードを調整する必要はありません。

SEV-SNP は、Secure Encrypted Virtualization-Secure Nested Paging の略です。 AMD によって提供される高信頼実行環境 (TEE) テクノロジーであり、複数の保護を提供します。たとえば、メモリの暗号化、一意の CPU キー、プロセッサ レジスタの状態の暗号化、整合性保護、ファームウェアのロールバック防止、サイド チャネルの強化、割り込みと例外の動作の制限などがあります。 総じて、AMD SEV テクノロジにより、ハイパーバイザーやその他のホスト管理コードによる VM のメモリおよび状態へのアクセスを拒否できるように、ゲストの保護が強化されます。 機密 VM では、AMD SEV-SNP を Azure テクノロジ (ディスク全体の暗号化や Azure Key Vault マネージド HSM など) と共に利用します。 自分で制御するキーを使用して、使用中と転送中のデータ、および保存データを暗号化できます。 組み込みの Azure Attestation 機能を使用すると、お使いの機密 VM のセキュリティ、正常性、基になるインフラストラクチャへの信頼を個別に確立できます。

Intel TDX は Intel Trust Domain Extensions (Intel TDX) の略です。Intel によって提供される高信頼実行環境 (TEE) テクノロジであり、複数の保護を提供します。Intel TDX では、メモリの管理と暗号化にハードウェア拡張機能を使用し、CPU 状態の機密性と整合性の両方を保護します。 さらに、Intel TDX ではハイパーバイザー、他のホスト管理コード、管理者による VM のメモリと状態へのアクセスを拒否することで、仮想化環境をより強化します。 コンフィデンシャル VM では、Intel TDX と Azure テクノロジ (ディスク全体の暗号化や Azure Key Vault マネージド HSM など) が組み合わされます。 自分で制御するキーを使用して、使用中と転送中のデータ、および保存データを暗号化できます。

Azure VM では既に、他のテナントや悪意のある侵入者に対して業界をリードするセキュリティと保護を提供しています。 Azure 機密 VM では、AMD SEV-SNP や Intel TDX などのハードウェア ベースの TEEを利用して、データの機密性と整合性を暗号化によって分離して保護することによってこれらの保護を強化します。 ホスト管理者やホスト サービス (Azure ハイパーバイザーを含む) は、機密 VM のメモリまたは CPU の状態を直接表示または変更できません。 さらに、完全な構成証明機能、完全な OS ディスク暗号化、ハードウェアで保護された仮想のトラステッド プラットフォーム モジュールにより、秘密キーやメモリの内容が、暗号化されていないホスティング環境に公開されないように、永続的な状態が保護されます。

現在、コンフィデンシャル VM の OS ディスクは暗号化してセキュリティで保護できます。 セキュリティをさらに強化するには、すべてのデータ ドライブに対してゲスト レベルの暗号化 (BitLocker や dm-crypt など) を有効にできます。

はい。ただし、pagefile.sys が暗号化された OS ディスクに存在する場合のみになります。 一時ディスクを備えたコンフィデンシャル VM では、pagefile.sys ファイルを暗号化された OS に移動できます (pagefile.sys を c:\ ドライブに移動するためのヒント)。

いいえ。この機能は、機密 VM には存在しません。

コンフィデンシャル VM をデプロイするには、次の方法があります。

• Azure portal からデプロイする
• Azure コマンド ライン インターフェイス (Azure CLI) からデプロイする
• ARM テンプレートを使用したデプロイ

AMD SEV-SNP 上の Azure コンフィデンシャル VM は、起動フェーズの一環として構成証明を受けます。 このプロセスはユーザーからは見えず、Microsoft Azure Attestation および Azure Key Vault サービスと共にクラウド オペレーティング システムで実行されます。 また、コンフィデンシャル VM を使用すると、ユーザーはコンフィデンシャル VM に対して独立した構成証明を実行できます。 この構成証明は、Azure コンフィデンシャル VM ゲスト構成証明と呼ばれる新しいツールを使用して行われます。 ゲスト構成証明を使用すると、SEV-SNP が有効になっている AMD プロセッサでコンフィデンシャル VM が実行されていることを証明できます。

Intel TDX を使用する Azure 機密 VM は、プラットフォームが準拠していて最新であることを確保するために、ブート フローの一部として透過的に構成証明できます。 このプロセスはユーザーからは見えず、Microsoft Azure Attestation および Azure Key Vault を使用して実行されます。 ブート後にさらにチェックを実行したい場合は、ゲスト内プラットフォーム構成証明が利用できます。 これにより、VM が正規の Intel TDX 上で動作していることを確認できます。 この機能を使用するには、プレビュー ブランチにアクセスします。 さらに、オペレーターに依存しない構成証明を求める企業向けに、Intel® Trust Authority に対応しています。 AMD SEV-SNP と同様に、完全なゲスト内構成証明のサポートが近日提供されます。 これにより、組織はさらに調査し、ゲスト アプリケーション レイヤーまでもさらに詳しい側面を検証できます。

コンフィデンシャル VM で実行するには、OS イメージがセキュリティと互換性について特定の要件を満たす必要があります。 コンフィデンシャル VM は、基になるクラウド インフラストラクチャに対して安全にマウントされ、構成証明され、かつそのインフラストラクチャから分離されている必要があります。 今後、カスタム Linux ビルドを実行する方法についてのガイダンスを提供し、一連のオープンソース パッチを適用して、機密性の高い VM イメージとして認定することを計画しています。

はい。 Azure Compute Gallery を使用すると、アプリケーションのインストールなどにより、コンフィデンシャル VM イメージを変更できます。 この後、変更したイメージに基づいて、コンフィデンシャル VM をデプロイできます。

オプションのディスク全体の暗号化スキームは、Azure の最も安全性が高い方法であり、Confidential Computing の原則を満たしています。 ただし、ディスク全体の暗号化と共に、またはその代わりに、他の ディスク暗号化スキームを使用することもできます。 複数のディスク暗号化スキームを使用する場合、二重の暗号化によってパフォーマンスが低下する可能性があります。

各 Azure コンフィデンシャル VM には独自の仮想 TPM があり、そこにシークレット/キーを封印できます。 vTPM の状態を確認することをお勧めします (Windows VM の場合は TPM.msc を使用)。 使用準備完了状態でない場合は、シークレット/キーを vTPM に封印する前に VM を再起動することをお勧めします。

不正解です。 コンフィデンシャル VM を作成した後、ディスク全体の暗号化を非アクティブ化または再アクティブ化することはできません。 代わりに、新しいコンフィデンシャル VM を作成します。

クラウド サービス プロバイダーからの TCB サービスに "職務の分離" を追加で求める開発者は、セキュリティの種類として "NonPersistedTPM" を使用する必要があります。

• このエクスペリエンスは、Intel TDX パブリック プレビューの一部としてのみ使用できます。 それを使用する組織、またはそれを使用してサービスを提供する組織が、TCB とそれに伴う責任を管理します。
• このエクスペリエンスにより、ネイティブ Azure サービスがバイパスされるため、独自のディスク暗号化、キー管理、構成証明ソリューションを利用できます。
• 各 VM には引き続き、ハードウェア証拠を取得するために使用する必要がある vTPM がありますが、再起動すると vTPM の状態は保持されません。つまり、このソリューションは、一時的なワークロードや、クラウド サービス プロバイダーから分離することを求めている組織に最適です。

いいえ。 セキュリティ上の理由から、コンフィデンシャル VM は最初から作成する必要があります。

はい。あるコンフィデンシャル VM から別のコンフィデンシャル VM への変換は、共有するリージョンの DCasv5/ECasv5 と DCesv5/ECesv5 の両方で許可されます。 Windows イメージを使用している場合は、最新の更新プログラムがすべて適用されていることを確認してください。 Ubuntu Linux イメージを使用している場合は、最小カーネル バージョン 6.2.0-1011-azure で Ubuntu 22.04 LTS コンフィデンシャル イメージを使用していることを確認してください。

コンフィデンシャル VM で利用可能なリージョンを選択していることを確認してください。 また、サイズ セレクターでは必ず [すべてのフィルターをクリア] を選択してください。

いいえ。 コンフィデンシャル VM では、Accelerated Networking はサポートされていません。 コンフィデンシャル VM のデプロイ、または Confidential Computing で実行される Azure Kubernetes Service クラスターのデプロイに対して Accelerated Networking を有効にすることはできません。

Operation could not be completed as it results in exceeding approved standard DCasv5/ECasv5 Family Cores Quota (承認されている標準 DcsV5 または ECasv5 ファミリのコア クォータを超えるため、操作を完了できませんでした) というエラーが表示される場合があります。 この Azure Resource Manager テンプレート (ARM テンプレート) のエラーは、Azure コンピューティング コアが不足しているためにデプロイが失敗したことを意味します。 Azure 無料試用版サブスクリプションには、コンフィデンシャル VM に使用できる十分なコア クォータがありません。 クォータを増やすためのサポート要求を作成します。

ECasv5 シリーズと ECesv5 シリーズは、メモリ最適化された VM サイズであり、高いメモリ対 CPU 比を実現します。 このシリーズは特に、リレーショナル データベース サーバー、中規模から大規模のキャッシュ、インメモリ分析に適しています。

いいえ。 現時点では、これらの VM は一部のリージョンでのみ利用できます。 現在利用可能なリージョンの一覧については、「リージョン別の利用可能な製品」を参照してください。

Azure には、お客様がアクセスを許可した場合でも、コンフィデンシャル VM へのアクセスを従業員に許可するための運用手順はありません。 そのため、コンフィデンシャル VM では、さまざまな復旧およびサポート シナリオを利用することはできません。

いいえ。現在、コンフィデンシャル VM では、VM 内でハイパーバイザーを実行する機能など、入れ子になった仮想化はサポートされていません。

コンフィデンシャル VM の請求は、使用量とストレージ、および VM のサイズとリージョンによって異なります。 コンフィデンシャル VM では、数メガバイトの小さな暗号化された仮想マシン ゲスト状態 (VMGS) ディスクを使用します。 VMGS には、vTPM や UEFI ブートローダーなどのコンポーネントの VM セキュリティ状態がカプセル化されます。 このディスクは、月単位のストレージ料金が発生する可能性があります。 また、オプションのディスク全体の暗号化を有効にすることを選択すると、暗号化された OS ディスクのコストが高くなります。 ストレージ料金の詳細については、マネージド ディスクの料金ガイドを参照してください。 最後に、一部の高度なセキュリティとプライバシーの設定では、マネージド HSM プールなどのリンクされたリソースを作成することを選択できます。 Azure では、そのようなリソースは、コンフィデンシャル VM のコストとは別途請求されます。

まれに DCesv5/ECesv5 シリーズの一部の VM で、UTC とわずかな時間のずれが発生することがあります。 この問題の修正プログラムは近日中に提供されます。 それまでの間は、次の Windows VM と Ubuntu Linux VM 用のワークアラウンドで対応してください。

sc config vmictimesync start=disabled
sc stop vmictimesync

Ubuntu Linux イメージについては、次のスクリプトを実行してください。

#!/bin/bash

# Backup the original chrony.conf file
cp /etc/chrony/chrony.conf /etc/chrony/chrony.conf.bak

# check chronyd.service status
status=$(systemctl is-active chronyd.service)

# check chronyd.service status is "active" or not
if [ "$status" == "active" ]; then
  echo "chronyd.service is active."
else
  echo "chronyd.service is not active. Exiting script."
  exit 1
fi

# Comment out the line with 'refclock PHC /dev/ptp_hyperv'
sed -i '/refclock PHC \/dev\/ptp_hyperv/ s/^/#/' /etc/chrony/chrony.conf

# Uncomment the lines with 'pool ntp.ubuntu.com' and other pool entries
sed -i '/#pool ntp.ubuntu.com/ s/^#//' /etc/chrony/chrony.conf
sed -i '/#pool 0.ubuntu.pool.ntp.org/ s/^#//' /etc/chrony/chrony.conf
sed -i '/#pool 1.ubuntu.pool.ntp.org/ s/^#//' /etc/chrony/chrony.conf
sed -i '/#pool 2.ubuntu.pool.ntp.org/ s/^#//' /etc/chrony/chrony.conf

echo "Changes applied to /etc/chrony/chrony.conf. Backup created at /etc/chrony/chrony.conf.bak."

echo "Restart chronyd service"
systemctl restart chronyd.service


echo "Check chronyd status"
systemctl status chronyd.service