Private Accessベストプラクティス

このセクションでは、Netskope Private Access (NPA) Publisherの復旧および移行作業を管理するための推奨されるベストプラクティスについて説明します。

展開された状態のパブリッシャーには、管理プレーンとは別に維持・保存する必要のある機密情報や永続的な情報は含まれていません。Netskopeテナントに接続するには、パブリッシャーは固有の登録コードを使用して登録する必要があります。

場合によっては、パブリッシャーを再構築または復旧する必要が生じる状況に直面することがあります。そうした状況には以下のようなものがある。

Publisherのアーキテクチャと構成の性質上、既存のPublisherイメージを復旧しようとするのは得策ではなく、新しいPublisherイメージをデプロイして、同じPublisher定義の下に登録する方が賢明です。 パブリッシャーへのアクセスに障害が発生したり、アクセスできなくなった場合は、以下の手順を実行することをお勧めします。

上記の手順を実行すると、新しいパブリッシャーは自動的に以前のパブリッシャーの役割と定義を引き継ぎ、以前のパブリッシャーに割り当てられていたアプリケーションの配信を開始します。

このセクションでは、プライベート アプリ セグメントのアプリ定義でパブリッシャー DNS 機能を適切に使用する方法について説明します。 まず、この機能をオフにした場合のNPAの動作について改めて確認してみましょう。

プライベートアプリセグメントで宛先を定義し、ポリシーを介してそのアプリをユーザーに割り当てると、エンドポイント上のNPAはDNS名クエリを監視し、それらのいずれかがプライベートアプリのホスト名と一致する場合、NPAはそれらを架空のIPアドレスに解決します。以前のバージョンでは、IPアドレス範囲は191.x.x.xでしたが、現在のバージョンでは CGNATアドレス空間は100.64.0.0/16です（これをスタブIPアドレスと呼びましょう）。 そして、プロセスがそのスタブIPアドレスにリクエストを送信すると、NPAがそれを傍受し、パブリッシャーにトンネル接続します。パブリッシャーは、自身が指すDNSサーバーに基づいて新しい名前解決を実行し、公開されたアプリケーションの内部IPアドレスを解決します。

Publisher DNS を使うをオンにすると、スタブ IP アドレスを使うという概念がなくなります。 リクエストで指定されたホスト名に対する実際のDNSリクエストはキャプチャされ、パブリッシャーにトンネル転送されます。クライアントが受信する応答は、パブリッシャーが指すDNSサーバーへのDNSクエリによって返された実際のIPアドレスです。

例えば、プライベートアプリセグメントportal.company.comにアクセスしようとしていて、そのホスト名がパブリッシャーのDNSサーバーによって10.10.10.10に解決された場合、エンドポイントプロセス（ブラウザなど）に返されるIPアドレスは、スタブIPアドレス（バージョンによって191.x.x.xまたは100.64.0.0/16 ）ではなく10.10.10.10になります。ブラウザはその後、IPアドレス10.10.10.10にリクエストを送信しますが、これは任意のIPアドレスであり、NPAはそのIPアドレス宛てのトラフィックを傍受してトンネルする必要があることを認識する必要があります。そのため、プライベートアプリセグメントのアプリ定義には、プライベートアプリケーションのIPアドレスをカバーするCIDRブロック、またはプライベートアプリケーションの正確なIPアドレスのいずれかを含める必要があります。

このアプローチでは、エンドポイント上のNPAに対し、 10.10.10.10宛てのトラフィックを傍受し、NPAトンネル経由で送信する必要があることを指示します。

これは非常に強力な概念ですが、特定のアプリケーションが利用すべき正確なプライベートIP空間を特定するために、十分な注意を払う必要があります。もし誤って単一のアプリケーションで処理すべき範囲よりも広い範囲を指定してしまうと、使うPublisher DNSフラグがオンになっているすべてのプライベートアプリへのトラフィックが、アプリ上で定義された単一のパブリッシャーまたはパブリッシャーグループに誤って送られてしまう可能性があります。そのグループはそのIP範囲をカバーしており、アプリのホスト名が定義されているPublisherを経由してはいません。 Publisher DNSモードでのベストプラクティスの実例については、NPAガイドをご参照ください 。

プライベートアプリセグメントの管理と定義に関するアプローチ

アプリケーションを パブリッシャーDNS機能で定義する場合、いくつかのオプションがあります。 1つ目は、各プライベートアプリセグメントのアプリ定義に、解決対象のホスト名に対応する適切なCIDR範囲が含まれていることを確認することです。複数のアプリケーションを公開する場合、各アプリケーションについて指定するCIDR範囲が一意であり、他のアプリケーションの定義と重複しないようにする必要があるため、このようなアプローチは面倒になる可能性があります。これは、トラフィックの送信先に関するルーティングの競合を回避するためです。

これに対する別のアプローチとしては、同じパブリッシャーセットを通じて配信されるCIDRによってプライベートアプリセグメントのアプリ定義を定義する方法があります。次のシナリオを見てみましょう。

あなたは、 hosta.company.com 、 hostb.company.com 、 hostc.company.comという 3 つのプライベート アプリケーションを定義しています。これらはすべて、 sameパブリッシャーからアクセス可能です。これら 3 つのアプリケーションにサービスを提供しているパブリッシャーの CIDR ネットワーク範囲は172.16.0.0/16あることはわかっていますが、各アプリケーションの具体的な IP アドレスはわかりません。また、これらの IP アドレスは将来変更される可能性があります。

構成アプローチ

パブリッシャーDNS機能を有効にすると、ホスト名とポート番号だけで3つの独立したアプリケーションを定義できます。 次に、例としてロケーションAネットワーク用のプライベートアプリケーションを作成し、CIDR 172.16.0.0/16で定義します。 パブリッシャーDNS機能は無効にします。 これにより、NPAは、定義した172.16.0.0/16ネットワークおよびアプリケーションポート宛てのすべてのトラフィックを傍受し、NPAトンネル経由で送信することが保証されます。CIDR 定義は、Publisher DNS 機能を使用するのと同じプライベート アプリ定義の一部である必要はありません。 アプリケーション定義がどのようなものになるかを示す視覚的な例として、以下の表を参照してください。

この設定により、ホスト名を使用してアプリA 、アプリB 、アプリCにアクセスできるほか、ロケーションAのCIDRブロックで定義された内部リソースにもアクセスできます。また、ロケーションAアプリケーションのCIDR定義は、非常に広いRFC1918範囲をカバーしているため、ローカルネットワークリソースと干渉し、望ましくないステアリング動作を引き起こす可能性があり、ステアリングの競合や不規則性が発生する可能性があることもわかります。このようなCIDRブロックによってプライベートアプリを定義すると、そのアプリが割り当てられたユーザーがアクセスできるようになり、アプリのすべてのIPアドレスが公開されるため、ゼロトラストネットワークアクセス（ZTNA）の概念における最小権限の原則に違反する可能性があります。

プライベートアプリケーションを定義する最も安全な方法は、 パブリッシャーDNS機能を使用して、プライベートアプリケーションの定義に正確なCIDRベースのIPアドレスを指定することです。 例えば、プライベートアプリAを定義する場合、ホスト名としてhosta.company.com,を入力し、それが内部的に10.10.10.10に解決される場合は、そのアプリ定義のCIDR値として10.10.10.10/32入力する必要があります。次に、プライベートアプリ B を定義する際に、ホスト名hostb.company.comを入力し、それが内部的に10.10.10.11に解決される場合は、そのアプリ定義の CIDR 値として10.10.10.11/32入力します。この方法により、意図せず内部ネットワークに過剰アクセスしたり、ネットワークIPアドレスの競合が発生したりするのを効果的に防止できます。この目的を達成するために推奨されるプライベートアプリの定義については、以下の表を参照してください。

個人ユーザーの場合、NPAはプライベートアプリ定義におけるアプリケーション仕様に関係なく、無制限の数のプライベートアプリへのアクセスをサポートします。各プライベートアプリセグメントのアプリ定義は、アプリケーションセグメント名（ 1 ）によって参照されます。アプリ定義では、宛先指定（ 2 ）は、個々のIPアドレス、IPサブネット、ホスト名、またはワイルドカードドメイン（ *.corp.com ）のいずれかになります。

プライベートアプリセグメントのアプリ定義は、エンドユーザーがアプリケーションセグメントの仕様にアクセスできるようにするために、リアルタイム保護ポリシーに列挙されます。ポリシー定義に基づき、NPAは各ユーザーに対してアプリケーションセグメント仕様の論理的な関連付けを構築し、最大6000個のアプリケーションセグメント仕様をサポートします。ユーザーあたり6000を超えるアプリケーション仕様がある場合は、IPアドレスまたはホスト名をIPサブネットまたはワイルドカードドメインに集約することを検討してください。

管理者は、どのユーザーに対してもリアルタイム保護ポリシーが40MBを超えないようにする必要があります。各ユーザーのリアルタイムポリシーのサイズは、NPAトラブルシューターツールの出力で確認できます。