私たちが取り組んできたいくつかのプロジェクトでは、顧客から、データベースにさらに多くのユーザーアクションを記録するように求められました。彼らは、ユーザーがアプリケーションで実行するすべてのアクションを知りたいと思っていますが、すべての人間の相互作用をキャプチャして記録することは困難な場合があります。システムを介して実行されたデータのすべての変更をログに記録する必要がありました。この記事では、私たちが遭遇したいくつかの落とし穴と、それらを克服するために使用したアプローチについて説明します。
はじめに
私はソリューションアーキテクトとして働いています 金融サービスで。行を変更した最後のユーザーの記録を保持することが重要です。最も単純なケースでは、変更のタイムスタンプを記録して、トレーサビリティを得るだけで十分です。 変更の。これは、last_changedを含む顧客契約を格納するテーブルの簡単な例です。 ユーザーとタイムスタンプの列。
しかし、場合によっては、これだけでは不十分です。多くの場合、完全なトレーサビリティが必要です（「画像」の前後を含む データの）。場合によっては、可聴性も必要です。 （誰が、何を、いつ）。
残念ながら、私たちのシステムの多くは、トレーサビリティと監査可能性を提供するように設計されていませんでした。 リバースエンジニアが必要でした これらのビジネスオペレーション要件をシステムに組み込みます。
トレーサビリティ
場合によっては、トレーサビリティを簡単に実現できることがわかりました。一方で、他の人たちでは、それが難しいか、不可能でさえあることに気づきました。システムによっては、解決策が簡単な場合があります。データアクセスにより、データの前後の画像のログを簡単に挿入できる場合があります。このロギングは、結果がログファイルではなくデータベーステーブルに保存されるように実装できます。一部の製品では、永続性を通じてこれを簡単な方法で実現しました。 層。たとえば、これは休止状態で可能でした 。
ここでは、各監査証跡項目のエントリを確認できます。さらに、変更された各列の前後の値が表示されます。また、行が削除された場合は、その情報をfunctioncodeで保存します。 削除を示します。実行された「操作」（作成、更新、削除）の名前や説明ではなく、変更のタイプを指定する関数（C、R、D）のコードを格納するためにvarchar（1）を使用することを選択しました。 instance_key トレーサビリティのために、追加、変更、または削除されたアイテムの主キーが含まれています。
ただし、データアクセス層が必要な機能を提供していない可能性があります。他の製品については、データアクセス層はそうではありませんでした。そのような場合、トレーサビリティには複雑な変更が必要でした。たとえば、取得とログ記録が必要になる場合があります 変更前のデータの。私が書いたように、これは可能ですが、配置するのが複雑になる可能性があります。開発者は、行を変更する前に、各行の取得を作成する必要があります。選択せずに更新を実行することはできません。
トレーサビリティをどのように回避できますか？考えられる解決策の1つは、すべてのデータの開始状況、つまり、システムにロードされた静的データによって作成された開始状況を確実に把握することです。次に、すべての変更をログに記録する必要があります。言い換えれば、データのすべての「後」の画像は何ですか？このようにして、「ロールフォワード」が可能になります。 ロードされた静的データから」。それまでに行われたすべての更新が適用されます。これは理想的な状況ではありませんが、許容できる場合があります。
利用可能な情報が以前の値ではなく新しい値のみである場合は、単純なテーブルを使用できます。
可聴性
状況によっては、システムで実行されるすべてのアクションが完全に監査可能であることを確認する必要があります 。誰がいつログインしましたか？データの表示のみを含め、各ユーザーはシステムでどのようなアクションを実行しましたか？ユーザーが支払いを見た場合に重要になる可能性があるため、これは重要です。
きめ細かいトレースを実現するには データベースアクセスだけを見るのは難しいかもしれません。多くの場合、より高いレベルを調べて、実行されたアクションまたはサービスを調べる必要があります。場合によっては、各サービスコールを追跡して、ユーザーがいつ何をしたかを知ることができました。 Webサービスの入出力コントローラーを使用すると、サービス要求のログ記録が非常に簡単になりました。
これは、各ユーザーが実行するアクションを記録する単純なユーザー監査ログの例です。このアプローチに関するいくつかの問題については、次のセクション「証明」で説明します。
簡単な表の説明を以下に示します：
user_audit テーブルには、タイムスタンプが付けられたデータ監査エントリが含まれています。主キーはaudit_entry_timeで構成されます スタンプとuser_id およびbank_id プラスactionの名前 実行されます。フィールドには、その名前に対応する意味があります。監査テーブルには、resultが格納されます アクションのほか、実際のclass アクションを実行した、その入力parameters およびerrors 。
これは、特定のテーブルで変更されたデータの前後の画像を記録する監査証跡の別の例です（実行されたアクション、ユーザーの資格情報、タイムスタンプとともに）。
audit_trail テーブルには、データの前後のイメージの監査エントリが含まれています。主キーはaudit_gen_keyで構成されます これは、アプリケーションによって生成されたキーです。フィールドには、その名前に対応する意味があります。この監査証跡エントリが記録されるデータベーステーブルの名前は、modified_tableに保存されます。 に加えて、「前」の画像はprev_valueに保存されます new_valueの「後」の画像 。 module 変更とfunct_typeを実行しています 変更（作成、更新、削除）も保存されます。最後に、user_idの監査情報 （および対応するbank_id ）と変更のタイムスタンプ（date_last_changed ）。
それから私たちは挑戦しました。トレーサビリティ情報と監査可能性情報の両方をログに記録する場合、ログは2回発生します。監査の観点からすると、これは厄介です。監査人は、これら2つのログ間で情報が同じであることを確認する必要があります。
証明
もう1つの課題は、すべてのユーザーアクションを確実に記録することでした。 。これは、金融サービス業界の監査人が必要とすることがよくあります。
今、私たちは本当の挑戦をしています。私たちのソリューションは、中央のトレーサビリティと監査可能性のロギングを確保することでした。中央の「インターフェース」により、そのインターフェースのすべての実装にロギングが含まれるようになります。適切なすべてのクラスがインターフェイスを実装していることを確認するのは簡単でした。
もちろん、これはロギングの100％の証拠を保証するものではありません。すべての適切なクラスが必要に応じてログに記録されていることは、強力な安全チェックです。
結論
新しいビジネス機能を既存のシステムにリバースエンジニアリングすることは、常に課題です。これは、実装された機能がコアに移行する場合にさらに当てはまる可能性があります。