ネットワークエグレスを設定する

ネットワークエグレスとは、Foundry 内部から外部システムへの接続を試みるネットワークトラフィックを指します。このページでは、Control Panel でネットワークエグレスを設定および管理する方法と、Foundry のユーザーワークロードがそれらの設定を利用する方法の概要を説明します。

Foundry から外部に送信されるネットワークトラフィックでも、データは双方向に流れる場合があります。つまり、外部への接続が許可された Foundry 内のワークロードは、データの同期とエクスポートの両方に使用できます。

一方、ネットワーク イングレスとは、Foundry の外部から Foundry への接続を確立しようとするネットワークトラフィックを指します。ネットワークイングレスも Control Panel で管理します。

ネットワークエグレスの概要

Foundry は、顧客データを保護するために厳格なネットワークファイアウォールを提供します。顧客が管理するネットワークエグレスポリシーを使用し、コンテナネットワーク技術（Cilium ↗、eBPF ↗）を通じて個々のワークロードにネットワークファイアウォールルールを適用します。これらの顧客固有のルールに加え、Palantir の情報セキュリティチームは、セキュリティをさらに強化するために、インフラストラクチャのプロキシレベルでネットワークファイアウォールルールを維持管理しています。これらのルールを組み合わせることで、以下を含む Foundry のユーザーワークロードによるネットワークエグレスの実行を制御します。

• Foundry ワーカーを使用する Data Connection ソース
• 外部トランスフォーム
• 外部関数
• 外部ストリーミングユーザー定義関数（UDF）
• 外部モデルアダプター（モデリングのライブデプロイ用）
• Code Workbooks

ネットワークエグレスの経路を開くことには、常にセキュリティリスクが伴います。Foundry エンロールメントの情報セキュリティ責任者は、信頼できる宛先へのネットワーク経路のみを開き、それらの経路へのアクセスを信頼できる開発者グループに制限してください。信頼できる外部システムであっても、悪意のある攻撃者に悪用され、セキュリティ制御が回避される可能性があります。情報セキュリティ責任者は、Foundry の変更管理ツールを活用し、エグレスロジックの変更を信頼できるグループがレビューするようにするとともに、エグレスロジックの安全性を維持するための監査プロセスを確立してください。

Foundry から外部システムへのさまざまなネットワーク経路に対応するため、複数の種類のエグレスポリシーが用意されています。

• 直接接続ポリシー
• Agent プロキシポリシー
• プライベートリンクポリシー
• バケットエンドポイントポリシー
• セキュアトンネルエグレスポリシー

エグレスポリシーを作成するには、Control Panel でネットワークのエグレスページに移動し、ネットワークエグレスポリシーをリクエストを選択します。

直接接続エグレスポリシー

直接接続ポリシーは、Foundry のネットワークから外部の宛先に直接エグレスできる接続を有効にします。クラウドでホストされている Foundry インスタンスの場合、これは REST API やクラウドでホストされているシステムなどへの、インターネット経由の接続を意味します。一方、オンプレミスの Foundry インスタンスの場合は、オンプレミスネットワーク自体に接続されたシステムへの接続を意味します。外部システムは、Foundry からの受信接続を許可する必要があります。

次の一覧は、直接接続エグレスポリシーの設定時に使用できるオプションの概要です。

Server Name Indication (SNI) 検証

Palantir のネットワークインフラストラクチャは、デフォルトで、ポート 443（デフォルトの HTTPS ポート）を使用するすべてのネットワーク接続に対して SNI 検証を試みます。FTP(S)、SFTP、大半の TCP ベースのデータベース接続など、一部のプロトコルでは、そのポートを通るトラフィックに SNI が含まれないため、接続が応答しなくなったり、タイムアウトエラーが発生したりする場合があります。

特定のポリシーでポート443上の HTTPS 以外のトラフィックが想定される場合、管理者はそのポリシーの SNI 検証を無効にできます。

ワイルドカードエグレスポリシー

ワイルドカードアドレスを使用すると、個々のサブドメインを管理する代わりに、ドメインのサブドメイン階層全体 （例：*.domain.com）を許可リストに登録できます。これは、 Azure SQL のリダイレクトモード、Kafka ノード、MongoDB SRV 接続など、 サブドメインが動的であるか、事前に不明な場合に役立ちます。

ワイルドカードは、ドメインの最も左側のラベルに単一の要素として配置する必要があり、 パブリックサフィックス（例：*.com、*.co.uk、*.github.io）を対象にしてはなりません。対象にすると、ポリシーは 使用できなくなります。ワイルドカードアドレスは、ちょうど1階層のサブドメインに一致します。たとえば、 *.domain.com は bar.domain.com に一致しますが、domain.com や bar.baz.domain.com には一致しません。

Agent プロキシエグレスポリシー

Agent プロキシエグレスポリシーを使用すると、Data Connection Agent を介してオンプレミスまたはプライベートにホストされたシステムに接続できます。Agent プロキシエグレスポリシーにより、追加の設定を行わずに、Foundry ワークフローが外部システムに直接接続している_かのように_動作します。すべてのトラフィックは、Agent を介して透過的にプロキシされます。

Agent プロキシポリシーでは、Foundry から外部システムへのインバウンド接続は開始されず、外部システムで Foundry からのインバウンド接続を許可する必要もありません。ただし、Agent のホストマシンは対象の外部システムへのアウトバウンドネットワーク接続を備えている必要があり、対象の外部システムは Agent ホストからのインバウンド接続を許可する必要があります。

Agent エグレスポリシーを使用するソースは、次のワークフローでサポートされています。

• すべての主要な Data Connection の機能
  • 対応していないワークフロー：
    • 仮想テーブル
    • OIDC 認証
• 外部トランスフォーム（プレビューは VS Code のみでサポート）
• 外部のデプロイ済み関数。外部関数について詳しくはこちら。
• 外部ストリーミングユーザー定義関数（UDF）
• Code Workspaces
• Compute Module

次のリストは、Agent プロキシエグレスポリシーの設定時に使用できるオプションをまとめたものです。

セキュアトンネルエグレスポリシー

セキュアトンネルエグレスポリシーを使用すると、セキュアトンネルを介してオンプレミスまたはプライベートにホストされたシステムに接続できます。Agent プロキシと同様に、Foundry ワークロードは外部システムに直接接続している_かのように_動作します。すべてのトラフィックは、ネットワーク内で実行されるイニシエーターを介して透過的に仲介されます。

このポリシーでは、Foundry から外部システムへのインバウンド接続は開始されず、外部システムで Foundry からのインバウンド接続を許可する必要もありません。ただし、イニシエーターは対象の外部システムへのアウトバウンドネットワーク接続を備えている必要があり、対象の外部システムはイニシエーターからのインバウンド接続を許可する必要があります。宛先は、イニシエーターに設定されたエグレス許可リストでも許可されている必要があります。

次のテーブルは、ポリシーの設定オプションをまとめたものです。

プライベートリンクエグレスポリシー

プライベートリンクエグレスポリシーでは、あるアドレスへのすべてのトラフィックをプライベートリンク経由でルーティングすることで、プライベートリンクを介した接続を可能にします。

プライベートリンクエグレスポリシーが導入される前は、直接接続エグレスポリシーを使用してプライベートリンク経由でトラフィックをルーティングしていました。プライベートリンクのドメインに対して設定された既存の直接接続エグレスポリシーは引き続き機能し、プライベートリンクエグレスポリシーに自動的に移行されます。

次のリストは、プライベートリンクエグレスポリシーの設定時に使用できるオプションをまとめたものです。

プライベートリンクエグレスポリシーを使用するソースは、次のワークフローでは利用できません。

• 仮想テーブル
• Iceberg テーブル向けの独自バケットストレージ
• OIDC 認証

バケットエンドポイントのエグレスポリシー

Palantir プラットフォームが、エグレス先の外部システムと同じクラウドプロバイダー（Amazon AWS、Azure、Google Cloud Platform）でホストされている場合、そのクラウドプロバイダーの特定のエンドポイント内でトラフィックが流れるように、個別の許可リスト登録が必要になることがあります。許可リスト登録は、バケットエンドポイントのエグレスポリシーで制御します。

AWS S3 バケットエンドポイントポリシー

AWS でホストされている Palantir プラットフォームのインスタンスでは、同じ AWS リージョン ↗ でホストされている外部の S3 バケットに接続する際に、バケットエンドポイントポリシーが必要です。これは、同じリージョン内の VPC ゲートウェイエンドポイント（この場合は Palantir プラットフォーム）から S3 へのリクエストに対して、AWS がネットワークを処理する方法に起因します。

AWS への接続を確立するには、次の手順に従います。

1. Control Panel で、バケットエンドポイントタイプのネットワークエグレスポリシーを作成します。

次のテーブルは、S3 バケットエンドポイントのエグレスポリシーの設定オプションをまとめたものです。

2. S3 バケットのバケットポリシー ↗が、Palantir プラットフォームインスタンスの VPC エンドポイントからの受信トラフィックを許可していることを確認してください。

ネットワークポリシーが作成されると、接続元の VPC エンドポイントがポリシーの概要ページに表示されます。

Amazon S3 のドキュメントには、バケットポリシーを使用して S3 バケットへのトラフィックを特定の VPC エンドポイントに制限する例 ↗が記載されています。VPC エンドポイントから S3 への受信トラフィックの管理について詳しくは、公式の AWS ドキュメント ↗を参照してください。

バケットエンドポイントのエグレスポリシーを使用するソースは、次のワークフローでは利用できません。

• 仮想テーブル
• Iceberg テーブル向けの Bring-your-own-bucket（BYOB）ストレージ

ポリシーを使用する

このセクションでは、ネットワークエグレスポリシーに関連する権限、ネットワークエグレスポリシーが取り得るライフサイクルの状態の概要と、ネットワークエグレスポリシーを適用する方法を説明します。

権限

以下のテーブルは、ネットワークエグレスポリシーに関連する操作権限と、そのデフォルト設定の概要を示しています。

ネットワークエグレスの主要な管理インターフェースは、Control Panel のエンロールメントレベルにあります。エンロールメント管理者ロールに関連付けられたネットワークエグレス設定の管理ワークフローへのアクセス権を持つユーザーは、ネットワークのエグレスページにアクセスして、エグレスポリシーに対するすべての管理操作を実行できます。

また、エンロールメント管理者と情報セキュリティ責任者は、エグレスポリシーがどのプロジェクトにインポートされているかを常に確認できます。これは、管理者ユーザーがそのプロジェクトに対する個別のアクセス権を持っているかどうかに関係なく可能です。このメタデータにより、情報セキュリティ責任者はポリシーの使用状況を十分に把握し、ポリシーの取り消しや、その他の使用制限に関するガバナンス上の判断を下すことができます。

ポリシーを承認する際、情報セキュリティ責任者は、ネットワークエグレスポリシーの閲覧またはインポートの権限をどのユーザーやグループに付与するかを決定する必要があります。これは、後から Control Panel のポリシー詳細ページにある共有の管理ボタンを使用して管理することもできます。

デフォルトでは、ポリシーは「オプトイン」方式であり、Foundry のワークロードにアタッチする必要があります。たとえば、Data Connection ソースを作成する際は、そのポリシーに対するインポーター権限を持つユーザーが、ソースで使用するポリシーを明示的にソースにアタッチする必要があります。これは最小権限の原則 ↗に従うものであり、ワークロードの正常な実行に厳密に必要なエグレスルールのみが、そのワークロードに付与されるようにします。

ポリシーの状態

ネットワークエグレスポリシーは、ライフサイクルを通じて、以下に示すいずれかの状態になります。

ポリシーを適用する

ネットワークポリシーを正常に適用するには、以下の手順に沿って進めます。

1. Control Panel でポリシーを作成します。Foundry のポリシーを Palantir が管理している場合は、エグレスポリシーの詳細を Palantir の担当者に提供してください。これにより、Palantir はネットワークアクセスを拡張する前にセキュリティリスクを評価できます。Foundry のポリシー管理が完全にセルフサービスの場合、ポリシーはファイアウォールに自動的に適用されます。

2. ポリシーをユーザーワークロードに割り当てます。

• Foundry ワーカーを使用する Data Connection ソース：新しいソースを作成する際にネットワークポリシーを指定します。
• Code Workbook: きめ細かなネットワーク管理はまだ利用できないため、管理者は代わりにグローバルポリシーを作成する必要があります。グローバルポリシーはすべてのワークロードに一律に適用されるため、信頼性が非常に高いネットワークルートに対してのみ設定してください。

ポリシーをユーザーワークロードに割り当てるには、該当するエグレスポリシーに対するインポーター権限が必要です。この権限は、それぞれのエグレスポリシーの共有の管理設定を通じて、ポリシーごとに付与されます。

制限

コードリソースまたはトランスフォームには最大10個のソースをインポートでき、それらを合わせて、TCP レベルの許可リスト登録を使用するエグレスポリシーを最大50個まで利用できます。

観測可能性

ログとメトリクスを使用してネットワークエグレスポリシーを監視し、トラブルシューティングするには、ネットワークエグレスの観測可能性のドキュメントを参照してください。

詳細設定

TCP レベルの許可リスト登録

エグレス制御は、HTTP レベルまたは TCP レベルで適用できます。TCP レベルの許可リスト登録は、HTTP および HTTPS トラフィックの標準ポートであるポート 80 と 443 を使用する直接接続ポリシーを除き、すべてのエグレスポリシーで必要です。TCP レベルの許可リスト登録を使用するかどうかによって、接続のセキュリティが変わることはありません。

ポート 80 または 443 を使用するポリシーを介して HTTP(S) 以外のトラフィックを送信する場合、エグレスを成功させるには TCP レベルの許可リスト登録を有効にする必要があります。

よくあるエッジケース

同一のポリシーが2つあり、一方が一時停止中または取り消し済みで、もう一方がアクティブの場合はどうなりますか？

アクティブなポリシーを使用するワークロードは正常に実行されますが、一時停止中または取り消し済みのポリシーを使用しようとするワークロードは実行に失敗します。

ポリシーが重複しており、一方が一時停止中または取り消し済みで、もう一方がアクティブの場合はどうなりますか？

単一の IP アドレスを使用するポリシーと、IP アドレスの CIDR ブロックを指定するポリシーが重複する場合に、この状況が発生することがあります。

この場合、同一のポリシーの場合と同様に、アクティブなポリシーを使用するワークロードは正常に実行されますが、一時停止中または取り消し済みのポリシーを使用しようとするワークロードは実行に失敗します。

すでに存在するポリシーを提案するとどうなりますか？

重複するポリシーは許可されており、提案を審査する情報セキュリティ責任者は、次のいずれかを選択できます。

1. 提案を全面的に却下します。
2. 提案を却下し、既存の同一または重複するポリシーに対する「インポーターアクセス権」を提案者に付与します。
3. 提案を承認し、同一または重複するポリシーを許可します（非推奨）。

Foundry からの接続はどの IP アドレスから行われますか？

Foundry から外部の宛先への接続が開始されると、その接続は特定の IP 範囲から行われます。Foundry からの接続を受け入れるために、事前にそれらの IP アドレスを許可リストに追加する必要がある場合があります。

Foundry が Palantir のクラウドインフラストラクチャでホストされている場合、Foundry のトラフィックの送信元となるエグレス IP アドレスは、Control Panel のネットワークエグレス管理ページに表示されます。宛先システムの許可リストに追加する際は、そこに表示されている CIDR 範囲をコピーしてください。

クラウドプロバイダーのエグレス

Amazon S3 バケットポリシー

AWS でホストされている Foundry インスタンスでは、同じリージョンの S3 バケットに接続する際に追加の設定が必要です。これは、同じリージョンの VPC ゲートウェイエンドポイントから S3 へのリクエストに対して、AWS がネットワークを処理する仕組みによるものです。

接続に追加の設定が必要かどうかを確認するには、Control Panel でネットワークのエグレスページに移動します。S3 バケットポリシーという追加のタブがある場合、インスタンスは AWS でホストされており、Palantir の VPC エンドポイントから同じリージョン内の S3 バケットへのトラフィックを明示的に許可する必要があります。

S3 バケットポリシータブがある場合は、インスタンスがホストされているリージョンと、Foundry から同じリージョン内の S3 バケットへのトラフィックのルーティングに使用される VPC エンドポイントの Amazon Reference Number (ARN) も表示されます。

Foundry と同じリージョンのバケットに正常に接続するには、次の手順を完了する必要があります。

1. AWS コンソールでバケットポリシーを設定し、Foundry インスタンスの VPC エンドポイントからのトラフィックを許可します。AWS バケットポリシーの詳しくはこちら ↗。
2. Control Panel で、目的のバケットがネットワークのエグレス > S3 バケットポリシー > AWS S3 バケットポリシーに一覧表示されていることを確認します。
3. 上記の説明に従って適切なネットワークエグレスポリシーを作成し、接続に使用している Data Connection ソースの設定の詳細に追加します。

Foundry インスタンスの VPC エンドポイントから S3 へのトラフィックを許可する

AWS コンソールで、S3 バケットのバケットポリシー ↗が、次に示すネットワークのエグレス > S3 バケットポリシータブに表示される VPC エンドポイントからの受信トラフィックを許可していることを確認する必要があります。

Amazon S3 のドキュメントには、バケットポリシーを使用して S3 バケットへのトラフィックを特定の VPC エンドポイントに制限する方法の例 ↗が記載されています。VPC エンドポイントから S3 への受信トラフィックの管理については、公式の AWS ドキュメント ↗を参照してください。

S3 バケットポリシーを追加する

同じリージョンのバケットを追加するには、バケットポリシーを追加するを選択し、次に示すプロンプトに従って目的のバケット名を入力します。

フォームは、バケット名の有効性とリージョンを自動的に確認します。バケット名が有効で、そのリージョンが Foundry インスタンスのホスト先リージョンと一致する場合、保存できます。バケット名に加えて、読み取り専用または読み取り/書き込みのポリシーを指定する必要があります。これにより、S3 への接続を確立する際に Palantir が要求するアクセスレベルが決まります。

S3 バケットポリシーを使用する

同じリージョンのバケットポリシーは、追加すると即座に有効になり、Foundry からそのバケットへ直接エグレス通信を試みるすべてのワークロードに適用されます。ネットワークエグレスポリシーとは異なり、Foundry 内の特定のソースやその他のワークロードにアタッチする必要はありません。

S3 ソースを作成するとき、設定インターフェースは、バケットが Foundry と同じリージョンにあるかどうか、および Control Panel ですでに追加されているかどうかを自動的に確認します。ソースを設定するユーザーには、バケットが正しく追加されていることを示す緑色のチェック、または Control Panel で S3 バケットポリシーを追加するアクセス権を持つ管理者による対応が必要であることを示す赤色のチェックのいずれかが表示されます。

S3 バケットポリシーの制限

エンロールメントごとに、同じリージョンのバケットを最大10個追加できます。Foundry インスタンスから同じリージョンの S3 バケット10個を超えるアクセスが必要な場合は、Palantir サポートにお問い合わせください。

Microsoft Azure Storage ポリシー

Azure でホストされている Foundry インスタンスでは、トラフィックが Azure サービスエンドポイント経由でルーティングされるため、Azure Storage リソースへの接続時に追加の設定が必要です。

接続に追加の設定が必要かどうかを確認するには、Control Panel でネットワークのエグレスページに移動します。Azure Storage ポリシーという選択可能なタブが追加で表示されている場合、インスタンスは Azure でホストされており、接続先のリソースを持つ Azure Storage アカウントへのトラフィックを、Palantir の Azure サブネットから明示的に許可する必要があります。

Azure Storage ポリシータブが表示されている場合、このタブには Foundry から Azure Storage リソースへのトラフィックのルーティングに使用されるサブネットIDが表示されます。

Azure Storage リソースに正常に接続するには、次の手順を完了する必要があります。

1. Azure で Azure Storage アカウントの仮想ネットワークルールを設定し、Foundry インスタンスのサブネットからのトラフィックを許可します。Azure 仮想ネットワークルールの管理について詳しくはこちら ↗。
2. Control Panel で、目的の Azure Storage アカウントがネットワークのエグレス > Azure Storage ポリシーに表示されていることを確認してください。
3. 上記の説明に従って適切なネットワークのエグレスポリシーを作成し、接続に使用する Data Connection ソースの設定の詳細に追加します。

Foundry インスタンスのサブネットから Azure Storage アカウントへのトラフィックを許可する

Azure アカウントで、Storage アカウントの仮想ネットワークルール ↗が、以下に示すネットワークのエグレス > Azure Storage ポリシータブに表示されるサブネットIDからの受信トラフィックを許可していることを確認する必要があります。

Azure Storage ポリシーを追加する

Azure Storage エグレスポリシーを追加するには、Azure Storage ポリシーを追加するを選択し、表示される案内に従って、以下に示すように目的の Storage アカウントのリソースIDを入力します。

フォームでは、入力された Azure Storage アカウントのリソースIDが有効かどうかが自動的に確認されます。Azure Storage アカウントのリソースIDを確認する方法の詳細は、Azure ドキュメント ↗を参照してください。

Azure Storage ポリシーを使用する

Azure Storage ポリシーは、追加するとすぐに有効になり、Foundry からその Storage アカウントへ直接エグレスを試みるすべてのワークロードに適用されます。ネットワークのエグレスポリシーとは異なり、Foundry の特定のソースやその他のワークロードにアタッチする必要はありません。

ABFS ソースを作成する際、設定インターフェースでは、Foundry が Azure にデプロイされているかどうか、および有効な Storage アカウントがすでに Control Panel で追加されているかどうかが自動的に確認されます。ソースを設定するユーザーには、以下に示すように、Control Panel で Azure Storage ポリシーを追加できるアクセス権を持つ管理者による対応が必要であることを示す警告が表示されます。

ネットワークのエグレスポリシーの作成後、エグレスに Azure Storage ポリシーも必要な場合は、以下に示す警告も表示されます。

Google Cloud Platform (GCP) エグレス

GCP でホストされている Foundry インスタンスでは、BigQuery、Google Cloud Storage、Google Pub/Sub など、GCP プロジェクト上でホストされているリソースに接続する場合、追加の設定が必要です。

GCP プロジェクトに必要な追加設定を行うには、Palantir サポートにお問い合わせください。