ガバメントクラウドAWSへP2V・V2Vしてもよいか考える

記事タイトルとURLをコピーする

こんにちは、Enterprise Cloud部 ソリューションアーキテクト1課 宮形 です。

本BLOGではガバメントクラウドAWSにおいて、オンプレミスのサーバーをP2V、V2Vの手法でクラウドリフト(クラウド移行)することが可能か検討した内容をご紹介します。

政府デジタル庁の方針によりますと、令和7年度末までに地方公共団体の基幹業務システム(マイナンバー利用事務系)をガバメントクラウドを活用した標準準拠システムに移行することが目標として策定されています*1。 本BLOG記載時 2024年4月では、その目標まで残すところ2年となりました。限られた短い時間のなかでサーバーをリプレース(移行)するときに用いる手法として P2VV2V があります。ガバメントクラウドAWSにおいてもこの手法が利用可能なのか、国から発行されるガイドラインや仕様と、AWS機能とを照らし合わせて実現性可否を検証していきたいと思います。

  • P2V・V2Vとは
    • P2V:Physical to Virtual の略。オンプレミス上の物理サーバーを仮想サーバーやクラウドへそのまま移行する手法
    • V2V:Virtual to Virtual の略。オンプレミス上の仮想サーバーを別の仮想サーバーややクラウドへそのまま移行する手法

なお、本BLOG記載時 2024年4月の時点ではガバメントクラウドに P2V、V2V を行った当社事例はございません。実施を推奨するものでもなく、あくまで個人的に技術可否を検討した内容になります。ご了承ください。

ガバメントクラウドAWSへP2V・V2Vしてもよいか

「ガバメントクラウドとしてAWSへP2V・V2Vしてもよいか?」という問いについては、個人的に調べた限り回答となる情報はありませんでした。デジタル庁の資料に移行手法の比較検討したものがありますが*2、ここにも P2V・V2V が行われたような事例は表記ありません。P2V・V2V はサーバー延命に用いられることが多いので、積極的に採用する方式ではなく当然かもしれません。逆に「してはダメ」という情報もないので、ガバメントクラウドの利用者においては各組織のセキュリティ要件から逸脱がない範囲において、実施可否をご自身で判断することになると考えました。

ガバメントクラウドにおけるマイナンバー利用事務系のセキュリティ要件を整理

AWSにおいてはオンプレミスのサーバーを P2V、V2V する機能は複数用意されています。代表的なものとして AWS Application Migration ServiceVM Import/Export があります。

これら機能が、地方自治体(地方公共団体)におけるマイナンバー利用事務系のIT全般セキュリティガイドラインに準拠しているかを見ていきたいと思います。本BLOG記載時 2024年4月の時点では、総務省より提供されております下記資料がガイドラインとして最新情報かと思われましたので、こちらの資料よりセキュリティ要件を整理しました。

地方公共団体における 情報セキュリティ監査に関する ガイドライン(令和 5 年 3 月版)

私なりに読解しまして、関係しそうな順守すべきセキュリティ要件は下記かと見受けられました。

  • P.31 「第3章 情報セキュリティ監査項目」
    • No.18 - マイナンバー利用事務系と他の領域との分離
  • P.133 「参考 市区町村においてクラウドサービス上で標準準拠システム等を整備及び運用する場合の追加監査項目を、次頁以降に示す」セクション
    • No.4 - マイナンバー利用事務系と接続されるクラウドサービス上での情報システムの扱い
    • No.5 - マイナンバー利用事務系と接続されるクラウドサービス上での情報資産の取扱い
    • No.7 - 機器の廃棄等

これらをかみ砕くと、下記が達成されている必要があると解釈しました。

1. サーバー移行に利用するネットワークがインターネットや他用途ネットワーク(LGWAN接続系、インターネット接続系)と分離されていること

2. サーバー移行に利用される通信が暗号化されていること

3. サーバー移行に利用されるデータが暗号化されたストレージに保管されていること

4. サーバー移行の過程でデータが保持された設備が、クラウド事業者によってセキュリティを確保し廃棄されていること

ではこれらを達成するために、AWSとしてどのような構成をとるべきか検討していきたいと思います。

AWSとしてのP2V、V2V手法毎の検討

P2V、V2V を行うための代表的なAWSサービス毎に、セキュリティ要件を達成する構成を検討します。おおざっぱですが、下記手法毎の概要、メリット・デメリット、向いているケースを表でまとめます。

移行手法に用いるAWSサービス 概要 メリット・デメリット 向いているケース
AWS Application Migration Service Agent が移行元サーバーのデータを追跡し、継続的レプリケーションでAWSのEC2へリフトを行う ■メリット
・仮想サーバー(V2V)のみならず物理サーバー(P2V)にも利用できる
・レプリケーションによる増分移行
■デメリット
・移行元サーバーにAgentインストールが必要(vCenter6.7 および 7.0 でエージェントレス可)
・AWS側に中継用サーバーが作られる
・サポートOSが限定的
・移行元が物理サーバー
・データ量が多いサーバー
VM Import/Export 移行元仮想サーバーのイメージファイルを直接AWSへアップロードしてEC2に変換する ■メリット
・Agentインストール不要
・中継用サーバー不要
■デメリット
・レプリケーション機能がないので移行、サーバー切替に時間要する
・データ量が少ないサーバー
・サーバー切替が長時間でも問題ない

それぞれ手法毎のAWS構成図をもとに各要素を解説したいと思います。結論としては、どちらの手法においてもセキュリティ要件を達成することは可能という見解となりました。

過去に AWS Server Migration Service という仮想サーバーのV2Vに用いるサービスがありました 2022 年 3 月 31 日 に廃止されています。

AWS Application Migration Service を用いる場合

AWS Application Migration Service はAWS提供サービスとして唯一物理サーバーのP2Vに利用できる移行手法になります。移行元サーバーには AWS Replication Agent をインストールし、このエージェントが移行元サーバーのデータを追跡し、AWSの Replication Server や Application Migration Service にレプリケーションにてデータ転送を行います。

1. サーバー移行に利用するネットワークの分離

地方自治体マイナンバー系ネットワークからAWSまでの間のネットワークは各社のクラウド接続サービスで接続します。これらは閉域網であるため他ネットワークとは分離されています。AWS内のVPCや各Gatewayは他用途のネットワークとの接続箇所は無く、こちらも分離されていると言えます。最後に AWS Application Migration Service への接続ですが、AWS Application Migration Service はプライベートIPアドレスを有しておらずVPCに直接接続せず、パブリックIPアドレスで接続する必要があります。これではインターネット経由の接続が必要となります。対策として VPCエンドポイント を用いることで、指定VPCに限定してプライベートに接続することが可能になります。これによりサーバー移行に利用した全てのネットワーク経路はインターネットや他用途ネットワークと分離した構成を維持することができます。

2. サーバー移行に利用される通信の暗号化

移行元サーバーの AWS Replication Agent は、Replication Server や Application Migration Service へデータ転送を行います。この通信は HTTPS が利用されますので、通信の暗号化を実現することができます。

3. データ保存先ストレージの暗号化

移行元サーバーからのレプリケーションによりAWS上に同期されたデータは Replication Server にアタッチされた仮想ディスクにあたる Amazon EBS に保管されます。Amazon EBSは AWS上の鍵管理を担う AWS Key Management Service (KMS) でストレージの暗号化を行います。これにより、KMSの利用権限の無いアクセス元からはデータを復号、閲覧することが出来なくなります。また、KMSでは ユーザーが鍵の作成、削除を制御できる カスタマーマネージドキー を選択することができます。カスタマーマネージドキーを削除することで、データは復号できなくなり、データ削除に確実性を持たせることができます。

VM Import/Export を用いる場合

VM Import/Export でV2Vを行う場合、移行元仮想サーバーのイメージファイル(OVF、OVA等)を S3バケット に格納し、そこからEC2のマシンイメージにあたる AMI へ変換する手順となります。

1. サーバー移行に利用するネットワークの分離

地方自治体マイナンバー系ネットワークからAWSまでの間のネットワークは各社のクラウド接続サービスで接続します。これらは閉域網であるため他ネットワークとは分離されています。AWS内のVPCや各Gatewayは他用途のネットワークとの接続箇所は無く、こちらも分離されていると言えます。最後にS3バケットへの接続ですが、S3はプライベートIPアドレスを有しておらずVPCに直接接続せず、パブリックIPアドレスで接続する必要があります。これではインターネット経由の接続が必要となります。対策として VPCエンドポイント を用いることで、指定VPCに限定してプライベートに接続することが可能になります。これによりサーバー移行に利用した全てのネットワーク経路はインターネットや他用途ネットワークと分離した構成を維持することができます。

2. サーバー移行に利用される通信の暗号化

移行元仮想サーバーのイメージファイル(OVF、OVA等)を 作業PC (AWS CLI) よりS3バケットへアップロードします。この通信は HTTPS が利用されますので、通信の暗号化を実現することができます。

3. データ保存先ストレージの暗号化

移行元仮想サーバーのイメージファイル(OVF、OVA等)の格納先となる S3バケット は、AWS上の鍵管理を担う AWS Key Management Service (KMS) でストレージの暗号化を行います。これにより、KMSの利用権限の無いアクセス元からはデータを復号、閲覧することが出来なくなります。また、KMSでは ユーザーが鍵の作成、削除を制御できる カスタマーマネージドキー を選択することができます。カスタマーマネージドキーを削除することで、データは復号できなくなり、データ削除に確実性を持たせることができます。

共通要件:クラウド事業者によるデータ廃棄について

AWS Application Migration Service、VM Import/Export どちらにも共通する要件として、AWSにおけるデータの廃棄のセキュリティの確保です。AWSでは「NIST 800-88 に詳細が説明されている方法を使用してメディアを廃棄する」ことが公言されており、総務省のガイドラインに準拠すると判断出来ます。

aws.amazon.com

技術的な懸念事項

IAMユーザーとアクセスキーが必要

AWS Application Migration Service での AWS Replication Agent インストール時、VM Import/Export での AWS CLI での S3バケットへの仮想サーバーイメージファイルのアップロード時、それぞれでIAMユーザーのアクセスキー入力が求められます。このIAMユーザーのアクセスキーですが漏洩するとAWSの不正利用や情報漏洩にもつながる恐れがあるため、ガバメントクラウドでは利用が原則禁止とされています*3。GCASガイドによると、届け出をして審査結果によっては対策が講じられた中で利用が認められるとありますが、P2V・V2Vが理由として認められるかは不明です。

AWSリソースへのDNSでの名前解決が必要

AWS Application Migration Service、VM Import/Export どちらの手法でもAWSリソースへの接続をインターネットを介さずプライベートに行うためにVPCエンドポイントを利用します。このVPCエンドポイントはDNSでの名前解決が必要です。地方自治体様のマイナンバー利用事務系ネットワークはインターネット未接続ですので、DNSサーバーが利用できない可能性があります。対策として新たにDNSサーバーを用意するか、Amazon Route 53 Resolver というAWS側が提供するDNS名前解決を実現するサービスを構築する必要があります。

AWS のサービス によるアクセス AWS PrivateLink - Amazon Virtual Private Cloud

まとめ

いかがでしたでしょうか。技術的な懸念事項が解消すれば、ガバメントクラウドにおいてもAWSの各サービスを適切に利用することで、総務省のガイドラインに基づいてマイナンバー利用事務系のサーバーを安全にAWS上へP2V・V2Vすることが可能と判断しました。

P2V・V2Vはあくまで早急なクラウドリフトのための一時的措置であり、クラウドリフト後は引き続きサーバーOSのライフサイクルに合わせた更新をする必要があることにご注意ください。総務省のガイドラインにも「No.278 サポート終了ソフトウェアの使用禁止」がセキュリティ監査項目として定義されております。AWSにおいては Amazon RDSAmazon AuroraAmazon FSx for Windows File Server といったマネージドサービスをご利用いただくことで、OSのライフサイクル管理の責任から脱却することができます。ぜひこの機会にこれらAWSマネージドサービスの活用を前向きにご検討ください。

本BLOGの内容が、少しでも皆様の参考になれば幸いです。

*1:2023年9月 - 地方公共団体情報システム標準化基本方針 : https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/c58162cb-92e5-4a43-9ad5-095b7c45100c/f6ea9ca6/20230908_policies_local_governments_outline_03.pdf

*2:2023年4月 - 標準準拠システム移行方法(比較)の検証-検証結果 : https://www.digital.go.jp/assets/contents/node/information/field_ref_resources/8c953d48-271d-467e-8e4c-f7baa8ec018b/09f2f45e/20230428_policies_gov_cloud_outline_05.pdf

*3:デジタル庁 GCASガイド - ガバメントクラウド AWS 利用ガイド - ユーザー管理方法(AWS編) - アクセスキーの原則利用禁止

宮形純平(執筆記事の一覧)

エンタープライズクラウド部 ソリューションアーキテクト1課

好きなお酒は缶チューハイと本格焼酎