メインコンテンツまでスキップ

6. 通知フィルタリング

通知フィルタリングは、通知の内容に基づいて管理ターゲットに選択的に通知を送信するメカニズムを提供します。これにより、どの管理ターゲットがどのタイプの通知を受信するかをきめ細かく制御できます。

通知フィルタリングは3つのMIBテーブルを使用します：

  • snmpNotifyFilterProfileTable: フィルタープロファイル名を一連のターゲットパラメータに関連付けます。
  • snmpNotifyFilterTable: 通知内容に基づいて実際のフィルタールールを定義します。
  • snmpTargetParamsTable: フィルタープロファイルテーブルによって参照されるターゲットパラメータ名を含みます。

フィルター処理アルゴリズム​

通知オリジネータが管理ターゲットの通知を生成するとき、次のように通知フィルタリングを適用します：

  1. 管理ターゲットのsnmpTargetAddrParamsオブジェクトからターゲットパラメータ名を取得します。

  2. ターゲットパラメータ名をインデックスとして使用して、snmpNotifyFilterProfileTableでフィルタープロファイルを検索します。

  3. フィルタープロファイルが見つからない場合、通知が送信されます（フィルタリングは適用されません）。

  4. フィルタープロファイルが見つかった場合、snmpNotifyFilterProfileNameがsnmpNotifyFilterTable内の一連のフィルターエントリを識別します。

  5. 通知内の各変数バインディングについて：

    a. フィルタープロファイル名と一致するsnmpNotifyFilterTableのエントリを検索します。

    b. エントリはインデックスの辞書順に処理されます。

    c. 各フィルターエントリについて、snmpNotifyFilterSubtreeで指定されたサブツリーが変数のオブジェクト識別子と一致するかどうかを確認します。

    d. 変数のOIDがフィルターサブツリー内またはそれと等しい場合（指定されている場合はsnmpNotifyFilterMaskを考慮して）、一致が発生します。

    e. 一致が見つかった場合：

    • snmpNotifyFilterTypeがincluded(1)の場合、他の変数のチェックを続けます。
    • snmpNotifyFilterTypeがexcluded(2)の場合、この管理ターゲットに通知を送信しません。

    f. すべてのフィルターエントリをチェックした後に変数の一致が見つからない場合、通知を送信しません。

  6. すべての変数バインディングがフィルターを通過した場合、管理ターゲットに通知を送信します。

フィルターマスクのセマンティクス​

snmpNotifyFilterMaskオブジェクトは、サブツリーマッチングに対するビットレベルの制御を提供します。これは、次のセマンティクスを持つビットマスクです：

  • マスク内の各オクテットは、フィルターサブツリーOID内のサブ識別子に対応します。
  • オクテット内の各ビットは、サブ識別子内のビットに対応します。
  • マスク内のビットが1の場合、サブ識別子内の対応するビットは変数のOIDと一致する必要があります。
  • マスク内のビットが0の場合、サブ識別子内の対応するビットは無視されます（ワイルドカード）。

ゼロ長マスク（デフォルト）は、すべてのサブ識別子が完全に一致する必要があることを意味します。

マスク使用例：​

フィルターサブツリー: 1.3.6.1.2.1.2.2.1.8
マスク: 0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFE

このマスクは、最後のサブ識別子の最後のビットがワイルドカードであるため、1.3.6.1.2.1.2.2.1.8（ifOperStatus）と1.3.6.1.2.1.2.2.1.9（ifLastChange）の両方のマッチングを許可します。

構成例​

例1：管理ターゲットへのすべての通知の送信​

フィルタリングなしで管理ターゲットにすべての通知を送信するには：

  1. ターゲットのパラメータ名のsnmpNotifyFilterProfileTableにエントリを作成しません。

または

  1. 単一の包含フィルターを持つフィルタープロファイルを作成します：
    • snmpNotifyFilterSubtree: 1（または任意のルートOID）
    • snmpNotifyFilterMask: ""（空）
    • snmpNotifyFilterType: included(1)

例2：インターフェース関連の通知のみの送信​

インターフェース（ifTable）に関連する通知のみを送信するには：

snmpNotifyFilterProfileTableエントリ:

  • snmpNotifyFilterProfileName: "interfaceFilter"
  • ターゲットパラメータ名に関連付け: "stationAParams"

snmpNotifyFilterTableエントリ:

エントリ1:

  • snmpNotifyFilterProfileName: "interfaceFilter"
  • snmpNotifyFilterSubtree: 1.3.6.1.2.1.2
  • snmpNotifyFilterMask: ""
  • snmpNotifyFilterType: included(1)

この構成により、interfacesグループ（1.3.6.1.2.1.2）からの変数を含む通知の送信が許可され、他のすべての通知がフィルタリングされます。

例3：特定の通知の除外​

TCP接続テーブルに関連する通知を除くすべての通知を送信するには：

snmpNotifyFilterProfileTableエントリ:

  • snmpNotifyFilterProfileName: "noTcpConnections"
  • ターゲットパラメータ名に関連付け: "stationBParams"

snmpNotifyFilterTableエントリ:

エントリ1:

  • snmpNotifyFilterProfileName: "noTcpConnections"
  • snmpNotifyFilterSubtree: 1
  • snmpNotifyFilterMask: ""
  • snmpNotifyFilterType: included(1)

エントリ2:

  • snmpNotifyFilterProfileName: "noTcpConnections"
  • snmpNotifyFilterSubtree: 1.3.6.1.2.1.6.13
  • snmpNotifyFilterMask: ""
  • snmpNotifyFilterType: excluded(2)

この構成はすべての通知を含みますが（エントリ1）、tcpConnTableからの変数を含む通知は明示的に除外します（エントリ2）。

実装に関する考慮事項​

パフォーマンス​

通知フィルタリングには、各変数バインディングについて、潜在的に複数のフィルターエントリに対するOID比較が必要です。実装はこのプロセスを最適化する必要があります：

  • OIDルックアップに効率的なデータ構造（トライやハッシュテーブルなど）を使用します。
  • 頻繁に使用される管理ターゲットのフィルタープロファイルルックアップをキャッシュします。
  • 構成時にフィルタールールを事前コンパイルすることを検討します。

フィルター順序​

フィルターエントリはインデックスの辞書順に処理されます。これは以下を意味します：

  • より広い包含に対して、より具体的な（より長いOID）除外を適切に構成する必要があります。
  • フィルターエントリの順序がフィルタリングの結果に影響を与える可能性があります。

デフォルトの動作​

ターゲットのパラメータにフィルタープロファイルが存在しない場合：

  • デフォルトの動作は通知を送信することです（フィルタリングなし）。
  • これにより、通知フィルタリングを使用しないシステムとの下位互換性が確保されます。

変数バインディング要件​

RFC 3416では、通知に少なくとも2つの変数バインディングを含める必要があります：

  1. sysUpTime.0
  2. snmpTrapOID.0

これらの必須の変数バインディングは、通知を送信するためにフィルターを通過する必要があります。フィルターがこれらのOIDを除外する場合、その管理ターゲットに通知は送信されません。

セキュリティに関する考慮事項​

通知フィルタリングは、いくつかの方法でセキュリティに影響を与える可能性があります：

  1. 情報開示の防止: フィルタリングにより、機密情報が未承認の管理ステーションに送信されるのを防ぐことができます。

  2. 構成の保護: フィルター構成テーブル（snmpNotifyFilterProfileTableとsnmpNotifyFilterTable）は、未承認の変更を防ぐためにアクセス制御によって保護する必要があります。

  3. フィルターのバイパス: 不適切なフィルター構成（過度に広い包含ルールなど）により、意図しない通知が送信される可能性があります。

  4. サービス拒否: 過度に複雑なフィルタールールは過剰な処理リソースを消費し、サービス拒否を引き起こす可能性があります。

包括的なセキュリティを確保するために、適切なアクセス制御（VACMなど）およびSNMPv3セキュリティ機能と組み合わせて通知フィルタリングを使用することをお勧めします。

に最終更新