ownCloud Enterpriseでアクティビティログ監査を有効にする方法

ownCloudのファイルアクティビティフィードを有効にしただけでは、管理者監査ログは作成されません。ownCloud Server Enterpriseの場合、関連するコンポーネントはEnterprise専用の監査アプリです。このアプリは、より広範なユーザーおよび管理者の操作をサーバーログシステムに記録し、必要に応じて、これらの記録を専用ファイルやログ分析プラットフォームにルーティングできます。

このガイドは、ownCloud Server 11.0 向けに作成されたクラシックデプロイメントの手順に基づいています。メニューのラベルや設定方法は、リリースやパッケージによって異なる場合があります。ownCloud Infinite Scale (oCIS) は別の監査サービスを使用するため、これらのサーバー手順を oCIS デプロイメントには適用しないでください。

ownCloudの監査では何が記録されますか？

監査アプリは、ユーザーのサインインとサインアウト、ファイルの作成、削除、移動、ゴミ箱操作とバージョン管理、共有と権限の変更、グループとユーザーの管理、コメント、タグ、ユーザー設定の変更、アプリの有効化または無効化、なりすまし、OCCコマンドの実行などのイベントをログに記録できます。エントリには、時間、ユーザー、リクエストの詳細、リモートアドレス、アプリ、メッセージ、固有のアクション名などの共通フィールドが含まれます。イベントフィールドの詳細は、アクションによって異なります。

監査機能はアクティビティアプリとは異なります。アクティビティは、ファイルやフォルダのイベントをユーザー向けに表示するストリームです。監査機能は、管理者によるレビュー、コンプライアンスワークフロー、およびセキュリティ関連イベントの分析を目的としています。サーバー側の記録が必要な場合はエンタープライズ監査アプリを有効にし、コンテンツの変更をユーザーが手軽に確認したい場合はアクティビティを使用してください。

監査を有効にする前に

• デプロイメントがownCloud Server Enterpriseであり、監査アプリがインスタンスで利用可能であることを確認してください。
• ownCloudの管理者アカウントを使用してアプリを有効にしてください。システム管理者は、ログ設定を行うためにシェルまたはコンテナへのアクセス権限が必要になる場合もあります。
• 十分なディスク容量を備えた専用のログ保存先を選択してください。Webサーバーまたはコンテナがその場所に書き込みできることを確認し、読み取り権限を持つユーザーを決定してください。
• 大量の監査ストリームを有効にする前に、保持およびローテーションポリシーを設定してください。監査レコードには、ユーザーID、IPアドレス、ファイルパス、クライアントの詳細、共有メタデータなどが含まれる場合があります。

ステップ1：監査アプリを有効にする

ownCloud管理者としてサインインし、管理インターフェースの「アプリ」エリアを開きます。「監査」を見つけて有効にします。アプリが表示されない場合は、エンタープライズライセンス、サーバーリリース、ownCloud Marketplaceまたはベンダーサポートチャネルで互換性のあるアプリパッケージを確認してください。標準のアクティビティアプリが代替として使用できるとは考えないでください。

ステップ2：監査メッセージを専用ファイルにルーティングする

ownCloudでは、監査メッセージを一般的なサーバーログから分離することを推奨しています。専用ファイルを使用することで、監査データのアクセス許可、保持期間、収集ルールの設定が容易になります。最新のServer 11.0ドキュメントには、コンテナ環境変数の例が記載されています。宛先を、デプロイメント内に存在し、ownCloudサービスが書き込み可能なパスに調整してください。

OWNCLOUD_LOG_CONDITIONS=[{"apps":["admin_audit"],"loglevel":0,"logfile":"/mnt/data/files/admin_audit.log"}]

この条件は、admin_auditアプリからのメッセージを指定されたファイルに転送します。ドキュメントに記載されている例では、監査メッセージを別のファイルにルーティングすることで、グローバルなログレベルフィルタをバイパスし、レベルに関係なくメッセージを記録します。表示されているパスは、Docker マウントされたデータボリュームに関連付けられたものであり、あくまで例であり、汎用的なパスではありません。環境変更を永続化するには、デプロイメントの構成方法を使用し、コンテナオーケストレーションプロセスで必要な場合にのみサービスを再起動または再作成してください。

を介して構成されたインストールの場合config.php、ownCloud のアプリ構成リファレンスにもlog.conditionsキーが記載されています。パスをホストの実際のデータディレクトリに合わせて調整し、配列全体を置き換えるのではなく、既存の構成エントリを保持してください。

'log.conditions' => [
  [
    'apps' => ['admin_audit'],
    'logfile' => '/var/www/owncloud/data/admin_audit.log'
  ],
],

監査出力を別途ルーティングせずに通常のownCloudログに保持する場合、ownCloudの監査ガイドによると、サーバーのログレベルを1（INFO）または0（DEBUG）に設定する必要があります。そうしないと、監査メッセージが書き込まれない可能性があります。別ファイル設定を使用すれば、グローバルログレベルへの依存を回避できますが、利用可能なディスク容量を監視する必要性はなくなります。

ステップ3：実際のイベントがファイルに到達したことを確認する

アプリを有効にしてログ設定を適用した後、ポリシーで許可されている制御イベントを1つ生成します。たとえば、指定されたテストアカウントで一時的なテストファイルを作成または削除します。次に、サーバー上の設定済み監査ログを確認します。一般的なエントリは、人間が理解しやすいアクティビティのタイムラインではなく、構造化データです。イベントの時刻、実行者、アプリケーション、アクション、および関連する詳細情報を探します。ファイル操作には、パス、所有者、またはファイル識別子が含まれる場合もあります。その他のイベントタイプには、それぞれ独自のフィールドがあります。

設定変更後に新しく生成されたアクションが表示されること、そのタイムスタンプがサーバーのタイムゾーンに合致していること、およびアクションとユーザーがテストと一致していることを確認してください。削除ログのテストには、機密性の高い本番ファイルを使用しないでください。何も表示されない場合は、監査アプリが有効になっていること、ログの保存先が正しく書き込み可能であること、環境変数またはPHP設定が実際に読み込まれていること、デフォルトログを使用している場合にサーバーのログレベルが適切であること、およびアクションの種類がインストールされている監査アプリのバージョンで記録されるアクションの種類に含まれていることを確認してください。

ステップ4：監査ファイルを保護、保管、および確認する

監査ログは、記録が常に利用可能で、アクセスが制御されている場合にのみ有効です。ファイルとディレクトリのアクセス許可は、アクセスが必要なオペレーティングシステムのアカウントと監査ロールに限定してください。ログのローテーションまたは収集を計画し、負荷の高いインスタンスがストレージをいっぱいにしないようにしてください。記録の保持期間は、社内ポリシーと法的義務に基づいて決定してください。ownCloudは、すべての組織に対して共通の保持期間を設定していません。

職務分担をより明確にするために、可能な限り監査ファイルを通常のウェブアクセス可能なファイル領域とは別の場所に保管し、どのシステム管理者と監査担当者が監査ファイルを読み取ったり管理したりできるかを定義してください。ownCloud のドキュメントには監査担当者の役割が記載されており、監査ログを一般的な ownCloud ログから分離する方法、システム管理者が監査ファイルにアクセスできない構成などについて説明されています。この結果はホストの権限とデプロイメントの構成方法によって異なるため、ファイル名を分けるだけで分離が実現すると想定するのではなく、セキュリティチームに確認してください。

Splunkを使用している場合は、ownCloudの監査に関するドキュメントで、admin_audit.logSplunk Universal Forwarderを使用した監視と、出力のJSON形式への解析について説明しています。ドキュメントにはサンプルinputs.confとprops.conf設定も含まれています。フォワーダーと受信システムを監査境界の一部として扱い、認証情報を保護し、ログ記録アーキテクチャでサポートされている場合は転送を暗号化し、イベントの到着を確認し、ギャップや取り込みの失敗をアラートで通知するようにしてください。

オプション：エントリに表示されるグループ名を制限する

デフォルトでは、監査コンテキストにはイベントに関連するユーザーと、それらのユーザーが所属するグループを含めることができます。このOWNCLOUD_ADMIN_AUDIT_GROUPS設定では、含めるグループ名を制限できます。この設定は、意図的なフィルタリングポリシーが適切な場合にのみ使用してください。グループコンテキストを減らすと、その後の調査で得られる情報が少なくなる場合があります。フィルタを適用する前に、結果として得られる記録とプライバシー要件を確認してください。

よくあるセットアップの問題

• 監査記録が表示されない場合は、エンタープライズ監査アプリが有効になっていることを確認してください。標準ログを使用している場合は、グローバルレベルがINFO（1）またはDEBUG（0）になっていることを確認してください。別のファイルを使用している場合は、アプリの状態と書き込み可能なパスを確認してください。
• 必要なファイルが見つかりません。ドキュメントに記載されているDockerパスは、ボリュームがマウントされていることを前提としています。コンテナの有効な構成、ボリュームマッピング、およびサービスユーザーの権限を確認してください。
• レコードが間違った場所に表示されます。アクティブOWNCLOUD_LOG_CONDITIONSなlog.conditions設定を確認し、重複または矛盾するルールを回避してください。
• フィードが不完全なようです。アクティビティと監査は別のアプリであり、監査アプリのカバー範囲はイベントの種類とバージョンによって異なります。ログ記録が壊れていると結論付ける前に、インストールされているバージョンでサポートされている既知のイベントを確認してください。
• コマンドラインイベントがありません: ownCloud にはデフォルトで CLI トリガーイベントが含まれています。admin_audit ignore_cli_eventsが に設定されているかどうかを確認してくださいyes。

最終確認チェックリスト

1. デプロイメントはownCloud Server Enterpriseで、互換性のある監査アプリが有効になっています。
2. 設定された保存先は存在し、ownCloudによる書き込みが可能であり、通常のユーザーコンテンツとして公開されていません。
3. 許可されたテストアクションは、妥当なタイムスタンプと実行者を持つ一致するレコードを作成します。
4. 権限、ローテーション、保持、およびアクセスに関する責任は文書化されています。
5. ログが外部に転送される場合、受信システムには最新のイベントが表示され、監視によって中断を検出できます。

リリース固有の詳細については、ownCloud Server Auditing のドキュメント、ownCloud アプリ構成リファレンス、およびownCloud の役割と監査の分離に関するガイダンスを参照してください。Infinite Scale 製品については、oCIS Audit Service のドキュメントを参照してください。