5

私は、アプリケーションの設計に関しては比較的熟練していると考えていますが、機密データを扱う必要があったことは一度もありません。私は、監査証跡のベスト プラクティスとは何か、そしてそれらをどのように実装する必要があるのか​​について疑問に思っていました。今はしなくてもいいのですが、医療機関から何か仕事を頼まれたら、安心して相談できるといいですね。

「教師」、「クラス」、「学生」がすべて多対多の「成績」テーブルで正規化された「学校」データベースがあるとします。何を記録しますか？「成績表」のすべての挿入/更新? 更新のみ (たとえば、子供が侵入して成績を変更したい場合、これは危険信号を送信する必要があります)? これは、どれだけ偏執的になりたいかによって完全に異なりますか? ベストプラクティスはありますか?

これはデータベースで行うべきことですか? (各クエリをログに記録する「監査」テーブルに行を挿入する、機密性の高い SELECT ごとのトリガー?) 何をログに記録する必要がありますか? Oracle/DB2 に自動的に組み込まれている機能はありますか? これはアプリケーション側のロジックである必要がありますか?

機密データの処理方法に関する正式なドキュメント/本を誰かが持っている場合 (DoD の「Trusted Computing」仕様ではありませんが、その線に沿ったものです:P)、私はそれを感謝します。この質問が非常に漠然としていて申し訳ありません。これはアプリケーションごとに異なることを認識しています。機密データの取り扱いに関する詳細な経験をお聞きしたいだけです.

4

2 に答える 2

4

最初に理解しておくべきことは、選択した DBMS のネイティブの監査機能です。これらは詳細に異なりますが、一般に、どの操作を監査するかを構成する方法を提供し、それらが生成する監査レコードの安全なストレージを提供します。

次に理解すべきことは、何を監査したいかです。たとえば、HIPAA と SOX の場合、おそらく PII (個人を特定する情報) を見ているでしょう。オバマの電話記録やさまざまな有名人の医療記録にアクセスする人々について大騒ぎしたことを思い出してください... システムが誰がそれらの記録を読んだかを監査し、監査分析官 (AAO) が有名人の記録に人々がアクセスしたことを発見したため、それらは捕らえられました。そうすることを特に許可されていない人。したがって、これらのシステムは、誰が各レコードにアクセスしたかをログに記録し、アクセスしたユーザーが正当なビジネス上の理由がない場合にそれを特定する必要があります。これらのケースでは、ユーザーはレコードに対する読み取り権限を持っていたように見えるため、通常の業務でレコードを参照する必要がある場合、ユーザーは参照できます。しかし、

これが意味することは、州コードと完全な名前 (および州に関するその他のさまざまな情報) を記録する州のテーブルに誰がアクセスしたかを追跡したくないということです。そのリストについて機密事項は何もありません - 誰がそれを読むかは問題ではありません。もちろん、ほとんど誰もそれに書き込みを行うべきではありません。状態のリストは頻繁に変更されるわけではありませんが、テーブルの更新と削除の権限を全員から取り消すことでおそらく処理できます。

OTOH さん、おそらく、誰が病歴の記録にアクセスしたか (HIPAA)、または誰が会計システムのデータを変更したか (SOX) を記録したいと思うでしょう。誰がアカウンティング データを読み取るかについて心配する必要がある場合とない場合があります。その多くは、基本的なパーミッションで処理できます (会計スタッフにはパーミッションがありますが、IT スタッフにはありません)。ただし、監査は常に追加の防御線です。

監査記録は、見なければ何の役にも立たないことを心に留めておいてください。一般に、監査はシステムの速度を低下させます (単純に、監査レコードを書き込む際により多くの作業を行っているためです)。監査戦略の実装を決定する前に、速度がどの程度低下するかを理解することが重要です。ただし、アプリケーションの速度よりも重要なことがいくつかあります。そのうちの 1 つは、自分自身や他のスタッフを刑務所から遠ざけることです。そのためには、監査が必要になる場合があります。

于 2008-12-01T05:47:33.410 に答える
3

Oracle には Oracle Audit Vault という製品があります。DB2 にはおそらく同等の製品があります。

予防から始めるべきです。システムは無効なアクションを許可すべきではありません。限目。システムが監視する必要がある「疑わしい」アクションを許可する場合、それは「ビジネスロジック」です。おそらく、ビジネスロジックの残りの部分と同じように実装する方がよいでしょう。

データベースで何かをしたい場合は、ログ配布を調べることができます (用語は RDBMS ごとに異なる場合があります)。基本的に、すべての DML 操作はファイルに記録されます。この情報は、レプリケーション/HA/フェイルオーバーなどの場合でも、バックアップとポイント イン タイム リカバリに使用できます。ログを別の「信頼できる」システムに「追加のみ」の方法で配布する場合 (つまり、ログ配布プロセスには新しいログ ファイルを作成する権限がありますが、既存の情報を変更する権限はありません)、基本的な監査機能が既にあります。 . 安全な方法（つまり、認証、否認防止）でそれを行う場合、おそらく「コンプライアンス」にかなり近づいています:-p

もちろん、非常に多くの INSERT/UPDATE/DELETE ステートメントをふるいにかけることは、最も洗練された作業方法ではありません。

于 2008-11-29T18:56:11.557 に答える