0

私は認証/承認を処理するシステムに取り組んでおり、個人のログイン試行、アクセス許可/ユーザーの変更、試行の失敗などを追跡する必要があります。この情報をデータベースに解析できるようにしたいと考えています。後でさらに分析/取得するため。

現在の実装では、ロギングフレームワーク（この場合はLog4jですが、これは重要ではありません）を使用してログに記録される自作の標準を使用しています。ロギングフレームワークは、この情報を追跡するための適切なメカニズムですか？そうではないように私には思えます。私は常に、ロギングがコードの剖検の一形態であることを理解していました。デバッグなどの目的で何が起こったのかをより詳しく知るためです。これは、私にはレポートメカニズムのように思えます。この種の問題の基準はありますか？人々が使用する標準的なソリューション/フォーマットはありますか？ロギングフレームワークを使用することはこれに適したソリューションですか、それともこのタイプのデータを処理するためのより良い方法がありますか？この情報を見て、利害関係者に提示するときに、どのような情報源を参照できますか？

注意する必要があります-ログに記録されているデータは、コンプライアンス/セキュリティ標準（パスワードなしなど）に基づいてすでにフィルタリングされており、すべてのログ記録は内部環境で行われます。認証・承認システムの変更情報を管理できる方法をもっと探しています。

4

2 に答える 2

2

監査に（そしておそらく診断情報やトレース情報のログにも）log4Jを使用しているようです。あなたの質問に答えるには：

ロギングフレームワークは、この情報を追跡するための適切なメカニズムですか？

簡単な答えは「いいえ、ロギングフレームワークは正しいメカニズムではありません」です。ロギングフレームワークに存在する場合、監査フレームワークとして使用できるようにする特定の属性があります。

これらの要件のいくつかを以下に示します。log4jを使用してこれらのいくつかに対応できます。これは網羅的なものではありません。より包括的なリストを導き出すために、監査フレームワーク（LAUSなど）の実装を検討することをお勧めします。

  • 監査フレームワークは、イベントのフェイルセーフ監査を保証する必要があります。これは、アプリケーションがフレームワークをどのように使用するかによって異なりますが、基本的な要件は、監査が失敗した場合、アプリケーションも失敗することです。イベントを監査できない場合は、アプリケーションが要求を処理しようとしないでください。ロギングフレームワークは通常、この要件に準拠していません。
  • 監査フレームワークは、理想的には、ライトワンスで読み取り専用のストアを提供する必要があります。つまり、監査ログに書き込まれたイベントは消去する必要があり、消去しないでください。監査フレームワークは通常、この保護を単独で実装するのではなく、他の要素の組み合わせに依存して、ログが改ざんされないようにします。
  • 監査フレームワークでは、別のシステムに監査ログを保存できるようにする必要があります。これにより、1つのシステムが侵害されても、監査ログが自動的に侵害されることはありません。
  • フレームワークは重要な情報の取得も可能にする必要があり、理想的にはこれをプログラマーに任せるべきではありません。重要な情報は、同期されたタイムソースからのタイムスタンプ、リクエストを担当するユーザー（またはユーザーを識別するための情報）、リクエストのソース、リクエストのステータス（成功したか失敗したか）、リクエストの処理など。
于 2011-05-19T18:20:11.543 に答える
0

ロギングフレームワークは、ここで使用するのに必ずしも悪いことではありません。通常、ファイルへのログ記録は、データベースへのログ記録よりも高速です。ただし、Log4jを使用すると、既存のJDBCアペンダーを実装または使用できます。これにより、ログに記録されるときにすべてのデータがデータベースに挿入されます。信頼性を確保するために、ログデータベースに障害が発生した場合に備えて、監査ログ用にファイルとデータベースの両方のアペンダーを構成して、バックアップをとることができます。

他の選択肢としては、データをロギングデータベースに直接挿入するセキュリティ/ビジネスロジックに関するAOPアスペクトが考えられます。

ただし、この種のデータに共通の基準はないと思います。

于 2011-05-19T18:08:59.227 に答える