セキュリティ マネージャーおよびセキュリティ構成

Micro Focus Directory Server (MFDS)、Enterprise Server Common Web Administration (ESCWA) サーバー、エンタープライズ サーバー インスタンス (または「リージョン」) など、Enterprise Server コンポーネントで外部セキュリティ機能 (ESF) を有効にするには、セキュリティ構成の指定が必要になります。セキュリティ構成を指定できるこれらのさまざまなコンテキスト (エンタープライズ サーバー インスタンス、MFDS、および ESCWA) は、セキュリティ ドメインと呼ばれることもあります。

ESCWA では、エンタープライズ サーバー インスタンスのセキュリティ構成は、デフォルト構成を使用するかどうかに応じて、リージョンの [Security Facility Configuration] ページまたは [Default ES Configuration] ページで指定します。ESCWA での MFDS セキュリティの構成については、MFDS インスタンスの [Security] メニューに [Directory Server Configuration] ページがあります。ESCWA のセキュリティ自体は、メニュー バーのスパナー アイコン () からアクセスできる [Security Settings] ページを使用して構成します。

各セキュリティ構成には、セキュリティ マネージャーのリストが含まれます。セキュリティ マネージャーは、ESF に対する外部セキュリティ マネージャー (ESM) を定義します。これには、ESM へのインターフェイスを提供する ESM モジュールの名前、および通常は接続情報と処理オプションが含まれます。ESCWA では、MFDS インスタンスの [Security Managers] ページでセキュリティ マネージャーを指定します。セキュリティ マネージャーはいくつでも指定できます。セキュリティ構成のリストにセキュリティ マネージャーが複数ある場合、それらのマネージャーは、各セキュリティ クエリを処理するために、リストに示されている順序で通常は呼び出されます (ただし、どのマネージャーが使用されるかに影響を与えるオプションもあります)。

64/32 ビットのセキュリティ マネージャー

セキュリティ マネージャーを使用するセキュリティ ドメインに対応する、適切なビット体系が必要になります。エンタープライズ サーバー リージョンが 64 ビットのリージョンである場合、64 ビットのセキュリティ マネージャーが必要です。同様に、MFDS に使用されるセキュリティ マネージャーは、MFDS と同じビット体系である必要があります。

MFDS とエンタープライズ サーバー リージョンのビット体系が異なる場合は、同じセキュリティ マネージャーを使用できない可能性があります。同じ外部セキュリティ マネージャー (LDAP リポジトリなど) を使用できますが、2 つの別個のセキュリティ マネージャー定義が必要になる場合があります。この場合、基本的には同じ構成の詳細を使用しますが、ビット数に固有の構成項目については異なる設定になります。

たとえば、MLDAP ESM モジュールには、LDAP クライアント ライブラリを指定するオプションのプロバイダー構成設定があります。これには、適切なビット数のライブラリを指定する必要があります。詳細は、システム管理者によるプラットフォームおよびインストール環境に関する決定によって異なりますが、次のようになります。

32 ビットのエンタープライズ サーバー リージョンおよび MFDS (64 ビット専用のプラットフォームを除き、通常は 32 ビット) 向けのセキュリティ マネージャーの場合:

[LDAP]
provider=/usr/lib/libldap_r-2.4.so.2.7.1

64 ビット リージョン向けのセキュリティ マネージャーの場合:

[LDAP]
provider=/usr/lib64/libldap_r-2.4.so.2.7.1

この 2 つの違いは、共有オブジェクトの場所 (/usr/lib/usr/lib64) です。

注: Enterprise Server の最近のリリースでは、MLDAP ESM モジュールは、通常のインストール場所で一般的に使用される LDAP ライブラリを見つけるロジックが改善されているため、多くの場合はプロバイダー設定を必要としません。

ESM モジュールは、セキュリティ マネージャーに対して適切なビット数である必要があります。Enterprise Server に付属の標準 ESM モジュールのいずれかを使用しており、パスや拡張子なしでベース名 (mldap_esm など) のみを使用してセキュリティ マネージャー定義で指定している場合は、適切なビット数のモジュールが ESF によって自動的に選択されます。セキュリティ マネージャーでモジュールのパスまたは拡張子を指定している場合は、その特定のファイルのみが使用されるため、32 ビットおよび 64 ビットのセキュリティ マネージャー定義を別々に用意する必要があります。

セキュリティ マネージャーの構成

セキュリティ マネージャーの強化に関する推奨事項は、使用する ESM モジュールによって異なります。各標準 ESM モジュールについては、以下にリストされているサブトピックを参照してください。

セキュリティ構成オプション

セキュリティ構成の各ページ ([Default ES Security]、特定のリージョンの [Security]、[Directory Server Configuration]、ESCWA の [Security Settings]) には、ESF を構成するためのオプションが用意されています。MFDS の [Directory Server Configuration] および ESCWA の [Security Settings] ページには、これらのコンポーネントに固有のオプションもあります。

強化に関連する ESF オプションには、次のものがあります。

[Allow unknown users]
このオプションは通常、特定のテスト状況でのみ有効にする必要があります。有効にした場合、認識されていないユーザー ID および任意のパスワードを使用して、誰でもシステムにサインオンできるようになります。
[Allow unknown resources]
セキュリティが懸念される場合、このオプションは有効にしないでください。このオプションは、認識されていない任意のリソースの使用を許可します。たとえば、攻撃者が Enterprise Server アプリケーションを介してシステム ファイルにアクセスする可能性があります。これは主に、開発者が独自のテスト用のインストール環境を使用しており、セキュリティ ルールの初期セットを段階的に導入する場合に役立ちます。
[Verify against all Security Managers]
通常、ユーザー認証 (Verify 操作) は、明確な結果 (サインオンの許可または拒否) を返す最初のセキュリティ マネージャーによって決定されます。このオプションが有効になっている場合、いずれかのセキュリティ マネージャーが拒否の結果を返すか、すべてのマネージャーが許可または不明を返すまで ([Allow unknown users] も有効になっている場合を除き、少なくとも 1 つのマネージャーが許可を返すことが必要)、すべてのマネージャーが参照されます。実質的に、このオプションにより、各セキュリティ マネージャーはユーザー認証を拒否する権限を持つことになります。これは、一部のセキュリティ構成で適切となる場合があります。特に、セキュリティ マネージャーが特定の状況 (時刻など) で特定のユーザーを拒否するように特別に構成されている場合に役立ちます。
[Create audit events]
監査により、侵害が見つかった場合や侵害が疑われる場合に監査証跡をフォレンジック分析に利用できるようになるため、セキュリティが向上します。また、監査情報をリアルタイムまたは定期的に処理して、疑わしいアクティビティをチェックしたり、機密性の高いリソースを重点的に監視したりすることもできます。このオプションを有効にする場合は、Micro Focus Audit API を構成し、syslogd などのセキュリティ情報およびイベント管理 (SIEM) を使用するか、Micro Focus Sentinel または ArcSight 製品を使用して、監査データを受信および処理する必要があります。
[Use all groups]
このオプションは、どちらの設定でもセキュリティが向上するとは限りませんが、組織によっては、ユーザーが選択したサインオン グループに基づいて特定のロールをユーザーに付与できるように、無効にする場合があります。たとえば、ユーザーが「アプリケーション」ロールと「管理」ロールの両方を持ち、それぞれに異なるリソース権限があり、サインオン時に指定したグループによってロールを選択する場合があります。また、Windows や UNIX と同様にシステムが動作するように、このオプションを有効にする組織もあります。
[Cache TTL] および [Cache limit]
これらのオプションは、ESF キャッシュを無効にするか (一方がゼロに設定されている場合)、有効にします (両方ともゼロ以外の場合)。組織の脅威モデルおよびセキュリティ体制によっては、キャッシュを無効にすると、ESM が保持するセキュリティ情報に変更が加えられた際に ESF が古い結果を使用するのを防止できるため、セキュリティ上の利点が得られる場合があります。ほとんどの組織では、パフォーマンスを向上させるためにキャッシュ機能が役立ちます。ただし、古いセキュリティ結果に対する許容度を決定し、[Cache TTL] を適切に設定する必要があります。たとえば、60 に設定すると、1 分以上経過した結果はキャッシュから返されなくなります。また、ESF Update メカニズムを使用してキャッシュをフラッシュすることもできます。
構成テキスト:グループ フェデレーション
グループ フェデレーション メカニズムは、構成テキスト フィールドで、次の設定を使用して有効にすることができます。
[Operation]
Federate=yes
注: セクション名およびキーワードでは、大文字と小文字は区別されません。
グループ フェデレーションは、複数のセキュリティ マネージャーを使用している場合にのみ適用されます。

グループ フェデレーションが有効な場合、セキュリティ ドメイン (エンタープライズ サーバー リージョン、MFDS、または ESCWA) のすべてのセキュリティ マネージャーで 1 つのユーザー グループ リストが共有されます。各セキュリティ マネージャーは、必要に応じてグループをリストに追加できます。また、あるセキュリティ マネージャーのアクセス制御ルールで、他のセキュリティ マネージャーで定義されたグループを参照することもできます。Federate=no によってフェデレーションが明示的に無効になっている場合、各セキュリティ マネージャーは独自のグループ リストを使用して、どのユーザーがどのグループに属しているかを把握します。フェデレーション設定で no が指定されている場合、セキュリティ マネージャーは下位互換性モードで動作しますが、複雑さが増して望ましくない影響が生じる可能性があります。

各セキュリティ マネージャーで個別のグループ情報を保持する必要がある明確な理由がない限り、グループ フェデレーションを有効にすることをお勧めします。

構成テキスト:冗長モード
冗長モードは、可用性が重要で、すべてのセキュリティ情報を単一のセキュリティ マネージャーに配置できる場合に適したオプションです。冗長モードでは、セキュリティ マネージャーは、セキュリティに関する決定を行うための個別のソースではなくなります。代わりに、最初のセキュリティ マネージャーだけが使用され、失敗した場合には、2 番目のマネージャーが使用されます (以下、同様です)。したがって、冗長モードでは、一貫性を保つために、セキュリティに関する決定を行う方法がすべてのセキュリティ マネージャーで同じである必要があります。冗長モードには、グループ フェデレーションも必要です。
冗長モードに適用される設定は次のとおりです。
[Operation]
redundant=yes
failover retry interval=time
failover retry interval 設定は、失敗した ESM を再試行するかどうか、また再試行する場合はその頻度を決定します。この設定の適切な値は、実際の要件によって異なります。詳細については、製品ヘルプを参照してください。
構成テキスト:Verify 調整
Verify 調整は、特定の時間間隔でプロセスが受信した Verify (認証) 要求が多すぎる場合に処理を遅くして、ユーザー資格情報のブルート フォースを防止するのに役立ちます。デフォルトでは、1 秒間に 100 を超える Verify 要求を受信した場合にこの機能がトリガーされます。[Operation] verify throttle threshhold 設定を使用して、しきい値を変更するか、調整を完全に無効にすることができます。調整を有効にしておくようお勧めしますが、ワークロードによってトリガーされる場合は、しきい値の調整が必要になることがあります。
構成テキスト:ESF キャッシュ オプション
前述のキャッシュ サイズおよび TTL パラメーターに加えて、追加のキャッシュ オプションを構成テキストで設定できます。
[Cache]
requests=types of requests to cache
flush on change=yes|no
report interval=time in seconds
ignore=request fields to ignore in comparison
これらのオプションについては、製品ヘルプで詳しく説明されていますが、概要を次に示します。
  • requests は、キャッシュ可能な ESF 要求のタイプを設定します。デフォルトでは、承認要求はキャッシュされますが、認証要求はキャッシュされないため、各ユーザー認証は ESM によって処理されます。
  • flush on change が有効になっている場合、要求の結果が変わると、その要求に関してキャッシュされている既存の情報がすべて削除されます。これは、認証 (Verify) キャッシュが有効になっていて、ESM でアカウント ロックアウトを実装している場合に役立ちます。詳細については、製品ヘルプを参照してください。
  • ignore 設定で指定した要求フィールドのリストは、受信要求をキャッシュ内のエントリと比較する際に無視されます。この設定を使用して、セキュリティ上重要ではないと考えられるフィールドを無視すると、キャッシュのパフォーマンスが向上する可能性があります。デフォルトでは、subsystem フィールドおよび facility フィールドは無視されます。

セキュリティを最大限に高めるためにデフォルトのキャッシュ オプションを使用し、必要に応じてパフォーマンスのために変更することをお勧めします。Verify キャッシュが有効になっている場合は、flush on change を有効にすることをお勧めします。

構成テキスト:監査オプション
監査のオプションは、監査が有効になっている場合にのみ適用されます。監査オプションは次のとおりです。
password change success
パスワードの変更が成功した場合に監査イベントを生成するかどうかを制御します。
category 3 events
ESF の呼び出しに対して監査イベントを生成するかどうか、およびそれらの呼び出しの結果を制御します。カテゴリ 3 のイベントは大部分が冗長であるため、必要に応じてそれらを抑制できます。
selective
選択的監査を有効にします。選択的モードでは、監査イベントは、ユーザー、グループ、およびリソース アクセス ルールの追加の LDAP 属性によって制御されます。MLDAP ESM モジュールのみが選択的監査機能を提供します。選択的監査は、機密性の高い特定のセキュリティ オブジェクトに適用される ESF 要求に対してのみ監査イベントを生成する必要がある場合に役立ちます。この機能を使用するには、目的とするオブジェクトの属性を適切に設定するために、追加の管理作業が必要になります。

これらのオプションに関する具体的な推奨事項はありません。適切な使用方法は、実際の要件によって異なります。

構成テキスト:その他のオプション
構成テキストのその他の設定は、次の項目に影響します。
  • ESF ユーザー出口 (user exit)
  • ESF 管理機能 (allow-list)
  • ユーザー名のマッピング (map short names)
  • Update 処理 (update interval)
  • 要求の文字フィールドからの空白の除去 (trim whitespace)
  • パストークン (allow)

詳細については、製品ヘルプを参照してください。