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

Appendix A. Guidelines for Model Designers (付録A. モデル設計者のためのガイドライン)

Appendix A. Guidelines for Model Designers (付録A. モデル設計者のためのガイドライン)​

この付録は, セキュリティモデル, メッセージ処理モデル, アクセス制御モデル, および SNMP アプリケーションの設計者のためのガイドラインを提供します。これらのガイドラインは情報提供を目的としており, SNMP アーキテクチャ内で適切に動作するコンポーネントの作成を支援することを目的としています。

A.1. Security Model Design Requirements (セキュリティモデル設計要件)​

セキュリティモデルは, 認証, プライバシー, 適時性チェックのメカニズムを提供しなければなりません。このセクションでは, セキュリティモデルの要件について説明します。

A.1.1. Threats (脅威)​

セキュリティモデルは以下の脅威に対処しなければなりません:

  1. 情報の変更 (Modification of Information): 不正なエンティティが転送中のメッセージを変更する

    • セキュリティモデルは, このような変更を検出するためのデータ完全性サービスを提供しなければなりません

  2. なりすまし (Masquerade): 不正なエンティティが認可されたエンティティの身元を装う

    • セキュリティモデルは, 身元を確認するための認証サービスを提供しなければなりません

  3. メッセージストリーム変更 (Message Stream Modification): メッセージの並べ替え, 遅延, またはリプレイ

    • セキュリティモデルは, このような攻撃を検出するための適時性チェックを提供しなければなりません

  4. 開示 (Disclosure): 不正なエンティティへのメッセージ内容の公開

    • セキュリティモデルは, 暗号化を通じて機密性サービスをオプションで提供できます

A.1.2. Security Processing (セキュリティ処理)​

セキュリティモデルは以下の抽象サービスプリミティブを実装しなければなりません:

  1. generateRequestMsg: 送信リクエストおよび通知メッセージにセキュリティ処理を適用

    • 入力: scopedPDU, セキュリティパラメータ
    • 出力: 送信準備ができたセキュア化されたメッセージ
    • 処理:
      • 認証を適用 (セキュリティレベルで必要な場合)
      • 暗号化を適用 (セキュリティレベルで必要な場合)
      • メッセージにセキュリティパラメータを追加
      • メッセージが securityLevel に従って保護されることを確認

  2. processIncomingMsg: 受信メッセージのセキュリティを処理

    • 入力: 受信したメッセージ
    • 出力: 抽出された scopedPDU, セキュリティパラメータ
    • 処理:
      • 認証を検証 (メッセージが認証されていると主張する場合)
      • メッセージを復号化 (メッセージが暗号化されている場合)
      • 適時性をチェック (リプレイ攻撃を防ぐため)
      • scopedPDU を抽出
      • 応答が必要な場合, セキュリティ状態をキャッシュ

  3. generateResponseMsg: 送信応答メッセージにセキュリティ処理を適用

    • 入力: scopedPDU, キャッシュされたセキュリティ状態
    • 出力: セキュア化された応答メッセージ
    • 処理:
      • キャッシュされた状態からセキュリティパラメータを取得
      • リクエストと同じセキュリティレベルを適用
      • 認証を適用 (必要な場合)
      • 暗号化を適用 (必要な場合)

A.1.3. Validate the security-stamp in a received message (受信メッセージのセキュリティスタンプの検証)​

セキュリティモデルは以下を検証しなければなりません:

  1. 認証が有効: メッセージが認証されていると主張する場合, 認証コードを検証

    • 適切な暗号検証を使用 (例: HMAC 検証)
    • 無効な認証のメッセージを拒否

  2. メッセージが適時: メッセージがリプレイでないことを検証

    • メッセージタイミングパラメータをチェック
    • リプレイを検出するための状態を維持
    • タイムウィンドウ外のメッセージを拒否

  3. プライバシーが正しく適用されている: メッセージが暗号化されている場合, 復号化できることを検証

    • 適切なキーを使用して復号化を試みる
    • 復号化が成功したことを検証
    • 復号化できないメッセージを拒否

  4. セキュリティレベルが要件と一致: 実際に適用されたセキュリティが要求されたものと一致することを検証

    • authNoPriv メッセージが認証されているが暗号化されていないことを確認
    • authPriv メッセージが認証と暗号化の両方がされていることを確認
    • noAuthNoPriv メッセージが認証も暗号化もされていないことを確認

A.1.4. Security MIBs (セキュリティ MIB)​

セキュリティモデルは以下を可能にする MIB モジュールを定義すべきです:

  1. セキュリティパラメータの設定: ユーザー, キー, 認証プロトコル, プライバシープロトコル
  2. セキュリティの監視: 認証失敗, 復号化エラーなどのカウンター
  3. 遠隔設定: セキュリティを遠隔で設定するための安全なメカニズム

ユーザーベースセキュリティモデル (USM) は, この目的のために SNMP-USER-BASED-SM-MIB を定義しています。

A.1.5. Cached Security Data (キャッシュされたセキュリティデータ)​

応答を必要とする可能性のある受信リクエストを処理するとき, セキュリティモデルはセキュリティ状態情報をキャッシュしなければなりません。このキャッシュされたデータにより, リクエストと同じセキュリティパラメータを使用して応答をセキュア化できます。

キャッシュされたセキュリティデータには通常以下が含まれます:

  • リクエストからのセキュリティパラメータ
  • 認証および/または暗号化に使用されるキー
  • タイミングパラメータ
  • 応答を生成するために必要なその他の状態

セキュリティモデルは以下を行わなければなりません:

  1. securityStateReference を生成: キャッシュされた状態の一意の識別子
  2. securityStateReference を返す: メッセージ処理モデルに
  3. キャッシュされた状態を取得: generateResponseMsg が呼び出されたとき
  4. キャッシュされた状態を解放: 応答が生成された後, または明示的に解放されたとき

キャッシュされた状態は以下の場合に暗黙的に解放される可能性があります:

  • 応答が正常に生成された
  • エラーが発生し, 応答が送信されない
  • タイムアウトが発生

キャッシュされた状態は stateRelease プリミティブを使用して明示的に解放できます。

A.2. Message Processing Model Design Requirements (メッセージ処理モデル設計要件)​

メッセージ処理モデルは, メッセージ形式とその形式のメッセージを処理するための手順を定義します。このセクションでは, メッセージ処理モデルの要件について説明します。

A.2.1. Receiving an SNMP Message from the Network (ネットワークからの SNMP メッセージの受信)​

ネットワークからメッセージが受信されると, ディスパッチャーはそれを処理すべきメッセージ処理モデルを決定します (メッセージのバージョンまたは形式に基づいて)。メッセージ処理モデルは prepareDataElements プリミティブを実装しなければなりません。

prepareDataElements 処理:

  1. メッセージ形式を解析: メッセージからさまざまなコンポーネントを抽出

    • メッセージヘッダー
    • セキュリティパラメータ
    • スコープ付き PDU またはペイロード

  2. セキュリティモデルを決定: どのセキュリティモデルが使用されたかを識別

    • 通常メッセージヘッダーに示されている

  3. セキュリティモデルを呼び出す: processIncomingMsg を呼び出して:

    • 認証を検証
    • メッセージを復号化
    • 適時性をチェック
    • スコープ付き PDU を抽出

  4. スコープ付き PDU を解析: 以下を抽出:

    • contextEngineID
    • contextName
    • PDU

  5. 必要に応じて状態をキャッシュ: 応答を必要とする可能性のあるリクエストの場合:

    • 応答を生成するために必要な情報をキャッシュ
    • stateReference を生成
    • stateReference をキャッシュされたデータと関連付ける

  6. 抽出されたデータ要素を返す: すべての必要な情報をディスパッチャーに返す:

    • messageProcessingModel
    • securityModel
    • securityName
    • securityLevel
    • contextEngineID
    • contextName
    • pduVersion
    • PDU
    • pduType
    • maxSizeResponseScopedPDU
    • stateReference
    • statusInformation

エラー処理:

いずれかのステップが失敗した場合, ディスパッチャーに適切なエラー statusInformation を返します。不正な形式または認証されていないメッセージをアプリケーションに渡さないでください。

A.2.2. Sending an SNMP Message to the Network (ネットワークへの SNMP メッセージの送信)​

メッセージを送信するとき, ディスパッチャーは prepareOutgoingMessage (リクエストと通知の場合) または prepareResponseMessage (応答の場合) のいずれかを呼び出します。メッセージ処理モデルはこれらのプリミティブを実装しなければなりません。

prepareOutgoingMessage 処理:

  1. スコープ付き PDU を作成: contextEngineID, contextName, PDU を結合

  2. セキュリティモデルを呼び出す: generateRequestMsg を呼び出して:

    • 認証を適用 (必要な場合)
    • 暗号化を適用 (必要な場合)
    • セキュリティパラメータを追加

  3. メッセージを作成: セキュリティで保護されたペイロードを適切なメッセージ形式でラップ

    • メッセージヘッダーを追加
    • バージョンまたは形式識別子を追加
    • メッセージ固有のフィールドを追加

  4. 完全なメッセージを返す: 送信準備が整った形式化されたメッセージを返す:

    • outgoingMessage
    • outgoingMessageLength
    • statusInformation

prepareResponseMessage 処理:

prepareOutgoingMessage と同様ですが:

  1. キャッシュされた状態を取得: stateReference を使用してキャッシュされた情報を取得

  2. スコープ付き PDU を作成: contextEngineID, contextName, PDU を結合 (元のリクエストから)

  3. セキュリティモデルを呼び出す: 以下で generateResponseMsg を呼び出す:

    • スコープ付き PDU
    • securityStateReference (リクエストと同じセキュリティパラメータを使用)

  4. 応答メッセージを作成: セキュリティで保護されたペイロードを適切な形式でラップ

  5. キャッシュされた状態を解放: 応答の作成に成功した後, キャッシュされた状態を解放

  6. 完全な応答を返す: 形式化された応答メッセージを返す

エラー処理:

いずれかのステップが失敗した場合, 適切なエラー statusInformation を返します。応答を生成できない場合, キャッシュされた状態が解放されることを確認してください。

A.3. Application Design Requirements (アプリケーション設計要件)​

SNMP アプリケーションは SNMP エンジンのサービスを使用して管理機能を実行します。このセクションでは, アプリケーション設計の要件とガイドラインについて説明します。

A.3.1. Applications that Initiate Messages (メッセージを開始するアプリケーション)​

メッセージを開始するアプリケーション (コマンドジェネレーター, 通知発信者) は以下を行わなければなりません:

  1. 宛先を決定: ターゲット SNMP エンジンを識別

    • transportDomain
    • transportAddress
    • contextEngineID

  2. セキュリティパラメータを決定:

    • securityModel
    • securityName
    • securityLevel

  3. PDU を作成: 目的の操作と変数を使用してプロトコルデータユニットを構築

  4. sendPdu を呼び出す: ディスパッチャーの sendPdu プリミティブを以下で呼び出す:

    • 宛先情報
    • セキュリティパラメータ
    • contextEngineID と contextName
    • PDU
    • expectResponse フラグ
    • sendPduHandle (後の応答を関連付けるため)

  5. 応答を処理: expectResponse が TRUE の場合, processResponsePdu を実装して応答を受信

ガイドライン:

  • 宛先を設定: 設定メカニズム (例: SNMP-TARGET-MIB) を使用して宛先情報を管理
  • セキュリティを設定: 設定メカニズム (例: SNMP-USER-BASED-SM-MIB) を使用してセキュリティパラメータを管理
  • エラーを処理: sendPdu からの statusInformation エラーを適切に処理
  • タイムアウトを実装: 妥当な時間内に応答が受信されない場合, タイムアウトを処理
  • 再試行を実装: 応答が受信されない場合, 再送信を検討

A.3.2. Applications that Receive Responses (応答を受信するアプリケーション)​

応答を受信するアプリケーションは processResponsePdu プリミティブを実装しなければなりません。

processResponsePdu 実装:

  1. 応答を関連付け: sendPduHandle を使用して応答を元のリクエストと一致させる

  2. statusInformation をチェック: メッセージ処理が成功したことを検証

  3. PDU を処理: 応答データを抽出して処理

    • error-status と error-index をチェック
    • 変数バインディングを抽出
    • アプリケーション固有の処理を実行

ガイドライン:

  • エラーを処理: SNMP エラー (例: noSuchName, tooBig, genErr) をチェック
  • 例外を処理: 例外値 (noSuchObject, noSuchInstance, endOfMibView) をチェック
  • セキュリティエラーを処理: 認証またはプライバシーの失敗に備える
  • 状態をクリーンアップ: リクエストに関連するリソースを解放

A.3.3. Applications that Receive Asynchronous Messages (非同期メッセージを受信するアプリケーション)​

非同期メッセージを受信するアプリケーション (コマンドレスポンダー, 通知受信者) は以下を行わなければなりません:

  1. ディスパッチャーに登録: registerContextEngineID を呼び出して以下に登録:

    • 特定の contextEngineID 値
    • 特定の PDU タイプ

  2. processPdu を実装: 受信 PDU を受信して処理

    • contextEngineID と contextName を検証
    • アプリケーションセマンティクスに従って PDU を処理
    • 応答を生成 (必要な場合)

processPdu 実装:

  1. コンテキストを検証: このアプリケーションが contextEngineID と contextName に責任があることを確認

  2. アクセス制御をチェック (適切な場合): PDU 内の各変数に対して isAccessAllowed を呼び出す

  3. リクエストを処理: 要求された操作を実行

    • GET の場合: 変数値を取得
    • SET の場合: 変数値を変更
    • GETNEXT の場合: 辞書順で次の変数を見つける
    • GETBULK の場合: 複数の変数を効率的に取得

  4. 応答 PDU を構築 (必要な場合): 結果を含む応答 PDU を作成

  5. returnResponsePdu を呼び出す (必要な場合): 応答を要求者に送り返す

ガイドライン:

  • 入力を検証: セキュリティ脆弱性を防ぐためにすべての入力を注意深く検証
  • アクセス制御を実装: すべての操作に適切なアクセス制御を適用
  • エラーを適切に処理: 無効なリクエストに対して適切なエラー応答を返す
  • maxSizeResponseScopedPDU を尊重: 応答がサイズ制限を超えないことを確認
  • stateReference を使用: processPdu から returnResponsePdu に stateReference を変更せずに渡す

A.3.4. Applications that Send Responses (応答を送信するアプリケーション)​

応答を送信するアプリケーションは returnResponsePdu プリミティブを使用しなければなりません。

returnResponsePdu の使用:

  1. processPdu からのパラメータを使用: 以下を渡す:

    • messageProcessingModel
    • securityModel
    • securityName
    • securityLevel
    • contextEngineID
    • contextName
    • pduVersion
    • maxSizeResponseScopedPDU
    • stateReference

  2. 応答 PDU を作成: 結果を含む PDU を構築

  3. returnResponsePdu を呼び出す: ディスパッチャーの returnResponsePdu プリミティブを呼び出す

ガイドライン:

  • セキュリティパラメータを変更しない: リクエストと同じセキュリティパラメータを使用
  • サイズ制限を尊重: 応答が maxSizeResponseScopedPDU 内に収まることを確認
  • エラーを処理: 応答を送信できない場合, エラーを適切に処理
  • 状態を解放: 応答の送信後, ディスパッチャーによって stateReference が解放されます

A.4. Access Control Model Design Requirements (アクセス制御モデル設計要件)​

アクセス制御モデルは, 管理対象オブジェクトへのアクセスを許可すべきかどうかを決定します。このセクションでは, アクセス制御モデルの要件について説明します。

アクセス制御モデルは isAccessAllowed プリミティブを実装しなければなりません。

isAccessAllowed 実装:

  1. プリンシパルを決定: 誰がアクセスを試みているかを識別

    • securityModel と securityName を使用

  2. アクセスタイプを決定: どのタイプのアクセスが要求されているかを識別

    • read: GET, GETNEXT, GETBULK
    • write: SET
    • notify: TRAP, INFORM

  3. ターゲットを決定: どのオブジェクトがアクセスされているかを識別

    • variableName (OID)
    • contextName

  4. アクセス制御ポリシーを適用: 設定されたポリシーに基づいて, アクセスを許可すべきかどうかを決定

  5. 結果を返す: 許可または拒否を返す

ガイドライン:

  • MIB を定義: アクセス制御ポリシーを設定するための MIB モジュールを定義
  • 遠隔設定をサポート: SNMP 経由でポリシーを設定できるようにする
  • デフォルトで拒否: 明示的なポリシーがアクセスを許可しない場合, デフォルトで拒否
  • 効率的な実装: アクセス制御はリクエストごとに何度も呼び出される可能性があります。効率的に実装
  • 一貫したポリシー: ポリシーが一貫して適用されることを確認

RFC 3415 で定義されたビューベースアクセス制御モデル (VACM) は実装例です。

に最終更新