従来の監査から飛躍的に改善され使いやすくなったUnified Audit：ユーザー目線でチェック！ Oracle Database 12cの知りたいところ（4）（1/4 ページ）

DB運用で避けては通れない、ログ監査。12cではどれくらいDBAが楽になる？　監査とセキュリティの問題を解消する目玉機能がUnified Auditだ。

[菅原 良也，株式会社コーソル]

　近年データベースでのセキュリティ対策の重要性が広く認識され、データベースが提供しているセキュリティに関わる機能を既に利用しているケースも多いかと思います。

　データベースのセキュリティ機能において、重要な役割を担っているのが監査機能です。しかし、監査機能を利用するに当たっては、パフォーマンスがダウンする、必要な監査ログだけを適切に取得するための設計が困難である、取得した監査ログの管理が面倒、などの問題がありました。

　Oracle Database 12c R1では、このような問題の解決につながる革新的な新機能Unified Auditが提供されました。本記事では、Unified Auditと、その他のセキュリティに関連する新機能についてご紹介します。

セキュリティの新機能

　Oracle Database 12cには多くのセキュリティ関連の新機能が導入されています。この中で、特に有効と思われる機能（Data Redaction、Privilege Analysis、Unified Auditing）を紹介します。

Data Redaction：アプリケーションに頼らずにデータを保護する選択肢

　データベースには、クレジットカード番号などセキュリティの観点で取り扱いに注意が必要なデータが格納されることがあります。このデータを表示するときには、番号の一部をマスクするといった、データの一部を置き換えて表示する処理が一般に求められます。

　このような処理は、従来、以下のいずれかの方法で実現されてきました。

1. 表示するたびに、アプリケーション側でデータベースから取得したデータを別の値に置き換えて表示する
2. 格納用のデータ列とは別に表示用のデータ列を別途用意し、あらかじめこの列には置き換えたデータを格納しておき、アプリケーションはこの列にアクセスするように実装する

　Data Redactionは、上記のうち、（1）のような置き換えをデータベースで自動的に行う機能です。データベースへのアクセス形態が事前に定義した条件に合致した場合、SELECT文で返される列の値がルールに基づき自動的に置き換えられます。

　例えば、アプリケーションサーバーとデータベースサーバー間のセッションのみ、クレジットカード番号の一部をデータベースで自動的にマスクするような処理を簡単に実現できます。

Column：SQLインジェクション対策にも使えるData Redaction

　Data Redaction機能は、SQLインジェクション対策にも有効です。アプリケーションにSQLインジェクションの脆弱性があり、その脆弱性を突くSELECT文が実行された場合、従来は当然ながらSELECT文に指定された列のデータが悪意を持ったユーザーに返されます。

　しかし、Data Redactionを使用すると、事前に設定したアクセス条件に合致していれば、置き換えられたデータを返します。Redactionポリシーによって元データが守られる形になります。

　完全にセキュアなアプリケーションを作るのは現実的には極めて困難であると考えます。アプリケーションの脆弱性であるSQLインジェクションに対し、データベース側で防衛が可能となる点で、非常に革新的で有効な新機能であると思っています。

Privilege Analysis：権限の使用状況を監視・レポートする

　データベースユーザーに本来は不要である過剰な権限が付与されていると、その過剰な権限が悪用される恐れがあります。そのため使用されていない権限を剥奪し、権限の最小化を実現することが望ましいのですが、「付与されている権限が使用されたのか」を調べる方法が従来のバージョンではありませんでした。そのため、付与されている権限を剥奪しても本当に良いかを判断することが極めて困難でした。

　Privilege Analysisは、付与された権限とともに、その利用状況を自動的に監視・記録し、分析レポートを出力する新機能です。利用されていない権限を洗い出し、それを過剰な権限として剥奪することで、付与されている権限を必要最小限にできます。

Unified Auditing：ログ管理をシンプルにする

　Unified Auditingは従来バージョンの監査機能の問題点を大きく改善した監査機能です。従来バージョンでは、標準監査、必須監査、DBA監査、FGA監査というように役割が異なる監査機能が複数存在し、それぞれの監査機能ごとに出力先や出力される情報が異なることから、一連の操作の追跡が難しかったり、ログの保管などの管理が煩雑になるといった問題がありました。また、RMANなどのユーティリティの使用が簡単に判断できるような監査ログを取得できませんでした。

　Unified Auditingは、標準監査、必須監査、DBA監査と一部のFGA監査(*1)の機能を統合しています。CREATE AUDIT POLICY文で監査設定を行います。Unified Auditingの監査証跡レコードはSYSAUX表領域に格納され、ビューUNIFIED_AUDIT_TRAILより参照できます。Unified Auditingの機能のイメージは次のようになります。

*1 列単位での監査条件の指定や、監査後のアクション実行については引き続きFGA監査を使用する必要があります。

Unified Auditing に搭載された機能のイメージ

　各種監査ログを統合したことで、データベースで実行される非常に多くの操作から、何らかの関連性のある一連の操作を発見するような分析が容易になりました。

　データベースで不正操作が行われた場合、不正操作そのものの監査ログだけではなく、不正操作を行ったユーザーが他に何を実行したかも併せて特定する必要があります。その他にも何か不正な操作を行っていなかったのか確認するためです。

　このとき、実行された操作の種別によって監査ログの出力先が異なると、関連性のある操作を容易に確認できず、分析が困難になります。

Unified Auditingと従来の監査機能の比較

　従来は、管理ユーザーで実行された操作を確認するためにはOSファイル（DBA監査）を、一般ユーザーで実行された操作を確認するためにはDBA_AUDIT_TRAILビュー（標準監査）を参照し、監査ログを突き合せる必要もありましたが、Unified Auditingでは全ての監査ログがビューUNIFIED_AUDIT_TRAILより参照可能なので、一度にまとめて必要な分だけSELECT文で参照することができます。

　さらに、監査設定の簡素化も図られました。従来の標準監査ではオブジェクトごとに監査を行うSQL文の指定が必要であり、監査設定は複雑なものになりがちでした。Unified Auditingでは監査対象をグループ化したポリシーが用意され、ポリシーを指定することである条件を満たしたオブジェクトやSQL文に対して簡単に監査設定行うことが可能となりました。

　また、従来の監査機能では監査が難しかったユーティリティの実行（RMAN、DataPump exp/imp、SQL*LoaderによるDirect Path Load）についても監査が可能となりました。

　引き続き、Unified Auditing機能について紹介します。