オンプレミスで動くVMをAzureへ移行する際は、移行作業そのものよりも「移行の前後で一時的に開く穴」や「権限・ログ・暗号化の設定漏れ」が重大事故につながりやすいのが落とし穴です。ここでは、移行前・移行中・移行後・ガバナンス運用の4フェーズで、実務で使えるセキュリティ対策と手順を具体的に整理します。
オンプレミスVMのAzure移行でセキュリティ事故が起きやすい理由
オンプレミスのVMをAzureへ「リフト＆シフト（Rehost）」する場合、OSやミドルウェアの状態もそのまま持ち込みやすく、脆弱性や設定不備も一緒に引っ越してしまいます。さらに移行期間中は、検証のために例外ルールを増やしたり、移行用アカウントを作ったり、ログの転送経路を増やしたりと、普段よりも攻撃面（Attack Surface）が急増します。
つまり、セキュアなAzure移行のポイントは「Azureに置けば安全」ではなく、移行プロジェクトの工程にセキュリティを組み込むことです。おすすめは、作業を4フェーズに分けて、フェーズごとの“やること”をチェックリスト化して潰す進め方です。
全体像：4フェーズで整理すると抜け漏れが減る
| フェーズ | 目的 | 最重要ポイント | 成果物（例） |
|---|---|---|---|
| 移行前（準備・計画） | 守る対象とルールを決め、移行作業で穴を開けない | 資産棚卸し、権限設計、ランディングゾーン、秘密情報管理 | 移行設計書、RBAC/PIM設計、ネットワーク設計、チェックリスト |
| 移行中（移行実施） | 移行経路・データ・権限を安全に保つ | 経路暗号化、最小開放、Key Vault/Managed ID、監視強化 | 移行用NSG/Firewall設定、監視アラート、作業ログ |
| 移行後（本番稼働・強化） | 一時設定を撤去し、本番基準へ戻す | RDP/SSH非公開、ハードニング、Defender、ログ一元化 | 本番セキュリティベースライン、バックアップ/DR、監査記録 |
| ガバナンス・運用（継続） | 「安全が続く仕組み」を作る | Azure Policy、タグ/命名、継続スキャン、SOAR、アクセスレビュー | ポリシー/ガードレール、運用手順、定期レビュー計画 |
責任分界を最初に押さえる（IaaS移行は“利用者側の責任”が大きい）
オンプレVMをAzure VM（IaaS）として動かす場合、クラウド側が守ってくれる範囲と、自社が守る範囲を混同すると設計が崩れます。最初に、責任分界をチームで共通認識にしておきましょう。
| 領域 | Azure（クラウド事業者） | 利用者（あなたの組織） |
|---|---|---|
| データセンター（物理） | 施設・物理セキュリティ、ハード故障対応 | — |
| 仮想化基盤 | ハイパーバイザー、基盤ネットワーク、ホスト保守 | — |
| OS/ミドルウェア | — | パッチ適用、設定、不要サービス停止、EDR導入 |
| ネットワーク設定 | 基盤提供 | NSG/Firewall/ルート/公開設定、セグメント設計 |
| IDと権限 | プラットフォーム提供 | MFA、RBAC、PIM、運用ルール、アカウント管理 |
| ログ・監査 | 取得手段提供 | 収集設計、保管、監視、アラート、インシデント対応 |
移行方式でセキュリティの打ち手は変わる
同じ「Azure移行」でも、方式によってリスクの出方が変わります。特にリフト＆シフトは“現状を持ち込む”ため、移行前のヘルスチェックの重要度が上がります。
| 方式 | 概要 | セキュリティ上の注意点 | 向いている対策 |
|---|---|---|---|
| Rehost（リフト＆シフト） | VMをそのままAzure VMへ | 脆弱性・設定不備も移行しやすい。RDP/SSH公開事故が起きやすい | 事前パッチ・棚卸し、移行後ハードニング、Bastion/JIT、Defender強化 |
| Replatform | 一部をPaaSへ寄せる | 接続方式や認証方式が変わり、秘密情報が散らかりやすい | Key Vault参照、Managed Identity、Private Link、監査ログ統合 |
| Refactor | アプリ構造から刷新 | 設計自由度が高い反面、標準化しないとばらつきが増える | IaC（Bicep/Terraform）でセキュリティベースライン強制、Policyでガードレール |
移行前：準備・計画フェーズでやるべきセキュリティ対策
守る対象を決める：資産棚卸し・データ分類・優先度付け
移行の成否は、最初の棚卸しでほぼ決まります。特にセキュリティ面では「重要VMを後回しにして本番直前に慌てる」パターンが危険です。
- VMの役割（AD/ファイル/DB/業務アプリ/踏み台/バッチなど）
- 機密度（個人情報、決済、認証情報、研究データなど）
- 外部公開有無（公開Web、API、VPN終端など）
- 依存関係（どのサーバーがどのポートで通信しているか）
- 停止許容（RTO/RPO、冗長化要否）
ここでのコツは、棚卸しを「台帳」ではなく移行のセキュリティ設計に直結する形にすることです。例えば「インターネット公開が必要」「個人情報を扱う」「特権IDが乗る」の3つは、別枠で“最優先”にするだけで、移行後の事故率が下がります。
Azureランディングゾーンを先に作る（移行先の土台が弱いと全てが崩れる）
VMを移す前に、Azure側の受け皿（サブスクリプション構成、ネットワーク、ログ、ポリシー）を固めます。移行作業中に都度作ると、例外が増えて統制が効かなくなります。
- 管理グループ：本番/検証/開発、部門単位などで整理
- サブスクリプション分割：課金だけでなく、権限境界にもなる
- ネットワーク設計：Hub-Spoke（推奨）、Firewall/DNS/踏み台はHubに集約
- ログ基盤：Log Analyticsのワークスペース設計、保持期間、転送先（SIEM）
- 命名規則・タグ：システム名、環境、担当、データ分類、期限（例：MigrationTempExpireDate）
Azure Migrateアプライアンスのセキュア配置（“移行ツール自体”が狙われやすい）
Azure Migrateのアプライアンスは、オンプレ環境をスキャンしてメタデータを収集します。移行プロジェクトでは、このアプライアンスや移行管理サーバーに権限が集まりがちなので、配置と権限を硬くします。
| 観点 | 推奨 | 実装のポイント |
|---|---|---|
| 権限 | 最小権限のアカウントで収集 | 棚卸し専用アカウントを作り、不要な管理権限を付けない |
| 通信方向 | インバウンドを極力許可しない | オンプレ内からの管理アクセスも管理セグメントに限定。外部からの到達性を作らない |
| ネットワーク | 専用VLAN/セグメントに隔離 | 移行期間だけ例外を作る場合は、期限付き運用（タグ・自動無効化）を前提にする |
| 出力物 | エクスポートデータを暗号化 | アセスメント結果（構成情報）は機微情報になり得る。保管場所とアクセス権を厳格に |
| 更新 | アプライアンス自体もパッチ管理 | 移行期間が長いほど未更新がリスク化。更新の担当者と頻度を決める |
ID・権限設計：RBAC、MFA、PIM、JITを“移行チーム”に適用する
移行プロジェクトは、通常より強い権限が必要になりがちです。ここで「とりあえずOwner」や「共有アカウント」をやると、移行後もその負債が残ります。
- MFA必須：移行管理者・サブスクリプション管理者は必須化
- RBAC：必要な範囲（リソースグループ単位など）まで絞る
- PIM（特権ID管理）：常時管理者をやめ、必要な時間だけ昇格する
- JIT（Just-In-Time）：作業時間だけ管理ポート/権限を開ける（開けっぱなしにしない）
- ブレークグラス：緊急用アカウントを別管理（普段は使わない、監査を強化）
| ロール/機能 | 付与の考え方 | よくあるNG |
|---|---|---|
| サブスクリプションOwner | 原則は最小人数、PIMで一時付与 | 移行ベンダーに常時Ownerを渡す |
| Contributor（RG単位） | 移行対象RGに限定して付与 | 全RGに広く付与して“後で直す” |
| Key Vault管理 | 秘密情報担当を限定、監査ログ必須 | 誰でもシークレット閲覧可能にする |
| ログ/監視 | 閲覧は広く、変更は狭く | アラート無効化やログ削除権限が広い |
オンプレ側の事前ヘルスチェック（“移行後に直す”は高コスト）
移行後に脆弱性が露見すると、Azure側の対策だけでは止まらず、結局OSやミドルの改修が必要になります。移行前に最低限、以下を実施して攻撃面を減らします。
- OS・ミドルウェア・エージェントのパッチ適用（移行前の凍結期間がある場合も、最低限のセキュリティ更新は例外にする）
- 不要サービス停止、不要ソフトのアンインストール（古いJava、使っていない管理ツールなど）
- ローカル管理者・特権アカウント棚卸し（使っていないものは削除/無効化）
- EDR/アンチマルウェアの状態確認（移行後にDefenderへ寄せる設計なら切替計画も作る）
- 公開サービスの設定確認（古いTLS、弱い暗号、使っていないポート開放）
バックアップとロールバックを“セキュリティ対策”として設計する
セキュリティ対策は「防ぐ」だけではなく「被害を限定し、復旧できる」ことが重要です。移行は大きな変更なので、ロールバックと復旧ができないと、インシデント時に選択肢がなくなります。
- 移行前に完全バックアップを取得し、復元テストを実施
- Azure側でもAzure Backupの保護を早期に有効化（本番切替前から）
- 暗号化キー（CMK運用など）を使う場合、復旧手順にキー管理を含める（キーがないと復旧できない）
移行中：リフト＆シフト作業を安全に進めるセキュリティ対策
ネットワーク経路：VPN/ExpressRoute＋“暗号化の前提”を揃える
オンプレとAzure間の接続は、通信経路の盗聴・改ざんリスクを減らすために設計が重要です。
- Site-to-Site VPN：IPsecで暗号化されるため、機密データを扱う移行でも扱いやすい
- ExpressRoute：インターネットを経由しない閉域接続として強い一方、暗号化が“自動で付く”前提にしない（必要に応じてTLS/IPsec等で暗号化を担保する）
実務では「閉域だから平文でもOK」という判断が事故につながりがちです。移行トラフィックの暗号化は、経路（VPN）か上位層（TLS）のどちらで担保するのかを明文化し、レビュー可能な形にしておくのが安全です。
NSG/Firewall：移行期間の例外は“最小＋期限付き”にする
移行中は「一時的に開ける」ルールが増えます。重要なのは、例外を作ること自体ではなく、例外を戻せる仕組みをセットにすることです。
- 移行用NSGは、本番用NSGと分けて管理（後で差分が追いやすい）
- 許可は送信元IP/送信元セグメントを限定（“社内から”ではなく“移行サーバーから”まで絞る）
- ポートは必要最小限（ツール要件に合わせる。迷ったら“広く開ける”ではなく公式要件を確認して確定する）
- 例外ルールにはタグや命名で期限を入れ、期限超過を検知して自動で通知/無効化
| ルール設計の例 | OK例 | NG例 |
|---|---|---|
| 送信元 | 移行アプライアンス/移行管理サーバーの固定IP | Any（0.0.0.0/0） |
| 宛先 | 対象VMサブネット、必要なAzureサービス | VNet全体、全サブスクリプション |
| 期間 | 移行期間のみ有効、期限タグで追跡 | 恒久ルール化して放置 |
| 変更管理 | 申請→承認→実施→証跡（チケット/ログ） | 作業者が現場判断で追加し、記録が残らない |
データ保護：移行ディスク・一時ストレージ・レプリケーションの扱いを統一する
移行時には、VMディスクやスナップショット、レプリケーション用のデータなど「一時的なデータ置き場」が増えます。ここが盲点になりやすいので、“一時でも本番相当”の扱いに寄せます。
- ディスク暗号化：BitLocker/Azure Disk Encryption等を要件に合わせて有効化
- ストレージ暗号化：Azure Storageの暗号化（SSE）を前提に、必要ならCMKを選択
- 転送時暗号化：ツールや経路でTLS 1.2以上を前提にする（設定・プロキシで弱い暗号に落ちないか確認）
- 一時ストレージの公開設定：公開アクセス禁止、ネットワーク制限（特に「作業用に作ったストレージアカウント」が残りやすい）
秘密情報の扱い：Key VaultとManaged Identityを“移行中から”徹底する
移行作業では、スクリプト、設定ファイル、作業手順書などにID/パスワードが紛れ込みやすいです。ここを最初に潰すと、移行後も安全な運用へスムーズにつながります。
- シークレット（パスワード、APIキー、接続文字列）はAzure Key Vaultに集約
- VMや自動化の認証は可能な限りManaged Identityを利用（固定パスワード運用を避ける）
- Key Vaultはアクセス制御と監査ログを必須化（誰がいつ取得したか追える）
移行中の監視：変更が多い期間は“普段より厳しめ”にする
移行期間はアラートが増えますが、ここで監視を緩めると本末転倒です。おすすめは「移行期間だけ監視を強める」運用です。
- Azure Activity Log：NSG変更、Public IP付与、Key Vault設定変更など重要操作を検知
- VMのOSログ：Windowsイベントログ、Linux監査ログをLog Analyticsへ送る
- ネットワーク可視化：NSGフローログ、Firewallログ（導入している場合）
- Defender for Cloud：推奨事項とアラートを移行対象に適用
| ログ種別 | 最低限集めたい内容 | 見たい検知例 |
|---|---|---|
| Azure操作ログ（Activity） | 権限変更、ネットワーク変更、Key Vault変更 | Public IP付与、NSGの0.0.0.0/0許可、所有者変更 |
| 認証ログ | サインイン、条件付きアクセス結果 | 不審な場所/失敗連続、MFA回避の兆候 |
| VM内部ログ | ログオン/特権操作/プロセス起動 | 管理者ログオン増加、未知プロセス、サービス作成 |
| ネットワークログ | 許可/拒否、通信先 | 外部への不審な通信、管理ポートへの試行 |
移行後：本番稼働・強化フェーズで必ずやること
管理アクセスを安全化：RDP/SSHをインターネットに直接公開しない
Azure移行で最も多い事故の1つが「移行後にRDP/SSHがPublicで開いていた」です。移行直後は設定が仮のまま残りやすいので、最優先で閉じます。
- Azure Bastionで管理接続（RDP/SSHの直接公開を避ける）
- JITアクセス（必要な時間だけ管理ポートを開放）
- 管理者端末は、可能なら専用の管理端末/VDIに統一し、条件付きアクセスで制御
移行のための一時設定を撤去する（“後で消す”はだいたい忘れる）
移行のために追加したアカウント、例外ルール、エージェント、作業用ストレージは、移行後に残るとリスクになります。移行完了の定義に「撤去完了」を入れて、完了条件にしてしまうのが現場で効きます。
- 移行専用アカウントの無効化/削除
- 移行専用NSG/Firewallルールの削除（期限タグで洗い出し）
- 作業用ストレージアカウントの削除、または公開無効化とアクセス制限
- 不要エージェントの整理（重複した監視・セキュリティエージェントが残ると運用が壊れる）
Defender for Cloudで“継続的に直す仕組み”を作る
移行直後は、推奨事項が大量に出ることがあります。大切なのは、推奨を放置せず、優先度を付けて回すことです。
- Microsoft Defender for Cloudを有効化（VM保護、推奨、脅威検知）
- 重要VMから順に、推奨事項（Secure Score）を改善
- 脆弱性管理は「移行直後に一度」ではなく、定期スキャン＋改善サイクルに乗せる
パッチ運用をAzure前提へ：属人化を解消する
オンプレ時代のWSUSや手動更新のまま運用すると、クラウドのスピードに追いつけずリスクが蓄積します。更新の適用方法・メンテナンス時間・検証手順を、Azure移行に合わせて再設計します。
- 更新適用の方式を統一（リング運用：検証→準本番→本番）
- 再起動を含むメンテ時間を合意し、業務影響を見える化
- 更新失敗時のロールバック/復旧手順を用意
バックアップ/DRを“Azureの標準機能”で再構築する
移行後は、オンプレのバックアップ方式をそのまま引きずるより、Azureの仕組みに寄せる方が監査・運用が楽になります。
- Azure Backupの適用範囲と保持期間を定義（機密度・RPO/RTOで差を付ける）
- 重要システムはリージョン障害も想定し、DR（例：レプリケーション）を検討
- 復元テストを定期化（年1回ではなく、重要度に応じて回す）
ガバナンス・運用：移行が終わってからが“本当のセキュリティ”
Azure Policyでガードレールを敷く（人の注意力に頼らない）
移行後に最も効くのが、Azure Policyによる強制です。「やってはいけない設定」を技術的にできなくすると、運用品質が安定します。
| ガードレール例 | 狙い | 実務での効果 |
|---|---|---|
| 暗号化されていないディスクを拒否 | 機密データ漏えい対策 | 移行時の“暗号化し忘れ”を防ぐ |
| Public IPの作成を制限 | 意図しない公開を防止 | RDP/SSH公開事故の芽を摘む |
| タグ必須（システム/環境/担当/機密度/期限） | 資産管理・責任所在 | 放置リソース、期限切れ例外の検知ができる |
| 診断設定（ログ送信）を必須 | 監査証跡の欠落防止 | ログ未送信の“ブラックボックスVM”が減る |
| 許可リージョン/許可SKUの制限 | 統制・コスト・要件順守 | バラバラな構成による運用崩壊を防ぐ |
権限は“強く付ける”より“必要な時間だけ上げる”へ
移行直後は作業が残りがちで、管理者権限が緩い状態が続きやすいです。ここでPIMとアクセスレビューを回し、恒久的に強権限が残らない形へ戻します。
- 管理者はPIMで昇格、承認フローと理由入力を必須化
- 外部委託がある場合、契約終了日に合わせて権限棚卸し（アクセスレビュー）
- ブレークグラス運用（緊急時以外は使わない、利用時は即通知＋事後レビュー）
ゼロトラストの考え方をAzureで実装する
移行後は「社内ネットワーク＝安全」という前提が崩れます。ゼロトラストの考え方（侵入前提、明示的検証、最小権限）を、ID・ネットワーク・データの3点で揃えるのが現実的です。
- ID：条件付きアクセス、MFA、デバイス準拠、特権分離
- ネットワーク：セグメント分割、Private Link、最小開放、踏み台経由
- データ：暗号化、キー管理、データ分類とアクセス制御
運用自動化：セキュリティを“毎日回る仕組み”にする
人手で回すと必ず漏れます。Azure AutomationやLogic Apps、（可能なら）Microsoft SentinelのSOARで、繰り返し作業を自動化します。
- 期限切れの例外ルール（NSG/Firewall）を検知して通知
- 使われていないアカウント・権限の棚卸しを定期実行
- Key Vaultのシークレット/証明書ローテーションをスケジュール化
- 高リスクアラートの一次対応（隔離、IPブロック、チケット起票）を半自動化
実務で使える：フェーズ別チェックリスト（最小セット）
現場で「やったつもり」を防ぐために、チェック項目を“判定できる形”にしています。プロジェクト管理表にそのまま貼り付けて使えます。
| フェーズ | チェック項目 | 合格条件（例） | 優先度 |
|---|---|---|---|
| 移行前 | 資産棚卸し（重要度/外部公開/依存関係） | 対象VMが分類され、優先度と移行順が決まっている | 高 |
| 移行前 | RBAC/PIM/MFAの適用 | 移行管理者にMFA必須、強権限はPIMで一時付与 | 高 |
| 移行前 | Key Vault運用（秘密情報の集約） | パスワード直書きがなく、取得ログが残る | 高 |
| 移行中 | 移行用ネットワーク例外の最小化 | 送信元/宛先/期間が限定され、期限タグで追跡可能 | 高 |
| 移行中 | ログ/監視の強化 | 重要操作・認証・VM内部ログが集約され、アラートが有効 | 高 |
| 移行後 | RDP/SSHの直接公開なし | Bastion/JIT等で管理し、Publicの管理ポートが存在しない | 高 |
| 移行後 | 一時設定の撤去 | 移行用アカウント/ルール/ストレージが棚卸しされ、撤去済み | 高 |
| 運用 | Azure Policyのガードレール | 暗号化・タグ・ログ送信・公開制限が強制/監査されている | 中 |
| 運用 | 定期レビュー（権限・ログ・脆弱性） | 月次/四半期で指標と改善が回り、担当が明確 | 中 |
よくある失敗と、現場で効く回避策
| 失敗パターン | 起きること | 回避策（実務向け） |
|---|---|---|
| 移行期間の例外ルールが残る | 公開面が広がり、攻撃されやすい | 期限タグ＋棚卸しジョブ＋移行完了条件に“撤去”を入れる |
| 共有アカウント/強権限のばらまき | 監査不能、内部不正リスク増 | MFA必須、PIMで昇格、作業者単位のIDを徹底 |
| 秘密情報が手順書やスクリプトに埋まる | 漏えい時の影響が大きい | Key Vault集約、Managed Identity利用、レビュー項目に追加 |
| ログ基盤が後回し | 問題が起きても追えない | ランディングゾーンにログを含め、移行前に“送れる状態”を作る |
| 「閉域＝暗号化不要」と判断 | 要件違反・盗聴リスク | 暗号化の担保方式（VPN/TLS/IPsec）を設計書に明記しレビューする |
セキュアなAzure移行を成功させる進め方
オンプレミスVMのAzure移行でセキュリティを確保するコツは、技術要素を増やすことではなく、移行工程に「最小権限」「暗号化」「監視」「撤去」「ガードレール」を組み込むことです。
- 移行前：棚卸しと設計（ランディングゾーン、RBAC/PIM、Key Vault、ネットワーク）で“穴を作らない”
- 移行中：例外は最小・期限付き、ログとアラートを強めて“怪しい動きを見逃さない”
- 移行後：RDP/SSH非公開、一時設定撤去、Defenderと脆弱性管理で“本番基準に戻す”
- 運用：Azure Policyと自動化で“安全が続く状態”を作る
この4フェーズをチェックリストで回せば、移行スピードを落とさずにセキュリティ品質を上げられます。移行は一度きりのイベントではなく、その後の運用の始まりです。最初から運用を見据えた設計にして、移行直後の不安定な期間を安全に乗り切りましょう。
コメント