12.7.2　設計

(1)　監査の方針を決める

最初に，監査の対象や，監査の実施間隔などの監査方針を決めます。

A社の情報分析システムでは，個人情報を扱っています。そのため，社員が個人情報に不正アクセスしていないかを監査で確認する必要があります。また，販売履歴や売り上げ情報なども社外秘の情報のため，社員がこれらの情報に不正アクセスしていないかを監査で確認する必要があります。

売り上げ情報や，訪問客数などは月に1回計上しているため，このタイミングで監査を実施することにします。

以上のことから，監査の対象とする操作と，監査の実施間隔を次のように決めます。

監査の対象とする操作

• 個人情報を格納しているデータベースへのアクセス操作

• 販売履歴や売り上げ情報などの社外秘の情報を格納しているデータベースへのアクセス操作

監査の実施間隔

• 月に1回実施

ページの先頭へ

(2)　監査証跡を出力するイベントを決める

「(1)　監査の方針を決める」で決めた監査方針に従って，監査証跡を出力するイベントを決めます。

監査対象のデータを格納しているデータベースへのアクセス記録が，監査の際に必要になります。また，データベースにアクセスしたユーザが，どのような経路でHADBサーバに接続してきたかを特定するために，HADBサーバへの接続または切断処理が発生したときの記録も必要になります。

データベースへのアクセス記録を出力するには，操作系SQLイベントを監査証跡の出力対象イベントとする必要があります。また，HADBサーバへの接続または切断処理に関する記録を出力するには，セッションイベントを監査証跡の出力対象イベントとする必要があります。操作系SQLイベントおよびセッションイベントの発生時に，監査証跡を出力する場合は，CREATE AUDIT文で選択監査イベントを監査対象として定義する必要があります。

メモ

イベントの種類，イベントの種類と操作の関係については，「12.9.1　監査対象イベントの一覧と出力項目」を参照してください。

ページの先頭へ

(3)　監査証跡機能で使用するディレクトリを設計する

A社の情報分析システムで扱うデータには，個人情報が含まれているため，監査証跡ファイルの保管規則を次のように決めました。

• 過去3か月分の監査証跡ファイルは，監査証跡の出力先ディレクトリ下に保管する

• 出力後3か月が経過した監査証跡ファイルは，監査証跡の保存先ディレクトリに移動する

• 出力後1年が経過するまで，監査証跡の保存先ディレクトリ下に監査証跡ファイルを保管する

• 監査証跡の保存先ディレクトリ下に保管している，出力後1年が経過した監査証跡ファイルは削除する

A社の情報分析システムでは，データベースへのデータインポートが30分ごとに実行されます。また，BIツールからの検索クエリが，1日に約2,400回発生します。これらを考慮し，監査証跡機能で使用するディレクトリを設計します。

■監査証跡の出力先ディレクトリの設計

監査証跡の出力先ディレクトリには，3か月分の監査証跡ファイルを格納できる容量が必要になります。監査証跡の出力先ディレクトリの容量は次のように見積もります。

計算式

｛2,400クエリ×｛2キロバイト＋16キロバイト(SQL文長)｝＋24×2×(1キロバイト＋1キロバイト＋1キロバイト)｝×31日×3か月
＝｛2,400×(2＋16)＋24×2×(1＋1＋1)｝×31×3＝4,030,992キロバイト
≒4ギガバイト

上記の計算結果から，監査証跡の出力先ディレクトリを作成するディスク領域は，余裕も含めて10ギガバイトにします。

このディスク領域を/mnt/audittrail/outputareaにマウントし，監査証跡の出力先ディレクトリのパスを次のようにします。

• /mnt/audittrail/outputarea/audit

■監査証跡の保存先ディレクトリの設計

監査証跡の保存先ディレクトリには，9か月分の監査証跡ファイルを格納できる容量が必要になります。監査証跡の保存先ディレクトリの容量は次のように見積もります。

計算式

｛2,400クエリ×｛2キロバイト＋16キロバイト(SQL文長)｝＋24×2×（1キロバイト＋1キロバイト＋1キロバイト）｝×31日×9か月
＝｛2,400×(2＋16)＋24×2×(1＋1＋1)｝×31×9＝12,092,976キロバイト
≒12ギガバイト

上記の計算結果から，監査証跡の保存先ディレクトリを作成するディスク領域は，余裕も含めて20ギガバイトにします。

このディスク領域を/mnt/audittrail/saveareaにマウントし，監査証跡の保存先ディレクトリのパスを次のようにします。

• /mnt/audittrail/savearea/audit_bak

メモ

出力後3か月が経過した監査証跡ファイルを監査証跡の保存先ディレクトリに移動したあとに，出力後1年が経過した監査証跡ファイルを削除します。そのため，監査証跡の保存先ディレクトリには，9か月分の監査証跡ファイルを格納する容量が必要になります。

ページの先頭へ

(4)　監査人を選定する

監査証跡機能を使用する場合，監査人を選定する必要があります。監査人とは，監査証跡機能の管理，運用を担当したり，監査を実施したりする人のことです。

データベースの運用担当者と，データベースの運用担当者の操作を確認する監査人は，別々の人物が担当する必要があります。A社では，監査証跡機能の使用に伴い，情報分析システムの担当者の役割分担を次の図のように決めました。

図12‒6　A社の情報分析システムの担当者の役割分担

• DB管理担当者

  HADBのデータベースを管理，運用する人です。主にデータベースのメンテナンス作業などを担当します。OSにログインする際は，HADB管理者のOSアカウントを使用します。また，HADBサーバに接続する際は，DBA権限を持っているHADBユーザの認可識別子ADBADMINを使用します。

• 監査証跡機能の管理担当者

  監査証跡機能の管理，運用をする人です。監査証跡機能の有効または無効を管理したり，監査対象の定義をしたりします。OSにログインする際は，HADB管理グループに所属するOSユーザのアカウントを使用します。また，HADBサーバに接続する際は，監査管理権限を持っているHADBユーザの認可識別子ADBAUDITADMINを使用します。

• DB監査担当者

  監査を担当する人です。監査証跡を参照して，データベースの操作記録などを確認します。OSにログインする際は，HADB管理グループに所属するOSユーザのアカウントを使用します。また，HADBサーバに接続する際は，監査参照権限を持っているHADBユーザの認可識別子ADBAUDITVIEWERを使用します。

  DB監査担当者は2名選定し，OSユーザのアカウントや，HADBユーザの認可識別子は，両者が使用します。

ページの先頭へ

(5)　監査証跡ファイルへの書き込みに失敗した場合の処理方式を選択する

ディスクの満杯，またはディスク障害などによって，HADBサーバが監査証跡ファイルへの書き込みに失敗した場合の処理方式を選択する必要があります。次のどちらの処理方式にするかを選択します。

1. 監査証跡ファイルへの書き込みに失敗した場合，HADBサーバを停止（異常終了）します。

2. 監査証跡ファイルへの書き込みに失敗した場合，書き込みに失敗した監査証跡を破棄します。HADBサーバの動作は継続します。

上記の2.の方法を選択した場合，監査証跡の欠損が発生するおそれがあります。この場合，セキュリティインシデントが発生したときの調査が不十分になるおそれがあります。また，安全管理措置を怠ったと見なされると，社会的信用の失墜につながり，大きな損失となるおそれもあります。

情報分析システムは，24時間連続稼働が求められるECサイトとは完全に切り離されています。そのため，情報分析システムが停止しても，ECサイトの運営に影響はありません。

以上のことから，情報分析システムでは，監査証跡ファイルの書き込みに失敗した場合，HADBサーバを停止する1.の処理方式を選択することにしました。

さらに，監査証跡ファイルの書き込みに失敗したときに出力されるKFAA51404-Eメッセージを監視し，書き込み失敗を検知した場合は，HADBサーバの管理担当者と監査証跡機能の管理担当者に対して，メールが送信される運用を決めました。

ページの先頭へ