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) のマニュアルページを参照してください。