監視対象のホームサーバーアプリの外部に監査ログを保存する理由

監視対象のホームサーバーアプリの監査ログは、アプリの外部に保存すべきです。侵害されたプロセスは、多くの場合、自身のローカルにある証拠を変更、削除、または停止できるためです。

アプリケーションログには、管理者の操作、ログイン失敗、ファイルアクセス、トークンの使用、オートメーションの実行、AIツールの呼び出し、権限変更、削除などが記録されることがあります。これらの記録が最も価値を持つのは、アプリケーションが誤動作している、または攻撃者に制御されているときです。しかし、それは同時に、書き込み可能なデータベースやボリュームに保存されたログが最も信頼できなくなる瞬間でもあります。外部収集により、障害と権限の境界を分離できます。以下では、リモート転送、追記専用ストレージ、相関分析、保持期間、プライバシー、そして証拠が維持されることを証明するために必要なテストについて説明します。

ローカルログはアプリの障害および権限の境界を共有する

通常、アプリケーションにはローカルログの作成とローテーションを行う権限が必要です。攻撃者がアプリケーションのIDやデータベース管理者ロールを取得すると、同じ権限によって、ログの選択的な削除、タイムスタンプの変更、またはログ全体の消去が可能になる場合があります。

OWASP Logging Cheat Sheetは、転送中および保存後のログ改ざんに対する保護を求めています。監視対象のプロセス内部に唯一のコピーを保存すると、疑わしいコンポーネントの権限下に証拠を置くことになります。

ファイルシステムのスナップショットで削除されたローカルログの一部を復元できる場合もありますが、実行頻度が低すぎる可能性があり、侵害された同じ管理者アカウントやストレージアカウントによって書き換えられることもあります。

リモート転送により、攻撃者は別の境界を越える必要がある

ログフォワーダーは、イベントの発生時に別のサービスやマシンへ送信します。受信後は、監視対象アプリが過去のエントリを書き換えるためのAPI権限やファイルシステム権限を持たないようにする必要があります。

集中ログ管理では、複数のシステムからのイベントをまとめて検索できる独立したリポジトリに記録を集約します。ソースアプリが侵害されても、保存された監査履歴の制御権が自動的に与えられることはありません。

保存先には、別の低消費電力サーバー、セキュリティアプライアンス、マネージドログサービス、または別のIDで管理する分離されたNASデータセットを利用できます。物理的な距離よりも独立性が重要です。

一時的な障害に備えてローカルでバッファリングする場合は、バッファの容量に上限を設け、復旧後に転送してください。そうしないと、ログサーバーの障害によってアプリのボリュームが満杯になったり、気付かないまま証拠の空白が生じたりする可能性があります。

追記専用および改ざん検知可能なストレージが履歴を保護する

管理者や取り込み用の認証情報で過去の任意の行を更新できる場合、リモートに保存するだけでは不十分です。ストレージモデルは、既存イベントの編集よりも新しいイベントの追加を優先するべきです。

追記専用ログは、通常のインプレース更新や削除を行わずに、順序付けられた記録を保持します。イミュータブルなオブジェクト保持、書き込み専用ポリシー、ハッシュチェーン、署名付きチェックポイントを組み合わせることで、不正な変更をさらに検知しやすくできます。

1人の管理者がすべてのシステムと復旧キーを管理している場合、完全に改ざん不可能な設計はありません。現実的な目標は、独立したIDとストレージ制御を通じて、改ざんへの耐性を高め、変更の証拠を残すことです。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

外部ログはサービス境界をまたぐ操作を相関分析できる

1つの家庭内ワークフローが、リバースプロキシ、IDプロバイダー、アプリ、データベース、ストレージサービス、オートメーションエンジン、外部APIを経由することがあります。ローカルのアプリログで確認できるのは、そのシーケンスの一部だけです。

OWASPは、データを取得してツールを実行するシステムにおいて、監査テレメトリの欠如を可視性の問題として挙げています。共有リクエストID、ユーザーID、イベントID、送信元アドレス、タイムスタンプがあれば、外部ログストアでどのサービスが各段階を実行したのかを再構成できます。

時刻同期も、この証拠の一部です。大きな時刻のずれがあると、正しい複数サービス間のシーケンスが、順序どおりでないように見えることがあります。

ZimaSpaceのコンテナログを分離するというガイダンスは、運用ログの増加やローテーションが、再作成できないアプリケーションの状態と絡み合うことも防ぎます。

保持期間とアクセス制御によって証拠を有用かつ非公開に保つ

監査ログには、ユーザー名、IPアドレス、ファイル名、検索語、デバイスID、認証情報の失敗、家庭内の行動パターンなどが含まれる場合があります。アプリの外部に移すことで、機密性の高いメタデータが新たな場所に集中します。

現代の改ざん耐性ログに関するガイダンスでは、ログ完全性の制御を、収集、転送、保存、アクセス、レビューの組み合わせとして捉えています。暗号化された転送、専用の取り込み用ID、読み取り専用の分析者アクセス、文書化された保持期間、転送の空白を知らせるアラートを使用してください。

既知の管理イベントを発生させ、それが外部に到着したことを確認してから、アプリを削除または再作成し、過去の記録を引き続き検索できることを確認してテストします。次にコレクターとの接続を切断し、ログが完全であるかのように振る舞うのではなく、システムが空白を報告することを確認してください。

アプリが侵害されても今後の報告を中断させることはできるが、独立したストアにすでに受け入れられた証拠を気付かれないまま書き換えることはできないとき、ログアーキテクチャは成功しています。