最近、内部統制に関係して、監査が強調されています。
しかし、内部統制自体は、昔から行われていました。
例えば、職務分掌として、実行者と承認者の権限の分離が挙げられます。
何かを実行するには別の人の承認を必要とし、一方で、承認者には直接実行する権限を与えないようにしている場合です。
それでも、最近になって監査が強調されているのは、個人情報保護法並びに金融商品取引法及び
会社法などの法令により、企業の内部統制は以前にも増して確認/強化することが要求されている為です。
特に上場企業では、2009年3月期以降の財務報告において、財務諸表だけでなく、
内部統制の整備状況についても、会計監査人による確認対象となりました。
また、クレジットカード業界を発端として、これら法律上の要求だけでなく、
PCI DSS(Payment Card Industry Data Security Standard)という独自基準を制定し、適合を求める動きもあります。
これに伴い、組織内の内部統制が全面的に再チェックされ、不足していると判断された場合、コントロールが追加されています。
特に、ITに関連する業務はまだ歴史が浅いため、他の業務に比べ、リスクの識別やコントロールが不足しがちです。
例えば、Oracle Database の SYS ユーザ 等データベース管理者(DBA)ユーザは、全データに対する参照/編集権限を持っています。
このため、DBAユーザであれば、個別業務のデータをいくらでも参照/編集することができます。
さらに、デフォルトの設定では、SYSによってどのような操作が行われたのかを後から確認することができません。
これでは、SYSで接続できれば、個人情報の参照も、財務情報の改ざんも、他の人に見つかることなくできてしまいます。
しかしながら、このような強力な権限を持ったユーザに対する利用履歴等の管理は、不足しているのが実情です。

前述のように、監査においては、アクセス記録等の証拠を取得しておくことが重要となります。
ここでは、どのようにアクセスを記録していくかを考えていきます。
最近は、パッケージアプリケーションの内部統制対応も進んできており、アプリケーションでアクセス記録を残せるようになってきました。
また、DBAユーザを使用した際には、発行したSQLの記録や、操作に使用したGUIツールのスクリーンショットを取得しておくことも可能です。
ところが、これだけでは以下の点で問題があります。
- 操作ログの取得が実行者に任されることになり、
取り漏れや改ざんの恐れを指摘される可能性がある
- GUIツールを用いた場合、操作毎にスクリーンショット等を記録することが
運用上大きな負担となる
上記の問題は、Oracle の audit 機能を使用することで解決することができます。
Oracle の audit 機能は、DBMSが提供する操作ログ記録機能です。この機能を有効にすることで、
Oracle に対するアクセスは全て自動で記録されます。DBMS 側で取得しているため、取り漏れの
心配はなく、また、アクセス経路によらずに取得できるので、運用上も負担が大きくなりません。
次回は、具体的な設定方法についてみていきます。