Level1-4でまとめた人気コンテンツのeBook版。標準監査機能の基本から応用まで全8回で解説。ベロ先週に引き続き3階層アーキテクチャのセキュリティについて見ていきましょう。THINドライバを使用してコネクションプールを作成し、監査レコードを確認してみた。THINドライバの場合はTERMINAL列がUNKNOWNとなり、APサーバの特定すらできない状態でした。APサーバから1つのコネクションを使用する場合、大きなセキュリティホールを作ってしまうことになる。実際に次のようなアプリケーションを考えてみる。更新は許可しないこのような環境の場合みなさんなのアプリケーションはどのように設計するでしょうか?1つの方法はAPサーバがDBユーザ/パスワードをフォームにより入力させ認証する。この場合、エンドユーザはそれぞれDBユーザを記憶しておく必要があり、またDBユーザが大量に存在する場合、コネクションプールの使用に向かない。2つ目の方法はすべてのDBユーザの権限をもつスーパーユーザを作成し(APPSRV)エンドユーザからのDBアクセスは全てこのAPPSRVが引き受ける。この方法は、コネクションプールには向くが、ORACLEが提供するロールによるセキュリティを設定することができず、APPSRVによる故意、不注意によるデータ破壊を防ぐことはできない。AUDITに関してもAPPSRVのみが監査対象となり、各DBユーザのアクティビティを監査することはできない。これは、アカウンタビリティという最低限の監査すらできないという大きなセキュリティホールと言えるでしょう。上記1、2の方法に加えOracle9iではプロキシ認証をサポートしています。APサーバには必要最低限の権限のみをもたせたユーザーproxyで接続させ、アクセスするユーザにはプロキシ認証を実装するという方法です。この方式では、SQL処理を要求する際にユーザーproxyのコネクション・プールを経由して認証を受けた利用者アカウントの権限でデータベースにアクセスできます。実際にプロキシ認証を使ってみましょう。その前に環境をちょっと設定。(b)ではプロキシ経由のEMPLOYEEユーザのアクティビティを監査する。プロキシ経由ですべのユーザを監査する場合は以下の通り。監査がどのように設定されたか確認してみよう。^^^^^(c)でPROXYユーザによる接続でEMPLOYEEユーザのアクティビティ(この場合はLOGIN)の監査を実施する設定になっていることが分かる。実際にプロキシ認証にてEMPLOYEEユーザでログインしSELECT文、およびINSERT文を発行してみよう。権限が不足しています。^^^^^^^^(f)でセッションを確立したPROXYユーザではなく、きちんとEMPLOYEEユーザの監査レコードが作成されている。THINドライバではUNKNOWNとなっていたTERMINAL列にAPサーバである「KSHINKUB」が設定されている。(やはり)エンドユーザの監査はできない。今回のプロキシ認証では、セキュリティの面でいろいろ便利な点がある。以下ちょっとまとめてみます。1.ロールを使用してユーザごとのセキュリティが確保できる。2.APサーバから必要最小限の権限をもつユーザで接続できる。3.DBユーザに対して正確なアカウンタビリティを確保できる。使用するロール)により、DB・AP両面からセキュリティ対策が行える。参考)以下は今回使用したプロキシ認証のサンプルソースです。reserved.トップページ企業概要プライバシーポリシ。