Micro Focus 監査エミッターの SNMP V3 の構成 (非推奨)

注: 監査マネージャーは非推奨です。下位互換性のみを目的として提供されています。代わりに syslog イベントを使用することをお奨めします。詳細については、「エンタープライズ サーバーの監査」を参照してください。

標準の V2 インストールに対する最初の変更は、V3 操作を有効にすることです。

mfaudit.emitter.snmp#agent.snmp_version = 3

その後、送信時に必要とするセキュリティ権限のレベルを選択する必要があります。

認証は任意に有効または無効にすることができますが、プライバシーは認証が既に有効になっている場合にしか有効にできません。したがって、送信権限は次の 3 つになります。

NoAuth データの認証と暗号化を行いません。

AuthPriv プライベート (暗号化) データを認証および使用します。

AuthNoPriv データの暗号化なしでユーザーを認証します。

SNMP 監査エミッターを構成する際、この選択は "privilege" 設定で保持されます。次の例では、認証とプライバシーの両方を有効にしています。

mfaudit.emitter.snmp#agent.privilege = AuthPriv

プライバシーまたは認証とプライバシーが無効になっている場合、構成の関連するセクションは無視されます。

認証を行う場合は、トラップを受信する監視側と発行元のエミッターでユーザー ID を構成します。5 つのオプションでユーザーを定義し、さらに追加のオプションでユーザーを論理的なグループにまとめるセキュリティ エンジン ID を定義します。

次に、ユーザーのオプションについて詳しく説明します。

ユーザー名
ユーザー名は、簡潔な名前の単一のテキスト文字列です。この名前にはスペースを含めることはできません。
mfaudit.emitter.snmp#agent.security_username = fred_jones
ハッシュ方式
ハッシュ方式と認証パスフレーズ (暗号化の用語では共有シークレット) の組み合わせで暗号の値が形成されます。この値が、受信側で同じように構成されたユーザー名とセキュリティ エンジン ID のペアと比較され、一致しないと認証の試行が拒否されます。

ほとんどのインストールで MD5 ハッシュ方式がサポートされており、より新しいインストールでは SHA1 もサポートされていることがあります。V3 ユーザーを新規に構成する場合は、トラップを受信する監視側にインストールされている最新のハッシュ方式を使用してください。現在 SHA1 よりも多くのインストールで事前に構成されているため、デフォルトのハッシュ方式は MD5 になっています。

mfaudit.emitter.snmp#agent.hmac = MD5

選択したハッシュ方式は、構成されるパス フレーズに適用されます。パス フレーズの長さは 8 文字以上でなければならず、空白文字を含む場合は一組の引用符で囲みます。パスワードに空白文字が含まれない場合は、引用符を省略できます。

mfaudit.emitter.snmp#agent.auth_passphrase = "auth password"
暗号化の暗号
プライバシーの暗号は、DES または AES128 のいずれかになります。上記の SHA1 ハッシュと同様に、AES は SNMP V3 に最近追加されたものであり、すべてのインストールで適切に機能するとは限りません。そのため、デフォルトの設定では DES 暗号が使用されます。ハッシュ方式の選択と同様に、V3 ユーザーを新規に構成する場合は、トラップを受信する監視側にインストールされている最新の暗号方式を使用してください。理想は AES ですが、現在の既存のインストールのほとんどに一致する DES がデフォルトの設定になっています。

オプションは、DES、AES、および AES128 の 3 つです。後者の 2 つは同等です。SNMP V3 標準への追加に伴い、AES192 および AES256 のサポートが今後追加される予定です。それ以降は、AES が AES128 を指すようになります。

mfaudit.emitter.snmp#agent.cipher = DES

プライバシー (暗号) のパス フレーズにも、認証のパス フレーズとまったく同じルールが適用されます。

mfaudit.emitter.snmp#agent.cipher_passphrase = "crypt password"
セキュリティ エンジン ID
特定のユーザー名のコピーは SNMP のインストールには複数含めることができますが、1 つのセキュリティ エンジンの範囲には 1 つしか含めることができません。したがって、上記の 5 つのオプションのグループは常に 1 つのセキュリティ エンジン ID とペアになります。これは 16 進数形式の数値文字列です。セキュリティ エンジン ID にどのような値を使用するかについては、さまざまな方法があり、まだ正式なコンセンサスはありません。それに関してはここで議論することではありませんが、いずれにしても、セットアップではセキュリティ エンジン ID として使用する値を選択しなければなりません。これは、受信側のエンジン ID およびユーザー名の構成オプションのグループと一致する必要があります。

次の例は、最初のテスト用の値としては機能しますが、より広い SNMP コンテキストにおいては意味がなく、ネットワーク管理チームは監査エミッターの監視用にセキュリティ エンジン ID を割り当てるか、使用する既存のエンジン ID をユーザーに伝える必要があります。

mfaudit.emitter.snmp#agent.security_engineID = 0x0102030405

これら一連の情報を合わせ、ユーザー、ユーザーのセキュリティ エンジン、ユーザーの ID を証明する方法、および監査イベントのデータ コンテンツを暗号化する方法について 1 つにまとめることで、単一のユーザーを示す完全な構成となります。

mfaudit.emitter.snmp#agent.privilege = AuthPriv
mfaudit.emitter.snmp#agent.security_engineID = 0x0102030405
mfaudit.emitter.snmp#agent.security_username = fred_jones
mfaudit.emitter.snmp#agent.hmac = MD5
mfaudit.emitter.snmp#agent.auth_passphrase = "auth password"
mfaudit.emitter.snmp#agent.cipher = DES
mfaudit.emitter.snmp#agent.cipher_passphrase = "crypt password"
コンテキスト ID とコンテキスト名
上記以外の最後の構成項目として、セキュリティ コンテキスト ID とコンテキスト名があります。これらは、セキュリティ エンジン ID とユーザー名の組み合わせと同じようにペアで使用され、制限された接続エンティティを形成します。

コンテキストは、SNMP データを受信するアプリケーションが複数ある環境において、すべてのアプリケーションですべての着信データを受信するわけではない場合に便利です。

異なるアプリケーションのセキュリティ エンジン ID とユーザー名の構成は同じにし、コンテキスト エンジンとコンテキスト名については異なる構成を使用することで、送信先と送信元を区別するためにセキュリティ エンジン ドメインで追加のユーザーを構成しなくても、特定の場所を送信先とするデータをその場所に送信できます。

セキュリティ エンジン ID とユーザー名の構成項目と同様に、コンテキスト エンジン ID は 16 進数の文字列で、コンテキスト名は人間が内容を理解できる文字列です。

mfaudit.emitter.snmp#agent.context_engineID = 0x0102030405
mfaudit.emitter.snmp#agent.context_name = primary_audit_monitor