リフト＆シフトでAWS移行｜セキュリティ負債の解消法

この記事のポイント

基調講演レポート：Phạm Thúc Phước（SupremeTech インフラマネージャー）

Phướcは講演の最後に、売り込みではなく「持ち帰ってほしいこと」として、次の3点をまとめました。

「スキップ」ボタンの裏側には、結果の連鎖があります。積み重なったセキュリティ負債は、いずれ「賭け」に変わります。
システムをその場で延々とアップデートし続けるのではなく、移行は負債を直接解消するための戦略的な選択肢になり得ます。
移行の完了はゴールではありません。本人の言葉を借りれば、負債を返済することは気を緩めることではなく、「受け身の対応」から「先手の対応」へと切り替えることです。

Windows Updateの通知から始まった講演は、組織がリスクをどのように判断しているのか、つまり先送りされたパッチの一つひとつがどう積み重なるのかという話へと展開しました。インフラやDevOpsのエンジニアが集まる会場にとって、まさに核心を突く内容でした。

「スキップ」ボタンという悪夢

先日開催されたクラウド＆DevOpsカンファレンスで、SupremeTechのインフラマネージャーであるPhạm Thúc Phướcは、会場のエンジニアなら誰もが何百回も目にしてきたもので基調講演を始めました。Windows Updateの通知です。続いて、Linuxのパッチ適用を促す画面。劇的なものは何もありません。システムが更新を求めてくる、ささいでおなじみの煩わしさにすぎません。

それこそが講演のポイントでした。Phướcが語ろうとしていたのは、まれで特殊な脅威ではなく、会場のほぼ全員が「スキップ」を押すたびに自ら生み出してきたリスクだったのです。

講演では、その習慣がどのように積み重なってはるかに深刻な問題へと発展するのか、そしてSupremeTechのチームが、その場でのパッチ適用を強化するのではなく、リフト＆シフトによるクラウド移行を通じてこの問題を解決してきた理由を説明しました。

セキュリティ負債が積み上がる仕組み：終わりのないループ

Phướcはこのパートを、ほとんどのインフラチームが共有している本能から始めました。「うまく動いているなら触るな」というものです。これは不注意な考え方ではない、と彼は指摘します。アップデートを適用すると、今は問題なく動いているものが壊れるかもしれない、という現実的な恐れから生まれているのです。

しかし、その恐れには代償があり、彼はそれがどのように膨らんでいくのかを具体的に示しました。会場の多くが何気なく「技術的負債」と呼ぶものを、彼は次のような繰り返されるループとして捉え直しました。

安定したシステムを壊すことへの恐れ
その恐れから、一部の修正が公式な管理の外にある「シャドーIT」へと追いやられる
チームが現在のパッチ適用を先送りにする
前のアップデートに対応する前に、新しいセキュリティアップデートが届く
セキュリティ負債が増え、このサイクルが繰り返される

彼はこれを、特定のチームの失敗として語ったわけではありません。誰かが意図的に決めたわけでもないのに、アップデートのたびに「今の安定」が「後回しのセキュリティ」に勝ち続けると、自然とこうなってしまうのです。

先送りがパッチ適用を「賭け」に変える理由

講演の中で最も響いたのは、このループが長く続くほど危険が減るのではなく増していく理由についての説明でした。組織が成熟し、システム同士のつながりが増えるにつれて、先送りされたパッチは山のように積み上がり、シャドーITもそれに合わせて拡大していきます。次のアップデートは適用しやすくなるどころか難しくなり、放置するリスクも高まっていきます。

その時点で、パッチ適用はもはや定常的なメンテナンスではなくなる、とPhướcは主張しました。長年放置された脆弱なシステムに手を入れて壊すリスクを取るか、既知の未修正の脆弱性を放置してさらに悪い事態を招くリスクを取るか――それは「賭け」になってしまうのです。

負債の返済期限が来たとき何が起きるのか

WannaCry（2017年、MS17-010）

彼が最初の事例として挙げたのがこれです。既知の、パッチで修正可能な脆弱性が、修正を先送りにしていた組織を狙って大規模に悪用されました。

CitrixBleed（2023年、CVE-2023-4966）

2つ目は、より最近の事例です。広く悪用される前に修正プログラムが提供されていた、公開済みの脆弱性でした。年もシステムも違いますが、パターンは同じです。

2つの事例を結び付けた彼の言葉はこうです。「年は違っても、根本原因は同じ。既知の穴が長く放置され、誰か別の人に先に見つけられてしまったのです。」

セキュリティ負債の本当のコスト

Phướcは続いて、話題を技術的なリスクからビジネスへの影響へと移し、経営層が実感する4種類のコストにセキュリティ負債を分類しました。

業務面：回避策や文書化されていない修正が積み重なり、非効率さが最初に目に見える兆候として表れる
財務面：何もしないことのコストは一定ではなく、時間とともに膨らんでいく
信用面：最も返済が難しい負債。特に、原因がすでに分かっていたものだった場合はなおさら
戦略面：長く放置されたセキュリティ負債は、組織がどれだけ速く、自信を持って変化に対応し、市場をリードできるかを最終的に制約する

最後のポイントを境に、講演は「問題」から「アプローチ」へと移りました。対処されない負債はただそこにあるだけではなく、成長の「天井」になってしまう、と彼は語りました。

リプラットフォーム：戦略的な出口

ここでPhướcは、SupremeTechが実際にクライアントのためにこの問題をどう解決してきたのかを紹介しました。まず、AWSが提唱する6つの代表的な移行戦略「6つのR」――リホスト（Rehosting）、リプラットフォーム（Replatform）、保持（Retain）、再購入（Repurchasing）、リファクタリング／再設計（Refactoring / Re-architecting）、廃止（Retire）――を説明しました。それぞれに適した場面があります。しかし、実際にセキュリティ負債を抱える組織に対しては、通常とは異なるやり方でのリプラットフォームを明確に推奨しました。

一般的なリフト＆シフトによるクラウド移行は、変更を最小限に抑えることを前提にしています。ワークロードを移し、それ以外はすべてそのままにして、ホスティングの問題を解決する。しかし、それではセキュリティの問題は解決しない、と彼は説明しました。

彼のチームが構築した「Lift, Shift, and Hardening（リフト、シフト、そしてハードニング）」は、あえてそうしないアプローチです。リプラットフォームにセキュリティファーストの考え方を組み合わせたもので、従来どおりのレガシーシステム移行のようにリソースをそのまま移すのではなく、移行そのものをインフラの最適化とアプリケーションのバージョンアップの機会とし、負債を移すのではなく解消します。

関連記事（英語）：

ハードニングが実際にもたらすもの

彼はこれを抽象的な提案のままにはしませんでした。アプローチを4つの具体的な目標に分解し、それぞれについて、チームが実際にクライアントに提供してきた成果物を紹介しました。

セキュリティ態勢

彼の説明によれば、クラウドのセキュリティ態勢の強化とは、適切なガバナンスを備えたマルチアカウント構成への移行、通信時と保存時の暗号化の実装、ネットワークセキュリティの強化とセグメンテーションの確立、最新のIAMモデルの導入、重大度「Critical」「High」の脆弱性の修正、多層防御アーキテクチャの実装、そしてセキュリティ監視とインシデント対応体制の確立を意味します。

インフラのモダナイゼーション

一貫したデプロイのためのInfrastructure as Codeの導入、セキュリティコンプライアンスの自動監視の確立、バックアップとリストアの戦略の構築、パフォーマンスとコストの監視の実装です。

アプリケーションのモダナイゼーション

アプリケーションをパッチ適用済みの最新バージョンに更新し、既知の脆弱性をふさぐためにサードパーティの依存関係を更新し、ベストプラクティスに沿った安全な設定プロセスを確立します。

運用の卓越性

彼によれば、これは上記3つの取り組みを組み合わせた成果です。一度パッチを当てて終わりではなく、パッチ適用済みで、監視され、コスト効率のよい状態を保ち続けられるよう設計されたシステムであり、同じ負債のサイクルに逆戻りしないことを意味します。

6フェーズの実行ロードマップ

Phướcは講演の技術パートの締めくくりとして、チームがすべての案件で実践している6フェーズのプロセスを紹介しました。何かを移す前にセキュリティの基盤が整うよう、意図的に構成されています。

アセスメント：現行システムを把握し、負債が実際にどこにあるのかを明らかにする
基盤の構築：すべての土台となるセキュリティベースラインを実装する
インフラのモダナイゼーション：インフラとセキュリティの強化策を適用する
アプリケーションのセキュリティアップグレード：脆弱性を修正し、サポート対象のバージョンに更新する
データ移行：移行先の環境のハードニングが完了してからデータを移す
検証、最適化、運用の引き継ぎ：目標が達成されたことを確認し、環境を引き渡す

彼は順序について率直に語りました。早く進めるために基盤構築のフェーズを飛ばせば、移行によって、取り除くはずだったリスクそのものを再び持ち込むことになる、と。

よくある質問

リフト＆シフトによるクラウド移行とは何ですか？

リフト＆シフトによるクラウド移行とは、既存のワークロードを最小限の変更でオンプレミスのインフラからクラウドへ移すことです。移行を迅速に進められる一方で、セキュリティの改善を伴わない場合は、古いソフトウェア、脆弱な設定、未修正の脆弱性まで新しい環境に持ち込んでしまうおそれがあります。

リフト＆シフトによるクラウド移行でセキュリティ負債は解消できますか？

それだけでは解消できません。一般的なリフト＆シフトは、根本的なセキュリティの問題に対処しないまま、ワークロードの実行場所を変えるだけです。セキュリティ負債を解消するには、脆弱性の修正、アプリケーションのアップグレード、ID管理の強化、ネットワークのセグメンテーション、暗号化、継続的なセキュリティ監視などの追加の取り組みが必要です。

AWSにおけるリフト＆シフトとリプラットフォームの違いは何ですか？

リフト＆シフト（リホストとも呼ばれます）は、最小限の変更でワークロードを移すことを優先します。リプラットフォームは、アプリケーションを完全に作り直すことなく、移行の過程で的を絞った改善を加えます。改善の例としては、サポート対象のアプリケーションバージョンへの更新、Infrastructure as Code、AWSのマルチアカウント構成、より強固なセキュリティ統制などがあります。

セキュリティファーストのAWS移行には何を含めるべきですか？

セキュリティファーストのAWS移行は、既存の脆弱性と依存関係のアセスメントから始めるべきです。そのうえで、ワークロードやデータを移す前に、安全なクラウド基盤を確立します。主な施策には、最新のIAM、暗号化、ネットワークのセグメンテーション、脆弱性の修正、バックアップ、セキュリティ監視、コンプライアンスチェック、そして明確な運用の引き継ぎが含まれます。

出典：Lift and Shift Cloud Migration: How to Resolve Security Debt on AWS（SupremeTech、著者：Quy Huynh）。日本語に翻訳して掲載しています。