標準セキュリティ運用で設定されているセキュリティパラメタ値に対して、組織のセキュリティポリシーに則した最適なセキュリティ運用が遂行できるように、セキュリティパラメタをチューニングします。
1つのSymfoware/RDBシステム全体に対して、どのようなセキュリティ機能を動作させるのか、セキュリティ運用にどのような強度を持たせるか、または運用系コマンドに対するロールの使用を有効にするかどうかをチューニングします。
セキュリティ形態パラメタのチューニングは、SET SYSTEM PARAMETER文で行います。
セキュリティ形態パラメタのチューニング、または運用系コマンドに対するロールの使用を制御するチューニングの指針を以下に示します。
標準セキュリティ運用では、さまざまなセキュリティ機能を提供しています。組織のセキュリティシステムにとって不要なセキュリティ機能を抑止することができます。
データベースへのデータのアクセスなどの操作を制限する必要のない場合は、USER_CONTROLを使用して利用者登録の使用を解除します。なお、本パラメタはセキュリティ強度に大きく影響します。
さらに、利用者のセキュリティシステム内へのログインを制限するなどのチューニングには、XA_USE、CONNECT_USERおよびWORKFILE_CLEARを使用します。
インストール時に標準運用を選択した場合、セキュリティパラメタをチューニングすることで、利用者制御などのセキュリティ機能を開始させることができます。
たとえば、標準運用において、データベースへのデータのアクセスなどの操作を制限したい場合は、USER_CONTROLを使用して利用者登録の使用を宣言します。
標準運用と標準セキュリティ運用の機能差および標準運用でのセキュリティ機能の使い方の詳細については、“付録E 機能差一覧”を参照してください。
調査用ファイルには、スナップファイル、ルーチンスナップファイル、アクセスプランおよび性能情報ファイルがあります。
スナップファイルはクライアント側に生成されるため、利用者が参照可能なファイルであり、その利用者のみが書込み可能なディレクトリを指定します。セキュリティパラメタのチューニングに関わらず、クライアント用の動作環境ファイルでスナップファイルの取得を指定した場合は、常に取得されます。
その他のファイルはサーバ側に生成されるため、無造作にファイルが作成された場合、サーバの環境を圧迫する脅威があります。また、これらのファイルは利用者が参照してはならないような格納情報を含んでいるので、たとえクライアント用の動作環境ファイルにこれらのファイルの取得を指定しても、標準セキュリティ運用では管理者が特にチューニングしない限り取得できません。管理者が特にチューニングした場合には、指定されたディレクトリに対して管理者の権限で書き込みます。この場合、管理者は利用者のログインやアプリケーションの実行を、調査対象の利用者やアプリケーションに限定しなければなりません。
運用系コマンドに対するロールの使用を有効にする
ROLE_RANGEパラメタを有効にすることで、各コマンドで必要な権限を含むロールが付与されている利用者でも、運用系コマンド（rdbfmt、rdbsloader、rdbsaloader、rdbsuloader、rdbunl、rdbunlx）を実行することができます。ただし、標準運用時のみ有効です。
利用者の資源量や認証識別情報をチューニングします。
ユーザパラメタのチューニングには、以下があります。
ユーザパラメタのチューニングは、SET SYSTEM PARAMETER文で行います。1人の利用者に対して個別にチューニングする場合は、CREATE USER文またはALTER USER文で行います。
ユーザパラメタの設定値は、次のコネクション接続時に有効になります。
利用者が使用できる資源量をチューニングします。
Symfoware Serverが獲得する資源には、以下があります。
利用者が上記の資源を使いつくさないように、セキュリティパラメタを使って資源へのアクセスを細かくチューニングする必要があります。
利用者の資源量のチューニングは、CONNECT文で指定した利用者に対して有効となります。
SET SESSION AUTHORIZATION文実行時に、CONNECT文発行時の利用者の資源量を引き継ぐか、SET SESSION AUTHORIZATION文で指定した利用者の資源量に変更するかをチューニングすることもできます。
これをチューニングするには、RESOURCE_LIMIT_CHECKを使用します。
各資源ごとのチューニング指針を以下に示します。
Symfoware Serverが動作するのに必要なメモリを、1人の利用者が大量に使用すると、Symfoware Serverが動作するのに必要なメモリを確保できなくなる可能性があります。1人の利用者が不当にメモリを使い尽くさないように、1つのコネクションで使用可能なメモリ量および1人の利用者が同時に接続可能なコネクション数を制限します。
Symfoware Serverが動作するのに必要なファイルを、1人の利用者が大量に使用すると、Symfoware Serverが動作するのに必要なファイルを確保できなくなる可能性があります。1人の利用者が不当に資源を使い尽くさないように、1つのコネクションで使用可能な作業用ファイルの量および1つのコネクションで使用可能な作業用ファイルの数を制限します。
アプリケーションの動作によっては、他のトランザクション実行を妨げる可能性があります。そのような事象の原因になるものには以下があります。
更新処理を実施したトランザクションが、コミットもしくはロールバックを実行せず存在し続けると、そのトランザクションが発生させたログはテンポラリログファイル上に保持し続けなければなりません。その状態で、別の更新トランザクション群がテンポラリログファイルにログを書き出していくと、最後には前者のトランザクションが存在しているためにログを書き出せなくなってしまいます。この状態を長トランザクションによるテンポラリログ域枯渇と呼びます。
このような状況を回避するために、1つのトランザクションで使用可能な時間を制限します。
トランザクションが資源をアクセスするために獲得したロックはそのトランザクションが終了するまで保持されるので、そのロックのモードによってはロックを獲得しているトランザクションが終了するまでは他トランザクションがその資源をアクセスできません。したがって、トランザクションが実行状態のまま長時間存続し続けると、他トランザクションの実行を不当に妨げることになります。
このような状況を回避するために、1つのトランザクションで使用可能な時間を制限します。
同一トランザクション内で大量の資源をアクセスすると、それぞれの資源に対してロックを獲得します。その結果、他トランザクションがロック待ちとなる可能性が高くなります。また、ロック情報が多く必要になるので、プロセス内ローカルメモリを多く消費することになります。ロックを獲得しているトランザクションが正常な処理をしている場合は、見積り範囲内でのロック待ち、メモリ消費しか発生しませんが、不当に大量の資源をアクセスしたり、長時間トランザクションを終了しなかったりすると、予想外のロック待ち、メモリ消費が発生することになります。
このような状況を回避するために、1つのトランザクションで使用可能な時間および1つのトランザクションでのトランザクション用メモリ量を制限します。
これをチューニングするには、MAX_TRAN_TIMEおよびMAX_TRAN_MEMを使用します。
トランザクションが更新処理を実施すると、そのログがアーカイブログファイルに保存されます。アーカイブログはデータベースの更新操作を保証するものであり、データベース全体をバックアップするまでは保存が必要なものです。したがって、運用計画に沿ってデータベースのバックアップがなされるまでの間に発生するすべてのアーカイブログを記録できるようにアーカイブログファイルを作成しておかなければなりません。
もし、アーカイブログ域に空き領域がなくなり、切替え先のアーカイブログファイルがなくなると、アーカイブログ域枯渇が発生します。アーカイブログ域枯渇が発生すると、更新処理実行中トランザクションはアーカイブログ域枯渇状態が解消されるまで無応答状態になるか、エラーになります。
このような状況を回避するために、1つのトランザクションで使用可能な時間および1つのトランザクションで使用可能なトランザクション用メモリ量を制限します。
これをチューニングするには、MAX_TRAN_TIMEおよびMAX_TRAN_MEMを使用します。
利用者の認証識別のチューニング指針を以下に示します。
パスワードは、システムのセキュリティ強度に合わせて、適切なパスワード期限を設定する必要があります。
パスワードに使用できる文字種
パスワードに最低限必要なバイト数
パスワードの誤り時の待ち時間
パスワードに使用できる文字種の詳細については、“12.2 パスワードの管理”を参照してください。
パスワードに最低限必要なバイト数をチューニングするには、MIN_PASSWORD_SIZEを使用します。
パスワードの誤り時の待ち時間をチューニングするには、INVALID_PASSWORD_WAIT_TIMEを使用します。
これらを組み合わせてパスワードが見破られる確率を導き出した上で、パスワードの期限を決めます。パスワードの期限をチューニングするには、PASSWORD_LIMIT_TIMEを使用します。
パスワードを連続して誤った際にパスワードロックされるまでの猶予の回数を設定します。
データベース専用利用者が、この回数を超えてパスワードを誤った場合、そのパスワードは自動的にシステムがロックします。
パスワードのロックは、システムまたは管理者が不当な利用者を発見した場合に、その利用者を制限する目的で行います。
パスワードのロックの対象となる利用者は、データベース専用利用者のみで、以下の場合に行います。
利用者がパスワードの連続失敗回数を超えたため、システムが自動的にパスワードをロックする場合
管理者がALTER USER文を実行して、利用者のパスワードをロックする場合
パスワードがロックされた利用者は、サーバシステムへの接続ができなくなります。
いずれの場合も、管理者がALTER USER文を実行して、利用者のパスワードを再設定することで、パスワードのロックは解除され、利用者名を再利用することができます。
ALTER USER文については、“11.2 ALTER USER文(利用者変更文)”を参照してください。
パスワードの連続失敗回数は、システムのセキュリティ強度に合わせて、適切な回数を設定する必要があります。この回数を設定することにより、不正な利用者から攻撃を受けた場合にも、システムを防御することができます。
パスワードを変更してからある程度の時間が過ぎると、パスワードの変更催促期間に入り、利用者にパスワードの変更を促します。変更催促期間とは、パスワードの期限の数日前から期限当日までの間で、パスワード変更の催促する警告メッセージを表示する期間のことです。
パスワードの有効期限までにパスワードが変更されない場合は、利用者のパスワードは無効になります。
無効になったパスワードは、管理者がALTER USER文を実行して、利用者のパスワードを再設定することで、利用者名を再利用することができます。
ALTER USER文については、“11.2 ALTER USER文(利用者変更文)”を参照してください。
デフォルトロールとは、アプリケーション中でSET ROLE文を実行せずに有効となるロールを、環境構築時にあらかじめ設定しておくことです。
デフォルトロールは、インストール時にセキュリティパラメタの省略値が設定されません。環境構築時に、権限情報の定義でロールを作成した場合に有効となります。
デフォルトロールの設定については、“デフォルトロールの設定”を参照してください。
標準セキュリティ運用では、監査ログデータベースを作成し、すべての監査ログ情報を取得します。監査ログは、利用者および管理者の作業を監視する場合に使用します。管理者は、各自のセキュリティシステムに有効な監査ログ運用を行うために、監査ログパラメタをチューニングします。
監査ログパラメタのチューニングは、SET SYSTEM PARAMETER文で行います。
監査ログにどのような情報を取得するか、またどの利用者の監査ログを取得するかは、各セキュリティシステムでのセキュリティポリシーに依存します。
監査ログに取得される情報には、以下の6つがあります。
セションに関する情報
アクセスに関する情報
管理者に関する情報
エラーに関する情報
SQL文に関する情報
SQL文の入力データに関する情報
各情報の詳細は、“8.1 監査ログの取得情報”を参照してください。
セションに関する情報の取得をチューニングするには、AUDIT_SESSION_SUCCESSおよびAUDIT_SESSION_FAILを使用します。
アクセスに関する情報の取得をチューニングするには、AUDIT_ACCESS_SUCCESSおよびAUDIT_ACCESS_FAILを使用します。
管理者に関する情報の取得をチューニングするには、AUDIT_MANAGEを使用します。
エラーに関する情報の取得をチューニングするには、AUDIT_ERRORを使用します。
SQL文に関する情報の取得をチューニングするには、AUDIT_SQLを使用します。
SQL文の入力データに関する情報の取得をチューニングするには、AUDIT_SQLBINDを使用します。
監査ログを取得する利用者をチューニングするには、AUDITを使用します。
各監査ログパラメタに“YES”を指定した場合、監査ログに取得した情報が格納される監査ログ表は以下となります。
監査ログパラメタ | 監査ログ表 |
|---|---|
AUDIT_SESSION_SUCCESS | AUDIT_TRAIL_SESSION |
AUDIT_SESSION_FAIL | AUDIT_TRAIL_SESSION |
AUDIT_ACCESS_SUCCESS | AUDIT_TRAIL_ACCESS |
AUDIT_ACCESS_FAIL | AUDIT_TRAIL_ACCESS |
AUDIT_SQL | AUDIT_SQL |
AUDIT_SQLBIND | AUDIT_SQLBIND |
AUDIT_MANAGE | AUDIT_MANAGE |
AUDIT_ERROR | AUDIT_ERROR |
監査ログ表の詳細については、“8.2 監査ログ表の詳細”を参照してください。
監査ログが満杯になった時の対処方法をチューニングするには、AUDIT_LOG_FULLを使用します。
監査ログの満杯時の対処方法には、以下の3つがあります。
Symfoware/RDBを強制停止します。
運用を中断する場合は、監査ログが満杯になった事象を検出した時点で、メッセージログファイルにメッセージを出力して、Symfoware/RDBを強制停止します。管理者は、監査ログのバックアップおよび初期化を行い、異常の原因を特定した後に、運用を再開する必要があります。
一番古い監査ログエレメントを再利用します。
一番古い監査ログの破棄は、監査ログエレメント単位に行われます。一番古いエレメントが自動的に初期化されて、そこに新しい監査ログが採取されますので、初期化される前にエレメント内の監査ログをバックアップする必要があります。
また、古い監査ログエレメントがすでにバックアップ済みであるが、初期化せずに置いておくような運用を実施している場合は、古いエレメントに上書きして使用しても、ログが失われずに運用を継続することができます。
監査ログの取得を停止して、メッセージログファイルに出力します。
監査ログの満杯時の対処方法の詳細については、“9.2.2 監査ログが満杯の場合の対処”を参照してください。
