「データベースセキュリティ」の視点から見る「ユーザー管理」「監査証跡（ログ）管理」のポイント：システムインテグレーションとセキュリティ（1）（3/3 ページ）

データベース監査の必要性

　上記のポイントを押さえてユーザーの権限を整備すれば、ユーザーが想定外の作業を行うのをシステム的に防ぐことができます。しかし、それだけでは不十分です。なぜなら、権限の付与・剥奪ができるユーザーを使用すれば、後から好きに権限を変更できてしまうからです。「不正に権限を付与して情報を盗み見た後で、権限を元通りに戻す」ということを繰り返されれば、永久に気付くことのできないセキュリティホールとして悪用されてしまう可能性すらあります。監査証跡（ログ）を使ったデータベース監査は、こうした穴を補うために必要となります。

　ログを取得すると、「いつ、誰が、どこから、何を行ったか」が記録されるため、たとえ不正が行われても、その証拠が残ります。また、監査を行っていることを周知することで、内部犯行を抑止する効果もあります。

　一方、ログ取得に関わる懸案事項としては、取得に掛かる負荷があります。これは、トランザクション量や監査対項目数などに依存するものですので、各環境において監査設定を実装し、性能試験を実施することを推奨します。また、特にパフォーマンスをシビアに気にしなければならないシステムの場合は、監査証跡の出力形式を変えながら試行を実施することもお勧めします。一般的には、データベース上にログを出力するよりも、OS上にos形式やXML形式のファイルで出力する方が、負荷は軽いとされています。参考までに、Oracle Databaseが持つ監査機能を以下に紹介します。

参考：監査機能の種類（出典元：オラクル）

監査証跡（ログ）のメンテナンス

　なお、ログ出力を有効にした際は、出力先のディスクサイズを考慮した定期的なメンテナンス（ログの削除など）が必要となります。Oracleの場合は、「DBMSD_AUDIT_MGMT」パッケージでメンテナンスを行うことができます。また、同パッケージを使用してログの保存領域を変更することもできます。

　以下は、全てのログを削除する場合の、Oracle Databaseでの実行例です。

SQL> begin
SQL>  dbms_audit_mgmt.clean_audit_trail(
        audit_trail_type=>dbms_audit_mgmt.audit_trail_all,
        Use_last_arch_timestamp=>false);
SQL> end;
SQL> /

　さて、ここではデータベース監査について紹介しました。データベース監査では、ログの取得レベルやディスクのキャパシティなどの要件を十分検討し、適切な実装をすることが重要です。また、ここではRDBMS自体が持つ監査機能について紹介しましたが、各種ベンダーから、ネットワークキャプチャ方式でデータベース監査を実現するソリューションも提供されています。こうしたソリューションを利用すれば、DBサーバに負荷を与えることなく監査を行うことも可能です。

　次回も引き続き、データベース構築視点でのセキュリティについて解説します。