「生殺与奪」の権限を誤った手に：午前2時の出来事
その夜、私のデスクの上で電話が激しく震えました。電話の向こうでは、ジュニアエンジニアが泣きそうな声でこう言いました。「先輩、本番環境のDBが消えてしまいました。インベントリを探してもどこにも見当たりません！」。あくびをしながらノートPCを開き、vCenterの「タスク & イベント」を確認した私は、残酷な事実に気づきました。彼はテストマシンのネットワークカードを調整しようとしていたのですが、最高権限である Administrator を持っていたため、誤って最も重要な本番DBの「ディスクから削除」ボタンを押してしまったのです。
結果はどうなったか？ Veeamのバックアップからデータをリストアするのに4時間近くかかりました。これは、権限管理を怠っていたことへの手痛い教訓です。現在、私は8台のESXiホストと150台以上の仮想マシンを管理していますが、RBAC（ロールベースアクセス制御）を徹底しなければ、遅かれ早かれ同様の運用ミスで窮地に立たされることになるでしょう。RBACは単なるパスワード設定ではなく、業務に必要な最小限の権限を与えつつ、事故を防ぐための「技術」なのです。
アクセス権限管理における3つのアプローチの比較
構成を始める前に、なぜ「RBACとアイデンティティソースの組み合わせ」がプロフェッショナルな環境における唯一の選択肢なのか、3つの一般的な方法を比較してみましょう。
- Administratorアカウントの共有: これはいつ起きてもおかしくない大惨事の予備軍です。全員が
[email protected]を共有します。唯一のメリットは「楽」なことですが、誰が何をしたのか全く分かりません（監査ログがゼロ）。一人のミスをチーム全員で背負うことになります。 - 各ホストでのローカルユーザー作成: ホストが1〜2台ならこれでもいいでしょう。しかし、ホスト数が増えると、新入社員のために8台のサーバーに8回ログインしてパスワードを設定するのは、まさに苦行です。
- RBACとAD/LDAPের連携: これが私の採用している方法です。vCenterをActive Directoryに直接接続します。権限の割り当てはADのグループに基づいて行います。社員が退職した際も、ADのアカウントを無効化するだけで済み、非常にクリーンで安全です。
メリットとデメリット：本当にバラ色なのか？
具体的なメリット
RBACの最大の強みは粒度（Granularity）、つまり権限を細かく切り分けられることです。開発チームには仮想マシンの電源操作は許可しつつ、RAMやCPUの構成変更は絶対に禁止するといった制御が可能です。また、ネットワークチームには仮想スイッチの操作のみを許可し、データストアには触れさせないといった運用もできます。さらに、継承（Inheritance）機能により、データセンターレベルでの権限割り当てを、配下にある数十のフォルダへわずか30秒で適用できます。
注意すべき点
実際の運用現場では、RBACは初期設計の複雑さで管理者を悩ませることがあります。VMフォルダの構成が不適切な場合、権限の割り当てが重複したり複雑化したりします。時には一人のユーザーが異なる2つのADグループに属していることで、権限の競合が発生することもあります。そのような場合、なぜユーザーがマシンを起動できないのかをデバッグするだけで、午後いっぱい潰れてしまうこともあります。
導入の3ステップ：理論から実践まで
標準的な構成を行う際、私は常に次の公式に従います：アイデンティティソースの定義 -> ロールの定義 -> パーミッションの割り当て。
ステップ1：Active Directoryとの連携
ユーザーを個別に作成してはいけません。[管理] > [Single Sign-On] > [設定] から会社のドメインを追加してください。ドメインへの参加に成功すれば、vCenterの画面上で名前を入力するだけで、同僚のアカウントを簡単に見つけることができます。
ステップ2：カスタムロールの作成 – 既定のロールを使わない
VMwareには VM Power User や ReadOnly といった既定のロールが用意されています。しかし、経験上、これらは権限が多すぎたり少なすぎたりすることがほとんどです。
私は通常、チームごとに専用のロールを作成します。例えば、「Junior-Operator」ロールには、以下の3つの権限グループのみをチェックします。
- 操作（Interaction）: 電源オン、電源オフ、コンソール操作。
- インベントリ（Inventory）: 既存からの作成（テンプレートからのクローン作成用）。
- スナップショット管理（Snapshot management）: コード更新前に自分でスナップショットを撮れるようにするため。
ステップ3：「最小権限」の原則に基づくパーミッションの割り当て
ここで、ユーザー（またはグループ） + ロール + オブジェクトを紐付けます。例えば、Dev_Team グループに Project_Alpha フォルダへの権限を付与する場合：
Project_Alphaフォルダを右クリックします。- [パーミッションの追加] を選択します。
- [ユーザー] セクションでドメインを選択し、
Dev_Teamと入力します。 - [ロール] セクションで、先ほど作成した
Junior-Operatorを選択します。 - [子オブジェクトへの伝達] に必ずチェックを入れて、フォルダ内のすべての仮想マシンに権限が自動適用されるようにします。
PowerCLIによる自動化
管理する仮想マシンが数百台ある場合、マウスでのクリック操作は不可能です。私は通常、PowerCLIスクリプトを使用して一括で権限を割り当てており、操作時間を約80%短縮しています。以下は、私が権限確認や付与によく使用するコードの一部です：
# vCenterに接続
Connect-VIServer -Server vcenter.itfromzero.com
# ユーザー 'hoang.admin' が持っている権限を確認
Get-VIPermission | Where-Object {$_.Principal -like "*hoang.admin*"} | Select-Object Entity, Role, Principal
# VMフォルダに対して特定のグループにロールを素早く割り当て
New-VIPermission -Entity (Get-Folder "Production_VMs") -Principal "DOMAIN\Group_Admins" -Role "Admin_Role" -Propagate:$true大規模クラスター管理における4つの重要な注意点
小規模から大規模まで、長年vCenterシステムと向き合ってきた中で得た実地経験を共有します：
- VMフォルダの活用は必須: 個別の仮想マシンに直接権限を割り当ててはいけません。プロジェクトごとにフォルダにまとめましょう。新しいマシンが作成された際、そのフォルダに移動させるだけで、適切な権限が自動的に継承されます。
- 個人への権限割り当ては絶対禁止: 必ずADグループに対して権限を付与してください。新しいスタッフが加わった際、AD側でグループに追加するだけでvCenter側が自動で認識するため、vCenterの構成を触る必要がなくなります。
- グローバルパーミッションには慎重に: この権限はライセンスからタギングまで、システム全体に影響を与えます。本当に信頼できる「コア管理者」だけに限定して付与してください。
- 常に再確認する: 設定後はテスト用のアカウントでログインし、意図した通りに動くか確認してください。権限のないユーザーに対しては、「削除」ボタンがグレーアウトされていることを必ず確かめてください。
権限管理は地味な作業ですが、非常に重要です。トラブルが起きてから慌ててプロセスを見直すのではなく、今すぐ対策を講じましょう。私のクラスター運用経験に基づいたこの共有が、皆さんが「午前2時の電話」を受けずに済む助けになれば幸いです！
