はじめに
昨年まで参画していたクラウド移行のPoC案件にてAzure Cloud HSMを使用したため、構築時に躓いた点とAWS CloudHSMと比較して気になった点を備忘として記載します。
Azure Cloud HSMとは
- Azure内で提供される専用のクラウド型ハードウェアセキュリティモジュール(HSM)サービスのこと
- Dedicated HSMの後継サービスとして、2025年の夏ごろから日本でも利用できるようになりました
環境
HSM : Azure Cloud HSM
クライアントVMのOS : Red Hat Enterprise Linux8.6
クライアントSDK : AzureCloudHSM-ClientSDK-2.0.2.1
HSMの用途 : PKCS#11を使用して電子署名を行う
構築時の参考資料
【オンボーディングガイド】OnboardingGuides/Azure Cloud HSM Onboarding.pdf
【統合ガイド】IntegrationGuides/Azure Cloud HSM PKCS11 Integration Guide.pdf
※現時点では日本語のドキュメントはありません
構築時に躓いた点①業務アプリが動かない
発生事象
Azureが提供しているガイドに従って構築を進め、ガイドに記載のサンプルアプリを作成し実行したところ問題なく動作したため、業務アプリの動作確認を行いましたが、エラーコード5※で異常終了が発生しました。
※PKCS#11におけるエラーコード5はCKR_GENERAL_ERRORを指す。ライブラリやNWなど発生原因の候補は多岐にわたる。
発生原因
Azure Cloud HSMでPKCS#11アプリケーションを動かす際に必須の環境変数が不足していたためでした。
なおその環境変数は構築ガイドには記載されておらず、クライアントSDKのリリースノートに書いてあるのみでした
Configuration Files
Added the "azcloudhsm_application" environment variable for locating the azcloudhsm_application.cfg file. This means it no longer is required to be in the working directory of customers applications.
対処
VMに以下の環境変数を設定したところ正常にアプリを動かすことができました。
- azcloudhsm_application=/opt/azurecloudhsm/bin/azcloudhsm_application.cfg
構築時に躓いた点②VM起動時にAzure Cloud HSMの前提サービスが自動起動しない
発生事象
Azure Cloud HSMを操作する場合は事前にVM上でazure-cloud-hsm.serviceという前提サービスを起動しておく必要があります。
構築の際、公式ガイドに従って以下のコマンドを実行し自動起動する設定を行ったはずですが、VMを起動してもこのサービスが自動で起動してきませんでした。
# systemctl enable azure-cloud-hsm.service
発生原因
クライアントSDKのインストール時に作成されたsystemdサービスファイルは、VMのNW管理サービスが起動した直後にサービスが起動するように構成されていました。その影響でVMとHSMが通信を行うための準備が済む前にサービスが起動しようとしてしまい異常終了していました。
[Unit]
Description=Azure Cloud HSM Client Service
After=network.target
#↑これが原因
[Service]
Type=simple
ExecStart=/opt/azurecloudhsm/bin/azcloudhsm_client /opt/azurecloudhsm/bin/azcloudhsm_resource.cfg
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
#Logging
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=azure-cloud-hsm
[Install]
WantedBy=multi-user.target
対処
azure-cloud-hsm.serviceを以下のように変更しリロードしたところ、VM起動時に自動的にサービスが上がるようになりました。
- ネットワークが利用不可な状態ではサービスを起動できないよう依存関係を設定
- 失敗時のリトライを追加
[Unit]
Description=Azure Cloud HSM Client Service
After=network-online.target
Requires=network-online.target
# 依存関係の設定
[Service]
Type=simple
ExecStart=/opt/azurecloudhsm/bin/azcloudhsm_client /opt/azurecloudhsm/bin/azcloudhsm_resource.cfg
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=10
# リトライを追加
#Logging
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=azure-cloud-hsm
[Install]
WantedBy=multi-user.target
AWS CloudHSMと比べて気になった点
同一プロジェクトにて競合サービスのAWS CloudHSMも使用したため気になった点をざっくり以下に記載しました。
情報の充実度
-
AWS CloudHSMの場合
構築手順、コマンドリファレンス、構築中・運用中のトラブルシューティングまで公式の情報が比較的充実している。 -
Azure Cloud HSMの場合
構築手順はガイドに書かれているが、HSM固有のコマンドに関する情報がどこにも書かれていない。トラブルシューティングに関しては構築時に発生し得る問題に対する簡単なFAQがあった。
デプロイについての自由度
-
AWS CloudHSMの場合
ユーザ側でデプロイするAZおよびHSMの台数を決めることができる。 -
Azure Cloud HSMの場合
1つのHSMクラスターにつき固定で3台のHSMがデプロイされる。またAZについてはAzure側で自動的に分散してデプロイするようになっている。
料金
- AWS CloudHSMの場合
アジアパシフィック(東京)hsm2m.medium : $1.81(1台あたり1H)
Azureと比較すると1台当たりの料金がやや高額だがHSMの台数はユーザ側で決められるため比較的コントロールしやすい。
- Azure Cloud HSMの場合
東日本リージョン Standard B1 : $4.80(3台あたり1H)
料金はAWSと同じく高額、1台当たりのコストはやや低いが3台セットでデプロイされるためAWSと比較すると融通が利かない。
※2026年1月時点での料金
前提サービスの有無
- AWS CloudHSMの場合
特になし。 - Azure Cloud HSMの場合
クライアントVM上でazure-cloud-hsm.serviceを起動しておく必要がある。
AWS CloudHSMから移行する場合はこのサービスによってメモリが常に一定量掴まれることを考慮してVMのサイズを選定したほうが良い。
バックアップとリストア
-
AWS CloudHSMの場合
HSMの削除時と1日1回不定期にバックアップが行われる。
取得済みバックアップからのリストアもGUIから簡単に実行できる。 -
Azure Cloud HSMの場合
自動でバックアップの取得は行われない。また、GUIからの操作もできないためスクリプト化して実行する必要がある。実運用に乗せる場合バックアップの取得を定期的に実行できるよう考慮が必要。
最後に
ご覧いただきありがとうございました。
誰かのお役に立てたら幸いです。