Confluence での監査ログの連携

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

Confluence Data Center は、データベースとログ ファイルに監査ログを書き込みます。これにより、監査ログを長期保存用のデータベースから定期的にエクスポートする手間は不要になります。なお、このファイルの主な目的は、Confluence Data Center をサードパーティ製のログ記録プラットフォームと簡単に連携することです。

On this page:

イベントの対象範囲とログの保存期間

[監査ログ設定] メニューは、データベースとログ ファイル両方の監査ログの対象範囲を制御します。ただし、このメニューでは、ログ ファイルの保存期間は制御できません。 

ログ ファイルの保存期間はログの切り替えで制御されます。製品では基本的なログ切り替えを使用してログの量を管理しています。監査ログ ファイルは次の場合に自動的にアーカイブされます。
  • ノードの時刻が深夜 12:00 を迎えた場合、または
  • 監査ログ ファイルが 100 MB に達した場合 

ノードでログ ファイルの保存件数が上限に達すると、最も古いものが削除されます。既定では、ログ ファイル数の上限は 100 件です (現在の監査ログ ファイル + アーカイブ 99 件)。各アプリケーション ノードで、これらのログ ファイルに対して十分なディスク空き容量を割り当てていることを確認してください。既定設定の 100 件のファイルでは、10 GB を割り当てる必要があります。 

ログ ファイルの詳細

Confluence Data Center は、監査ログをホーム ディレクトリにリアルタイムで書き込みます。これらのログは監査ログ ファイルに書き込まれます。クラスタ化された Confluence Data Center デプロイでは、各アプリケーション ノードのログ ファイルがそれぞれのローカル ホーム ディレクトリに作成されます。 

場所

監査ログ ファイルをサードパーティ製のログ記録プラットフォームと連携するには、ファイルの正確な場所を把握しておく必要があります。これはホーム ディレクトリの設定方法によって異なる場合があります。ローカルのホーム ディレクトリの詳細については、「Confluence ホームとその他の重要なディレクトリ」記事をご確認ください。

クラスタ化された Confluence Data Center デプロイでは、通常、監査ログ ファイルのディレクトリはすべてのノードで同じになります。

詳細については、「CloudWatch Logs エージェントのリファレンス」を参照してください。Ansible を使用してこれを自動化する方法については、https://bitbucket.org/atlassian/dc-deployments-automation/src/master/ にあるデプロイメント プレイブックをご覧ください。

ファイル名

監査ログのファイル名には次のような命名規則が使用されます。

YYYYMMDD-XXXXX.audit.log


XXXXX の部分は 00000 から始まる 5 桁の数字で、同じ日 (YYYMMDD) にアーカイブされた監査ログ ファイルの何番目にあたるかを示します。たとえば、本日 (2020 年 1 月 1 日) にアーカイブされたログ ファイルが 5 件ある場合、次のようになります。

  • 最も古いアーカイブ ログ ファイルは 20200101.00000.audit.log
  • 現在の監査ログ ファイルは 20200101.00005.audit.log 

形式

それぞれの監査ログは JSON エントリの形式で監査ログ ファイルに書き込まれます。ファイルの各行が 1 つのイベントを表します。必要に応じて正規表現を使用して簡単な検索を行うことができます。

ログ記録エージェントとの連携

大多数のエンタープライズ環境では、サードパーティ製のログ記録プラットフォームを使用して、すべてのホストのログを集計、保存、管理しています。AWS CloudWatch や Splunk などのログ記録プラットフォームはエージェントを使用して、環境内の各ホストのログを収集します。これらのエージェントは各ホストにインストールされ、ローカル ログを収集して、集計、分析、監査、および保存を一元的に行う場所に送信します。

ご利用のログ記録プラットフォームがこのようにエージェントを使用する場合、各ノードにエージェントを構成して監査ログ ファイルを直接監視できます。ほとんどの大手プラットフォームのログ記録エージェント (AWS CloudWatch、Splunk、ELK、Sumo Logic など) には監査ログ ファイルとの互換性があります。 

Amazon CloudWatch エージェント

アトラシアンでは、AWS でのデプロイを簡単にするため、Confluence Data Center 用のクイックスタートを提供しています。このクイック スタートを使用すると、Confluence Data Center を、Confluence Data Center を監視する Amazon CloudWatch インスタンスとともにデプロイできます。 

Amazon CloudWatch をセットアップするには、Enable CloudWatch Integration パラメーターのデフォルト設定 (つまり Metrics and Logs) を使用します。クイック スタートは次に Amazon CloudWatch エージェントを構成して、各ノードの監査ログ ファイルからログを収集します。エージェントはこれらのログを confluence-<aws-stack-id>-audit という名前の独立したログ グループに送信します。

また、クイック スタートは、既定のダッシュボードをセットアップして、各監査ログ ファイルからのログを含む収集されたデータを読み取りやすい形式で表示します。関連情報については、「ログ グループとログ ストリームを操作する」をご参照ください。

ここをクリックして手動での構成手順を確認

手動での構成

必要に応じて、Amazon CloudWatch エージェントを手動で構成して監査ログ ファイルを収集することもできます。これを実行するには、エージェント構成ファイルで次のパラメータを設定します。

  • file: これを <local home directory>/log/audit/* に設定します。ホーム ディレクトリへの絶対パスを設定するようにします。 
  • log_group_name と log_stream_name: これらを使用して、Confluence Data Center の監査ログを特定のログ グループまたはストリームに送信します。


Splunk Universal Forwarder

Splunk Enterprise または Splunk Cloud では Splunk Universal Forwarder をログ記録エージェントとして使用できます。これを行うには、各アプリケーション ノードに Universal Forwarder ををインストールする必要があります。

また、各ノードの監査ログ ディレクトリをいずれかのフォワーダーの入力として定義する必要もあります。これにより、フォワーダーは監査ログ ディレクトリからのすべてのログを、設定済みのレシーバーに送信するように設定されます。フォワーダーの入力を定義する 1 つの方法は、Splunk の CLI を使用することです。Linux システムの場合、各アプリケーション ノードで次のコマンドを使用します。

./splunk add monitor <local home directory>/log/audit/

各ノードで Splunk Universal Forwarder を構成する方法の詳細については、以下のリンクをご参照ください。

Splunk でのソース・タイプの設定

ソース タイプは、Splunk インデクサーがデータを解析する方法を定義します。 これには、データをイベントに分離する方法、イベントを解析する方法、イベントからタイムスタンプを抽出する方法が含まれます。

Splunk で監査ログを正しく解釈するには、インデクサーに アトラシアン監査ログ用の新しいソース タイプを追加し、設定したフォワーダーに送信データにそのソース タイプでタグを付けるように指示する必要があります。

次のプロパティを持つ atlassian-audit という名前のソース タイプを作成する必要があります。

[atlassian-audit]

pulldown_type = true

SHOULD_LINEMERGE = false

disabled = false

category = Custom

LINE_BREAKER = ([\r\n]+)

TIME_FORMAT = %s,"nano":%9N

TIME_PREFIX = \"timestamp\":{\"epochSecond\":

その方法の詳細については、「 Splunk でソース タイプを作成する方法」を参照してください。

ソース タイプを作成したら、送信データに新しいソース タイプのラベルを付けるようにフォワーダーを設定する必要があります。 これを行うには、inputs.conf ファイルで設定したモニターに sourcetype プロパティを追加します。 例えば:

[monitor:///path/to/jira/home/log/audit]

disabled = false

sourcetype=atlassian-audit

詳細については、次のリンクを参照してください。

Filebeat (ELK Stack 用)

ELK Stack 内で Filebeat プラグインを使用して、各ノードの監査ログ ファイルからログを収集できます。現在の監査ログ ファイルにログが書き込まれるたびに、Filebeat がそのログを Elasticsearch または Logstash に転送します。

これをセットアップするには、まず、各アプリケーション ノードに Filebeat をインストールします。次に、監査ログ ファイル ディレクトリを Filebeat の入力として設定します。これを実行するには、そのディレクトリを各ノードの  filebeat.yml 構成ファイルの filebeat.inputs セクションに path として追加します。たとえば、次のようになります。

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - <local home directory>/log/audit/

Sumo Logic の Installed Collector

Sumo Logic インスタンスをお持ちの場合、Installed Collector を使用して、各ノードの監査ログ ファイルのログを収集できます。これを実行するには、まず、各ノードに Collector をインストールします。次に、<local home directory>/log/audit/* Local File ソースとして各ノードのコレクタに追加します。




最終更新日 2021 年 8 月 17 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.