CloudflareとAWSで進めるレガシー攻撃面の段階的モダナイゼーション
文書番号：2609.00009
要旨
非API型の既存Webシステムを全面刷新する前に、外部から到達できる機能と入力を段階的に限定する設計を検討するのだ。Cloudflareを共通の入口とし、AWS上の透明プロキシで互換性を確認した後、観測した通信からAIがAPI契約と変換処理の候補を生成し、業務単位の検証を経て新しい公開境界へ移す計画なのだ。移行の完了条件はAPIの生成数ではなく、正常な業務を維持したまま旧経路と未承認の操作を閉じたことを確認できる状態なのだ。
本稿は2026年9月14日時点の製品文書と設計上の考察に基づく計画であり、実装済みの性能や安全性を示す実験報告ではないのだ。特に、観測通信からの仕様推定、状態を持つ業務の変換、二つの製品間の検証差分を、移行判断の中心に置くのだ。
1. 問いと対象範囲
長年稼働するWebシステムでは、業務ロジック、データ、バッチ、外部連携を維持しながら公開境界を改善する必要があるのだ。本稿の問いは「内部の全面刷新を待たずに、外部利用者が操作できる範囲をどう縮めるか」なのだ。対象はHTTP(S)で提供され、Cookie、フォーム送信、画面遷移、サーバー側セッションを利用する既存Webなのだ。
ここでいう攻撃面のモダナイゼーションは、公開する操作、入力、利用主体、到達経路を整理し、それらを新しい境界で制御することなのだ。内部の脆弱性の修正や保守期限への対応は、引き続き別の計画として必要なのだ。
基本原則は既存記事のレガシーシステムは捨てなくていいで扱っているのだ。本稿ではCloudflareとAWSを使う場合の工程、生成物、昇格条件を具体化するのだ。AWSのStrangler fig patternは、プロキシを介して新旧の機能を共存させ、段階的に移す方式なのだ。本計画はこの構造を公開境界の縮小へ応用する設計なのだ。1
2. 二つの通信経路と責任分担
移行開始時とAPI化後では、必要な経路が異なるのだ。最初から古いWebの全通信をAPI Gatewayへ移すと、フォーム、ファイル転送、リダイレクトなどの互換性確認と、業務のAPI設計を同時に抱えることになるのだ。本計画では次の二経路を分けるのだ。
| 段階 | 通信経路 | 主な役割 |
|---|---|---|
| 透明プロキシ化 | 利用者 → Cloudflare → ALB → ECS上のプロキシ → 既存Web | 既存の業務動作を維持し、境界で制御・観測 |
| API化した機能 | 新UI／APIクライアント → Cloudflare → API Gateway REST API → VPC Link V2 → Private ALB → BFF／Adapter → 既存Web | 公開操作と入力を限定し、既存処理へ変換 |
BFFはフロントエンドに必要なAPIを提供する層、Legacy Adapterはその操作を既存Webの通信へ翻訳する層なのだ。例えば「注文確定」を受け、既存画面の確認用情報を取得し、必要なセッションとCSRFトークンを使ってフォームを送信する処理をAdapterへまとめるのだ。両者を同じサービスへ実装する場合も、外部契約と内部変換の責任を分けるのだ。
AWSの現行文書では、REST APIからVPC Link V2を使ってALBへプライベート統合できるのだ。REST API、VPC Link、ロードバランサーは同一AWSアカウントに置く条件があるのだ。バックエンドへのステージ名の付加やHTTPS設定も、接続試験で確認する必要があるのだ。2
プライベート統合はAPI Gatewayからバックエンドへの接続を指し、APIの公開入口まで非公開になることを意味しないのだ。API経路ではRegionalカスタムドメインのmTLSと、既定のexecute-apiエンドポイントの無効化を組み合わせる設計なのだ。Workersからの接続にはmTLS bindingを利用できるのだ。345
ただし、CloudflareからAWSへ接続する証明書は、エンドユーザーの業務権限を表すものではないのだ。利用者の認証、対象データへの認可、Adapterが引き継ぐセッションの対応関係は別に検証するのだ。クライアントが任意に指定したユーザーIDや転送ヘッダーを、そのまま権限の根拠にしない設計が必要なのだ。
3. DNS切替前に用意するもの
本計画ではDNS切替を本番移行の開始点とするため、それ以前に新経路で主要業務を再現できる状態を作るのだ。Cloudflare、AWS、既存システムの間で、接続先、証明書、タイムアウト、ログの相関、障害時の責任者を確定するのだ。
| 確認領域 | 切替前に残す証拠 |
|---|---|
| 業務互換性 | ログイン、検索、更新、ログアウト、アップロード、例外処理の試験結果 |
| HTTPの扱い | Host、Cookie属性、リダイレクト先、文字コード、圧縮、キャッシュ条件の比較 |
| 到達経路 | 旧IP、別名DNS、IPv6、管理画面を含む入口台帳と許可元の設定 |
| TLSと接続 | 各区間の証明書検証、AWSから既存Webへの限定接続、接続失敗時の挙動 |
| 観測 | 境界で採番・管理したRequest IDと各層のログを追跡できる例 |
| 性能と停止判断 | 現行の応答時間・エラー率・業務完了率、移行後の許容値と中止条件 |
| 復旧 | 経路・設定・セッションを含む切戻し手順と実行結果 |
| データ管理 | 取得項目、マスキング、保存期間、AIへの提供範囲、閲覧権限 |
「透明」は業務上の意味を保つ目標であり、HTTPの全バイトが不変という意味ではないのだ。特に認証後のページを共有キャッシュへ保存する設定や、旧ホスト名への絶対リダイレクトは、切替前の確認対象なのだ。AWSと既存環境はVPNやDirect Connectなどで接続する案とし、必要な宛先とポートを限定するのだ。
DNSを変更しても旧IPへの直通経路は残り得るため、移行中の旧入口をどの時点で制限するかも決めるのだ。通常の切戻し先は、可能な限りCloudflareを通る既存処理経路として保持するのだ。防御境界を外す緊急復旧は、別の判断、期限、監視を伴う手順として定義するのだ。DNSのキャッシュや既存接続があるため、DNS操作だけで即時に全利用者を戻せると想定しないのだ。
4. 観測からAPI候補を作る
4.1 観測された通信と正しい仕様を分ける
透明プロキシを通る通信から、Path、Method、Content-Type、パラメーター、ステータス、画面遷移、処理時間を整理するのだ。本文やCookieが必要な場合は、通常のアクセスログとは別に取得範囲を設計し、秘密情報を収集段階で除去するのだ。生の認証情報を保存してからAIの直前で隠す方式より、不要な情報を初めから残さない構成を優先するのだ。
Cloudflare API DiscoveryはAPIエンドポイントの発見を補助する機能なのだ。Schema Learningは対象Operationの通信からフィールドや制約を学習する機能で、確認時点では過去7日間の対象通信を週次処理し、2xx応答のリクエストを用いるのだ。これは非API型Webの業務手順を理解する機能とは分けて扱うのだ。67
認証済み、2xx応答、既知のクライアントという条件は、学習対象を絞る手掛かりなのだ。ただし、権限を悪用した操作やアプリケーションが受理した不正入力も含まれ得るため、正しさの証明にはならないのだ。月次処理、エラーからの回復、低頻度の管理操作も通常観測から漏れるため、業務担当者の確認と合成試験で補うのだ。
AIへ与えるHTTP本文や公開情報は、命令ではなく分析対象のデータとして扱うのだ。取得先やツールの実行権限を分離し、通信内の文章によってデプロイや外部送信が起動しない構成にするのだ。
4.2 AIの生成物を業務単位で管理する
本計画でAIが生成するものは、OpenAPI、BFF、Legacy Adapter、回帰試験、セキュリティ試験の変更候補なのだ。本番の受信通信に反応して稼働コードを自己改変する構造ではなく、Git上の差分をレビューし、CI/CDで検証して採用する構造なのだ。
例えば検索、対象選択、確認、確定という画面列をAPIへ変換するなら、何が一つの業務操作か、どこで状態が確定するか、誰が操作できるかを先に定義するのだ。URLの置換だけでは、業務上の境界は定まらないのだ。
| 生成物 | 人が確認する内容 |
|---|---|
| OpenAPI | 公開する操作、必須項目、入力の上限、エラー表現 |
| BFF | 利用者の認証、オブジェクト単位の認可、応答から除く情報 |
| Adapter | セッション分離、CSRF、画面遷移、送信先の固定、再試行の扱い |
| 回帰試験 | 通常業務、低頻度業務、取消し、エラー回復、並行実行 |
| セキュリティ試験 | 越権操作、別利用者のセッション混入、未定義操作、不正入力 |
Adapterを任意URLへアクセスできる汎用プロキシにすると、新しい迂回経路を作ることになるのだ。操作から接続先への対応を固定し、利用者間でCookieや一時状態が混ざらない実装を昇格条件にするのだ。
5. Shadow検証と段階昇格
5.1 読取りと書込みで検証方法を変える
読取り操作は、副作用がないことを確認したうえで旧経路と新経路を並行実行し、業務上の結果と応答時間を比較するのだ。GETというMethodだけで読取り専用と判定せず、既読化、通知、監査状態などへの影響を調べるのだ。
書込み操作では、本番の既存Webへ新旧リクエストを二重送信しないのだ。資料が提案する往復変換の検証は、観測した旧リクエストをAPIの操作へ変換し、Adapterから旧形式を再生成して比較する方法なのだ。
旧リクエスト L
→ APIの業務操作
→ Adapterが再生成した旧リクエスト L'
正規化(L) と 正規化(L') を比較
本番の書込み先へ L' は送信しない
この比較で確認できるのは変換の整合性なのだ。残高更新、権限判定、競合時の処理、外部への通知まで同等に動くかは、分離した検証環境で状態の前後を確認する必要があるのだ。CSRFトークンや時刻のような変動値を正規化する場合も、必要な対応関係まで消してしまわない規則を用意するのだ。
特に、書込み後にタイムアウトした場合は、処理済みか未処理かを照会できる仕組みが必要なのだ。冪等性キーを新APIへ付けるだけで既存処理まで自動的に冪等になると考えず、再試行、重複検出、結果照会を一組で設計するのだ。
5.2 昇格と切戻しをセッションに合わせる
新経路への昇格は業務機能ごとに行い、少数の対象から段階的に広げるのだ。複数画面にまたがる処理では、リクエストごとのランダム振分けで新旧を混在させず、利用者やセッションに対して一貫した経路を割り当てるのだ。
エラー率だけでなく、業務完了率、重複更新、照合差分、認可エラー、待ち時間を監視するのだ。判定値は切替前に現行値と業務要件から決め、問題が起きてから合格基準を緩めない運用にするのだ。
旧HTMLやフォームを利用者が使い続ける段階では、内部にAPIがあっても外部の旧インターフェースは残るのだ。対象機能のUIも移行し、旧Pathを拒否して初めて、その機能の公開面を縮退できるのだ。切戻しで稼働中の状態を扱えるように、進行中の処理を完了させるか中断するかも定めるのだ。
6. 同じ契約から二層の検証を作る条件
Positive Securityは、許可する操作と入力を定義し、その範囲へ通信を制約する考え方として用いるのだ。ただし、OpenAPIを二つの製品へ登録するだけで、全制約が同じように強制されるとは限らないのだ。
CloudflareのSchema Validationは、確認時点でOpenAPI 3.0系を対象とし、リクエスト本文の検証はapplication/jsonに対応するのだ。サイズ上限を超える本文や未対応の定義も考慮する必要があるのだ。また、Schema違反の検知自体は遮断を行わず、Custom Rulesで強制する構造なのだ。未登録Operationへの通信も、別途fallthroughの扱いを定義するのだ。8
API Gateway REST APIの基本検証は、必須パラメーターの存在と非空を確認する一方、その型や形式までは確認しないのだ。本文は対応するモデルで検証するが、Content-Typeに合うモデルがなければ検証されない条件があるのだ。9
この差分を踏まえ、本計画ではOpenAPIと補助ポリシーを正本として、製品別の設定を生成し、受理・拒否が期待どおりになるかを同じ試験ケースで確認するのだ。未対応の制約はBFF／Adapterで検証するか、公開範囲を狭めるのだ。構文上正しい入力への認可、回数制限、業務状態の検証も、担当する層を明示するのだ。
| 確認項目 | 合格の判断 |
|---|---|
| 定義済みの正常リクエスト | 認可された利用者が期待した業務結果を取得 |
| 未定義Path／Method | 適用範囲内で拒否し、透明プロキシへ迂回しない |
| 未対応Content-Type／サイズ超過 | 未検査のまま通さず、拒否または担当層で検証 |
| 形式は正常だが越権した操作 | 対象データの権限判定で拒否 |
| 旧IP／別名／既定エンドポイント | 承認された公開経路を迂回した業務実行を拒否 |
7. 継続運用と脆弱性へのフィードバック
7.1 ポリシー変更と既存Webの変更を追跡する
WAF、レート制限、API契約は、観測、変更提案、検知・ログ評価、回帰試験、限定適用、全面適用の順に更新するのだ。利用する機能や契約でログ専用動作が使えない場合は、非本番や限定範囲で代替評価するのだ。遮断数の増加だけで改善と判断せず、正常業務への影響と回帰試験の結果を合わせて判断するのだ。
既存Webの変更検知には、本番観測、定期的な合成試験、既存システムのリリース通知を併用するのだ。AIが差分からAdapterや試験を修正しても、外部契約を広げる変更や認可の変更は別に審査するのだ。旧Webの挙動が変わるたびに許可範囲を自動拡張すると、維持したい境界そのものが弱くなるのだ。
各変更には、契約版、Adapter版、ポリシー版、試験結果、承認者、切戻し先を結び付けるのだ。互換性のある変更を自動昇格する場合も、事前に許可した差分の種類と停止条件を決めるのだ。
7.2 到達可能性を三つの結果で記録する
脆弱性情報はCISA KEV、NVD、ベンダーのアドバイザリーを入口にし、構成情報、SBOM、公開Operationへ対応付ける設計なのだ。KEVは実際に悪用された脆弱性のカタログであり、優先順位付けの入力として用いるものなのだ。10 NVDの情報も利用できるが、製品・版・設定との照合は対象環境で行う必要があるのだ。11
AIには「どの入口から、どの権限と入力を使うと、対象コンポーネントへ到達し得るか」という仮説と試験候補を作らせるのだ。実行は許可された検証環境を基本とし、対象範囲、停止条件、負荷、証拠の扱いを定めるのだ。NIST SP 800-115は、技術的なセキュリティ評価の計画、実施、結果分析、対策の検討を扱う指針なのだ。12
| 結果 | 記録する内容 | 運用への反映 |
|---|---|---|
| 到達または悪用条件を確認 | 入口、権限、入力、到達段階、観測証拠 | 影響に応じて修正を優先し、暫定防御も検証 |
| 検証条件下で遮断を確認 | 対象経路、遮断した層、適用版、ログ | 残存リスクと再検証条件を記録 |
| 判定不能 | 試験不足、環境差分、観測不足、未確認の前提 | 追加確認と期限を設定 |
到達と悪用成功は区別するのだ。また、試験が成功しなかっただけで「到達不能」と確定せず、遮断の証拠がある条件に限定して記述するのだ。境界での暫定防御はパッチ適用計画と併記し、設定変更や新経路の追加後に再検証するのだ。
8. 工程の完了条件と水平展開
工程は日数で一律に区切らず、各段階の証拠で次へ進む計画なのだ。添付計画の「透明化、観測、生成、昇格、縮退」を、次の判定条件へ整理したのだ。
| 工程 | 次へ進む条件 |
|---|---|
| 基盤準備 | 主要業務、ログ相関、限定接続、切戻しを試験済み |
| 透明プロキシ化 | 実利用で互換性とサービス目標を満たし、迂回経路を把握 |
| 観測・契約設計 | 業務担当者が操作・権限・例外を確認し、未観測部分を明示 |
| 生成・Shadow検証 | 変換比較と分離環境の状態検証に合格し、差分を説明可能 |
| Canary昇格 | 対象群の業務結果が基準内で、進行中の状態も復旧可能 |
| 公開面の縮退 | 旧UI／Path、別名、直接接続から対象業務を実行できないことを確認 |
| 継続運用 | 契約変更、脆弱性、再検証、暫定対策の期限を担当者が追跡 |
複数システムへ展開する場合は、ログ基盤、設計基準、IaC、試験の形式を共通化し、実行環境、認証情報、Adapter、デプロイ単位を分離する案なのだ。AWS SRAの複数アカウント構成を参照し、共通基盤とWorkloadの責任を整理するのだ。13 共通ポリシーにも障害を広げる可能性があるため、全システムへの適用には段階配布と個別の停止手段を持たせるのだ。
進捗指標は、生成したAPI数に加え、廃止した旧経路、許可外操作の拒否試験、業務回帰試験の対象範囲、切戻し所要時間、未解決の判定不能件数を用いる案なのだ。API数が増えても旧経路が残るなら、攻撃面縮小の成果とは分けて報告するのだ。
9. 考察と限界
この計画の難所は、既存Webが暗黙に持つ状態と業務規則を、新しい公開契約へ移す作業なのだ。複雑なブラウザー側処理、外部サイトをまたぐ認証、長時間の処理、巨大ファイル転送などは、単純なHTTP Adapterでは扱いにくい可能性があるのだ。機能ごとに適用可否を確認し、専用の移行方式や既存側の変更を選ぶ余地を残すのだ。
また、プロキシ、観測基盤、生成パイプライン、Adapterを追加すれば、運用費用と保守対象も増えるのだ。DDoS対策やWAFの導入による効果は期待できるものの、本稿では費用対効果、誤検知率、応答時間、AI生成の成功率を測定していないのだ。PoCでは小さな読取り機能と状態を持つ書込み機能を選び、互換性、認可、復旧、旧経路遮断まで評価するのだ。
10. 結論
レガシーの攻撃面を段階的に改善するには、透明プロキシによる経路の集約から始め、業務操作の契約化、Adapterの検証、新UI／APIへの移行、旧公開経路の遮断までを一つの工程として扱うのだ。CloudflareとAWSはその境界を構成する基盤であり、AIは契約・実装・試験の候補作成を支援する位置付けなのだ。
移行の判断を支えるのは、業務が維持される証拠と、許可していない経路・操作が拒否される証拠なのだ。この二つを工程ごとに確認することで、全面刷新と独立して公開境界を改善し、その後の刷新範囲も選びやすくするのだ。
参考資料（出典）
構想の基礎は『レガシーの攻撃面モダナイゼーション計画 ― Cloudflare＋AWSとAIによる段階的な外部Attack Surface再設計』（2026年9月、提供資料）なのだ。以下の一次資料で製品の条件を確認し、工程の判定条件と残存リスクを本稿の設計考察として補ったのだ。