Azure Key Vaultを「作った」ところまでは進んだものの、実際に中身をどう出し入れするのかで手が止まっていませんか。シークレット・キー・証明書の3種類があるのは分かった、でも「キーはどうやって作るの？」「ローテーションって結局なにを設定するの？」「証明書の自動更新って本当に勝手に更新されるの？」——このあたりは、公式ドキュメントを読んでもなかなかスッと入ってこない部分です。
私自身、Key Vaultを触りはじめた頃はここで一度つまずきました。とくにキーとローテーションまわりは、金庫という比喩のイメージと、実際のコマンドやポリシー画面がうまく結びつかなくて、しばらくモヤモヤしていた記憶があります。
「シークレット・キー・証明書、それぞれ作り方が違うの？ローテーションと自動更新はどう設定するの？」
この記事では、その3種類のオブジェクトを実際に作って・取り出して・更新するところまでを、手を動かす目線で解説します。具体的には、シークレットの作成とバージョン管理、キーの作成とローテーションポリシー、証明書の作成と自動更新（統合CA連携）まで。公式Microsoft Learnの正確さは押さえつつ、運用でつまずきやすい所を日本語で噛み砕いていきます。読み終わるころには、「Key Vaultの中身を自分で管理する」感覚がつかめているはずです。
なお、そもそもKey Vaultが何のための仕組みなのか、全体像があやふやな方は先に Azure Key Vaultとは？シークレット・キー・証明書を安全に管理する仕組み に目を通しておくと、この記事の位置づけがはっきりします。本記事はその親記事の「中身を実際に扱う」部分を深掘りする子記事です。
その前に：Key Vault最大の勘所「取り出さずに金庫の中で使う」
手を動かす前に、一つだけ頭に入れておいてほしい考え方があります。ここを外すと、とくにキーの話が最後まで腑に落ちません。それは「シークレットは取り出して使う、キーは取り出さずに金庫の中で使う」という違いです。
Key Vaultは機密情報のための「クラウドの金庫」でした。この金庫、しまい方に2つのモードがあると考えると分かりやすいです。
シークレットは、金庫にしまった「紙のメモ」です。データベースの接続文字列やAPIキーといった文字列をそのまま保管し、アプリが必要になったら金庫を開けてメモそのものを取り出して使います。中身の文字列を丸ごと持ち出す、というイメージですね。
対してキーは、金庫の中に据え付けられた「はんこ（印鑑）」だと思ってください。ふつう、大事な実印は外に持ち出しません。書類のほうを金庫に持ち込んで、金庫の中で押印して返してもらいます。Key Vaultのキーもまさにこれで、暗号化・復号・署名といった操作を金庫の中で行い、結果だけを受け取る。キーそのもの（秘密鍵）は基本的に外に出しません。だから盗まれにくいわけです。とくにPremiumやManaged HSMでは、この「はんこ」がHSMという耐タンパーな金庫の奥に固定されていて、物理的に取り出せない構造になっています。
「シークレット＝取り出して使うメモ」「キー＝取り出さず金庫の中で押すはんこ」。この一行を軸に読み進めると迷いません。
そして証明書は、そのはんこ（キー）に「これは本物ですよ」という公的な保証書を貼り付けたもの、というイメージです。中身はキーとメタデータの組み合わせで、HTTPS通信などで身元を証明するのに使います。以下、この3つを順番に、実際に作って動かしていきます。操作はコマンド（Azure CLI）を中心に載せますが、ポータルの同じボタンを押しても結果は同じです。
シークレットを作成・取得し、バージョンを理解する
まずは一番シンプルなシークレットからです。ここで「同名で上書きしたのに古い値も残っている」という、Key Vault独特のバージョンの挙動をつかんでおくと、この後のキー・証明書も一気に理解が進みます。
作成する（secret set）と取得する（secret show）
ポータルなら、Key Vaultのリソースを開いて「オブジェクト」→「シークレット」→「生成/インポート」から、名前と値を入れるだけです。CLIなら次の一行で作れます。--vault-name に自分の金庫（Vault）名、--name にシークレットの名前、--value に中身を渡します。
az keyvault secret set \
--vault-name myVault \
--name DbPassword \
--value "P@ssw0rd-01"取り出すときは show です。ただし注意点があって、素の show は値を含めた全メタデータを返すので、実務でシェルに値だけ欲しいときは --query value -o tsv を付けて中身の文字列だけを抜き取るのが定番です。
az keyvault secret show \
--vault-name myVault \
--name DbPassword \
--query value -o tsvここでよくあるつまずきが、作成はできたのに取得で権限エラーになるパターンです。「Set（書き込み）はできたのにGet（読み取り）で弾かれる」ときは、アクセス制御の設定を疑ってください。RBACモデルのVaultなら、あなたのアカウントに Key Vault シークレット ユーザー のようなデータ操作ロールが割り当たっているかを確認します。この「操作する権限」と「値そのもの」は別レイヤーの話で、詳しくは姉妹記事の アクセス制御 で扱っています。
バージョン管理：上書きしても古い値は消えない
ここがシークレットの面白いところです。さっきと同じ名前で、値だけ変えてもう一度 set してみます。
az keyvault secret set \
--vault-name myVault \
--name DbPassword \
--value "P@ssw0rd-02"普通のファイルなら「上書き＝前の内容は消える」ですが、Key Vaultは違います。同名で set するたびに新しい「バージョン」が積み上がり、古いバージョンもそのまま金庫の中に残るのです。イメージとしては、上書きというより「同じ名前のフォルダに、日付入りのメモをどんどん重ねていく」感じですね。最新のものが既定で取り出されますが、過去のメモも捨てられずに残っている。
実際に積み上がったバージョンは、次のコマンドで一覧できます。
az keyvault secret list-versions \
--vault-name myVault \
--name DbPassword \
-o table各バージョンには、URLの末尾に付く長い16進数のバージョンIDが振られています。特定の古いバージョンを取りたければ --version <バージョンID> を付けて show します。この仕組みのおかげで、パスワードを更新したあとにアプリが不調になっても、一つ前のバージョンにすぐ戻せるわけです。「更新したら壊れた、でも前の値が分からない」という事故を防いでくれる、地味ですが重要な機能です。
ちなみに、このバージョンという考え方はシークレット・キー・証明書のすべてに共通しています。「同名で新しくすると、旧世代を残したまま世代交代する」——このモデルが分かっていると、次のキーのローテーションが驚くほどすんなり入ってきます。
キーを作成し、ローテーションポリシーで自動更新する
次はキーです。冒頭で触れたとおり、キーは「取り出さず、金庫の中で暗号操作するはんこ」でした。ここではまず種類を選んで作成し、そのあと自動で世代交代させるローテーションポリシーまで設定します。
キーを作成する：RSAとECの使い分け
キーを作るときに最初に選ぶのが種類で、代表的なのが RSA と EC（楕円曲線） の2つです。ここで固まりやすいので、ざっくりの使い分けを先に言ってしまいます。
RSAは、いわば昔から広く使われている定番のはんこです。暗号化（データを包む）にも署名（本人性の証明）にも使え、対応している相手も多い。迷ったらRSAでまず問題ありません。サイズは2048ビットが標準で、より強固にしたければ3072・4096も選べます。
ECは、短い鍵長で同等の強度を出せる、新しめの高性能なはんこです。主な用途は署名で、鍵が小さいぶん処理が軽く、モバイルやTLSの署名まわりで好まれます。「暗号化にも署名にも」という汎用性ならRSA、「署名用途で効率重視」ならEC、と覚えておけば実務では十分です。CLIでRSAキーを作るなら次のとおり。
az keyvault key create \
--vault-name myVault \
--name MyAppKey \
--kty RSA \
--size 2048--kty（key type）で種類を指定します。ECにしたいなら --kty EC にして、サイズの代わりに --curve P-256 のように曲線を指定します。作成しても、返ってくるのは公開鍵の情報や識別子だけで、秘密鍵そのものは出てきません。これが「金庫から出さない」の実物です。ここで「あれ、鍵の中身がダウンロードできない、失敗した？」と勘違いしがちですが、出てこないのが正常です。
ローテーションポリシー：有効期限と自動ローテーション間隔
キーは長く使い続けるほど、万一漏れたときの被害が大きくなります。そこでセキュリティの定石として、定期的に新しい鍵へ切り替える（ローテーションする）運用が推奨されます。とはいえ、これを人間が手動でカレンダー管理するのは現実的ではありません。忘れます。
そこでKey Vaultには、キーにローテーションポリシーを設定して、期限が来たら自動で新しいバージョンを作らせる機能があります。ここで押さえるべき設定値は主に2つです。
- 有効期限（expiry）：そのキーがいつまで有効か。「作成から○ヶ月」のように期間で決めます。
- 自動ローテーション間隔：どのタイミングで新バージョンを自動生成するか。「有効期限の○日前」または「作成から○ヶ月後」といった条件で指定します。
ポータルなら、キーを開いて「ローテーションポリシー」から「有効期限」「ローテーションのタイミング（Automatically renew）」を埋めるだけです。CLIやポリシーファイルでも設定できます。たとえば「有効期限は540日、期限の30日前に自動ローテーション」というポリシーを設定するイメージは次のようになります（expiryTime のP540DはISO 8601の期間表記で「540日」を意味します）。
# policy.json の中身（抜粋イメージ）
{
"lifetimeActions": [
{
"trigger": { "timeBeforeExpiry": "P30D" },
"action": { "type": "Rotate" }
}
],
"attributes": { "expiryTime": "P540D" }
}
az keyvault key rotation-policy update \
--vault-name myVault \
--name MyAppKey \
--value policy.jsonローテーションが走ると何が起きるか。ここで前のセクションのバージョンの話が効いてきます。ローテーションは同じキー名のまま、新しいバージョンを作るだけです。古いバージョンも金庫に残るので、まだ古い鍵で暗号化されているデータも、その古いバージョンで問題なく復号できます。名前は変わらないので、アプリ側は「バージョン指定なしで最新を使う」書き方にしておけば、切り替えを意識せず自然と新しい鍵に乗り換わっていく。これがローテーションの気持ちよさです。
逆に、ここが実務でのつまずきポイントでもあります。アプリが特定のバージョンID付きのURLを決め打ちで参照していると、鍵が新しくなっても古いバージョンを見続けてしまい、「自動ローテーションしたのに新しい鍵が使われない」ことになります。自動更新の恩恵を受けたいなら、バージョンを固定しない参照にしておく——これを覚えておくだけで、後々の事故がぐっと減ります。
証明書を作成・インポートし、自動更新を構成する
最後は証明書です。冒頭で「はんこ（キー）に公的な保証書を貼り付けたもの」と表現しました。HTTPSでサーバーの身元を証明するのに使う、あのSSL/TLS証明書のことです。証明書はキーとメタデータがセットになっているため、Key Vaultで証明書を作ると、対応するキーとシークレットも裏側で一緒に管理されます。
作成する：自己署名 or 手持ちのPFX/PEMをインポート
証明書をKey Vaultに用意する道は、大きく2つあります。
1つ目はKey Vault上で新しく作る（生成）方法。学習や社内検証なら、まず自己署名証明書が手軽です。ポータルで「証明書」→「生成/インポート」→「生成」を選び、証明機関（CA）に「自己署名証明書」を指定します。ちなみに自己署名は「自分で自分に発行した保証書」なので、外部からは信頼されません。本番の公開サイトには使えず、あくまで検証用と割り切ってください。
2つ目はすでに持っている証明書をインポートする方法。他所で発行してもらった PFX（.pfx／秘密鍵込み） や PEM のファイルを取り込みます。CLIならこの一行です。
az keyvault certificate import \
--vault-name myVault \
--name MyTlsCert \
--file mycert.pfx \
--password "PfxPassword"--file に証明書ファイル、PFXにパスワードが掛かっていれば --password で渡します。取り込んだ証明書は、App ServiceやApplication Gatewayなどから参照して、TLSの終端に使えます。ここまでは「金庫にしまう」だけなので難しくありません。本題は次です。
自動更新（統合CA連携）：期限切れの事故を根絶する
証明書には必ず有効期限があります。そして現場で本当によく起きる事故が、証明書の期限切れによるサイト停止です。「ある朝いきなりHTTPSがエラーになって大騒ぎ、原因は証明書の更新忘れ」——エンジニアなら一度は聞いたことがあるはずの、古典的かつ致命的なやつです。
Key Vaultは、これを仕組みで防ぐために統合CA（証明機関）連携による自動更新を用意しています。具体的には DigiCert や GlobalSign といった対応CAをKey Vaultにアカウント登録しておくと、証明書の発行から期限前の自動更新までKey Vaultが代行してくれるのです。人が更新作業をしなくても、期限が近づくと裏で勝手に新しい証明書に差し替わる。冒頭の「金庫が世代交代を自動でやってくれる」の証明書版ですね。
設定の流れはこうです。まずKey Vaultの「証明書」→「証明機関」で、DigiCertなどのCAアカウント情報（アカウントID・組織情報・APIキーなど、CA側で発行される認証情報）を登録します。次に証明書を新規作成する際、CAとして「自己署名」ではなく登録したそのCAを選びます。そのうえで、証明書のポリシーで「有効期間の○%を過ぎたら自動更新」あるいは「期限の○日前に自動更新」を指定しておく。これで準備は完了で、あとはKey Vaultが期限を見張って更新まで面倒を見てくれます。
ここで運用上のつまずきどころを2つ挙げておきます。1つ目は統合CAとの連携が使えるのは、その連携パートナーCA（DigiCert・GlobalSignなど）で発行する場合に限られること。他のCAで手動発行した証明書を「インポート」しただけの場合、Key Vaultは中身を知らないので完全な自動更新まではやってくれず、期限が近いと警告を出すにとどまります。この場合は自分で新しい証明書をインポートし直す運用になります。
2つ目は、更新されても証明書名は同じまま、新しいバージョンとして差し替わるという点。ここでも一貫してバージョンモデルが効いています。だから、App ServiceやApplication Gatewayから証明書を参照するときは、キーと同じくバージョンを固定せずに参照しておくのが鉄則です。バージョンを決め打ちすると、せっかく自動更新されても古い証明書を掴み続けて、結局期限切れ事故に逆戻り——という笑えない事態になります。
キーも証明書も、自動更新の恩恵を受ける条件は共通で「バージョンを固定しない参照」。ここだけは繰り返す価値があります。
まとめ
この記事では、Key Vaultの3つのオブジェクトを実際に作って・取り出して・更新するところまでを、運用でつまずく順に見てきました。要点を振り返っておきます。
- 大前提：シークレットは取り出して使うメモ、キーは取り出さず金庫の中で使うはんこ。この違いがすべての土台。
- シークレット：
secret setで作成、secret showで取得。同名で更新しても古いバージョンは残るので、いつでも前の値に戻せる。 - キー：種類はRSA（汎用の定番）とEC（署名向けで効率的）。ローテーションポリシーで有効期限と自動ローテーション間隔を設定し、期限前に自動で世代交代させる。
- 証明書：自己署名は検証用、本番はPFX/PEMインポートか統合CA発行。DigiCert/GlobalSign連携なら期限前の自動更新までKey Vaultが代行し、期限切れ事故を根絶できる。
- 共通の鉄則：キーも証明書も、自動更新の恩恵を受けるにはバージョンを固定しない参照にしておくこと。
ここまでできれば、「Key Vaultの中身を自分で作り、安全に更新し続ける」という運用の基礎は固まりました。次に気になるのは、そもそも誰がこの金庫を開けられるのかという制御の話や、アプリからパスワードなしで安全にアクセスする方法でしょう。そのあたりは下の姉妹記事で扱っています。
あわせて読みたい：
