代表的なデータベース・ベンダーである米Oracleの製品に，セキュリティ・ホール[用語解説]が次々と見つかっている。3月14日には，セキュリティ組織である米CERT/CC[用語解説]が改めて警告を発した（関連記事）。問題はどこにあるのか。ユーザーは何に注意すればよいのか。長年にわたりデータベース・システムのインテグレーションなどに従事してきた，ビークイックの取締役である寺田聡氏に話を聞いた。同氏によると，「Oracle製品のセキュリティ・ホールといっても，RDBMS[用語解説]エンジン自体に問題があるわけではない。競合他社への対抗などのため，DBMS本体の周辺に導入された拡張機能が問題なのだ」。同氏の発言内容を以下にまとめた。
続出するホール，問題は3つ
CERT/CCにより警告されているセキュリティ・ホールは，以下の3つに大別できる。
(1) Application Server のセキュリティ問題
(2) 外部プロシージャ関連の問題
(3) デフォルト・ユーザー/パスワードの問題
(1) Application Serverのセキュリティ問題
今回警告されたセキュリティ・ホールの多くは，Oracle 9i Application Server に原因がある。つまり，Oracleのデータベース本体（RDMBSエンジン）ではなく，周辺機能における問題なのだ。
もちろん，拡張された機能――非RDBMSエンジン機能（製品）――についても，主力製品たるRDBMSエンジンと同様のレベルで，開発やサポートが行われれば問題はない。しかし，元々RDBMSエンジンを生業（なりわい）としているベンダーなので，アプリケーション・サーバー[用語解説]や開発ツールなどは“周辺機能”という位置付けになる。主力であるRDBMSエンジン本体とでは，ノウハウの蓄積に違いがあることはやむを得ないだろう。
加えて，周辺機能に関しては，他社の買収により製品化したものが少なくない。オリジナルの開発スタッフがいないかもしれない状況では，問題の発生と対策がいたちごっこになるセキュリティ問題をキャッチ・アップしていくことが難しい場合もあるだろう。ユーザーとしては，その点を認識しておく必要があるだろう。
(2) 外部プロシージャ関連の問題
外部プロシージャ機能に関する問題も同様である。SQL関数[用語解説]やストアド・プロシージャ[用語解説]などを，ユーザー作成ライブラリにより拡張するこの機能は，当初は他社が採用したものだ。追随する形でOracleも採用したこの機能に，セキュリティ・ホールが見つかった。
あくまでも私見ではあるが，そもそもRDBMSレベルで外部ライブラリを呼ばなければならない実装などをしてはいけない。複雑な処理が必要であれば，アプリケーションで処理するべきだ。RDBMSは，あくまで単純なデータベース・エンジンの役割に徹するべきである。
それ以上を期待する，あるいは期待に応えようすると，当然余計な問題を抱え込むことになる。今回のセキュリティ・ホールは，その典型例といえよう。
（1）や（2）の問題を見る限り，RDBMSエンジンはともかくとして，周辺機能や拡張機能に関しては100%の信頼を置くべきではない。
(3) デフォルト・ユーザー/パスワードの問題
デフォルトで用意されている，特定のユーザーID/パスワードについても警告されている。しかし，これは目新しい話題ではない。Sybase[用語解説]やSQL Server[用語解説]では「sa」のパスワードがデフォルトでは設定されていない関連記事。Oracleについても，「system」や「sys」ユーザーのパスワードは，一部では知られている。
当然，管理者はこのことを知っているべきであり，インストールしたらまず第一にこれらを変更することが“常識”であった。実際，メインフレームで構築したシステムを運用した経験がある部門などでは，デフォルト・ユーザーがそのまま残されていることはほとんどない。
しかし，機能拡張が進むにつれて，デフォルト・ユーザーの種類が増えてきた。Oracle8ぐらいまでは，デフォルト・ユーザーは「system」や「sys」などと少数であったが，Oracle 9iになると，すぐには列挙できないほどに増えている。新たに搭載された機能にもデフォルト・ユーザーが用意されているために，システム全体では相当数存在することになる。
こうなると，デフォルト・ユーザーを変更していなかったからといって，管理者を責めるのは酷だろう。ベンダーには，できる限りデフォルト設定を用意せず，管理者（ユーザー）が必要に応じて設定するようにしてもらいたい。
現状では，（3）の対策としては，管理者が設定を変更することが第一である。新機能とともに持ち込まれるデフォルト・ユーザーを極力減らすために，必要がない拡張機能を使用しないことも重要だ。これについては，（1）や（2）についても同様である。
また，ユーザー・サイドで実装可能な機能に関しては，自己の判断で（At Your Own Risk），標準で提供される機能をあえて使用しないことも有効な対策である。システムで実現されるすべての機能を，ベンダーの製品に任せてしまうと，いざというときに自ら緊急対応できない状況に追い込まれる恐れがある。
とはいえ，すべてを自作することが不可能であることも事実である。コストやセキュリティなどを考慮して，「どこまでをベンダーの製品に任せて，どこをユーザー・サイドで実装すればよいか」を十分検討したい。
製品選択についても同様のことが言える。「どのベンダーの，どの製品を使用すればよいか」などを十分検討した上で，導入しなければならない。
一般的にはRDBMSをインターネットからアクセスできる場所に配置することは考えられない。それに対して，周辺機能であるアプリケーション・サーバーは，当然アクセスできる場所に配置する。両製品はまったく性質が異なるのだ。たとえ一ベンダーが両製品を用意していたとしても，「餅は餅屋」の言葉通り，それぞれを専業ベンダーから購入することも考慮すべきだろう。
いずれにしても，安易に判断しないよう警告したい。後々，必ず自身を苦しめることになる。
