Azure Key Vaultは、シークレットを安全に格納してアクセスするためのクラウド サービスです。 シークレットは、API キー、パスワード、証明書、暗号化キーなど、アクセスを厳密に制御する必要があるあらゆるものです。 Key Vault サービスでは、コンテナーとマネージド ハードウェア セキュリティ モジュール (HSM) プールの 2 種類のコンテナーがサポートされています。 ボールトでは、ソフトウェアと HSM でバックアップされるキー、シークレット、証明書を保存できます。 Managed HSM プールは、HSM でバックアップされるキーにのみ対応しています。 詳細については、Azure Key Vault REST API の概要を参照してください。
その他の重要な用語を次に示します。
Tenant: テナントは、クラウド サービスの特定のインスタンスを所有および管理Microsoft組織です。 これは、組織の一連のAzureおよびMicrosoft 365 サービスを参照するために最もよく使用されます。
コンテナーの所有者:コンテナー所有者は、キー コンテナーを作成し、それにフル アクセスして制御することができます。 ボルト所有者は、誰が秘密情報とキーにアクセスしたかを記録するように監査を設定することもできます。 管理者は、キーのライフサイクルを制御できます。 新しいバージョンのキーへの切り替え、キーのバックアップ、および関連タスクを行うことができます。
コンテナー コンシューマー:コンテナー コンシューマーは、コンテナー所有者によってアクセスを許可されると、キー コンテナー内のアセットに対してアクションを実行できます。 使用可能なアクションは、付与されるアクセス許可によって異なります。
Managed HSM 管理者:管理者ロールが割り当てられているユーザーは、Managed HSM プールを完全に制御できます。 ロール割り当てをさらに作成し、制御されたアクセスを他のユーザーに委任できます。
Managed HSM Crypto Officer とユーザー:Managed HSM でキーを使用して暗号操作を実行するユーザーまたはサービス プリンシパルに通常割り当てられる組み込みロール。 Crypto User は新しいキーを作成できますが、キーを削除することはできません。
Managed HSM 暗号化サービスの暗号化ユーザー: 顧客が管理するキーで保存データを暗号化するためのサービス アカウント管理サービス ID (ストレージ アカウントなど) に通常割り当てられる組み込みロール。
Resource: リソースは、Azureで使用できる管理可能な項目です。 一般的な例として、仮想マシン、ストレージ アカウント、Web アプリ、データベース、仮想ネットワークなどがあります。 他にもさまざまなリソースが存在します。
リソース グループ: リソース グループは、Azure ソリューションの関連リソースを保持するコンテナーです。 リソース グループには、ソリューションのすべてのリソースか、グループとして管理したいリソースのみを含めることができます。 組織にとって最も有用になるように、リソースをリソース グループに割り当てる方法を決定します。
セキュリティ プリンシパル: Azure セキュリティ プリンシパルは、ユーザーが作成したアプリ、サービス、およびオートメーション ツールが特定のAzure リソースにアクセスするために使用するセキュリティ ID です。 アクセス許可が厳しく管理された、特定のロールが与えられた "ユーザー ID" (ユーザー名とパスワードまたは証明書) と考えてください。 セキュリティ プリンシパルは、一般的なユーザー ID とは異なり、特定の操作のみを行う必要があります。 管理タスクを実行するために必要な最小限のアクセス許可レベルのみを付与すれば、セキュリティは向上します。 アプリケーションまたはサービスと共に使用されるセキュリティ プリンシパルは、サービス プリンシパルと呼ばれています。 詳細については、「 アプリケーション オブジェクトとサービス プリンシパル オブジェクト」を参照してください。
Microsoft Entra ID: Microsoft Entra IDはテナントのActive Directory サービスです。 各ディレクトリには、1 つまたは複数のドメインが存在します。 ディレクトリには複数のサブスクリプションを関連付けることができますが、テナントは 1 つだけです。
Azure テナント ID: テナント ID は、Azure サブスクリプション内のMicrosoft Entra インスタンスを識別する一意の方法です。
管理 ID: Azure Key Vaultは、資格情報やその他のキーとシークレットを安全に格納する方法を提供しますが、それらを取得するにはKey Vaultに対してコードを認証する必要があります。 マネージド ID を使用すると、Azure サービスにMicrosoft Entra IDで自動的にマネージド ID を提供することで、この問題をより簡単に解決できます。 この ID を使用すると、コードに資格情報を持たずに、Microsoft Entra認証をサポートするKey Vaultまたはサービスに対する認証を行うことができます。 詳細については、次の図とAzure リソースのマネージド ID の概要を参照してください。
認証
Key Vaultを使用して操作を実行するには、最初に認証する必要があります。 Key Vaultに対して認証するには、次の 3 つの方法があります。
- Azure リソースの管理 ID: Azureの仮想マシンにアプリをデプロイするときに、Key Vaultにアクセスできる ID を仮想マシンに割り当てることができます。 その他のAzure リソースに ID を割り当てることもできます。 この手法の利点は、最初のシークレットのローテーションがアプリやサービスで管理されないことにあります。 Azureは、ID を自動的に回転させます。 ベスト プラクティスとして、この手法をお勧めします。
- サービス プリンシパルと証明書: Key Vaultにアクセスできるサービス プリンシパルと関連付けられた証明書を使用できます。 アプリケーションの所有者または開発者が証明書をローテーションする必要があるため、この手法はお勧めできません。 詳細については、「 サービス プリンシパルの作成」を参照してください。
- サービス プリンシパルとシークレット: サービス プリンシパルとシークレットを使用してKey Vaultを認証することはできますが、お勧めしません。 Key Vaultの認証に使用されるブートストラップ シークレットを自動的にローテーションするのは困難です。
包括的な認証ガイダンスについては、Azure Key Vault の
転送中のデータの暗号化
Azure Key Vaultでは、Transport Layer Security (TLS) プロトコルを適用して、Azure Key vaultとクライアント間を移動するときにデータを保護します。 クライアントは、Azure Key Vaultとの TLS 接続をネゴシエートします。 TLS には、強力な認証、メッセージの機密性、整合性 (メッセージの改ざん、傍受、偽造の検出が有効)、相互運用性、アルゴリズムの柔軟性、デプロイと使用のしやすさといったメリットがあります。
Perfect Forward Secrecy (PFS) は、顧客のクライアント システムとMicrosoftクラウド サービス間の接続を一意のキーで保護します。 Connectionsは、RSA ベースの 2,048 ビット暗号化キーの長さも使用します。 この組み合わせにより、転送中のデータの傍受やデータへのアクセスを困難にしています。
Key Vault ロール
開発者とセキュリティ管理者のニーズを満たすためにKey Vaultがどのように役立つかを理解するには、次の表を使用します。
| 役割 | 問題の説明 | Azure Key Vaultで解決 |
|---|---|---|
| Azure アプリケーションの開発者 | "署名と暗号化にキーを使用するAzure用のアプリケーションを作成する必要があります。 しかし、ソリューションが地理的に分散したアプリケーションに合うように、これらのキーをアプリケーションの外部に設定したい。 これらのキーとシークレットは、自分でコードを記述せずに保護したい。 私は、これらの鍵と秘密が私のアプリケーションから最適なパフォーマンスで簡単に使用できるようにしたい。 |
√ キーは、保管庫に格納され、必要に応じてURIによって呼び出されます。 √ キーは、業界標準のアルゴリズム、キーの長さ、ハードウェア セキュリティ モジュールを使用して、Azureによって保護されます。 √ キーは、アプリケーションと同じAzure データセンターに存在する HSM で処理されます。 この方法では、オンプレミスなどの別の場所に存在するキーより、信頼性が向上し、待機時間が削減されます。 |
| サービスとしてのソフトウェア (SaaS) の開発者 | "お客様のテナント キーやシークレットに対して義務や潜在的責任を負いたくない。 お客様がキーを自分で所有して管理すれば、自分はコア ソフトウェア機能を提供することに集中してベストを尽くすことができる。" |
√お客様は、Azureに独自のキーをインポートして管理できます。 SaaS アプリケーションが顧客のキーを使用して暗号化操作を実行する必要がある場合、Key Vaultはアプリケーションに代わってこれらの操作を実行します。 アプリケーションからは顧客のキーが見えません。 |
| 最高セキュリティ責任者 (CSO) | "アプリケーションが、セキュリティで保護されたキー管理のために FIPS 140 レベル 3 HSM に準拠していることを確認したい。 組織が、キーのライフサイクルを管理し、キーの使用状況を確実に監視できるようにしたい。 また、複数のAzureサービスとリソースを使用していますが、Azureの 1 つの場所からキーを管理したいと考えています。 |
√ FIPS 140 への準拠が検証済みの HSM にコンテナーまたはマネージド HSM を選択します。 √ FIPS 140-3 レベル 3 で検証された HSM のマネージド HSM プール を選択します。 √ Key Vaultは、Microsoftがキーを表示または抽出しないように設計されています。 √ キーの使用状況は、ほぼリアルタイムで記録されます。 √ コンテナーには、Azure内のコンテナーの数、サポートされているリージョン、使用するアプリケーションに関係なく、1 つのインターフェイスが用意されています。 |
Azure サブスクリプションを持つすべてのユーザーが、キー コンテナーを作成して使用できます。 Key Vault開発者とセキュリティ管理者にメリットがありますが、他のAzure サービスを管理する組織の管理者が実装および管理できます。 たとえば、この管理者は、Azure サブスクリプションでサインインし、キーを格納する組織のコンテナーを作成し、次のような運用タスクを担当できます。
- キーやシークレットの作成やインポート
- キーやシークレットの取り消しや削除
- ユーザーまたはアプリケーションに Key Vault へのアクセスを許可します。結果、ユーザーまたはアプリケーションはそのキーおよびシークレットを管理または使用できるようになります。
- キーの使用状況の構成 (署名や暗号化など)
- キーの使用状況の監視
その後、この管理者は開発者に、アプリケーションから呼び出す URI を提供します。 また、この管理者は、セキュリティ管理者にキーの使用状況のログ情報を提供します。
開発者は、API を使用してキーを直接管理することもできます。 詳細については、Azure Key Vault開発者ガイドを参照してください。
次のステップ
- Azure Key Vault開発者ガイドで始めましょう
- Azure Key Vaultセキュリティ機能について説明します
- Azure Key Vault での認証について学ぶ
- Managed HSM プールをセキュリティで保護する方法を学習する
Azure Key Vaultは、ほとんどのリージョンで利用できます。 詳細については、Key Vault価格に関するページを参照してください。