Migration GovernanceとSecurity

AWSへの移行では、データやサーバーをAWSへ転送できるだけでは十分ではありません。

移行先のAWS環境について、

「どのアカウントへ配置するか」

「どの統制を適用するか」

「誰とどの移行ツールへ、どこまで権限を与えるか」

「転送中・中間領域・移行先のデータをどう保護するか」

「誰が移行可否や例外を承認し、問題発生時に誰へエスカレーションするか」

まで決めておく必要があります。

重要なのは、ガバナンスとセキュリティをカットオーバー後に追加するのではなく、移行を開始できる条件として事前に完成・検証することです。

1. 移行先を受け入れ可能な状態にする

大規模な移行では、最初のワークロードをAWSへ転送する前に、移行先となるAWS環境を準備します。

ここで確認するのは、

AWS Organizationsによる組織構造

AWS Control Towerなどによる統制

移行先アカウントとOU

IAMによるアクセス管理

ログと監査

セキュリティとコンプライアンス

などです。

ランディングゾーンを用意していても、単にAWSアカウントが存在するだけでは十分ではありません。

対象ワークロードが、

意図したアカウントと統制下へ最初から配置されること

が重要です。

原則は、

移行先を決める
↓
必要な統制を適用する
↓
移行手順を検証する
↓
ワークロードを移行する

です。

2. ランディングゾーンは移行開始前に検証する

ランディングゾーンは、AWS環境を安全かつ一貫して運用するための基盤です。

移行時にはランディングゾーンの一般設計をやり直すのではなく、

現在のランディングゾーンが移行対象を安全に受け入れられるかを確認します。

例えば、

対象アカウントが適切なOUにあるか

必要な組織統制が適用されているか

移行担当者のアクセス方法が用意されているか

移行ツールに必要な権限が成立するか

ログと監査要件を満たせるか

対象ワークロードのコンプライアンス要件を満たすか

を移行前に確認します。

移行ツールが動作しても、移行先のガバナンス要件を満たしていなければ、移行準備が完了したとは判断しません。

3. 既存のアカウント構造へ移行対象を割り当てる

アカウント境界をどのように設計するかという一般的な判断は、移行開始前に定められている前提とします。

移行時に必要なのは、その設計を再検討することではなく、

各ワークロードを、既存方針に従って正しい移行先アカウントへ対応付けることです。

例えば移行ポートフォリオには、

アプリケーション所有者

環境区分

データ分類

規制要件

移行ウェーブ

移行先アカウント

移行先OU

などの情報を持たせます。

移行ウェーブを開始する前に、

移行対象
↓
移行先アカウント
↓
移行先OU
↓
適用される統制

の対応関係を確定します。

ここで重要なのは、「移行しやすいアカウントへ一旦入れて後から移動する」のではなく、移行時点から所定のアカウント境界へ配置することです。

4. 既存のAWS OrganizationsとAWS Control Towerを移行へ利用する

企業がすでにAWS OrganizationsやAWS Control Towerを運用している場合、移行のためだけに別のガバナンス体系を作成する必要はありません。

既存AWS Organizations内のOUやアカウントへAWS Control Towerのガバナンスを拡張することもできます。

移行時に確認するのは、対象ワークロードをどのOU / アカウントへ配置し、必要な統制が移行前から適用されるかです。

既存のガバナンスモデルを利用できる場合は、それを移行先にも継続適用します。

5. ガバナンス制御が移行ツールへ与える影響を事前検証する

強い組織統制を適用していると、移行ツールが必要とするAWS API操作も制限される場合があります。

例えば、

移行先アカウントへ厳格な制御を適用した
↓
移行ツールが必要とする操作まで禁止された
↓
カットオーバー当日に初めて判明した

という状態は避けます。

移行前に、本番と同じOU・アカウント・統制条件で移行手順を検証します。

必要な操作が統制と競合する場合も、「移行中だからすべての統制を無効化する」のではありません。

必要性を確認し、

対象

期間

操作

責任者

を限定した例外として管理します。

通常の統制を可能な限り維持したまま移行できる設計を優先します。

6. 移行ガバナンスモデルで責任と判断経路を決める

AWS OrganizationsやAWS Control Towerによる技術的な統制だけでは、大規模移行全体のガバナンスは完成しません。

複数チーム・複数ウェーブで移行する場合は、

誰が作業するか

誰が承認するか

誰が最終責任を持つか

誰へ相談するか

問題発生時に誰へエスカレーションするか

を明確にします。

RACIなどを利用して責任分担を整理できます。

また、移行ウェーブごとに、

前提条件を満たしているか

セキュリティ承認が完了しているか

未解決のリスクや課題が許容可能か

カットオーバーを開始してよいか

ロールバック条件が確認されているか

などを判断するためのゲートを設けます。

例えば、

移行準備完了
↓
セキュリティ・運用確認
↓
カットオーバー承認
↓
本番切り替え
↓
移行後確認

のように、重要な判断ポイントを明確にします。

重大な問題が発生した場合に、その場の担当者だけで判断し続けるのではなく、事前に定めたエスカレーション経路へ上げます。

したがって、移行ガバナンスモデルでは、技術的な統制だけでなく、責任、承認、コミュニケーション、エスカレーション、リスク・課題管理、判断ゲートも定義します。

7. IAMでは人の移行操作とサービス実行権限を分離する

最小権限や一時的な認証情報といったIAMの一般原則を適用することを前提として、移行ではさらに、人が行う移行操作と、移行サービス自身が実行するAWS API操作を分離して管理します。

例えば、中央の移行チームが複数の移行先アカウントを扱う場合は、

移行担当者
↓
対象アカウントの移行作業用IAMロールを引き受ける

移行サービス
↓
サービス用IAMロールを使用する

のように役割を分けます。

移行担当者がサービス用IAMロールの認証情報を共有したり、移行サービスへ人の管理者権限を流用したりしません。

複数アカウントへ移行する場合は、対象アカウントごとに必要な移行ロールやサービスロールを事前に準備しておくことで、

誰がどのアカウントで操作したか

どの操作が人によるものか

どの操作が移行サービスによるものか

を監査しやすくできます。

また、移行ウェーブ単位で対象アカウントが変わる場合でも、人の操作経路とサービスの実行経路を混在させないことが重要です。

8. 暗号化は転送経路だけを見ない

移行データの暗号化では、「ネットワーク上で暗号化されている」だけでは判断を完了できません。

移行データが通る場所を分けて考えます。

つまり、転送中暗号化 ≠ 中間領域の暗号化 ≠ 移行先の保管中暗号化です。

使用する移行サービスごとに、どこまでサービス自身が保護し、どこから利用者側で設定するかを確認します。

9. AWS Transform MGNの移行ツールセキュリティ

2026年現在、従来のAWS Application Migration ServiceはAWS Transform MGNという名称で提供されています。

ここではリホスト方式そのものではなく、AWS Transform MGNを利用すると決めた後のセキュリティを確認します。

代表的な確認事項は、

AWS Replication Agentとレプリケーションサーバー間の通信

レプリケーションサーバーで使用するAmazon EBSの暗号化

レプリケーションサーバーへのネットワークアクセス制限

AWS Replication Agent導入時の認証情報

移行完了後に不要となるアクセスキー

です。

AWS Replication Agentからレプリケーションサーバーへ送信されるレプリケーショントラフィックは、TLS 1.2で暗号化されます。

AWS Transform MGNでは一時的なAWS STS認証情報を利用できるため、利用可能な場合は長期認証情報より一時的な認証情報を優先します。

また、レプリケーションサーバーは不必要に広くインターネットへ公開せず、必要な接続元へ限定します。

移行専用として作成したアクセスキーが残る場合は、利用終了後に削除します。

10. AWS DMSの移行ツールセキュリティ

AWS DMSでは、データベース移行方式そのものとは別に、

移行元との接続

中間レプリケーション領域

移行先との接続

データベース認証情報

を保護します。

対応する接続ではSSL/TLSを利用して、移行元・移行先エンドポイントとの通信を暗号化できます。

またAWS DMSはAWS KMSを利用して、中間レプリケーションストレージや接続情報を暗号化できます。

対応するデータベースエンドポイントでは、AWS Secrets Managerを利用して認証情報を管理することもできます。

したがって、「AWS DMSを使用しているからセキュリティ設定は自動的に完成する」のではありません。

エンドポイント、認証情報、暗号化、IAM権限を移行構成に合わせて確認します。

11. AWS DataSyncでは転送中と保管中の責任を分ける

AWS DataSyncは、転送するストレージデータとメタデータを転送中に暗号化します。

一方で、移行先ストレージの保管中暗号化については、利用するストレージサービス側の設定も確認します。

例えばAmazon S3を移行先にする場合は、Amazon S3側で必要な保管中暗号化を確認します。

このように、移行ツールが担当する保護と、移行先サービスで設定する保護の責任範囲を区別します。

12. 移行ツール自体のセキュリティ承認を確認する

企業によっては、新しいサービスやツールを利用する前にセキュリティ部門の承認が必要です。

移行開始後に、

「AWS Transform MGNは未承認だった」

「AWS DMSが必要とする権限を審査していなかった」

「AWS DataSyncの認証情報管理が社内規程に合っていなかった」

と判明すると、移行ウェーブ全体へ影響します。

そのため、使用予定の移行ツールについて、

IAM権限

認証情報

通信

暗号化

ログ

データ保存場所

コンプライアンス要件

を移行開始前に確認し、必要な社内承認を完了させます。

AWSサービスであること自体を、社内セキュリティ審査を省略する理由にはしません。

13. カットオーバー前にガバナンスとセキュリティを実環境で確認する

本番切り替え直前に確認するのは、アプリケーションが起動するかだけではありません。

少なくとも、

移行先アカウントとOUが正しい

必要な組織統制が適用されている

移行ツールが必要な操作を実行できる

不要な権限が付与されていない

データが必要な範囲で暗号化されている

ログと監査が有効である

必要なセキュリティ承認が完了している

カットオーバーの承認者とエスカレーション経路が明確である

ことを確認します。

ガバナンスとセキュリティを本番切り替え後の作業として残さないことが重要です。

14. 移行時のガバナンス例外はライフサイクルで管理する

移行では、通常の統制では許可されない操作を一時的に認める必要が生じる場合があります。

重要なのは単に「例外を設定する」「後で元に戻す」ことではなく、各例外を誰が、何のために、どの移行ウェーブへ、いつまで承認したのかを追跡できる状態にすることです。

移行ガバナンスでは、少なくとも例外ごとに、

対象の移行ウェーブ

対象アカウントやOU

例外が必要な理由

例外の所有者

承認者

有効期間または終了条件

関連するリスク

終了確認の証跡

を管理します。

例えば、

第12移行ウェーブ
↓
AWS Transform MGNで必要な操作が統制と競合
↓
例外申請
↓
所有者・承認者・適用範囲・有効期限を記録
↓
承認後に移行ウェーブを実行
↓
移行ウェーブ完了
↓
終了証跡を確認
↓
例外を終了済みに更新

という流れです。

これにより、複数ウェーブを並行していても、「この例外はどの移行に必要なのか」「まだ有効であるべきか」「誰が終了を確認したのか」を追跡できます。

特に避けるべきなのは、

移行ウェーブごとに口頭で例外を許可する

所有者を記録しない

終了条件を設定しない

別ウェーブが以前の例外をそのまま流用する

終了したはずの例外が未確認のまま残る

といった状態です。

したがって、移行ガバナンスでは例外を単なる設定変更として扱わず、申請 → 承認 → 利用 → 有効期限 / 終了条件確認 → 終了証跡というライフサイクルで管理します。

15. 移行時のガバナンスとセキュリティの判断フロー

移行対象のセキュリティ・コンプライアンス要件を確認する
↓
既存のアカウント戦略に従って移行先アカウントとOUを対応付ける
↓
AWS Organizations / AWS Control Towerの統制を適用する
↓
責任者・承認者・エスカレーション経路・判断ゲートを定義する
↓
人の移行操作とサービスの実行権限を分離する
↓
転送中・中間領域・移行先の暗号化を確認する
↓
移行ツール固有のセキュリティ要件を確認する
↓
必要なガバナンス例外について所有者・承認者・適用範囲・有効期限を記録する
↓
本番と同じ統制条件で移行を検証する
↓
カットオーバー承認を得る
↓
本番切り替えを行う
↓
移行ウェーブ完了後に例外の終了条件と証跡を確認する

SAP-C02では、AWS OrganizationsやAWS Control Towerの機能を個別に暗記するだけではなく、移行対象を既存のガバナンスモデルへ組み込み、責任・承認・IAM・暗号化・移行ツール固有のセキュリティを移行前から適用し、移行例外をウェーブ単位で追跡・終了管理できることが重要です。