金融・証券サイトのオリジンIPを隠し、取引システムへの直接攻撃を防ぐには

CDN導入後も金融サイトのオリジンIPが露出するのはなぜか。過去のDNS記録、APIドメイン、アプリ設定、テスト環境などの漏えい経路と、CDN07のDDoS対策CDN、オリジンの許可リスト、HTTPSによるオリジン接続、トラフィックスクラビングを組み合わせた保護方法を解説します。

Tatyana Hammes

10月 13, 2026

2 mins to read

午前2時、ある金融プラットフォームのセキュリティチームがDDoS対策CDNへの切り替えを終えました。WebサイトはCDN経由で正常にアクセスでき、DDoS対策、HTTPフラッド対策、WAFルールも有効になっています。

ようやく一息つけると思った矢先、オリジン側の帯域が飽和しました。

攻撃者はWebサイトのドメインを狙うのをやめ、CDNを迂回して取引システムの実際のIPアドレスへ直接トラフィックを送り込んでいました。DDoS対策エッジには攻撃が届かず、スクラビングもできません。数分後には相場情報APIがタイムアウトし始め、ユーザーがログインできなくなり、取引APIで502や504のエラーが相次ぎました。

こうした事態は珍しくありません。

DDoS対策CDNの導入は、オリジンIPを隠すための第一歩にすぎません。過去のDNS記録、アプリ設定、APIのサブドメイン、メールサーバー、テスト環境、ファイアウォールのルールなどから実際のアドレスが分かれば、攻撃者はエッジの防御を迂回して金融プラットフォームのオリジンを直接攻撃できます。

証券、先物、投資信託、フィンテックのプラットフォームでオリジンを効果的に守るには、公開トラフィックの入口を集約し、露出したIPを変更し、アクセスを許可リストで制限する必要があります。不要なドメインの整理、管理系システムの分離、継続的な露出監視も欠かせません。

金融取引システムでオリジンIPの保護が必要な理由

DDoS対策CDNの基本は、正規ユーザーの通信も攻撃トラフィックも、まずCDNのエッジを通すことです。

CDNはエッジでDDoSトラフィックをスクラビングし、HTTPフラッドを検知して、WAFルールとAPIアクセス制御を適用します。セキュリティチェックを通過したリクエストだけを金融プラットフォームのオリジンへ転送します。

本来のアクセス経路：ユーザーまたは攻撃トラフィック → CDN07のDDoS対策エッジ → セキュリティチェックとトラフィックスクラビング → 金融プラットフォームのオリジン

実際のオリジンIPが露出すると、攻撃者はCDNを迂回できます：攻撃トラフィック → 金融プラットフォームの実際のIPアドレス

CDNに十分な緩和能力があっても、CDNを通らないトラフィックはスクラビングできません。

攻撃者がサーバーへの侵入に成功する必要はありません。オリジンの帯域、接続数、ファイアウォールのセッションテーブルを使い切るだけで、次の障害が起こり得ます。

Webサイトやアプリにログインできない。
相場情報APIの応答が遅れる。
WebSocket接続が広範囲で切断される。
APIゲートウェイでタイムアウトが多発する。
注文や取消のリクエストが失敗する。
データベースや内部サービスとの接続が不安定になる。
クラウド事業者によるブラックホール処理やトラフィック制限が発動する。
プライマリとスタンバイのオリジンが同時に攻撃を受ける。

金融プラットフォームでは、オリジンIPの保護は任意の最適化ではありません。DDoS対策CDNを機能させるための前提です。

DDoS対策CDNを導入しても実際のIPが露出するのはなぜか

メインドメインをCDNに向ければオリジンIPも隠せる、と考えるプラットフォームは少なくありません。しかし攻撃者は、現在のメインドメインのDNSレコードだけを調べるわけではありません。

主な露出経路を見ていきます。

過去のDNS記録から旧オリジンが分かる

CDN導入前、金融サイトのメインドメインが米国、香港、シンガポールなどのサーバーに長期間直接向いていた可能性があります。

現在はCDNのアドレスに変更していても、過去の名前解決結果が履歴データベース、ネットワークスキャンシステム、第三者の監視サービスに保存されている場合があります。

CDN導入後も同じオリジンIPを使い続ければ、攻撃者はその記録からサーバーを特定できます。

対処方法

CDNへの切り替え後は、すでに露出した旧アドレスを使い続けず、オリジンのパブリックIPをできるだけ早く変更します。

旧IPが本番サービスを提供しておらず、新しいオリジンへの転送も行っていないことを確認してください。旧入口が残ると、攻撃者がそこからアプリケーションを追跡できます。

API、相場情報、WebSocketのサブドメインがCDNを経由していない

メインサイトはDDoS対策CDNを利用していても、ほかのサービス用ドメインが直接オリジンを指している場合があります。たとえば次のようなドメインです。

api.example.com
trade.example.com
quote.example.com
account.example.com
ws.example.com
download.example.com
upload.example.com

CDNを経由しないサブドメインが一つでもあれば、メインの取引システムと同じオリジンIPや、同じデータセンターのアドレス帯が判明する可能性があります。

特に注意したいのがアプリです。画面はCDNのドメインから読み込んでいても、ログイン、相場情報、取引のリクエストはAPIサーバーへ直接送られているかもしれません。Webサイトは守られているように見えても、取引システムの中核は露出したままです。

対処方法

公式サイトのドメインだけでなく、インターネットに公開されたすべての入口を棚卸しします。

Webサイト、アプリ、API、WebSocket、ファイルアップロード、ソフトウェアのダウンロード、公開コールバックは、それぞれのプロトコルと用途に合ったDDoS対策サービスを経由させます。

HTTP・HTTPSサービスはDDoS対策CDNでプロキシできます。HTTPプロキシを使えないTCPサービスには、DDoS対策TCPプロキシ、レイヤー4転送、または専用のネットワーク防御策が必要です。

アプリにサーバーIPがハードコードされている

DNS名前解決の時間を減らすため、古い金融アプリではクライアントの設定ファイルやコードにサーバーIPを直接書き込んでいる場合があります。ドメインとIPの両方を保持し、名前解決に失敗すると予備のIPへ自動接続するアプリもあります。

可用性を高める設計に見えても、オリジンを直接露出させるおそれがあります。

ユーザーの端末がそのIPを取得できるなら、攻撃者も公開されたアプリのパッケージ、ネットワークリクエスト、エラーログから見つけられる可能性があります。

対処方法

アプリからオリジンIPへ直接接続させないでください。公開リクエストはすべて、保護されたサービス用ドメインを通じてCDN07のDDoS対策ネットワークへ送ります。

予備の接続先が必要なら、実際のオリジンをクライアントの代替先にするのではなく、DDoS対策を適用した複数のドメインまたは入口アドレスを設定します。

アプリの設定を更新するときは、旧バージョンの利用者も考慮してください。最新版だけを修正しても、旧版からのオリジンの露出や直接アクセスは止まりません。

メール、サポート、ファイルサービスが取引システムとIPを共有している

サーバーリソースを節約するため、Webサイト、メール、カスタマーサポートの管理システム、ファイルダウンロード、取引APIを一つのパブリックIPで運用する金融プラットフォームがあります。

WebサイトをCDNに接続しても、メールサーバーのMXレコード、サポートシステム、ファイルサーバーが同じIPを直接公開している可能性があります。

攻撃者は取引用ドメインを調べる必要すらありません。同じアドレスを使う別のサービスを見つければ、CDNを迂回できます。

対処方法

取引システムの入口IPを、次のサービスと共有すべきではありません。

メールの送受信サーバー。
企業サイトの管理システム。
オンラインサポートシステム。
開発・テスト環境。
ファイル転送サービス。
リモート管理ポート。
監視・ログ基盤。
第三者のコールバックサービス。

対外メール、管理システム、社内業務システム、取引サービスには、別々のネットワークとパブリックアドレスを使います。重要度の低いシステムが露出しても、取引システムのオリジンまで判明しない構成が必要です。

テスト環境や一時ドメインから本番サーバーが露出する

開発チームがテスト、段階的リリース、一時的なAPI、旧バージョン用のドメインを作成していたかもしれません。公開後もレコードを削除していなければ、本番オリジンを指したままになる場合があります。

典型的な例は次のとおりです。

テスト用ドメインが本番IPを直接指している。
段階的リリース用のドメインがCDNを経由しない。
旧版アプリのドメインがまだ利用できる。
運用チームが一時的に作ったデバッグ用ドメインが残り続ける。
第三者の監視サービスが直接接続用のドメインを使っている。
スタンバイオリジンのドメインにインターネットからアクセスできる。

こうした入口には普段、正規ユーザーがほとんどアクセスしないため、セキュリティチームも見落としがちです。

対処方法

ドメインの資産台帳を整備し、DNSレコード、証明書、クラウドのロードバランサー、パブリックIPを定期的に確認します。

一時ドメインは使用後に停止します。内部監視やヘルスチェックは専用ネットワーク、プライベートアドレス、または厳格な認証を備えた入口を使います。監視の便宜のために、公開された直接接続用ドメインを恒久的に残してはいけません。

オリジンから第三者サービスへの通信で送信元アドレスが露出する

金融プラットフォームのオリジンは、決済サービス、メール基盤、相場情報の提供元、SMSサービス、不正取引対策システムなどに自ら接続する場合があります。

外向きの通信と内向きのサービスに同じパブリックIPを使うと、第三者のログ、エラー情報、コールバック設定にそのアドレスが記録される可能性があります。

第三者システム、セキュリティ対策が十分でない提携先、関連アカウントが侵害されれば、オリジンIPも漏れるおそれがあります。

対処方法

オリジンの受信用IPと送信用IPを分離します。

本番サーバーから第三者サービスへ接続する際は、別のNATゲートウェイまたは出口プロキシを利用できます。送信元アドレスが記録されても、ユーザーの通信を受けるオリジンの入口を直接特定できなくなります。

外部に公開するコールバック先もCDNまたはセキュリティゲートウェイのドメインを使い、第三者が取引システムの中核サーバーに直接接続しないようにします。

エラーページやレスポンスヘッダーからネットワーク構成が分かる

サーバーがエラーを返す際、レスポンスに次の情報が含まれる場合があります。

内部サーバーのアドレス。
上流ホスト名。
実際のポート番号。
リバースプロキシの情報。
デバッグ用パス。
クラウドのリージョン。
バックエンドサービス名。

パブリックIPを直接含まなくても、こうした情報を手掛かりに攻撃者がプラットフォームの構成を少しずつ推測できます。

対処方法

本番環境ではデバッグ情報を無効にし、エラーページの表示を統一して、公開する必要のないサーバーのレスポンスヘッダーを削除します。

CDN、リバースプロキシ、APIゲートウェイが返すのは、ユーザーに必要なエラー情報だけにします。詳細なスタックトレース、上流アドレス、内部ルートは保護されたログシステムにのみ保存します。

オリジンIPを効果的に保護するには

オリジンを守るには、DNSを一度変更するだけでは不十分です。次のような閉じたアクセスモデルを構築します。

インターネット上のユーザーはCDN07にのみアクセスでき、オリジンにはCDN07からしかアクセスできない。

このモデルの実現には、いくつかの重要な手順があります。

ステップ1：公開された入口をすべて把握する

まず、インターネットに公開された資産を網羅的に洗い出します。対象には次が含まれます。

Webサイトとモバイル向けページ。
静的リソース用ドメイン。
ログイン・認証API。
相場情報の照会API。
WebSocketによる相場情報配信用ドメイン。
口座・保有ポジションのAPI。
注文、取消、注文照会のAPI。
KYC書類のアップロード。
アプリのインストールファイルと更新サービス。
第三者向けコールバックAPI。
管理システムと運用担当者向けの入口。
プライマリオリジン、スタンバイオリジン、災害対策拠点。

現在使われている入口をすべて把握して初めて、DDoS対策CDNに通すべき通信と、非公開にすべきサービスを判断できます。

「メインドメインはCDNを使っているか」だけではなく、「オリジンに直接接続できる経路が残っていないか」を確認する必要があります。

ステップ2：公開サービスをCDN07経由にする

HTTP・HTTPSサービスは、DNSまたはCNAMEを使ってトラフィックをCDN07へ送れます。

CDN07はエッジで次の処理を行います。

HTTPS接続。
静的コンテンツのキャッシュ。
動的APIリクエストの転送。
WebSocketのプロキシ。
DDoSトラフィックのスクラビング。
HTTPフラッドの検知。
WAFによるアプリケーション保護。
APIリクエストのレート制限。
ボットや異常な挙動の検知。

ユーザーに見えるのはCDN07のDDoS対策エッジのアドレスであり、金融プラットフォームのオリジンアドレスではありません。

サービスごとに同じルールを適用することはできません。Webサイト、相場情報、口座サービス、取引APIには、それぞれ適切なキャッシュ、タイムアウト、レート制限、防御ポリシーを設定します。

ステップ3：一度も公開していない新しいオリジンIPへ移行する

以前に直接公開サービスを提供していたオリジンIPは、すでに露出したものとして扱います。

旧IPをそのままCDNの背後に置くだけでは不十分です。次の順に進めます。

CDN07に接続してサービスをテストする。
新しいオリジンIPを用意する。
本番サービスを新しいアドレスへ移行する。
CDN07のオリジン接続設定を更新する。
新しいオリジンがCDNからの接続だけを受け入れることを確認する。
旧IPでの本番サービスを停止する。
旧IPへの攻撃が続いていないか監視する。

新しいオリジンアドレスを、公開DNS、アプリのコード、メール設定、監視用ドメイン、第三者向けコールバックに記載してはいけません。

攻撃が旧IPに集中し続ける一方で新しいオリジンが安定していれば、移行によって過去の露出経路を効果的に断てたと判断できます。

ステップ4：ファイアウォールでCDN07からのオリジン接続だけを許可する

IPを非公開にすれば、オリジンが見つかる確率は下がります。CDNの迂回を防ぐ決め手は、ファイアウォールの許可リストです。

オリジンは不要なインターネットからのアクセスをすべて拒否し、次の通信だけを許可します。

CDN07のオリジン接続元ノード。
必要な内部サービス。
認可済みの運用ネットワーク。
プライマリ・スタンバイのデータベースおよび業務システム間の通信。
確認済みの監視システム。

攻撃者が偶然新しいIPを見つけても、許可リストにない送信元からWebサイトやAPIへ直接アクセスできません。

ファイアウォールの設定後、一般のインターネット回線からオリジンIPへ直接アクセスできないことと、CDN07からは正常にオリジンへ接続できることの両方を確認します。

ステップ5：CDNからオリジンへのリクエストも認証する

IPの許可リストだけに依存しないことも重要です。CDNからオリジンへのリクエストには、次のような認証を追加できます。

オリジンとの接続をHTTPSで暗号化する。
CDNとオリジン間の接続に使う証明書を検証する。
相互TLS認証を使用する。
専用のオリジンリクエストヘッダーを確認する。
機密性の高いAPIではリクエスト署名を検証する。
不明なHostヘッダーやSNIを拒否する。
オリジン認証用の鍵を定期的にローテーションする。

専用のリクエストヘッダーは防御を一層強化しますが、ファイアウォールの許可リストを代替するものではありません。通常のヘッダーは偽装できるため、送信元ネットワークの制限と認証を組み合わせてオリジンへの信頼できる境界を作ります。

ステップ6：管理システムを取引サービスの入口から分離する

運用管理システム、データベース管理、ログ基盤、サーバーへのリモートログインを、公開されたCDNドメインから直接アクセスできる状態にすべきではありません。

より安全なアクセス方法には、次のものがあります。

企業向けVPN。
ゼロトラストアクセスシステム。
踏み台サーバー。
専用の管理ネットワーク。
認証プロキシ。
多要素認証。
デバイスの信頼性確認。

管理プレーンはユーザー向けの取引サービスから分離する必要があります。公開サイトが攻撃を受けても、運用担当者が管理ツールにアクセスして障害対応できなければなりません。また、管理者アカウントに異常が起きても、取引システムの入口が直接露出しない構成が必要です。

ステップ7：実際のクライアントIPを伝える経路の信頼性を守る

CDN導入後、オリジンから見える接続元は通常、ユーザーの実際のIPではなく、CDNのオリジン接続元ノードです。一方、金融プラットフォームでは、ログイン時のリスク判定、デバイス識別、セキュリティ監査にクライアントIPが必要です。

CDN07は管理されたリクエストヘッダーで実際のクライアントIPをオリジンへ伝えられます。ただし、オリジンがそのヘッダーを信頼できるのは、リクエストの送信元がCDN07のオリジン接続元ノードである場合だけです。

インターネットからの任意のリクエストが「実際のIP」を示すヘッダーを送れるなら、攻撃者はクライアントの識別情報を偽装し、リスク判定や監査記録を乱す可能性があります。

したがって、信頼関係は次のように設計します。

インターネットからの通信はCDN07にだけ届く。
オリジンはCDN07のオリジン接続元アドレスからのリクエストだけを受け入れる。
CDN07が伝えたクライアントIPのヘッダーだけを信頼する。
APIゲートウェイでクライアントIP、口座、デバイス情報を一元的に記録する。

ステップ8：プライマリとスタンバイのオリジンに同じ安全境界を設ける

プライマリオリジンは守っていても、スタンバイオリジンにはインターネットから直接アクセスできるプラットフォームがあります。

攻撃者がスタンバイサーバーを見つければ、直接攻撃できるだけでなく、プライマリシステムをすでに攻撃で飽和した災害対策環境へ切り替えさせることもできます。

プライマリオリジン、スタンバイオリジン、災害対策拠点のすべてで、次を徹底します。

実際のIPを保護する。
CDN07からのオリジン接続だけを許可する。
HTTPSまたは相互TLSを使用する。
不要なポートを閉じる。
同じセキュリティ基準を適用する。
監視とアラートを一元化する。
定期的にフェイルオーバーをテストする。

災害対策システムは「普段使わないから防御を弱めてよい」ものではありません。重要なサービスをいつでも引き継げる必要があります。

証券プラットフォームのFIXやTCPなど、HTTP以外の通信はどう守るか

証券プラットフォームによっては、WebサイトやREST APIに加えて、FIX、独自のTCPプロトコル、その他のレイヤー4の長時間接続を使用します。

一般的なHTTP CDNでは、こうした通信をプロキシできません。インターネットへ直接公開したままでは、その経路から主要データセンターを発見されたり、攻撃されたりする可能性があります。

CDN07はプロトコルに応じて、DDoS対策TCPプロキシ、レイヤー4転送、独立した防御用入口を設定できます。ユーザーや提携機関がまずDDoS対策済みのアドレスへ接続し、保護された経路を通じて実際のサーバーへ転送します。

FIXなどの機関投資家向け取引APIには、次の対策も組み合わせます。

取引相手の固定アドレスを許可リストに登録する。
相互証明書認証を使用する。
専用線または暗号化トンネルを使用する。
ポートとネットワーク領域を分離する。
セッション単位で認証する。
接続数とリクエスト頻度を制限する。

一般ユーザー向けWebサイトの防御と、機関向け取引チャネルの防御は、別々に設計する必要があります。

オリジンIPの保護でよくある誤解

誤解1：ドメインをCDNに向ければオリジンは安全になる

オリジンがインターネット上のあらゆるIPからの接続を受け入れるなら、アドレスを見つけた攻撃者はCDNを迂回できます。

誤解2：問題が起きた場合に備え、旧IPを残しておく

旧IPから新システムにつながる状態を残せば、攻撃者にとってDDoS対策ネットワークを迂回する予備経路になります。切り戻しには、公開された旧オリジンではなく、保護された予備ドメインとエッジ拠点を使います。

誤解3：Webサイトだけ守ればよく、APIの保護は不要

金融プラットフォームでは、APIや相場情報システムがWebサイト以上に重要な場合があります。攻撃者はトップページを無視して、ログイン、相場情報、取引のAPIを直接狙えます。

誤解4：秘密のリクエストヘッダーだけで十分

ヘッダーは偽装できます。オリジンのファイアウォール許可リスト、CDNからオリジンへのHTTPS接続、必要な認証を併用しなければなりません。

誤解5：オリジンIPは知られていないので変更しなくてよい

一度でも公開されたIPは、どこかに記録されている可能性があります。過去のDNS、監視サービス、アプリ、第三者のシステムにアドレスが残っているかもしれません。

誤解6：防御帯域が十分ならIPを隠す必要はない

どれほど大きな緩和能力でも、防御エッジを通るトラフィックしかスクラビングできません。攻撃が直接オリジンに届く場合、エッジの防御帯域は役に立ちません。

オリジンIPが本当に保護されているか確認する方法

導入後は、CDNの管理画面に「接続済み」と表示されるだけで判断せず、独立した検証を行います。

確認する項目は次のとおりです。

公開ドメインがすべてCDN07を指しているか。
過去のドメインや一時ドメインが新しいオリジンを指していないか。
アプリにIPや直接接続用アドレスがハードコードされていないか。
APIとWebSocketの通信がすべてDDoS対策エッジを経由するか。
メール、サポート、ダウンロードのサービスが取引オリジンとIPを共有していないか。
一般のインターネット回線からオリジンに直接アクセスできないか。
正しいHostヘッダーや認証情報を伴わないリクエストが拒否されるか。
オリジンのファイアウォールがCDN07からの接続だけを許可しているか。
管理ポートがインターネットに公開されていないか。
プライマリとスタンバイのオリジンに同じ防御ポリシーが適用されているか。
ログに実際のクライアントIPが正しく記録されているか。
旧オリジンIPでのサービスが完全に停止しているか。

オリジンIPの保護は一度設定すれば終わるものではありません。ドメインの追加、アプリの新バージョン、データセンターの移転、第三者サービスとの連携によって、新たな露出経路が生まれる可能性があります。

CDN07は金融取引システムのオリジンをどう保護するか

CDN07は金融サイトの前に単にプロキシを置くのではなく、インターネットからの入口からオリジンまでの安全境界を構築します。

金融・証券プラットフォーム向けに、CDN07は次の機能を提供できます。

Webサイト、アプリ、API、WebSocketの入口をまとめてDDoS対策ネットワークで保護する。
DDoSトラフィックのスクラビングとHTTPフラッド対策。
WAFとAPIアクセス制御。
動的リクエストと越境ネットワーク経路の高速化。
オリジンIPの保護。
オリジン接続元の許可リスト。
HTTPSで暗号化したオリジン接続。
オリジンリクエストの認証。
複数オリジンのヘルスチェック。
自動フェイルオーバー。
リアルタイムのログと攻撃アラート。
TCPなどHTTP以外のサービス向けDDoS対策接続。

プラットフォームは、米国、香港、シンガポールなどの既存サーバーを維持したまま、ドメイン経由で段階的にトラフィックを移行できます。CDN07はWebサイト、相場情報、ログイン、口座、取引サービスそれぞれの特性に応じて、キャッシュ、動的通信の高速化、防御、オリジン接続のルールを設定できます。

すでに露出した旧IPについても、CDN07はプラットフォームと協力し、オリジンアドレスの変更、段階的なトラフィック切り替え、ファイアウォールのアクセス制限を進められます。すべての取引サービスを一度に切り替える必要はありません。Webサイトと静的リソースから始め、相場情報、API、WebSocketを順次接続できます。

目指すのは「ドメインからオリジンが見えない」状態だけではありません。次のような一連の防御を確立することです。

攻撃トラフィックはCDN07のDDoS対策エッジでスクラビングし、正規リクエストは保護された越境経路を通ってオリジンへ届く。実際のサーバーは、認可されていないインターネットからの接続を受け付けない。

取引システムまで守る

金融・証券プラットフォームで最も危険なのは、CDNを導入しただけで安全になったと思い込むことです。

旧ドメイン、APIレコード、アプリの予備アドレス、テストサーバーのどれか一つでも実際のIPを露出させていれば、攻撃者はDDoS対策エッジを迂回し、取引システムを直接狙えます。

オリジンを効果的に保護するには、次のすべてが必要です。