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

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

この文書は、SNMPアプリケーションの動作を構成するためのメカニズムを定義しています。これらのアプリケーションは、SNMPv3セキュリティ機能を使用する際に安全な通信を提供するSNMPエンジンに関連付けられる場合があります。

ただし、考慮すべきいくつかのセキュリティ上の考慮事項があります：

10.1. 構成のセキュリティ​

この文書で定義されているMIBモジュール（SNMP-TARGET-MIB、SNMP-NOTIFICATION-MIB、およびSNMP-PROXY-MIB）には、SNMP通信のセキュリティ態勢に直接影響を与える構成情報が含まれています：

機密オブジェクト​

いくつかのオブジェクトには、機密性の高いセキュリティ情報が含まれているか、参照しています：

  • snmpTargetParamsSecurityName: セキュリティ資格情報を含みます（SNMPv1/v2cのコミュニティ文字列、SNMPv3のユーザー名）。
  • snmpTargetParamsSecurityModelおよびsnmpTargetParamsSecurityLevel: 使用されるセキュリティメカニズムと保護レベルを定義します。
  • snmpProxyTargetParamsIn: プロキシへの受信メッセージのセキュリティパラメータを参照します。

これらのオブジェクトは、以下を防ぐために適切なアクセス制御で保護する必要があります：

  • 未承認の開示: セキュリティ名/コミュニティ文字列の読み取り。
  • 未承認の変更: セキュリティパラメータの変更によるセキュリティの弱体化またはトラフィックのリダイレクト。

推奨されるアクセス制御​

この文書のMIBモジュールを実装するSNMPエンティティには、次のことが推奨されます：

  1. これらのMIBオブジェクトへのすべての管理アクセスに対してSNMPv3セキュリティ機能（USM）を使用する。
  2. VACM（ビューベースアクセス制御モデル）を構成して、これらのオブジェクトへのアクセスを承認されたセキュリティ管理者のみに制限する。
  3. セキュリティに敏感なオブジェクトにアクセスする際に認証と暗号化（authPrivセキュリティレベル）を使用する。

10.2. 通知のセキュリティ​

情報開示​

通知には、管理対象システムに関する機密情報が含まれている場合があります。通知ターゲットの不適切な構成は、次のことにつながる可能性があります：

  • 未承認の受信者に通知を送信する。
  • 機密性の高い運用データまたはセキュリティイベントを公開する。
  • ネットワークトポロジまたは脆弱性に関する情報を漏洩する。

緩和策:

  • 通知フィルタリングを使用して、どのターゲットにどの情報を送信するかを制御します。
  • 認証と暗号化を使用してSNMPv3を使用するように通知ターゲットを構成します。
  • snmpTargetAddrTableを定期的に監査して、通知が承認された管理ステーションにのみ送信されるようにします。

通知のなりすまし​

適切なセキュリティがない場合、攻撃者は通知をなりすますことができます：

  • 偽の通知は誤警報を引き起こしたり、実際のセキュリティインシデントを隠蔽したりする可能性があります。
  • 悪意のある行為者は、巧妙に作成された通知を送信することで管理システムを操作できます。

緩和策:

  • 通知レシーバは、SNMPv3セキュリティ機能を使用して通知のソースを認証する必要があります。
  • 信頼性の高い配信を確保し、認証を許可するために、（trapではなく）informリクエストを使用します。
  • 疑わしい通知パターンを識別するために、レート制限と異常検出を実装します。

10.3. プロキシ転送のセキュリティ​

プロキシフォワーダは、追加のセキュリティ上の考慮事項を導入します：

セキュリティレベルのダウングレード​

プロキシは異なるSNMPバージョン間で変換する可能性があり、セキュリティをダウングレードする可能性があります：

  • SNMPv3（authPriv）からSNMPv1（セキュリティなし）へ：認証および暗号化されたトラフィックを平文で公開します。
  • 認証の喪失：ターゲットはリクエストの真のソースを確認できません。

緩和策:

  • 可能な限りセキュリティのダウングレードを避けます。SNMPv3をエンドツーエンドで展開します。
  • ダウングレードが必要な場合は、補償制御（IPsec、物理的セキュリティなど）を使用します。
  • すべてのセキュリティダウングレードを監査目的で記録します。
  • アクセス制御を使用して、ダウングレード可能な操作を制限します。

中間者攻撃​

プロキシは通信パスに位置し、次のことが可能になる可能性があります：

  • 機密情報を傍受して読み取る。
  • リクエストまたは応答を変更する。
  • コマンドジェネレータまたはコマンドレスポンダのいずれかになりすます。

緩和策:

  • プロキシは、安全で制御された環境に展開する必要があります。
  • プロキシの両側でSNMPv3セキュリティを使用します（コマンドジェネレータからプロキシ、プロキシからコマンドレスポンダ）。
  • プロキシ構成に強力なアクセス制御を実装します。
  • プロキシアクティビティを監視および監査します。

コンテキスト変換の脆弱性​

プロキシでの不適切なコンテキスト変換は、次のことにつながる可能性があります：

  • 意図しない管理情報へのアクセス。
  • 異なるコンテキストが異なるアクセスポリシーを持つ場合、アクセス制御のバイパス。

緩和策:

  • snmpProxyTableエントリを慎重に構成して、正しいコンテキストマッピングを確保します。
  • すべてのコンテキストで一貫したアクセス制御ポリシーを適用します。
  • コンテキスト変換ルールを定期的に確認および監査します。

10.4. サービス拒否に関する考慮事項​

この文書で定義されている機能は、サービス拒否を引き起こすために悪用される可能性があります：

リソースの枯渇​

  • 過剰な通知: 多くの通知ターゲットを構成すると、通知オリジネータに過負荷がかかる可能性があります。
  • 複雑なフィルタリングルール: 計算集約型のフィルター操作は、過剰なCPUを消費する可能性があります。
  • プロキシ増幅: 複数のターゲット転送で構成されたプロキシへの単一のリクエストは、多くの送信リクエストを生成する可能性があります。

緩和策:

  • 通知生成とプロキシ転送にレート制限を実装します。
  • 構成されたターゲットの数に合理的な制限を設定します。
  • フィルター処理を最適化し、フィルターの複雑さを制限することを検討します。
  • リソース使用状況を監視し、異常時にアラートを出します。

ネットワークフラッディング​

  • 誤って構成された通知ターゲットは、ネットワークをトラフィックで氾濫させる可能性があります。
  • プロキシループ（プロキシが相互に転送する場合）は、メッセージストームを引き起こす可能性があります。

緩和策:

  • 構成中にターゲットアドレスを検証します。
  • プロキシフォワーダにループ検出メカニズムを実装します。
  • TTLまたはホップカウントメカニズムを使用して、無限転送を防ぎます。

10.5. SNMPバージョンに関する考慮事項​

SNMPv1およびSNMPv2cの制限​

SNMPv1およびSNMPv2cは、認証にコミュニティ文字列を使用します：

  • コミュニティ文字列は平文で送信され、盗聴に対して脆弱です。
  • コミュニティベースの認証は弱く、簡単に侵害されます。
  • 整合性保護なし：メッセージは検出されずに転送中に変更される可能性があります。

推奨事項:

すべてのSNMP通信に対してUSMを使用したSNMPv3を使用することを強く推奨します。SNMPv1およびSNMPv2cは、次の制御された環境でのみ使用する必要があります：

  • ネットワークが物理的に安全である。
  • トラフィックが他の手段（VPN、IPsecなど）によって保護されている。
  • レガシーデバイスをSNMPv3にアップグレードできない。

SNMPv3セキュリティ​

USMを使用したSNMPv3は、次を提供します：

  • 認証: HMAC-MD5またはHMAC-SHAを使用してメッセージのソースを検証します。
  • 暗号化: DESまたはAESを使用してメッセージの機密性を保護します。
  • 適時性: タイムスタンプを使用してリプレイ攻撃から保護します。

ただし、SNMPv3セキュリティは適切な構成に依存します：

  • 強力な認証プロトコルを使用します（HMAC-MD5よりもHMAC-SHAが推奨されます）。
  • 強力な暗号化を使用します（DESよりもAESが推奨されます）。
  • 暗号化キーを適切に管理します（強力なキー、定期的なローテーション）。
  • 適時性ウィンドウの悪用を防ぐために時計を同期します。

10.6. セキュリティ推奨事項の概要​

  1. この文書で定義されているMIBモジュールに関連するすべてのSNMP通信に対してUSMを使用したSNMPv3を使用する。

  2. VACMを構成して、セキュリティに敏感なオブジェクトへのアクセスを承認された管理者のみに制限する。

  3. 機密情報にアクセスまたは送信する際に認証と暗号化（authPriv）を使用する。

  4. 通知ターゲットを慎重に構成し、情報開示を防ぐために通知フィルタリングを使用する。

  5. プロキシフォワーダでのセキュリティダウングレードを回避する；避けられない場合は、補償制御を使用し、すべてのダウングレードを監査する。

  6. 強力なアクセス制御と監視を備えた安全な環境にプロキシを展開する。

  7. サービス拒否攻撃を防ぐためにレート制限を実装する。

  8. ターゲット、通知、フィルター、およびプロキシルールの構成を定期的に監査する。

  9. 重要な通知に対してtrapではなくinformリクエストを使用して、信頼性が高く認証された配信を確保する。

  10. RFC 3410（インターネット標準管理フレームワークの適用可能性声明）で概説されているセキュリティのベストプラクティスに従う。

に最終更新