Fessの監査ログに、パスワード変更の実行者と対象、管理APIでのトークン拒否、アクセスのHTTPメソッドと対象IDを残す改善が提案されています。SSO失敗の記録も含め、運用時の確認点を整理します。
パスワードを変更した人と対象を区別する
PR #3723では、パスワード変更の成功時にUPDATE_PASSWORDを記録します。userが実行者、targetが変更対象のユーザー名で、パスワードやハッシュは含めません。共通のipとtimeも付与されます。
対象はログイン画面からの変更、POST /api/v2/auth/password、管理画面でのユーザー更新、管理REST APIのユーザー更新です。管理者の更新では、パスワード欄に空白以外の入力がある場合だけ記録します。新規ユーザー作成や変更失敗は、この新しい成功イベントの対象ではありません。
これにより、管理者によるリセットと本人による変更を実行者・対象の組み合わせで調べやすくなります。ログにユーザー名が残るため、閲覧権限と保存期間も運用に合わせて確認します。
管理APIのトークン拒否も調査対象にする
PR #3722では、/api/admin/*へのリクエストがアクセストークンの欠落・不明・権限不足で拒否された際に、ACCESS_DENIEDとパスを記録します。HTTP応答は引き続き401で、トークンそのものやそのパラメーターをログへ追加する変更ではありません。セッションがなければuserは「-」です。
以前紹介した管理画面のアクセス拒否から、管理REST APIのトークン確認へ記録対象を広げる提案です。一般のAPIすべてに同じ監査を追加するものではありません。
ACCESSにメソッドと対象IDを加える
PR #3724は、従来のpathとexecuteにmethodを追加し、リクエストパラメーターに空白以外のidがある場合はidも残します。たとえば削除操作なら、POSTかどうかと対象エントリーのIDを確認しやすくなります。フォーム全体を保存することはありません。
idはリクエストパラメーターから読み取ります。JSON本文の任意のIDまで抽出する仕組みではなく、multipartのアップロードではidの読み取りを省略します。リクエストが関連付いていない場合は従来の項目だけです。
ACCESSは処理の前に出るため、更新や削除が成功した証拠にはなりません。入力エラーやCSRF拒否まで含めた結果判定は、このPRの対象外です。対象IDと操作の試行を調べ、実際の成否は画面・API応答や別の記録と照合します。
SSO失敗は記録される経路を確認する
マージ済みのPR #3720では、SSOが設定され、認証処理がSsoLoginExceptionを投げた経路にLOGIN_FAILUREを追加します。SsoStateExceptionも対象ですが、認証ユーザーを取得できないためuserやclassはなく、例外メッセージや資格情報も入りません。
資格情報なしのアクセスや、IdPへのリダイレクト・SPNEGOの401チャレンジは失敗イベントにしません。SAMLやOIDCのプラグインが拒否をnullで返す経路も対象外なので、「すべてのSSO失敗を数えられる」とは扱わないでください。
初期値と確認手順
これらのPRはイベントごとの有効化スイッチを追加しません。変更を含むビルドと、監査ロガーの出力設定が必要です。ソースの標準設定ではfess.log.auditはINFOでaudit.logへ出力します。
app.audit.log.formatの初期値は空です。この場合、FESS_APP_TYPE=dockerならECS形式、それ以外ならLTSV形式になります。明示的にecsを指定した場合もECSです。ECSではlabels.action、labels.user、labels.targetなどの項目を確認し、LTSVではaction、user、targetなどのフィールドを確認します。script.audit.log.enabledはスクリプト実行用で、今回のイベントを切り替える設定ではありません。
検証環境で、本人のパスワード変更と管理者のリセット、無効なトークンによる管理APIアクセスを順に試し、期待するイベントと対象が記録されることを確認します。ACCESSの集計処理は追加フィールドと、idが存在しないレコードの両方を扱えるようにします。既存環境で出力を変更している場合は、標準値だけで判断せず実際のログを確かめてください。