test

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

第 4 章 セキュリティーの管理

この章では、システム管理エージェントのセキュリティーに関する基礎的な情報と、各種手順および例を示します。システム管理エージェントでは、SNMPv3 の機能により、ユーザーおよびネットワークデバイスの管理のセキュリティーレベルが拡張され、構成可能です。

この章で扱うトピックは次のとおりです。

セキュリティーの概要

システム管理エージェントは、SNMPv1、SNMPv2c、および SNMPv3 をサポートします。SNMPv1 とSNMPv2c の認証サービスは、管理ステーション上で定義されたコミュニティー文字列に基づいています。SNMPv3 認証サービスは、ユーザーに基づいています。各要求には、コミュニティー名またはユーザー名のどちらか (使用するプロトコルによる) が含まれていなければなりません。

SNMPv3 認証処理は、ユーザーに基づくセキュリティーモデル (USM) を実装しており、ユーザー名からセキュリティー名とセキュリティーレベルを取得します。同様に、SNMPv1 と SNMPv2c は、コミュニティー文字列からセキュリティーレベルを決定します。セキュリティー名とセキュリティーレベルは、コンテキスト文字列、グループ名、およびビュー名とともに、アクセス制御の実行に使用されます。アクセス制御は、ビューに基づくアクセス制御モデル (VACM) を使って行われます。このアクセス制御モデルは、認証処理の完了後に使用されます。つまり、USM が認証用であるのに対し、VACM は承認用であると言えます。

システム管理エージェントでサポートされる SNMP のバージョンについては、「SNMP のバージョン」を参照してください。

USM による認証とメッセージプライバシ

システム管理エージェントでは、SNMPv3 パケットの認証、暗号化、および復号化に、ユーザーに基づくセキュリティーモデル (USM) を使用します。USM の使用目的は次のとおりです。

snmpusm ユーティリティーは、SNMP エージェントの USM テーブルの基本管理用 SNMP アプリケーションです。usmUserTable MIB テーブルへの書き込みアクセスが必要です。詳細については、snmpusm(1M) のマニュアルページを参照してください。

注 –

snmpusm サブコマンドは、SNMPv1 および v2c ではサポートされません。プロキシなしでこれらのコマンドを実行できるのは、SNMPv3 ユーザーだけです。

エージェントの働きにより、ユーザーは、主要構成ファイル snmpd.conf と snmpusm コマンドを利用して、USM MIB を通してユーザーエントリを管理できます。システム管理エージェントは、USM MIB を利用して、ユーザー情報 (ユーザーが存在するかどうかの情報も含む) を検索します。ユーザーからの要求はすべて、USM MIB と照合されます。ユーザーが存在する場合、USM MIB は次のアクセス権をチェックします。

USM MIB は、ローカルストアキーを使って、MIB 内の特定のユーザーによって指定された認証プロトコルに基づく新しいダイジェストを計算します。計算されたダイジェストは、着信パケットから保存されたダイジェストと比較されます。2 つのダイジェストが一致すれば、そのユーザーは認証されます。メッセージダイジェストの詳細については、「認証プロトコルアルゴリズム」を参照してください。

以下では、USM の設定について説明します。

ユーザー

SNMP エンジンとの通信を許可されたユーザーを表す

認証の型

使用する認証プロトコルアルゴリズム を指定する(MD5 または SHA)。詳細については、「認証プロトコルアルゴリズム」を参照

認証パスワード

ユーザーの認証パスワードを指定する。パスワードは 8 文字以上で構成する必要がある。

プライバシの型

使用するプライバシプロトコルを指定する。システム管理エージェントの場合、DES (データ暗号化規格) が使用される。詳細については、「メッセージプライバシ」を参照

プライバシパスワード

ユーザーのプライバシパスワードを指定する。パスワードは 8 文字以上で構成する必要がある。

セキュリティーレベル

認証とプライバシに関するユーザーのセキュリティーレベルを指定する。

noAuthNoPriv

ユーザー名の一致だけを使って認証を行う

authNoPriv

MD5 または SHA1 アルゴリズムに基づいた認証を行う

authPriv

DES プロトコルに基づいたプライバシ (暗号化) を提供する

認証では、秘密鍵を使って MAC (メッセージ認証コード) を生成し、usmSecurityParameters を構成する msgAuthenticationParameters に格納します。送信側と受信側のエンティティーは、同じ秘密鍵を使って MAC を生成します。このため、送信側の MAC と受信側の MAC が一致すれば、メッセージは認証されます。

認証プロトコルアルゴリズム

システム管理エージェントに実装されている USM では、2 つの認証プロトコルがサポートされます。以下のリストに認証プロトコルを示します。

HMAC-MD5–96

システム管理エージェントでは、メッセージダイジェスト実装は HMAC-MD5–96。これは、MD5 に基づく単方向の暗号化であり、96 ビットのハッシュと16 オクテットのキー長を使用する。計算上、2 つのメッセージが同じメッセージダイジェストを持つことはできない。事前に指定されたターゲットメッセージダイジェストからメッセージを生成することもできない。MD5 アルゴリズムは電子署名アプリケーションを対象にしている。これらのアプリケーションでは、サイズの大きいファイルを安全に圧縮する必要がある。圧縮後、公開鍵暗号システムにより、秘密鍵を使って暗号化する。HMAC-MD5–96 アルゴリズムは 32 ビットマシンで使用可能。大規模な置換テーブルは不要。このアルゴリズムは非常にコンパクトにコード化することができる。MD5 の詳細については、RFC 1321 (http://www.ietf.org/rfc/rfc1321.txt ) を参照

HMAC-SHA–96

システム管理エージェントでは、セキュアハッシュアルゴリズム (SHA) 実装は HMAC-SHA–96。この単方向暗号化は、96 ビットのハッシュと 20 オクテットのキー長を使用する。このアルゴリズムは、2 64 ビット未満の長さのメッセージを入力として受け付ける。入力メッセージは 512 ビットブロックで処理される。このアルゴリズムは 160 ビットのメッセージダイジェスト出力を生成する。このメッセージダイジェストは、たとえば、メッセージの署名を生成または検証する署名アルゴリズムへの入力として使用される。メッセージダイジェストには、メッセージそのものではなく署名が付いている。このため、元のメッセージよりサイズが小さくなるため、効率がよくなる。電子署名の作成者が SHA を使用している場合は、検証側でも SHA を使用する必要がある。通常、転送中にメッセージに変更が加えられた場合は、メッセージダイジェストにも変更が加えられる。その結果、電子署名の検証は失敗する。SHA の安全性が高いのは、計算上、2 つのメッセージが同じメッセージダイジェストを持つことができないためである。また、事前に指定されたターゲットメッセージダイジェストからメッセージを生成することもできない。SHA の設計は MD5 ファミリのハッシュ関数と類似している。SHA の詳細については、RFC 3174 (http://www.ietf.org/rfc/rfc3174.txt ) を参照

システム管理エージェントの場合、デフォルトの認証プロトコルは HMAC-MD55–96 です。設定は auth proto = MD5 です。

メッセージプライバシ

USM はメッセージのプライバシをサポートします。USM は、SNMPv3 パケットの暗号化と復号化に、CBC-DES 対称暗号化プロトコルを使用します。認証の場合と同様に、送信側でのメッセージの暗号化と受信側でのメッセージの復号化には、同じ秘密鍵を使用します。データ部分だけが暗号化されます。暗号化を使用するには、auth フラグを有効にし、セキュリティーレベルでプライバシを有効にする必要があります。scopedPDU だけが暗号化されます。詳細については、「USM セキュリティー情報の格納場所」を参照してください。

現在、Solaris OS では、DES 暗号化がサポートされています。DES 暗号化では 56 ビットの鍵暗号化を使用します。これが、今回の Solaris ソフトウェアリリースの DES でサポートされている、現段階で最高レベルの暗号化です。

公開鍵

システム管理エージェントは、公開鍵暗号化標準 (PKCS) #11 をサポートします。このトークンインタフェース標準は、SSL モジュールと PKCS #11 モジュールの間の通信に使用するインタフェースを定義します。システム管理エージェントでコンパイルされた PKCS ライブラリは、PKCS#11 v2.11 標準に基づいています。

「認証プロトコルアルゴリズム」に記述されているように、MD5 に加えて SHA1 アルゴリズムがサポートされます。システム上に PKCS ライブラリがない場合、SMA は DES のサポートなしで標準 Net-SNMP 内部 MD5 の使用を試みます。

USM セキュリティー情報の格納場所

USM 情報は、SNMPv3 パケット文字列内の次のフラグに含まれています。

msgFlags

メッセージの処理方法を指定する 8 ビット。たとえば、msgFlags の 8 ビット中 2 ビットは、パケットが暗号化されているかどうかと、パケットが認証されているかどうかを指定する。このフラグを使って、メッセージのセキュリティーレベルが決定される。セキュリティーレベルは、主要ファイル snmpd.conf で次のように指定する

noAuthNoPriv

次の整数で表される。1。

最小限のアクセス

authNoPriv

次の整数で表される。2。

noAuthNoPriv 以上、 authPriv 以下のアクセス権

authPriv

次の整数で表される。3。

最大限のアクセス。もっとも安全

msgSecurityModel

メッセージの生成に使用するセキュリティーモデルを指定して、受信側エンティティーが適切なセキュリティー処理モデルを利用できるようにする。システム管理エージェントでサポートされているセキュリティーモデルは USM のみ

msgSecurityParameters

セキュリティーモデルに関するデータを含む 8 ビット文字列。このデータは使用するセキュリティーモデル (複数可) によって定義される。このデータは使用するセキュリティーモデル専用として使用される。セキュリティーモデルは msgSecurityModel に指定される。USM は、このフィールドを使って、SNMPv3 メッセージの認証、暗号化、および復号化を行う

scopedPDU

標準のプロトコルデータユニット (PDU) と、この PDU の処理に使用される管理上一意のコンテキストの識別情報を含む。SNMPv2 メッセージと SNMPv3 メッセージは、どちらも同じ PDU フォーマットを使用する。トランザクションのプライバシが有効になっている場合、この scopedPDU 形式は暗号化される

USM の MIB 定義は、/etc/sma/snmp/mibs/SNMP-USER-BASED-SM-MIB.txt にあります。

USM の詳細については、RFC 3414 (http://www.ietf.org/rfc/rfc3414.txt ) を参照してください。

VACM によるアクセス制御

ビューに基づくアクセス制御モデル (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 トークンエントリは、ユーザーが指定しなければならない最小限のアクセス権を指定します。

rwuser1 priv

ユーザーはプライバシパスワードを指定しなければならない

rwuser2 auth

プライバシパスワードを使って作成されたユーザーはプライバシパスワードを指定できる。それ以外の場合、ユーザーは認証パスワードを指定しなければならない

rwuser3 none

ユーザーは、パスワードを指定しないか、または認証パスワードを指定できる。また、プライバシパスワードを使って作成されたユーザーはプライバシパスワードを指定できる

VACM セキュリティー情報の格納場所

VACM 情報は、SNMPv3 パケット文字列内の複数のパラメータに含まれています。これらのパラメータは isAccessAllowed 機構に渡されます。isAccessAllowed 機構は、アクセスを付与すべきかどうかをチェックする VACM 内の唯一のエントリポイントです。

VACM パラメータを以下に示します。

msgFlags

メッセージの処理方法を指定する 8 ビット。詳細については、「USM セキュリティー情報の格納場所」を参照

msgSecurityModel

メッセージの生成時に使用されたセキュリティーモデルを指定して、受信側エンティティーが適切なセキュリティー処理モデルを利用できるようにする。SNMPv3 では、単一のセキュリティーモデルの使用か複数のセキュリティーモデルの使用かを選択できる

msgSecurityParameters

セキュリティーモデルに関するデータを含む 8 ビット文字列。セキュリティーモデル (複数可) は msgSecurityModel に指定される

scopedPDU

PDU を含む。PDU 処理に使用する管理情報の管理上一意のセレクタを示す。つまり、scopedPDU にはコンテキストと管理対象オブジェクトの OID が含まれる。scopedPDU には次のフィールドがある

contextEngineID

コンテキスト内の管理対象オブジェクトのインスタンスにアクセスできる SNMP エンティティーを一意に識別する

contextName

PDU データの属するコンテキストの名前。contextName は一意

PDU

SNMPv3 のプロトコルデータユニット (PDU) には、contextName 内のデータの操作が含まれる。contextEngineID と contextName の組み合わせにより識別される

SNMPv3 パケット文字列のその他のフィールドについては、「SNMP のバージョン」を参照してください。

図 4–1 SNMPv3 パケットフォーマットと、認証と暗号化の範囲

図は、SNMPv3 のパケットフォーマットおよび PDU パケットのサブコンポーネントを示します。

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

ユーザーの作成と管理

この節では、ユーザーを安全に作成する手順について説明します。システム管理エージェントでは、複数の方法でユーザーを作成できます。システム管理エージェントのインストール後、デフォルトの構成では、新しいユーザーは SNMPv1 および v2c ユーザーになります。

注 –

デフォルトでは、エージェントは SNMPv3 ユーザーを作成するように設定されていません。システム管理エージェントで SNMPv3 ユーザーを作成するには、まず主要 ファイル /etc/sma/snmp/snmpd.conf を編集する必要があります。詳細については、snmpd.conf(4) のマニュアルページを参照してください。

この節の最初の手順、「新しい SNMPv3 ユーザーを作成するには」では、最初の初期ユーザーを新規作成する方法を説明します。その他のユーザーは、この初期ユーザーを複製して作成します。ユーザーの認証やセキュリティーの型も、初期ユーザーから継承できます。これらの型はあとで変更可能です。複製を作成するときは、ユーザーの秘密鍵のデータを設定します。初期ユーザーと、あとで設定するユーザーのパスワードが必要になります。設定済みの初期ユーザーから、同時に複数の複製を作成することはできません。

Procedure新しい SNMPv3 ユーザーを作成するには

この手順で使用される net-snmp-config コマンドは、/etc/sma/snmp/snmpd.conf ファイルに 1 行を追加することにより、初期ユーザーに対し、エージェントへの読み取りおよび書き込みアクセスを許可します。

  1. システム管理エージェントを停止します。


    # svcadm disable -t svc:/application/management/sma:default

  2. 新規ユーザーを作成するには、net-snmp-config コマンドを実行します。


    # /usr/sfw/bin/net-snmp-config --create-snmpv3-user -a "my_password" newuser

    このコマンドは、newuser という新しいユーザーを作成します。パスワードは my_password と同じになります。新しいユーザーの作成には、MD5 とDES の両方を使用します。これらについては、「認証プロトコルアルゴリズム」を参照してください。

    デフォルトでは、これらの設定は、net-snmp-config コマンドを使ってユーザーを作成するとき、特に指定しなくても作成されます。

    auth protocol = MD5 security level = rwuser auth

  3. システム管理エージェントを起動します。


    # svcadm enable svc:/application/management/sma:default

  4. 新しいユーザーが存在するかどうかを確認します。


    # snmpget -v 3 -u newuser -l authNoPriv -a MD5 -A my_password localhost sysUpTime.0
    注 –

    パスワードは 8 文字以上にする必要があります。

    新しいユーザーに読み取りおよび書き込みアクセスを許可することが適切でない場合もあります。新しいユーザーに許可するアクセス権を減らすか変更する場合は、/etc/sma/snmp/snmpd.conf ファイルを編集します。詳細については、snmpd.conf(4) のマニュアルページを参照してください。

Procedureシステムプロンプトを使って新しいユーザーを作成するには

  1. システム管理エージェントを停止します。


    # svcadm disable -t svc:/application/management/sma:default

  2. newuser という名前の新しいユーザーを作成し、my_password というパスワードを設定するには、net-snmp-config コマンドを対話的に使用します。


    # /usr/sfw/bin/net-snmp-config --create-snmpv3-user


    Enter a SNMPv3 user name to create:

  3. 適切なユーザー名を指定します。この例の場合、次のように指定します。


    newuser


    Enter authentication pass-phrase:

  4. 適切なパスワードを入力します。この例の場合、次のように入力します。


    my_password


    Enter encryption pass-phrase:

  5. 認証パスワードを再利用する場合は、Return キーを押します。


    adding the following line to /var/sma_snmp/snmpd.conf:
createUser newuser MD5 "newuser_pass" DES
adding the following line to /etc/sma/snmp/snmpd.conf:
rwuser newuser

    デフォルトでは、これらの設定は、net-snmp-config コマンドを使ってユーザーを作成するとき、特に指定しなくても作成されます。

    auth protocol = MD5

    security level = rwuser auth

  6. システム管理エージェントを起動します。


    # svcadm enable svc:/application/management/sma:default

  7. 新しいユーザーが存在するかどうかを確認します。


    # snmpget -v 3 -u newuser -l authNoPriv -a MD5 -A my_password localhost sysUpTime.0
    注 –

    パスワードは 8 文字以上にする必要があります。

    新しいユーザーに読み取りおよび書き込みアクセスを許可することが適切でない場合もあります。新しいユーザーに許可するアクセス権を減らすか変更する場合は、/etc/sma/snmp/snmpd.conf ファイルを編集します。詳細については、snmpd.conf(4) のマニュアルページを参照してください。

Procedure追加の SNMPv3 ユーザーを安全に作成するには

安全な SNMP で新しいユーザーを作成する場合は、最初に設定した初期ユーザーを複製する方法をお勧めします。この方法では、「新しい SNMPv3 ユーザーを作成するには」で設定したユーザーをコピーします。この方法では、「USM による認証とメッセージプライバシ」で説明した snmpusm コマンドを使用します。詳細については、snmpusm(1M) のマニュアルページを参照してください。

  1. システム管理エージェントが実行中かどうかをチェックします。


    # svcs svc:/application/management/sma:default

    エージェントがまだ起動していない場合は、起動します。


    # svcadm enable svc:/application/management/sma:default

  2. snmpusm コマンドを使って新しいユーザーを作成します。


    # snmpusm -v 3 -u newuser -a MD5 -A my_password -l authNoPriv localhost create lee newuser

    このコマンドでは、lee というユーザーを作成します。この新しいユーザーには、 「新しい SNMPv3 ユーザーを作成するには」で作成したソースユーザー newuser と同じパスワード my_password が与えられます。

  3. 新しいユーザーのパスワードを変更します。


    # snmpusm -v 3 -u lee -a MD5 -A my_password -l authNoPriv localhost passwd my_password lee_password

    このコマンドでは、ユーザー lee に新しいパスワード lee_password が与えられます。デフォルトの auth type は MD5 です。

  4. /etc/sma/snmp/snmpd.conf ファイルを直接編集するか、snmpvacm コマンドを使って、関連する VACM エントリを作成します。

    snmpd.conf ファイルを直接編集する場合は、まずエージェントを一時的に停止する必要があります。


    # svcadm disable -t svc:/application/management/sma:default

  5. lee にアクセスを割り当てます。

    • lee に読み取りおよび書き込みアクセスを許可するには、snmpd.conf ファイルに新しい rwuser 行を追加します。


      rwuser lee

    • lee に読み取り専用アクセスを許可するには、snmpd.conf ファイルに新しい rouser 行を追加します。


      rouser lee

    セキュリティーレベルを指定しなかった場合、デフォルトの authNoPriv が選択されます。詳細については、snmpd.conf(4) または snmpvacm(1M) のマニュアルページを参照してください。

  6. システム管理エージェントを起動します。


    # svcadm enable svc:/application/management/sma:default

  7. この手順が成功したかどうかを確認します。

    新しいユーザーが存在するかどうかを確認します。


    # snmget -v 3 -u lee -a MD5 -A lee_password -l authNoPriv localhost sysUpTime.0

SNMPv3 セキュリティーを使った SNMPv1 および SNMPv2c ユーザーの管理

SNMPv1 および v2c ユーザーのセキュリティー保護には、コミュニティー文字列が使用されます。SMA には、標準 Net-SNMP トークン com2sec が付属しています。com2sec トークンにより、SNMPv1 および v2c のホスト名とコミュニティー文字列のペアをセキュリティー名にマッピングできます。この場合、セキュリティーレベルは noAuthNoPriv になります。 noAuthNoPriv セキュリティーレベルとその他のセ キュリティレベルの詳細については、「USM セキュリティー情報の格納場所」を参照してください。

プロキシ文とセキュリティー

システム管理エージェントでは、プロキシは SNMPv1 および v2c ユーザーに対してのみサポートされます。詳細については、「Solstice Enterprise Agents 要求のプロキシ処理」を参照してください。

グループの作成と管理

SNMP 内で多数のグループを作成すると、これらのグループの管理が非常に複雑になります。多数のグループを作成すると、これらのグループの問題の障害追跡も非常に困難になります。

注 –

snmpd.conf ファイルを編集して、グループやビューを作成した場合、ストレージの型は固定されます。snmpvacm コマンドを使用せず、snmpd.conf ファイルを編集した場合、グループのエントリが固定されます。エントリを削除するには、これらを snmpd.conf ファイルから削除する必要があります。

「VACM によるアクセス制御」 のグループの作成および管理の例を参照してください。