SNMP セキュリティについて
SNMP は、ネットワーク デバイス間での管理情報の交換を容易にするアプリケーション層プロトコルです。すべての Cisco MDS 9000 ファミリ スイッチで、SNMPv1、SNMPv2c、および SNMPv3 の 3 つの SNMP バージョンが使用できます(SNMPセキュリティ を参照)。
SNMP バージョン 1 およびバージョン 2c
SNMP バージョン 1(SNMPv1)および SNMP バージョン 2c(SNMPv2c)は、コミュニティ ストリングを使用してユーザ認証を行います。コミュニティ ストリングは、SNMP の初期のバージョンで使用されていた弱いアクセス コントロール方式です。SNMPv3 は、強力な認証を使用することによってアクセス コントロールを大幅に改善しています。したがって、SNMPv3 がサポートされている場合は、SNMPv1 および SNMPv2c に優先して使用してください。
SNMP バージョン 3
Note |
Cisco MDS NX-OS リリース 8.5(1) 以降、AES-128 は強力な暗号化アルゴリズムであるため、推奨される暗号化アルゴリズムです。ただし、DES 暗号化もサポートされています。 DES プライバシー プロトコルを持つユーザが SNMP データベースに存在する場合、install all コマンドによる In-Service System Downgrade(ISSD)が中断されます。ユーザはデフォルトの AES-128 を使用して再構成または削除する必要があります。この動作は、Cisco MDS NX-OS リリース 8.5(1) で見られます。ISSD の場合の DES ユーザ サポートは、将来のリリースで追加される予定です。ただし、コールド リブートの場合、DES プライバシー プロトコルを持つ SNMP ユーザは削除されます。 |
SNMP バージョン 3(SNMPv3)は、ネットワーク管理のための相互運用可能な標準ベースのプロトコルです。SNMPv3 は、ネットワーク経由のフレームの認証と暗号化を組み合わせることによって、デバイスへのセキュア アクセスを実現します。SNMPv3 で提供されるセキュリティ機能は、次のとおりです。
-
メッセージの完全性:パケットが伝送中に改ざんされていないことを保証します。
-
認証:メッセージのソースが有効かどうかを判別します。
-
暗号化:許可されていないソースにより判読されないように、パケットの内容のスクランブルを行います。
SNMPv3 では、セキュリティ モデルとセキュリティ レベルの両方が提供されています。セキュリティ モデルは、ユーザおよびユーザが属するロールを設定する認証方式です。セキュリティ レベルとは、セキュリティ モデル内で許可されるセキュリティのレベルです。セキュリティ モデルとセキュリティ レベルの組み合わせにより、SNMP パケット処理中に採用されるセキュリティ メカニズムが決まります。
SNMPv3 CLI のユーザ管理および AAA の統合
Cisco NX-OS ソフトウェアは RFC 3414 と RFC 3415 を実装しています。これには、ユーザベース セキュリティ モデル(USM)とロール ベースのアクセス コントロールが含まれています。SNMP と CLI のロール管理は共通化されており、同じ証明書とアクセス権限を共有しますが、以前のリリースではローカル ユーザ データベースは同期化されませんでした。
SNMPv3 のユーザ管理を AAA サーバ レベルで一元化できます。ユーザ管理を一元化すると、Cisco MDS スイッチ上で稼働する SNMP エージェントが AAA サーバのユーザ認証サービスを利用できます。ユーザ認証が検証されると、SNMP PDU の処理が進行します。また、AAA サーバにはユーザ グループ名も格納されます。SNMP はグループ名を使用して、スイッチでローカルに使用できるアクセス ポリシーまたはロール ポリシーを適用します。
CLI および SNMP ユーザの同期
ユーザ グループ、ロール、またはパスワードの設定が変更されると、SNMP と AAA の両方のデータベースが同期化されます。
SNMP または CLI ユーザを作成するには、username コマンドまたは snmp-server user コマンドを使用します。
- snmp-server user コマンドで指定された パスフレーズは、CLI ユーザのパスワードと同期します。
- username コマンドで指定したパスワードは、SNMP ユーザ用の auth および priv パスフレーズとして同期されます。
ユーザの同期化は、次のように処理されます。
- いずれかのコマンドを使用してユーザを削除すると、SNMP と CLI の両方の該当ユーザが削除されます。
- ユーザとロールの対応関係の変更は、SNMP と CLI で同期化されます。
Note |
パスフレーズ/パスワードをローカライズド キー/暗号化形式で指定すると、パスワードは同期化されません。 |
- 既存の SNMP ユーザは、特に変更しなくても、引き続き auth および priv のパスフレーズを維持できます。
- 管理ステーションが usmUserTable 内に SNMP ユーザを作成する場合、対応する CLI ユーザはパスワードなし(ログインは無効)で作成され、network-operator のロールが付与されます。
SNMPv3 サーバーの AAA 排他動作
AAA の排他的な動作機能を使用して、ロケーションに基づいてユーザを認証できます。
ユーザがローカル ユーザまたはリモート AAA ユーザでない場合、一意の SNMPv3 ユーザは認証されません。ユーザがローカルおよびリモート データベースの両方に存在する場合、ユーザは AAA の排他的な動作が有効かそうでないかに基づいて許可または拒否されます。
ユーザの場所 |
AAA サーバー |
AAA の排他的な動作 |
ユーザー認証 |
ローカル ユーザ データベース |
無効 |
有効 |
ユーザが認証されました。 |
ローカル ユーザ データベース |
有効 |
有効 |
ユーザは認証されません。 |
ローカル ユーザ データベース |
有効 |
無効 |
ユーザが認証されました。 |
ローカル ユーザ データベース |
無効 |
無効 |
ユーザが認証されました。 |
リモートおよびローカル ユーザーデータベース(同一ユーザ名) |
有効 |
有効 |
リモート ユーザは認証されますが、ローカル ユーザは認証されません。 |
リモートおよびローカル ユーザーデータベース(同一ユーザ名) |
無効 |
有効 |
ローカル ユーザは認証されますが、リモート ユーザは認証されません。 |
リモートおよびローカル ユーザーデータベース(同一ユーザ名) |
無効 |
無効 |
ローカル ユーザは認証されますが、リモート ユーザは認証されません。 |
リモートおよびローカル ユーザーデータベース(同一ユーザ名) |
有効 |
無効 |
ローカル ユーザは認証されますが、リモート ユーザは認証されません。 |
(注) |
AAA サーバが到達不能な場合、ユーザがローカル ユーザーデータベースに対して検証されるようにフォールバック オプションをサーバーで構成することができます。ユーザがローカル データベースまたはリモート ユーザーデータベースで使用できない場合、SNMPv3 サーバーはエラーを返します。SNMPv3 サーバはー、リモート ユーザーデータベースにユーザが存在しない場合、AAA サーバの可用性をチェックせずに「Unknown user」メッセージを返します。 |
スイッチ アクセスの制限
IP アクセス コントロール リスト(IP-ACL)を使用して、Cisco MDS 9000 ファミリ スイッチへのアクセスを制限できます。
グループベースの SNMP アクセス
Note |
group が業界全体で使用されている標準規格 SNMP 用語なので、この SNMP のセクションでは、ロールのことをグループと言います。 |
SNMP アクセス権は、グループ別に編成されます。SNMP 内の各グループは、CLI を使用する場合のロールに似ています。各グループは 3 つのアクセス権により定義されます。つまり、読み取りアクセス、書き込みアクセス、および通知アクセスです。それぞれのアクセスを、各グループでイネーブルまたはディセーブルに設定できます。
ユーザ名が作成され、ユーザのロールが管理者によって設定され、ユーザがそのロールに追加されていれば、そのユーザはエージェントとの通信を開始できます。
ユーザの作成および変更
SNMP、DCNM-SAN、または CLI を使用して、ユーザの作成、または既存のユーザの変更を実行できます。
- SNMP:スイッチ上の usmUserTable に存在するユーザのクローンとして、新規のユーザを作成します。ユーザを作成した後、クローンの秘密キーを変更してから、そのユーザをアクティブにします。RFC 2574 を参照してください。
- DCNM-SAN。
- CLI:snmp-server user コマンドを使用して、ユーザの作成または既存のユーザの変更を実行します。
Cisco MDS 9000 ファミリ スイッチ上で使用できるロールは、network-operator および network-admin です。GUI(DCNM-SAN および Device Manager)を使用する場合は、default-role もあります。また、Common Roles データベースに設定されている任意のロールも使用できます。
Tip |
CLI セキュリティ データベースおよび SNMP ユーザ データベースに対する更新はすべて同期化されます。SNMP パスワードを使用して、DCNM-SAN または Device Manager のいずれかにログインできます。ただし、CLI パスワードを使用して DCNM-SAN または Device Manager にログインした場合、その後のログインには必ず CLI パスワードを使用する必要があります。Cisco MDS SAN-OS Release 2.0(1b) にアップグレードする前から SNMP データベースと CLI データベースの両方に存在しているユーザの場合、アップグレードすると、そのユーザに割り当てられるロールは両方のロールを結合したものになります。 |
AES 暗号ベースの機密保全
Advanced Encryption Standard(AES)は対称暗号アルゴリズムです。Cisco NX-OS ソフトウェアは、SNMP メッセージ暗号化用のプライバシー プロトコルの 1 つとして AES を使用し、RFC 3826 に準拠しています。
priv オプションで、SNMP セキュリティ暗号化方式として、DES または 128 ビット AES 暗号化を選択できます。Cisco MDS NX-OS リリース 8.5(1) 以前では、aes-128 トークンと連動する priv オプションは、128 ビットの AES キーを生成するためのプライバシ パスワードであることを示します。AES-128 は、Cisco MDS NX-OS リリース 8.5(1) からデフォルトのプライバシー オプションになりました。これは、Cisco MDS NX-OS リリース 8.5(1) から構成または変更されたすべてのユーザが aes-128 をプライバシー オプションとして使用することを示しています。AES のプライバシー パスワードは最小で 8 文字です。パスフレーズをクリア テキストで指定する場合、最大 64 文字を指定できます。ローカライズド キーを使用する場合は、最大 130 文字を指定できます。
Note |
外部の AAA サーバを使用して SNMPv3 を使う場合、外部 AAA サーバのユーザ設定でプライバシー プロトコルに AES を指定して、SNMP PDU を暗号化する必要があります。 |
トラップ、通知、およびインフォーム
トラップは、SNMP エージェントから SNMPv1 の SNMP マネージャに送信される未確認のメッセージです。SNMPv2 および SNMPv3 では通知と呼ばれます。インフォームは、SNMP エージェントから SNMP マネージャに送信される確認応答メッセージです。エージェントが応答を受信しない場合は、インフォーム要求を再度送信します。
ただし、インフォームは、エージェントやネットワークでより多くのリソースを消費します。送信と同時にエージェントによって廃棄されるトラップまたは通知とは異なり、インフォーム要求は応答を受信するまで、または要求がタイムアウトになるまで、メモリ内に保持する必要があります。トラップと通知は 1 回だけ送信できますが、インフォームは複数回送信できます。インフォームの再送信によりトラフィックが増加し、ネットワークのオーバーヘッドが高くなる原因になります。同じトラップ、通知、およびインフォームを複数のホスト受信者に送信できます。
Note |
SNMPv3 インフォームを機能させるには、snmp-server user name engineID コマンドを使用して、SNMP ユーザでネットワーク管理サーバー(NMS)engineID を構成する必要があります。 NMS から Linux engineID を取得するには、snmptarpd を起動し、出力で lcd_set_enginetime 文字列を探します。
|
EngineID
SNMP engineID は、送信元アドレスに関係なくエンティティを識別するために使用されます。エンティティは、SNMP エンジンと SNMP アプリケーションで構成されます。プロトコルデータユニット(PDU)がプロキシまたはネットワーク アドレス変換(NAT)を通過する必要がある場合、または送信元エンティティ自体に動的に割り当てられたトランスポートアドレスまたは複数の送信元アドレスがある場合、engineID は重要です。
SNMPv3 では、安全な PDU のエンコードとデコードにも engineID が使用されます。これは、SNMPv3 ユーザーベース セキュリティ モデル(USM)の要件です。
engineID には、ローカルとリモートの 2 種類があります。Cisco MDS 9000 シリーズ スイッチでは、リモート engineID のみを構成できます。ローカル engineID は、MAC アドレスに基づいてスイッチによって自動的に生成され、変更されません。
スイッチの LinkUp/LinkDown 通知
スイッチに対して、イネーブルにする LinkUp/LinkDown 通知を設定できます。次のタイプの LinkUp/LinkDown 通知をイネーブルにできます。
- Cisco:インターフェイスに対して ifLinkUpDownTrapEnable(IF-MIB で定義)がイネーブルになっている場合、そのインターフェイスについて CISCO-IF-EXTENSION-MIB.my で定義された通知(cieLinkUp、cieLinkDown)のみが送信されます。
- IETF:インターフェイスに対して ifLinkUpDownTrapEnable(IF-MIB で定義)がイネーブルになっている場合、そのインターフェイスについて IF-MIB で定義された通知(LinkUp、LinkDown)のみが送信されます。通知定義で定義された変数バインドのみが、それらの通知とともに送信されます。
- IEFT extended:インターフェイスに対して ifLinkUpDownTrapEnable(IF-MIB で定義)がイネーブルになっている場合、そのインターフェイスについて IF-MIB で定義された通知(LinkUp、LinkDown)のみが送信されます。通知定義で定義された変数バインドに加え、シスコの実装に固有の IF-MIB で定義された変数バインドも送信されます。これがデフォルト設定です。
- IEFT Cisco:インターフェイスに対して ifLinkUpDownTrapEnable(IF-MIB で定義)がイネーブルになっている場合、そのインターフェイスについて IF-MIB で定義された通知(LinkUp、LinkDown)および CISCO-IF-EXTENSION-MIB.my で定義された通知(cieLinkUp、cieLinkDown)のみが送信されます。通知定義で定義された変数バインドのみが、linkUp 通知や linkDown 通知とともに送信されます。
- IEFT extended Cisco:インターフェイスに対して ifLinkUpDownTrapEnable(IF-MIB で定義)がイネーブルになっている場合、そのインターフェイスについて IF-MIB で定義された通知(LinkUp、LinkDown)および CISCO-IF-EXTENSION-MIB.my で定義された通知(cieLinkUp、cieLinkDown)のみが送信されます。linkUp と linkDown の通知定義で定義された変数バインドに加え、シスコの実装に固有の IF-MIB で定義された変数バインドも LinkUp 通知や LinkDown 通知とともに送信されます。
Note |
シスコの実装に固有の IF-MIB で定義される変数バインドの詳細については、『Cisco MDS 9000 Family MIB Quick Reference』を参照してください。 |
LinkUp および LinkDown トラップ設定の範囲
インターフェイスに対する LinkUp および LinkDown トラップ設定は、次の範囲に基づいてトラップを生成します。
スイッチレベルのトラップ設定 |
インターフェイスレベルのトラップ設定 |
インターフェイス リンクについて生成されるトラップか? |
---|---|---|
有効(デフォルト) |
有効(デフォルト) |
はい |
有効 |
無効 |
いいえ |
無効 |
有効 |
いいえ |
無効 |
無効 |
不可 |