安全なデータベース運用、設定は具体的にどうすればいいのか（セキュリティ関連の初期化パラメーター一覧付き）：今さら？ 今こそ！ データベースセキュリティ (9)（4/4 ページ）

本連載では、データベースセキュリティの「考え方」と「必要な対策」をおさらいし、Oracle Databaseを軸にした「具体的な実装方法」や「Tips」を紹介していきます。今回は安全なデータベース運用のための設定について紹介します。後半部分では、Oracle Databaseのセキュリティ関連初期化パラメーター一覧を掲載しました。

[福田知彦，日本オラクル株式会社]

SEC_MAX_FAILED_LOGIN_ATTEMPTS

　11gR1から追加されたパラメーターです。

　パスワード推測攻撃は、一昔前は同じデータベースユーザーに対してパスワードを次々変えてログイン試行するものでした。この場合、一定回数以上パスワードを間違えるとアカウントをロックするという対策をとれました。しかし、パスワードを固定してデータベースユーザー名を次々に変えてログインを試行する新しいパターンの攻撃が見受けられるようになりました。この場合、接続を試みるデータベースユーザーが異なるため、ユーザーはロックされません。

　このような攻撃に対応するために、複数回ログインに失敗すると接続を強制的に切断する機能が、11gR1から追加されました。パラメーターの値で指定した回数接続に失敗すると、接続は切断されます。デフォルト値は、11gでは「10」でしたが、12cから「3」に変更になりました。

　不必要に大きな値になっていないかどうかを確認してください。また、この設定は攻撃を遅らせるだけで、攻撃を防止したり、検知したりすることはできません。ログイン失敗を監査・監視して不正なログイン試行に気付く仕組みは別途必要です。

SEC_PROTOCOL_ERROR_FURTHER_ACTION

　11gR1から追加されたパラメーターです。正常ではないパケットを受け取った時の挙動を設定します。

　11gのデフォルト値はCONTINUEで、継続して正常なパケットを待ち続ける動作です。この状態では、データベースサーバは不正なパケットによってサービス妨害（DoS）攻撃を受ける可能性があります。

　12cからはデフォルト値が(DROP,3)に変更になりました。この場合、正常でないパケットを累積で3つ受信すると、接続を強制的に切断します。サービス妨害攻撃からサーバを保護できますが、ネットワークが不安定な環境など、正規の通信でもパケットが壊れてしまった場合などは、強制切断されますので、トランザクションの再実行が必要など、アプリケーションに影響が出る可能性もあります。通信が安定している環境では、12cのデフォルト値を利用することを推奨します。

SEC_PROTOCOL_ERROR_TRACE_ACTION

　11gR1から追加されたパラメーターです。正常ではないパケットを受け取った時の挙動を設定します。デフォルト値はTRACEでデバッグを行うための詳細なトレースファイルが出力されます。不正なパケットが多いためにトレースファイルがストレージを圧迫することがなければ、デフォルトの値を利用することを推奨します。

SEC_RETURN_SERVER_RELEASE_BANNER

　11gR1から追加されたパラメーターです。認証中（完了前）のクライアントに対して、脆弱性の有無の確認など攻撃のヒントとなるデータベースの詳細なバージョンを戻さないように設定できます。デフォルト値はFALSEで、詳細なバージョン（PSRレベル）を戻しません。特別な理由がない限りはデフォルトの設定を利用することを推奨します。

SQL92_SECURITY

　Oracle Databaseでは、表に対してSELECT権限を持っていなくても、UPDATE、DELETE権限を持っている場合、UPDATE、DELETE文のWHERE句やSET句の中で、暗黙的に表を参照することができました。しかし、この仕様はSQLの標準であるSQL92から外れていました。

　今までのOracleのポリシーを適用するか、SQL92の標準に従うかを、このパラメーターで制御できます。12cR2からデフォルト値がTRUEに変更になりました。設定がTRUEの場合、UPDATEやDELETEのWHERE句やSET句で表を参照する場合には、SELECT権限も併せて持つことが必要になります。12cR1までのデフォルト値であるFALSEの場合には、SELECT権限がなくてもUPDATEやDELETEのWHERE句やSET句で表を参照することができます。以下に簡単な例を示します。

　まず、住所録を格納したAPP.ADDRBOOK表があるとします。表の定義は以下の通りです。

SQL> desc app.addrbook
 名前                     NULL?    型
 ------------------------ -------- ----------------
 ID                       NOT NULL NUMBER
 KANA_NAME                         VARCHAR2(64)
 SEX                               VARCHAR2(8)
 PHONE                             VARCHAR2(16)
 MAIL                              VARCHAR2(64)
 ZIP                               VARCHAR2(8)
 ADDRESS                           VARCHAR2(128)
 BIRTHDAY                          VARCHAR2(16)

　ユーザーはこの表に対して、SELECT権限は持っていないが、UPDATE権限を持っているとします。そのため、APP.ADDRBOOK表に対するSELECT文は権限不足エラーとなります。

SQL> select * from app.addrbook;
select * from app.addrbook
                  *
行1でエラーが発生しました。:
ORA-01031: 権限が不足しています。

ここで、以下のようなUPDATE文を発行してみます。

SQL> update app.addrbook set KANA_NAME='' where SEX='男';
57行が更新されました。

　SQL92_SECURITY=FALSEの設定の場合、このSQL文は正常に実行できます。

　ユーザーはAPP.ADDRBOOK表のデータを検索する権限はありませんが、この表には男性のデータが57件入っていることは分かってしまいます。WHERE句でさらに条件を絞った問い合わせを実行することで、どのようなデータが表に格納されているか、推測できてしまいます。これが推測攻撃と呼ばれるものです。SQL92_SECURITYをTRUEに設定しておけば、このようなUPDATE文をエラーで実行できないようにすることができます。

　検索はできないようにしたいけど、更新はできるようにしたいというような特別な要件がない場合には、12cR2からのデフォルトのTRUEを設定することを推奨します。

UNIFIED_AUDIT_SGA_QUEUE_SIZE

　12cR1で新しく追加されたパラメーターですが、12cR2で非推奨となり、下位互換のために残されています。

　12cR1では、監査レコードはCommon Logging Infrastructure（CLI）の仕組みであるSGAキューを利用していました。このパラメーターはそのキューのサイズを指定するものでしたが、12cR2からはデータベースの異常終了時における監査レコードのロスト防止とパフォーマンス向上のエンハンスのため、SGAキューを利用しないようになりました。12cR2では、このパラメーターが設定されていないことを確認してください。

UTL_FILE_DIR

　UTL_FILEなどのPL/SQLパッケージプロシージャで、ファイルをI/Oするディレクトリを指定するパラメーターですが、12cR2から非推奨となりました。

　このパラメーターで指定したディレクトリのファイルは、全てのデータベースユーザーからPL/SQLパッケージプロシージャ経由で読み書き可能となりますので、注意が必要です。利便性のために「*（アスタリスク、全てのディレクトリでファイルI/O許可）」の設定をしているシステムをよく見掛けます。この場合、最悪データファイルを上書きされ、データベースが破壊されてしまう危険性がありますので、指定するディレクトリには細心の注意が必要です。なお、UTL_FILEの代わりにデータベースユーザーごとに読み取り、書き込みなどの権限を詳細に設定できるディレクトリオブジェクトを利用するようにしてください。

　古くは9iR2のマニュアルにも、「UTL_FILE_DIRでなくCREATE DIRECTORY機能を使用してください」という記載があります。

筆者紹介

福田知彦（ふくだ ともひこ）

日本オラクルでセキュリティ関連のプロダクトやソリューションを長年担当。出荷前製品検証からプリセールス、コンサルティングと、さまざまな部署を転々とするも担当はだいたいいつもデータベースセキュリティかIDマネジメント。出荷前から構築、運用、トラブル対応まで製品の一生を見守るエンジニア