アイデンティティ認識型ファイアウォール

アイデンティティソースはファイアウォールレベルでどのように展開されますか。

ファイアウォールは、アクティブディレクトリ、Juniper® Identity Management Service(JIMS)、Aruba ClearPass、統合型アクセス制御(UAC)などのさまざまなアイデンティティソースからユーザー情報を取得します。ネットワーク管理者は、ユーザ情報を取得した後、アイデンティティ ソースからデータを受信するようにデバイスを展開できます。

先端：

このガイドでは、 ジュ ニパーネットワーク®スのSRXシリーズファイアウォールまたはジュニパーネットワーク®スのvSRX仮想ファイアウォール(vSRX3.0)、またはジュニパーネットワーク®スのcSRXコンテナファイアウォールまたはジュニパーネットワーク®スのNFXシリーズネットワークサービスプラットフォーム(NFXシリーズ)デバイスを指すものとして、ファイアウォールを使用します。

ファイアウォールは、IPアドレスではなくユーザーIDに基づいてファイアウォールルールを作成、管理、および再定義できます。ファイアウォールは、JIMSにクエリーを実行し、正しいユーザーID情報を取得してから、適切なセキュリティポリシーの決定を実施して、保護された企業リソースとインターネットへのアクセスを許可または拒否することができます。

アイデンティティ・ソース・プロセスに関与する各コンポーネントには、独自のセキュリティ・インフラストラクチャがあり、保護されたリソースへのアクセスを制御する認可ポリシーが管理上定義されます。次の表では、これらのコンポーネントの役割と、コンポーネントの相互通信方法について説明します。

表 1:ファイアウォール レベルでの ID の展開

展開モード	アイデンティティ ソース	展開モードの詳細
アイデンティティ ソースとしての Active Directory	Active Directory	シンプルな構成や、ファイアウォールの外側にある ID マネージャーは必要ありません。
Identity ManagerとしてのJuniper® Identity Management Service(JIMS)	Active Directory	より高い拡張性と導入の柔軟性。
	Microsoft Azure	ファイアウォールは、Azure で構成されたユーザー ID をサポートできます。
	Okuta	ファイアウォールは、JIMSを使用してOktaで構成されたユーザーIDをサポートできます。
	サードパーティ製のSyslogジェネレータ	JIMSは、ユーザー情報を取得するために、さまざまなサードパーティソースを通じて生成されたsyslog情報を収集できます。
アイデンティティソースとしてのAruba ClearPass	Aruba ClearPass	ファイアウォールは、Aruba ClearPassからユーザー情報を取得できます。
アイデンティティソースとしての統合型アクセス コントロール	UACの	ファイアウォールは、UAC で構成されているユーザー情報を取得できます。
SRXファイアウォールユーザー	ファイアウォール ユーザー	ユーザー情報は、ファイアウォール認証で設定することができ、ローカルサーバー、またはLDAPやRADIUSサーバーなどの外部サーバーで管理することができます。

アイデンティティソースとIdentity Managerの役割

Identity Source	アイデンティティ・ソースは、ユーザーまたはデバイス情報、ロールを管理し、ユーザー・イベントを維持できます。
Identity Manager	JIMSは、高度なユーザーID管理システムです。 JIMS は、ファイアウォールに代わって、図 1 に示すさまざまな ID ソースに接続し、通信します。

表2:Identity Aware Firewallコンポーネントの説明

展開モード	形容	導入のメリット
アイデンティティ ソースとしての Active Directory	アイデンティティ ソースとしての Active Directory は、ドメイン コントローラのイベント ログを読み取り、ドメイン PC をプローブし、構成された Windows ドメイン内のライトウェイト ディレクトリ アクセス プロトコル (LDAP) サービスを照会することで、認証用のユーザーおよびグループの情報を収集します。	一元管理: 組織内のユーザーとグループの管理を一元化し、管理を簡素化します。 有効な認証: ユーザーとコンピュータの身元を確認し、ネットワークセキュリティを強化します。 ポリシーの適用: 管理者は、グループポリシーオブジェクト(GPO)を使用してセキュリティポリシーを適用できます。 依存 関係： Active Directory インフラストラクチャに依存しています。組織によっては、このインフラストラクチャを好まない場合もあります。
Juniper® Identity Management Service(JIMS)	Juniper® Identity Management Service(JIMS)は、スタンドアロンのWindowsサービスアプリケーションで、アイデンティティソースドメインまたはsyslogソースからユーザー、デバイス、グループ情報の大規模なデータベースを収集して維持します。 詳細については、 SRXシリーズファイアウォールを使用したJIMSを参照してください。	効率的な管理: ユーザー名、デバイス、IPアドレス間の関連付けを自動化することで、エンドユーザーエクスペリエンスを簡素化します。 負荷軽減: ID管理とファイアウォール間のミドルウェアとして機能することで、ID管理システムの負荷を軽減します。 アクセス制御: グループメンバーシップに基づくポリシー制御、セキュリティの強化、およびアクセス制限を可能にします。 依存 関係： スタンドアロンのWindowsサービスに依存しているため、障害点が追加されたり、Windows環境に依存したりする可能性があります。
アイデンティティソースとしてのAruba ClearPass	ファイアウォールとAruba ClearPassが連携して、ネットワーク・リソースを保護します。これらのデバイスは、インターネットへのユーザー アクセスを制御し、ユーザー名またはネットワーク リソースが属するグループに基づくユーザー ID レベルでセキュリティを適用します。	ポリシー管理: 新しいデバイスのオンボーディングや、役割やデバイスタイプに基づくアクセス制御のポリシー管理を容易にします。 きめ細かなアクセス制御: ユーザーの役割に基づいてアクセスレベルを付与し、セキュリティとコンプライアンスを強化します。 依存 関係： アイデンティティ・ソースはAruba ClearPassと統合する必要があり、追加の構成とセットアップが必要になる場合があります。
アイデンティティソースとしてのUAC(Unified Access Control)	統合アクセス制御 (UAC) は、IC シリーズ UAC アプライアンス、イントラネット Enforcer、Infranet エージェントを使用して、有効なユーザーのみがリソースにアクセスできるようにすることでネットワークを保護します。ICシリーズアプライアンスは、認証情報とポリシールールを使用して、ネットワーク上の個々のリソースへのアクセスを提供するかどうかを決定する、ネットワーク内のポリシー決定ポイントです。	簡略化された構成: ユーザー情報、グループ、ポリシールールを一元的に作成することで、設定を簡素化します。 セキュリティの適用: 有効なユーザーのみがIPベースのポリシーを通じてネットワークリソースにアクセスできるようにします。 依存 関係： ICシリーズUACアプライアンス、イントラネットエンフォーサー、およびインフラネットエージェントの展開が必要です。これにより、ネットワークがより複雑になる可能性があります。

アイデンティティ認識型ファイアウォールコンポーネントの選択

お客様は通常、特定の組織のニーズ、既存のインフラストラクチャ、およびセキュリティ要件に基づいて、アイデンティティ認識型のファイアウォールコンポーネントを選択します。

アイデンティティのソース

表 1 で説明するように、ファイアウォールを ID ソースまたは Identity Manager の 1 つに接続する必要があります。

スケーリング

拡張要件が高い導入には、Juniper Identity Management Serviceをお勧めします。

アイデンティティ認識型ファイアウォールのコンポーネントを選択する前に、統合とメンテナンス要件の複雑さを評価して、組織の目標とセキュリティ要件に合致することを確認します。

認証テーブルとは

認証テーブルには、認証ソースとして機能するIPアドレス、ユーザー名、およびグループのマッピング情報が含まれています。

認証テーブルはどのように実装されていますか?

認証テーブル内のユーザーおよびグループのマッピング情報は、ユーザー ID 情報によって取得されます。JIMS がデプロイされると、認証テーブルは IP クエリまたはバッチ クエリを使用して取得されます。

テーブルで取得された情報は、デバイスのルーティングエンジンで生成され、認証テーブルがパケット転送エンジンにプッシュされます。セキュリティポリシーは、テーブルの情報を使用してユーザーを認証し、ファイアウォールを通過するトラフィックのアクセス制御を提供します。

Windows Active Directory 環境で Active Directory をアイデンティティ ソース情報の取得として有効にするには、アクティブ ディレクトリ認証テーブルを設定する必要があります。 SRXシリーズファイアウォールでActive Directoryをアイデンティティソースとして設定するを参照してください。

priority オプションは、ユーザー情報テーブルをチェックする順序を指定します。アイデンティティ・ソースに最も低い設定を使用すると、最高の優先度が指定され、Active Directory認証ソースが最初に検索されます。詳細については、アイデンティティ ソース認証テーブルとしての Active Directory および ClearPass 認証テーブルを参照してください。

認証テーブルはどのように管理されますか?

Windowsドメイン環境は、ユーザーがネットワークにログインおよびログアウトしたり、ネットワーク管理者がユーザーグループ情報を変更したりするたびに、絶えず変化しています。アイデンティティ・ソースは、Windowsドメインの変更を管理し、定期的に更新します。認証テーブルも更新され、リストされたすべてのユーザーの最新の関連グループ情報が反映されます。

また、イベントログの読み取り中に生じた変化や、イベントログ情報が失われた場合に対応するためのプローブ機能も備えています。オンデマンドプローブは、クライアントトラフィックがファイアウォールに到着したが、そのクライアントの送信元IPアドレスがテーブルで見つからない場合にトリガーされます。また、特定のIPアドレスをプローブするために、いつでも手動プローブを利用できます。

「 ドメイン PC プローブ」を参照してください。

アイデンティティ ソース認証テーブル エントリの状態情報

アイデンティティ ソース認証テーブルのエントリは、次の 4 つの状態のいずれかになります。

Initial	IP アドレスからユーザーへのマッピング情報がドメイン コントローラーのイベント ログを読み取ることによって取得され、エントリが認証テーブルに追加されたことを指定します。この状態のエントリーは、テーブルがルーティングエンジンからパケット転送エンジンにプッシュされると、有効なものに変更されます。
Valid	ドメイン コントローラー イベント ログの読み取りによって有効なエントリが取得されたこと、またはドメイン PC プローブから有効な応答が受信され、ユーザーが有効なドメイン ユーザーであることを指定します。
Invalid	ドメイン PC プローブから無効な応答を受信し、ユーザーが無効なドメイン ユーザーであることを指定します。
Pending	プローブ イベントによって認証テーブルにエントリが生成されましたが、ドメイン PC からプローブ応答が受信されていないことを示します。プローブ応答が 90 秒以内に受信されない場合、エントリはテーブルから削除されます。

タイムアウト設定

ユーザーがアクティブでなくなると、認証テーブル内のそのユーザーのエントリーに対してタイマーが開始されます。時間切れになると、ユーザーのエントリがテーブルから削除されます。テーブル内のエントリーは、エントリーに関連付けられたセッションがある限り、アクティブなままです。

オンデマンドプローブを無効にする場合は、タイムアウトを無効にして、再度ログインせずにインターネットにアクセスするのを防ぐことをお勧めします。

詳細については、 アイデンティティ ソースとしての Active Directory のタイムアウト設定 および ClearPass タイムアウト設定を参照してください。