はじめに
企業の情報セキュリティ要件は年々厳しくなっています。 検索システムには膨大な機密文書が集約されるため、適切な認証・認可の仕組みが不可欠です。
本記事では、第5回で紹介したロールベース検索をさらに発展させ、SSO（シングルサインオン）との連携を中心としたセキュリティアーキテクチャを設計します。
対象読者
エンタープライズ環境で Fess を運用する方
SSO 連携（OIDC、SAML）の設計を行う方
ゼロトラストセキュリティの概念を理解している方
セキュリティ要件の整理
典型的な企業のセキュリティ要件を整理します。
| 要件 | 説明 |
|---|---|
| シングルサインオン | 既存の IdP と連携し、追加のログイン操作を不要にする |
| ロールベースアクセス | ユーザーの所属・権限に応じた検索結果の制御 |
| 通信の暗号化 | HTTPS によるすべての通信の暗号化 |
| API アクセス制御 | トークンベースの API 認証と権限管理 |
| 監査ログ | 誰が何を検索したかの記録 |
SSO 連携の選択肢
Fess がサポートする SSO プロトコルと、それぞれの適用場面を整理します。
| プロトコル | 代表的な IdP | 適用場面 |
|---|---|---|
| OpenID Connect | Entra ID、Keycloak、Google | クラウド環境、モダンな認証基盤 |
| SAML 2.0 | Entra ID、Okta、OneLogin | エンタープライズ環境、既存の SAML IdP がある場合 |
| SPNEGO/Kerberos | Active Directory | Windows 統合認証環境 |
OpenID Connect / Entra ID による SSO 連携
最もモダンで推奨されるアプローチです。 Fess では汎用の OpenID Connect 連携に加えて、Entra ID（Azure AD）専用の連携機能も提供されています。 ここでは Entra ID との連携を例に解説します。
認証フローの概要
利用者が Fess にアクセス
Fess が Entra ID の認証画面にリダイレクト
利用者が Entra ID で認証（MFA 含む）
Entra ID が認証トークンを Fess に返却
Fess がトークンからユーザー情報とグループ情報を取得
グループ情報をもとにロールを割り当て
ロールに基づいた検索結果を提供
Entra ID 側の設定
Entra ID でアプリケーションを登録
リダイレクト URI を設定（Fess の OIDC コールバック URL）
必要な API 権限を付与（User.Read、GroupMember.Read.All など）
クライアント ID とシークレットを取得
Fess 側の設定
管理画面の ［システム］ > ［全般］ のページ内で SSO の接続情報を設定します。 主な設定項目は以下の通りです。
OpenID Connect プロバイダの URL（Entra ID のエンドポイント）
クライアント ID
クライアントシークレット
スコープ（openid、profile、email など）
グループクレームの設定
グループとロールのマッピング
Entra ID のグループを Fess のロールにマッピングします。 これにより、Entra ID でのグループ管理がそのまま検索結果の制御に反映されます。
例: Entra ID のグループ「Engineering」→ Fess のロール「engineering_role」
SAML による SSO 連携
既存の SAML IdP がある環境では、SAML 連携が適しています。
認証フローの概要
SAML では、SP（Service Provider = Fess）と IdP 間で SAML Assertion をやり取りします。
利用者が Fess にアクセス
Fess が SAML AuthnRequest を IdP に送信
IdP が利用者を認証
IdP が SAML Response（ユーザー属性を含む）を Fess に返却
Fess がユーザー属性からロールを割り当て
Fess 側の設定
SAML 連携には、以下の設定が必要です。
IdP のメタデータ URL または XML ファイル
SP のエンティティ ID
Assertion Consumer Service URL
属性マッピング（ユーザー名、メールアドレス、グループ）
SPNEGO / Kerberos 連携
Windows Active Directory 環境では、SPNEGO/Kerberos による統合 Windows 認証が利用できます。 ドメインに参加した PC からブラウザでアクセスすると、追加のログイン操作なしに自動的に認証されます。
この方式は利用者にとって最も透過的ですが、設定は最も複雑です。 Active Directory のドメイン環境が前提となります。
通信の暗号化
SSL/TLS の設定
本番環境では、Fess へのすべてのアクセスを HTTPS で行うことが推奨されます。
リバースプロキシ方式（推奨）
Nginx や Apache HTTP Server をリバースプロキシとして配置し、SSL 終端を行います。 Fess 自体は HTTP で動作し、リバースプロキシが HTTPS を処理します。
[クライアント] --HTTPS--> [Nginx] --HTTP--> [Fess]
この方式のメリットは、証明書の管理がリバースプロキシに集約されることです。
Fess 直接設定方式
Fess の Tomcat に直接 SSL 証明書を設定することも可能です。 小規模環境やリバースプロキシを設置しない場合に適しています。
API アクセスのセキュリティ
第11回で紹介した API 連携のセキュリティを強化します。
トークンの権限設計
アクセストークンに適切な権限を設定します。
| 用途 | 権限 | 備考 |
|---|---|---|
| 検索ウィジェット用 | 検索のみ（読み取り専用） | フロントエンドで使用 |
| バッチ処理用 | 検索 + インデクシング | サーバーサイドで使用 |
| 管理自動化用 | 管理 API アクセス | 運用スクリプトで使用 |
トークンの管理
定期的なローテーション（3〜6ヶ月ごと）
不要になったトークンの即時無効化
トークンの利用状況の監視
監査とログ
検索システムにおける監査ログは、セキュリティインシデントの調査やコンプライアンス対応に重要です。
Fess が記録するログ
検索ログ: 誰が何を検索したか（管理画面の ［システム情報］ > ［検索ログ］ で確認可能）
監査ログ (
audit.log): ログイン・ログアウト・アクセス・権限変更などの操作が統一的に記録される
ログの保管
セキュリティ要件に応じて、ログの保管期間を設定します。 コンプライアンス上の要件がある場合は、外部のログ管理システム（SIEM）への転送も検討します。
まとめ
本記事では、エンタープライズ環境での Fess のセキュリティアーキテクチャを設計しました。
SSO 連携の3つの選択肢（OIDC、SAML、SPNEGO）とそれぞれの適用場面
OpenID Connect による Entra ID 連携の設計
SSL/TLS による通信の暗号化
API アクセストークンの権限設計
監査ログの管理
セキュリティと利便性のバランスを取りながら、安全な検索基盤を構築しましょう。
次回は、検索インフラの自動化について扱います。