MENU

Azure Managed HSM の PKCS#11でPIN変更は可能？C_SetPIN非対応とC_Loginの認証情報ローテーション手順

Azure

Azure Managed HSM を PKCS#11（C_Login）経由で利用していると、PIN の設定・変更方法で迷いがちです。本記事では、C_SetPIN が使えない理由と、実際に“PIN相当”の認証情報をどこで管理し、どうローテーションするのが安全かを運用目線で整理します。

目次

結論：Azure Managed HSM では PKCS#11 の C_SetPIN で PIN 変更できない

Azure Managed HSM を PKCS#11 インターフェイスとして使う場合、まず押さえるべきポイントは「Managed HSM が提供する PKCS#11 は“フル実装”ではない」という点です。Microsoft が提供するのは TLS Offload Library（PKCS#11 v2.40 準拠）であり、F5 BIG-IP と Nginx の SSL/TLS オフロード用途に必要な機能に絞って提供されています。そのため、PKCS#11 仕様に存在するすべての関数が実装されているわけではありません。

この前提に立つと、質問で挙がりやすい C_SetPIN による PIN 変更は、Managed HSM の PKCS#11 ではサポートされません。Microsoft Q&A でも「C_SetPIN はサポートされず、PIN は PKCS#11 コマンドではなく Managed HSM リソース側で管理される」旨が明言されています。

確認したいこと結論
C_SetPIN で PIN を変更できるかできない（サポート対象外）
C_Login の “PIN” はどこで管理されるかPKCS#11 の世界ではなく、Managed HSM のアクセス制御（ロール）と、利用する Azure ID の資格情報（サービスプリンシパル/マネージド ID）側で管理する
PIN をローテーションしたい場合の現実解サービスプリンシパルのシークレット/証明書の更新、またはマネージド ID へ移行し、必要に応じて Managed HSM のロール割り当てを更新する

まず整理：Azure Managed HSM の「PKCS#11」は TLS Offload Library

Azure Managed HSM の PKCS#11 連携は、一般的な HSM ベンダーが提供する汎用 PKCS#11 ライブラリとは設計思想が異なります。Microsoft Learn では、TLS Offload Library が「F5 (BIG-IP) と Nginx の SSL/TLS Offload のために、限定された機構・関数だけをサポートする」と説明されています。さらにライブラリ内部では Azure Key Vault REST API を利用して Managed HSM とやり取りします。

項目Azure Managed HSM（TLS Offload Library）
主な用途F5 BIG-IP / Nginx の TLS 署名処理を HSM にオフロード（鍵を外に出さずに署名する）
PKCS#11 準拠PKCS#11 v2.40 準拠（ただしサポート関数は限定）
内部通信Azure Key Vault REST API を通じて Managed HSM のデータプレーンにアクセス
実装の特徴PKCS#11 の属性を Key Vault のタグに変換して保持する設計（タグ操作に注意が必要）

特に「タグ変換」は運用で効きます。Learn では、TLS Offload Library が PKCS#11 属性を Key Vault のタグとして扱い、タグを REST API で不用意に操作するとアプリが壊れ得る点が警告されています。

サポートされる鍵種別と暗号機構（TLS Offload 用途）

Managed HSM の TLS Offload Library は「TLS ハンドシェイクで必要になる署名」を主眼にしているため、サポート範囲は偏ります。README では RSA/ECDSA の鍵種別、署名・検証、SHA 系ダイジェストなどが挙げられ、暗号化/復号や鍵ラップはライブラリ経由では非サポートとされています。

カテゴリサポート状況（TLS Offload Library）補足
鍵種別RSA / ECDSA（AES は非サポート）RSA は複数ビット長、ECDSA は複数曲線が例示されている
署名・検証RSA / ECDSA の Sign/Verify をサポートSignRecover/VerifyRecover は非サポート
ハッシュ/ダイジェストSHA256 / SHA384 / SHA512 をサポートTLS の典型構成で必要になりやすい範囲
暗号化・復号ライブラリ経由では非サポート必要なら Managed HSM API（別経路）での設計を検討
鍵ラップライブラリ経由では非サポート必要なら Managed HSM API（別経路）での設計を検討

C_SetPIN が非サポートである根拠：サポート API 一覧に含まれない

TLS Offload Library の GitHub README には、サポートされる PKCS#11 API 操作が列挙されています。ここに C_Login はありますが、C_SetPIN は含まれていません。つまり、仕様上「存在する関数」でも、Managed HSM の PKCS#11 インターフェイスとしては呼び出し対象外です。

カテゴリ代表的な関数Managed HSM TLS Offload Library
初期化・情報取得C_Initialize / C_Finalize / C_GetInfo などサポート
セッション管理C_OpenSession / C_CloseSession / C_GetSessionInfoサポート
認証C_Login / C_Logoutサポート
オブジェクト探索C_FindObjectsInit / C_FindObjects / C_FindObjectsFinalサポート
鍵生成・属性C_GenerateKeyPair / C_GetAttributeValue / C_SetAttributeValueサポート
署名・検証C_SignInit / C_Sign / C_VerifyInit / C_Verifyサポート
PIN 変更C_SetPIN非サポート

上表の根拠となる「サポート API 操作の列挙」は README に明示されています。

C_Login の “PIN” は何者か：トークン内 PIN ではなく「Azure への認証情報」

PKCS#11 の一般的な世界観では、PIN はトークン（HSM）内ユーザーの認証情報です。一方で TLS Offload Library は、内部で REST API を呼び出すため、Azure 側で認証できる主体（サービスプリンシパルやマネージド ID）を前提にしています。実際、Learn と README では、鍵生成ツールや TLS サーバーが サービスプリンシパルのクライアント ID とクライアント シークレット、または マネージド ID を使うことが具体的に説明されています。これが多くの PKCS#11 クライアントからは「C_Login に渡す PIN」として見える部分です。

サービスプリンシパルで使う場合

Learn の手順では、鍵生成ツール（mhsm_p11_create_key）が環境変数 MHSM_CLIENT_ID と MHSM_CLIENT_SECRET からサービスプリンシパルの資格情報を読み取ることが明記されています。README でも同様に、サービスプリンシパルの「Application (Client) ID」と「Password (Client Secret)」を使う説明があります。

マネージド ID で使う場合

マネージド ID を使う場合、鍵生成ツールは –identity 引数で有効化でき、ユーザー割り当てマネージド ID の場合は client_id を設定ファイル（mhsm-pkcs11.conf）に記載する、と説明されています。また README では、TLS サーバー側も MSI を有効化すればサービスプリンシパル資格情報を無視する挙動が書かれています。ここまで来ると「PIN を変更する」のではなく、「どの Azure ID でアクセスするか」を切り替える発想になります。

PIN（認証情報）を変えたいときに触るべき場所は二つ

Managed HSM で “PIN 相当”を更新する際は、次の二つを分けて考えると混乱が減ります。

  • Azure ID の資格情報（秘密情報）をどう更新するか
    サービスプリンシパルのシークレット/証明書、またはマネージド ID の割り当て・設定を更新します。
  • Managed HSM 側の権限（ロール割り当て）をどう更新するか
    どの主体が /keys あるいは /keys/<keyname> に対して署名できるかを更新します。Managed HSM のデータプレーンはローカル RBAC（組み込みロール）で制御されます。

Managed HSM のローカル RBAC（組み込みロール）を理解する

Managed HSM には「Managed HSM Crypto User」「Managed HSM Crypto Officer」などの組み込みロールがあり、どのロールが鍵の sign/verify などを許可するかが一覧化されています。例えば Crypto User は署名などの鍵操作を含む多くの鍵管理操作を許可します。

ロール名（例）何ができるか（要点）よく使う場面
Managed HSM Crypto User鍵の各種操作（署名/検証などを含む）を実行できる（ただし一部例外あり）TLS 署名を実行する実行主体（Nginx / F5 用の ID）
Managed HSM Crypto Officerロール管理、削除済みキーの purge/recover、キーの export など運用管理者（権限を強くしすぎない設計が重要）
Managed HSM Policy Administratorロール割り当ての作成/削除を実行できる権限付与の担当者（職務分掌）

各ロールが許可するデータアクション（/keys/sign/action など）は Learn の表で確認できます。

ロール割り当ての「スコープ」も重要

Managed HSM のローカル RBAC は、HSM 全体（/ または /keys）と、特定キー（/keys/<keyname>）のスコープをサポートします。最小権限を徹底するなら、署名に使うキー名を固定し、/keys/<keyname> に絞って割り当てる設計が有効です。

アクセス制御は「permissive」と「granular」どちらで組むか

TLS Offload Library の公式ドキュメントでは、アクセス制御の組み方として「permissive approach」と「granular approach」が紹介されています。前者はシンプルに Crypto User を /keys に付与する方法、後者は “鍵生成用” と “TLS 署名用” で主体を分けて最小権限を狙う方法です。

アプローチ構成イメージ向いているケース注意点
PermissiveTLS Offload 用の主体に Crypto User を /keys で付与Managed HSM を TLS オフロード専用にしており、シンプルに早く動かしたい権限が広くなりやすい。後から絞るのが難しくなるため、将来の拡張も見越して設計する
Granular「鍵生成用の主体」と「TLS 署名用の主体」を分離し、読み取り/署名などの権限を細かく割り当て職務分掌・監査要件が強い、鍵が増える予定がある、署名対象キーを厳密に限定したい初期設計・運用手順が複雑になりやすい（どの主体に何を付けたか、を常に追える仕組みが必要）

PIN ローテーションの現実的な運用パターン

「C_SetPIN が使えない」ことを前提に、現場で採用しやすい更新パターンを三つに整理します。TLS オフロード用途では、アプリ停止を極小化しつつ、漏えい・期限切れ・権限過多のリスクを下げることが目的になります。

パターン何を変更するかメリット注意点
同一サービスプリンシパルでシークレットを更新クライアント ID は固定し、クライアント シークレット（パスワード）だけをローテーション影響範囲が小さく、切り替えが単純秘密情報を扱う運用は残る（漏えい対策/保管/配布）
サービスプリンシパル自体を作り替えて切り替え新しい ID を作り、Managed HSM のロール割り当ても新 ID へ付け替え資格情報と権限の“棚卸し”を同時にできるライブラリは複数サービスプリンシパルを同時に扱えないため、切り替えタイミングの設計が重要
マネージド ID へ移行アプリに MSI を割り当て、設定ファイルで client_id 等を指定（必要に応じて）秘密情報（PIN 相当）を持たずに運用できる実行環境が Azure にあることが前提になりやすい（VM/AKS など）

「複数サービスプリンシパルを同時に扱えない」は README の FAQ に明記されているため、特に切り替え手順では意識しておくと事故が減ります。

同一サービスプリンシパルでシークレットだけ更新する

最も現実的で事故が少ないのはこのパターンです。TLS サーバーや鍵生成ツールが参照する「パスワード（クライアント シークレット）」を更新し、同じクライアント ID のまま切り替えます。鍵生成ツールは MHSM_CLIENT_ID / MHSM_CLIENT_SECRET を読み取るため、更新対象が明確です。

  • 新しいシークレットを発行（旧シークレットは残す）
  • Nginx/F5 側の設定（または環境変数）を新シークレットに更新
  • プロセス再起動や設定リロードで新シークレットを有効化
  • 署名処理（ハンドシェイク）を検証後、旧シークレットを無効化

サービスプリンシパルを作り替えて切り替える

棚卸しとセットでやりたい場合は、ID そのものを作り替えます。切り替えには Managed HSM 側のロール割り当て更新が必須です。Learn の例では、/keys スコープに Crypto User を割り当てる Azure CLI コマンドが提示されています（実環境では最小権限に合わせてスコープを調整してください）。

az keyvault role assignment create --hsm-name ContosoMHSM \
  --role "Managed HSM Crypto User" \
  --assignee <新しいサービスプリンシパル> \
  --scope /keys

また、Managed HSM のローカル RBAC は /keys/<keyname> のような「キー単位スコープ」もサポートします。署名用途キーが限定できるなら、こちらに寄せるのがセキュアです。

az keyvault role assignment create --hsm-name ContosoMHSM \
  --role "Managed HSM Crypto User" \
  --assignee <新しいサービスプリンシパル> \
  --scope /keys/<keyname>

マネージド ID に寄せて「PIN を持たない」設計にする

長期運用で効くのは、サービスプリンシパルのシークレット管理から卒業することです。Learn と README では、鍵生成ツールは –identity でマネージド ID を利用でき、ユーザー割り当ての場合は mhsm-pkcs11.conf に client_id を設定できると説明されています。また TLS サーバー側も MSI を有効化すればサービスプリンシパル資格情報を無視する、と書かれています。

  • 実行基盤（VM/AKS など）にマネージド ID を割り当てる
  • Managed HSM のロール割り当てを、そのマネージド ID に付与する（/keys または /keys/<keyname>）
  • mhsm-pkcs11.conf で MSI を有効化（必要なら user-assigned の client_id を指定）
  • アプリ（Nginx/F5）の設定から固定シークレットを排除する

運用上の落とし穴：PIN 以前にハマりやすいポイント

キーは「TLS Offload Library で作ったもの」しか互換にならない

README の FAQ には、Managed HSM で普通に作成したキーを後から TLS Offload Library で使うことはできず、ライブラリ経由で作ったキーだけが互換になる旨が明記されています。C_Login の成否以前に「鍵が見つからない」「期待した属性で検索できない」といった事象が出る場合、まずこの前提を疑うのが近道です。

タグを直接編集するとアプリが壊れる可能性がある

TLS Offload Library は PKCS#11 属性を Key Vault のタグとして扱います。Learn では、REST API でタグを操作するとライブラリ利用アプリが壊れ得る、と明確に警告しています。運用の自動化でタグを一括変更したり、ポータルでラベルを変えたりする前に、影響範囲を必ず検証してください。

複数サービスプリンシパルを同時に扱えない

README の FAQ では「複数サービスプリンシパルをサポートしない」と明記されています。つまり “新旧並行運用で無停止切替” がやりにくい構造です。だからこそ、切替が必要なら「同一サービスプリンシパルでシークレット更新」か「マネージド ID 化」が現実的になります。

「C_SetPIN が必要」な要件なら、サービス選定を見直す

もし要件として「汎用 PKCS#11 アプリをそのまま持ち込みたい」「暗号化/復号、鍵ラップ、トークン管理まで含めて PKCS#11 を使いたい」といった場合、Managed HSM（TLS Offload Library）ではギャップが出ます。Microsoft Learn の比較記事では、PKCS#11/JCA/JCE/CNG/KSP といったレガシー API とライブラリは Azure Cloud HSM のみがサポート対象である旨が記載されています。Managed HSM は SSL/TLS Offload では強みがありますが、フル機能の PKCS#11 目的なら Cloud HSM 側を検討するのが筋です。

サービス向いているシナリオPKCS#11 の位置づけ
Azure Managed HSMTLS オフロード（F5/Nginx）で署名を HSM に任せたいTLS Offload Library として限定的に提供（サポート関数が限定）
Azure Cloud HSMPKCS#11 を前提とした既存アプリの Lift & Shift、レガシー API の利用PKCS#11 を含むレガシー API のサポート対象

Cloud HSM の PKCS#11 では、C_Login の PIN を <username>:<password> 形式で渡す、といった “一般的な PKCS#11 らしい” 前提がドキュメントにも登場します（Managed HSM とは前提が異なります）。

実務チェックリスト：PIN ローテーションを安全に終わらせるために

  • 何を PIN として渡しているかを棚卸しする（サービスプリンシパルのシークレットなのか、MSI なのか）
  • どのスコープにロールを割り当てているかを確認する（/keys か /keys/<keyname> か）
  • 署名に必要な最小権限になっているかを見直す（Crypto User を付けっぱなしにしない、キー単位スコープを検討）
  • 更新手順は「新しい資格情報を追加 → アプリで切替 → 動作確認 → 古い資格情報を無効化」の順で行う
  • 鍵のタグや属性を外部から更新する自動化がないか確認する（ある場合は影響検証を必須にする）

まとめ

Azure Managed HSM の PKCS#11（TLS Offload Library）では、C_Login に見える “PIN” は一般的なトークン内 PIN とは性質が異なり、サービスプリンシパル/マネージド ID など Azure 側の認証とロール割り当てに紐づく概念です。そのため C_SetPIN による変更はできず、運用としては「資格情報（シークレット/ID）のローテーション」と「Managed HSM のロール割り当て更新」をセットで設計するのが最短ルートになります。

Azure
マネージドID C_Login Azure Managed HSM C_SetPIN PKCS#11

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次