test

Solaris のシステム管理 (システム管理エージェント)

VACM テーブルについて

メッセージにアクセスを付与するかどうかを決定する際、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 内の一般的なエントリの例を示します。

例 4–1 一般的なコンテキストテーブルエントリの作成

モジュールにより作成される一般的な 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 テーブルは、以下の項目で索引付けられています。

vacmSecurityToGroupTable テーブルの各行には、次の情報が含まれます。

vacmSecurityModel

SNMPv3 セキュリティーモデル。この例では USM。USM の詳細については、「USM による認証とメッセージプライバシ」を参照。com2sec トークンを利用すると、SNMPv1 および v2c のセキュリティーモデルを使用できるようになる。com2sec トークンの詳細については、snmpd.conf(4) のマニュアルページを参照

vacmSecurityName

USM では、vacmSecurityName と userName は一致する。セキュリティーモデルとは無関係のフォーマットでユーザーを表現する。com2sec トークンを利用すると、SNMPv1 および v2c のセキュリティー名を使用できるようになる。com2sec トークンの詳細については、snmpd.conf(4) のマニュアルページを参照

vacmGroupName

読み取り可能な文字列。このエントリに関連付けられているグループを示す

メッセージの認証と復号化に成功すると、SecurityName が msgSecurityModel 指示子によって取得されます。システム管理エージェントは、vacmSecurityToGroupTable テーブル内で、この msgSecurityModel 指示子および関連する SecurityName を検索します。vacmSecurityToGroupTable 内で msgSecurityModel 指示子および関連する SecurityName が見つからない場合、アクセスは拒否されます。この場合、戻り値は noSuchGroupName になります。

エントリが見つかった場合、対応する groupName が返されます。図 4–2 のように、アクセスチェックが続行されます。

例 4–2 に、vacmsecurityToGroupTable 内の一般的なエントリを示します。

例 4–2 一般的なグループセキュリティーテーブルエントリの作成

以前に作成したユーザー user2 および user5 のグループを作成します。この例では、ユーザーは、grpnam1 という新しく作成されたグループに配置されます。次のいずれかの方法を選択します。

ビューツリーファミリテーブル

vacmViewTreeFamilyTable テーブルには、ビューサブツリーファミリの全コレクションが格納されます。これらのコレクションを「MIB ビュー」と呼びます。MIB ビューは、OID サブツリー値です。ファミリ名と、ファミリマスクであるビット文字列値から成ります。ファミリマスクは、MIB ビュー内に存在するファミリ名のサブ識別子を特定します。マスクは、次のいずれかで区切られた 16 オクテットのリストです。「.」または「:」。デフォルトは「ff」です。

MIB ビュー内の各ビューサブツリーファミリには、型があります。この型によって、そのビューサブツリーファミリが MIB ビューに含まれるかどうかが決まります。管理対象オブジェクトインスタンスは、次の条件が両方とも真である場合に限り、MIB ビューに含まれます。

マスクの構成値が短すぎてこれらの条件をチェックできない場合、暗黙のうちにこの値に 1 の連続が付加されます。したがって、マスクが 0 ビットのビューファミリサブツリーは、すべての値が 1 のマスクと同等であり、すなわち 1 つの MIB サブツリーと同等です。

vacmViewTreeFamilyTable テーブルは、以下の項目で索引付けられています。

viewName

vacmAccessTable テーブルで選択されたアクセス権によって指定される。アクセスチェックに使用される

MIB サブツリーの OID

PDU の OID が MIB ビューと比較される

vacmViewTreeFamilyTable テーブルの各行の値は次のとおりです。

vacmViewTreeFamilyViewName

MIB ビューの名前

vacmViewTreeFamilySubtree

OID サブツリー。OID サブツリーはマスクとともに MIB ビューサブツリーを構成する

vacmViewTreeFamilyMask

ビット文字列マスク。ビット文字列マスクは OID サブツリーとともに MIB ビューサブツリーを構成する

vacmViewTreeFamilyType

この型によって、そのビューサブツリーファミリが MIB ビューに含まれるかどうかが決まる

MIB ビューに検索対象の OID が含まれていない場合、アクセスは拒否されます。この場合、戻り値は notInView になります。MIB ビューに正しい OID が含まれていれば、アクセスは許可されます。この場合、戻り値は accessAllowed になります。

この VACM アルゴリズム全体のフローチャートは、図 4–2 のようになります。以下では、この図に含まれる RFC 推奨の用語について解説します。

securityName と securityModel

アクセスの要求元を示す

contextName

アクセスが許可される場所を特定する

securityLevel と securityModel

アクセスを許可する方法を特定する

viewType

読み取り、書き込み、通知のいずれか。グループまたはユーザーが特定のアクセスレベルを要求する理由を特定する

管理対象オブジェクトのオブジェクト型または OID

チェック対象の管理データの型を示す

管理対象オブジェクトのインスタンス

オブジェクト型と連携して、MIB ビュー内でチェックするインスタンスを特定する。選択肢は yes か no

図 4–2 VACM 全体のフローチャート

この図は、VACM テーブルのアクセスチェックプロセスを示します。

例 4–3 に、vacmViewTreeFamilyTable の一般的なエントリを示します。

例 4–3 一般的なビューツリーファミリテーブルエントリの作成

ビューは次の 2 通りの方法で作成できます。

アクセステーブル

vacmAccessTable テーブルには、各グループのアクセス権が格納されます。各グループに複数のアクセス権を付与できます。最も安全なアクセス権が選択されます。vacmAccessTable テーブルは、以下の項目で索引付けられています。

groupName

vacmSecurityToGroupTable テーブル内の検索から返される

contextPrefix

vacmContextTable テーブル内で一致する有効な contextName

securityModel

メッセージの msgSecurityModel パラメータ内に指定する

securityLevel

メッセージの msgFlags パラメータ内に指定する

vacmAccessTable テーブル内の各行には、次の値が含まれます。

vacmGroupName

グループ名。このグループには 1 つ以上のアクセス権がある

vacmAccessContextPrefix

contextName は vacmAccessContextPrefix の値と一致する必要がある。vacmAccessContextMatch を参照

vacmAccessSecurityModel

アクセス権の取得で使用する必要のあるセキュリティーモデルを示す

vacmAccessContextMatch

vacmAccessContextMatch が exact に設定されている場合、contextName は vacmAccessContextPrefix オブジェクトの値と正確に一致している必要がある

vacmAccessContextMatch が prefix に設定されている場合、contextName は vacmAccessContextPrefix オブジェクトの値の最初の数文字と一致している可能性がある。この contextName は、vacmContextTable テーブル内ですでに一致している名前である

vacmAccessSecurityLevel

このアクセス権の使用に必要な最低限のセキュリティーレベルを示す。セキュリティーレベルについては、「VACM セキュリティー情報の格納場所」を参照

vacmAccessReadViewName

読み取りアクセスが承認された MIB viewName。vacmAccessReadViewName が空の場合、読み取りアクセス用のアクティブなビューは存在しない

vacmAccessWriteViewName

書き込みアクセスが承認された MIB viewName。vacmAccessWriteViewName が空の場合、書き込みアクセス用のアクティブなビューは存在しない

vacmAccessNotifyViewName

通知アクセスが承認された 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 テーブル内に登録されているかどうかをチェックする方法を示します。

例 4–4 一般的なアクセステーブルエントリの作成

アクセステーブルエントリは次の 2 通りの方法で作成できます。

例 4–5 VACM テーブル内にユーザーが存在するかどうかのチェック

例 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 テーブルエントリの作成時には、ユーザーとユーザーグループに正しいアクセス権を設定する必要があります。アクセス権の設定が正しくないと、主要ユーザーのアクセスが拒否される可能性があります。

ユーザーグループを大量に作成することは避けてください。グループの数が多いと、管理が難しくなります。ユーザーグループの数が多すぎると、問題の障害追跡が困難になります。

VACM テーブルの使用時、戻り値に次のメッセージが含まれることがあります。

noSuchContext

システム管理エージェントが、vacmContextTable 内で特定のメッセージの contextName を検出できない場合に返される値。アクセスは拒否される。コンテキストテーブルのエントリをチェックする必要がある。これらのエントリが正しく構成されているか確認する必要がある。各ユーザーにコンテキストを持っているかを確認する必要がある。詳細については、「コンテキストテーブル」を参照

noSuchGroupName

msgSecurityModel 指示子および関連する SecurityName が vacmSecurityToGroupTable 内にない場合に返される値。アクセスは拒否される。グループセキュリティーテーブルのエントリをチェックする必要がある。これらのエントリが正しく構成されているか確認する必要がある。各ユーザーがグループ名を持っているかを確認する必要がある。ユーザーがテーブルに正しく入力されているかを確認する必要がある。詳細については、「グループセキュリティーテーブル」を参照

notInView

この値は、MIB ビューに検索対象の OID が含まれていない場合に返される。アクセスは拒否される。詳細については、「ビューツリーファミリテーブル」を参照

noAccessEntry

この値は、アクセス権が見つからない場合に返される。アクセスは拒否される。マスクが正しく設定されているか確認する必要がある。各グループは複数のアクセス権を持つことができるが、そのうちもっとも安全なアクセス権だけが選択される

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 にあります。