Azure Key Vault セキュリティ
Azure Key Vault により、クラウド内の暗号化キー、証明書 (および証明書に関連付けられている秘密キー)、シークレット (接続文字列やパスワードなど) が保護されます。 ただし、ビジネスに不可欠な機密データを格納する場合は、コンテナーとそこに格納されるデータのセキュリティを最大化するための手順を実行する必要があります。
この記事では、Azure Key Vault のセキュリティ機能とベスト プラクティスの概要について説明します。
Note
Azure Key Vault のセキュリティに関する推奨事項の包括的な一覧については、「Key Vault 用の Azure セキュリティ ベースライン」を参照してください。
ネットワークのセキュリティ
コンテナーに対するアクセス権を持つ IP アドレスを指定することで、コンテナーの公開を縮小できます。 Azure Key Vault の仮想ネットワーク サービス エンドポイントを使用すると、指定した仮想ネットワークに対するアクセスを制限できます。 エンドポイントでは、IPv4 (インターネット プロトコル バージョン 4) アドレス範囲のリストへのアクセスを制限することもできます。 このようなソースの外部からお使いのキー コンテナーに接続するユーザーはすべて、アクセスを拒否されます。 詳細については、「Azure Key Vault の仮想ネットワーク サービス エンドポイント」を参照してください。
ファイアウォール ルールを有効にした後は、要求が許可された仮想ネットワークまたは IPv4 アドレス範囲から送信された場合にのみ、ユーザーは Key Vault のデータを読み取ることができます。 これは、Azure portal から Key Vault にアクセスする場合にも適用されます。 ユーザーは Azure portal からキー コンテナーを参照できますが、クライアント マシンが許可リストに登録されていない場合、キー/シークレット/証明書を一覧表示できない場合があります。 実装の手順については、「Azure Key Vault のファイアウォールと仮想ネットワークを構成する」を参照してください。
Azure Private Link サービスを使用すると、自分の仮想ネットワーク内のプライベート エンドポイント経由で、Azure Key Vault および Azure でホストされている顧客サービスやパートナー サービスにアクセスできます。 Azure プライベート エンドポイントは、Azure Private Link を使用するサービスにプライベートかつ安全に接続するためのネットワーク インターフェイスです。 プライベート エンドポイントは、ご自分の VNet からのプライベート IP アドレスを使用して、サービスを実質的に VNet に取り込みます。 サービスへのすべてのトラフィックをプライベート エンドポイント経由でルーティングできるため、ゲートウェイ、NAT デバイス、ExpressRoute または VPN 接続、パブリック IP アドレスは必要ありません。 仮想ネットワークとサービスの間のトラフィックは、Microsoft のバックボーン ネットワークを経由して、パブリック インターネットからの公開を排除します。 最高レベルの細分性でアクセスを制御しながら Azure リソースのインスタンスに接続できます。 実装の手順については、「Key Vault を Azure Private Link と統合する」を参照してください。
TLS と HTTPS
- Key Vault のフロントエンド (データ プレーン) はマルチテナント サーバーです。 つまり、異なる顧客のキー コンテナーで同じパブリック IP アドレスを共有できます。 分離を実現するため、各 HTTP 要求は、他の要求とは別に認証および承認されます。
- HTTPS プロトコルを使用すると、クライアントは TLS ネゴシエーションに参加できます。 クライアントで TLS のバージョンを強制することができ、クライアントでそれを行うと常に、対応するレベルの保護が接続全体で使用されます。 Key Vault では、TLS 1.2 および 1.3 プロトコル バージョンがサポートされています。
Note
こちらのサンプル Kusto クエリを使用して Key Vault ログを監視することで、クライアントによって使用される TLS バージョンを監視できます。
Key Vault の認証オプション
Azure サブスクリプション内にキー コンテナーを作成すると、そのキー コンテナーはサブスクリプションの Microsoft Entra テナントに自動的に関連付けられます。 両方のプレーンの呼び出し元はすべて、このテナントに登録されている必要があり、キー コンテナーにアクセスするには認証を行う必要があります。 どちらの場合も、アプリケーションは次の 3 つの方法で Key Vault にアクセスできます。
- アプリケーションのみ: アプリケーションは、サービス プリンシパルまたはマネージド ID を表します。 この ID は、キー コンテナーの証明書、キー、またはシークレットに定期的にアクセスする必要があるアプリケーションの最も一般的なシナリオです。 このシナリオが機能するには、アプリケーションの
objectIdをアクセス ポリシーで指定する必要があり、applicationIdを指定しないようにするか、またはnullにする必要があります。 - ユーザーのみ: ユーザーは、テナントに登録されている任意のアプリケーションからキー コンテナーにアクセスします。 この種類のアクセスの例として、Azure PowerShell や Azure portal があります。 このシナリオが機能するには、ユーザーの
objectIdをアクセス ポリシーで指定する必要があり、applicationIdを指定しないようにするか、またはnullにする必要があります。 - アプリケーションとユーザー (複合 ID とも呼ばれます): ユーザーは、特定のアプリケーションからキー コンテナーにアクセスする必要があり、かつそのアプリケーションは On-Behalf-Of 認証 (OBO) フローを使用してそのユーザーを偽装する必要があります。 このシナリオが機能するには、
applicationIdとobjectIdの両方をアクセス ポリシーで指定する必要があります。applicationIdによってその必要なアプリケーションが識別され、objectIdによってそのユーザーが識別されます。 現時点では、このオプションはデータ プレーンの Azure RBAC では使用できません。
すべての種類のアクセスで、アプリケーションは Microsoft Entra ID を使用して認証します。 アプリケーションでは、アプリケーションの種類に基づいてサポートされる認証方法が使用されます。 アプリケーションでは、アクセス権を付与するプレーン内のリソース用のトークを取得します。 このリソースは、管理プレーンまたはデータ プレーン内にあるエンドポイントであり、Azure 環境に基づいています。 アプリケーションでは、このトークンを使用して、Key Vault に REST API 要求を送信します。 詳細については、認証フロー全体に関するページを確認してください。
1 つのメカニズムで両方のプレーンを認証するモデルには次のようないくつかの利点があります。
- 組織では、組織内のすべてのキー コンテナーへのアクセスを一元的に管理できます。
- 退職したユーザーは、組織内のすべてのキー コンテナーに即座にアクセスできなくなります。
- 組織では、Microsoft Entra ID のオプションを使用して認証をカスタマイズできます (セキュリティを強化するために多要素認証を有効にするなど)。
詳細については、「Key Vault 認証の基礎」を参照してください。
アクセス モデルの概要
キー コンテナーへのアクセスは、2 つのインターフェイス (管理プレーンとデータ プレーン) を使用して制御します。 管理プレーンでは、Key Vault 自体の管理を行います。 このプレーンでは、キー コンテナーの作成および削除、Key Vault のプロパティの取得、アクセス ポリシーの更新などの操作を行います。 データ プレーンでは、キー コンテナーに格納されているデータを操作します。 キー、シークレット、証明書の追加、削除、および変更を行うことができます。
どちらのプレーンも、認証には Microsoft Entra ID を使用します。 認可については、管理プレーンでは Azure ロールベースのアクセス制御 (Azure RBAC) が使用され、データ プレーンでは Key Vault アクセス ポリシーと Key Vault データ プレーン操作用の Azure RBAC が使用されます。
いずれのプレーン内でもキー コンテナーにアクセスするには、すべての呼び出し元 (ユーザーまたはアプリケーション) が適切な認証と承認を必要とします。 認証では、呼び出し元の ID が確立されます。 認可では、呼び出し元が実行できる操作が決定されます。 Key Vault による認証は、特定のセキュリティ プリンシパルの ID の認証を行う Microsoft Entra ID と連携して機能します。
セキュリティ プリンシパルは、Azure リソースへのアクセスを要求するユーザー、グループ、サービス、またはアプリケーションを表すオブジェクトです。 すべてのセキュリティ プリンシパルには、Azure によって一意のオブジェクト ID が割り当てられます。
- ユーザー セキュリティ プリンシパルでは、Microsoft Entra ID 内にプロファイルを持つ個人が示されます。
- グループ セキュリティ プリンシパルでは、Microsoft Entra ID 内に作成されたユーザーのセットが示されます。 グループに割り当てられたすべてのロールまたはアクセス許可は、グループ内のすべてのユーザーに付与されます。
- サービス プリンシパルは、アプリケーションまたはサービス、つまりユーザーまたはグループではなくコードを示すセキュリティ プリンシパルの一種です。 サービス プリンシパルのオブジェクト ID はクライアント ID と呼ばれ、ユーザー名のように機能します。 サービス プリンシパルのクライアント シークレットまたは証明書は、パスワードのように機能します。 多くの Azure サービスによって、クライアント ID および証明書の自動管理によるマネージド ID の割り当てがサポートされます。 マネージド ID は、Azure 内での認証で最も安全かつ推奨されるオプションです。
Key Vault の認証の詳細については、「Azure Key Vault に対する認証」を参照してください。
条件付きアクセス
Key Vault は、Microsoft Entra 条件付きアクセス ポリシーのサポートを提供しています。 条件付きアクセス ポリシーを使用すると、必要な場合は Key Vault に適切なアクセスの制御を適用して組織のセキュリティを維持し、必要でない場合はユーザーの邪魔にならないようにすることができます。
詳しくは、条件付きアクセスの概要に関するページをご覧ください。
特権アクセス
承認によって、呼び出し元が実行できる操作が決定されます。 Key Vault での認可では、管理プレーン上の Azure ロールベースのアクセス制御 (Azure RBAC) と、データ プレーン上の Azure RBAC または Azure Key Vault アクセス ポリシーが使用されます。
コンテナーに対するアクセスは 2 つのインターフェイスすなわちプレーンを介して行います。 これらのプレーンは、管理プレーンとデータ プレーンです。
- "管理プレーン" は Key Vault そのものを管理する場所であり、コンテナーの作成と削除に使用されるインターフェイスです。 キー コンテナーのプロパティを読み取り、アクセス ポリシーを管理することもできます。
- "データ プレーン" では、キー コンテナーに格納されているデータを操作できます。 キー、シークレット、証明書の追加、削除、および変更を行うことができます。
アプリケーションによって、エンドポイントを介してプレーンにアクセスされます。 2 つのプレーンに対するアクセス制御は独立して機能します。 キー コンテナー内のキーを使用するためのアクセスをアプリケーションに許可する場合は、Azure RBAC または Key Vault アクセス ポリシーを使用してデータ プレーンのアクセスを許可します。 ユーザーに対して Key Vault のプロパティおよびタグの読み取りアクセスは許可するが、データ (キー、シークレット、証明書) へのアクセスは許可しない場合は、Azure RBAC を使用して管理プレーンのアクセスを許可します。
次の表に、管理プレーンとデータ プレーンのエンドポイントを示します。
| アクセス プレーン | アクセス エンドポイント | 操作 | アクセス制御メカニズム |
|---|---|---|---|
| 管理プレーン | グローバル: management.azure.com:443 21Vianet によって運営される Microsoft Azure: management.chinacloudapi.cn:443 Azure US Government: management.usgovcloudapi.net:443 Azure Germany: management.microsoftazure.de:443 |
キー コンテナーの作成、読み取り、更新、削除 Key Vault アクセス ポリシーの設定 Key Vault タグの設定 |
Azure RBAC |
| データ プレーン | グローバル: <vault-name>.vault.azure.net:443 21Vianet によって運営される Microsoft Azure: <vault-name>.vault.azure.cn:443 Azure US Government: <vault-name>.vault.usgovcloudapi.net:443 Azure Germany: <vault-name>.vault.microsoftazure.de:443 |
キー: encrypt、decrypt、wrapKey、unwrapKey、sign、verify、get、list、create、update、import、delete、recover、backup、restore、purge、rotate (プレビュー)、getrotationpolicy (プレビュー)、setrotationpolicy (プレビュー)、release (プレビュー) 証明書: 連絡先の管理、発行者の取得、発行者の一覧表示、発行者の設定、発行者の削除、発行者の管理、取得、一覧表示、作成、インポート、更新、削除、回復、バックアップ、復元、消去 シークレット: 取得、一覧表示、設定、削除、回復、バックアップ、復元、消去 |
Key Vault アクセス ポリシーまたは Azure RBAC |
キー コンテナーに対する管理アクセスの管理
リソース グループ内にキー コンテナーを作成する場合、Microsoft Entra ID を使用することでアクセスを管理します。 リソース グループ内のキー コンテナーを管理する権限をユーザーまたはグループに付与します。 適切な Azure ロールを割り当てることで、特定のスコープ レベルでアクセスを付与できます。 キー コンテナーを管理するためのアクセス権をユーザーに付与するには、定義済みの key vault Contributor ロールを特定のスコープでそのユーザーに割り当てます。 Azure ロールには以下のスコープ レベルを割り当てることができます。
- サブスクリプション:サブスクリプション レベルで割り当てられた Azure ロールは、そのサブスクリプション内のすべてのリソース グループとリソースに適用されます。
- [リソース グループ] :リソース グループ レベルで割り当てられた Azure ロールは、そのリソース グループ内のすべてのリソースに適用されます。
- 特定のリソース: 特定のリソースに対して割り当てられた Azure ロールは、そのリソースに適用されます。 この場合、リソースは特定のキー コンテナーです。
定義済みのロールが複数あります。 定義済みのロールがニーズに合わない場合は、独自のロールを定義できます。 詳細については、Azure RBAC: 組み込みのロールに関するページをご覧ください。
重要
アクセス ポリシーのアクセス許可モデルを使用するときに、ユーザーがキー コンテナーの管理プレーンに対する Contributor や Key Vault Contributor、または Microsoft.KeyVault/vaults/write アクセス許可が含まれている他のロールを持っている場合、そのユーザーは Key Vault アクセス ポリシーを設定することで、データ プレーンへのアクセス権を自分自身に付与できます。 アクセス ポリシーのアクセス許可モデルを使用して、キー コンテナーに対する Contributor ロールのアクセス権を持つユーザーを厳重に管理して、認可されたユーザーのみがキー コンテナー、キー、シークレット、証明書にアクセスして管理できるようにする必要があります。 この問題を回避するには、新しいロールベースのアクセス制御 (RBAC) アクセス許可モデルを使用することをお勧めします。 RBAC アクセス許可モデルを使用すると、アクセス許可管理は "所有者" と "ユーザー アクセス管理者" ロールに制限されます。これにより、セキュリティ操作と一般的な管理操作のロール間で職務を分離できます。
Key Vault データへのアクセスの制御
Azure RBAC または Key Vault アクセス ポリシーを使用して、Key Vault キー、証明書、シークレットへのアクセスを制御できます。
詳細については、「
ログ記録と監視
Key Vault のログによって、コンテナーに対して実行されたアクティビティの情報が保存されます。 詳細については、Key Vault のログ記録に関する記事を参照してください。
Key Vault を Event Grid に統合して、キー コンテナーに格納されているキー、証明書、またはシークレットの状態が変更されたときに通知を受けることができます。 詳細については、「Azure Event Grid での Key Vault の監視」を参照してください。
また、サービスが意図したとおりに動作していることを確認するために、キー コンテナーの正常性を監視することも重要です。 その方法の詳細については、「Azure Key Vault の監視とアラート」を参照してください。
バックアップと回復
Azure Key Vault の論理的な削除と消去保護を使用すると、削除されたコンテナーとコンテナー オブジェクトを復旧できます。 詳細については、「Azure Key Vault の論理的な削除の概要」を参照してください。
また、コンテナー内のオブジェクトの更新、削除、作成の際には、コンテナーの定期的バックアップを取る必要があります。