Azure Key Vault

完了

Azure Key Vault は、シークレットを安全に保管し、それにアクセスするためのクラウド サービスです。 シークレットは、API キー、パスワード、証明書、暗号化キーなど、アクセスを厳密に制御する必要がある任意のものです。 Key Vault サービスでは、コンテナーおよびマネージド ハードウェア セキュリティ モジュール (HSM) プールという 2 種類のコンテナーがサポートされています。 ボールトでは、ソフトウェアと HSM でバックアップされるキー、シークレット、証明書を保存できます。 Managed HSM プールは、HSM でバックアップされるキーにのみ対応しています。

その他の重要な用語を次に示します。

Tenant: テナントは、Microsoft クラウド サービスの特定のインスタンスを所有および管理する組織です。 ほとんどの場合、この用語は、組織の Azure と Microsoft 365 の一連のサービスを指すために使用されます。

コンテナーの所有者:コンテナー所有者は、キー コンテナーを作成し、それにフル アクセスして制御することができます。 コンテナー所有者は、だれがシークレットとキーにアクセスしたかをログに記録するように監査を設定することもできます。 管理者は、キーのライフサイクルを制御できます。 新しいバージョンのキーへの切り替え、キーのバックアップ、および関連タスクを行うことができます。

コンテナー コンシューマー:コンテナー コンシューマーは、コンテナー所有者によってアクセスを許可されると、キー コンテナー内のアセットに対してアクションを実行できます。 使用可能なアクションは、付与されるアクセス許可によって異なります。

Managed HSM 管理者:管理者ロールが割り当てられているユーザーは、Managed HSM プールを完全に制御できます。 ロール割り当てをさらに作成し、制御されたアクセスを他のユーザーに委任できます。

Managed HSM Crypto Officer とユーザー:Managed HSM でキーを使用して暗号操作を実行するユーザーまたはサービス プリンシパルに通常割り当てられる組み込みロール。 Crypto User は新しいキーを作成できますが、キーを削除することはできません。

Managed HSM 暗号化サービスの暗号化ユーザー: 顧客が管理するキーで保存データを暗号化するためのサービス アカウント管理サービス ID (ストレージ アカウントなど) に通常割り当てられる組み込みロール。

リソース:リソースは、Azure を通じて使用できる、管理可能な要素です。 一般的な例として、仮想マシン、ストレージ アカウント、Web アプリ、データベース、仮想ネットワークなどがあります。 他にもさまざまなリソースが存在します。

[リソース グループ] :リソース グループは、Azure ソリューションの関連するリソースを保持するコンテナーです。 リソース グループには、ソリューションのすべてのリソースか、グループとして管理したいリソースのみを含めることができます。 組織にとって最も有用になるように、リソースをリソース グループに割り当てる方法を決定します。

セキュリティ プリンシパル:Azure セキュリティ プリンシパルは、ユーザーが作成したアプリ、サービス、オートメーション ツールで特定の Azure リソースにアクセスするために使用されるセキュリティ ID です。 アクセス許可が厳しく管理された、特定のロールが与えられた "ユーザー ID" (ユーザー名とパスワードまたは証明書) と考えてください。 一般的なユーザー ID とは異なり、セキュリティ プリンシパルで行うタスクは制限する必要があります。 管理タスクを実行するために必要な最小限のアクセス許可レベルのみを付与すれば、セキュリティは向上します。 アプリケーションまたはサービスと共に使用されるセキュリティ プリンシパルは、サービス プリンシパルと呼ばれています。

Microsoft Entra ID:Microsoft Entra ID はテナントのためのディレクトリ サービスです。 各ディレクトリには、1 つまたは複数のドメインが存在します。 ディレクトリには複数のサブスクリプションを関連付けることができますが、テナントは 1 つだけです。

Azure テナント ID:テナント ID は、Azure サブスクリプション内で Microsoft Entra インスタンスを識別する独自の方法です。

マネージド ID:Azure Key Vault は、資格情報およびその他のキーやシークレットを安全に保管する方法を提供しますが、コードは Key Vault に認証してそれらを取得する必要があります。 マネージド ID を使用すると、Microsoft Entra ID で自動的に管理された ID を Azure サービスに提供することで、この問題を簡単に解決できます。 この ID を使用すれば、コードに必要な資格情報を追加しなくても、キー コンテナーまたは Microsoft Entra 認証をサポートするサービスに対して認証を行うことができます。

認証

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 とクライアント間をデータが移動するときにデータを保護するために、トランスポート層セキュリティ (TLS) プロトコルが強制されます。 クライアントは、Azure Key Vault との TLS 接続をネゴシエートします。 TLS には、強力な認証、メッセージの機密性、整合性 (メッセージの改ざん、傍受、偽造の検出が有効)、相互運用性、アルゴリズムの柔軟性、デプロイと使用のしやすさといったメリットがあります。

Perfect Forward Secrecy (PFS) は、顧客のクライアント システムと Microsoft クラウド サービスとの間の接続を一意のキーで保護します。 接続では、Rivest-Shamir-Adleman (RSA) ベースの 2,048 ビットの暗号化キーの長さも使われます。 この組み合わせにより、転送中のデータの傍受やデータへのアクセスを困難にしています。

Key Vault の役割

次の表を使用して、Key Vault が開発者やセキュリティ管理者のニーズを満たすのに役立つ方法を十分に理解します。

Role	問題の説明	Azure Key Vault による解決
Azure アプリケーションの開発者	"キーを使って署名と暗号化を行う Azure 用のアプリケーションを作成したい。 しかし、ソリューションが地理的に分散したアプリケーションに合うように、これらのキーをアプリケーションの外部に設定したい。 これらのキーとシークレットは、自分でコードを記述せずに保護したい。 さらに、アプリケーションから最適なパフォーマンスで簡単に使用できるようにしたい。"	√ キーは、資格情報コンテナーに格納され、必要に応じて、URI によって呼び出されます。 √ キーは、業界標準のアルゴリズム、キーの長さ、ハードウェア セキュリティ モジュールを使用して、Azure によってセキュリティで保護されています。 √ キーは、アプリケーションと同じ Azure データセンターに存在する HSM で処理されます。 この方法では、オンプレミスなどの別の場所に存在するキーより、信頼性が向上し、待機時間が削減されます。
サービスとしてのソフトウェア (SaaS) の開発者	"お客様のテナント キーやシークレットに対して義務や潜在的責任を負いたくない。 お客様がキーを自分で所有して管理すれば、自分はコア ソフトウェア機能を提供することに集中してベストを尽くすことができる。"	√ 顧客は Azure に自分のキーをインポートして管理できます。 サービスとしてのソフトウェア (SaaS) アプリケーションで顧客のキーを使って暗号化操作を実行する必要がある場合は、アプリケーションに代わって Key Vault がこれらの操作を行います。 アプリケーションからは顧客のキーが見えません。
最高セキュリティ責任者 (CSO)	"アプリケーションが、セキュリティで保護されたキー管理のために Federal Information Processing Standards (FIPS) 140-2 レベル 2 または FIPS 140-2 レベル 3 HSM に準拠していることを確認したい。 組織が、キーのライフサイクルを管理し、キーの使用状況を確実に監視できるようにしたい。 複数の Azure サービスとリソースを使用しているが、Azure の 1 つの場所からキーを管理したい。"	√ Federal Information Processing Standards (FIPS) 140-2 レベル 2 検証済み HSM のコンテナーを選びます。 √ FIPS 140-2 レベル 3 への準拠が検証済みの HSM に Managed HSM プールを選択します。 √ Key Vault は、マイクロソフトがキーを確認または抽出しないように作られています。 √ キーの使用状況は、ほぼリアルタイムで記録されます。 √ コンテナーは、Azure にあるコンテナーの数、サポートするリージョン、使用するアプリケーションに関係なく、1 つのインターフェイスを提供します。

Azure サブスクリプションを持つユーザーはだれでも、Key Vault を作成して使用できます。 Key Vault は開発者とセキュリティ管理者にとってメリットがありますが、他の Azure サービスを管理する組織の管理者がこれを実装して管理することができます。 たとえば、この管理者は Azure サブスクリプションを使用してサインインし、キーの格納先に組織用のコンテナーを作成し、次のような運用タスクを担当できます。

• キーやシークレットの作成やインポート
• キーやシークレットの取り消しや削除
• ユーザーまたはアプリケーションに Key Vault へのアクセスを許可します。結果、ユーザーまたはアプリケーションはそのキーおよびシークレットを管理または使用できるようになります。
• キーの使用状況の構成 (署名や暗号化など)
• キーの使用状況の監視