ビューに基づくアクセス制御モデル (VACM) を使って、特定の管理対象オブジェクトへのアクセスが承認されているかどうかを調べることができます。アクセス制御は、次のタイミングで行われます。
マネージャーからの取得要求メッセージを処理するとき
マネージャーからの変更要求メッセージを処理するとき
マネージャーに通知メッセージを送信する必要があるとき
VACM は、「コミュニティー文字列」で説明されているコミュニティー文字列の概念に基づいています。VACM では、アクセス制御をシステム管理エージェントで簡単に管理できます。
アクセス制御は、主要構成ファイル snmpd.conf 内のトークンによって定義されます。SMA デーモン snmpd が認識する VACM アクセスセキュリティー用のトークンを、以下に示します。これらのトークンは主要構成ファイル snmpd.conf 内で使用できます。
最初の 3 つのトークンについては、「VACM テーブルについて」を参照してください。com2sec トークンには、NAME SOURCE オプションと COMMUNITY オプションを指定できます。このトークンを使って、SNMPv1 や SNMPv2 のユーザーおよびコミュニティーに、SNMPv3 のセキュリティー特権を付与することができます。com2sec トークンは、ソースとコミュニティーのペアからセキュリティー名へのマッピングを示します。
snmpd.conf ファイルは、より高速で有用なラッパーを提供しています。これらのラッパーは、SMA snmpd エージェントで認識可能です。これらのラッパーは、ユーザーやコミュニティー向けの読み取り書き込み (rw) および読み取り専用 (ro) 構文を使用して、次のように定義されています。
rwuser
rouser
rwcommunity
rocommunity
rwuser トークンエントリは、ユーザーが指定しなければならない最小限のアクセス権を指定します。
ユーザーはプライバシパスワードを指定しなければならない
プライバシパスワードを使って作成されたユーザーはプライバシパスワードを指定できる。それ以外の場合、ユーザーは認証パスワードを指定しなければならない
ユーザーは、パスワードを指定しないか、または認証パスワードを指定できる。また、プライバシパスワードを使って作成されたユーザーはプライバシパスワードを指定できる
VACM 情報は、SNMPv3 パケット文字列内の複数のパラメータに含まれています。これらのパラメータは isAccessAllowed 機構に渡されます。isAccessAllowed 機構は、アクセスを付与すべきかどうかをチェックする VACM 内の唯一のエントリポイントです。
メッセージの処理方法を指定する 8 ビット。詳細については、「USM セキュリティー情報の格納場所」を参照
メッセージの生成時に使用されたセキュリティーモデルを指定して、受信側エンティティーが適切なセキュリティー処理モデルを利用できるようにする。SNMPv3 では、単一のセキュリティーモデルの使用か複数のセキュリティーモデルの使用かを選択できる
セキュリティーモデルに関するデータを含む 8 ビット文字列。セキュリティーモデル (複数可) は msgSecurityModel に指定される
PDU を含む。PDU 処理に使用する管理情報の管理上一意のセレクタを示す。つまり、scopedPDU にはコンテキストと管理対象オブジェクトの OID が含まれる。scopedPDU には次のフィールドがある
SNMPv3 パケット文字列のその他のフィールドについては、「SNMP のバージョン」を参照してください。
メッセージにアクセスを付与するかどうかを決定する際、VACM は次の 4 つのテーブルを使用します。
これらの VACM テーブルは、それぞれアクセス機構の特定の部分を処理します。各テーブルは、VACM MIB を使ってリモートで構成できます。VACM MIB は RFC 3415 (http://www.ietf.org/rfc/rfc3415.txt) で定義されています。
VACM は、SMA の USM によって認証された要求が、この要求に含まれる MIB オブジェクトへのアクセスを承認されるかどうかを判断します。snmpvacm ユーティリティーは、SNMP エージェントの VACM テーブルの基本管理用 SNMP アプリケーションです。snmpvacm ユーティリティーを使用するには、snmpvacm MIB テーブルの書き込みアクセス権が必要です。詳細については、snmpvacm(1M) のマニュアルページを参照してください。
この節では、各 VACM テーブルについて説明します。たとえば、テーブルの索引の付け方や、各行の内容などについて説明します。
vacmContextTable テーブルには、ローカルで使用可能なコンテキストが格納されています。コンテキストは、管理情報のセレクタです。単一の管理対象オブジェクトを複数のコンテキストで使用できます。たとえば、プリンタの状態を監視する単一のモジュールの場合を考えてみましょう。複数のプリンタが設置されているネットワークでは、このモジュールの複数のインスタンスにそれぞれ独自のプリンタ名を格納して実装できます。この場合、プリンタ名がコンテキストになります。
単一の SNMP エンティティーから複数のコンテキストにアクセスできます。
vacmContextTable テーブルは、 contextName で索引付けられています。各行には、読み取り可能な一意の文字列 vacmcontextName の形式でコンテキスト名が付けられます。
システム管理エージェントは、vacmContextTable 内で、scopedPDU 内の contextName を検索します。scopedPDUについては、 「SNMP のバージョン」を参照してください。システム管理エージェントが特定のメッセージの contextName を vacmContextTable 内で検出できない場合、アクセスは拒否されます。この場合、戻り値は noSuchContext になります。
contextName が見つかった場合、 図 4–2 のように、アクセスチェックが続行されます。例 4–1 に、vacmContextTable 内の一般的なエントリの例を示します。
モジュールにより作成される一般的な vacmContextTable エントリの例を、以下に示します。
SNMP-VIEW-BASED-ACM-MIB::vacmContextName."fileX" = STRING: fileX SNMP-VIEW-BASED-ACM-MIB::vacmContextName."fileY" = STRING: fileY |
この例の contextNames は fileX と fileY です。
コンテキストの詳細については、『Solaris System Management Agent Developer’s Guide 』を参照してください。システム管理エージェントには、コンテキストの概念を理解するのに役立つデモモジュールが付属しています。このデモモジュールでは、単一のモジュールの複数のインスタンスを実装する場合の、コンテキストの重要性を示しています。詳細については、『Solaris System Management Agent Developer’s Guide』の「Implementing Multiple Instances of a Module」を参照してください。
vacmSecurityToGroupTable テーブルには、グループ情報が格納されています。ユーザーグループにはグループ名が付けられます。このグループ名は、アクセス権の管理に使用されます。グループには、SecurityModel と SecurityName の値のペアが含まれます。その結果、ペアは最大 1 つのグループにしかマッピングできません。vacmSecurityToGroupTable テーブルは、以下の項目で索引付けられています。
securityModel
securityName
vacmSecurityToGroupTable テーブルの各行には、次の情報が含まれます。
SNMPv3 セキュリティーモデル。この例では USM。USM の詳細については、「USM による認証とメッセージプライバシ」を参照。com2sec トークンを利用すると、SNMPv1 および v2c のセキュリティーモデルを使用できるようになる。com2sec トークンの詳細については、snmpd.conf(4) のマニュアルページを参照
USM では、vacmSecurityName と userName は一致する。セキュリティーモデルとは無関係のフォーマットでユーザーを表現する。com2sec トークンを利用すると、SNMPv1 および v2c のセキュリティー名を使用できるようになる。com2sec トークンの詳細については、snmpd.conf(4) のマニュアルページを参照
読み取り可能な文字列。このエントリに関連付けられているグループを示す
メッセージの認証と復号化に成功すると、SecurityName が msgSecurityModel 指示子によって取得されます。システム管理エージェントは、vacmSecurityToGroupTable テーブル内で、この msgSecurityModel 指示子および関連する SecurityName を検索します。vacmSecurityToGroupTable 内で msgSecurityModel 指示子および関連する SecurityName が見つからない場合、アクセスは拒否されます。この場合、戻り値は noSuchGroupName になります。
エントリが見つかった場合、対応する groupName が返されます。図 4–2 のように、アクセスチェックが続行されます。
例 4–2 に、vacmsecurityToGroupTable 内の一般的なエントリを示します。
以前に作成したユーザー user2 および user5 のグループを作成します。この例では、ユーザーは、grpnam1 という新しく作成されたグループに配置されます。次のいずれかの方法を選択します。
主要構成ファイル /etc/sma/snmp/snmpd.conf に次の行を追加します。
group grpnam1 usm user2 group grpnam1 usm user5 |
主要構成ファイル /etc/sma/snmp/snmpd.conf に追加してグループを作成した場合、 vacmSecurityToGroupTable テーブル内に次のエントリが作成されます。
SNMP-VIEW-BASED-ACM-MIB::vacmGroupName.3."user2" = STRING: grpnam1 SNMP-VIEW-BASED-ACM-MIB::vacmGroupName.3."user5" = STRING: grpnam1 SNMP-VIEW-BASED-ACM-MIB::vacmSecurityToGroupStorageType.3."user2" = INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmSecurityToGroupStorageType.3."user5" = INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmSecurityToGroupStatus.3."user2" = INTEGER: active(1) SNMP-VIEW-BASED-ACM-MIB::vacmSecurityToGroupStatus.3."user5" = INTEGER: active(1) |
リブートしてもエントリは削除されません。この VACM テーブルのエントリを削除するには、snmpvacm deleteGroup コマンドを使用します。この方法は、ストレージの型が nonVolatile の場合に使用できます。これ以外のストレージの型を持つ VACM テーブルエントリの場合は、主要構成ファイル /etc/sma/snmp/snmpd.conf からテーブルエントリを手動で削除する必要があります。主要構成ファイル /etc/sma/snmp/snmpd.conf を編集することで作成されたグループの場合、vacmSecurityToGroupTable テーブルのエントリを削除するには、主要構成ファイル /etc/sma/snmp/snmpd.conf を編集する必要があります。
snmpvacm コマンドを使用します。user2 の場合、次のように snmpvacm コマンドを使ってグループを作成できます。
# snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv localhost createSec2Group 3 user2 grpnam1 |
user5 の場合、次のように snmpvacm コマンドを使ってグループを作成できます。
# snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv localhost createSec2Group 3 user5 grpnam1 |
ユーザー myuser のアクセスレベルは rwuser です。したがって、この例では、コンテキストに適していれば、グループエントリは myuser として作成されます。ユーザー user2 と user5 は、VACM テーブルを更新する権限を持ちません。
vacmViewTreeFamilyTable テーブルには、ビューサブツリーファミリの全コレクションが格納されます。これらのコレクションを「MIB ビュー」と呼びます。MIB ビューは、OID サブツリー値です。ファミリ名と、ファミリマスクであるビット文字列値から成ります。ファミリマスクは、MIB ビュー内に存在するファミリ名のサブ識別子を特定します。マスクは、次のいずれかで区切られた 16 オクテットのリストです。「.」または「:」。デフォルトは「ff」です。
MIB ビュー内の各ビューサブツリーファミリには、型があります。この型によって、そのビューサブツリーファミリが MIB ビューに含まれるかどうかが決まります。管理対象オブジェクトインスタンスは、次の条件が両方とも真である場合に限り、MIB ビューに含まれます。
管理対象オブジェクトの OID に、OID サブツリーと同数以上のサブ識別子が含まれている
対応するマスクのビットが 0 以外の場合、管理対象オブジェクトの OID サブ識別子が OID サブツリー内の対応するサブ識別子と一致する
マスクの構成値が短すぎてこれらの条件をチェックできない場合、暗黙のうちにこの値に 1 の連続が付加されます。したがって、マスクが 0 ビットのビューファミリサブツリーは、すべての値が 1 のマスクと同等であり、すなわち 1 つの MIB サブツリーと同等です。
vacmViewTreeFamilyTable テーブルは、以下の項目で索引付けられています。
vacmAccessTable テーブルで選択されたアクセス権によって指定される。アクセスチェックに使用される
PDU の OID が MIB ビューと比較される
vacmViewTreeFamilyTable テーブルの各行の値は次のとおりです。
MIB ビューの名前
OID サブツリー。OID サブツリーはマスクとともに MIB ビューサブツリーを構成する
ビット文字列マスク。ビット文字列マスクは OID サブツリーとともに MIB ビューサブツリーを構成する
この型によって、そのビューサブツリーファミリが MIB ビューに含まれるかどうかが決まる
MIB ビューに検索対象の OID が含まれていない場合、アクセスは拒否されます。この場合、戻り値は notInView になります。MIB ビューに正しい OID が含まれていれば、アクセスは許可されます。この場合、戻り値は accessAllowed になります。
この VACM アルゴリズム全体のフローチャートは、図 4–2 のようになります。以下では、この図に含まれる RFC 推奨の用語について解説します。
アクセスの要求元を示す
アクセスが許可される場所を特定する
アクセスを許可する方法を特定する
読み取り、書き込み、通知のいずれか。グループまたはユーザーが特定のアクセスレベルを要求する理由を特定する
チェック対象の管理データの型を示す
例 4–3 に、vacmViewTreeFamilyTable の一般的なエントリを示します。
ビューは次の 2 通りの方法で作成できます。
主要構成ファイル /etc/sma/snmp/snmpd.conf にビューを追加することで、ビューを作成できます。
view all included .1 FF view none excluded .1 FF view vwnam1 included .1.3.6.1 FF |
この例では、マスクは「FF」になります。
主要構成ファイル /etc/sma/snmp/snmpd.conf にグループを追加することでビューを作成した場合、 vacmViewTreeFamilyTable テーブル内に次のエントリが作成されます。
SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyMask."all".1.1 = STRING: "ÿ" SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyMask."none".1.1 = STRING: "ÿ" SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyMask."vwnam1".4.1.3.6.1 = STRING: "ÿ" SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyType."all".1.1 = INTEGER: included(1) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyType."none".1.1 = INTEGER: excluded(2) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyType."vwnam1".4.1.3.6.1 = INTEGER: included(1) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyStorageType."all".1.1 = INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyStorageType."none".1.1 = INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyStorageType."vwnam1".4.1.3.6.1 = INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyStatus."all".1.1 = INTEGER: active(1) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyStatus."none".1.1 = INTEGER: active(1) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyStatus."vwnam1".4.1.3.6.1 = INTEGER: active(1) |
# snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv -Ce localhost createView all .1 FF |
# snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv localhost createView none .1 FF |
# snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv localhost createView vwnam1 .1.3.6.1 FF |
ユーザー myuser のアクセスレベルは rwuser です。したがって、この例では、コンテキストに適していれば、myuser 用にビューエントリが作成されます。
snmpvacm コマンドを使って作成されたビューの場合、ストレージの型は nonVolatile になります。
vacmAccessTable テーブルには、各グループのアクセス権が格納されます。各グループに複数のアクセス権を付与できます。最も安全なアクセス権が選択されます。vacmAccessTable テーブルは、以下の項目で索引付けられています。
vacmSecurityToGroupTable テーブル内の検索から返される
vacmContextTable テーブル内で一致する有効な contextName
メッセージの msgSecurityModel パラメータ内に指定する
メッセージの msgFlags パラメータ内に指定する
vacmAccessTable テーブル内の各行には、次の値が含まれます。
グループ名。このグループには 1 つ以上のアクセス権がある
contextName は vacmAccessContextPrefix の値と一致する必要がある。vacmAccessContextMatch を参照
アクセス権の取得で使用する必要のあるセキュリティーモデルを示す
vacmAccessContextMatch が exact に設定されている場合、contextName は vacmAccessContextPrefix オブジェクトの値と正確に一致している必要がある
vacmAccessContextMatch が prefix に設定されている場合、contextName は vacmAccessContextPrefix オブジェクトの値の最初の数文字と一致している可能性がある。この contextName は、vacmContextTable テーブル内ですでに一致している名前である
このアクセス権の使用に必要な最低限のセキュリティーレベルを示す。セキュリティーレベルについては、「VACM セキュリティー情報の格納場所」を参照
読み取りアクセスが承認された MIB viewName。vacmAccessReadViewName が空の場合、読み取りアクセス用のアクティブなビューは存在しない
書き込みアクセスが承認された MIB viewName。vacmAccessWriteViewName が空の場合、書き込みアクセス用のアクティブなビューは存在しない
通知アクセスが承認された MIB viewName。vacmAccessWriteViewName が空の場合、通知アクセス用のアクティブなビューは存在しない
アクセス権が見つからない場合、アクセスは拒否されます。この場合、戻り値は noAccessEntry になります。
アクセス権が選択されると、そのアクセス権により指定された viewName が選択されます。この viewName は PDU によって決定されます。PDU 内の SNMP 操作が GETNEXT または GET である場合、文字列 vacmAccessReadViewName が使用されます。PDU 内の SNMP 操作が TRAP である場合、文字列 vacmAccessNotifyViewName が使用されます。viewName が構成されていない場合、アクセスは拒否されます。この場合、戻り値は noSuchView になります。
正しく構成された viewName でアクセス権が選択されると、 図 4–2 のように、引き続きアクセスチェックが続行されます。例 4–4 に、一般的なアクセステーブルエントリを示します。
例 4–5 では、この例と前の例のユーザー設定が存在し、VACM テーブル内に登録されているかどうかをチェックする方法を示します。
アクセステーブルエントリは次の 2 通りの方法で作成できます。
主要構成ファイル /etc/sma/snmp/snmpd.conf にエントリを追加して、アクセステーブルエントリを作成できます。
access grpnam1 fileX usm priv exact all none none access grpnam1 "" usm auth exact all vwnam1 none |
主要構成ファイル /etc/sma/snmp/snmpd.conf に追加することで作成されたグループの場合、 vacmAccessTable テーブル内に次のエントリが作成されます。
SNMP-VIEW-BASED-ACM-MIB::vacmAccessContextMatch. "grpnam1"."".3.authNoPriv = INTEGER: exact(1) SNMP-VIEW-BASED-ACM-MIB::vacmAccessContextMatch. "grpnam1"."fileX".3.authPriv = INTEGER: exact(1) SNMP-VIEW-BASED-ACM-MIB::vacmAccessReadViewName. "grpnam1"."".3.authNoPriv = STRING: all SNMP-VIEW-BASED-ACM-MIB::vacmAccessReadViewName. "grpnam1"."fileX".3.authPriv = STRING: all SNMP-VIEW-BASED-ACM-MIB::vacmAccessWriteViewName. "grpnam1"."".3.authNoPriv = STRING: vwnam1 SNMP-VIEW-BASED-ACM-MIB::vacmAccessWriteViewName. "grpnam1"."fileX".3.authPriv = STRING: none SNMP-VIEW-BASED-ACM-MIB::vacmAccessNotifyViewName. "grpnam1"."".3.authNoPriv = STRING: none SNMP-VIEW-BASED-ACM-MIB::vacmAccessNotifyViewName. "grpnam1"."fileX".3.authPriv = STRING: none SNMP-VIEW-BASED-ACM-MIB::vacmAccessStorageType. "grpnam1"."".3.authNoPriv = INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmAccessStorageType. "grpnam1"."fileX".3.authPriv = INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmAccessStatus. "grpnam1"."".3.authNoPriv = INTEGER: active(1) SNMP-VIEW-BASED-ACM-MIB::vacmAccessStatus. "grpnam1"."fileX".3.authPriv = INTEGER: active(1) |
主要構成ファイル /etc/sma/snmp/snmpd.conf を直接編集することで作成されたグループの場合、ストレージの型は permanent になります。
snmpvacm コマンドを使ってアクセステーブルエントリを作成する方法もあります。
# snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv localhost createAccess grpnam1 "fileX" 3 3 1 all none none |
ユーザー myuser のアクセスレベルは rwuser です。したがって、この例では、コンテキストに適していれば、アクセスエントリは myuser として作成されます。
# snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv localhost createAccess grpnam1 "" 3 2 1 all vwnam1 none |
snmpvacm コマンドで作成されたグループの場合、ストレージの型は nonvolatile になります。snmpvacm コマンドまたは snmpusm コマンドで作成されたオブジェクトの場合、ストレージの型は nonvolatile になります。
例 4–3 と 例 4–4 の情報を使って、例 4–2 で作成した SNMPv3 ユーザー user2 が存在することを確認します。user2 の値をチェックおよび設定して、このユーザー用に作成されたアクセスエントリを検証します。暗号化を使用して 1 回、暗号化を使用しないで 1 回、snmpget コマンドと snmpset コマンドを実行します。この方法により、user2 のアクセスエントリが最小限必要なセキュリティーレベル auth= 2 であることがわかります。この方法により、より安全なセキュリティーレベル priv の使用が可能であることもわかります。
snmpget コマンドを使って、暗号用の DES オプションが設定された新しいユーザーが存在することをチェックします。コンテキスト -n fileX が指定されています。
# snmpget -v3 -u user2 -a MD5 -A my_password -l authPriv -x DES -X my_password -n fileX localhost 1.3.6.1.4.1.42.2.2.4.4.6.1.1.0 |
このコマンドは、user2 に設定したアクセスエントリのうち 1 つを検証します。snmpget コマンドの使用に関連付けられているオプションについては、snmpcmd(1M) のマニュアルページを参照してください。
snmpget コマンドで、次の情報が取得できます。
SNMPv2-SMI::enterprises.42.2.2.4.4.6.1.1.0 = INTEGER: 111 |
この出力の 111 は、指定の OID に格納された整数です。
同様に、snmpget コマンドを使って、DES オプションを設定せずに、新しいユーザーの存在をチェックできます。DES オプションを設定しない場合、暗号化は要求されません。この例では、ユーザー user2 はコンテキスト内にない操作を実行できます。
# snmpget -v3 -u user2 -a MD5 -A my_password -l authNoPriv localhost 1.3.6.1.2.1.1.3.0 |
snmpgetコマンドは、システム稼働時間に関する次の情報を取得します。
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (5375) 0:00:53.75 |
sysLocation に新しい値を設定してみてください。
# snmpset -v3 -u user2 -a MD5 -A my_password -l authPriv -x DES -X my_password localhost 1.3.6.1.2.1.1.6.0 s "new val" |
このコマンドの s は文字列を表します。OID は sysLocation です。sysLocation に追加される値は new val です。
user2 は、DES のコンテキストに対する完全なアクセス権 (authPriv) を持っています。パスワードは my_password です。次の情報が返されます。
SNMPv2-MIB::sysLocation.0 = STRING: new val |
snmpget コマンドを使って、これらの設定を確認します。
# snmpget -v3 -u user2 -a MD5 -A my_password -l authPriv -x DES -X my_password localhost 1.3.6.1.2.1.1.6.0 |
SNMPv2-MIB::sysLocation.0 = STRING: new val |
同じコマンドを、DES 暗号化を設定しないで実行してみてください。
# snmpset -v3 -u user2 -a MD5 -A my_password -l authNoPriv localhost 1.3.6.1.2.1.1.6.0 s "new val2" |
同じ結果が返されます。
SNMPv2-MIB::sysLocation.0 = STRING: new val2 |
# snmpget -v3 -u user2 -a MD5 -A my_password -l authNoPriv localhost 1.3.6.1.2.1.1.6.0 |
SNMPv2-MIB::sysLocation.0 = STRING: new val2 |
この出力によると、ユーザーは MIB-II への書き込みアクセスが許可されています。
user2 が snmptrapd.conf ファイルに定義されている場合は、snmptrapd コマンドを使って SNMP トラップデーモンを起動します。
# /usr/sfw/sbin/snmptrapd |
また、snmpinform コマンドを使って INFORM-PDU トラップを送信します。snmpinform コマンドは、ユーザー user2 または user2 が通知を生成できることを確認します。コールドスタートを実行すると、通知が生成されます。コールドスタートは、通知 (トラップ) を生成します。このトラップは、/var/log/snmpd.log ファイルで確認できます。
# /usr/sfw/sbin/snmpinform -v3 -u user2 -a MD5 -A my_password -l authNoPriv localhost 42 coldStart.0 |
詳細については、snmptrapd.conf(4) および snmpinform(1M) のマニュアルページを参照してください。
VACM テーブルエントリの作成時には、ユーザーとユーザーグループに正しいアクセス権を設定する必要があります。アクセス権の設定が正しくないと、主要ユーザーのアクセスが拒否される可能性があります。
ユーザーグループを大量に作成することは避けてください。グループの数が多いと、管理が難しくなります。ユーザーグループの数が多すぎると、問題の障害追跡が困難になります。
VACM テーブルの使用時、戻り値に次のメッセージが含まれることがあります。
システム管理エージェントが、vacmContextTable 内で特定のメッセージの contextName を検出できない場合に返される値。アクセスは拒否される。コンテキストテーブルのエントリをチェックする必要がある。これらのエントリが正しく構成されているか確認する必要がある。各ユーザーにコンテキストを持っているかを確認する必要がある。詳細については、「コンテキストテーブル」を参照
msgSecurityModel 指示子および関連する SecurityName が vacmSecurityToGroupTable 内にない場合に返される値。アクセスは拒否される。グループセキュリティーテーブルのエントリをチェックする必要がある。これらのエントリが正しく構成されているか確認する必要がある。各ユーザーがグループ名を持っているかを確認する必要がある。ユーザーがテーブルに正しく入力されているかを確認する必要がある。詳細については、「グループセキュリティーテーブル」を参照
この値は、MIB ビューに検索対象の OID が含まれていない場合に返される。アクセスは拒否される。詳細については、「ビューツリーファミリテーブル」を参照
この値は、アクセス権が見つからない場合に返される。アクセスは拒否される。マスクが正しく設定されているか確認する必要がある。各グループは複数のアクセス権を持つことができるが、そのうちもっとも安全なアクセス権だけが選択される
vacmAccessContextMatch パラメータが exact に設定されているか確認する必要がある。vacmAccessContextMatch パラメータが exact に設定されている場合、contextName は完全に一致している必要がある。適切な場合は、vacmAccessContextMatch の値を prefix に設定してみるとよい。詳細については、「アクセステーブル」を参照
VACM テーブルが正しく構成されていないと、ネットワークが承認されていない不正なアクセスを受ける可能性があります。VACM 構成をテスト環境でテストしてから、ネットワークデバイスに実装してください。
VACM の詳細については、RFC 3415 (http://www.ietf.org/rfc/rfc3415.txt ) を参照してください。
VACM の MIB 定義は、/etc/sma/snmp/mibs/SNMP-VIEW-BASED-ACM-MIB.txt にあります。