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

1.6. Abstract Service Interfaces (抽象サービスインターフェース)

1.6. Abstract Service Interfaces (抽象サービスインターフェース)​

ユーザーベースセキュリティモデルは, 明確に定義された抽象サービスインターフェースを通じて SNMPv3 アーキテクチャと統合するように設計されています。これらのインターフェースにより, USM は他のサブシステムから独立して動作しながら, 必要なセキュリティサービスを提供できます。

Security Model Interface (セキュリティモデルインターフェース)​

USM は RFC 3411 で定義されたセキュリティモデルインターフェースを実装します。このインターフェースは 2 つの主要なプリミティブで構成されています:

1. generateRequestMsg (リクエストメッセージの生成)​

目的 (Purpose): セキュリティ関連情報を追加して送信 SNMP メッセージを処理します。

入力 (Inputs):

  • messageProcessingModel: SNMP バージョン (SNMPv3 の場合は 3)
  • globalData: グローバルメッセージヘッダー情報
  • maxMessageSize: サポートされる最大メッセージサイズ
  • securityModel: セキュリティモデル識別子 (USM の場合は 3)
  • securityEngineID: 権威ある SNMP エンジンの識別子
  • securityName: メッセージが生成される主体
  • securityLevel: 希望するセキュリティレベル (noAuthNoPriv, authNoPriv, または authPriv)
  • scopedPDU: 保護するメッセージペイロード

出力 (Outputs):

  • securityParameters: USM 固有のセキュリティパラメータ (engineID, engineBoots, engineTime, userName, 認証パラメータ, プライバシーパラメータ)
  • wholeMsg: 送信準備が整った完全なセキュアメッセージ
  • statusInformation: 成功またはエラー表示

処理 (Processing):

  1. 入力を検証
  2. ユーザーの認証およびプライバシー鍵を取得
  3. engineBoots と engineTime を増分して含める
  4. securityLevel にプライバシーが含まれる場合, プライバシープロトコルを適用
  5. securityLevel に認証が含まれる場合, 認証ダイジェストを計算
  6. 完全なメッセージを組み立てる

2. processIncomingMsg (受信メッセージの処理)​

目的 (Purpose): セキュリティ関連情報を検証して受信 SNMP メッセージを処理します。

入力 (Inputs):

  • messageProcessingModel: SNMP バージョン
  • maxMessageSize: サポートされる最大メッセージサイズ
  • securityParameters: 受信した USM セキュリティパラメータ
  • securityModel: セキュリティモデル識別子
  • securityLevel: 期待されるセキュリティレベル
  • wholeMsg: 受信した完全なメッセージ
  • securityEngineID: 権威あるエンジンの識別子 (メッセージから)

出力 (Outputs):

  • securityName: 認証された主体
  • scopedPDU: 復号化および検証されたメッセージペイロード
  • maxSizeResponseScopedPDU: 応答の最大サイズ
  • securityStateReference: 応答生成のための参照
  • statusInformation: 成功またはエラー表示

処理 (Processing):

  1. securityParameters を解析
  2. msgAuthoritativeEngineID がローカルエンジンと一致することを検証 (コマンドレスポンダーの場合)
  3. userName が usmUserTable に存在することを検証
  4. タイムウィンドウをチェック (engineBoots と engineTime)
  5. プライバシーが適用されている場合, メッセージを復号化
  6. 認証が適用されている場合, 認証ダイジェストを検証
  7. scopedPDU を抽出して返す

Integration with Message Processing Subsystem (メッセージ処理サブシステムとの統合)​

メッセージ処理サブシステムは, メッセージ処理の特定のポイントでこれらのインターフェースを通じて USM を呼び出します:

送信メッセージの場合 (For Outgoing Messages):

アプリケーション → ディスパッチャー → メッセージ処理 → セキュリティモデル (USM) → トランスポート

受信メッセージの場合 (For Incoming Messages):

トランスポート → ディスパッチャー → メッセージ処理 → セキュリティモデル (USM) → アプリケーション

Interaction with Access Control (アクセス制御との相互作用)​

USM は認証された securityName をアクセス制御サブシステム (VACM) に提供し, VACM はそれを使用して承認を決定します:

  1. USM がユーザーを認証して securityName を提供
  2. VACM が securityName, securityModel, securityLevel を使用してアクセス権を決定
  3. VACM が設定されたポリシーに基づいてアクセスを許可または拒否

この分離により以下が保証されます:

  • USM の焦点: "あなたは誰ですか?" (認証) と "メッセージは無傷ですか?" (完全性)
  • VACM の焦点: "何をすることが許可されていますか?" (承認)

Error Handling and Reports (エラー処理とレポート)​

USM がセキュリティエラーを検出すると, レポート-PDU を生成する可能性があります:

一般的なエラーシナリオ (Common Error Scenarios):

  1. 未知のエンジン ID (Unknown Engine ID): usmStatsUnknownEngineIDs カウンター増分

    • ディスカバリープロセス中に使用
    • レポートにはローカルエンジンの engineID が含まれる

  2. タイムウィンドウ違反 (Time Window Violation): usmStatsNotInTimeWindows カウンター増分

    • 時刻同期中に使用
    • レポートには現在の engineBoots と engineTime が含まれる

  3. 認証失敗 (Authentication Failure): usmStatsWrongDigests カウンター増分

    • パスワード/鍵が正しくないかメッセージの改ざんを示す
    • 受信メッセージと同じセキュリティレベルでレポートを送信

  4. 復号化失敗 (Decryption Failure): usmStatsDecryptionErrors カウンター増分

    • プライバシー鍵が正しくないかメッセージの破損を示す
    • 受信メッセージと同じセキュリティレベルでレポートを送信

  5. 未知のユーザー (Unknown User): usmStatsUnknownUserNames カウンター増分

    • userName が usmUserTable にないことを示す
    • 認証なしでレポートを送信

Service Primitive Sequences (サービスプリミティブシーケンス)​

Discovery Sequence (ディスカバリーシーケンス)​

1. アプリケーションが空の engineID でリクエストを送信
2. USM が securityLevel = noAuthNoPriv でメッセージを生成
3. 権威あるエンジンがメッセージを受信
4. USM が未知の engineID を検出
5. USM が usmStatsUnknownEngineIDs でレポートを生成
6. アプリケーションがレポートを受信し, engineID を学習

Time Synchronization Sequence (時刻同期シーケンス)​

1. アプリケーションがキャッシュされた engineID とゼロの engineBoots/Time でリクエストを送信
2. USM が認証済みメッセージを生成
3. 権威あるエンジンがメッセージを受信
4. USM がタイムウィンドウ違反を検出
5. USM が usmStatsNotInTimeWindows と現在の時刻値でレポートを生成
6. アプリケーションがレポートを受信し, キャッシュされた時刻値を更新
7. アプリケーションが同期された時刻で元のリクエストを再試行

Authenticated Communication Sequence (認証済み通信シーケンス)​

1. アプリケーションがリクエストを送信
2. USM が現在の engineBoots/Time で認証済みメッセージを生成
3. USM が認証ダイジェストを計算
4. 権威あるエンジンがメッセージを受信
5. USM がタイムウィンドウを検証
6. USM が認証ダイジェストを検証
7. USM が scopedPDU を抽出
8. アプリケーションがリクエストを処理
9. アプリケーションが応答を生成
10. USM が認証済み応答メッセージを生成
11. 非権威あるエンジンが応答を受信
12. USM が認証ダイジェストを検証
13. USM が scopedPDU を抽出
14. アプリケーションが応答を処理

Asynchronous vs. Synchronous Operation (非同期 vs. 同期操作)​

抽象サービスインターフェースは両方をサポートするように設計されています:

同期操作 (Synchronous Operation):

  • アプリケーションが応答を待つ
  • コマンドジェネレーター/レスポンダーモデルの典型

非同期操作 (Asynchronous Operation):

  • アプリケーションは待たない
  • 通知発信者/受信者モデルの典型

USM は操作モデルを指示しません。アプリケーションがどのように操作することを選択しても, 単にセキュリティサービスを提供します。

に最終更新