いまだ現役の古典プロトコル
SNMP（Simple Network Management Protocol）は、ネットワーク監視の世界で 30 年以上にわたり利用されてきました。
2025 年の現在でも、多くの環境では依然として SNMPv2 が稼働しており、SNMPv3 はほとんど採用されていません。
標準化の観点から見れば v3 が“正統”ですが、実際の運用現場では「確実に動くこと」が優先され、セキュリティ強化版である v3 は“使われない理想”となっています。
SNMPv2 の「セキュリティ」は幻想に近い
SNMPv2 のセキュリティ機構は、「コミュニティ名」という名ばかりのパスワードに依存しています。
理論上は秘匿すべきものですが、実際には public や private、あるいはわかりやすいサービス名を設定している例が多く見られます。
これは、鍵を掛けたまま鍵をドアに刺しておくようなものです。
もし本気でセキュリティを考えるなら、コミュニティ名は意味のないランダム文字列にすべきです。
しかし現実には「覚えやすい」「運用しやすい」という理由で単純な名前が選ばれ、結果として SNMPv2 のセキュリティ機構は形骸化しています。
「セキュリティに配慮している」と口にする人の多くが、そこまでの前提を考えていないのが実情です。
守るのは通信経路と権限
多くの運用現場では、SNMPv2 のセキュリティそのものを信用していません。代わりに、通信経路そのものを安全に保つことに重点を置いています。
具体的には次のような手法が一般的です。
- 送信元 IP の制御（ACL や Firewall）：監視サーバーからのみアクセスを許可する
- VPN や閉域セグメント内での通信：SNMP は“外に出ない”前提で設計する
- 読み取り専用（read-only community）で運用：書き込み操作を禁止する
つまり、「SNMP 自体を強化する」よりも、「SNMP を囲い込む」ことが安全対策の基本とされています。
この方法は古典的ですが、現在でも最も現実的なアプローチです。
SNMPv3 は正しい理想、しかし現場に届かない
SNMPv3 は RFC 3411 – 3418 で定義され、認証・暗号化・アクセス制御の三要素で“安全な監視”を実現することを目的としています。
理想的な仕様であることは間違いありませんが、実際にはほとんど普及していません。
その理由は明快です。
- 設定が煩雑である
- 既存ツール（Zabbix、LibreNMS など）との互換性に課題がある
- 現場では「すぐに動かせること」が最優先される
結果として、SNMPv3 は「理想として正しいが、現場では扱いづらい仕組み」となりました。
Cisco や Juniper などの主要ベンダーも v3 に対応していますが、実際の設定例やドキュメントでは v2c が中心に使われています。
「対応しているが使われない」という状態が長く続いているのです。
監視の概念そのものが変わりつつある
さらに、Prometheus や OpenTelemetry のような新世代の監視基盤が登場し、監視のあり方そのものが変わりつつあります。
今や、監視データは API 経由で取得され、構造化され、暗号化された通信で扱われます。
IETF も gNMI や NetConf などの Telemetry 系プロトコルを推奨しており、SNMP は徐々に“レガシー・プロトコル”として扱われつつあります。
SNMPv2.1 くらいで良かったのではないか
SNMPv3 の方向性は決して間違ってはいません。
しかし、現実に必要だったのは「認証」「暗号化」「簡易アクセス制御」の3点をシンプルに SNMPv2 に追加する程度だったのではないでしょうか。
v3 は設計思想を詰め込みすぎた結果、扱いづらい仕組みになってしまいました。
もし「SNMPv2.1」という中間的なバージョンが存在していれば、v2 の実用性と v3 の安全性を両立できたかもしれません。
正しさより、続けられる仕組みへ
セキュリティの歴史は、常に「正しい設計」よりも「使われ続ける設計」に支えられてきました。
SNMPv2 の脆弱さを笑うのは簡単ですが、それを 30 年以上使い続けてきた運用現場の知恵には重みがあります。そして、SNMPv3 の理想が広まらなかったことも、技術史の自然な淘汰の一形態です。
監視とは、結局のところ人とシステムの“信頼関係”を築き直す営みです。
SNMPv2 の形骸化も、SNMPv3 の不遇も、その一章にすぎません。
これからの時代において、監視の本質はプロトコルではなく、「どのようにシステムの状態を正直に伝えるか」という問いに移りつつあるのです。
