Azure Key Vault セキュリティ

3 分

Azure Key Vault により、クラウド内の暗号化キー、証明書 (および証明書に関連付けられている秘密キー)、シークレット (接続文字列やパスワードなど) が保護されます。ただし、ビジネスに不可欠な機密データを格納する場合は、コンテナーとそこに格納されるデータのセキュリティを最大化するための手順を実行する必要があります。

ネットワークのセキュリティ

コンテナーに対するアクセス権を持つ IP アドレスを指定することで、コンテナーの公開を縮小できます。 Azure Key Vault の仮想ネットワークサービスエンドポイントを使用すると、指定した仮想ネットワークに対するアクセスを制限できます。エンドポイントでは、IPv4 (インターネットプロトコルバージョン 4) アドレス範囲のリストへのアクセスを制限することもできます。このようなソースの外部からお使いのキーコンテナーに接続するユーザーはすべて、アクセスを拒否されます。

ファイアウォールルールを有効にした後は、要求が許可された仮想ネットワークまたは IPv4 アドレス範囲から送信された場合にのみ、ユーザーは Key Vault のデータを読み取ることができます。これは、Azure portal から Key Vault にアクセスする場合にも適用されます。ユーザーは Azure portal からキーコンテナーを参照できますが、クライアントマシンが許可リストに登録されていない場合、キー/シークレット/証明書を一覧表示できない場合があります。

Azure Private Link サービスを使用すると、自分の仮想ネットワーク内のプライベートエンドポイント経由で、Azure Key Vault および Azure でホストされている顧客サービスやパートナーサービスにアクセスできます。 Azure プライベートエンドポイントは、Azure Private Link を使用するサービスにプライベートかつ安全に接続するためのネットワークインターフェイスです。プライベートエンドポイントは、ご自分の VNet からのプライベート IP アドレスを使用して、サービスを実質的に VNet に取り込みます。サービスへのすべてのトラフィックはプライベートエンドポイントを経由してルーティングできるため、ゲートウェイ、ネットワークアドレス変換 (NAT) デバイス、ExpressRoute または VPN 接続、もしくはパブリック IP アドレスは必要ありません。仮想ネットワークとサービスの間のトラフィックは、Microsoft のバックボーンネットワークを経由して、パブリックインターネットからの公開を排除します。最高レベルの細分性でアクセスを制御しながら Azure リソースのインスタンスに接続できます。

トランスポート層セキュリティ (TLS) とハイパーテキスト転送プロトコルセキュア (HTTPS)

Key Vault のフロントエンド (データプレーン) はマルチテナントサーバーです。つまり、異なる顧客のキーコンテナーで同じパブリック IP アドレスを共有できます。分離を実現するため、各 HTTP 要求は、他の要求とは別に認証および承認されます。

HTTPS プロトコルを使用すると、クライアントは TLS ネゴシエーションに参加できます。クライアントで TLS のバージョンを強制することができ、クライアントでそれを行うと常に、対応するレベルの保護が接続全体で使用されます。 Key Vault では、TLS 1.2 および 1.3 プロトコルバージョンがサポートされています。

キーコンテナーの認証オプション

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 内のオプション (セキュリティを追加するために多要素認証を有効にするなど) を使用することで、認証をカスタマイズできます。

アクセスモデルの概要

キーコンテナーへのアクセスは、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 は、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、back up、restore、purge、rotate (プレビュー)、getrotationpolicy (プレビュー)、setrotationpolicy (プレビュー)、release(プレビュー) 証明書: manage contacts、getissuers、list issuers、set issuers、delete issuers、manage issuers、get、list、create、import、update、delete、recover、back up、restore、purge シークレット: get、list、set、delete、recover、back up、restore、purge	Key Vault アクセスポリシーまたは Azure RBAC

キーコンテナーに対する管理アクセスの管理

リソースグループ内にキーコンテナーを作成する場合、Microsoft Entra ID を使用することでアクセスを管理します。リソースグループ内のキーコンテナーを管理する権限をユーザーまたはグループに付与します。適切な Azure ロールを割り当てることで、特定のスコープレベルでアクセスを付与できます。キーコンテナーを管理するためのアクセス権をユーザーに付与するには、定義済みのキーコンテナー共同作成者ロールを特定のスコープでこのユーザーに割り当てます。 Azure ロールには以下のスコープレベルを割り当てることができます。

サブスクリプション:サブスクリプションレベルで割り当てられた Azure ロールは、そのサブスクリプション内のすべてのリソースグループとリソースに適用されます。
[リソースグループ] :リソースグループレベルで割り当てられた Azure ロールは、そのリソースグループ内のすべてのリソースに適用されます。
特定のリソース: 特定のリソースに対して割り当てられた Azure ロールは、そのリソースに適用されます。この場合、リソースは特定のキーコンテナーです。

アクセスポリシーのアクセス許可モデルを使用するときに、ユーザーがキーコンテナーの管理プレーンに対する Contributor アクセス許可を持っている場合、そのユーザーは Key Vault アクセスポリシーを設定することで、データプレーンへのアクセス権を自分自身に付与できます。アクセスポリシーのアクセス許可モデルを使用して、キーコンテナーに対する Contributor ロールのアクセス権を持つユーザーを厳重に管理して、認可されたユーザーのみがキーコンテナー、キー、シークレット、証明書にアクセスして管理できるようにする必要があります。この問題を回避するには、新しいロールベースのアクセス制御 (RBAC) アクセス許可モデルを使用することをお勧めします。 RBAC アクセス許可モデルを使用すると、アクセス許可管理は "所有者" と "ユーザーアクセス管理者" ロールに制限されます。これにより、セキュリティ操作と一般的な管理操作のロール間で職務を分離できます。

Key Vault データへのアクセスの制御

Azure RBAC または Key Vault アクセスポリシーを使用して、Key Vault キー、証明書、シークレットへのアクセスを制御できます。

ログ記録と監視

Key Vault のログによって、コンテナーに対して実行されたアクティビティの情報が保存されます。

Key Vault を Event Grid に統合して、キーコンテナーに格納されているキー、証明書、またはシークレットの状態が変更されたときに通知を受けることができます。

また、サービスが意図したとおりに動作していることを確認するために、キーコンテナーの正常性を監視することも重要です。

バックアップと回復

Azure Key Vault の論理的な削除と消去保護を使用すると、削除されたコンテナーとコンテナーオブジェクトを復旧できます。

また、コンテナー内のオブジェクトの更新、削除、作成の際には、コンテナーの定期的バックアップを取る必要があります。