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

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

11.1. 推奨される実践​

このセクションでは、このメモで定義されているメカニズムの安全で効果的な動作に貢献する実践について説明します。

  • SNMPエンジンは、現在未処理のリクエストメッセージに対応しないSNMPレスポンスメッセージを破棄する必要があります。これに対処するのはメッセージ処理モジュールの責任です。たとえば、msgIDを使用できます。

    SNMPコマンドジェネレータアプリケーションは、現在未処理の確認済みクラスPDUに対応しないレスポンスクラスPDUを破棄する必要があります。たとえば、SNMPv2 [RFC3416] PDUの場合、PDUのrequest-idコンポーネントを使用してレスポンスを未処理のリクエストに関連付けることができます。

    SNMPエンジンとSNMPコマンドジェネレータアプリケーションが通常これを当然のこととして行うのは一般的ですが、これらのセキュリティプロトコルを使用する場合、メッセージの重複(悪意のあるものか否かを問わず)の可能性があるため、重要です。

  • SNMPエンジンがレスポンスメッセージを未処理のリクエストメッセージに関連付けるためにmsgIDを使用する場合、タイムウィンドウ(150秒)期間中に送信するすべてのリクエストメッセージで異なるmsgIDを使用する必要があります。

    コマンドジェネレータまたは通知発信者アプリケーションは、タイムウィンドウ(150秒)期間中に送信するすべてのリクエストPDUで異なるrequest-idを使用する必要があります。

    これは、メッセージの重複(悪意のあるものか否かを問わず)の可能性から保護するために行う必要があります。

    たとえば、msgIDおよび/またはrequest-id値をゼロから開始することは良い考えではありません。予測不可能な番号で初期化し(各再起動後に同じ値から始まらないようにする)、1ずつインクリメントすることは許容されます。

  • SNMPエンジンは、メッセージの重複(悪意のあるものか否かを問わず)の可能性から保護するために、認証されたメッセージを使用して時刻同期を実行する必要があります。

  • 管理された権威あるSNMPエンジンに状態変更メッセージを送信する場合、コマンドジェネレータアプリケーションは、前のメッセージの肯定的な確認応答を受信するか、前のメッセージが期限切れになるまで、その管理されたSNMPエンジンへの後続のメッセージの送信を遅らせる必要があります。

    SNMPによってメッセージの順序は課されません。メッセージは、生成時刻に対して任意の順序で受信され、それぞれが受信された順序で処理されます。認証されたメッセージが管理されたSNMPエンジンに送信されると、通常の状況では約150秒間有効であり、この期間中にリプレイの対象となることに注意してください。実際、SNMPエンジンとSNMPコマンドジェネレータアプリケーションは、ネットワークの異常から生じるメッセージの損失と再順序付けに通常対処する必要があります。

    ただし、管理対象オブジェクトsnmpSetSerialNo [RFC3418]は、SNMPメッセージの処理が特定の順序で行われることを保証するメカニズムを提供するために、SNMP Set操作で使用するために特に定義されています。

  • ユーザーベースセキュリティモデルユーザーのシークレットを変更する頻度は、その使用頻度と間接的に関連しています。

    シークレットを開示から保護することは、プロトコル全体のセキュリティにとって重要です。シークレットを頻繁に使用すると、暗号解析者がアルゴリズムの既知または認識された弱点を悪用するのに役立つ可能性のあるデータの継続的なソースが提供されます。シークレットを頻繁に変更することで、この脆弱性を回避できます。

    使用するたびにシークレットを変更することは、一般に最も安全な実践と見なされていますが、かなりのオーバーヘッドが関連付けられている可能性があります。

    また、ローカル環境では、開示の脅威がそれほど重要ではない可能性があり、そのためシークレットの変更頻度が低くなる可能性があることに注意してください。ただし、公衆データネットワークが通信パスとして使用される場合は、より慎重になることが賢明です。

11.2 ユーザーの定義​

このドキュメントで定義されているメカニズムは、メッセージが送信されるユーザーの概念を採用しています。「ユーザー」の定義方法は、ネットワーク管理のセキュリティポリシーの対象となります。たとえば、ユーザーは個人(「joe」や「jane」など)、特定の役割(「operator」や「administrator」など)、または組み合わせ(「joe-operator」、「jane-operator」、「joe-admin」など)である可能性があります。さらに、ユーザーは、個人または役割、個人のセット、役割のセット、組み合わせを含む、SNMPアプリケーションまたは一連のSNMPアプリケーションなどの論理エンティティである可能性があります。

付録Aでは、ユーザーの「パスワード」を、ユーザーの認証鍵またはプライバシー鍵(またはその両方)として使用する16/20オクテット値にマッピングするためのアルゴリズムについて説明しています。ただし、認証とプライバシーの両方に同じパスワード(したがって同じ鍵)を使用することは、非常に貧弱なセキュリティ実践であり、強く非推奨であることに注意してください。パスワードは、多くの場合、人間によって生成、記憶、入力されます。人間が生成したパスワードは、認証およびプライバシープロトコルで必要な16/20オクテットよりも少ない場合があり、比較的短いASCII文字セットに対するブルートフォース攻撃は非常に簡単です。したがって、付録Aのアルゴリズムは、パスワードに対して変換を実行します。付録Aアルゴリズムが使用される場合、SNMP実装(およびSNMP構成アプリケーション)は、パスワードが少なくとも8文字の長さであることを保証する必要があります。繰り返し文字列を含むより長いパスワードは、まったく同じ鍵になる可能性があることに注意してください。たとえば、パスワード「bertbert」は、パスワード「bertbertbert」とまったく同じ鍵になります。

付録Aアルゴリズムはこのようなパスワードを(ほぼ)直接使用するため、推測しにくいことが非常に重要です。辞書で見つかる単語やフレーズを形成しない大文字小文字混在の英数字と句読点文字で構成されることをお勧めします。より長いパスワードは、システムのセキュリティを向上させます。ユーザーは、パスワード文字列を長くしながら、記憶しやすいように複数の単語フレーズを入力したい場合があります。

人間のユーザーがすべてのSNMPエンジンに対して異なるパスワードを維持することは実行不可能ですが、セキュリティ要件では複数のSNMPエンジンに対して同じ鍵を持つことを強く非推奨としているため、ユーザーベースセキュリティモデルは[Localized-key]で提案された妥協案を採用しています。ユーザーのパスワードからSNMPエンジンのユーザー鍵を導出する方法で、SNMPエンジン上のユーザーの鍵の任意の組み合わせから、ユーザーのパスワードまたは別のSNMPエンジンのユーザーの鍵を決定することは事実上不可能です。

ただし、ユーザーのパスワードが開示された場合、鍵のローカリゼーションは役に立たず、この場合ネットワークセキュリティが侵害される可能性があることに注意してください。したがって、ユーザーのパスワードまたはローカライズされていない鍵は、管理対象デバイス/ノードに保存してはなりません。代わりに、ローカライズされた鍵を保存する必要があります(保存する場合)。これにより、デバイスが侵害された場合でも、他の管理対象または管理デバイスが侵害されないようになります。

11.3. 適合性​

ユーザーベースセキュリティモデルに基づく「安全なSNMP実装」と呼ばれるためには、SNMP実装は次のことを行う必要があります:

  • 1つ以上の認証プロトコルを実装する。このメモで定義されているHMAC-MD5-96およびHMAC-SHA-96認証プロトコルは、そのようなプロトコルの例です。

  • 可能な限り、ローカル設定データストア(LCD)で保持している各ユーザーのシークレットへのアクセスを、そのユーザーに関するSNMPメッセージを生成および/または検証するために必要な場合を除き、すべての状況で禁止する。

  • 鍵ローカリゼーションメカニズムを実装する。

  • SNMP-USER-BASED-SM-MIBを実装する。

さらに、権威あるSNMPエンジンは、付録A.1に従って初期設定を提供する必要があります。

プライバシープロトコルの実装(このメモで定義されているDES対称暗号化プロトコルは、そのようなプロトコルの1つです)はオプションです。

11.4. レポートの使用​

安全でないレポート(つまり、noAuthNoPrivのsecurityLevelで送信される)の使用は、権威のないSNMPエンジンを何らかの形式の攻撃にさらす可能性があります。一部の人々はこれらをサービス拒否攻撃と見なし、他の人々はそうではありません。インストールでは、安全でないレポートPDUを展開する前に、関連するリスクを評価する必要があります。

11.5 SNMP-USER-BASED-SM-MIBへのアクセス​

このMIBのオブジェクトは、多くの環境で機密と見なされる場合があります。具体的には、usmUserTableのオブジェクトには、ユーザーとその認証およびプライバシープロトコルに関する情報が含まれています。適切に構成されたアクセス制御モデル(たとえば、[RFC3415]で指定されているビューベースのアクセス制御モデル)を使用して、これらのMIBオブジェクトへのアクセス(読み取りと書き込みの両方)を厳密に制御することが重要です。

に最終更新