クラウド移行のセキュリティ｜移送・並行稼働・切り替え直後に穴が空く工程と対策設計

クラウド移行での情報漏えいは、移行が終わったあとの設定より、移行している最中に仕込まれることのほうが多いものです。データを運ぶ間だけ開ける通信経路、切り替えまで残す旧環境の管理者アカウント、検証のために緩めて戻し忘れる制限。総務省の令和6年通信利用動向調査では、クラウドを使っていない企業が挙げた理由の第3位が「情報漏えいなどセキュリティに不安がある」の24.9%でした。この記事では、移行前・移送中・並行稼働中・切り替え直後という四つの時点に分け、それぞれで何を決め、何を証跡として残すかを整理します。

まとめ：クラウド移行のセキュリティは工程を四つに割って決める

• 移行前：データを分類し、そもそも社外の基盤へ出してよいかを先に決める。ここで線を引かないと、以降の統制はすべて後追いになります
• 移送中：転送経路の暗号と鍵の所在を分けて設計する。物理デバイスを使う場合は鍵をデバイスに載せない構成にする
• 並行稼働中：旧環境と新環境が同時に生きるため攻撃面が二重になる。移行ベンダー用のアカウントには必ず失効期限を付ける
• 切り替え直後：構成のベースラインを機械的に検証し、その結果を証跡として保存する。ここを飛ばすと監査で再現できません
• 方式の選択：そのまま載せ替えるリホストは自社の責任範囲が最大になる。運用人員が5名を下回るなら、マネージドサービスへ寄せたほうが守りやすくなります
• 鍵の持ち方：顧客管理鍵は監査要求か契約要求がある場合に採る。鍵の運用担当を置けない組織では見送ってよい判断です

クラウド移行のセキュリティが工程ごとに変わる理由と穴が空く三つの時点

定常運用のクラウドセキュリティと移行期間のそれは、守る対象が違います。定常運用では守る境界が一つですが、移行期間中は旧環境と新環境の二つが同時に稼働し、その間をデータが流れ続ける状態。境界が二つあり、しかも両者をつなぐ経路が一時的に開いています。

責任の所在も動きます。クラウド事業者の責任共有モデルは、事業者が基盤側、顧客が基盤の上を守る分担です。ところが移行期間中は、その分担に加えて移行ベンダーという第三者が入ります。作業アカウントを持ち、データに触れ、しかし契約が終われば去る主体。ここが定常運用の設計図に載っていない部分です。モデルそのものの定義はクラウドセキュリティとは？リスクと責任共有モデルで整理しています。

穴が空きやすい時点は三つに絞れます。第一にデータが経路上を流れている移送中。第二に二重の環境を維持している並行稼働中。第三に切り替えた直後、まだ誰も新環境の設定を点検していない数日間です。IPAが2026年1月29日に公表した情報セキュリティ10大脅威では、委託先やサプライチェーンを狙った攻撃が組織編の2位に入りました。移行ベンダーが持つ一時的な権限は、まさにその経路にあたります。移行そのものでつまずく論点はクラウド移行の課題と失敗パターンにまとめました。

移行前のアセスメントで決めるデータ分類と持ち出し可否の判断基準

最初にやるのはデータの棚卸しです。全件を同じ強度で守ろうとすると、費用も工期も現実的でなくなります。四段階に分けるのが扱いやすい粒度でしょう。公開してよいもの、社外秘だが移送に制約がないもの、個人情報や機微情報を含むもの、法令や業界規則でデータの所在地や管理形態が指定されているもの。

四段目に該当するデータは、移行対象から外す判断を先に検討してください。所在地の指定がある場合、国内リージョンを選べば済むこともありますが、事業者側の運用や保守がどの国から行われるかまで指定されていると、リージョン選択だけでは足りません。要件を満たす構成を組めると確認できるまで動かさないほうが安全です。

三段目のデータで先に確認すべきなのは、移送方法の制約です。テスト環境へコピーする場合はマスキングを前提にし、本番データをそのまま検証に使わない方針を移行計画書に明記します。政府調達に関わる場合はISMAPの登録簿に掲載されたサービスかどうかも確認対象になります。

移行先の事業者を見る目線も、この段階で固めておきます。総務省が示した「クラウドサービス提供における情報セキュリティ対策ガイドライン」は、2026年8月時点で第3版（2021年9月）が公開版。ここで求められている観点のうち、発注側が契約前に確認しておくべきは四つに絞れます。第三者認証の取得範囲、データの保管場所と運用拠点の国、再委託先の有無と管理方法、そして事業者側でインシデントが起きたときの通知条件と時間です。

特に見落とされやすいのが再委託先と通知条件でしょう。保守や監視を別会社が担っている構成は珍しくなく、そこまで含めて自社の管理範囲だと認識できているかで、事故時の初動が変わります。判断の材料が揃ったら、工程そのものの組み立てはクラウド移行の進め方の手順に沿って進めてください。

データ移送中の暗号化と鍵の管理をネットワーク経由と物理輸送で分ける

移送方法は大きく二つです。ネットワーク経由の転送と、物理デバイスによる輸送。データ量と回線帯域で決まりますが、暗号の設計はまったく別物になります。

ネットワーク経由なら、転送中はTLS 1.3系で保護し、着地先のストレージでは保存時の暗号を有効にします。落とし穴は中継用のステージング領域です。転送ツールが一時置き場としてオブジェクトストレージを使う構成では、そのバケットの公開範囲が既定のまま残ることがあります。ステージング領域も本番と同じ強度で扱ってください。専用線やVPNを引く場合、経路自体が閉じていても、そこを通るデータの暗号は別に掛けておくのが安全側の設計です。

物理デバイスによる輸送では、鍵をどこに置くかが分かれ目になります。AWSのSnowball Edgeは、データを256ビットで暗号化し、鍵はKMS側で管理してデバイス上には保存しません。耐タンパー筐体とTPMを備え、返却後にメモリを消去する設計です。つまり輸送中にデバイスを奪われても、鍵が同行していないため復号できません。自前でディスクを郵送する運用に切り替えるなら、この「鍵を同送しない」条件を再現できるかを必ず確認してください。

移送後の検証も工程に入れます。件数とチェックサムの突き合わせで整合を確認し、その結果を記録に残す。そして移行元の媒体をどう始末するかを決めておきます。NIST SP 800-88 Rev.1は、消去の水準をClear・Purge・Destroyの三段階で整理しました。返却するリース機器はPurge以上、廃棄する自社機器は物理破壊まで踏むのが無難な線引きです。

並行稼働の期間に広がる攻撃面と一時アカウント・接続経路の締め方

並行稼働は、旧環境を止めずに新環境を立ち上げ、動作を確かめてから切り替える進め方です。安全に見えて、セキュリティの観点では最も緩む期間になります。守る対象が二倍になり、そこへ移行作業用の権限が上乗せされるためです。

一時アカウントの設計から始めてください。移行ベンダーや移行ツールが使うアカウントには、四つの条件を付けます。第一に失効期限を設定する。第二に付与する権限を作業対象のリソースだけに限る。第三に管理者権限を常時付与せず、必要な時だけ昇格させる仕組みにする。第四に操作ログを別アカウントの領域へ書き出し、作業者自身が消せない状態にしておくこと。

接続経路も同じ考え方です。移行のために開けたVPNや踏み台サーバは、移行計画の中で閉じる日付まで決めておきます。開けたまま忘れられた経路が、数年後に侵入口になる事例は珍しくありません。データベースのレプリケーション経路も同様で、切り替え完了後に停止する手順を切り替え計画に含めます。

もう一つ、この期間に生まれやすいのが監視の空白です。運用チームの意識が新環境へ移り、旧環境のアラートを誰も見ていない状態が発生します。旧環境はまだ本番データを保持したまま稼働しており、狙う側から見れば手薄な標的。並行稼働の期間中は、旧環境の監視も同じ水準で維持し、停止の日付を決めたうえで監視を外す順序にしてください。ランサム攻撃はIPAの10大脅威で組織編の1位が続いており、放置された旧環境のバックアップ領域は典型的な着弾点になります。

切り替え直後に必ず走らせるセキュリティ検証の項目と証跡の残し方

切り替えた直後の数日が、設定の穴が最も残りやすい時間帯です。動作確認を優先して緩めた制限が、そのまま本番として動き始めます。ここは人の目視ではなく、機械的な検証で潰してください。

検証の骨子は五つ。ストレージやバケットの公開範囲、管理者アカウントの多要素認証、通信を許可する範囲の広さ、保存時の暗号が有効か、そして監査ログが記録され保存されているか。クラウド事業者が提供する構成監査の機能や、CIS Benchmarksのような外部の基準文書に沿った点検ツールを使えば、この五つは自動で走ります。切り替え当日と、一週間後の二回実施する運用にしておくと、暫定設定の戻し忘れを拾えます。

インシデント対応の体制も、切り替えと同時に組み替えます。障害や不審な挙動を検知したとき、これまでは自社の運用担当へ連絡すれば完結していたはずです。移行後は、事業者のサポート窓口が経路に入ります。契約しているサポートの等級で応答時間が変わり、等級によっては夜間の一次応答が付かないこともある。切り替え前に、検知から誰へ、どの手段で、何分以内に連絡するかを一枚の連絡表にして配ってください。連絡先が分からないまま数時間を失うのが、移行直後に最も起きやすい損害の広げ方です。

証跡の残し方も先に決めておきます。検証結果の出力、切り替え時点の構成情報、権限の一覧、そして誰がいつ承認したかの記録。監査や事故調査で問われるのは「当時どうだったか」であり、現在の設定画面では答えられません。監査ログの保存期間は、契約や社内規程で求められる年数から逆算して設定します。既定値のまま短期間で消えていくと、後から遡れなくなります。

移行方式の選び分けでセキュリティの負担がどこへ動くかを見極める

ここからは判断の話です。移行方式によって、自社が守るべき範囲は大きく動きます。既存のサーバをそのまま仮想マシンへ載せ替えるリホストは、工期は短いものの、OSのパッチ適用もミドルウェアの脆弱性対応も自社に残ります。責任共有モデルでいえば、顧客側の負担が最大になる方式です。

一方、データベースやアプリケーション基盤を事業者のマネージドサービスへ寄せると、基盤の修正対応は事業者側へ移ります。移行の手間は増えますが、移行後に人手で守り続ける範囲は縮む。運用に割ける人員が5名を下回る組織なら、工期が延びてもマネージドサービスへ寄せる判断を推奨します。載せ替えただけの環境は、移行直後こそ安全に見えても、数年後のパッチ未適用として跳ね返ってくるからです。

逆に、マネージドサービスへ寄せるべきでない場面もあります。事業者側の仕様変更が業務を止めうる基幹処理、法令でミドルウェアの構成まで指定されている業務、そして既存製品のライセンスが特定構成に縛られている場合。この三つに当てはまるなら、リホストで運び、パッチ運用の体制を別途組むほうが結果的に安全です。閉域や専有環境で組む場合の設計はプライベートクラウド移行の方式選定と手順を参照してください。方式の選定から移送設計、切り替え後の検証までを一括で任せたい場合は、システムマイグレーション・リプレイスでご相談ください。

暗号鍵を自社で持つか事業者に預けるかの採用条件と見送るべき場面

保存時の暗号を有効にするところまでは、どの案件でも入れてよい前提です。分かれるのはその先、鍵を誰が持つかという設計。選択肢は三つあります。事業者が管理する鍵をそのまま使う方式、事業者の鍵管理サービス上で自社が作成・制御する顧客管理鍵、そして自社で生成した鍵を持ち込む方式です。

顧客管理鍵を採るべき条件は二つに整理できます。第一に、監査や業界規則で鍵の生成・失効の記録を自社が示す必要がある場合。第二に、契約上、事業者側の操作でデータへ到達できない状態を証明する必要がある場合。この二つのどちらかが立つなら、運用コストを払ってでも顧客管理鍵にする価値があります。

逆に、次の三条件のいずれかに当てはまる組織は、顧客管理鍵を見送って構いません。鍵の失効・更新を担当する人を専任で置けない場合、鍵の紛失時に復旧手順を演習できない場合、そして規制要求が特に無い一般的な社内業務システムの場合。鍵を自社で持つということは、鍵を失えばデータも失うという責任を引き受けることです。運用体制が伴わない顧客管理鍵は、守りを固めるどころか、可用性の側に新しい単一障害点を作ります。持ち込み方式はさらに要求水準が上がるため、外部の監査要求で名指しされていない限りは検討対象から外して問題ありません。

よくある質問

移行中だけ一時的にセキュリティ設定を緩めても大丈夫ですか？

緩めること自体は現実的な選択です。問題は戻し忘れのほう。緩める判断をした時点で、対象・理由・戻す日付・戻す担当者の四点を記録に残してください。そのうえで切り替え後の検証で機械的に点検すれば、暫定設定は必ず拾えます。記録を残さず口頭で決めた緩和が、数年後に原因不明の穴として残るというのがよくある経路です。

データ移送はネットワーク経由と物理輸送のどちらが安全ですか？

安全性の差は方法ではなく、鍵と経路の設計で決まります。ネットワーク経由は中継のステージング領域が盲点になり、物理輸送は鍵をデバイスに同送するかどうかが分かれ目。事業者提供の輸送デバイスは、鍵を鍵管理サービス側で持ちデバイスに保存しない設計になっています。自前でディスクを送る運用に切り替えるなら、その条件を再現できるか先に確認してください。

移行ベンダーにはどこまで権限を渡すべきですか？

作業対象のリソースに限った権限を、期限付きで渡すのが基本線です。管理者権限を常時渡す構成は避け、必要な作業のときだけ昇格させる仕組みにします。加えて、ベンダーの操作ログを自社側のアカウントへ書き出し、作業者が消せない状態にしておく。委託先経由の攻撃はIPAの10大脅威で組織編の上位に定着しており、契約書の守秘条項だけでは防げない領域です。

移行後のセキュリティ監査はいつ受けるのがよいですか？

切り替え直後の機械的な検証と、外部監査は別物として計画してください。前者は当日と一週間後、後者は運用が定常状態に入ってから、目安として三か月後。移行直後は暫定運用が残っており、その状態で外部監査を受けても指摘が暫定分に集中して本質を拾えません。ただし規制業種で期限が決まっている場合は、期限が優先です。

暗号化していれば移行中の情報漏えいは防げますか？

防げるのは経路上でデータを盗み見られる形の漏えいだけです。移行期間中に起きる事故の多くは、権限を持った正規のアカウントが誤って公開範囲を広げる、あるいは乗っ取られるという形で発生します。暗号は前提として入れたうえで、権限の範囲と失効期限、操作ログの分離を組み合わせてください。暗号だけを頼りにした設計では、鍵にアクセスできる主体が増えた時点で守りが崩れます。

関連記事

• クラウド移行の進め方：計画から移行方式・費用・切り替えまでの手順
• クラウド移行の課題と失敗パターン：コスト増・人材不足を移行前に潰す判断軸
• クラウドセキュリティとは：リスクと責任共有モデルから見た企業の守り方
• クラウドとは？AWSとは何か：仕組みと料金の考え方という前提の整理
• プライベートクラウド移行：閉域・専有環境の方式選定と手順