Azure Key Vaultのネットワーク閉域と運用｜Private Endpoint・監査ログ・バックアップ・アラート

Key Vaultにシークレットやキーを入れ、アクセス制御まで整えたとします。それでも、金庫がインターネットから丸見えのままだと、本番の——とくに金融・医療・公共といった規制の厳しい現場では——「これでは要件を満たせない」と差し戻されます。金庫の中身をどれだけ厳重に管理しても、金庫そのものが誰でもアクセスできる場所に置いてあれば意味が薄いからです。

私は普段、Azureで閉域ネットワーク（外から直接触れない構成）を設計する仕事をしていて、Key Vaultの閉域化は毎回のように出てくるテーマです。そして毎回、初めての人が同じ場所でつまずくのを見てきました。Private Endpointを作ったのに、なぜかつながらない。原因はほぼ100%、名前解決（DNS）です。この記事は、そのハマり所を先回りして潰しにいきます。

「ファイアウォールとPrivate Endpointって何が違うの？Private DNS Zoneって結局なんのために要るの？監査ログやバックアップって、どこから手をつければいいの？」

この記事では、Key Vaultをネットワークで閉じ込め（ファイアウォール／Private Endpoint／Private DNS Zone）、さらに保存時暗号化の考え方・監査ログ・バックアップ／復元・アラート監視までを、公式Microsoft Learnの内容を実務目線で噛み砕いて解説します。これはKey Vault実務シリーズの締めの記事です。読み終わるころには、Key Vaultを「規制業種でも通用する堅牢さ」で運用する道筋が頭に入ります。

なお、そもそもKey Vaultの全体像があやふやな方は、先に Azure Key Vaultとは？シークレット・キー・証明書を安全に管理する仕組みに目を通しておくと、この記事の位置づけがはっきりします。本記事はそのハブ記事の実務シリーズの一本です。

まず全体像：Key Vaultを「閉じる」3段階
ファイアウォール：IPと仮想ネットワークで入口を絞る
Private Endpointで閉域化する（本番の本命）
最大のつまずき所：Private DNS Zoneでの名前解決
保存時暗号化の考え方：キー階層とエンベロープ暗号化
監査ログ：誰がいつアクセスしたかを残す
バックアップと復元：金庫の中身を別ボールトへ退避する
アラートと監視：期限切れ・異常アクセスを検知する
まとめ：規制業種でも通用するKey Vault運用へ
あわせて読みたい

まず全体像：Key Vaultを「閉じる」3段階

手を動かす前に、ネットワーク面で何をやるのかを整理しておきます。Key Vaultはデフォルトだとパブリックエンドポイント（インターネット越しに到達できる入口）を持っていて、認証さえ通れば理屈上どこからでもアクセスできます。認証・認可（RBAC）で守られてはいますが、規制業種では「そもそもネットワーク的に届かないようにしておく」ことが求められます。

閉じ方には段階があります。マンションの入口にたとえると分かりやすいです。

ファイアウォール（IP／仮想ネットワーク制限）：エントランスに「この住所リストの人だけ入れます」という受付を置くイメージ。パブリックの入口は残しつつ、通してよい相手を絞る。
Private Endpoint（プライベートエンドポイント）：そもそも公道からエントランスを消し、建物内の専用通路からしか入れなくするイメージ。金庫を自分の仮想ネットワークの中に引き込む。
Private DNS Zone（プライベートDNSゾーン）：その専用通路への「正しい行き先案内板」。これが無いと、専用通路を作っても入居者が入口の場所を間違えて表玄関（パブリック）に迷い込む。

本番の堅牢な構成のゴールは、パブリックアクセスを完全に無効化し、Private Endpoint経由でのみアクセスさせ、DNSで正しくプライベートIPへ誘導する——この3つがそろった状態です。まずは軽いファイアウォールから見ていきます。

ファイアウォール：IPと仮想ネットワークで入口を絞る

いちばん手軽な第一歩が、Key Vaultのファイアウォール設定です。ポータルでKey Vaultを開き、「設定」→「ネットワーク」→「ファイアウォールと仮想ネットワーク」を見ると、アクセスの許可範囲を選ぶ画面があります。ここでの選択肢は大きく次の3つです。

すべてのネットワークからのアクセスを許可：デフォルト。パブリックに開いている状態。
選択したネットワークからのアクセスを許可：許可するIPアドレス範囲（CIDR）や、特定の仮想ネットワーク／サブネットだけを通す。
パブリックアクセスを無効化：パブリックの入口を閉じ、Private Endpoint経由でしか入れなくする（本番の理想形）。

「選択したネットワーク」を選ぶと、ファイアウォール欄で許可するパブリックIPを追加できます。たとえば会社オフィスの固定グローバルIPや、自分の作業環境のIPを入れておけば、「この場所からのアクセスだけ通す」という受付リストが作れます。CLIならこう書きます。

# デフォルトの動作を「拒否」にする（許可リストに無い相手は弾く）
az keyvault update \
  --name ait0303-kv \
  --resource-group myResourceGroup \
  --default-action Deny

# 許可するパブリックIP（CIDR）を追加
az keyvault network-rule add \
  --name ait0303-kv \
  --resource-group myResourceGroup \
  --ip-address 203.0.113.10/32

# 許可する仮想ネットワーク／サブネットを追加
az keyvault network-rule add \
  --name ait0303-kv \
  --resource-group myResourceGroup \
  --subnet /subscriptions/xxxx/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVnet/subnets/appSubnet

各オプションの意味はこうです。

--default-action Deny：許可リストに無いアクセスをすべて拒否する。これを設定して初めて「絞り込み」が効きます。Allowのままだとルールを足しても素通しなので要注意。
network-rule add --ip-address：通してよいパブリックIP／CIDRを登録。/32は単一IPの指定。
network-rule add --subnet：通してよいサブネットを登録。指定サブネットには後述のサービスエンドポイントが必要です。

ここで一つ実務的な注意です。「選択したネットワーク」でIP制限をかけても、それはパブリックの入口を”絞っている”だけで、”閉じている”わけではありません。入口自体は残っているので、規制要件で「パブリック無効」が求められる場合は、この後のPrivate Endpointまで進む必要があります。IP制限は手軽な反面、オフィスIPが変わるたびにメンテが要る、リモートワークだと管理しづらい、という弱点もあります。ファイアウォールは”軽い防御”、本命はPrivate Endpointと位置づけておくとよいです。

「信頼されたMicrosoftサービスを許可」という例外

ファイアウォールを絞ると、地味だけれど重要なチェックボックスが出てきます。「信頼されたMicrosoftサービスがこのファイアウォールをバイパスすることを許可する」です。これは何かというと、Azureの正規サービスからのアクセスだけは、ファイアウォールの許可リストに関係なく通すという例外の穴です。

なぜこの例外が要るのか。たとえばストレージアカウントを「顧客管理キー（自分のKey Vaultのキーで暗号化）」で守るとき、ストレージ側がKey Vaultのキーを取りに来ます。あるいはApp ServiceがKey Vault参照でシークレットを読みに来る。こうしたAzure内部のサービス連携は、決まったパブリックIPを持たないことが多く、IP許可リストで通そうとしても現実的に無理です。そこで「Microsoftの信頼済みサービスなら通す」という例外で連携を成立させます。

ポイントは、これは”全Azureサービス”を無条件で通す穴ではないことです。Microsoftが「信頼済み」として明示的にリスト化したサービス（Storage、App Service、Azure Backup、Event Gridなど）だけが対象で、しかも多くは対象リソースにマネージドIDが割り当てられていることが前提になります。「なんでも通る抜け道」ではなく「正規の内部連携専用の通用口」と理解しておくと、必要以上に怖がらずに済みます。ファイアウォールを絞ったらAzureサービス連携が急に動かなくなった——という時は、まずこのチェックを疑ってください。

「ファイアウォールで絞ったら連携が止まった」の犯人は、たいてい”信頼されたMicrosoftサービスを許可”のチェック忘れです。

Private Endpointで閉域化する（本番の本命）

いよいよ本命のPrivate Endpoint（プライベートエンドポイント）です。これはKey Vaultへの入口を、自分の仮想ネットワーク（VNet）の中にプライベートIPとして生やす仕組みです。金庫の受付窓口が、公道（インターネット）ではなく自分の建物の廊下に移設される、というイメージです。これでパブリックの入口を完全に閉じても、VNet内のアプリからはプライベートIP経由でアクセスできます。

作成の考え方はシンプルで、「Key Vault用のPrivate Endpointを、指定したサブネットに作る」だけです。CLIで書くとこうなります。

# Key Vault のリソースIDを取得
KV_ID=$(az keyvault show --name ait0303-kv \
  --resource-group myResourceGroup --query id -o tsv)

# Private Endpoint を作成（対象は vault というサブリソース）
az network private-endpoint create \
  --name kv-private-endpoint \
  --resource-group myResourceGroup \
  --vnet-name myVnet \
  --subnet peSubnet \
  --private-connection-resource-id "$KV_ID" \
  --group-id vault \
  --connection-name kv-connection

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

--vnet-name / --subnet：Private Endpointを生やすVNetとサブネット。ここに指定したサブネットの中に、Key Vault用のプライベートIP（ネットワークインターフェース）が作られます。
--private-connection-resource-id：接続先のKey VaultのリソースID。
--group-id vault：接続するサブリソースの指定。Key Vaultの場合は vault です。ここを間違えると正しくつながりません。

作成できたら、パブリックアクセスを無効化して閉域を完成させます。

# パブリックアクセスを無効化（Private Endpoint 経由のみに）
az keyvault update \
  --name ait0303-kv \
  --resource-group myResourceGroup \
  --public-network-access Disabled

これで、Key Vaultはパブリックからは一切見えなくなり、Private Endpointを置いたVNet（およびそことつながったネットワーク）からのプライベートIP接続だけを受け付ける状態になります。規制業種で求められる「パブリック無効」の要件は、ここまでやって初めて満たせます。

なお、そもそも「サービスエンドポイント」と「プライベートエンドポイント」がごっちゃになっている方は、両者の違いを整理したサービスエンドポイントとプライベートエンドポイントの違いを先に読むと、この章の理解が一段深まります。ざっくり言えば、サービスエンドポイントは「VNetからパブリックの入口へ安全に出ていく通用口」、プライベートエンドポイントは「サービスの入口をVNetの中に引き込む」もので、閉域の本命は後者です。

最大のつまずき所：Private DNS Zoneでの名前解決

ここが、冒頭で「原因はほぼ100%DNS」と書いた核心です。Private Endpointを作ってパブリックを無効化したのに、アプリから ait0303-kv.vault.azure.net にアクセスするとタイムアウトや接続拒否になる。犯人は名前解決です。何が起きているのか、順を追って説明します。

なぜPrivate Endpointだけでは足りないのか

Key VaultのURLは、閉域化しても ait0303-kv.vault.azure.net のまま変わりません。アプリはこの名前をDNSに問い合わせて、返ってきたIPアドレスへ接続します。ところが、DNSに何も手を打たないと、この名前はパブリックのIPアドレスを返してきます。せっかくVNet内にプライベートIPの入口を作ったのに、アプリは「表玄関（パブリックIP）」の住所を教えられ、そこへ向かう。でもパブリックは無効化してあるので届かない——これが接続失敗の正体です。

ここで登場するのが特殊なドメイン privatelink.vaultcore.azure.net です。AzureのPrivate Link対応サービスは、裏側で vault.azure.net の名前を privatelink.vaultcore.azure.net へCNAME（別名）で転送するようになっています。そして、この privatelink.vaultcore.azure.net をプライベートDNSゾーンとしてVNetにひも付け、「この名前ならプライベートIPを返す」と教え込むことで、初めてアプリがプライベートIPへ正しくたどり着けるようになります。

案内板の例えに戻すと、こうです。廊下の中に専用窓口（Private Endpoint）を作った。でも入居者向けの案内板（DNS）を更新し忘れているので、みんな古い案内に従って表玄関（パブリック）へ歩いていく。privatelink.vaultcore.azure.net のプライベートDNSゾーンは、その「新しい窓口はこちら」と書き換えた正しい案内板なのです。

Private DNS Zoneを構成する手順

やることは3ステップです。①プライベートDNSゾーンを作る→②アプリのいるVNetにリンクする→③Private EndpointのIPをゾーンに登録する。CLIならこう流れます。

# ① プライベートDNSゾーンを作成（名前は固定でこれ）
az network private-dns zone create \
  --resource-group myResourceGroup \
  --name privatelink.vaultcore.azure.net

# ② アプリのいるVNetにゾーンをリンク（名前解決を効かせる）
az network private-dns link vnet create \
  --resource-group myResourceGroup \
  --zone-name privatelink.vaultcore.azure.net \
  --name kv-dns-link \
  --virtual-network myVnet \
  --registration-enabled false

# ③ Private Endpoint と DNS ゾーンを自動でひも付け（Aレコード自動登録）
az network private-endpoint dns-zone-group create \
  --resource-group myResourceGroup \
  --endpoint-name kv-private-endpoint \
  --name kv-zone-group \
  --private-dns-zone privatelink.vaultcore.azure.net \
  --zone-name vault

各ステップの勘どころです。

ゾーン名は privatelink.vaultcore.azure.net で固定。ここを vault.azure.net などと書き間違えると効きません。Key Vaultだけこの「vaultcore」という綴りなのが引っかかりやすいポイントです。
VNetリンクを忘れない（②）。ゾーンを作っただけでは、そのVNetの中の名前解決に反映されません。「ゾーンは作ったのに直らない」時は、たいていリンク漏れです。
dns-zone-group（③）を使うと、Aレコードの登録・更新が自動になります。Private EndpointのプライベートIPが変わっても追従してくれるので、手動でAレコードを打つより安全。ここは自動化しておくのが定石です。

設定後は、VNet内のVMやApp Serviceから実際に名前解決を確認しておくと安心です。nslookup ait0303-kv.vault.azure.net を打って、返ってくるIPが 10.x.x.x のようなプライベートIPになっていればOK。パブリックIP（グローバルなアドレス）が返ってくるなら、まだDNSが効いていません。閉域トラブルの切り分けは、まずこの nslookup から始めるのが鉄則です。

Private Endpointの閉域が「つながらない」時、9割は「ゾーン名の綴り違い」か「VNetリンク忘れ」。まず nslookup でプライベートIPが返るか確認しましょう。

ちなみに、オンプレミスや別のVNetから閉域のKey Vaultを引きたい場合は、そのネットワークからも privatelink.vaultcore.azure.net の名前解決が届くようにDNS転送を設計する必要があります。ハブ＆スポーク構成での閉域DNS設計は奥が深いので、VNet側の全体像は Azure VNet入門⑥ Private接続とセキュリティ運用で押さえておくと、Key Vault以外のサービスにも応用が効きます。

保存時暗号化の考え方：キー階層とエンベロープ暗号化

ネットワークで閉じたら、次は「そもそもデータはどう暗号化されているのか」という土台の理解です。ここを押さえると、Key Vaultのキーが実務でどんな役割を果たすのかが腑に落ちます。キーワードはエンベロープ暗号化（封筒式の暗号化）です。

Azureのストレージやデータベースは、保存されたデータを必ず暗号化しています（保存時暗号化）。このとき、データを直接暗号化する鍵をデータ暗号化キー（DEK）、そのDEKを暗号化して守る上位の鍵をキー暗号化キー（KEK）と呼びます。Key Vaultに置くのは、このKEK（上位の鍵）です。つまりKey Vaultのキーは、データそのものではなく「データを守る鍵を、さらに守る鍵」なのです。

手紙の封筒でたとえると分かりやすいです。手紙（データ）を封筒（DEK）に入れて封をする。その封筒を、さらに鍵付きの箱（KEK＝Key Vaultのキー）にしまう。箱の鍵を持っている人だけが封筒を取り出せる。この二段構えがエンベロープ暗号化です。何が嬉しいかというと、大量のデータを再暗号化しなくても、上位のKEKを差し替える／無効化するだけで、全データへのアクセスを止められる点です。鍵をKey Vaultから消せば、下位のDEKは復号できなくなり、事実上データが読めなくなる——強力な緊急停止スイッチになります。

この「自分のKEKで守る」構成が、Key Vaultとハブ記事でも触れた顧客管理キー（CMK）です。Azureが用意した鍵（Microsoft管理キー）で十分な場合も多いですが、規制で「鍵の統制を自社で握る」ことが求められる現場では、Key VaultのキーをKEKに指定します。Key Vaultのキーが、組織全体の暗号化の”要”になる——このイメージを持っておくと、なぜKey Vaultの削除保護や監査がここまで重視されるのかが一本の線でつながります。詳しくは公式の保存データの暗号化も参照してください。

監査ログ：誰がいつアクセスしたかを残す

規制業種でKey Vaultを使う以上、避けて通れないのが監査ログ（診断ログ）です。「いつ・誰が・どのシークレットに・何をしたか」を記録し、あとから追跡できる状態にしておく。これが無いと、いざインシデントが起きたときに「誰が触ったのか分かりません」となり、監査に通りません。

Key Vault自体はログを勝手に貯めてくれるわけではなく、診断設定（Diagnostic Settings）で「ログをどこに送るか」を明示的に構成する必要があります。送り先は主に、分析・アラート向けのLog Analyticsワークスペース、長期保管向けのストレージアカウント、リアルタイム連携向けのEvent Hubから選べます。実務では「Log Analyticsに送って検索・アラートに使い、必要なら長期保管でストレージにも」という組み合わせが定番です。

# 監査ログを Log Analytics ワークスペースへ送る診断設定
az monitor diagnostic-settings create \
  --name kv-audit \
  --resource "$KV_ID" \
  --workspace <Log Analytics ワークスペースのリソースID> \
  --logs '[{"category":"AuditEvent","enabled":true}]'

ここでのカテゴリ AuditEvent が、Key Vaultへのアクセス操作（シークレットの取得、キーの署名操作など）を記録する肝心のログです。送り先をLog Analyticsにしておくと、KQL（クエリ言語）で「特定シークレットへのアクセス履歴」や「失敗したアクセス」を検索でき、次章のアラートにもそのまま使えます。たとえば AzureDiagnostics | where ResourceType == "VAULTS" のようなクエリで、誰がどのオブジェクトにアクセスしたかを一覧できます。

一つ実務の注意です。診断設定はKey Vaultを作った”後で”必ず入れるもので、デフォルトではオフです。「作ったその日から全操作を記録できていること」が監査では効いてくるので、閉域化とセットで、Key Vaultを立てたら真っ先に診断設定を入れるのを運用の型にしておくとよいです。

バックアップと復元：金庫の中身を別ボールトへ退避する

論理削除・パージ保護（ハブ記事で解説）があるとはいえ、個々のオブジェクト（シークレット・キー・証明書）を明示的にバックアップしたい場面もあります。たとえば「別リージョンのKey Vaultへ複製したい」「重要なキーを手元の保管手順に含めたい」といったケースです。Key VaultはCLIで、オブジェクト単位のバックアップ／復元を提供しています。

# キーをバックアップ（暗号化されたBlobファイルとして書き出す）
az keyvault key backup \
  --vault-name ait0303-kv \
  --name my-encryption-key \
  --file my-key-backup.blob

# 別のKey Vaultへ復元する
az keyvault key restore \
  --vault-name ait0303-kv-dr \
  --file my-key-backup.blob

# シークレットも同様にバックアップ／復元できる
az keyvault secret backup --vault-name ait0303-kv --name db-connection --file db-secret.blob
az keyvault secret restore --vault-name ait0303-kv-dr --file db-secret.blob

使うときの重要なクセを押さえておきましょう。

バックアップで書き出される .blob ファイルはAzure側で暗号化されており、中身を人間が読むことはできません。あくまで「Key Vaultへ戻すための封印された退避ファイル」です。
復元先には制約があります。基本的に同じAzureサブスクリプションかつジオグラフィ（地理的リージョン群）内の別Key Vaultにしか復元できません。「日本で取ったバックアップを海外リージョンのVaultへ」といった越境復元は原則できない、と覚えておいてください。
これはオブジェクト単位の退避であって、Key Vault全体を丸ごとエクスポートする機能ではありません。数が多い本番では、Terraformなどで構成をコード管理し、値はこのbackup/restoreで扱う、という組み合わせが現実的です。

災害対策（DR）の観点では、「本番Vaultとは別リージョンにDR用Vaultを用意し、重要オブジェクトを定期的にbackup/restoreで同期する」といった設計が取れます。ただ、越境の制約があるため、DRリージョンの選定はジオグラフィを意識して行う必要があります。ここは要件次第なので、まず「オブジェクト単位で別Vaultへ退避できる」という手段を引き出しに入れておけば十分です。

アラートと監視：期限切れ・異常アクセスを検知する

締めはアラート（監視）です。どれだけ堅牢に組んでも、「証明書の有効期限が切れてサービス停止」「深夜に見慣れないアクセスが大量発生」を気づけなければ意味がありません。運用の最後のピースは「異常に自動で気づく仕組み」です。

Key Vaultの監視でとくに効くのは、次の2種類のアラートです。

有効期限が近いことの検知：証明書やキー、シークレットの有効期限切れは、本番停止の定番事故です。Key Vaultは有効期限が近づいたことをEvent Gridのイベント（Microsoft.KeyVault.SecretNearExpiry など）として発行できるので、これを拾ってメールやTeamsに通知する。「切れる前に気づいて更新」を自動化できます。
異常なアクセスの検知：前章の監査ログ（Log Analytics）を土台に、Azure Monitorのメトリックアラートやログアラートを組みます。たとえば「短時間に一定回数以上のアクセス失敗（401/403）が出たら通知」「想定外のIDからのアクセスを検知」といったルールです。

アラートの通知先はアクショングループという仕組みでまとめて管理します。メール・SMS・Webhook・Teams連携などをアクショングループに登録しておき、複数のアラートから共通で呼び出す形です。CLIでメトリックアラートを作る例を示します。

# 通知先のアクショングループを作成（メール通知）
az monitor action-group create \
  --name kv-alerts \
  --resource-group myResourceGroup \
  --short-name kvalert \
  --action email admin admin@example.com

# 例：Key Vault の API 応答（失敗）が閾値を超えたら通知するメトリックアラート
az monitor metrics alert create \
  --name kv-availability-alert \
  --resource-group myResourceGroup \
  --scopes "$KV_ID" \
  --condition "avg Availability < 100" \
  --action kv-alerts

ここでの考え方は「Key VaultのAvailability（可用性）やSaturation（スロットリング）などのメトリックを監視し、閾値を割ったらアクショングループ経由で通知する」というものです。有効期限系はEvent Gridベース、アクセス異常系はログ／メトリックベース、と系統が分かれるので、「期限切れ＝Event Grid」「異常アクセス＝Monitorアラート」と役割で覚えておくと設計がぶれません。

細かいメトリック名やイベントスキーマは変わることがあるので、実際に組むときは公式の Key Vaultの監視とアラートで最新を確認してください。この記事では「監視すべき2系統（期限・異常アクセス）」と「アクショングループで通知先をまとめる」という骨格をつかんでおけば十分です。

まとめ：規制業種でも通用するKey Vault運用へ

この記事では、Key Vaultを本番の堅牢さで運用するためのネットワーク閉域＋運用を通しで見てきました。要点を振り返ります。

ファイアウォール：IP／仮想ネットワークで入口を絞る”軽い防御”。default-action Denyで初めて効く。「信頼されたMicrosoftサービスを許可」はAzure内部連携用の正規の通用口。
Private Endpoint：VNet内にプライベートIPの入口を引き込み、パブリックを無効化する本命の閉域化。--group-id vaultがポイント。
Private DNS Zone：閉域最大のつまずき所。privatelink.vaultcore.azure.netゾーンを作り、VNetにリンクし、Aレコードを自動登録。切り分けはまずnslookupでプライベートIPが返るか。
保存時暗号化：エンベロープ暗号化で、Key Vaultのキー（KEK）がデータ暗号化キー（DEK）を守る。鍵を消せば全データを実質停止できる要の存在。
監査ログ：診断設定でAuditEventをLog Analytics／ストレージへ。作ったら真っ先に入れる。
バックアップ／復元：オブジェクト単位で別Vaultへ退避。同一サブスク・同一ジオ内という制約に注意。
アラート：「期限切れ＝Event Grid」「異常アクセス＝Monitorアラート」、通知はアクショングループで集約。

ここまでを組み合わせると、Key Vaultはパブリックから見えず、内部連携は成立し、全アクセスが記録され、異常には自動で気づき、消えても戻せる——という、金融・医療・公共といった規制の厳しい現場でも通用する堅牢な状態になります。これがKey Vault実務シリーズの到達点です。あとは案件の要件に合わせて、どこまでの段階を採用するかを選ぶだけ。閉域とDNSさえ自分で切り分けられれば、Key Vaultの運用でもう迷うことはありません。