MENU

Azure VMのTrusted Launch既定有効化を解説｜Secure Boot・vTPMとIaCの対応方法

Azure

Azure Virtual Machinesでは、対応する新規Gen2 VMと仮想マシンスケールセット（VMSS）で、Trusted Launchが既定で有効になります。これにより、Secure Bootと仮想TPM（vTPM）も自動的に有効化されます。

Azure Portal、Azure CLI、Azure PowerShellから作成する場合は、サブスクリプション側の追加登録なしで既定動作が適用されます。一方、ARMテンプレート、Bicep、Terraform、Azure SDKなどからデプロイする場合は、サブスクリプションごとに一度だけ機能登録が必要です。既存のVMやVMSSは自動変更されず、デプロイコードで明示したセキュリティ設定も上書きされません。

ただし、Trusted Launchに対応していないイメージやVMサイズを選んだ場合、デプロイが失敗するとは限りません。Trusted Launchを有効にせず、通常のGen2 VMとして作成が成功する場合があります。そのため、既定有効化されたからといって、すべてのVMが自動的に同じセキュリティ状態になるとは限りません。作成後の確認までを運用手順に含める必要があります。(Microsoft Learn)

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

Trusted Launchの既定有効化で何が変わったのか

Trusted Launch as Default（TLaD）は、2026年7月に一般提供となりました。対応する新規Gen2 VMとVMSSに対し、追加料金なしでSecure BootとvTPMを既定適用する仕組みです。

主な変更点を整理すると、次のようになります。

作成・管理方法Trusted Launch既定化後の動作
Azure Portal対応する新規Gen2 VMでTrusted Launchを既定適用
Azure CLI対応する新規Gen2 VMでTrusted Launchを既定適用
Azure PowerShell対応する新規Gen2 VMでTrusted Launchを既定適用
ARMテンプレート／Bicepサブスクリプション登録と対応APIバージョンの利用により既定適用
Terraformサブスクリプション登録と対応するプロバイダー／APIの利用により既定適用
Azure SDKサブスクリプション登録と対応するCompute APIの利用により既定適用
既存のVM／VMSS自動変更されない
securityTypeを明示したデプロイ明示した設定が優先される
非対応イメージ／非対応サイズTrusted Launchなしで作成される場合がある

これまでARMテンプレートなどでは、securityProfileを記述しなければTrusted Launchは有効になりませんでした。新しい動作では、条件を満たすデプロイに対してSecure BootとvTPMが既定適用されます。(Microsoft Learn)

Secure BootとvTPMが自動有効になる理由

Trusted Launchは、OSが起動する前後の低いレイヤーを保護するためのAzure VM向けセキュリティ機能です。ブートキット、ルートキット、カーネルレベルのマルウェアなど、一般的なウイルス対策ソフトだけでは検出や防御が難しい攻撃への耐性を高めます。(Microsoft Learn)

Secure Bootが未署名コンポーネントの起動を防ぐ

Secure Bootは、ブートローダー、OSカーネル、カーネルドライバーなどの署名を起動時に検証します。

信頼できる発行元によって署名されていないコンポーネントや、改ざんされたコンポーネントが検出された場合、それらの読み込みを拒否します。これにより、OSより先に動作するブートキットやルートキットの侵入を防ぎやすくなります。(Microsoft Learn)

一方、独自にビルドしたLinuxカーネル、未署名ドライバー、古いブートローダーなどを利用している場合は、Secure BootによってVMが起動できなくなる可能性があります。

vTPMがキーと起動状態を保護する

vTPMは、物理TPM 2.0を仮想化した仕組みです。暗号鍵、証明書、起動時の測定値などを、各VM専用の保護された領域に保存します。

UEFI、ブートローダー、OS、ドライバーを含むブートチェーンの状態を測定できるため、VMが信頼できる状態で起動したかをリモート構成証明で確認できます。(Microsoft Learn)

ただし、Secure BootとvTPMが有効になっただけで、Defender for Cloudの構成証明監視がすべて自動的に完成するわけではありません。リモート構成証明や整合性アラートを利用する場合は、ゲスト構成証明拡張機能やDefender for Cloud側の設定も確認してください。(Microsoft Learn)

Trusted Launchが既定適用される条件

新しいVMまたはVMSSがGen2であっても、無条件にTrusted Launchになるわけではありません。公式ドキュメントでは、APIバージョン2025-11-01以降を使用し、次の条件を満たす場合に既定適用されると説明されています。

  • Azure MarketplaceのOSイメージがTrusted Launchに対応している
  • Azure Compute GalleryのOSイメージがTrusted Launch対応として検証されている
  • デプロイ元のディスクがTrusted Launchに対応している
  • 選択したVMサイズがTrusted Launchに対応している

いずれかの条件を満たさない場合、Trusted Launchを有効にせず、通常のGen2 VMまたはVMSSとしてデプロイが完了することがあります。(Microsoft Learn)

Trusted Launchは、対応するx64とArm64のGen2 VMで利用できます。また、Azureパブリックリージョン、Azure Government、Azure Chinaの対応環境で提供されています。利用によるVM料金の追加はありません。

Marketplaceイメージの対応状況を確認する

Azure CLIでは、Marketplaceイメージの世代とセキュリティ対応状況を確認できます。

az vm image show \
  --urn "MicrosoftWindowsServer:WindowsServer:2022-datacenter-azure-edition:latest" \
  --query "{generation:hyperVGeneration,security:features[?name=='SecurityType'].value}"

確認するポイントは次の2つです。

  • hyperVGenerationがV2
  • SecurityTypeの値にTrustedLaunchまたはTrustedLaunchSupportedが含まれる

単に「Gen2」と表示されているだけでは、Trusted Launch対応まで保証できません。特にカスタムイメージや古いMarketplaceイメージを使う場合は、事前確認が必要です。(Microsoft Learn)

VMサイズの対応状況を確認する

VMサイズの対応状況は、次のように確認できます。

az vm list-skus \
  --resource-type virtualMachines \
  --location japaneast \
  --query "[?name=='Standard_D2s_v5'].capabilities" \
  --output table

出力に次の情報がある場合、そのVMサイズはTrusted Launchに対応していません。

TrustedLaunchDisabled    True

Gen2対応サイズであり、TrustedLaunchDisabledが出力されなければ、Trusted Launchを利用できると判断できます。リージョンによって利用可能なSKUが異なるため、実際にデプロイするリージョンを指定して確認してください。(Microsoft Learn)

作成方法によって必要な対応が異なる

Trusted Launchの既定有効化で最も間違えやすいのが、「どの作成方法でも何もしなくてよい」と考えてしまうことです。

デプロイ方法サブスクリプション登録主な対応
Azure Portal不要作成画面で最終設定を確認する
Azure CLI不要最新版へ更新し、作成後に設定を確認する
Azure PowerShell不要最新版へ更新し、作成後に設定を確認する
ARMテンプレート必要機能登録とAPIバージョン更新
Bicep必要機能登録とリソースAPIバージョン更新
Terraform必要機能登録とAzureRM／AzAPIプロバイダーの対応確認
Azure SDK必要機能登録と利用中のCompute APIバージョン確認

Azure Portal、CLI、PowerShellでは、機能登録の有無にかかわらずTrusted Launchが既定になります。ARM、Bicep、Terraform、SDKなどにも同じ既定動作を拡張するには、VMを作成するサブスクリプションで機能登録を行います。(Microsoft Learn)

登録はテナント単位ではなく、サブスクリプション単位です。開発、検証、本番でサブスクリプションを分けている場合は、それぞれに登録してください。

ARM・Bicep・Terraform・SDK向けの機能登録手順

一般提供後も、公式ドキュメントに記載されている登録名は次のとおりです。

TrustedLaunchByDefaultPreview

名前にPreviewが含まれていますが、2026年8月3日更新の公式ドキュメントでも、この機能名を使用するよう案内されています。TrustedLaunchByDefaultなど、推測した別名に変更しないでください。(Microsoft Learn)

機能登録には、Microsoft.Features/*アクションの権限が必要です。Azureの組み込みロールでは、所有者または共同作成者に必要な権限が含まれます。(Microsoft Learn)

Azure CLIで登録する

まず、対象のサブスクリプションを選択します。

az account set --subscription "<subscription-id>"

Trusted Launchの既定化機能を登録します。

az feature register \
  --namespace Microsoft.Compute \
  --name TrustedLaunchByDefaultPreview

登録状態を確認します。

az feature show \
  --namespace Microsoft.Compute \
  --name TrustedLaunchByDefaultPreview \
  --query properties.state \
  --output tsv

次のように表示されることを確認してください。

Registered

最後に、変更をリソースプロバイダーへ反映させます。

az provider register --namespace Microsoft.Compute

機能登録後にaz provider registerを実行するのは、登録内容をリソースプロバイダー側へ伝達するためです。(Microsoft Learn)

Azure PowerShellで登録する

対象サブスクリプションへ切り替えます。

Set-AzContext -SubscriptionId "<subscription-id>"

機能を登録します。

Register-AzProviderFeature `
  -ProviderNamespace "Microsoft.Compute" `
  -FeatureName "TrustedLaunchByDefaultPreview"

登録状態を確認します。

Get-AzProviderFeature `
  -ProviderNamespace "Microsoft.Compute" `
  -FeatureName "TrustedLaunchByDefaultPreview"

RegistrationStateがRegisteredになったら、リソースプロバイダーを再登録します。

Register-AzResourceProvider `
  -ProviderNamespace "Microsoft.Compute"

Azure Portalから登録する場合は、「サブスクリプション」から対象サブスクリプションを開き、「プレビュー機能」で機能名を検索します。機能が一覧に表示されない場合は、Azure CLIまたはAzure PowerShellを使用してください。(Microsoft Learn)

ARMテンプレートとBicepはAPIバージョンも確認する

サブスクリプションへ機能登録しただけでは、古いAPIバージョンを使用するテンプレートに新しい既定動作が反映されない可能性があります。

ARMテンプレートとBicepでは、VMまたはVMSSのリソースAPIを2025-11-01以降へ更新します。(Microsoft Learn)

Bicepでは、次のようにリソースバージョンを指定します。

resource vm 'Microsoft.Compute/virtualMachines@2025-11-01' = {
  name: vmName
  location: location
  properties: {
    // その他のVM設定
  }
}

TerraformやAzure SDKではAPIバージョンを直接記述しない場合があります。その場合は、利用しているAzureRMプロバイダー、AzAPIプロバイダー、SDKパッケージが新しいCompute APIに対応しているかを確認してください。

プロバイダーを更新したら、いきなり本番環境へ適用せず、検証用サブスクリプションで次の点を確認します。

  • 作成されたVMのsecurityType
  • Secure BootとvTPMの状態
  • Terraformの次回planで不要な差分が出ないか
  • カスタムイメージが正常に起動するか
  • 将来利用する予定のVMサイズへ変更できるか

本番のIaCではセキュリティ設定を明示する方法も有効

既定値に任せれば、テンプレートの記述を増やさずにTrusted Launchを利用できます。しかし、長期運用する本番環境では、セキュリティ設定を明示する方が管理しやすい場合があります。

理由は、非対応イメージや非対応サイズを指定した場合、Trusted Launchなしでデプロイが成功する可能性があるためです。暗黙の既定値だけでは、コードレビュー時に期待するセキュリティ状態が分かりにくくなります。

BicepでTrusted Launchを明示する例は次のとおりです。

resource vm 'Microsoft.Compute/virtualMachines@2025-11-01' = {
  name: vmName
  location: location
  properties: {
    securityProfile: {
      securityType: 'TrustedLaunch'
      uefiSettings: {
        secureBootEnabled: true
        vTpmEnabled: true
      }
    }

    // その他のVM設定
  }
}

Trusted Launchの既定化は、デプロイコードで明示された入力を上書きしません。そのため、既にTrustedLaunchまたはStandardを明示しているテンプレートでは、その設定が優先されます。

次のように使い分けると管理しやすくなります。

  • 一時的な検証VM：既定値を利用して記述を簡略化
  • 長期運用する本番VM：Trusted Launchをコードで明示
  • 例外的に非対応機能を使うVM：Standardを明示し、理由をコードコメントや設計書に残す

作成後にSecure BootとvTPMを確認する

デプロイの成功だけでは、Trusted Launchが有効になったことを確認できません。作成後にsecurityProfileを確認します。

単体VMを確認する

az vm show \
  --resource-group "<resource-group>" \
  --name "<vm-name>" \
  --query "{
    securityType:securityProfile.securityType,
    secureBoot:securityProfile.uefiSettings.secureBootEnabled,
    vTPM:securityProfile.uefiSettings.vTpmEnabled
  }" \
  --output table

期待する結果は次のとおりです。

SecurityType    SecureBoot    VTPM
--------------  ------------  ----
TrustedLaunch   True          True

VMSSを確認する

az vmss show \
  --resource-group "<resource-group>" \
  --name "<vmss-name>" \
  --query "{
    securityType:virtualMachineProfile.securityProfile.securityType,
    secureBoot:virtualMachineProfile.securityProfile.uefiSettings.secureBootEnabled,
    vTPM:virtualMachineProfile.securityProfile.uefiSettings.vTpmEnabled
  }" \
  --output table

多数のVMを管理している場合は、Azure Resource GraphやAzure Policyを使い、次の状態を継続的に監査する運用が有効です。

  • securityTypeがTrustedLaunchか
  • Secure Bootが有効か
  • vTPMが有効か
  • StandardになっているVMに承認済みの例外理由があるか

Trusted Launchの既定有効化は、セキュリティ設定の入力を減らす仕組みです。すべてのリソースが必ず準拠することを保証する仕組みではないため、監査と組み合わせることが重要です。

Trusted Launchを明示的に無効化するケース

基本的には、対応するVMではTrusted Launchを有効にしたまま利用することが推奨されます。ただし、次のようなケースではStandardを明示する必要があります。

ケース主な問題対応
未署名カーネルや独自ドライバーを利用Secure Bootで起動を拒否される可能性署名対応を優先し、困難な場合のみStandardを検討
Linux VMの休止状態が必要Trusted Launchとの組み合わせが未対応の場合がある要件を確認してStandardを明示
Managed Imageを作成するTrusted Launchで未対応Azure Compute Galleryへの移行を検討
PackerやAzure Image Builderの元VMとして利用イメージ定義との組み合わせで例外設定が必要イメージ作成用VMのみStandardを明示
非対応のVMサイズへ将来変更する作成後のサイズ変更ができないサイズ設計を先に確定する
古いカスタムOSイメージを利用Secure Boot互換性が不明検証環境で起動テストを実施

公式ドキュメントでは、Managed ImageとLinux VMの休止状態がTrusted Launchの非対応機能として挙げられています。また、イメージ作成用VMなどでは、Trusted Launchの既定値を明示的に回避する必要があります。(Microsoft Learn)

Azure CLIでStandardを指定する

az vm create \
  --resource-group "<resource-group>" \
  --name "<vm-name>" \
  --image Ubuntu2204 \
  --security-type Standard

新規デプロイでStandardを明示するには、Microsoft.Compute APIバージョン2025-11-01以降、Azure CLI 2.86.0以降、またはAzure PowerShell 15.6.1以降が必要です。(Microsoft Learn)

Secure Bootだけを安易に無効化するのは避けてください。未署名のカーネルやドライバーが必要など、具体的な互換性理由がある場合に限定します。

作成後のサイズ変更にも注意する

Trusted Launchとして作成されたVMやVMSSは、Trusted Launchに対応していないVMサイズファミリへ変更できません。公式ドキュメントでは、非対応のMシリーズなどが例として挙げられています。(Microsoft Learn)

例えば、最初は小規模なDシリーズで作成し、将来は大容量メモリを持つ特定のMシリーズへ変更する設計の場合、後からサイズ変更できない可能性があります。

VMサイズを選ぶときは、現在の負荷だけでなく、次の点も確認してください。

  • 1年後に想定するCPUとメモリ
  • スケールアップ先のサイズファミリ
  • GPUやHPCサイズへの変更予定
  • 予約インスタンスの購入予定
  • Trusted Launch対応状況

非対応サイズを利用するには、VMを割り当て解除し、securityTypeをStandardへ変更する対応が必要になる場合があります。この変更にはUseStandardSecurityType機能フラグと、APIバージョン2025-11-01以降を利用するクライアントツールが必要です。Azure Portalからは実行できません。(Microsoft Learn)

既存のVMとVMSSは自動変更されない

Trusted Launchの既定有効化は、既に稼働しているVMやVMSSには影響しません。Secure Bootが突然有効になったり、既存OSが再起動されたりする変更ではありません。

既存VMもTrusted Launchへ変更できますが、新規VMの既定化とは別の作業です。既存環境を移行する場合は、少なくとも次の項目を確認します。

  • Gen2または移行可能なGen1 VMか
  • OSイメージとVMサイズが対応しているか
  • 未署名のカーネルやドライバーがないか
  • Azure Backupのポリシーが対応しているか
  • 復元ポイントやロールバック手段を確保できるか
  • 検証用VMで起動確認を実施したか

新規VMの既定化を確認した後、既存VMを一括変更するのではなく、重要度の低いVMから段階的に移行する方が安全です。

管理者が最初に実施すべきチェックリスト

Trusted Launchの既定有効化に対応する際は、次の順番で進めると抜け漏れを減らせます。

| 順番 | 実施内容 |
| -: | ———————————————– |
| 1 | VMとVMSSの作成経路をPortal、CLI、PowerShell、IaCに分類する |
| 2 | ARM、Bicep、Terraform、SDKを使うサブスクリプションを洗い出す |
| 3 | 各サブスクリプションでTrustedLaunchByDefaultPreviewを登録する |
| 4 | ARM／BicepのAPIバージョンを2025-11-01以降へ更新する |
| 5 | TerraformプロバイダーとAzure SDKを更新し、検証環境でテストする |
| 6 | カスタムイメージ、独自ドライバー、休止状態などの例外を整理する |
| 7 | デプロイ後にsecurityType、Secure Boot、vTPMを確認する |
| 8 | Standardを許可する場合は、例外理由と承認者を記録する |
| 9 | Azure Resource GraphやAzure Policyによる継続監査を検討する |

まず確認すべきなのは、VMをどのツールで作成しているかです。Portal、CLI、PowerShellだけなら基本的に自動適用されます。ARM、Bicep、Terraform、SDKを利用している場合は、サブスクリプション登録とAPI・プロバイダーの更新状況を確認してください。

最後に検証用VMを1台作成し、securityType=TrustedLaunch、Secure BootとvTPMがともにtrueになっていることを確認します。既定値だけに依存せず、作成後の検証と例外管理まで実施することが、Trusted Launch既定化を安全に活用するポイントです。

Azure

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次