Data Connectivity Proxyの紹介：Snowflake Openflowをプライベートデータに導入

エンタープライズデータはマルチクラウド、アプリ、プラットフォームにまたがっており、境界ファイアウォールに重大な死角を生み出しています。ネットワーク境界を保護するだけではもはや十分ではありません。ガバナンスと制御は、データが存在するまさにその場所に組み込まれる必要があります。一般的な大規模組織では、コア財務用のOracleデータベースをオンプレミスで実行し、プライベートVPC内のKafkaブローカーを通じてリアルタイムイベントをストリーミングし、複数のパブリッククラウドに分散したデータベースを運用している場合があります。ハイブリッド環境でこれらのプライベートソースに到達することは、これまで不可能であったか、トポロジーごとに異なるネットワークソリューションが必要でした。VPN、PrivateLink、および単発のエージェントのこのような継ぎ接ぎは、時間の経過とともにそれ自体がインフラストラクチャの問題になります。

本日、プライベートデータアクセスの問題に対処するため、Snowflake Openflow向けのData Connectivity Proxy（DCP）を発表します。Snowflake Openflowは、カスタムETLインフラストラクチャを構築することなくデータを接続するフルマネージドのデータ統合サービスであり、DCPにより、これまで到達できなかったプライベートソースへのアクセスが可能になります。これは、トポロジーごとのVPN、PrivateLink、およびサードパーティエージェントの必要性を減らす、一貫したSnowflake提供のエージェントモデルを通じて実現されます。

プライベートデータをマネージドパイプラインに取り込むには、歴史的に選択を迫られてきました。チームは、すべてのネットワーク境界でカスタムETLインフラストラクチャの運用コストを負担するか、通常は許可されていない環境でインバウンドポートを開くための承認を得るために数か月にわたるプロジェクトに着手するかのいずれかです。

金融サービス、ヘルスケア、製造企業の企業にとって、すべてのインバウンドを拒否するポリシーは、多くの場合、規制上の要件です。マネージドパイプラインベンダーが「プライベートネットワーク接続をセットアップする」と言う場合、実際に必要なのは、ネットワークエンジニアリングを巻き込み、ファイアウォールルールを開き、変更諮問委員会をクリアすることです。DCPは、すべてのインバウンドを拒否するネットワーク向けに構築されています。エージェントは、ポート443でアウトバウンドTLSのみを行います。関連する制約の1つは次のとおりです。エージェントホストは、そのポートでSnowflakeへの直接アウトバウンドアクセスを必要とします。エンタープライズマネージドのフォワードプロキシ（HTTPS_PROXYまたはCONNECTベースの転送）を介したエージェント自身のアウトバウンドトラフィックのルーティングは、現在サポートされていません。 

それでも、これらすべてをセットアップすることは、データが移動する前の数週間にわたるプロジェクトであり、既存のオプションは問題の一部を解決するだけです。 

• CSPネイティブのプライベート接続（AWS PrivateLink、Azure Private Endpoint、およびGoogle Private Service Connect）は、同じクラウド内にプライベートなクラウド内パスが必要な場合に適しています。オンプレミスのソースを対象としていません。DCPは、ネットワーク上のアウトバウンドエージェントでこれらのケースをカバーします。
• VPN、ExpressRoute、およびVPCピアリングは機能しますが、それぞれがインフラストラクチャチームの調整、承認、および継続的なメンテナンスを必要とする数週間にわたるネットワークエンジニアリングプロジェクトである
• レガシーなパイプラインツールは、これをほとんど未解決のままにしています。ファーストパーティエージェントがまったくないものもあるため、パイプラインが何かを実行する前に、お客様自身でVPNと専用のネットワーク接続を構築する必要があります。
• サードパーティの接続エージェントは技術的な問題を解決しますが、運用およびサポートするための別のベンダー、別の契約、および別のシステムを追加する

DCPは、データがすでに存在する環境（オンプレミスのデータセンター、プライベートクラウド環境、VPC、または別のクラウド）内で実行される軽量エージェントとして提供されることにより、データ統合パスからこれらのネットワーク依存関係を排除します。

エージェントは、ポート443でSnowflakeへのアウトバウンド接続を作成し、暗号化されたトンネルを確立します。その後、SnowflakeはOpenflowトラフィックをそのトンネルを介してルーティングし、プライベートソースに到達します。

この設計は、通常のモデルを反転させます。Snowflakeがネットワークに到達するのではなく、ネットワークがSnowflakeに到達します。ファイアウォールは、境界内から開始されたアウトバウンドTLS接続のみを認識します。開く、変更する、または承認するインバウンドファイアウォールルールはありません。

エージェントとSnowflake間のトラフィックは相互TLS（mTLS）で保護されます。つまり、両者が証明書を使用して互いのIDを検証します。セットアップは1回限りのブートストラップトークンから始まります。その後、エージェントは証明書ペアを使用して自動的に認証され、Snowflakeはバックグラウンドで証明書をローテーションします。エージェントはTCPレベルで動作します。通過するデータを検査、解析、または保存することなくトラフィックを転送します。

セキュリティ　ー　DCPは、すべてのインバウンドを拒否するネットワーク向けに構築されています。エージェントはインバウンド接続を受け入れないため、ファイアウォールの例外を要求したり、新しいインバウンドリスナーを追加したりすることはありません。ファイアウォールは、ポート443でのアウトバウンドTLSという1つのクラスのトラフィックを認識します。

IDは明示的であり、監査可能です。SnowflakeでブートストラップJSON Webトークン（JWT）を作成し、エージェントホストに配置します。エージェントは、そのトークンをDCPコントロールプレーンに1回提示し、そのDCPクライアントに紐付けられたmTLS証明書を受け取ります。その後、トンネル、ハートビート、およびルーティングの更新にはmTLSが使用されます。両者はすべての接続で証明書を検証します。ブートストラップトークンは、次の証明書のローテーションまで再び使用されることはありません。

エージェントはTCPパススルーです。トンネル内のバイトを検査、解析、または保存しません。ソースの認証情報はSnowflakeに保持され、エージェントに到達することはありません。宛先はSnowflakeで許可リストに登録されます。ネットワークルールはプライベートホストとポートを指定し、外部アクセス統合はそのルールを許可し、DCPオブジェクトに統合をバインドします。オプションで、オブジェクトのネットワークポリシーにより、DCPコントロールプレーンと通信できるソースIPを制限できます。オブジェクトを無効にするかドロップすると、証明書の有効期限が切れていなくても、エージェントの証明書は機能しなくなります。

到達性　ー　DCPは、同じクラウドのプライベートエンドポイントとパブリックSaaSコネクタが開いたままにするギャップをカバーします。

• Oracle、SQL Server、PostgreSQL、MySQLなど、企業ファイアウォールの背後にあるオンプレミスデータベース
• VPCまたはデータセンター内のプライベートKafkaブローカー
• SnowflakeアカウントがAzureにある場合のAWS上のデータなどのクロスクラウドソース
• これらのトポロジーのいくつかを同時に持つハイブリッド環境

エージェントはアウトバウンドポート443のみを必要とするため、データとSnowflakeアカウントがAWS、Azure、Google Cloud、またはオンプレミスのいずれにあるかに関係なく、同じパターンが機能します。これらのギャップをカバーするためにサードパーティツールを継ぎ接ぎしてきた場合、DCPはその継ぎ接ぎをOpenflowにネイティブなファーストパーティパスに置き換えます。

シンプルさ　ー　エージェントはDockerイメージとして提供され、Dockerまたは別のOCI互換ランタイムを備えた任意のLinuxホストで実行されます。Kubernetesは必要ありません。トンネルが切断されるとエージェントは再接続し、Snowflakeはアクティブな接続を切断することなくバックグラウンドでエージェント証明書をローテーションします。

DCPは本日、Standard、Enterprise、およびBusiness-CriticalエディションのSnowflakeのお客様向けに、AWS、Azure、およびGCPで一般提供されています。オンプレミスでOracleを使用する中堅の製造企業から、ファイアウォールの背後でPostgreSQLを運用する地方銀行まで、プライベートソースの接続ニーズを持つ組織は、最初に上位のSnowflakeエディションに移行することなく、ファーストパーティのOpenflow機能の使用を開始できます。

Snowflake Openflowに接続できなかったオンプレミスデータベース、プライベートKafkaブローカー、またはクロスクラウドソースがある場合は、インバウンドファイアウォールアクセスを開いたり、ネットワークを再設計したりすることなく、それらを接続するために今すぐOpenflowでDCPをお試しください。

クイックスタート

ドキュメント

• Data Connectivity Proxyの概要：アーキテクチャ、DCPを使用するタイミング、PrivateLinkおよび安定したエグレスIPとの比較
• Data Connectivity Proxyのセットアップ：ステップバイステップの展開ガイド
• セキュリティモデル：mTLS、証明書管理、およびアクセスの取り消し
• Data Connectivity Proxyの監視：DESCRIBE DATA CONNECTIVITY PROXY、イベント履歴、Prometheusメトリクス
• Data Connectivity ProxyでのSnowflake Openflowの使用