※本記事は、個人の意見および個人的活動を記したものであり、会社を代表するものではありません
VMローカルアカウントの運用を辞めてEntraID認証にしたいのだが、様々な制約があるため、せめてパスワードの管理をもう少し改善したい。少なくとも、手元で複数VMローカルの管理アカウントとパスワードを共有フォルダー＋パスワード付きExcelとかで管理するのはもう辞めたい。Excelのパスワードの管理も必要になる。ダサい、ダサすぎる。。。
今回の内容を実施することで、パスワードだけは手元で管理するということをしないくても済む。
- KeyVaultに権限のあるユーザーしかパスワードを参照＆更新できない
- VMに権限のあるユーザーしかVMにアクセスできない
- VMログイン時にはパスワードを知らなくても良い
パスワード管理をKeyVaultに任せ、各リソースへのアクセス権限はEntraで管理できる。ちょっと幸せになれる。
1. KeyVaultは対象システムとは別管理にする方針
KeyVaultはとても慎重に取り扱う必要があるリソースの１つ。
各システムで構築するリソースとは別で管理した方が良いと思ったので、今回は「ManagedResources」というリソースグループを作成し、そこにデプロイする。
別管理にした方が良いと思う理由は以下の通り。
- 各システムのデプロイ時にキー、シークレット、証明書の安全な参照が必要になるケースを想定（デプロイ時には既にKey Vaultに登録され、各値が参照できる状態）
- 永続保管対象であるため、システムリソースのスクラップ＆ビルドのサイクルに向かない（システムリソースのスクラップ＆ビルドはリソースグループ単位であることが多い）
- システム構築チームとは別のチーム（例えばオーナー組織のIT部門など）が管理する情報になる可能性がある（通常のシステムリソースとは明確にアクセス権限を分けて管理）
まずはKey Vaultを管理するためのリソースグループを作成する。
ここもBicepでIaC化しておきたいが、注力すべきは他にあるため、一旦手動でPortalから作成し、今後の検証時には「既に用意されているリソース」という前提で進める。
1-1. 管理用リソースグループ（管理用RG）の定義
以下のパラメータで管理用RGを作成
- RG名: ManagedResources
- Tags: システム共通のリソースであることがわかるタグを指定
1-2. Azure Portalでの構築手順
リソースグループはこれだけ。
2. 管理用RGに個別システム用Key Vaultを構築
2-1. KeyVaultリソースの定義
今回はVMのローカルユーザーのパスワード管理用に構築するのが目的なので、その他の不要なオプションは外し、後で必要になった時に追加設定する方針。たたし、データリテンションのポリシーだけは作成時の設定から変更できない。今回はデフォルト90日の削除保護有効化で構築することにした。
Key Vaultの推奨は、システム・環境・リージョン毎に分けて管理するというのがMS推奨のようだが、私は今回リージョンは不要だと思ったのでシステム名と環境名をリソース名に付与することにした。
リージョンはシステム要件に合わせて設定すれば良いと思う。
- 基本設定
- リソース名：RagSystem-Vault-dev（システム名-Vault-環境略称）
- リージョン: east us 2
- Sku: standard
- 削除データの保持期間: 90日
- 永続的な削除保護: enabled
- アクセス設定
- 権限モデル: RBAC
- リソースアクセス: 全てdisabled（必要が発生した時に後で有効化）
- ネットワーク設定
- パブリックアクセス: enabled
- 有効なアクセス元: 選択した仮想ネットワークからのみ（FirewallをONにする）
- アクセスを許可する仮想ネットワーク: なし（どこからもアクセスできない状態で構築し、後で変更する）
- MSサービスのFirewallバイパスを許可: enabled（MSサービスからのアクセスはFirewallをバイパスするよう設定されるが、KeyVaultにアクセスするためには各MSサービスに別途権限の付与が必要）
- Private Endpointの設定: なし
2-2. Azure Portalでの構築手順
2-2-1. 基本設定
2-2-2. アクセス設定
今は最低限の設定として、権限モデルにRBACを設定するだけとし、後から必要に応じて設定を追加する方針。
2-2-3. ネットワーク設定
パブリックアクセスは許可するものの、指定したネットワーク（VNet or 特定のIPレンジ）からのみアクセスできるように設定。
ここではまだVNetもIPレンジも指定しない。（＝結果的にFirewallだけは有効にするが、まだ誰もアクセスできない状態で構築）
MSのサービスはKey VaultのFirewallを通過できるようにするが、あくまでもFirewallの通過のみであり、各リソースに対して適切なアクセス権限を付与しないとKey Vaultのデータにはアクセスできない。
2-2-4. タグ設定
tagには、このVaultが所属するシステム名を登録しておく。
2-2-5. 設定サマリー
2-3. ロールの割り当て
Key Vaultを構築した直後はデータに対するアクセス権がないため、リソースを作成した所有者であってもキー、シークレット、証明書にはアクセスできない。
リソースを作成したユーザーは、あくまでもリソースに対する権限で構築しており、Key Vaultの各データへのアクセス権限は別途必要。
適切なロールを割り当てないとこうなる。
Permission modelはRBACモデルで構築しているので、操作を行うEntraユーザーに対して適切なRBACの付与が必要。
本来はユーザーではなくSGもしくは管理グループに割り当てるのが良いと思うが、ここでは気にせず自分にKey Vault Administratorを付与。
以下「アクセス設定」画面で、Permission modelがRBACになっていることを確認して、IAMの画面に遷移。
IAMの画面では、数あるロールからKey Vault Administratorを選択。自分に権限を付与する。
2-4. ネットワーク設定の追加
再度Keyやsecretやcertificatesにアクセスすると、今度はFirewallが効いていてアクセスできず。
ネットワークの設定画面で、自分のグローバルIPを追加。
ようやくkey、secrets、certificatesを追加できるようになった。
3. KeyVaultのSecretに管理者パスワードを登録
早速VMの管理者パスワードをSecretsに追加。
こんな感じで、シークレットを利用するシステム名、リソース名、利用目的がわかるような名前にすると良いかも。
4. VMログイン時にKey Vaultに登録したVM用パスワードを指定
BastionからVM接続時に、「Password from Azure Key Vault」を選択すると、リストから目的のKeyVaultとSecretが選択できる。
これでBasion経由のアクセス時に毎回パスワードを入力する必要がなくなった。
今回はBicepも書いておらず、バージョン管理するものがないのでGithubのリンクはなし。