[Azure] Key Vault について
アップデート
2024/04/3：
「Application Gatewayに直接証明書をアップロードするのではなく、Key Vaultを利用する意味は？」とPJで聞かれたときに、管理の一元化としか回答ができなかったので、証明書周りの補足も実施。
Key Vaultで証明書を管理する意義について
- ライフサイクルを別に管理できる。
- 例えばAppGWのリスナーに直接証明書をアップロードした場合、AppGWの再作成時に証明書の再アップも必要になってしまう。本来削除が不要な証明書のライフサイクルをKeyVaultに外だしすることが可能になる。
- 証明書を一元管理し、利用するサービスからの参照にすることで運用が楽になる。
- 複数のリソース(AppGWやAppService/FunctionsやAPIM)で証明書を扱う際に、各リソースでの管理作業が不要になる。
- 証明書の有効期限の通知が可能
- 証明書の有効期限を設定し、近づいてきたらリマインドのメールを飛ばすように設定できる。
- 証明書の自動更新が可能（ただし全ての証明書が対象ではない）
- Key Vaultと連携されたCAから発行された証明書については、期限の自動更新を実施することができる。
- 対象のCAはDigiCertとGlobalSignである。それ以外のCAや自己証明書の場合には、上記の通知機能に従って更新作業を実施する必要がある。
Azure Key Vaultのローテーションについて
キーのローテーションはポリシーを設定して、KeyVaultで完結して実施することができる。
証明書も、キーほど細かい設定ではないが、有効期限が来た時のアクションを設定できる。
一方で、シークレットの場合は、有効期限は存在するが自動対応に関する設定項目はない。
そのため、Azure Functionにて自動ローテーションを実行する必要がある。
以前の項目で載せているリンクを参照。
Key Vaultローテーションの自動化
Event Gtid とAzure functionを使った実現が可能らしい。 powershell rundeckだと、実行間隔が日数になるので場合によっては向いていない？（ヵ月指定とかになると）
KeyVaultの設定として自動ローテーションも可能なので、労力が少ないのはそのやり方になる。
key vaultシークレットの有効/無効化
key vaultへのアクセスはRBACでも制御可能？
制御可能。
Key Vaultを作成するときに、アクセスポリシー or RBACでの制御で選択ができる。
作成後は各人にRBACの割り当てを行うことで、権限に応じた操作が可能になる。
ちなみにRBACの割り当てを行うことができるのは、サブスクリプションレベルでの所有者権限を持つ人になる。
Key Vaultの不思議なところだが、所有者みたいにすべてのアクションが許可されている場合でも、許可の割り当てが行われるまではキーの作成等はできない。暗黙的な拒否を上書きするような明示的な許可が必要になるのだろう。
信頼できるサービス（Key Vaultのみ)
例えばDiskの暗号化の場合、信頼できるサービスからのアクセスの☑を入れることで、ネットワークの追加をせずに済む。
Discussion