ユーザーロールファイアウォールセキュリティポリシー

ローカル認証テーブル

ローカル認証テーブルは、エントリを挿入または削除する CLI コマンドで管理されます。ローカル認証テーブルは、動的 UIT が使用できない場合のバックアップ ソリューションとして、またはプリンターやファイル サーバーなど、ネットワークに対して認証できないデバイスにユーザーおよびロール情報を割り当てるために使用できます。ローカル認証テーブルを使用して、ファイアウォール認証またはアクセス コントロール サービスを構成せずにユーザー ロール ファイアウォールがどのように機能するかをテストしたり、デモンストレーションしたりできます。

サードパーティの認証ソースからIPアドレス、ユーザー名、およびロールをダウンロードして、CLIコマンドを使用してプログラムでローカル認証テーブルに追加できます。認証ソースでユーザーとグループが定義されている場合、グループをロールとして構成し、通常どおりユーザーに関連付けることができます。

UAC 認証テーブルに準拠するために、ユーザー名は 65 文字に制限され、ロール名は 64 文字に制限されています。ローカル認証テーブルには、インストールされたJunos OSリリースに応じて、SRX1500デバイス以上で最大10,240認証エントリ、SRX650デバイスで最大5120認証エントリがあります。ローカル認証テーブルには、vSRX 仮想ファイアウォールに関する 5120 個の認証エントリがあります。各認証エントリは、最大 200 個のロールに関連付けることができます。最大容量は、各ユーザーに割り当てられた平均 10 個のロールに基づきます。これは、UAC 認証テーブルに指定された容量と同じです。

次のコマンドを使用して、ローカル認証テーブルにエントリを追加します。各エントリは IP アドレスによってキーが付けられることに注意してください。

1 つの CLI コマンドの role オプションは、最大 40 個のロールを受け入れます。40 を超えるロールを 1 人のユーザーに関連付けるには、複数のコマンドを入力する必要があります。認証、ユーザー、およびロールのエントリを追加または変更するときは、次の特性に注意してください。

• ロール名をユーザー名と同じにすることはできません。

• add既存の IP アドレスとユーザー名で オプションを使用すると、ロール エントリが集約されます。このテーブルでは、ユーザーごとに最大 200 個のロールをサポートできます。

• add既存のIPアドレスと新しいユーザー名で オプションを使用すると、そのIPアドレスの既存のユーザー名が上書きされます。

• ロールの集約は、既存のセッションには影響しません。

• 既存のエントリのロール リストを変更するには、既存のエントリを削除し、新しいロール リストを含むエントリを追加する必要があります。

• 既存のエントリの IP アドレスを変更するには、既存のエントリを削除し、新しい IP アドレスでエントリを追加する必要があります。

エントリは、IP アドレスまたはユーザー名で削除できます。

ローカル認証テーブルは、次のコマンドでクリアできます。

ローカル認証テーブルの内容を表示するには、次のコマンド show... を使用します。

オプション(デフォルト)は brief 、IPアドレス順に表形式で情報を表示します。ユーザー名とロール リストは、形式に合わせて切り捨てられます。

オプションには extensive 、各フィールドの完全な内容が表示されます。その他のオプションでは、表示が 1 つのユーザー名、IP アドレス、またはロールに制限されます。

UAC 認証テーブル

SRXシリーズファイアウォールは、Junos Pulseアクセスコントロールサービスのエンフォーサーとして機能します。この実装では、SRXシリーズファイアウォールがレイヤー3の適用ポイントとして機能し、アクセス制御サービスからプッシュダウンされたIPベースのリソースポリシーでリソースへのアクセスを制御します。

ユーザーロールファイアウォールとして実装された場合、SRXシリーズファイアウォールは、ユーザーロールを取得するために同様の方法でUACネットワークにアクセスできます。この場合、認証されたすべてのユーザーのユーザーとロールの情報がアクセス制御サービスからプッシュされます。

SRXシリーズのファイアウォールの構成は、エンフォーサーの構成と似ています。通信を確立するには、両方のデバイスが他方を認識するための構成とパスワード設定が必要です。SRXシリーズファイアウォールから、アクセスコントロールサービスをインフラネットコントローラとして接続します。

アクセスコントロールサービスから、SRXシリーズファイアウォールを新しいエンフォーサーとして定義します。SRXシリーズファイアウォールで指定されているものと同じパスワードを使用します。

ユーザーとパスワードは、標準の認証構成と同様にアクセス制御サービスで定義されます。1 つ以上のロールをユーザーに関連付けることもできます。ユーザーが認証されると、IP アドレス、ユーザー名、および関連付けられたロールを含むエントリが、アクセス制御サービスの UAC 認証テーブルに追加されます。

UAC認証テーブルは、2つのデバイス間の接続が初期化されるときに、アクセスコントロールサービスからSRXシリーズファイアウォールにプッシュされます。アクセスコントロールサービスでエントリーが追加、削除、または更新されるたびに、更新されたUAC認証テーブルがSRXシリーズファイアウォールにプッシュされます。

リソースアクセスポリシーは、ユーザーロールファイアウォール実装のアクセス制御サービスには必要ありません。アクセス動作は、SRXシリーズファイアウォールのポリシー設定で提供されます。リソースアクセスポリシーがアクセス制御サービスで定義されている場合、それらはSRXシリーズファイアウォールにプッシュされますが、特定のファイアウォールポリシーがポリシーのアクションフィールドにUACポリシーを実装しない限り、使用されません。

次のコマンド show services は、SRXシリーズファイアウォール上のUAC認証テーブルの内容を表示し、テーブルがアクセスコントロールサービスから正常にプッシュされたことを確認します。

SRXシリーズファイアウォールは接続を監視し、アクセス制御サービスへの通信が失われたかどうかを検出します。UAC設定に基づいて、SRXシリーズファイアウォールは、別のリクエストを発行する前に、設定された間隔で応答を待ちます。応答を受信した場合、アクセス制御サービスは機能していると見なされます。指定したタイムアウト期間が経過しても応答が受信されない場合、通信は失われたと見なされ、タイムアウト・アクションが適用されます。次の UAC コマンド構文は、間隔、タイムアウト、およびタイムアウト アクションを構成します。

切断中に、切断されたデバイスに対してユーザーとロールの検索を試みると、タイムアウトアクションに関係なく失敗コードが返されます。すべての認証ソースへのアクセスが失われると、キーワード unknown-user が IP アドレスに関連付けられます。ポリシールックアップが再開されると、送信元IDがunknown-userのポリシーがトラフィックに一致します。不明なユーザーに対する特定のポリシーを実装することで、認証ソースの損失を処理する方法を作成できます。

ファイアウォール認証テーブル

ファイアウォール認証では、ゾーンとデバイス間のアクセスを許可する前に、SRXファイアウォールに対する認証が必要です。トラフィックを受信すると、ユーザーはユーザー名とパスワードの入力を求められ、有効なユーザーの指定されたプロファイルに対して検証されます。ファイアウォール認証は、デバイスの設定に応じて、telnet、HTTP、HTTPS(SRX5800、SRX5600、およびSRX5400デバイスの場合)、およびFTPトラフィックがローカルまたはRADIUS、LDAP、またはSecureID認証サーバーによって認証されていることを確認します。

デバイスでファイアウォール認証が使用されている場合、認証プロセスでは、ユーザー ロールのファイアウォール一致条件に必要なユーザー名とロール情報も提供されます。この場合、情報はファイアウォール認証テーブルと呼ばれる UIT で収集および維持されます。階層内の 1 つ以上のアクセス ポリシーが、 edit access ファイアウォール認証に使用する認証方法を定義します。

ファイアウォール認証テーブルは、ユーザーロール情報取得の認証ソースとして有効にする必要があります。このオプションは priority 、すべての UT がチェックされる順序を指定します。

特定のゾーンペアのファイアウォールポリシーでは、アクションにpermit指定されたサービスが一致するfirewall-authenticationトラフィックの認証を開始します。認証の種類によってuser-firewall、認証されたユーザーの UIT エントリが生成されます。オプションで指定されたaccess-profile名前は、有効なユーザーの認証に使用するプロファイルを識別します。

UITテーブルエントリには、認証されたユーザーとユーザーの関連グループにマッピングされたトラフィックのIPアドレスが含まれています。ユーザーがアクティブでなくなると、エントリはテーブルから削除されます。トラフィックや認証済みユーザーの変化に応じてエントリーが継続的に追加および削除されるため、ファイアウォール認証テーブルは動的と見なされます。

同じゾーンペア内のポリシーが一致条件の一部としてフィールドを指定する source-identity と、有効なすべてのUITでトラフィックのIPアドレスに対応するエントリが検索されます。見つかった場合、関連付けられたユーザ名とグループが取得され、送信元と ID が照合されます。(ユーザー認証グループ名は、ソースと ID の照合ではロール名と見なされます)。

ユーザーとロールを使用したポリシーのプロビジョニング

SRXシリーズファイアウォールまたはアクセスコントロールサービスで定義されているかどうかにかかわらず、すべてのユーザーとロールは、SRXシリーズファイアウォールのユーザーロールファイルに保持されます。プロビジョニングに使用できるすべてのユーザーとロールを表示するには、次のコマンド show security... を使用します。

メモ：

ファイアウォール認証テーブルのユーザー名とロールは、以下の表示には含まれていません。

• プロビジョニングに使用できるすべてのロールを表示するには、 コマンドを使用します show security user-identification role-provision all 。すべての UT のロールが一緒に一覧表示されていることに注意してください。

• プロビジョニングに使用できるすべてのユーザーを表示するには、 コマンドを使用します show security user-identification user-provision all 。

• プロビジョニングに使用できるすべてのユーザーとロールを表示するには、 コマンドを使用します show security user-identification source-identity-provision all 。

ポリシー構成がコミットされると、ユーザー ロール ファイルがチェックされ、ポリシーで指定されたすべてのユーザーとロールがプロビジョニングに使用できるかどうかが確認されます。ユーザーまたはロールが見つからない場合は、後で定義できるように、不足しているユーザーまたはロールが識別される警告が表示されます。

メモ：

ポリシーは、ユーザーまたはロールがまだ定義されていない場合でもコミットされます。