Level1-4でまとめた人気コンテンツのeBook版。標準監査機能の基本から応用まで全8回で解説。Trail(監査証跡)について検証していきたいと思います。最近、セキュリティがらみの監査が注目されていますが、監査といっても幅広く、まずは監査機能の概要から勉強してみましょう。成立、施行に伴い、セキュリティ関連分野が盛り上がりを見せている。多発する情報漏洩事件をきっかけにエンドユーザの関心も高まっており、セキュリティを疎かにすることは企業にとっては社会信用問題に発展する恐れが強まっている。以前より、Oracleには様々なセキュリティ機能が搭載されている。その中に、セキュリティ侵害による被害を抑制する仕組みとして、「監査」という機能がある。この監査を使用すると、データベースにログオンしたユーザが実行中の操作を監視し不正な操作があった場合には早期発見することができる。容に応じて監査証跡(ログ)を記録することがでる。大きく分けると次の3種類がある。1)文監査2)権限監査3)オブジェクト監査1)「文監査」は、特定のSQL文を対象にした監査。TABLE文などの使用が監査対象となる。2)「権限監査」は、特定の権限の使用を対象にした監査。TRIGGER権限を使用してデータベース・トリガーを作成した場合に監査対象となる。3)「オブジェクト監査」は、特定のオブジェクトに対する操作を対象にした監査。ordersでは、ORDERS表に対するSELECT文の発行が監査対象となる。環境やセキュリティポリシーによって使い分ける必要があるのね。何でもかんでも監査すればよいわけじゃ無いということ。監査の種類によって、性格は違うし、システムパフォーマンスへの影響も心配だ。そこで、今回は、監査の本質とパフォーマンスへの影響を見極めるべく、バリバリ監査することにします。ちなみに検証での目標は以下の3つ。検証シナリオは以下の通り。検証では、前提となる監査シナリオにそって、監査を実施します。session等の文監査による包括的な監査手法を検証します。2では、オブジェクト監査による、詳細な監査手法を検証します。3、4では、ファイングレイン監査(Oracle9iからの新機能)により、更に詳細かつアプリケーションディペンドな監査手法を検証してみる。前提)ある企業(A社)は、商品の受発注システムを構築している。A社の情報システム部門はA社内部からの情報漏洩、不正アクセス等により、重要な顧客データの流出の可能性を懸念している。そこで、Oracleの持つ監査機能を使用して、内部監査を実施することにした。監査といっても幅広く、また、監査によるパフォーマンス劣化も心配される。1)特定のアプリケーションユーザのログインの監査ログを取得し、データベースへの不正アクセスを発見する。2)重要度の異なる特定のテーブルに対する操作(SELECT、UPDATE、INSERT、DELETE等)の監査ログ取得し、不正データ操作を見破る。3)特定のテーブル(例えばCustomer表)には、顧客情報が格納されている。番号など顧客を特定できる機密情報には、情報漏洩を防止するため、アクセスされる度に監査ログを取得する。列に対する監査を実行してみる。1から検証スタート!!まず、監査を行うには、パラメータファイルに以下の設定を行う。]audit_file_dest=$ORACLE_HOME/rdbms/audit(デフォルト値)NONE、FALSEは監査証跡を残さない。TRUE、DBと設定すれば、オラクルオブジェクトのSYS.AUD$上にデータを格納する。OSと設定した場合は、audit_file_destに指定したディレクトリにファイルとしてデータを格納する。SYS.AUD$は放っておくとどんどんデータが蓄積されていく。的にデータを削除する必要がある。SYS.AUD$はSYSTEM表領域に作成され、TruncateなどDMLが実行することからSYSTEM表領域のフラグメントが心配される。そこで、SYS.AUD$を他の表領域に移動させることを考える人もいるだろうが、アップグレードなどに問題が発生する可能性があるとして、サポートされていない。そんな時は、audit_trailをOSと設定し、ファイルとして蓄積させることが可能。]このパラメータは、9iから導入されオラクルのSYSユーザ(すべてのSYSOPE、SYSDBA含む)の動作を監査対象にするかどうかのオプションである。ちなみに8i以前では、SYSOPE、SYSDBAユーザを監査対象にすることはできない。今回はaudit_trail=DB、audit_sys_operations=FALSEに設定して、Oracle再起動。今回のミッションはセッション情報の監査ログを残し、不正アクセスを防止することなので、早速セッション情報の監査ログを残すよう設定しよう。OSユーザなど様々な情報を取得できる。ここで、ちゃんと監査が設定されたかどうか確認してみる。要があるかもしれません。ユーザ別監査の場合はユーザ名。クライアントに対して操作を実行しているプロキシ・ユーザ名。クライアントが直接操作を実行している場合はNULL。システム監査のモード**********************************************************************ちゃんとログインした時(成功、不成功)に監査するオプションが設定されたようだ。在しないユーザや、パスワードを間違えてログインしようとする環境を作ってみる。行したSQLの特定などを行ってみたいと思います。reserved.トップページ企業概要プライバシーポリシ。