【テクニカル・上級編】Grafana IAMと細粒度アクセス制御（Fine-grained Access Control）：マルチテナント環境のセキュアな構築法 – 運用監視・オブザーバビリティ活用バイブル

Grafana IAMの深淵：マルチテナント環境における「究極のアクセス制御」とデータ分離の技術

オブザーバビリティの世界において、Grafanaはもはや単なる可視化ツールではない。それは組織の「信頼のハブ」だ。しかし、多くのエンジニアが陥る罠がある。それは「とりあえず全員に閲覧権限を与える」という怠惰な設計だ。

マルチテナント環境において、誤った権限設定は単なるセキュリティリスクではない。それは、あるチームの障害が他チームのダッシュボードを汚染し、不要なクエリでデータソースを圧迫する「オブザーバビリティの崩壊」を招く。

本稿では、GrafanaのGUIを飛び越え、API駆動で構築する「境界が明確で、かつセキュアな」マルチテナント・アーキテクチャの極意を解説する。

—

1. 組織設計の再定義：Orgs vs Folders vs Teams

Grafanaの「Organizations」機能は、論理的な分離の最終手段だ。だが、運用コストは最大になる。私は、「同一Org内でのフォルダベース制御」を基本とし、コンプライアンス要件が極めて高い場合のみ「Org分離」を行う設計を推奨する。

なぜか？

Orgを跨ぐデータソースの共有は複雑であり、認証基盤（LDAP/OIDC）との同期が地獄と化すからだ。

フォルダ階層: チームごとにトップレベルフォルダを割り当て、`Viewers`と`Editors`を同期させる。
RBACの自動化: チームの入退社とGrafanaの権限を完全にデカップリングするため、Terraformでの構成管理が必須である。

—

2. API駆動による「権限の完全自動プロビジョニング」

GUIでポチポチと設定しているようでは、プロとは呼べない。Grafanaの管理はすべてコード化（IaC）すべきだ。以下は、チーム単位でフォルダ権限を自動適用するGo言語によるプロトタイプ・アプローチだ。

// チームIDとフォルダIDを紐付け、アクセス権を強制適用するスニペット
func syncFolderPermission(client grafana.Client, folderID int64, teamID int64, role string) error {
// 既存権限を上書きし、不要なアクセスを剥奪する（最小権限の原則）
permission := grafana.Permission{
TeamId: teamID,
Role: role, // “Viewer” or “Editor”
}

// API経由で権限を更新。ここで失敗することは許されない
_, err := client.UpdateFolderPermissions(folderID, []grafana.Permission{permission})
return err
}

極意: APIを叩く際は、必ず`admin`ロールを持つService Accountを使用すること。また、APIレートリミットを回避するため、キャッシュを挟んだ差分同期パイプラインを構築せよ。

—

3. 行レベルセキュリティ（Row-level Security）の裏技

マルチテナント環境で最も頭を悩ませるのが、「AチームにはAチームのデータだけを見せたい」という要件だ。データソース側でクエリを制限するのは非効率すぎる。

ここで使うのが、「ダッシュボード変数とデータソースのクエリ置換」による擬似的なRow-levelセキュリティだ。

実装ステップ：

1. グローバル変数 `__user.login` の活用: ダッシュボードのクエリに`${__user.login}`を埋め込む。
2. データソース側のフィルタリング:

例えばPrometheusであれば、`up{team=~”$team_label”}` のように変数を渡す。
Grafanaの「Data Source Permissions」と組み合わせ、特定のユーザー以外には特定のクエリを発行させないようプロキシ側で制御する。

高度なハック: Grafanaの「Dashboard Templating」の`Custom`フィールドに、ユーザーの属性情報をOIDCから注入し、それに基づいてクエリのWHERE句を動的に生成する構成が最も堅牢だ。

—

4. アーキテクチャ最適化：メモリとクエリ負荷の管理

マルチテナント環境で「あるユーザーの重いクエリ」が全体のダッシュボードを凍結させる事態を防ぐ必要がある。

Query Caching: Redisをサイドカーとして配置し、頻繁にアクセスされるダッシュボードの計算済み結果をキャッシュせよ。
Quota Management: Grafanaの`[quota]`設定を徹底する。
`org_user_limit`: 組織ごとのユーザー数上限。
`global.max_concurrent_queries`: これを厳格に設定し、単一ユーザーがデータソースをDOS攻撃状態にするのを防ぐ。
メモリ監視: Grafanaプロセスのメモリ消費は、Dashboardのレンダリング回数に比例する。`pprof`を用いて、特定のダッシュボードがヒープをどれだけ占有しているかを定期的にプロファイリングせよ。

—

5. 伝説的アーキテクトからの助言

最後に、技術以上に大切なことを伝える。
「権限設定は、人間が手を出せない場所に置け」。

TerraformやPulumiで構成を管理し、CI/CDパイプラインを通さない変更は即座にCIによってリセットされる環境を構築すること。「設定変更の痕跡」がGitに残らない環境は、やがて腐敗する。

君たちが構築するのは、単なるグラフの箱ではない。組織の意思決定を支える「信頼のインフラ」だ。細部に宿る神を信じ、設定の隅々までコードで支配せよ。

次回の講義では、Grafana Lokiを用いた「マルチテナント・ログ隔離の物理的アプローチ」について触れることにする。準備をしておくように。