Zabbix は LDAP 認証に対応しており、複数の LDAP サーバーを登録できます。しかし、複数 LDAP と JIT プロビジョニングを組み合わせる場合は、単純な冗長化やマルチテナント認証として考えるとつまずきます。
この記事では、Zabbix の複数 LDAP 連携で気になった点を、認証設計の観点から整理します。結論として、Zabbix の LDAP 連携は便利ですが、JIT プロビジョニング、デフォルト LDAP サーバー、グループマッピングの扱いを理解しておかないと、期待したマルチテナンシーにはなりません。
Zabbix の LDAP 認証でできること
Zabbix の LDAP 認証は、Microsoft Active Directory や OpenLDAP と連携して、ユーザー名とパスワードを外部ディレクトリで確認するための機能です。ユーザーが Zabbix に存在している場合は、Zabbix 側のパスワードではなく LDAP の認証結果でログインできます。
| 機能 | 意味 |
|---|---|
| LDAP 認証 | ユーザーの資格情報を LDAP / AD 側で確認する |
| 複数 LDAP サーバー | 複数のディレクトリ設定を Zabbix に登録できる |
| JIT プロビジョニング | 初回ログイン時に Zabbix ユーザーを作成できる |
| ユーザーグループマッピング | LDAP グループと Zabbix ユーザーグループ / ロールを対応付ける |
JIT プロビジョニングはデフォルト LDAP サーバーが重要
元記事で気になっていたのは、複数 LDAP サーバーを登録しても、JIT プロビジョニングが期待通りに動くのは「標準」として扱われる LDAP 側に寄る、という点です。
Zabbix の現行ドキュメントでも、LDAP ユーザーがログインした時、まだ Zabbix にユーザーが存在しない場合は、デフォルト LDAP サーバーでユーザーを確認して作成する説明になっています。また、JIT で作成されたユーザーは、その時点のデフォルト LDAP サーバーに関連付けられます。
つまり、複数 LDAP サーバーを登録できることと、複数ディレクトリを対等に横断して JIT プロビジョニングできることは同じではありません。ここを誤解すると、マルチテナント的な認証設計で期待と実際の挙動がずれます。
複数 LDAP をマルチテナントとして使う難しさ
複数 LDAP 連携を使いたくなる場面は、たとえば組織ごと、拠点ごと、顧客ごと、管理領域ごとにディレクトリが分かれている場合です。しかし Zabbix の認証とプロビジョニングをそのままマルチテナント基盤として使うには注意が必要です。
- 初回ログイン時にどの LDAP サーバーでユーザーを探すのか
- 作成済みユーザーがどの LDAP ディレクトリに紐付くのか
- 同じユーザー名が複数 LDAP に存在した場合にどう扱うのか
- LDAP グループと Zabbix ユーザーグループの対応が衝突しないか
- ユーザーが複数グループに一致した場合、Zabbix 側のロールがどう決まるのか
Zabbix のドキュメントでは、ユーザーが複数の Zabbix ユーザーグループに一致する場合は複数グループのメンバーになり、複数ロールに一致する場合は最も高い権限レベルのロールが適用されると説明されています。これは便利な一方で、マッピング設計を誤ると権限が広がりすぎる可能性があります。
単一 LDAP 内の複数グループマッピングも注意が必要
単一 LDAP サーバー上で複数のグループにマッピングする場合も、単純ではありません。ユーザーが複数の LDAP グループに所属していると、Zabbix 側で複数のユーザーグループやロールに一致する可能性があります。
元記事では、この挙動を「グループマッピングが非常におかしい」と感じていました。今の観点で見ると、Zabbix の仕様として複数一致を許容する部分と、実際の権限設計として危険に見える部分が混ざっていたのだと思います。
LDAP group A -> Zabbix group A / User role
LDAP group B -> Zabbix group B / Admin role
ユーザーが LDAP group A と LDAP group B の両方に所属する場合、
Zabbix 側では複数グループに入り、ロールはより高い権限が選ばれる可能性がある。SAML を使えば解決するわけでもない
では SAML にすればよいかというと、それも単純ではありません。Zabbix は SAML 認証と JIT プロビジョニングにも対応していますが、SAML では証明書、秘密鍵、IdP メタデータ、属性マッピング、グループマッピングの設計が必要になります。
特に Kubernetes 環境では、SAML の証明書や秘密鍵をどこに置くか、Zabbix frontend コンテナにどう渡すか、設定を Secret / ConfigMap / 永続ボリュームのどれで扱うかが地味に面倒です。
Zabbix の現行ドキュメントでは、SAML の秘密鍵と証明書は通常 ui/conf/certs/ に置く説明になっています。ただし設定によっては DB へ証明書を保存する方式もあり、環境に応じた設計が必要です。
監視システムではローカル管理者を残す
Zabbix は監視システムです。認証基盤そのものや LDAP / SAML / IdP に障害が起きた時にも、監視画面へ入れる必要があります。
- LDAP が停止してもログインできるローカル管理者を残す
- SAML / IdP 停止時の緊急ログイン経路を確認する
- 外部認証ユーザーとローカル管理者の責務を分ける
- 認証設定変更前に復旧手順を確認する
- 過剰なグループマッピングで管理権限が広がらないようにする
認証を外部化すると便利ですが、監視システムでは外部認証に依存しすぎること自体がリスクになります。特に障害時に Zabbix へ入れない構成は避けるべきです。
まとめ
Zabbix は複数 LDAP サーバーを登録できますが、JIT プロビジョニングやグループマッピングまで含めると、単純なマルチテナント認証として扱うのは難しいです。
重要なのは、複数 LDAP を登録できること、JIT でユーザーを作れること、LDAP グループを Zabbix グループへマッピングできることを、それぞれ別の機能として理解することです。
現状では、Zabbix の LDAP / SAML 連携は便利ではあるものの、認証設計としては慎重に扱うべきです。監視システムでは、外部認証の便利さだけでなく、障害時のログイン経路、権限マッピング、ローカル管理者の保持まで含めて設計する必要があります。
書籍
認証と認可 Keycloak入門 第2版
Keycloak、SSO、OAuth、OpenID Connect、認証・認可の設計を確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
参考
- Zabbix Documentation – LDAP authentication
- Zabbix Documentation – SAML authentication
- Zabbix Blog – Just-in-Time user provisioning explained
Related posts:
CentOS 8 で Zabbix エージェントを設定する – passive / active と監視方式の使い分け
QNAP Zabbix エージェントの有効化
CentOS 8 OpenLDAP LDAP クライアント – ldapsearch と証明書信頼設定
CentOS 8 SSSD Linux クライアント – LDAP 認証の基本設定
Ubuntu 22.04 389 Directory Server #2 – TLS 有効化と LDAPS 設定
Ubuntu 22.04 389 Directory Server #3 – ベースエントリーの登録
Ubuntu 22.04 389 Directory Server #4 – BIND ユーザーとアクセス制御
Ubuntu 22.04 389 Directory Server #5 – グループとユーザーの登録
Ubuntu 22.04 SSSD – LDAP ユーザーで Linux 認証する
Ubuntu 22.04 OpenLDAP LDAP ユーティリティ – ldapsearch / ldapadd / ldapmodify の使い方
LDAP クライアント Apache Directory Studio は開発終了なのか
LDAP より SAML/OIDC が高セキュリティという幻想 – 認証方式は適材適所で選ぶ