プライベートアプリケーション定義でのGlobパターンの使用

ホスト名が予測可能な命名規則に従っているものの、値が変化するプライベートアプリを定義するには、globパターンを使用します。Globパターンは、AWS ECS、Kubernetes、マルチリージョンクラウドサービスなど、ワークロードが頻繁に作成、名前変更、または置換される動的な環境で役立ちます。

例えば、ECSタスクのホスト名を個別にすべて追加するのではなく、ホストをtask-*.ecs.internalとして定義します。

Globパターンは、*.internal のような広範な先頭ワイルドカードよりも正確なマッチングを提供します。これにより、管理作業を削減し、関連のないホストがNetskope Private Accessを経由してステアリングされるのを防ぐことができます。

R141以降、内部の * はマルチレベルマッチングを実行できます。本番環境でパターンを使用する前に、Behavior by release を確認してください。

サポートされているアクセス方法

アクセス方法	Globパターン
Netskope Clientベースのアクセス	対象となるクライアントビルドでサポートされています
Netskope Enterprise Browser	対象となるEnterprise Browserビルドでサポートされています
NPA Browser Access（クライアントレス）	サポートされていません
ユーザーポータルアプリケーション	サポートされていません

GlobパターンはDNSホスト名に適用されます。これらはIPアドレスやCIDR定義には適用されません。

Glob syntax

Globパターンは以下のメタ文字をサポートしています：

Character	Meaning	例
*	可変の文字列シーケンスに一致します。R141以降、完全なラベルとして使用される内部の*は、1つ以上のDNSラベルにまたがることができます。	task-*.ecs.internal, db.*.corp
?	ドット (.) 以外の文字にちょうど1つ一致します。	k8s-node?.prod.corp

サポートされているその他のホスト名の文字は、そのまま（リテラルで）マッチングされます。マッチングでは大文字と小文字は区別されません。

最後（一番右）のラベルは文字通りである必要があります。最終ラベルには*または?を配置しないでください。例えば、task-*.internalは有効ですが、task.internal*は無効です。

既存の先頭ワイルドカード

既存の *.domain 形式のホストは、globパターンではなく、先頭のワイルドカードとして扱われます。その動作は変更されません。先頭のワイルドカードは、引き続き任意の深さのサブドメインに一致します。

例えば、*.example.internal は両方に一致します：

• app.example.internal
• app.eu.example.internal

可変文字が別の位置に現れる場合、または ? が必要な場合は、globパターンを使用してください。

リリース別の動作

Pattern	Hostname	R140 ベータ	R141以降
db.*.corp	db.us-west-2.corp	試合	試合
db.*.corp	db.us-west-2.rds.corp	一致しません	試合
db.*.corp	db.corp	一致しません	一致しません

R141以降では、db.*.corp は db. と .corp の間で複数のラベルを消費できます。アップグレードの前に、既存のR140パターンを確認してください。以前は1つのラベルに一致していたパターンが、アップグレード後にはより深い階層のホスト名にも一致する可能性があります。

より広範な一致を意図していない場合は、可変部分をよりリテラルなテキストに置き換えるか、変化する部分の文字数がわかっている場合は?を使用してください。R141には、「任意の文字だが、次のドットで停止する」ことを意味する演算子は用意されていません。

R140 beta limitation: Netskope Clientは単一ラベルのDNS名をインターセプトできませんが、R140のUIおよび検証APIでは host* のようなドットなしのglobパターンを受け入れることができます。そのような定義では、一致するトラフィックはステアリングされません。R140ではドットなしのパターンを使用しないでください。R141以降、NPAは検証時にそれらを拒否します。

開始する前に

• テナントの管理対象ベータ機能の有効化については、Netskopeの担当者にお問い合わせください。
• エンドポイントが、globパターンをサポートするNetskope ClientまたはEnterprise Browserのビルドを使用していることを確認します。
• アプリケーションホスト名の固定部分と可変部分を特定します。
• 一致する必要があるホスト名と、一致してはならないホスト名に対してパターンをテストします。
• 専用のプライベート名前空間が利用可能な場合は、パブリックまたは共有のDNSサフィックスの使用を避けてください。

globパターンを使用してプライベートアプリを作成する

1. Settings > Security Cloud Platform > App Definitionへ移動してください。
2. Private App Segments Select 。
3. Select New Application Segment を選択するか、既存のアプリケーションセグメントを編集してください。
4. アプリケーション名を入力します。
5. Host に、task-*.ecs.internal のようなglobパターンを入力してください。
6. 必要なTCPまたはUDPポートを追加してください。
7. 1つ以上のPublisherを選択してください。
8. 残りのアプリケーション設定を構成します。
9. Save Select 。
10. 確認ウィンドウを確認し、Confirmを選択してください。

更新された定義がエンドポイントに到達するまで、通常のポリシー配布間隔を確保してください。

検証ルール

R141以降、グロブパターンのホストはこれらの要件をすべて満たす必要があります。R140ではドットの要件が正しく適用されませんが、R140ベータ定義を作成する際も同じルールに従ってください。

• 少なくとも1つのドット（.）を含めてください。
• 文字、数字、またはハイフンを少なくとも1つ含めてください。
• *文字を3文字以内で使用してください。
• ?文字以内で入力してください。
• リテラルな最終ラベルを使用してください。右端のラベルに * および ? を含めることはできません。
• 隣接するアスタリスク（**）は使用しないでください。
• 10.*.1.50のようなIPアドレス形式の値には、グロブ文字を使用しないでください。
• サポートされているDNSホスト名の文字のみを使用してください。

例：

Input	Result	理由
task-*.ecs.internal	Accepted	有効なglobパターン
k8s-node?.prod.corp	Accepted	? 1文字を表します
host*	R141以降で拒否	パターンにドットが含まれていません
*.*	Rejected	パターンにリテラル文字が含まれていません
a*b*c*d*.internal	Rejected	* 文字より多い
*.int?rnal	Rejected	メタ文字が最終ラベルに表示されます
abc**.internal	Rejected	隣接するアスタリスクはサポートされていません
10.*.1.50	Rejected	GlobパターンはIPアドレスには適用されません

トップレベルドメインおよびパブリックDNSサフィックスに対するテナントレベルの制限は引き続き適用されます。

優先順位の照合

複数のプライベートアプリ定義が同じ宛先に一致する場合、NPAは以下の順序でホスト名定義を評価します：

1. 完全修飾ドメイン名（FQDN）
2. グロブパターン
3. 既存の先行ワイルドカード
4. デフォルトルール

例えば、app.prod.internal が完全一致FQDNとして構成されており、かつ app.*.internal にも一致する場合、完全一致FQDNの定義が優先されます。

新しいパターンが既存のグロブパターンまたはワイルドカードと重複する場合、NPAは非ブロッキングの警告を表示できます。可能な限り重複を解決してください。重複するパターンが保持されている場合、トラフィックが意図したものとは異なるプライベートアプリに関連付けられる可能性があります。

制限事項

• NPA Browser AccessまたはUser Portalアプリケーションでは、Globパターンはサポートされていません。
• globパターンは、IPv4アドレス、IPv6アドレス、またはCIDR範囲には適用されません。
• 最終的なホスト名ラベルはリテラルである必要があります。
• 完全な正規表現および [a-z] などの文字クラスはサポートされていません。
• 隣接するアスタリスク（**）はサポートされていません。
• 古いNetskope Clientは、globパターンを解釈しません。これらはパターンをリテラルなホスト名として安全に処理するため、動的ホストは一致しません。
• パターン作成後に管理対象ベータ機能が無効になると、それらのパターンはグロブマッチングを実行しなくなります。

グロブパターンアクセスのトラブルシューティング

ホスト名が一致しない場合、またはトラフィックが誘導されない場合：

1. その機能がテナントに対して有効になっていることを確認してください。
2. エンドポイントがサポートされているNetskope ClientまたはEnterprise Browserのビルドを使用していることを確認してください。
3. アプリケーションがBrowser Accessではなく、クライアントベースのアクセスまたはEnterprise Browserを使用していることを確認してください。
4. すべてのリテラル文字とドットを含む完全なパターンとホスト名を比較します。
5. 各?がドット以外の文字1つに正確に対応していることを確認してください。
6. R140については、内部の*がドットをまたがないことを確認してください。
7. 重複パターンの警告を確認し、より優先度の高い完全一致のFQDN定義がないかチェックしてください。
8. PublisherがプライベートDNS環境を使用してホスト名を解決できることを確認してください。
9. アプリケーション定義を変更した後は、通常のポリシー配布間隔を待ってください。

一般的なユースケース

動的なAWS ECSタスク

タスク識別子が変更されるタスクホスト名には、1つの定義を使用します：

task-*.ecs.internal

一致する例:

• task-a17f3.ecs.internal
• task-worker-1e2cdc5.ecs.internal

一致しない例：

• database.ecs.internal

Kubernetesノードまたはバージョン管理されたサービス

1文字のみが異なる場合は、?を使用してください：

k8s-node?.prod.corp

一致する例:

• k8s-node1.prod.corp
• k8s-nodeA.prod.corp

一致しない例：

• k8s-node12.prod.corp

マルチリージョンサービス

固定されたプレフィックスとサフィックス間の階層が変化する可能性がある場合は、マルチレベルパターンを使用してください：

db.*.corp

R141以降、一致する例には次のようなものがあります：

• db.us-west-2.corp
• db.us-west-2.rds.corp
• db.eu-central-1.database.production.corp

一致しない例：

• db.corp
• web.us-west-2.rds.corp

複数の変更値を持つホスト

ホスト名の異なる部分が複数ある場合は、複数のメタ文字を使用してください：

*-worker-*.svc.internal

一致する例：

• payments-worker-4f92.svc.internal

一致しない例：

• payments-server-4f92.svc.internal

予測可能なデスクトップ名またはサーバー名

組織の命名規則に従うホストには、位置指定パターンを使用してください：

rdp-finance-??.corp.internal

一致する例:

• rdp-finance-01.corp.internal
• rdp-finance-eu.corp.internal

一致しない例：

• rdp-finance-001.corp.internal