SNMPv2c の community 名は秘匿ではなくアクセス制御のキーとして扱う

SNMP は、ネットワーク機器やサーバーを監視するための古典的なプロトコルです。現在でもスイッチ、ルーター、UPS、ストレージ、Linux サーバーなどで広く使われています。

一方で、実運用でよく使われる SNMPv2c は、セキュリティ機構としてはかなり割り切ったものです。community 名はよく「パスワード」のように説明されますが、SNMPv2c では平文で流れるため、それを秘匿して守るという発想には限界があります。この記事では、SNMPv2c をどう割り切るべきか、そしてなぜ SNMPv3 が使われにくいのかを整理します。

まず SNMPv2 ではなく SNMPv2c として考える

現場で「SNMPv2」と呼ばれるものの多くは、実際にはコミュニティ名を使う SNMPv2c です。ここを曖昧にすると、セキュリティの議論も曖昧になります。

SNMPv2c は、監視の互換性と簡単さでは優秀です。しかし、community 名を秘匿情報として扱うことで守るプロトコルだと考えると、設計を誤ります。

community 名を秘匿して守る発想には限界がある

SNMPv2c の community 名は、しばしば共有パスワードのように扱われます。しかし、通信は基本的に平文であり、経路上で見えてしまうことを前提に考えるべきです。

つまり、community 名を複雑にすること自体は無意味ではありませんが、それをセキュリティの主軸に置くのは筋が悪いです。community 名は、秘匿して外部から守る鍵というより、読み取り専用、書き込み権限、監視対象のビューなどに紐づくアクセス制御用の識別子として扱うくらいが現実的です。

SNMPv2c はネットワーク制御で守る

SNMPv2c を使う場合、守るべき中心は community 名そのものではなく、SNMP に到達できるネットワーク経路です。監視サーバー以外から UDP/161 に到達できる設計になっているなら、その時点でかなり危うい設計です。

SNMP を大きくさらすネットワーク設計自体に問題を見出せないなら、設計者として重要な前提を見落としていると言ってよいです。SNMPv2c の community 名をいくら工夫しても、SNMP が広く到達可能な状態では根本的な防御にはなりません。

• 監視サーバーからの送信元 IP だけを許可する
• UDP/161 を利用者セグメントや外部ネットワークへ開けない
• 管理セグメント、VPN、閉域ネットワーク内に限定する
• read-only community を基本にする
• write community は原則使わない
• community はアクセス制御の識別子として扱い、秘匿性に過度な期待をしない

SNMPv2c の防御軸

community 名を秘密にする
  ↓  期待しすぎない

SNMP に到達できる経路を制限する
  ↓  こちらが本質

read-only / view / ACL で取得範囲を制限する
  ↓  community 名はその制御のキーとして使う

community 名に意味がある場面

community 名に意味がないわけではありません。意味があるのは、到達可能な相手をネットワークで絞った上で、どの範囲の情報を読ませるか、書き込みを許すか、どのビューを見せるかを分ける場面です。

この意味では、community 名は「外部に漏れなければ安全」という秘密鍵ではなく、閉じたネットワーク内でアクセス範囲を区別するための運用キーです。

SNMPv3 は正しいが扱いづらい

SNMPv3 は、RFC 3411 で定義される SNMP 管理フレームワークの中で、ユーザー、認証、暗号化、アクセス制御を扱えるようにしたものです。特に RFC 3414 の User-based Security Model、USM により、認証と暗号化を組み合わせられます。

問題は、SNMPv3 が正しい方向に進んだ一方で、設定項目が増え、機器ごとの差異が目立ち、監視ツール側のテンプレートや運用手順も複雑になったことです。

• ユーザー、認証方式、暗号方式、パスフレーズを管理する必要がある
• 機器ベンダーごとに設定コマンドや対応暗号が異なる
• 監視ツール側にも SNMPv3 の認証情報を正しく登録する必要がある
• 大量機器では認証情報の配布と更新が運用負荷になる

なぜ SNMPv3 は使われにくいのか

SNMPv3 が使われにくい理由は、単に現場が怠慢だからではありません。監視は「確実に取れること」が最優先される領域です。監視対象が多く、機器ベンダーも多く、障害時にはまず状態を取得できなければ困ります。

そのため、多少セキュリティが弱くても、動作実績があり、テンプレートが揃っていて、切り分けしやすい SNMPv2c が選ばれ続けます。これは理想と現実のズレというより、監視運用における可用性と保守性の重みが大きいという話です。

SNMPv2c を使うならどう割り切るか

SNMPv2c を使う場合は、「community 名を秘密にすればよい」と考えるのではなく、「SNMP は閉じた管理ネットワーク内でだけ到達できる」という前提を作るべきです。

• SNMP は管理セグメントに閉じる
• 監視サーバー以外からの UDP/161 を遮断する
• community は read-only や view の識別子として扱う
• write community は原則使わない
• 機器種別や環境ごとに取得範囲を分ける
• SNMP 到達性を定期的に確認する

SNMPv3 を使うなら authPriv を目標にする

SNMPv3 を採用するなら、単にバージョンを v3 にするだけでは不十分です。noAuthNoPriv のような設定では、v3 であることの意味が薄くなります。

実運用で SNMPv3 を使うなら、可能な限り authPriv、つまり認証あり・暗号化ありを目標にします。その上で、監視ツール、機器、認証情報管理、更新手順をセットで設計する必要があります。

監視は SNMP だけではなくなっている

近年は、Prometheus、OpenTelemetry、NETCONF、REST API、gNMI / OpenConfig など、監視やテレメトリの選択肢が増えています。SNMP は今でも重要ですが、すべての監視を SNMP で行う時代ではなくなっています。

SNMP はネットワーク機器や既存設備の状態取得に強く、Prometheus や OpenTelemetry はアプリケーションやクラウドネイティブなメトリクスに強い。どちらが正しいかではなく、監視対象に応じて使い分けるべきです。

まとめ

SNMPv2c の community 名は、平文で流れる以上、秘匿性に強く期待するべきではありません。community 名は、read-only や view などに紐づくアクセス制御用のキーとして扱うくらいが現実的です。

SNMPv2c を守る本質は、community 名を複雑にすることではなく、SNMP に到達できるネットワーク経路を厳しく制御することです。SNMP を広くさらしておいて community 名で守ろうとする設計は、そもそもの前提が危ういです。

SNMPv3 は設計としては正しい方向ですが、運用の複雑さによって現場に届きにくい面があります。だからこそ、SNMPv2c を使い続けるなら「ネットワークで囲い込む」、SNMPv3 を使うなら「authPriv まで設計する」という割り切りが必要です。

参考

• RFC 3411 – An Architecture for Describing SNMP Management Frameworks
• RFC 3414 – User-based Security Model for SNMPv3
• RFC 3416 – Version 2 of the Protocol Operations for SNMP

Related posts:

SNMP Trap は監視設計の主役ではない – 状態監視とイベント通知を分けて考える