update_engine_config

update_engine_config コマンドは、検査エンジン設定を変更する場合に使用します。

検査エンジンは、特定のデータベース・プロトコル (Oracle や Sybase など) を使用して、サーバーとクライアント間のトラフィックをモニターします。 「検査エンジン構成」 ページから検査エンジンを構成します。 検査エンジンの構成後、update_engine_config コマンドを使用してパラメーターを変更できます。 詳しくは、 検査エンジンの構成を参照してください。

この API は、Guardium V11.0 以降で使用可能です。

REST API 構文

この API は PUT メソッドで、REST サービスとして使用可能です。 この API を次のように呼び出します。
PUT https://[Guardium hostname or IP address]:8443/restAPI/engine_config

GuardAPI 構文

update_engine_config parameter=value

パラメーター

各パラメーターについて詳しくは、 検査エンジンの構成 を参照してください。

パラメーター 値のタイプ 説明
computeAverage ブール値 有効にすると、ロギングされる各 SQL 構文について平均応答時間が計算されます。 有効な値:
  • 0 (false)
  • 1 (真)
defaultAutoCommit ブール値 さまざまなデータベースには各種の自動コミット・モデルがあるため、この値は、当該トランザクションと各コマンドの後の自動コミットに明示的にマークを付けるためにリプレイ関数により使用されます。 有効にすると、コミットおよびロールバックは無視されます。 現在サポートされているデータベースには、Db2®、Informix®、 Oracle などがあります。 有効な値:
  • 0 (false)
  • 1 (真)
defaultCapture ブール値 リプレイ関数によって、トランザクションとキャプチャー値を区別するために使用されます。準備済みステートメントがある場合は、割り当てられた値がキャプチャーおよびリプレイされます。 キャプチャーされた準備済みステートメントを準備済みステートメントとしてリプレイする場合は、これを有効にします。 有効な値:
  • 0 (false)
  • 1 (真)
excludePorts ストリング 無視するポートのリストです。 データベース・サーバーが非データベース・プロトコルを処理していることがわかっており、 Guardium® が非データベース・トラフィックを分析するサイクルを無駄にしないようにする場合は、このリストに値を追加します。 例えば、データベースのあるホストがポート 80 で HTTP サーバーも実行していることがわかっている場合は、無視ポート・リストに 80 を追加して、Guardium がこれらのストリームを処理しないようにすることができます。 値を複数入れる場合にはコンマで区切り、ポートの範囲をその値も含めて指定する場合は、値をハイフンでつなぎます。 例: 101,105,110-223
granularity 整数 ロギング単位の分数。 Guardium は、レポートで要求された場合、この細分度で要求データを要約します。 例えば、ロギング単位が 60 の場合、ある要求が、指定した 1 時間に「n」回発生したことになります。 無効にすると、その時間内でコマンドが実行された正確な時刻は記録されません。 しかし、ポリシーのルールが要求によってトリガーされると、リアルタイム・アラートにより、正確な時刻を示すことができます。 ポリシーの例外ルールを定義するときに、それらのルールはログ単位にも適用されます。 例えば、1 時間に 5 回のログイン失敗を無視させるが、6 回目のログイン失敗時にアラートを送信させる場合などが考えられます。 有効な値:
  • 1
  • ※2
  • 5
  • 10
  • 15
  • 30時間まで
  • 60
inspectData ブール値 有効にすると、SQL 要求から返されたデータが検査され、Ingress 数と Egress 数が更新されます。 セキュリティー・ポリシーでルールが使用される場合は、このパラメーターを有効にする必要があります。 有効な値:
  • 0 (false)
  • 1 (真)
logExceptionSql ブール値 有効にすると、例外がログに記録されるときに、SQL ステートメント全体が記録されます。 有効な値:
  • 0 (false)
  • 1 (真)
logRecords ブール値 有効にすると、SQL ステートメント (該当する場合) ごとに、影響を受けるレコードの数が記録されます。 有効な値:
  • 0 (false)
  • 1 (真)
デフォルト = 0

「影響されるレコード」オプションは、スニファーに対して、追加の応答パケットを処理し、影響を受けたデータのロギングを延期するように要求するスニファー操作です。 これによって、バッファー・サイズが増え、スニファー全体のパフォーマンスに悪影響が出る可能性があります。 大きな影響を受けるのは、非常に大きい応答からです。 この操作に関連する大量のオーバーヘッドを避けるために、Guardium はデフォルトのしきい値セットを使用して、しきい値を超えたときに、処理操作をスキップすることをスニファーが決定できるようにします。

細分度のレベルを設定するには、 構成および制御 CLI コマンド store max_results_set_size、 store max_result_set_packet_size 、および store max_tds_response_packetsを参照してください。

「影響されるレコード」機能は、以下ではサポートされていません。
  • Db2 (ストリーミングを使用して結果を送信する場合)
  • AWS
  • Couchbase
  • Hadoop 統合
結果セットの値の例は次のとおりです。
  • ケース 1、「影響されるレコード」値: 正数。 これは、結果セットの正しいサイズを表します。
  • ケース 2、「影響されるレコード」値: -2。 これは、レコード数が構成可能な限度 (CLI コマンドによって調整可能) を超えたことを示します。
  • ケース 3、「影響されるレコード」値: -1。 これは、Guardium によってサポートされないパケット構成のケースを示します。
  • ケース 4、「影響されるレコード」値: -2。 結果セットがストリーム・モードで送信される場合。
  • ケース 5、「影響されるレコード」値: -2 未満。 現在の値についてユーザーを更新するためのレコード・カウント中の中間結果。最終的には、レコードの合計を示す正数になります。 例えば、サーバーが 4 つのパケットで 1000 件のレコードを返す場合、
    • パケット #1 250
    • パケット #2 200
    • パケット #3 250
    • パケット #4 200

    影響されるレコードは、次のとおり報告されます。

    • パケット #1 -250
    • パケット #2 -500
    • パケット #3 -750
    • パケット #4 1000
logSequencing ブール値 有効にすると、直前の SQL ステートメントと現在の SQL ステートメントのレコードが作成されます (ただし、前回の構成が十分短期間内に発生していることが条件となります)。 有効な値:
  • 0 (false)
  • 1 (真)
maxHits 整数 戻りデータが検査されるときに、いくつのヒット (ポリシー・ルール違反) が記録されるかを示します。
parseXml ブール値 検査エンジンは通常、XML トラフィックの構文解析を実行しません。 XML トラフィックの構文解析を有効にします。 有効な値:
  • 0 (false)
  • 1 (真)
recordEmpty ブール値 有効にすると、SQL ステートメントを含まないセッションがログに記録されます 無効にすると、これらのセッションは無視されます。 有効な値:
  • 0 (false)
  • 1 (真)
api_target_host ストリング

API の実行場所であるターゲット・ホストを指定します。有効な値
  • all_managed: すべての管理対象ユニットで実行しますが、中央マネージャーでは実行しません
  • all: すべての管理対象ユニットと中央マネージャーで実行します
  • group:<group name>: < group name> で識別されるすべての管理対象ユニットで実行します。
  • 管理対象ユニットのホスト名または IP アドレス: ある管理対象ユニットで実行するように中央マネージャーから指定されます。 例えば、api_target_host=10.0.1.123などです。
  • 中央マネージャーのホスト名または IP アドレス: 中央マネージャーで実行するように管理対象ユニットから指定されます。 例えば、api_target_host=10.0.1.123などです。

IP アドレスは、ネットワークの IP モードに規格適合している必要があります。 デュアル IP モードの場合、管理対象ユニットの中央マネージャーへの登録に使用されているものと同じ IP プロトコルを使用します。 例えば、登録で IPv6 が使用されている場合、IPv6 アドレスを指定します。 ホスト名は、IP モードには依存しないため、任意のモードで使用できます。

例

以下の GuardAPI の例では、3 つの検査エンジン・パラメーターを変更します。

grdapi update_engine_config defaultCapture=true logExceptionSql=false maxHits=32

成功した場合、コマンドから以下の情報が返されます。

ID=0
OK