こんにちは！オブザーバビリティ・監視アーキテクトの先輩です。
今回は、複数チームや顧客が同居するカオスな環境、いわゆる「マルチテナント環境」におけるZabbixのアクセス権限管理（RBAC：役割ベースアクセス制御）の極意についてお話しします。
「開発チームAには自分たちのサーバーだけを見せたい」
「外部の保守ベンダーには、特定のメトリクス（例：CPUとメモリのみ）に読み取り専用でアクセスさせ、機密性の高いログやコマンド実行権限は絶対に渡したくない」
「でも、ホストが増えるたびに手作業で権限設定をするのは無理ゲー……」
そんな現場の悲鳴を、今日で終わりにしましょう。
Zabbixの「ユーザーグループ」「ホストグループ」、そして現代Zabbixの神機能である「タグベースの権限管理」を正しく組み合わせれば、情報漏洩のリスクをゼロにしつつ、管理工数を劇的に減らす美しい権限マトリクスが構築できます。
これをマスターすれば、毎日のアクセス権限に関する問い合わせ対応から解放され、夜もぐっすり眠れるようになりますよ。さあ、一緒に扉を開けましょう！
—
1. そもそもZabbixにおける権限管理の基本思想とは？
Zabbixの権限管理は、基本的に「誰が（User Group）」×「何を（Host Group）」の組み合わせで決まります。
初心者がやりがちな最大の罠が、「ユーザーごとに細かく権限を設定する」ことです。これをやると、組織変更や人員異動のたびに設定が破綻し、誰も全貌を把握できないモンスター環境が完成します。
- 鉄則1：ユーザーは必ず「ユーザーグループ」に所属させる（個人に直接権限を与えない）
- 鉄則2：ホストは「ホストグループ」で論理分割する（プロジェクト別、環境別など）
- 鉄則3：権限は「拒否」が優先される（複数のグループに属する場合、最も厳しい権限が勝つ）
この3つを頭に叩き込んでおくだけで、設計のブレがなくなります。
—
2. 実践！マルチテナント権限マトリクスの設計と実装ステップ
今回は、以下の3つのテナント（プレイヤー）が混在する環境を想定して、具体的なセットアップ手順を解説します。
1. システム管理者（Admin）：全てを統括する神権限
2. 開発チームA（Dev-A）：自社アプリ用サーバー（`Project-A`）のみフルアクセス
3. 保守ベンダー（Vendor-B）：全サーバーの「参照のみ」、かつ機密タグがついたアイテムは隠す
ステップ①：ホストグループの階層構造を設計する
まずは「何を」の対象を整理します。Zabbixではホストグループにスラッシュ（`/`）を使うことで、階層構造を持たせることができます。これがマルチテナント設計のキモです。
- `Clients` （ルート）
- `Clients / Project-A` （開発チームA用）
- `Clients / Project-B` （開発チームB用）
- `Clients / Shared-Infra` （共通インフラ）
【設定手順】
1. Zabbixフロントエンドにログインし、`データ収集` > `ホストグループ` に移動。
2. 上記の階層構造に合わせてグループを作成します。
3. 監視対象のホストをそれぞれの適切なグループに割り当てます。
ステップ②：ユーザーロールで「できること」を制限する
Zabbix 5.4以降では、UIの操作権限（メニューの表示、APIの利用、設定変更の可否など）を「ユーザーロール」という概念で一元管理できるようになりました。
保守ベンダー向けに「監視データの閲覧はできるが、設定変更やスクリプト実行は一切できない」安全なロールを作りましょう。
【保守ベンダー向けロールの作成手順】
1. `管理` > `ユーザーロール` > `ロールを作成` をクリック。
2. ロール名：`保守ベンダー用リードオンリーロール`
3. 権限設定のポイント：
- UI要素：ダッシュボード、ホスト、最新データ、問題画面以外はチェックを外す（設定画面へのアクセスを遮断）。
- アクション：スクリプトの実行やホストの有効化などの危険なアクションは全て「オフ」。
- API：原則として「閉じる」（API経由の不正操作を防ぐため）。
これで、「何ができるか（Capabilities）」の縛りが完了しました。
ステップ③：ユーザーグループとホストグループを紐付ける（肝心要の権限マトリクス）
いよいよ、「誰が」と「何を」を結びつけます。
【開発チームAのグループ設定】
1. `管理` > `ユーザーグループ` > `グループを作成`。
2. グループ名：`Group-Dev-A`
3. 「権限」タブを開き、以下のように設定します：
- ターゲットグループ：`Clients / Project-A`
- 権限：「読み取り/書き込み (Read-write)」
4. ※注意：他のホストグループ（`Project-B`など）については、ここでグループを追加しない（＝デフォルトでアクセス不可になる）。
【保守ベンダーのグループ設定】
1. グループ名：`Group-Vendor-B`
2. 「権限」タブ：
- ターゲットグループ：`Clients` （ルートを指定することで配下全てを含む）
- 権限：「読み取り (Read-only)」
3. これにより、保守ベンダーは全てのホストのメトリクスを見られますが、設定を壊すことはできません。
—
3. さらに安全性を高める！「タグベースのアクセス制限」の極意
「プロジェクトAのサーバーは見せたいけれど、その中にある『DBの接続パスワード』や『個人情報ログ』といった特定の機密アイテムだけは、外部ベンダーや一般開発者に見せたくない」
そんな高度な要求に応えるのが、Zabbixのタグベースの権限管理です。ホスト単位ではなく、データ（アイテムやトリガー）に付与された「タグ」を基準にアクセスを制限します。
実装アプローチ：機密データにタグを仕込む
1. 機密アイテムにタグを付与する
監視アイテムの設定画面（例：ログ監視やデータベース接続情報）の「タグ」タブで、以下のようにタグを付けます。
- 名前：`Security` / 値：`Confidential`
2. ユーザーグループ側でタグによるフィルタリングを行う
先ほど作成した保守ベンダー用のユーザーグループ（`Group-Vendor-B`）の設定に戻ります。
- 「権限」タブの該当ホストグループの行に、「タグ」の条件を追加します。
- 例：`Security` `Equals` `Confidential` のデータは「アクセス権なし (Deny)」とする、あるいは逆に含めないように設定します。
これにより、同じサーバー（ホストグループ）を見ていても、機密データだけが綺麗にマスクされ、画面から消滅します。このきめ細かさが、プロのオブザーバビリティ設計です。
—
4. 動作確認：本当に正しく権限が効いているかテストする（HelloWorld的検証）
設計が終わったら、必ず「検証」を行いましょう。これをサボると、障害時に「あれ、見えないはずのデータが見えている！」という大惨事につながります。
1. テスト用のアカウントを作成する
- `ユーザー` > `ユーザーを作成` から、テスト用の一般ユーザー（例：`test-vendor-user`）を先ほどの `Group-Vendor-B` に所属させて作成します。
2. シームレスにログインし直す（またはブラウザのシークレットウィンドウを使う）
- 作成したテストユーザーでZabbixにログインします。
3. 以下のポイントをチェイン形式で確認する
- [ ] 意図しないプロジェクト（例：`Project-B`）のホストが、ホスト一覧に一切表示されていないか？
- [ ] ダッシュボードや最新データで、見せたくない機密タグ付きのデータが隠れているか？
- [ ] 設定変更ボタン（ホストの追加・削除など）がグレーアウトしているか、あるいは存在しないか？
ここまでクリアできれば、あなたのマルチテナント環境は完璧に要塞化されています。
—
おわりに
今回は、Zabbixにおけるマルチテナント環境の構築とアクセス権限管理の神髄を解説しました。
- ユーザーグループとホストグループで「誰が・どこを見られるか」を大きく切り分ける。
- ユーザーロールでUIや操作の権限を安全に縛る。
- タグベースのアクセス制限で、同一ホスト内の機密データをもコントロールする。
この3つを組み合わせることで、どんなに複雑な組織や顧客が混在する巨大な監視基盤であっても、美しく、セキュアに保つことができます。
日々の運用管理が驚くほどスムーズになりますので、ぜひ次の環境設計から取り入れてみてください。
あなたの監視ライフが、より平穏で知的なものになることを応援しています！