ステップ 1: 一般情報の構成

ポリシーを定義する前に、ポリシー・エージェントの基本的な操作上の特性を構成する必要があります。

手順

以下のステップに従って、これらの特性を構成します。

  1. TZ および LIBPATH の環境変数を設定します。 TZ 環境変数を使用して正しい時間帯を指定します。ポリシー・エージェントを開始するときに、必要なダイナミック・リンク・ライブラリー (DLL) ファイルを検索できるようにするため、LIBPATH 環境変数を使用します。これらの環境変数の指定方法について詳しくは、ポリシー・エージェントの開始と停止を参照してください。また、SEZAINST(EZAPAGSP) の中に同梱されているサンプル・スタート・プロシージャーのコメントも参照できます。
  2. メインの構成ファイルの名前を指定します。 メインの構成ファイルの名前は、次の方法を使用すると指定できます。
    • -c 始動オプション
    • PAGENT_CONFIG_FILE 環境変数
    • デフォルト・ファイル名 /etc/pagent.conf

    メインの構成ファイルを見つけるためにポリシー・エージェントで使用する検索順序、およびメインの構成ファイル名を指定するさまざまな方法の例について詳しくは、ポリシー・エージェントの開始と停止を参照してください。また、SEZAINST(EZAPAGSP) の中に同梱されているサンプル・スタート・プロシージャーのコメントも参照できます。

  3. メインのポリシー・エージェント構成ファイル内に、TcpImage または PEPInstance ステートメントを定義します。 PEPInstance ステートメントは、TcpImage の同義語で、 いずれも使用できます。 PEPInstance は、ポリシー強制ポイント (PEP)、つまりポリシーを強制するポリシー・システムのコンポーネント (z/OS® の場合は TCP/IP スタック) を参照します。
    結果:
    • メイン構成ファイルに用いるリフレッシュ・インターバルは、イメージ固有構成ファイルに指定する値の中で最小のものとなります。
    • メイン構成ファイルが MVS™ データ・セットである場合は、各リフレッシュ・インターバル (個々のスタック・リフレッシュ・インターバルのうち最小のもの) のたびに再読み取りされます。そのファイルが実際に変更されたかどうかは関係ありません。メイン構成ファイルが再読み取りされると、ポリシー・エージェントはスタック関連のすべての処理を再始動するため、実際は、これによって、すべてのスタックに対するリフレッシュ・インターバルが、この最も小さく構成されたインターバルと 同じになります。
    • TcpImage または PEPInstance ステートメントおよびそのすべてのパラメーターは、ポリシー・クライアントに対して定義されるポリシーには影響がありません。

    単一のポリシー・エージェントによって処理される 1 組のスタックに共通のポリシー・セットをインストールする場合は、イメージごとにイメージ固有構成ファイルを指定しないでください。この場合、存在する構成ファイルは 1 つ (メイン構成ファイル) だけであり、その中に入っているポリシー情報がすべての構成済みスタックにインストールされます。各イメージごとに異なるリフレッシュ・インターバルを構成することはできますが、この場合、おそらく有効性が低下します。

    いずれの場合であっても、ポリシー・エージェントに対して構成された TCP/IP スタックは開始されず、定義もされない可能性があります。そのようなスタックへの接続と、該当するエラー・メッセージの記録を試行すると、ポリシー・エージェントは失敗に終わります。

    規則: TCP/IP スタックを動的にポリシー・エージェント構成に追加し、アクティブなポリシーを自動的にインストールさせるには、TcpImage ステートメントを構成ファイルに追加するのに加えて、以下のように、さらにアクションが必要になる場合があります。
    • ポリシー・エージェントが -i 開始オプションを指定して開始された場合、それ以上のアクションは必要ありません。アクティブ・ポリシーは、 アクティブになる際に自動的にスタックにインストールされます。
    • ポリシー・エージェントが -i 開始オプションを指定して開始されなかった場合、以下のアクションを実行します。
      • スタックがアクティブになった後で、MODIFY REFRESH または MODIFY UPDATE コマンドを発行する。スタックがアクティブになる前に MODIFY REFRESH または MODIFY UPDATE コマンドを発行した場合は、ポリシーは自動的にはインストールされません。
      • 次の更新間隔を待ち、構成変更を確認する。 スタックがアクティブでない場合、ポリシーは自動的にはインストールされません。

    いずれかの (あるいはすべての) スタックが終了しても、ポリシー・エージェントは終了しません。スタックが再始動されると、自動的にアクティブ・ポリシーが再インストールされます。

    TcpImage ステートメントでは、TCP/IP イメージと、そのイメージにインストールする関連構成ファイルを指定します。次の例では、既存のポリシー制御データをフラッシュした後で、ポリシー制御ファイル /tmp/TCPCS.policy を TCPCS TCP/IP イメージ にインストールします。
    TcpImage TCPCS /tmp/TCPCS.policy FLUSH

    FLUSH、NOFLUSH、PURGE、および NOPURGE パラメーターについては、FLUSH および PURGE の考慮事項を参照してください。

  4. ログ・ファイルの宛先および適切なロギング・レベルを定義します。 ポリシー・エージェントのログ・メッセージを syslog デーモンまたは z/OS UNIX ファイルに書き込むように指定できます。 syslog デーモンを示すには、大文字で SYSLOGD を指定します。z/OS UNIX ファイルを示すには、ファイル名を指定します。ログ・ファイルの宛先を指定するには、-l 開始オプションまたは PAGENT_LOG_FILE 環境変数を使用します。あるいは、デフォルト値の /tmp/pagent.log を使用することもできます。
    ヒント: 集中ロギング・メカニズムを使用するには、SYSLOGD を指定します。
    結果: ポリシー・エージェントが開始オプションを読み取ることができない場合、ログ・ファイルの宛先がありません。そのため、ポリシー・エージェントが、z/OS UNIX ログ・ファイルを開くことができない可能性があります。この状態では、ポリシー・エージェントは、syslog デーモンにエラー・メッセージを記録し、異常終了します。
    ガイドライン: ポリシー・エージェントをゼロでない UID で実行し、z/OS UNIX ログ・ファイルを使用する場合、以下のガイドラインに従ってください。
    • ファイル許可を 776 または 766 のいずれかに指定します。
    • syslog デーモンが、同じ z/OS UNIX ファイルにログを記録するように構成されていないことを確認します。syslog デーモンは、UID 0 で実行されるため、syslog デーモンがポリシー・エージェントの開始前にログ・ファイルを作成した場合、ポリシー・エージェントはそのログ・ファイルにアクセスできない可能性があります。

    ポリシー・エージェントがログに記録する情報の量を定義する場合は、LogLevel ステートメントを使用します。 デフォルトはイベント、エラー、コンソール、および警告の各メッセージだけをログに 記録することです。これは、継続的なポリシー構成には適しますが、初めてポリシーを設定する場合や重要な変更を行う場合にポリシー処理やデバッグ上の問題を理解するためには、さらに詳しい情報が必要になります。メイン構成ファイルで適切なロギング・レベルを指定して LogLevel ステートメントを指定してください。

    注: ロギング・レベルを最大 (511) にすると、LDAP 構成が大きい場合は特に、大量の出力を生成する可能性があります。z/OS UNIX ログ・ファイルを使用する場合には、これを心配する必要はありません。ポリシー・エージェントはラウンドロビンの構成で有限サイズのログ・ファイルのセット (これらのファイルの数とサイズ は、PAGENT_LOG_FILE_CONTROL 環境変数を用いて制御することができます) を使用するためです。しかし、ログ・ファイルとして syslog デーモンを使用する場合には、生成されるログ出力の量を考慮に入れる必要があります。
  5. 以下のセキュリティー許可を提供します。 以下のセキュリティー許可が必要とされるのは、ポリシー・エージェントがシステムの動作に与える影響が大きいためです。
    • ポリシー・エージェントを開始するユーザーはスーパーユーザーでなければなりません。
    • ポリシー・エージェントを開始するには、セキュリティー製品権限 (例えば RACF(R)) が必要です。プロファイル名の作成、およびそのプロファイルに対するユーザーの許可に必要なコマンド例は、SEZAINST 内の EZARACF のサンプルを参照してください。
  6. ポリシー・エージェントの PAPI クライアント (pasearch コマンドを含む) がスーパーユーザーとして定義されていない場合に、ポリシーを検索するためには、そのクライアントの SERVAUTH クラス内でセキュリティー製品権限を定義する必要があります。 イメージ名をスーパーユーザーとして定義できない場合は、セキュリティー製品権限が常に必要です。リモート・ポリシー・クライアントは、ポリシー・サーバー上でスーパーユーザーとして決して定義されません。したがって、それらのクライアントにはセキュリティー製品権限が常に必要になります。これらのプロファイルは、イメージ名とポリシー・タイプ (ptype = QoS、IDS、IPSec、TTLS、または Routing) によって定義できます。プロファイル名には、ワイルドカードを使用できます。
    EZB.PAGENT.sysname.image.ptype
    ここで、
    • sysname: シスプレックス内で定義されているシステム名。
    • image - 要求されているポリシー情報の TCP 名、ポリシー・クライアント名、またはインポート要求名。
    • ptype - 要求されているタイプ (以下参照)。
      • QOS - ポリシー QoS
      • IDS - ポリシー IDS
      • IPSec - ポリシー IPSec
      • TTLS - ポリシー AT-TLS
      • Routing - ポリシー・ルーティング
      • CFGSERV - TCP/IP プロファイル情報

    インポート要求名について詳しくは、構成ファイルのインポート・サービスを参照してください。

    ヒント: プロファイル名のセグメントにワイルドカードを指定することができます。
    規則:
    • ポリシー・クライアントを使用する場合は、ポリシー・サーバー上のプロファイル名のイメージ部分がポリシー・クライアントの名前と一致しているか、その名前を含んでいる必要があります。それぞれのポリシー・クライアント名を構成するには、PolicyServer ステートメントの ClientName パラメーターを使用するか、ClientName パラメーターのデフォルト値を使用します。PolicyServer ステートメントでのクライアント名の指定については、「z/OS Communications Server: IP 構成解説書」を参照してください。
    • インポート・リクエスターを使用する場合は、ポリシー・サーバー上のプロファイル名のイメージ部分がインポート要求名と一致しているか、その名前を含んでいる必要があります。インポート・リクエスターとして IBM® Configuration Assistant for z/OS Communications Server を使用している場合は、「Import Policy Data」パネルまたはディスカバリー・インポートの要求パネルでインポート要求名を構成してください。インポート要求名については、構成ファイルのインポート・サービスを参照してください。

    ポリシー・エージェントはクライアントのすべての要求を検査して、SERVAUTH クラスがアクティブであり、要求内のイメージおよびタイプにプロファイルが存在することを検証します。

    クライアントの要求が複数のイメージまたはポリシー・タイプに対するものであり、要求されるものの一部に対する許可のみが付与されている場合、ポリシー・エージェントは、許可されている部分の情報のみを戻します。しかし、単一イメージまたはポリシー・タイプのみが要求される場合のインスタンスを含めて、要求全体の許可が拒否される場合は、クライアントにエラーが戻され、その許可が拒否されていることを示します。

    SERVAUTH クラスがアクティブでないか、クライアントの要求 (イメージ、ポリシー・タイプ) に対してプロファイルがアクティブでない場合、クライアントにエラーが戻され、許可が拒否されていることを示します。

    プロファイル名を作成し、それをユーザーに許可するために必要なコマンドのサンプルについては、SEZAINST 内の EZARACF サンプルを参照してください。

親トピック: ポリシー・エージェントを構成するためのステップ