Azure Key Vaultは何を入れる場所？シークレット・キー・証明書の違い

この記事の内容

外部サービスを使うアプリに、APIキーが必要になった。「コードに直接書かず、Key Vaultへ置こう」と言われても、今度は「シークレット」と「キー」のどちらなのか迷うかもしれません。

最初の整理は、名前に「キー」が付いているかではなく、アプリがその情報を何に使うかです。Key Vaultにある三つの種類と、使う側のID・アクセス許可を分けてみましょう。

三つの種類は、用途から見分ける

Azure Key Vaultは、アプリなどが使う秘密情報・暗号鍵・証明書を管理するサービスです。Microsoft Learnの概要

種類	まず考える用途
シークレット（Secrets）	APIキーやパスワードなど、値へのアクセスを厳しく管理したい情報
キー（Keys）	データの暗号化などに使う暗号鍵
証明書（Certificates）	TLSなどで使う証明書の管理

「APIキー」という呼び名だけで、暗号鍵のKeysと同じ種類だとは判断しません。公式概要でも、APIキーはシークレット管理の対象として挙げられています。

また、三つが完全に無関係な保存箱というわけではありません。Key Vaultの証明書はキーとシークレットの仕組みの上に成り立ちます。ここでは、まず何を管理したいのかを見分ける入口として、この表を使います。オブジェクトの種類

架空のアプリが、外部サービスのAPIキーを参照する場面を考えます。秘密値そのものを書く代わりに、構成を三つに分けます。

Key Vaultが置き場所にあたり、マネージドIDは、対応する実行環境のアプリが自分を名乗るためのIDです。マネージドIDがあるだけで、中の秘密情報を読めるわけではありません。認証に加えて、必要なアクセス許可を確認します。Key Vaultの認証

IDの種類から整理したい場合は、システム割り当て・ユーザー割り当てのマネージドIDへ。ここで考えるのは、そのIDがどの情報を使う必要があるかです。

Key Vaultへ情報をまとめると、アプリのコードに秘密値を直接埋め込まずに管理する構成を考えられます。ただし、置き場所を用意しただけで、利用元の設定・アクセス許可・更新時の扱いまで自動で決まるわけではありません。秘密情報の集約と管理

たとえば、アプリが参照する情報を変更するときは、利用元への影響を確かめる必要があります。まず関係するアプリを整理し、誰が更新し、誰が影響を確認するかを決めます。いきなり既存の値を置き換えたり、広い範囲のロールを付けたりするところから始めないようにしましょう。

ネットワークから到達できることも、情報を読む許可があることとは別です。通信経路を整理する際は、Private Endpoint・DNS・公開アクセスの違いもあわせて確認できます。

まずは次の四項目だけを、値なしで整理します。下の例は架空の役割名です。

実際のAPIキー、パスワード、接続文字列を、相談用メモやチャット、画面共有用の画像へ貼り付ける必要はありません。Key Vaultの名前やオブジェクト名にも、秘密情報を含めないようにします。識別子に関する注意

このメモで用途と利用者が分かったら、次は管理担当者と、対応する認証方法・最小限の操作範囲・更新時の影響を確認します。実際の作成や登録は、その設計と取り扱い方法が決まってから進めましょう。