こんにちは、Enterprise Cloud部 ソリューションアーキテクト1課 宮形 です。
令和6年度はガバメントクラウドへの早期移行団体検証事業へ申込された、またはこれから申込予定の地方自治体様が多くおられると予想します。それに合わせて必要なAWSリソース利用料やAWSの設計構築・運用保守費用の見積・予算取りを進めることになります。
気を付けたいのが、ガバメントクラウドAWS「以外」にも必要となる設備・作業があることです。プロジェクトを開始しても、準備不足により作業がストップしたり予算不足になる事態は避けたいところです。
本BLOGでは、私がこれまで幅広い分野のお客様と接してお伺いすることが多かったAWS「以外」で必要となった設備・作業についてご紹介したいと思います。
この内容は個人の私見と経験則で書いておりますので、ご覧なられた皆様のシステムや環境に必ずしも該当するものではありません。またAWSに関わる範囲のみになりますので、他にも必要となる設備・作業がありえます。どうかご了承ください。
まずご覧いただきたい資料
まずご覧いただきたい資料として、AWSより提供される「ガバメントクラウド利用タスクリスト」になります。こちらには、地方自治体様がガバメントクラウドAWSへ移行するにあたり必要となる作業内容一覧（タスクリスト）が紹介されています。 チェックリストとしてご活用いただき、移行に必要な備えを洗い出して頂くところから始めるとよいでしょう。
そのうえで AWS「以外」で必要な設備・作業について考える
「ガバメントクラウド利用タスクリスト」をチェックしまして、おおまかに全体としてのやるべき事をイメージ出来たと思います。そのうえで、AWS「以外」で必要な設備や作業について、個人的に該当する可能性が高いと思う順にご紹介させていただきます。
庁内ルーター(BGPルーター等) Customer Gateway、既存ネットワーク機器
ほぼ全ての地方自治体様で必要となる設備および設定変更作業として、クラウド接続サービスと接続する為のマイナンバー利用事務系ネットワーク(以下 マイナンバー系と記)のルーターがあります。（図では Customer Gatewa BGPルーター等と表記)
オンプレミスとAWS間の接続は、専用の閉域ネットワークを提供する AWS Direct Connect を用いることになります。AWS Direct Connectは ボーダーゲートウェイプロトコル (BGP) を用いてルーターとAWS間を接続し、経路の交換を行います。ネットワークを得意とされるベンダー様への設定変更の依頼や、キャリア様が提供するクラウド接続サービスのルーターを調達して利用することになるかと思います。また、昨年度には第5次LGWANにおいてガバメントクラウドへの接続機能が提供される旨の方針が打ち出されております*1ので、LGWANをクラウド接続サービスとしてご利用計画する地方自治体様も多いのではないでしょうか。
AWSクラウドの利用により Amazon VPC としてプライベートネットワークを新設することになります。マイマンバー系ネットワークに新しいIPアドレス範囲が追加になりますので、既存ネットワーク機器のルーティング等の設定変更が必要な場合もありえます。事前に調査のうえご計画頂くことをお勧めします。
コンソール保守端末とMFAデバイス
AWSの設定管理を行うための管理画面になる、AWSマネジメントコンソール の専用の保守端末となるパソコンが必要になるかと思われます。
ガバメントクラウドでは無い通常のAWSマネジメントコンソールでは、インターネットに接続できればIDパスワード認証を元にサポートするWebブラウザからどこからでも利用することができます。ただし、ガバメントクラウドのコンソール保守端末は総務省ガイドラインの三層分離方針に基づきアクセス元の制限が必須となっています *2。制限手法としては端末シリアル番号等が想定されますので、専用のパソコンを用意することになるかと思われます。
また、早期移行団体検証事業の検証テーマ*3にもある通り、管理コンソールにはMFAデバイス(ハードウェア)を用いた多要素認証が必要となることが想定されます。MFAデバイスを有していない地方自治体様は、設備の用意を計画する必要があります。
AWSアカウント毎に受信できるメールアドレス
こちらはガバメントクラウドに限った話ではないのですが、AWSアカウント毎に一意な受信できるメールアドレスを用意する必要があります*4。
ご利用のメールサーバーやサービスによっては、メールアドレスやエイリアスが増える都度ライセンス買い足ししたり、設定作業をベンダーにお願いする状況が考えられます。多くの地方自治体様では、組織や環境毎にAWSアカウントを別途払い出す「マルチアカウント」構成になりますので、アカウントが増える都度受信できるメールアドレスが必要になります。軽微な所ですが、数も多くなると管理コストもかかりますので注意が必要と考えます。
「受信できる」メールアドレスであればよいので、エイリアス(別名メールアドレス)やメーリングリストでも代替可能です。
クライアントの設定変更作業（標準準拠システム等利用端末・マイナンバー系PC）
ガバメントクラウドへの移行の目的としては、標準準拠システム等へのアプリケーション移行があります。アプリケーションが変わることでクライアント側の設定変更作業が必要になる可能性があります。
AWSクラウドへの移行においてはネットワーク構成が大きく変わります。サーバーのIPアドレスも変更になる可能性があり、例えば下記のようなクライアントの設定変更作業が考えられます。
- クライアントに設定した各ショートカットアイコンの変更
- 庁内ポータルサイトなどのURLリンク書き換え
- ログインスクリプトの修正
後記の Active Directory グループポリシーやDNSサーバーの設定変更でこれらを回避できる場合もあるかと思います。現状のクライアント仕様を整理し、設定変更作業の有無を計画するとよいでしょう。
Active Directory ドメインサービス の設定変更作業
上記の「クライアントの設定変更」にも関係しますが、何かと利用され設定変更が伴うのが Active Directory ドメインサービス (以下ADと記) です。ご利用されるAWSサービスにもよりますが、例えば下記のような作業が考えられます。
- アプリケーションやAWSサービスの利用に必要な設定を一括で行うグループポリシーの設定変更
- AD と連携する AWSサービスのサービスアカウントの作成 (例: AD Connector、FSx for Windows File Server)
- ネットワークアドレス追加に伴う サイト構成
なお、ファイルサーバーのマネージドサービス Amazon FSx for Windows File Server においても、ADサーバー側で サービスアカウント、サービスプリンシパル名 (SPN)、DNSエイリアス等の設定変更を求める箇所があります。ご利用計画されている地方自治体様においてはご注意ください。
FSx for Windows ファイルサーバーのファイルシステムを、セルフマネージド Microsoft アクティブディレクトリのドメインに結合するためのベストプラクティス - Amazon FSx for Windows File Server チュートリアル 5: DNS エイリアスを使用してファイルシステムにアクセスする - Amazon FSx for Windows File Server
庁内DNSサーバーの設定変更作業
AWSサービスではDNSでのホスト名(FQDN)での接続が必須なものが多くあります。庁内のマイナンバー系ネットワークより名前解決が行えるよう、庁内DNSサーバーの設定変更作業が必要になると考えられます。
AWSサービスにおいては、データベースのマネージドサービスにあたる Amazon RDS、Amazon Aurora や、バックアップやログ保管に多く利用されるオブジェクトストレージ Amazon S3、各AWSサービスへのプライベート接続を提供する VPCエンドポイント 等が、ガバメントクラウドにおいても多く利用されると考えられます。これらAWSサービスはIPアドレスでの接続がサポートされておらず、DNSでのホスト名(FQDN)での接続方法のみが提供されます。
クライアントからAWSサービスの名前解決が行えるように、具体的には 庁内DNSサーバーのフォワーダー等を Amazon Route 53 Resolver に向けて設定する等が想定されます。
庁内ファイアウォールの設定変更作業
庁内のマイナンバー系ネットワークのクライアント、サーバー間にファイアウォールを設定している地方自治体様においては、ファイアウォールのルール(ポリシーやACL)の設定変更が必要になる可能性があります。
繰り返しですが、AWSクラウドの移行に伴い各サーバーのIPアドレスも変更になることが一般的です。ファイアウォールのルールに設定された接続元、接続先IPアドレスを変更することで、クライアントからガバメントクラウドAWS上のサーバーに接続が可能となります。
ルート証明書・中間証明書の配布作業
AWSクラウドの各サービスの多くでは、クライアントとの通信に HTTPS のプロトコルが利用されます。HTTPSでの通信を行うため、 ルート証明書・中間証明書をクライアントへ配布する作業が必要となる場合があります。
HTTPSでは通信の暗号化（TLS 化）が行われますので、セキュリティ的にも望ましく、各ガイドラインの準拠にも貢献します。HTTPSではサーバー側が利用するサーバー証明書の正当性の確認を、クライアント側に配置されるルート証明書・中間証明書で行います。このルート証明書・中間証明書はクライアントのパソコンやOSが古い状態だと最新化されておらず、サーバー証明書の正当性を確認することが出来ない場合があります。
クライアントがインターネットに接続していれば、OSアップデートによりルート証明書・中間証明書が最新化されるのですが、マイナンバー系ネットワークは閉域になりますので、この最新化が行われていない可能性があります。
この場合は、手動で ルート証明書・中間証明書をクライアントへ配布することで解決します。この作業を想定しておく必要があります。
なお、上記で説明したADサーバーのグループポリシーでクライアントへ ルート証明書・中間証明書を一斉配布することもできます*5。この機能を活用するのも手かと思います。
AWSが提供する ルート証明書・中間証明書は下記サイトよりダウンロードして入手することができます。
まとめ
ここまでご覧いただきありがとうございます。事前に理解して備えておけば、プロジェクトの進行の妨げにならないよう対応を計画することが可能なものばかりかと思います。AWSに関わる範囲として取り上げましたが、いずれもITインフラを大きく変更する時には共通する事項にも思えますので、今の環境理解を深めるよい機会としてチェックいただいてはいかがでしょうか。
令和7年度末までに地方公共団体の基幹業務システム(マイナンバー利用事務系)をガバメントクラウドを活用した標準準拠システムに移行することが目標として策定されています*6。残された時間はそれほど多くはないと考えますので、皆様のガバメントクラウドへの移行がスムーズに行われることを心より願っています。
本BLOGの内容が、少しでも皆様の参考になれば幸いです。
*1:令和５年２月２１日 地方公共団体情報システム機構 J-LIS 次期LGWANの検討状況（セキュリティ関係） : https://www.soumu.go.jp/main_content/000866619.pdf
*2:デジタル庁 GCASガイド - ガバメントクラウドの全般的なガイド - ガバメントクラウド利用システムにおけるセキュリティ対策(共通)
*3:令和6年度ガバメントクラウド早期移行団体検証事業 : https://www.digital.go.jp/news/d6208297-df46-4a4f-9810-46d34a0d2640
*4:AWS アカウント・請求関連のご質問「Q. 同じメールアドレスで複数の AWSアカウントを作成することは可能ですか？」 : https://aws.amazon.com/jp/aws-jp-faq/
*5:グループ ポリシーを使用してクライアント コンピューターに証明書を配布する : https://learn.microsoft.com/ja-jp/windows-server/identity/ad-fs/deployment/distribute-certificates-to-client-computers-by-using-group-policy
*6: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
