Azure Key Vaultの使い方入門|az keyvaultでLinux VMから秘密情報を安全に参照する手順

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)Azure > Azure Key Vaultの使い方入門|az keyvaultでLinux VMから秘密情報を安全に参照する手順
「VMの環境変数にパスワードをべた書きしていて、気づいたらgitにコミットされていた」——クラウド環境で最も起きやすい情報漏洩インシデントの一つです。

AzureでLinuxサーバーを運用していると、DBの接続文字列・APIキー・証明書のパスフレーズなどを「どこに安全に置くか」という問題は必ず出てきます。.envファイルや環境変数への平文保存は手軽ですが、バージョン管理への混入やログへの流出リスクがあり、本番環境で採用できる設計ではありません。

この記事では、az keyvaultコマンドを使い、Linux VMからAzure Key Vaultのシークレットを安全に参照する手順を解説します。Key Vault作成・シークレット登録・RBAC設定から、Managed Identityを活用した認証情報ゼロの設計まで、RHEL 9.4の実機ログを交えてカバーします。

この記事のポイント

・Key Vault はシークレット・証明書の集中管理庫として機能する
・az keyvault secret set/show で登録・取得できる
・--query value -o tsv オプションで値のみを取り出せる
・Managed Identity 連携で認証情報ゼロの設計が実現できる


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

Azure Key Vaultとは何か——なぜ平文保存を避けるべきか

Azure Key Vault(キーボルト)は、パスワード・APIキー・証明書・暗号鍵などの秘密情報を安全に保管・管理するための Azure マネージドサービスです。

従来、設定ファイルへの平文保存や環境変数への埋め込みが行われてきましたが、以下の問題があります。

バージョン管理への混入リスク:.envファイルを誤ってgitにコミットすると、リポジトリの履歴に残り続けます
ログへの流出リスク:アプリのデバッグログや systemd の journald に環境変数が出力されることがあります
権限管理の難しさ:ファイルの読み取り権限は Linux レベルで管理されるため、Azure RBAC との統合ができません

Key Vault を使うと、秘密情報の保管場所を一元化し、Azure RBAC でアクセス権を細かく制御できます。誰がいつシークレットを参照したかの監査ログも自動で記録されます。

前提条件と実行環境

この記事の手順は以下の環境で動作確認しています。

・RHEL 9.4(Azure VM、Standard_B2s)
・Azure CLI 2.61.0(az コマンド)
・サブスクリプション: Contributor 権限あり

Azure CLI のインストールと認証が済んでいない場合は、まず以下を実行してください。

# Azure CLI のインストール(RHEL 9.x) $ sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc $ sudo dnf install -y azure-cli # インタラクティブにサインイン $ az login # サインイン済みアカウントの確認 $ az account show --query "{subscription:name, id:id}" -o table Name Id ---------------------------- ------------------------------------ My Azure Subscription xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Azure Key Vaultを使ったシークレット管理の基本手順

1. リソースグループとKey Vaultを作成する

Key Vault 名はグローバルで一意である必要があります。3~24文字の英数字とハイフンのみ使用可能です。

# リソースグループの作成(既存のものがあればスキップ) $ az group create --name rg-linux-practice --location japaneast # Key Vault の作成(RBAC認可モードを有効化) $ az keyvault create --name mykeyvault-prod-01 --resource-group rg-linux-practice --location japaneast --enable-rbac-authorization true { "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-linux-practice/providers/Microsoft.KeyVault/vaults/mykeyvault-prod-01", "location": "japaneast", "name": "mykeyvault-prod-01", "properties": { "enableRbacAuthorization": true, "enableSoftDelete": true, "provisioningState": "Succeeded", "softDeleteRetentionInDays": 90, "vaultUri": "https://mykeyvault-prod-01.vault.azure.net/" }, "type": "Microsoft.KeyVault/vaults" }

--enable-rbac-authorization true を指定することで、従来のアクセスポリシー方式ではなく Azure RBAC でアクセス権を管理できます。新規作成時は RBAC モードを推奨します。

enableSoftDelete: true はデフォルトで有効です。シークレットを削除してもすぐには消えず、90日間は復旧できます(後述のトラブルシュート参照)。

2. シークレットを登録する(az keyvault secret set)

# シークレットを登録する $ az keyvault secret set --vault-name mykeyvault-prod-01 --name db-password --value "P@ssw0rd-Secure-2026" { "id": "https://mykeyvault-prod-01.vault.azure.net/secrets/db-password/a1b2c3d4e5f6...", "name": "db-password", "properties": { "created": "2026-07-11T04:12:33+00:00", "enabled": true, "updated": "2026-07-11T04:12:33+00:00" }, "value": "P@ssw0rd-Secure-2026" } # シークレット一覧の確認 $ az keyvault secret list --vault-name mykeyvault-prod-01 --query "[].{name:name, enabled:attributes.enabled}" -o table Name Enabled ----------- --------- db-password True

シークレット名は英数字とハイフンのみ使用可能です。アンダースコア(_)は使えない点に注意してください。

3. アクセス制御を設定する(RBACロール付与)

RBAC モードでは、Key Vault 固有のロールを使ってアクセス権を付与します。シークレットの参照のみ許可する場合は Key Vault Secrets User ロールを使います。

# 自分のユーザーオブジェクトIDを取得 $ MY_OID=$(az ad signed-in-user show --query id -o tsv) # Key VaultのリソースIDを取得 $ VAULT_ID=$(az keyvault show --name mykeyvault-prod-01 --query id -o tsv) # シークレット参照権限を付与(Key Vault Secrets User) $ az role assignment create --assignee $MY_OID --role "Key Vault Secrets User" --scope $VAULT_ID { "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/.../roleAssignments/...", "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "principalType": "User", "roleDefinitionId": ".../Key Vault Secrets User", "scope": "/subscriptions/.../mykeyvault-prod-01" }

主要な Key Vault RBACロールの使い分けは以下のとおりです。

Key Vault Administrator:ポリシー変更を含む完全な管理権限(管理者専用)
Key Vault Secrets Officer:シークレットの作成・更新・削除が可能(CI/CDパイプライン用途)
Key Vault Secrets User:シークレットの参照のみ可能(アプリケーション・VM用途)

4. Linux VMからシークレットを取得する(az keyvault secret show)

# シークレットの値のみを取得(スクリプト向け) $ az keyvault secret show --vault-name mykeyvault-prod-01 --name db-password --query value --output tsv P@ssw0rd-Secure-2026 # 環境変数に格納して利用する例 $ DB_PASS=$(az keyvault secret show --vault-name mykeyvault-prod-01 --name db-password --query value --output tsv) $ echo "DBに接続中..." DBに接続中... $ mysql -h db.internal -u appuser -p"$DB_PASS" mydb Welcome to the MariaDB monitor.

--query value -o tsv を組み合わせることで、JSONではなく値のみを取り出せます。シェルスクリプト内で変数に代入して使う場合、この形式が最もシンプルです。
Managed Identityを使った認証情報不要の設計に進む前に、Azure対応セミナーの情報をご確認ください。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、20年以上の運用経験を持つ現役エンジニアが基礎から教えます。
Azure対応セミナーの詳細を見る >>

Managed Identityと組み合わせたクレデンシャルレス設計

これまでの手順では、az login でサインインしたユーザーの認証情報を使ってシークレットを取得していました。しかし本番運用では、VM上にサービスプリンシパルのIDやパスワードを置くことなく、VM自体が Azure AD のアイデンティティとして振る舞える Managed Identity を使う設計が推奨されます。

詳しい仕組みと設定手順は「AzureのManaged IdentityでLinux VMから鍵なしにリソースへアクセスする方法」で解説しています。ここでは Key Vault 連携に特化した手順をまとめます。

5. システム割り当てManaged Identityを有効化する

# 対象VMにManaged Identityを割り当て $ az vm identity assign --resource-group rg-linux-practice --name linuxvm-rhel94 { "systemAssignedIdentity": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "userAssignedIdentities": {} } # VMのプリンシパルIDを取得(後続のロール付与で使用) $ VM_OID=$(az vm show --resource-group rg-linux-practice --name linuxvm-rhel94 --query identity.principalId --output tsv) $ echo $VM_OID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

6. Key VaultのシークレットへのRBACロールを付与する

# Key VaultのリソースIDを取得 $ VAULT_ID=$(az keyvault show --name mykeyvault-prod-01 --query id --output tsv) # VMのManaged IdentityにKey Vault Secrets Userロールを付与 $ az role assignment create --assignee $VM_OID --role "Key Vault Secrets User" --scope $VAULT_ID { "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/.../roleAssignments/...", "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "principalType": "ServicePrincipal", "roleDefinitionId": ".../Key Vault Secrets User", "scope": "/subscriptions/.../mykeyvault-prod-01" }

ロールの伝播には通常1~2分かかります。すぐに次のステップを実行してアクセス拒否が出た場合は少し待ってから再実行してください。

7. VM内からIMDSトークンでシークレットを取得する

VM内では、Azure Instance Metadata Service(IMDS)のエンドポイントからアクセストークンを取得し、Key Vault の REST API を直接叩くことでシークレットを取得できます。このとき、認証に必要なのはVMのManaged Identityだけで、AzureのIDやパスワードは一切不要です。

# VM内で実行する(SSH接続後) # 1. IMDSからKey Vault向けアクセストークンを取得 $ TOKEN=$(curl -s 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net' -H 'Metadata:true' | python3 -c "import sys,json;print(json.load(sys.stdin)['access_token'])") # 2. Key Vault REST APIでシークレットを取得 $ curl -s "https://mykeyvault-prod-01.vault.azure.net/secrets/db-password?api-version=7.4" -H "Authorization: Bearer $TOKEN" | python3 -c "import sys,json;print(json.load(sys.stdin)['value'])" P@ssw0rd-Secure-2026

VM 内に az コマンドがインストールされている場合は、az login --identity で Managed Identity を使ったサインインができ、その後は az keyvault secret show で同様に取得できます。

# az コマンドがある場合の代替手順 $ az login --identity [ { "cloudName": "AzureCloud", "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "isDefault": true, "name": "My Azure Subscription", "state": "Enabled", "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "user": { "assignedIdentityInfo": "MSI", "name": "systemAssignedIdentity", "type": "servicePrincipal" } } ] $ az keyvault secret show --vault-name mykeyvault-prod-01 --name db-password --query value --output tsv P@ssw0rd-Secure-2026

実務Tips——Key Vault設計の3つのポイント

1. シークレットのバージョン管理
Key Vault では、同じ名前のシークレットを更新すると新しいバージョンが作成され、古いバージョンは保持されます。az keyvault secret show はデフォルトで最新バージョンを返しますが、特定バージョンを指定することも可能です。ローテーション対応アプリケーションでは、バージョンIDを明示的に指定することでゼロダウンタイムのローテーションが実現できます。

2. 診断ログの有効化
Key Vault に誰がいつアクセスしたかの監査ログを残すには、診断設定でLog Analyticsへの転送を有効化します。本番環境では必ず設定すべき項目です。AzureのLog Analyticsを使ったLinuxサーバーログの収集・分析については「AzureのLog AnalyticsでLinuxサーバーのログを収集・分析する方法」も参照してください。

3. ネットワーク制限でアクセス元を絞る
Key Vault のネットワーク設定で「選択したネットワーク」を選択し、Private Endpoint またはサービスエンドポイントを使うと、インターネット経由のアクセスを遮断できます。RBACだけでなく、ネットワーク層でもアクセスを制限する多層防御の設計を推奨します。NSGの設定方法については「AzureのNSGとSSH公開鍵認証でLinux VMを安全に保護する方法」が参考になります。

トラブルシュート——よくあるエラーと対処法

「(Forbidden) Caller is not authorized to perform action on resource」が出た時

Key Vault の RBAC ロールが付与されていないか、ロールの伝播前にアクセスしたケースです。

・ロール付与から1~2分待ってから再実行する
az role assignment list --scope --assignee でロールが付与されているか確認する
・Key Vault の RBAC モードとアクセスポリシーモードが混在していないか確認する

「(KeyNotFound) A secret with (name/id) xxx was not found」が出た時

シークレット名のタイポか、ソフト削除後のシークレットが通常の一覧に出ていないケースです。

# 削除済みシークレット(ソフト削除)の確認 $ az keyvault secret list-deleted --vault-name mykeyvault-prod-01 --query "[].{name:name, scheduledPurgeDate:scheduledPurgeDate}" -o table Name ScheduledPurgeDate ----------- ------------------------- db-password 2026-10-10T04:12:33+00:00 # 削除済みシークレットの復旧 $ az keyvault secret recover --vault-name mykeyvault-prod-01 --name db-password { "name": "db-password", "properties": { "enabled": true, "recoveryLevel": "Recoverable+Purgeable" } }

「(VaultAlreadyExists) The vault name 'xxx' is already in use」が出た時

Key Vault 名はグローバルで一意のため、別のサブスクリプションでも同名は使えません。ソフト削除が有効なVaultは削除後もリソースとして残ります。

・別の名前を使う(プロジェクト名+環境名+連番の組み合わせを推奨)
・削除済みVaultが原因の場合は az keyvault purge --name xxx --location japaneast で完全削除してから作成し直す

本記事のまとめ

やりたいこと コマンド
Key Vaultの作成 az keyvault create --name NAME --resource-group RG --enable-rbac-authorization true
シークレットの登録 az keyvault secret set --vault-name NAME --name KEY --value VALUE
シークレットの取得(値のみ) az keyvault secret show --vault-name NAME --name KEY --query value -o tsv
シークレット一覧の確認 az keyvault secret list --vault-name NAME -o table
RBACロールの付与 az role assignment create --assignee OID --role "Key Vault Secrets User" --scope VAULT_ID
Managed Identityの有効化 az vm identity assign --resource-group RG --name VM
削除済みシークレットの復旧 az keyvault secret recover --vault-name NAME --name KEY
Azure Key Vault は、秘密情報を環境変数やファイルから切り離すための基本インフラです。特にManaged Identityと組み合わせると、VM上に一切の認証情報を置かない設計が実現できます。Managed Identityの詳しい設定手順は「AzureのManaged IdentityでLinux VMから鍵なしにリソースへアクセスする方法」で解説していますので、あわせてご覧ください。

次に読む記事
・AzureのManaged IdentityでLinux VMから鍵なしにリソースへアクセスする方法
AzureのNSGとSSH公開鍵認証でLinux VMを安全に保護する方法
AzureのBastionでパブリックIPなしにLinux VMへSSH接続する方法
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、20年以上の運用経験を持つ現役エンジニアが基礎から教えます。
Azure対応セミナーの詳細を見る >>

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。