Cloudflareで金融機関の安全な運用を支える方法

銀行や証券会社のWebサービスは、止められないうえに、扱う情報も重要です。DDoS攻撃に耐えること、顧客情報を守ること、変更の記録を残すこと。そのすべてを同時に求められます。

Cloudflare Enterpriseは有力な選択肢ですが、導入しただけでFISCの安全対策基準を満たせるわけではありません。自社のリスク評価と責任分担を土台に、Cloudflareの機能をどう組み込むか。金融機関ならではの検討点を整理します。

金融機関に求められるFISC基準と運用管理

「製品が準拠」ではなくシステム全体で考える

FISCの「金融機関等コンピュータシステムの安全対策基準・解説書」は、金融情報システムの開発、導入、運用などで必要と考えられる安全対策を示したものです。2026年3月には第14版が刊行されています。※

ここで注意したいのは、特定のクラウド製品を入れれば自動的に基準を満たす、という性質ではないことです。対象システムの重要度、利用する機能、運用体制、外部委託先を含めて評価します。Cloudflareが担う範囲と、金融機関・SIer・クラウド事業者が担う範囲を線引きすることが出発点です。

外部委託先まで含めて確認する

Cloudflareの契約相手が代理店やSIerであれば、障害対応や設定変更の窓口も含めて確認します。再委託の有無、インシデント時の報告時間、監査資料の提供範囲、契約終了時のデータや権限の扱いなど、技術以外の論点も少なくありません。

「24時間対応」という言葉だけでは判断できないため、受付、一次切り分け、Cloudflareへのエスカレーション、復旧判断を誰が行うのかを表にします。年次の見直しや監査対応まで依頼できるかも、運用費用とあわせて比べたいところです。

証跡を残せる運用にする

金融システムでは、攻撃を止めた事実だけでなく、誰が、いつ、何を変更したかを追えることが欠かせません。CloudflareのAudit Logsでは、ダッシュボードやAPIなどを介した操作履歴を確認できます。必要に応じてLogpushで外部の保管先やSIEMへ送る設計も検討します。

保存期間、閲覧権限、時刻同期、アラートの条件は、自社の規程と合わせます。緊急時に一時的なルールを追加した場合も、承認者と戻し忘れを確認できる流れを作っておくと、監査で説明しやすくなります。

Cloudflare Enterpriseの設計ポイント

公開サービスと社内アクセスを分ける

インターネットバンキングや会員サイトなどの公開サービスには、DDoS防御、WAF、Bot対策、API保護が関係します。一方、社内システムや管理画面へのアクセスには、Cloudflare OneのAccessやGatewayなどが候補になります。

同じCloudflareのサービスでも目的は違います。顧客向け通信と従業員向け通信を一つの構成図に詰め込まず、利用者、認証方法、通信先、ログの保管先を分けて整理しましょう。段階導入なら、影響を限定しながらルールを調整できます。

ゼロトラストはID連携後の運用が本番

Cloudflare Oneを使ったゼロトラストでは、IDプロバイダーと連携し、利用者の属性や端末状態に応じてアクセスを制御できます。ただし、認証が通ることと、必要最小限の権限になっていることは別です。

人事異動や退職、委託先の契約終了に合わせて権限を変える仕組みが必要です。例外ルールを誰が承認するのか、端末チェックに失敗した場合の問い合わせ先はどこか。実際の業務フローまで決めて、初めて運用が回り始めます。

データの処理場所と保存場所を確認する

規制や社内方針によっては、TLS鍵、HTTPS通信の処理、ログの保存場所が論点になります。CloudflareのData Localization Suiteには、Geo Key Manager、Regional Services、Customer Metadata Boundaryがありますが、それぞれ制御する対象と利用可能な地域が異なります。

たとえばCustomer Metadata Boundaryは、選択地域に顧客ログを保存する機能で、既定では境界が適用されません。日本国内だけに限定できると決めつけず、対象製品との互換性と選べる地域を公式情報で確認します。要件が合わない場合は、ログへ含める情報やシステム構成自体の見直しも必要です。

大規模導入を任せるSIerの選び方

要件整理から参加できる会社を選ぶ

金融機関での導入は、DNSを切り替えて終わる仕事ではありません。既存WAF、認証基盤、SOC、クラウド、データセンターとの接続を整理し、どの機能を残して何をCloudflareへ移すかを決めます。

製品説明だけでなく、現行調査、リスク評価、移行計画、テスト、監査資料の整備まで提案できる会社が向いています。FISC基準への対応経験がある場合も、どの業務とシステムを担当したのか、具体的に確かめましょう。

移行中の二重運用と切り戻しを確認

重要な金融サービスを一度に切り替えるのはリスクがあります。対象ドメインや通信を分け、既存環境と並行して検証する計画が現実的です。負荷試験や障害試験だけでなく、誤検知、証明書、外部API、バッチ処理への影響も見ます。

想定外の挙動が出たとき、どの条件で切り戻すのか。DNSのTTL、旧環境を残す期間、意思決定者まで決めておくと、当日の迷いを減らせます。作業手順書だけでなく、判断基準が用意されているかが重要です。

導入後の内製化まで見通す

大手SIerへ任せる場合でも、設定内容が見えない状態は避けたいところです。ルールの命名方法、変更申請、ログの見方、日常点検を共有してもらい、金融機関側にも判断できる担当者を育てます。

CloudflareとFISC対応の関係は、「準拠できる製品か」だけでなく「説明できる運用か」で考えると見通しがよくなります。責任分担と証跡、変更管理を先に固め、必要なEnterprise機能を選びましょう。業種ごとのCloudflare活用は、Cloudflareの業種・用途別ガイドでも紹介しています。