MENU

Azure Key Vault Premiumでoct-HSM AES-256対称鍵を作成・利用する方法

Azure

Azure Key Vault PremiumでHSM保護されたAES対称鍵を使う場合は、パブリックプレビューとして追加されたoct-HSM鍵を利用できます。AES-256鍵を作成し、暗号化・復号・鍵のラップ・アンラップをAzure Key Vault上で実行できる機能です。

この機能は2026年7月30日付のAzure Update 566746で発表されました。耐量子暗号への移行を見据える場合は、CNSA 2.0の要件に沿った256ビットAES鍵が有力な選択肢になります。ただし、現時点ではパブリックプレビューであり、SLAが適用されないため、まずは非本番環境で検証することが重要です。

この記事では、oct-HSM AES-256鍵の特徴、Azure CLIとBicepによる作成方法、暗号化・復号の確認手順、実システム向けのエンベロープ暗号化まで具体的に解説します。

目次

Azure Key Vault Premiumのoct-HSM対称鍵とは

octは、対称鍵を表す「オクテット列」を意味します。oct-HSMは、その対称鍵をソフトウェアではなくHSMで保護する鍵タイプです。

Azure Key Vault Premiumでは、従来のRSA-HSMやEC-HSMに加えて、次のサイズのoct-HSM鍵を作成できます。

  • 128ビット
  • 192ビット
  • 256ビット

対称鍵の実体はAzure Key Vaultの外へ取り出せません。アプリケーションはKey VaultのAPIを通じて暗号化や鍵ラップを実行するため、鍵を設定ファイルやアプリケーションメモリに長期間保持せずに済みます。バックアップもAzureが保護する形式で出力され、外部で生の鍵として利用することはできません。(Microsoft Learn)

Azure Update 566746の要点

今回のアップデートを実務向けに整理すると、次のようになります。

項目内容
発表日2026年7月30日
提供段階パブリックプレビュー
対象SKUAzure Key Vault Premium
鍵タイプoct-HSM
鍵サイズ128、192、256ビット
主な操作encrypt、decrypt、wrapKey、unwrapKey
主なアルゴリズムAES-GCM、AES-CBC、AES-KW
作成方法Azure CLI、ARMテンプレート、Bicep
ポータル対応順次展開中
本番利用SLAがないため原則として検証用途

Azure Portalでoct-HSMの選択肢が表示されない場合でも、機能が利用できないとは限りません。ポータル対応は段階的に展開されているため、プレビュー期間中はAzure CLIまたはARMテンプレートを使うのが確実です。

Azure Managed HSMとは別の機能

oct-HSMという名前からAzure Managed HSMを連想しやすいものの、両者は別のリソースです。

今回の機能は、既存のAzure Key Vault Premium内にHSM保護された対称鍵を作成するものです。Azure CLIでも、Key Vaultを操作する場合は--vault-name、Managed HSMを操作する場合は--hsm-nameを使用します。

既存のKey Vault運用、Azure RBAC、監査ログ、ネットワーク制御に対称鍵を組み込みたい場合は、Key Vault Premiumのoct-HSMが適しています。一方、Managed HSMを導入すべきかどうかは、分離要件や組織のセキュリティ基準を含めて別途判断する必要があります。(Microsoft Learn)

対応するAESアルゴリズムと使い分け

oct-HSMでは、用途に応じてAES-GCM、AES-CBC、AES-KWを使い分けます。256ビット鍵を使用する場合、アルゴリズム名には原則としてA256が付きます。(Microsoft Learn)

アルゴリズム主な用途実務上の注意点
A256GCM小さなデータの暗号化・復号暗号文に加えてIVと認証タグの保存が必要
A256CBC既存システムとの互換性が必要な暗号化改ざん検知を別途設計する必要がある
A256CBCPADパディングを伴うCBC暗号化IVとパディング処理を考慮する
A256KWデータ暗号化鍵のラップ・アンラップ大きな本文データではなく鍵の保護に使う

新規システムで小さな値を直接暗号化する場合は、暗号化と改ざん検知を同時に行えるA256GCMが扱いやすい選択肢です。

ファイルや大きなJSON、データベースの本文を保護する場合は、Key Vaultに本文全体を送るのではなく、A256KWを使ったエンベロープ暗号化が適しています。

AES-256とCNSA 2.0の関係

Microsoftは、256ビットAESのoct-HSM鍵がCNSA 2.0の要件に沿い、耐量子暗号への準備に利用できると説明しています。量子計算機を意識した長期的な暗号設計では、128ビットや192ビットではなく、256ビット鍵を選ぶ理由になります。

ただし、AES-256鍵を使うだけでシステム全体が耐量子化されるわけではありません。実務上は、対称暗号部分の準備が進むと捉えるべきです。

将来的には、次の要素も個別に確認する必要があります。

  • TLS通信で利用する鍵交換方式
  • 証明書やコード署名の署名方式
  • アプリケーション間の認証方式
  • 鍵を共有・配送する仕組み
  • 長期間保存する暗号データの再暗号化計画

oct-HSM鍵を作成する前の準備

Key VaultのSKUをPremiumにする

oct-HSM鍵は、Standard SKUのKey Vaultには作成できません。既存のKey Vaultを使う場合は、最初にSKUを確認します。

az keyvault show \
  --name "<Key Vault名>" \
  --query "properties.sku.name" \
  --output tsv

結果がpremiumであることを確認してください。新しく作成する場合は、az keyvault createに--sku premiumを指定します。(Microsoft Learn)

データプレーン用のAzure RBACロールを割り当てる

Key Vaultのリソースを作成できる権限と、鍵を操作できる権限は別です。たとえば、Key Vault Contributorを持っていても、鍵の作成や暗号化を実行できるとは限りません。

主な組み込みロールは次のとおりです。(Microsoft Learn)

利用者推奨ロール主な用途
鍵管理者Key Vault Crypto Officer鍵の作成、更新、暗号操作
アプリケーションKey Vault Crypto User暗号化、復号、ラップ、アンラップ
ラップ専用アプリKey Vault Crypto Service Encryption User鍵メタデータの参照、ラップ、アンラップ
Key Vault管理者Key Vault ContributorKey Vaultリソースの管理。鍵データへのアクセスは不可

アプリケーションには、必要以上に強いKey Vault Crypto Officerを割り当てないことが重要です。暗号操作だけを行う場合は、Key Vault Crypto Userなどに権限を絞ります。

Azure CLIでoct-HSM AES-256鍵を作成する方法

以下のコマンドは、BashまたはAzure Cloud Shellを想定しています。

Premium Key Vaultを作成する

まず、リソースグループとPremium SKUのKey Vaultを作成します。

RESOURCE_GROUP="rg-kv-oct-hsm"
LOCATION="japaneast"
VAULT_NAME="<グローバルに一意なKey Vault名>"
KEY_NAME="aes256-oct-hsm"

az group create \
  --name "$RESOURCE_GROUP" \
  --location "$LOCATION"

az keyvault create \
  --name "$VAULT_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --location "$LOCATION" \
  --sku premium \
  --enable-rbac-authorization true

Key Vault名はAzure全体で一意である必要があります。

本番利用を見据える場合は、誤削除対策として消去保護も検討します。ただし、消去保護は有効化後に無効へ戻せないため、短期間で削除する検証環境では運用方針を決めてから設定してください。(Microsoft Learn)

鍵作成者にCrypto Officerを割り当てる

現在サインインしているユーザーに、Key Vault単位でKey Vault Crypto Officerを割り当てます。

VAULT_ID=$(az keyvault show \
  --name "$VAULT_NAME" \
  --query id \
  --output tsv)

MY_OBJECT_ID=$(az ad signed-in-user show \
  --query id \
  --output tsv)

az role assignment create \
  --assignee-object-id "$MY_OBJECT_ID" \
  --role "Key Vault Crypto Officer" \
  --scope "$VAULT_ID"

サービスプリンシパルやマネージドIDで実行する場合は、MY_OBJECT_IDを対象IDのオブジェクトIDに置き換えます。

ロール割り当てがデータプレーンへ反映されるまで時間がかかることがあります。直後の鍵作成で403エラーになった場合は、ロール名とスコープを確認したうえで、少し時間を置いて再実行してください。(Microsoft Learn)

oct-HSM AES-256鍵を作成する

--kty oct-HSMと--size 256を指定して鍵を作成します。

az keyvault key create \
  --vault-name "$VAULT_NAME" \
  --name "$KEY_NAME" \
  --kty oct-HSM \
  --size 256 \
  --ops encrypt decrypt wrapKey unwrapKey \
  --tags purpose=envelope-encryption environment=preview

各オプションの意味は次のとおりです。

オプション意味
--kty oct-HSMHSM保護された対称鍵を作成する
--size 256256ビットAES鍵にする
--ops encrypt暗号化を許可する
--ops decrypt復号を許可する
--ops wrapKey別の鍵をラップできるようにする
--ops unwrapKeyラップ済み鍵を復元できるようにする

同じ名前の鍵がすでに存在する場合、既存鍵が上書きされるのではなく、新しい鍵バージョンが作成されます。自動化スクリプトを繰り返し実行する場合は、意図せずバージョンが増えないように注意してください。(Microsoft Learn)

作成結果を確認する

次のコマンドで、鍵タイプ、許可された操作、バージョン付きの鍵IDを確認します。

az keyvault key show \
  --vault-name "$VAULT_NAME" \
  --name "$KEY_NAME" \
  --query "{
    kid:key.kid,
    kty:key.kty,
    keyOps:key.keyOps,
    enabled:attributes.enabled
  }" \
  --output json

確認すべきポイントは次のとおりです。

{
  "enabled": true,
  "keyOps": [
    "encrypt",
    "decrypt",
    "wrapKey",
    "unwrapKey"
  ],
  "kid": "https://<vault-name>.vault.azure.net/keys/aes256-oct-hsm/<version>",
  "kty": "oct-HSM"
}

kidには鍵のバージョンまで含まれます。一方、対称鍵の生データはレスポンスに含まれません。これは、鍵をHSMの外へ持ち出せない設計によるものです。(Microsoft Learn)

A256GCMで暗号化と復号を確認する

鍵を作成したら、短いテスト文字列を使って暗号化と復号を確認します。

テスト文字列を暗号化する

az keyvault key encrypt \
  --vault-name "$VAULT_NAME" \
  --name "$KEY_NAME" \
  --algorithm A256GCM \
  --value "oct-HSM preview test" \
  --data-type plaintext \
  --query "{
    result:result,
    iv:iv,
    tag:tag
  }" \
  --output json

A256GCMのレスポンスでは、次の3つを必ず保存します。

値役割
result暗号化されたデータ
iv暗号化時に使用された初期化ベクトル
tag改ざん検知に使う認証タグ

resultだけを保存しても復号できません。ivとtagも暗号文にひも付けて保存してください。追加認証データとしてAADを使った場合は、復号時に同一のAADが必要です。(Microsoft Learn)

出力された値を使って復号する

暗号化結果を変数へ設定します。

CIPHERTEXT="<resultの値>"
IV="<ivの値>"
TAG="<tagの値>"

続いて復号を実行します。

az keyvault key decrypt \
  --vault-name "$VAULT_NAME" \
  --name "$KEY_NAME" \
  --algorithm A256GCM \
  --value "$CIPHERTEXT" \
  --iv "$IV" \
  --tag "$TAG" \
  --data-type plaintext \
  --query result \
  --output tsv

次の文字列が表示されれば成功です。

oct-HSM preview test

復号に失敗した場合は、暗号文、IV、認証タグ、AAD、鍵バージョンのいずれかが暗号化時と異なっていないか確認します。(Microsoft Learn)

大きなデータにはエンベロープ暗号化を使う

Key Vaultのencryptとdecryptは、ファイル全体や大きな本文データを繰り返し処理する目的には向きません。Key Vaultの暗号化APIは単一データブロックを対象としており、大容量データを処理すると通信遅延やAPI呼び出し回数が増えます。(Microsoft Learn)

実システムでは、次のエンベロープ暗号化構成が扱いやすくなります。

  1. アプリケーション側でランダムな256ビットのデータ暗号化鍵を生成する
  2. データ暗号化鍵を使い、本文をローカルのAES-GCMで暗号化する
  3. データ暗号化鍵をoct-HSM鍵とA256KWでラップする
  4. 暗号文、ラップ済み鍵、IV、認証タグ、鍵IDを保存する
  5. 復号時にKey Vaultでデータ暗号化鍵をアンラップする
  6. 復元したデータ暗号化鍵で本文をローカル復号する

この構成では、Key Vault内の鍵をKEK、アプリケーションが一時的に生成する鍵をDEKとして扱います。

  • KEK：Key Encryption Key
  • DEK：Data Encryption Key

Key VaultへのリクエストはDEKのラップとアンラップに限定されるため、大きなデータを効率よく暗号化できます。

.NETからA256KWで鍵をラップする例

必要なパッケージを追加します。

dotnet add package Azure.Identity
dotnet add package Azure.Security.KeyVault.Keys

次の例では、32バイトのDEKを生成し、oct-HSM鍵でラップした後にアンラップしています。

using Azure.Identity;
using Azure.Security.KeyVault.Keys.Cryptography;
using System.Security.Cryptography;

string keyId =
    Environment.GetEnvironmentVariable("KEY_VAULT_KEY_ID")
    ?? throw new InvalidOperationException(
        "KEY_VAULT_KEY_IDが設定されていません。");

var credential = new DefaultAzureCredential();

var cryptographyClient = new CryptographyClient(
    new Uri(keyId),
    credential);

byte[] dek = RandomNumberGenerator.GetBytes(32);

try
{
    var wrapResult = await cryptographyClient.WrapKeyAsync(
        KeyWrapAlgorithm.A256KW,
        dek);

    byte[] wrappedDek = wrapResult.EncryptedKey;

    // 保存時は、wrappedDekと一緒にwrapResult.KeyIdも記録する
    string wrappingKeyId = wrapResult.KeyId;

    var unwrapResult = await cryptographyClient.UnwrapKeyAsync(
        KeyWrapAlgorithm.A256KW,
        wrappedDek);

    byte[] restoredDek = unwrapResult.Key;

    try
    {
        // restoredDekを使用して、本文をローカルのAES-GCMで復号する
    }
    finally
    {
        CryptographicOperations.ZeroMemory(restoredDek);
    }
}
finally
{
    CryptographicOperations.ZeroMemory(dek);
}

WrapResult.KeyIdには、ラップに使用された鍵のバージョン付きIDが入ります。ラップ済みDEKと一緒に保存しておけば、鍵をローテーションした後も、どのバージョンでアンラップすべきか判断できます。MicrosoftのSDKドキュメントでも、ラップ済み鍵と同じ鍵を使えるようにKeyIdを保存する必要があると説明されています。(Microsoft Learn)

本番コードでは、平文のDEKや復元したDEKをログへ出力しないでください。使用後は可能な範囲でメモリを消去し、変数の保持時間を短くします。

Bicepでoct-HSM鍵を作成する

複数環境へ同じ設定を展開する場合は、Azure CLIの手動実行だけでなくBicepで管理すると、鍵サイズや許可操作の差異を防ぎやすくなります。

次の例は、既存のPremium Key VaultにAES-256のoct-HSM鍵を作成します。

param vaultName string
param keyName string = 'aes256-oct-hsm'

resource vault 'Microsoft.KeyVault/vaults@2026-02-01' existing = {
  name: vaultName
}

resource aesKey 'Microsoft.KeyVault/vaults/keys@2026-03-01-preview' = {
  parent: vault
  name: keyName

  properties: {
    kty: 'oct-HSM'
    keySize: 256

    keyOps: [
      'encrypt'
      'decrypt'
      'wrapKey'
      'unwrapKey'
    ]

    attributes: {
      enabled: true
    }
  }
}

output keyResourceId string = aesKey.id

デプロイコマンドは次のとおりです。

az deployment group create \
  --resource-group "$RESOURCE_GROUP" \
  --template-file main.bicep \
  --parameters vaultName="$VAULT_NAME"

oct-HSMを含むリソース定義にはプレビューAPIが使われます。APIバージョンやスキーマは正式提供までに変更される可能性があるため、継続的インテグレーションへ組み込む際は、利用時点のMicrosoft Learnで最新仕様を確認してください。(Microsoft Learn)

導入時に失敗しやすいポイント

Standard SKUのKey Vaultを使っている

oct-HSMはPremium SKU専用です。鍵タイプが無効になる場合は、Azure CLIのバージョンだけでなくKey VaultのSKUも確認してください。

Key Vault Contributorだけを割り当てている

Key Vault ContributorはKey Vaultリソースを管理するロールであり、鍵データへのアクセス権ではありません。

鍵を作成する担当者にはKey Vault Crypto Officer、暗号処理を行うアプリケーションにはKey Vault Crypto Userなど、データプレーン用ロールが必要です。(Microsoft Learn)

Azure Portalにoct-HSMが表示されない

ポータル対応は段階的に展開されています。ポータルに項目がなくても、Azure CLIやBicepで作成できる可能性があります。

AES-GCMのIVや認証タグを保存していない

A256GCMでは、暗号文だけでなくIVと認証タグが必要です。AADを指定した場合はAADも復号時に一致させます。

保存データの構造は、たとえば次のようにします。

{
  "algorithm": "A256GCM",
  "keyId": "https://<vault>.vault.azure.net/keys/<name>/<version>",
  "ciphertext": "<暗号文>",
  "iv": "<IV>",
  "tag": "<認証タグ>",
  "aad": "<必要な場合のみ>"
}

鍵名だけを保存している

鍵をローテーションすると、同じ鍵名の下に新しいバージョンが作成されます。古い暗号文やラップ済みDEKを復号するには、暗号化時に使ったバージョンが必要です。

保存対象には鍵名だけでなく、バージョンを含むkidまたはKeyIdを含めてください。(Microsoft Learn)

ファイル全体をKey Vaultで直接暗号化している

Key Vaultへの暗号化呼び出しを本文データのサイズや件数に比例させると、通信遅延、スロットリング、コストの影響を受けやすくなります。

直接暗号化は動作確認や小さな秘密情報に限定し、一般的なアプリケーションデータにはエンベロープ暗号化を使います。(Microsoft Learn)

連携先Azureサービスも自動的に対応すると考えている

Key Vaultがoct-HSMに対応しても、Azure Key Vaultを利用するすべてのAzureサービスが、oct-HSM鍵をカスタマー管理キーとして受け付けるとは限りません。

Azure Storage、データベース、分析サービスなどへ組み込む場合は、各サービスのカスタマー管理キー要件で、対応する鍵タイプとアルゴリズムを個別に確認してください。

プレビューのまま本番へ導入する

oct-HSM対称鍵はパブリックプレビューとして提供されており、現段階ではSLAがありません。Microsoft Learnでも、プレビュー機能は現状有姿で提供され、本番ワークロードには推奨されないと案内されています。(Microsoft Learn)

検証では、機能が動くかどうかだけでなく、次の項目を確認します。

検証項目確認内容
認証マネージドIDやサービスプリンシパルで接続できるか
RBAC最小権限で必要な操作だけを実行できるか
ネットワークファイアウォールやプライベートエンドポイント環境で利用できるか
性能ラップ・アンラップの遅延が許容範囲か
障害処理Key Vaultへ接続できない場合の再試行やエラー処理
ローテーション新旧バージョンの暗号データを復号できるか
監査操作ログから利用主体と操作内容を追跡できるか
復旧削除、無効化、ロール変更時の復旧手順があるか

oct-HSM AES-256鍵を導入するための進め方

Azure Key Vault Premiumのoct-HSM対称鍵を試す場合は、次の順序で進めると安全です。

  1. 非本番用のPremium Key Vaultを用意する
  2. Azure RBACで鍵管理者とアプリケーションの権限を分離する
  3. Azure CLIで256ビットのoct-HSM鍵を作成する
  4. A256GCMによる暗号化・復号を確認する
  5. A256KWによるDEKのラップ・アンラップを実装する
  6. 鍵バージョン、IV、認証タグを含む保存形式を決める
  7. ローテーション後も過去データを復号できるか確認する
  8. 正式提供、SLA、対応リージョン、SDK仕様を確認して本番利用を判断する

oct-HSMの価値は、単にAES暗号化をクラウドで実行できることではありません。AES-256のKEKをアプリケーションから分離し、HSM保護、Azure RBAC、監査、鍵バージョン管理の下に置ける点にあります。

まずはPremium Key Vaultに検証用鍵を1本作成し、A256GCMの動作確認だけで終わらせず、実際の利用形態に近いA256KWのエンベロープ暗号化まで試すことが、導入判断の最短ルートです。

Azure
Azure Key Vault 対称鍵 oct-HSM AES-256 耐量子暗号

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次