メインコンテンツまでスキップ

レガシーシステムは捨てなくていい

レガシーシステムは捨てなくていいの結論、主分析、判断材料、前提と限界を一枚にまとめた詳細図

先に結論​

レガシーシステムは、すべてを一度に作り直さなくても公開境界から変えられる。外部利用者が古いWeb実装へ直接到達する経路を閉じ、API GatewayとWAF、必要に応じて媒介層を唯一の入口にする。公開機能、Method、入力、認証、流量を限定し、その内側で既存処理を動かすのだ。

ただし、Gatewayを前に置いただけでは攻撃面は減らない。旧DomainやOrigin IPから直接到達できるなら入口が増えただけである。GatewayはBackendのCVEを消さず、パッチを不要にもしない。悪用に必要な到達経路や入力を狭め、パッチ適用と段階的移行までの時間を稼ぐ統制として扱う。

レガシーシステムとは、古いというだけで捨てられない既存システムである。何十年分もの業務規則やデータを持ち、毎日の受注、会計、生産、顧客対応を支えていることがある。新しい技術へ一度に置き換えればよいように見えても、仕様を知る人が少ない、停止できる時間が短い、他システムとの接続が多いといった事情で、全面刷新は大きな危険を伴う。

そこで、「中身をすぐ全部作り直す」問題と、「インターネットからどのように触れられるか」問題を分ける。家全体を建て直せなくても、使っていない勝手口を閉じ、受付を一か所へ集め、受付から必要な部屋だけへ案内することはできる。API Gatewayは受付、WAFは入口での危険物検査、媒介層は新しい申請書を古い社内書式へ翻訳する担当に近い。

ただし、入口を置いただけでは安全にならない。古い勝手口が開いたままなら迂回される。翻訳担当が利用者の入力をそのまま古いシステムへ渡せば、危険な機能まで呼べるかもしれない。境界を作るとは、公開機能を限定し、直接経路を閉じ、その状態を外部から確認することなのだ。

悪い構成

Internet ----> API Gateway ----> Legacy
    |
    `---------------------------> Legacyの旧URL / Origin IP


目指す構成

Internet
    |
    v
API Gateway + WAF
    |
    v
媒介層 / Adapter
    |
    +------> Legacy
    |
    `------> Modern Services

LegacyはGateway経由の通信だけを受け付ける

上の図で最も重要なのは、中央にGatewayがあることではない。下にある「LegacyはGateway経由の通信だけを受け付ける」という条件である。悪い構成では、正面入口と旧入口の両方が開いている。目指す構成では、利用者が必ず検査と制御のある入口を通る。

レガシーはなぜ簡単に捨てられないのか​

古いシステムには問題が多い。それでも使われ続けるのは、単なる怠慢とは限らない。長年の例外処理、取引先ごとの形式、過去データ、法令対応、月末処理などが内部へ蓄積しているからである。設計書に残っていない規則を、古いプログラムだけが知っていることもある。

たとえば「顧客区分Aには月末だけ特別な値引きを適用する」という処理があるとする。担当者は当然の業務として知っていても、現行の設計書に書かれていないかもしれない。新システムへ一括移行し、その例外を落とせば、技術的には動いても業務上は誤った請求を作る。

また、Legacyは一つで完結していないことが多い。夜間にFileを受け渡す、特定の端末からだけ接続する、帳票を印刷する、別部門のDatabaseを直接読む、といった依存がある。画面だけを新しくしても、背後の依存は残る。

したがって、最初にすべきことは「古いから交換する」という宣言ではない。どの機能が誰に使われ、どのDataを読み書きし、どの外部経路から到達できるかを調べることである。そのうえで、公開境界の改善と機能移行を分けて計画するのだ。

レガシーの問題を二つに分ける​

レガシーには「内部に古い実装や脆弱な依存関係があること」と「その実装へ外部から到達できること」という別の問題がある。前者は修正、更新、置換が必要である。後者はネットワーク、公開経路、認証、入力制約によって先に縮小できる。

脆弱性の存在と悪用可能性は同じではない。攻撃成立に特定のPath、Method、Content-Type、Header、Parser、認証状態が必要なら、その前提を境界で崩せる可能性がある。ただし、到達不能という主張には実測証拠が必要である。

問い確認内容
脆弱性はどこにあるかFramework、Library、Legacy Endpoint、Parser、管理機能
攻撃の前提は何か到達経路、認証、Method、Content-Type、入力形状、権限
境界で崩せる前提は何か公開Path、Method、Schema、Size、Header、送信元、相互認証
境界で崩せない前提は何かBackend内部呼出、業務認可、保存済みデータ、内部侵害後の経路
修正まで何をするかOrigin遮断、仮想パッチ、監視、例外期限、Patch、置換

一つ目の「内部が古い」は、使用言語、OS、Library、Database、設計、保守体制などの問題である。脆弱性が見つかっても更新できない、担当者しか変更方法を知らない、試験環境を再現できない、といった課題が含まれる。これは長期的に解消する必要がある。

二つ目の「外から広く触れる」は、公開範囲の問題である。古い管理画面、使われていないURL、不要なMethod、直接接続用のDomainやIP Addressが残っていれば、攻撃者が試せる入口が増える。この範囲をAttack Surface、つまり攻撃面と呼ぶ。

攻撃面を減らすとは、脆弱性をなかったことにする意味ではない。外部から到達できる入口と操作を必要な範囲へ絞り、悪用の前提を崩すことである。BackendにCVEが残っていても、該当機能へ外部から到達できなければ、インターネットからの直接悪用リスクは下げられる。ただし内部侵入後の悪用や、許可された経路からの悪用は残るため、修正計画は続けなければならない。

到達可能性で考える​

Reachabilityは、攻撃者の通信が脆弱な処理まで実際に届くかという観点である。次の四つを順に確認すると分かりやすい。

  1. 外部から対象のDomainやIP Addressへ接続できるか。
  2. 接続後、該当するPathとMethodを呼べるか。
  3. 認証や入力検査を通過して、脆弱な機能まで進めるか。
  4. 脆弱性の悪用に必要な条件がそろうか。

Gatewayは1から3を狭める手段になりうる。しかし、設定したつもりでは証拠にならない。実際に外部から旧Domainへ接続できないか、Gatewayを通らない通信をBackendが拒否するかを試す必要がある。

API Gatewayで公開機能を細くする​

NIST SP 800-204は、Microservices間のAPI通信に必要な認証、アクセス管理、安全な通信、監視、可用性、Throttlingなどを挙げ、それらをAPI GatewayやService Meshのようなアーキテクチャへ束ねられるとしている。Gatewayは単なるRouterではなく、複数の共通制御を置ける境界である。1

レガシーを包む場合は、次を明示する。

  • 外部へ公開する業務機能と公開しない管理機能。
  • 許可するHost、Path、HTTP Method、Content-Type。
  • Request Body、Query、HeaderのSchemaとSize上限。
  • 利用者、クライアント、Service Identityの認証方式。
  • Object、Function、Tenant単位の認可責任。
  • Rate Limit、Timeout、同時実行、Queueの上限。
  • Request ID、利用者、判定、Backend結果を結ぶログ。

これらが定義できないなら、API Gatewayは古いWeb画面をそのままProxyするだけになる。公開面を細くするには、外部契約と内部実装の間に意図的な差を作る必要があるのだ。

Gatewayは、複数のAPIへ向かう通信を一度受け取り、行き先を決める共通入口である。ここで認証、通信量制限、記録、PathやMethodの制限などを行える。利用者はLegacy本体の住所や内部形式を知らず、Gatewayが公開する契約だけを使う。

たとえばLegacyに、顧客検索、顧客更新、全件出力、管理者設定、帳票生成という五つの機能があるとする。外部の取引先に必要なのが顧客検索だけなら、APIでは検索Operationだけを公開する。Legacyに存在するからといって、五つすべてを外へ見せる必要はない。

Legacyが持つ機能
  顧客検索      ----> APIで公開
  顧客更新      ----> 社内だけ
  全件出力      ----> 公開しない
  管理者設定    ----> 公開しない
  帳票生成      ----> 社内だけ

この「公開する能力を列挙する」作業が、攻撃面を細くする。外部利用者は決められた窓口しか見えず、Gatewayは存在しないPathや許可されていないMethodを拒否する。もちろん、Gateway設定が正しく、Backendへの直接経路が閉じていることが前提である。

GatewayとWAFは同じではない​

GatewayとWAFはどちらも入口付近に置かれるため混同されやすい。Gatewayは、APIの行き先、認証、利用量、契約などを管理する交通整理役である。WAFは、通信の内容に既知攻撃や異常な特徴がないかを検査する防御役である。製品によって機能が重なる場合はあるが、設計上の役割は分けて考えた方がよい。

Gatewayで存在するAPIだけを許し、WAFで契約内に入り込む攻撃文字列を検査する。さらにアプリ側で、その利用者が対象Dataを操作してよいかを判断する。入口を一つにしても、一つの製品だけにすべての判断を任せるわけではないのだ。

媒介層は翻訳と防火区画を担う​

既存システムがSOAP/XML、独自RPC、画面遷移、Cookie Session、特殊な文字コードを使う場合、外部REST/JSON契約を直接接続できない。そこで媒介層が、外部契約をLegacy形式へ変換する。

外部契約                媒介層                 Legacy契約

REST / JSON      ->  検証・正規化・変換  ->  SOAP / XML
OAuth Scope      ->  Session / Service ID ->  既存認証
明示的なError    <-  例外マッピング       <-  独自Error
Request ID       <-> Trace対応             <-> Legacy Log ID

媒介層は便利だが、新しい攻撃面でもある。自動生成する場合でも、次を省略してはならない。

  • Method allowlistと完全一致のContent-Type確認。
  • malformed JSON、重複Parameter、未知Propertyの拒否。
  • Header正規化、Hop-by-Hop Headerの除去、改行や区切りの扱い。
  • JSONからXMLへ変換する場合の外部Entity、巨大展開、Namespaceの制御。
  • Payload、展開後Size、Timeout、Retry、同時実行の上限。
  • 外部の利用者権限を、Legacyの共有Service Accountへ潰さない設計。
  • Legacyの副作用とErrorを含むContract Test。

AIは変換コードの下書きとテスト生成を支援できる。正しい認証変換、冪等性、取引境界、例外時の副作用は人間が決める。

媒介層は、Adapterや翻訳層とも呼ばれる。新しいAPIがJSON形式で顧客番号と検索条件を受け取り、古いシステムが固定長の文字列やSOAP/XMLしか理解できない場合に、両者の形式を変換する。新しい受付票を、古い部署が使う帳票へ書き写す担当に近い。

変換は形式だけではない。新しいシステムの利用者Tokenを、Legacyが理解するService Accountへ対応付ける。Legacyの分かりにくいError Codeを、利用者向けの一貫したResponseへ変える。古いシステムが長時間応答しない場合にTimeoutで打ち切る。再送による二重登録を防ぐ。こうした役割も媒介層が担う場合がある。

翻訳で意味を変えない​

翻訳層の難しさは、形を変えても意味を保つ必要がある点にある。新APIのquantity: 10をLegacyの数量欄へ渡すだけなら単純に見える。しかしLegacyでは空欄を0として扱う、負数を取消として扱う、文字数を超えると切り捨てる、といった独自規則があるかもしれない。

確認項目確認する理由
入力対応どの新項目を、どのLegacy項目へ変換するか明確にする
文字コード・桁数文字化けや切り捨てによる意味の変化を防ぐ
認証情報利用者ごとの権限を共有Accountへ潰さない
Timeout・Retry応答遅延や二重登録を制御する
Error変換内部情報を外へ漏らさず、失敗理由を一貫させる
監査記録誰のどの要求が、どのLegacy処理になったか追跡する

入力を厳しく限定しても、出力に個人情報や内部情報が余分に含まれれば問題になる。媒介層はLegacyから返った全項目をそのまま外へ出さず、新APIの契約に必要な項目だけを選ぶ。入口と出口の両方を細くするのだ。

AIは翻訳案を作れても、意味を決められない​

AIは古い設計書やCodeを読み、項目対応表、変換Code、Contract Testの案を作るのに使える。しかし、古い項目STATUS=7が「保留」なのか「取消待ち」なのかは、資料や業務担当者の確認が必要である。もっともらしい変換を自動生成できても、業務上の意味が合っている保証にはならない。

そのため、AIが作った媒介層には、既存の正しい処理結果と比較するTest、境界値のTest、失敗時のTestを用意する。金額、在庫、権限、通知などの副作用も確認する。AIは移行を速める補助役であり、Legacyの暗黙知を自動的に正解へ変える魔法ではない。

Direct Accessを閉じて初めて境界になる​

攻撃面削減の成否は、Gateway機能一覧ではなくBackendへの迂回可能性で決まる。最低限、次の状態を作る。

  1. LegacyをPrivate Networkまたは非公開Load Balancerへ移す。
  2. Security GroupやFirewallでGatewayまたは媒介層からの通信だけを許可する。
  3. 送信元IPだけに依存せず、mTLSまたはGateway処理済みCredentialで経路を認証する。
  4. 旧Domain、直接公開IP、管理Path、別Portを廃止または遮断する。
  5. Backendが外部のX-Forwarded-*を無条件に信頼しないよう正規化する。
  6. 外部からOrigin、旧URL、未知Host、別Protocolを継続的に再検査する。

CDNやGatewayのIP範囲を許可しただけでは、同じ提供者を経由した任意通信や設定誤りに弱い場合がある。経路を認証し、Backend側でも想定したHostとIdentityを確認する。

Direct Accessは、利用者がGatewayを通らずBackendへ直接接続できる状態である。建物の正面受付を立派にしても、裏口が誰でも開けられるなら、受付の本人確認や持込検査を迂回できる。API境界も同じである。

よくある誤解は、古いDomain名を案内から消せば閉じたと思うことである。検索結果や過去の設定、証明書情報、IP Addressの調査から旧入口が見つかることがある。DNS名を削除しても、IP Addressへ直接接続できる場合もある。

BackendをPrivate Networkへ置くと、原則としてインターネットから直接到達できなくなる。FirewallやCloudのSecurity Groupでは、Gatewayまたは媒介層の接続元だけを許可する。mTLSを使えば、通信を暗号化するだけでなく、接続する双方が証明書を示して相手を確認できる。

ただし、内部Networkに置くだけで完全ではない。誤設定、別のLoad Balancer、試験環境、保守用VPN、古い公開IPなど、迂回経路が残る可能性がある。構成図と設定を確認し、最後に組織外のNetworkから接続試験を行うのだ。

「守れた」を証拠で説明する​

APIラッピングによる緩和を成立させる証拠は次になる。

主張必要な証拠
Originは外部非公開外部複数地点からの接続失敗、Firewall設定、公開資産台帳
Gateway以外を拒否mTLSまたは経路Credential試験、許可元・拒否元のログ
危険な入力が届かないMethod、Content-Type、Schema、Sizeの拒否試験
CVEの成立条件を崩したCVE前提と制御の対応表、Backend到達ログ、再現試験
変更後も維持できるIaC差分、CI試験、外形監視、設定変更後の再検査
Patchまでの暫定統制であるOwner、期限、残余リスク、Patchまたは移行計画

WAFやGatewayのログに攻撃がなかったことは、迂回不能の証明ではない。ログに残らない経路、暗号化された内部通信、別Port、別Domainを外部観測で確認する必要がある。

Evidenceは証跡、つまり後から確認できる記録である。「担当者が閉じたと言った」だけでは、設定変更や監査のときに再現できない。いつ、どの環境へ、どの条件を設定し、外部から何を試し、どの結果になったかを残す。

たとえば「Legacyの管理画面を保護した」と説明するなら、次のような証跡を組み合わせる。

  • 旧DomainとIP Addressへの外部接続が失敗した記録。
  • BackendのFirewallが媒介層からの通信だけを許可する設定差分。
  • Gatewayで許可したPathとMethodの一覧。
  • 契約外の入力が拒否されたTest結果。
  • 正しい利用者でも他人のDataは取得できない認可Test。
  • 構成変更後に外形監視を再実行した記録。

一つの記録だけでは不足する。外部接続が失敗しても、単なる一時障害かもしれない。Firewall設定が正しく見えても、別の公開経路があるかもしれない。設定と外部試験を組み合わせることで、説明の信頼性が上がる。

CVEは消えない​

CVEは、公開された脆弱性へ付けられる共通の識別番号である。GatewayやWAFで外部からの悪用条件を狭めても、LegacyのSoftwareにあるCVEそのものは残る。「修正済み」ではなく、「この経路からは到達できない」「この入力条件はGatewayで拒否する」と説明する必要がある。

これはPatchを不要にする議論ではない。すぐに修正できない期間の危険を下げ、調査と移行の時間を稼ぐ議論である。Backendへアクセスできる内部利用者、侵入後の攻撃者、別経路からの処理には脆弱性が利用される可能性が残るため、更新または置換の計画を続けるのだ。

Stranglerで機能ごとに置き換える​

AWS Prescriptive GuidanceはStrangler Fig Patternを、Big Bang移行のリスクと業務中断を抑えながら、Monolithの機能を一つずつ新しいServiceへ移すPatternとして説明している。Proxy層がLegacyと新ServiceへRouteし、移行完了後にMonolithを廃止する。Proxyが単一障害点や性能上のボトルネックになりうる点も明記されている。2

このPatternをセキュリティ境界と組み合わせると、次の段階になる。

段階Routeセキュリティ上の状態
0利用者→Legacy旧公開面が直接露出
1利用者→Gateway→Legacy入口を集約し、Origin遮断を確認
2一部Path→Modern、残り→Legacy同一の外部契約とPolicyで段階移行
3主要機能→Modern、例外→LegacyLegacy到達を例外として計測
4ModernのみLegacy Route、Credential、Data依存を廃止

移行率をコード行数で測るより、Legacyへ残るOperation、Traffic、Data書込み、副作用、Credentialを測る方が終了条件になる。OpenAPIのOperation一覧と実トラフィックを突き合わせれば、どの外部機能がまだLegacyへ依存しているかを追跡できる。

Strangler Fig Patternは、絞め殺しの木が別の木を取り囲む姿から名付けられた段階移行のPatternである。名称は物騒だが、考え方は穏当である。入口をProxyで受け、移行済みの機能だけを新Serviceへ送り、残りはLegacyへ送る。新しい側が増えるにつれて、Legacyの役割を小さくする。

注文システムなら、最初に参照だけの「注文状況確認」を新Serviceへ移す。次に新規注文、変更、取消を移す。最後に夜間処理や帳票を移す。この間、利用者は同じAPI契約を使い続け、内部の行き先だけが変わるように設計する。

最初        Gateway ──> すべてLegacy
途中        Gateway ──> 参照はModern
                    `─> 更新はLegacy
最後        Gateway ──> すべてModern

段階移行にはRollbackしやすい利点がある。新Serviceで問題が起きたとき、影響を受けるOperationだけLegacyへ戻せる場合がある。ただし、新旧双方が同じDataを書き換える期間は整合性が難しくなる。どちらを正本にするか、二重書込みを許すか、再送をどう扱うかを設計する必要がある。

また、GatewayやProxyへ通信が集中するため、そこが停止すると多くの機能が影響を受ける。責任範囲ごとにGatewayを分ける、冗長化する、Timeoutを設ける、障害時の切替を試験する、といった対策も必要なのだ。

API化で新しく生まれるリスクも引き受ける​

入口をAPIへ集めると、API自体が重要な攻撃面になる。OWASP API Security Top 10が示すBOLA、Broken Authentication、Resource Consumption、Sensitive Business Flow、Inventory不備は、Gatewayを置いても自動的には解決しない。3

さらに、Gateway障害の影響範囲、共有基盤の設定ミス、Rate Limitによる正常業務停止、Token検証差異、Legacyとの二重認証、Data整合性を設計する必要がある。一つの巨大Gatewayへ全システムを集約するより、責任境界ごとにRuntimeを分け、共通Policy、Inventory、証跡をControl Planeで揃える方がよい場合もある。

APIは万能な防壁ではない。外部公開面を明示し、直接到達を閉じ、Legacy依存を計測しながら置き換えるための境界なのだ。

API化すると、以前は画面操作でしか使えなかった機能を、Programから高速に呼べるようになる。利便性が上がる一方で、自動化された大量アクセスや、識別番号を変えた他人Dataへのアクセスも試しやすくなる。認証、認可、Rate Limit、業務濫用対策を新しいAPI側で設計し直さなければならない。

Gatewayを全社で一つにまとめると、共通Policyや記録をそろえやすい。しかし、設定ミスや障害の影響が全システムへ広がることもある。逆に、システムごとに完全分離すると、ルールがばらばらになりやすい。共通の管理基準を持ちながら、実際のGatewayは責任境界や障害影響に応じて分けるという選択肢がある。

顧客照会機能を段階移行する例​

古い顧客管理Systemが、Internet向けのWeb画面から直接利用されているとする。画面では、顧客番号を入れると氏名、連絡先、契約状況を表示できる。古いFrameworkに脆弱性があるが、業務停止を伴う更新はすぐにできない。

この状況で、新しいSystemを一から作って切り替えるまで何もしないのは危険である。一方、Gatewayを置いて古い画面を丸ごとProxyするだけでは、公開機能を狭めたことにならない。機能を分解し、最初の一Operationを選ぶ。

段階1：利用実態を調べる​

まず、誰がどの機能を使っているかを調べる。顧客照会、更新、CSV Export、管理者設定のうち、外部の取引先が本当に必要なのは照会だけかもしれない。実通信、Access Log、利用者への確認から一覧を作る。

この時点では、不明な機能をすぐ止めない。Owner不明の通信、古いClient、定期Batchを分類する。利用が見つからないことは、不要の証明とは限らない。月末や年次だけ使う処理もあるため、業務周期を考慮する。

段階2：外部API契約を作る​

GET /customers/{customerId}という照会APIを定義する。Responseには取引先に必要な氏名と契約状態だけを含め、内部Noteや管理属性は出さない。MethodはGET、顧客番号の形式、Response、ErrorをOpenAPIへ記述する。

外部契約とLegacy画面を一対一にしないことが重要である。古い画面が持つ全機能を再公開せず、利用目的に必要な能力だけを選ぶ。これがAPIラッピングで攻撃面を減らす中心になる。

段階3：媒介層で安全に翻訳する​

媒介層は新APIの顧客番号を検証し、Legacyの検索処理へ変換する。Legacyから返る多数の項目から、契約にある二項目だけを選んでResponseを作る。外部の利用者Identityと照会対象をLogへ結ぶ。

Legacyが共有Service Accountしか使えない場合でも、外部の利用者Identityを失ってはいけない。媒介層で認可を行い、監査Logへ元の利用者を残す。共有Accountを使うことを理由に、全利用者へ同じ権限を与えない。

段階4：旧入口を閉じる​

Gatewayと媒介層が動いても、旧Web画面へ直接接続できれば移行は未完成である。LegacyをPrivate Networkへ移し、媒介層からの通信だけを許可する。旧Domain、公開IP、別Port、管理画面を外部から試す。

取引先が新APIへ移るまで旧画面を残す必要がある場合は、終了日、対象利用者、追加認証、監視を決める。「移行中」という名前だけで無期限に残さない。

段階5：Modern Serviceへ置き換える​

外部契約を保ったまま、顧客照会のRoute先を新Serviceへ変える。最初は一部の取引先だけを新側へ送り、Responseと性能を比較する。問題があればLegacyへ戻す。

照会が安定したら、顧客更新など次のOperationを同じ手順で移す。Legacyへ向かうOperation数、Traffic、Data書込み、Credentialを計測し、ゼロに近づける。最後に、使われなくなったRouteとCredentialを削除する。

この例で残るRisk​

公開経路を狭めても、Legacy内部の脆弱性は残る。媒介層や内部利用者から悪用条件へ到達する可能性、Legacyが返す誤ったData、共有Account、Gateway障害が残る。したがって、外部公開の緩和と、本体のPatch・置換を別の項目として追跡する。

境界設計でよく起きる失敗​

旧画面をそのまま新しいURLへ通す​

Gatewayが単なる中継になり、Legacyの全PathとMethodを受け付ける。入口の名前は変わっても公開能力は減らない。Operation単位で許可し、管理機能や不要な画面を外部契約へ含めない。

Networkだけ閉じて認可を忘れる​

Backendが非公開でも、正規のGateway利用者が他人の顧客番号を指定できればDataは漏れる。Network境界は外部経路を狭めるが、Object単位の認可を代替しない。

変換層を万能Proxyにする​

任意Path、任意Header、任意BodyをLegacyへ渡せると、外部契約の制約を迂回できる。媒介層はOperationごとに変換と上限を固定し、未知入力を拒否する。

移行率を新Code量で測る​

新ServiceのCodeが増えても、実通信とData書込みがLegacyへ残っていれば廃止できない。利用者から見えるOperationと、内部の依存を終了条件にする。

暫定対策を完了扱いする​

WAF RuleやGateway制限で時間を稼いだ後、Patch計画を閉じてしまう。暫定統制にはOwnerと期限を付け、構成変更後も外部から再検査する。

よくある言い方を正確に直す​

よくある言い方より正確な読み替え
APIで包めば脆弱性が消える公開経路と入力を狭められるが、Backendの脆弱性は残る
Gatewayを置けば攻撃面が減る旧経路を閉じ、公開Operationを限定して初めて減る
内部Networkなら安全内部侵害、誤設定、保守経路、認可不備は残る
AIならLegacy仕様を解析できる候補は整理できるが、暗黙の業務意味は資料と担当者で検証する
段階移行は二重運用するだけOperationごとにRouteを変え、Legacy依存を測って削除する
仮想パッチで対応済みPatchまでの悪用経路を一時的に狭めた状態

非技術者が移行計画で確認すること​

  1. 外部利用者に本当に必要なLegacy機能はどれか。
  2. Gatewayを通らない旧Domain、IP、管理画面は閉じたか。
  3. 新しいAPIの入力を、媒介層が任意のLegacy操作へ変換できないか。
  4. 認証だけでなく、対象Dataごとの認可を確認しているか。
  5. どのOperationがまだLegacyへ向かっているか計測できるか。
  6. 新旧でDataを書き換える場合、正本と失敗時の戻し方は決まっているか。
  7. Gateway障害や設定ミスの影響範囲を把握しているか。
  8. CVEへの暫定対策と、本体の修正・置換計画を分けて管理しているか。

この質問へ具体的な経路、Owner、Test結果を添えて答えられれば、「API化したから安全」という曖昧な説明を避けられる。

この回で覚えておくこと​

  • Legacyの内部刷新と、外部からの到達経路の改善は分けて進められる。
  • API Gatewayは、外部へ公開する機能を列挙して入口を集約する。
  • 媒介層は新旧の形式を翻訳するが、任意の操作を通す汎用Proxyにしてはいけない。
  • 旧DomainやBackendへ直接到達できるなら、Gatewayの防御は迂回される。
  • GatewayはCVEを消さない。悪用経路を狭める暫定対策として証跡を残す。
  • Strangler Fig Patternで機能ごとにModern Serviceへ移し、残るLegacy依存をOperation単位で測る。
  • API化によって新しい認可、濫用、共有基盤のリスクも生まれる。

全面刷新を待たずにできることは多い。まず入口を細くし、直接経路を閉じ、何が残っているかを計測する。そのうえで一つずつ置き換えるのが、現実的で説明可能な進め方なのだ。

前後の記事​

用語集​

用語平易な説明
Legacy System（レガシーシステム）長年使われ、古い技術や複雑な依存を抱えながらも、業務上すぐには廃止できないシステム。
Attack Surface（攻撃面）外部や利用者から触れられ、攻撃の入口になりうる機能、通信経路、アカウントなどの範囲。
Reachability（到達可能性）攻撃者の通信が、対象の機能や脆弱な処理まで実際に届くかどうか。
API GatewayAPIの入口を集約し、認証、認可、通信量制限、振り分け、記録などを行う仕組み。
WAFWebやAPIへの通信を検査し、攻撃と判断した通信を遮断する仕組み。
Origin／BackendGatewayの背後で実際の処理を行う元のサーバーや内部システム。
APIラッピング既存システムを直接公開せず、必要な機能だけを新しいAPI経由で使えるように包む方法。
Mediator／Adapter新しいAPIのデータや操作を、Legacyが理解できる形式へ安全に変換する仲介層。
REST／JSON・SOAP／XMLAPIで使われる代表的な通信様式とデータ形式。新旧システムの間では相互変換が必要になることがある。
Proxy（プロキシ）通信をいったん受け取り、行き先を選んで別のシステムへ中継する仕組み。
Private Networkインターネットから直接接続できないように分離した内部ネットワーク。
Load Balancer複数のサーバーへ通信を振り分け、負荷や障害を分散する仕組み。
Security Group／Firewall接続元、接続先、通信方法などの条件で、ネットワーク通信を許可または拒否する仕組み。
mTLS（相互TLS認証）通信を暗号化するだけでなく、接続する双方が証明書を示して相手を確認する方式。
Credential（認証情報）Password、鍵、Tokenなど、システムや利用者の正当性を証明する情報。
CVE公開された脆弱性へ付けられる共通の識別番号。Gatewayで到達経路を狭めても、BackendのCVE自体が消えるわけではない。
Virtual Patch（仮想パッチ）本体をすぐ修正できない間、WAFやGatewayで悪用される通信を抑える暫定対策。正式な修正の代替ではない。
Contract Test新しいAPIと既存システムの変換結果が、決めた契約どおりかを確認するテスト。
Strangler Fig Pattern既存システムを一度に置き換えず、入口で振り分けながら機能ごとに新システムへ移す段階移行方式。
Monolith／MicroserviceMonolithは多くの機能を一体で動かす構成。Microserviceは機能や責任ごとに小さなServiceへ分ける構成。
冪等性（Idempotency）同じ要求を複数回実行しても、意図せず結果が重複しない性質。再送時の二重注文などを防ぐために重要。
Rollback問題が起きた変更を取り消し、以前の正常な状態へ戻すこと。
IaC（Infrastructure as Code）ネットワークやGatewayなどの構成を、手作業ではなく再現可能なコードで管理する方法。

参考資料​

Footnotes​

  1. NIST, SP 800-204: Security Strategies for Microservices-based Application Systems（2019年8月）。API通信の共通セキュリティ機能とAPI Gateway、Service Meshを扱う。https://csrc.nist.gov/pubs/sp/800/204/final ↩

  2. AWS Prescriptive Guidance, Strangler fig pattern。段階移行のIntent、Proxyの役割、適用条件、単一障害点やDomain分割の注意を説明する。https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/strangler-fig.html ↩

  3. OWASP, OWASP Top 10 API Security Risks – 2023。API境界に残る認可、認証、資源消費、業務フロー、Inventory等のリスク。https://owasp.org/API-Security/editions/2023/en/0x11-t10/ ↩