Azure Key Vaultで実践するシークレット管理とセキュリティ設計

接続文字列や API キー、証明書といった機密情報をアプリケーションの構成ファイルやリポジトリに直接置く運用は、漏えいのリスクと監査対応の負担を同時に抱え込みます。Azure Key Vault は、これらの機密情報を集中管理し、アクセスを認可・記録するためのマネージドサービスです。本記事では、2026年時点で推奨される構成を前提に、RBAC によるアクセス制御、マネージド ID を使ったキーレスなアクセス、Private Endpoint によるネットワーク保護、そしてローテーションと監査までを、C# / Azure CLI / Bicep の実装例とともに整理します。

Key Vault が扱う3種類のオブジェクト

Key Vault が管理する対象は、シークレット・キー・証明書の3種類に分かれます。それぞれ用途とアクセス方法が異なるため、まず区別を押さえておきます。

• シークレット — 接続文字列や API キー、パスワードなど任意の文字列を格納します。バージョン管理され、値は取得時に平文で返されます。
• キー — RSA / EC などの暗号鍵を格納します。原則として鍵素材は外部に出さず、署名や暗号化の操作を Key Vault 側で実行します。より強い保護が必要な場合は HSM 保護（Managed HSM を含む）を選択します。
• 証明書 — X.509 証明書を、対応する秘密鍵およびメタデータと一体で管理します。発行や更新のライフサイクルを Key Vault に委ねられる点が特徴です。

いずれもデータプレーンの操作（値の読み書き）と、コントロールプレーンの操作（コンテナー自体の作成や構成変更）で認可の経路が分かれます。この分離を意識すると、権限設計が整理しやすくなります。

RBAC によるアクセス制御

Key Vault のデータプレーンへのアクセスは、従来のアクセスポリシーと、Azure RBAC の2方式があります。現在は Azure RBAC の利用が推奨されます。ロール定義を Azure 全体の権限モデルと統一でき、リソースグループやサブスクリプション単位での継承、条件付きアクセスや PIM との組み合わせが利用できるためです。アクセスポリシーは Vault 単位で主体ごとの許可を列挙する方式で、規模が大きくなると管理が煩雑になりがちです。

代表的な組み込みロールとして、シークレット読み取り専用の Key Vault Secrets User、シークレット管理の Key Vault Secrets Officer、キー操作の Key Vault Crypto User、証明書管理の Key Vault Certificates Officer があります。アプリケーションには読み取り専用ロールのみを最小スコープで割り当てるのが基本方針です。

新規に Vault を作成し、RBAC を有効化する例を示します。

az keyvault create \
  --name kv-contoso-prod \
  --resource-group rg-contoso-prod \
  --location japaneast \
  --enable-rbac-authorization true \
  --sku standard

# アプリのマネージドIDに読み取り専用ロールを割り当てる
az role assignment create \
  --assignee-object-id "$PRINCIPAL_ID" \
  --assignee-principal-type ServicePrincipal \
  --role "Key Vault Secrets User" \
  --scope "$(az keyvault show --name kv-contoso-prod --query id -o tsv)"

--enable-rbac-authorization true を指定すると、その Vault では RBAC が認可の起点になります。ロールを割り当てる主体は個々のユーザーではなく、後述するマネージド ID を基本とします。

マネージド ID によるキーレスなアクセス

アプリケーションから Key Vault にアクセスする際、資格情報そのものを持たせないことが安全設計の要点です。マネージド ID を使えば、Key Vault へアクセスするためのクライアントシークレットを別途どこかに保管する、という本末転倒を避けられます。Entra ID が発行するトークンで認証するため、アプリ側に長期資格情報を置く必要がありません。

.NET では Azure.Identity の DefaultAzureCredential を用いると、ローカル開発では開発者の資格情報、Azure 上ではマネージド ID を自動的に使い分けられます。

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

var vaultUri = new Uri("https://kv-contoso-prod.vault.azure.net/");
var client = new SecretClient(vaultUri, new DefaultAzureCredential());

KeyVaultSecret secret = await client.GetSecretAsync("Sql-ConnectionString");
string connectionString = secret.Value;

SecretClient は内部でトークンをキャッシュするため、毎回のリクエストで認証が走るわけではありません。一方でシークレット値の取得は都度ネットワーク往復を伴うため、起動時にまとめて読み込む、あるいは構成プロバイダー経由でキャッシュする設計が適します。次のように Microsoft.Extensions.Configuration.AzureKeyVault 相当の拡張を使えば、構成システムに統合できます。

var builder = WebApplication.CreateBuilder(args);

builder.Configuration.AddAzureKeyVault(
    new Uri("https://kv-contoso-prod.vault.azure.net/"),
    new DefaultAzureCredential());

var app = builder.Build();
// builder.Configuration["Sql-ConnectionString"] で参照できる

この方式では、Key Vault 上のシークレット名がそのまま構成キーになります。-- を区切り文字にすると Section:Key のような階層キーへマッピングされるため、既存の構成体系と揃えやすくなります。

Private Endpoint とネットワーク制限

既定の Key Vault はパブリックエンドポイントを持ちます。本番環境では、ネットワーク境界での保護を追加するのが望ましい構成です。方法は大きく2段階に分けて考えられます。

ひとつはファイアウォールによる制御で、既定の公開アクセスを拒否したうえで、特定の仮想ネットワークのサブネットや信頼された Azure サービスのみを許可します。もうひとつが Private Endpoint で、Vault への接続を仮想ネットワーク内のプライベート IP に閉じ、経路をインターネットから切り離します。Private Endpoint を利用する場合は、privatelink.vaultcore.azure.net のプライベート DNS ゾーンを構成し、名前解決がプライベート IP に向くようにします。

Bicep での Vault 定義と、公開アクセスを既定拒否にする例を示します。

resource vault 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: 'kv-contoso-prod'
  location: location
  properties: {
    tenantId: subscription().tenantId
    sku: { family: 'A', name: 'standard' }
    enableRbacAuthorization: true
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
    enablePurgeProtection: true
    publicNetworkAccess: 'Disabled'
    networkAcls: {
      defaultAction: 'Deny'
      bypass: 'AzureServices'
    }
  }
}

Private Endpoint 経由でアプリを接続する場合は、アプリ側も同じ仮想ネットワークに統合しておく必要があります。App Service や Functions では仮想ネットワーク統合、Container Apps では専用の環境を仮想ネットワークに配置することで、プライベート経路が成立します。

ソフトデリートとパージ保護、そしてローテーション

誤削除と悪意ある削除への備え

ソフトデリートは、削除したオブジェクトや Vault 自体を保持期間中は復元可能な状態で残す機能で、現在は無効化できません。保持期間は7〜90日の範囲で設定します。さらにパージ保護を有効にすると、保持期間の満了前に完全削除（パージ）を行えなくなり、権限を持つ主体による即時削除も防げます。本番環境ではパージ保護の有効化を基本とします。前掲の Bicep では enablePurgeProtection: true と softDeleteRetentionInDays: 90 で両者を設定しています。

証明書とキーのローテーション

証明書は、統合された CA（DigiCert など）を発行元として登録すれば、有効期限が近づいた時点での自動更新を構成できます。自己署名や手動発行の証明書でも、ライフサイクルポリシーで更新のタイミングとアラートを設定しておくことで、期限切れによる停止を予防できます。

# 有効期間の残り30日で自動更新するポリシーを設定
az keyvault certificate create \
  --vault-name kv-contoso-prod \
  --name cert-www-contoso \
  --policy "$(az keyvault certificate get-default-policy)"

# 既存キーに自動ローテーションポリシーを付与
az keyvault key rotation-policy update \
  --vault-name kv-contoso-prod \
  --name key-data-encryption \
  --value @rotation-policy.json

キーについても、ローテーションポリシーで自動的に新しいバージョンを生成できます。アプリケーションが最新バージョンを参照するようにしておけば、ローテーション後もコード変更なしで新しい鍵を利用できます。シークレット（接続文字列など）のローテーションは、Event Grid の有効期限イベントと Functions を組み合わせて、資格情報の再生成と Vault への書き戻しを自動化する構成が一般的です。

App Service / Functions / Container Apps からの Key Vault 参照

アプリケーションコードから SecretClient を呼ぶ以外に、プラットフォーム側の機能でシークレットを注入する方法があります。App Service と Functions では、アプリ設定の値に Key Vault 参照構文を書くと、実行時に Vault から解決された値が環境変数として渡されます。

az webapp config appsettings set \
  --name app-contoso \
  --resource-group rg-contoso-prod \
  --settings "SqlConnection=@Microsoft.KeyVault(SecretUri=https://kv-contoso-prod.vault.azure.net/secrets/Sql-ConnectionString/)"

この参照が機能するには、App Service または Functions にシステム割り当てのマネージド ID を有効化し、その ID に Key Vault Secrets User を割り当てておく必要があります。Container Apps では、シークレットの値として Key Vault 参照を指定し、環境変数へマッピングする方式が利用できます。いずれの場合も、アプリのコードには Vault の URL とシークレット名だけが現れ、値そのものは持ちません。

コードで直接参照する方式とプラットフォーム参照のどちらを選ぶかは、更新の即時性で判断します。プラットフォーム参照は起動時やアプリ設定更新時に解決されるため、ローテーション直後に反映したい場合はアプリの再起動が必要になることがあります。実行中の即時反映が要件なら、構成プロバイダー経由でリロード可能な形にするか、コードから明示的に再取得する設計を選びます。

Key Vault と App Configuration の使い分け

Key Vault はあくまで機密情報の保管庫であり、機能フラグや非機密の設定値を大量に扱う用途には向きません。そうした構成値の集中管理には Azure App Configuration が適します。両者は排他ではなく、組み合わせて使うのが実務上の定石です。

非機密の構成値は App Configuration に置き、接続文字列やキーなどの機密値は Key Vault に置いたうえで、App Configuration 側から Key Vault 参照として関連付けます。アプリケーションは App Configuration を単一の窓口として読み込み、機密部分だけが実行時に Key Vault から解決されます。この構成により、設定の一元管理と機密の分離を両立できます。

監査ログによる可視化

Key Vault はすべてのアクセスを記録できます。診断設定を有効にし、AuditEvent カテゴリのログを Log Analytics ワークスペースへ送ると、どの主体がいつどのオブジェクトにアクセスしたかを追跡できます。

az monitor diagnostic-settings create \
  --name kv-audit \
  --resource "$(az keyvault show --name kv-contoso-prod --query id -o tsv)" \
  --workspace "$LOG_ANALYTICS_ID" \
  --logs '[{"category":"AuditEvent","enabled":true}]'

収集したログは Kusto クエリで分析でき、想定外の主体によるアクセスや、失敗した認可の急増といった異常の検知に使えます。監査対応の観点でも、アクセスの証跡が自動で残ることは大きな利点です。しきい値を超えた場合にアラートを発報する構成を併せて用意しておくと、運用時の検知が確実になります。

実務における設計方針のまとめ

ここまでの内容を、本番環境で採用したい方針として整理します。認可は Azure RBAC を起点とし、アプリには読み取り専用ロールを最小スコープで割り当てます。認証はマネージド ID によるキーレス方式とし、資格情報をアプリ側に持たせません。ネットワークは Private Endpoint とファイアウォールで保護し、ソフトデリートとパージ保護で削除事故に備えます。証明書とキーは自動ローテーションを構成し、監査ログを Log Analytics に集約して異常検知とアラートにつなげます。これらは個別の機能ではなく、一体の設計として組み合わせて初めて効果を発揮します。

エンハンスド株式会社では、Azure を用いたセキュリティ設計と基盤構築を支援しています。Key Vault を中核としたシークレット管理、RBAC とマネージド ID による最小権限のアクセス制御、Private Endpoint を含むネットワーク保護、監査とローテーションの自動化まで、要件に即した構成の設計と実装をご提供します。既存システムのセキュリティ強化や、クラウド基盤の見直しをご検討の際は、お気軽にご相談ください。

このテーマの全体像は .NET モダナイゼーション完全ガイド にまとめています。