Amazon Web Services ブログ

ガバメントクラウドの道案内『ASP＆運用管理補助者編』

[2024.12.03 Updated] 「d. Private CA」 に関する記載を「d. 暗号化通信」 とし、パブリック証明書を含めた内容に修正しました。

ガバメントクラウドに関する情報は AWS も含めてさまざまな方面から毎日のように発信されており、どの情報を追ったらいいのか、何を気にするべきなのかわからなくなってくることもあるかと思います。

そこで、このブログでは「ガバメントクラウドの道案内」と題して自治体ガバメントクラウドに携わる方がそれぞれ何を検討すべきで、どの資料を確認した方がいいのかを役割別にまとめています。

本ブログは自治体に業務システムを提供するベンダーの方へ向けた「ASP&運用管理補助者編」です。
そのほかの方に向けたブログに関しては以下リンクをご参照ください。

ガバメントクラウドではガバメントクラウドの個別領域 (AWS アカウント) の運用管理を行う事業者を「ガバメントクラウド運用管理補助者」、業務システムの構築・提供・運用保守など行う事業者を ASP として定義しています。
どちらか片方、もしくは両方に該当する事業者の方にご参考いただける内容となっています。

ここでは気にするべきポイントをステップに分けて紹介します。

  1. 「共同利用方式」か「単独利用方式」かを考える
  2. 自社の作業範囲を明確にする
  3. (共同利用方式の場合) 団体間の分離方式を確認する
  4. 運用保守経路を確保する
  5. モダナイズを検討する
  6. 利用できるベストプラクティスやサンプルがないか確認する

それぞれの対応方法について概要と、どのように考えていくかをお伝えします。

(1) 「単独利用方式」か「共同利用方式」かを考える

まずはガバメントクラウドの利用方式として「単独利用方式」か「共同利用方式」のどちらで自治体へ環境を提供するか考える必要があります。
単独利用方式の場合、自治体職員にも AWS アカウントの権限が払い出されます。共同利用方式の場合、ベンダーにのみ AWS アカウントを利用する権限が払い出されます。
共同利用方式では自治体が AWS アカウントの運用管理を個別に行わない前提となっているため、各自治体で要件の差が出づらいと考えられます。そのため複数の自治体へ業務システムを提供する場合、共同利用方式を選択し、 AWS CDK などの IaC や、監視のダッシュボード等を共通化しておくことにより、運用保守の工数や構築の初期費用を削減できることがあります。
「地方公共団体情報システムのガバメントクラウドの利用に関する基準 【第 1.0 版】」でもいくつかの理由から共同利用方式が推奨されています。
一方で、Direct Connect ・AWS Transit Gateway 等のネットワークを管理するアカウントは、自治体個別の要件が発生することが多いため単独利用方式になることが多いと考えられます。
ガバメントクラウドの道案内: 第 1 回『自治体職員編』: (4) 「共同利用方式」か「単独利用方式」かを考える では自治体職員の方の立場から 2 つの利用方式の違いについて記載しているため、こちらも併せてご参照ください。

(2) 自社の作業範囲を明確にする

自治体のガバメントクラウドの利用環境は、複数の事業者によって構成されるマルチベンダーの環境になることがほとんどです。
そのため、自社の作業範囲としてどこまでを担うか自治体の方と協議して決定する必要があります。それぞれの事業者の詳細な役割分担については、AWS Blog 自治体のお客様向け「ガバメントクラウド利用タスクリスト」を公開します をご参照ください。
例えば、以下の作業項目は自治体の方針に合わせて構成が変わってくるポイントのため、まずはじめに確認しておくことをお勧めします。

a. ASP 、運用管理補助者それぞれの役割の有無

まず、自社が AWS アカウントの管理を実施する「ガバメントクラウド運用管理補助者」としての業務、アプリケーションの構築・提供を行う「ASP」としての業務のどちらを担うか確認します。傾向としては、1 つの事業者が運用管理補助者と ASP を両方担うケースが多いようです。
運用管理補助者の業務も実施する場合、業務を提供する自治体が ガバメントクラウドの道案内:『統合運用管理補助者編』に記載されている統合運用管理補助者を採用していないか確認し、統合運用管理補助者が実施する業務を確認し、それを基に運用管理補助者として実施しなければいけない業務を設計していきます。

b. 庁舎との接続

自治体から基幹業務システムを利用するためには、自治体庁舎と AWS 間を専用線で接続する必要があります。
以下の構成例は一例ですが、庁舎 – AWS 間を接続するために、Direct Connect ・AWS Transit Gateway を管理する事業者が必要です。

本ブログでは、庁舎との接続などネットワーク関連の作業を担当する事業者を「ネットワーク構築運用補助者」と呼びます。ネットワーク構築運用補助者の詳細については ガバメントクラウドの道案内:『ネットワーク構築運用補助者編』 をご確認ください。
自治体へネットワーク構築運用補助者に該当する事業者を採用しているか確認し、採用している場合はネットワーク構築運用補助者へ連絡を取り、自社で実施しなければならないネットワーク関連のタスクについて確認しましょう。

c. DNS サーバー

自治体の個人番号利用事務系ネットワーク内では、システムの名前解決にインターネットを利用することができないため、クライアントに提供されるシステムの名前解決を行う手段を提供する必要があります。
Amazon Route 53 Resolver インバウンドエンドポイントを利用することで、閉域網から AWS 上に構築されたシステムの名前解決を行うことが可能です。
インバウンドエンドポイントは、各 ASP・運用管理補助者が個別に管理する場合と、ネットワーク構築運用補助者や統合運用管理補助者が統合的に管理する場合が考えられるため、自治体の方針を確認し、自社のシステムの名前解決をどのように提供することになるか事前に把握しておく必要があります。
詳しくは ガバメントクラウドの道案内:『ネットワーク構築運用補助者編』 の「 DNS の設計について」をご確認ください。

d. 暗号化通信

自治体の基幹システムの実装では「地方公共団体情報システム非機能要件の標準」において、すべての伝送データの暗号化をするように記載されています。そのため、内部ネットワークからアクセスされる個人番号利用事務系のシステムでも TLS による HTTP 通信の暗号化の実装が必要です。TLS で HTTP 通信を暗号化するために TLS サーバー証明書が必要です。サーバー証明書を利用する際には AWS Certificate Manager (ACM) を利用できます。ACM の利用パターンについてご説明します。

d-1. パブリック証明書の利用

AWS ACM ではドメインの所有権を検証した後にパブリック証明書を利用することができます。ドメインを取得する必要がある一方、後述のプライベート証明書を利用する方法と比較して、「プライベート証明書を信頼するための設定」や「プライベート認証局の管理」といった業務がない点が優れています。自治体基幹システムにおけるユースケースとしては、共同利用方式で業務システムを提供する事業者がドメインを取得し、複数の自治体へシステムを提供する例などが挙げられます。

d-2. プライベート証明書の利用

AWS ACM ではプライベート証明書をインポートし利用することができます。自治体基幹システムにおけるユースケースとしては、自治体でプライベートのドメインを運用する場合・庁内にすでにプライベート認証局がある場合・ネットワーク構築運用補助者や統合運用管理補助者が統合的にプライベート認証局を管理している場合などにこの構成が採用されます。AWS でプライベート認証局を構築する場合、 AWS Private CA をご利用いただくことができます。AWS Private CA は、プライベート証明書を安全に発行し、一箇所で管理できます。さらに、ACM と連携して証明書のリクエストと自動更新をすることができます。利用料は、2024 年 12 月時点の汎用モードで AWS Private CA あたり月額 400 USD と発行するプライベート証明書の発行数で決まります。複数の AWS アカウントで AWS Private CA を利用したい場合、 AWS Private CA を複数の AWS アカウントで共有するような工夫をすることでコストを最適化することができます。

e. 認証認可サーバー (データ連携の方針)

「地方公共団体情報システム共通機能標準仕様書」にデータ連携機能の標準仕様が定められ、各標準準拠システムは一部の例外を除き、ガバメントクラウドの CSP が提供するオブジェクトストレージと REST API を利用したデータ連携が求められることとなりました。
ガバメントクラウド上のシステムとオンプレミスのシステムとの連携や、複数の CSP にシステムが分散している場合などでは、システム間の認証認可をどのように行うかが課題となります。標準仕様では自治体ごとに一台の認証認可サーバーを運用していくことが求められており、この認証認可サーバーの運用を行っているベンダーと連携をとる必要があります。

f. Active Directory との連携

業務システムのうち、ファイルサーバーなど Active Directory との連携が必要な場合があります。その場合、自治体で管理している Active Directory と連携が必要です。どのベンダーが Active Directory を管理しているのか、どの方式で Active Directory が構築されているのか (オンプレミス、Amazon EC2 上の Active Directory、AWS Managed Microsoft Active Directory) を確認し、Active Directory と連携ができることを確認します。

(3) 団体間の分離方式を決定する

共同利用方式で業務システムの提供を行う場合、主に 3 種類の団体間のシステム分離方法が考えられます。

  1. 団体ごとに専用のアカウントを用意し、団体に関係するリソースをアカウントレベルで分離 (アカウント分離)
  2. 複数の団体でアカウントを共有、団体専用の VPC (閉域論理ネットワーク: Amazon VPC) を用意し、主要なリソースを VPC レベルで分離 (ネットワーク分離)
  3. 複数の団体でアカウント、VPC、主要なリソースを共有し、アプリケーションレベルで分離 (アプリケーション分離)

このうち、アプリケーション分離を採用できるかどうかはシステムやアプリケーションの実装に大きく依存することになるため、アカウント分離やネットワーク分離が採用されることが多くなることが想定されます。
ネットワーク分離では一部のサービスを団体間で共有することが可能でアカウント分離と比べると一定のコスト抑制効果を期待でき、アカウント分離では団体ごとの範囲を明確化することができる点、アカウントごとのクォータを気にする必要がない点がメリットと言えます。
それぞれの方式の特徴を把握し、提供する業務システムに合わせて選択します。

(4) 運用保守経路を確保する

ガバメントクラウド上で構築した業務システムへの運用保守経路を構築します。自治体の基幹業務ではインターネット経由でシステムの運用保守を行うことができないため、以下のいずれかの方法を利用して業務システムの運用保守をする必要があります。

  1. 自治体庁舎へ赴き、自治体が保有している回線を利用して保守
  2. ベンダの拠点と自治体庁舎が専用線で接続されている場合、自治体庁舎を経由して自治体が保有している回線を利用して保守
  3. ベンダーが独自に専用線を利用してクラウドへの運用保守経路を構築

共同利用方式を選択している場合、3 の方法を選択する場合でも、自治体の数と同じ専用線を契約する必要はなく、1 つの専用線で複数の自治体の業務システムを運用保守できます。

3 の方法では、1 ベンダーが複数の自治体システムの運用保守を行うことが想定されます。その場合、複数の自治体のネットワークと運用保守 VPC の CIDR 重複が発生し得ます。 AWS PrivateLink を利用すれば、ネットワークアドレスが重複していても各業務システムと通信が行えるため、上記の図は AWS PrivateLink の利用を踏まえた構成図となっております。

(5) モダナイズを検討する

ガバメントクラウドに構築するシステムは、ガバメントクラウドへの移行のタイミングをはじめ、継続的にシステムのモダナイズを検討することが求められます。これは一般的なシステムについても同様で、システムの構築後、適切なモニタリングを実施することで改善点を見つけ、より堅牢で効率の良いクラウドネイティブなシステムへと改善を繰り返すサイクルを構築することが重要です。
このサイクルを構築するために、主に 3 つの観点でモダナイズを検討していくことをお勧めいたします。

運用・監視業務のモダナイズ
Amazon CloudWatch などのマネージドサービスを利用してシステム全体やアプリケーションの稼働状況を観測可能にします。
AWS における運用・監視について包括的に学ぶには One Observability Workshop の実施がおすすめです。

インフラストラクチャ構築・システム構築のモダナイズ
AWS CloudFormation や AWS CDK を利用しインフラストラクチャの構築を自動化し、AWS Code シリーズによる CI/CD を実施しシステムのデプロイを自動化することで、高頻度のリリースをミスなく実行する環境を構築します。
AWS CDK について初歩から学ぶには、 TypeScript の基礎から始める AWS CDK 開発入門 がおすすめです。

アプリケーションのモダナイズ
Amazon ECS や Amazon EKS を利用したアプリケーションのコンテナ化の検討や、AWS Lambda を利用した機能のマイクロサービス化、AWS Step Functions を利用したバッチ処理のマネージド化を検討します。
特に、アプリケーションをコンテナ化する上では以下の資料・ワークショップが参考になります。

また、AWS ではこういったシステムのモダナイズを検討する上で指針となる情報を様々な形で発信しています。ぜひご活用ください。

(6) 利用できるベストプラクティスやサンプルがないか確認する

AWS では様々なシステムのサンプルアプリケーションおよびサンプルテンプレートを公開しており、標準準拠システムをガバメントクラウドに構築する際に重要となる閉域網におけるサンプルも提供しています。

また、ガバメントクラウド向けのテンプレートがデジタル庁からも提供されており、Government Cloud Assistant Service (GCAS) などを通じて入手することが可能です。

  • ガバメントクラウド利用における推奨構成 (AWS 編)
  • 地方公共団体情報システム認証機能に関するリファレンスガイド(AWS 編)

このほか、AWS では継続してガバメントクラウドや標準準拠システムに資するサンプルテンプレートを公開していく予定です。

まとめ

本ブログでは、ASP・運用管理補助者となる事業者の方向けにガバメントクラウド上で業務システムを構築するうえで検討すべきポイントをご紹介しました。ガバメントクラウドを利用する際の不明点が少しでも取り除けていたら幸いです。
自治体に所属している方、または関連するベンダーパートナーの方でこのブログに関して追記した方がいいことやご不明点などございましたらお気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へお気軽にご連絡ください。

免責事項

  • 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。
  • 本ブログや添付資料はあくまで一例であり、全ての作業内容を充足するものではありません。
  • 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。
  • 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。

ガバメントクラウドに関するお問い合わせ

AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。
本記事で紹介したタスクリストに関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。
https://thinkwithwp.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

著者について

今坂 優 (Yu Imasaka)は、パブリックセクターの自治体担当ソリューションアーキテクトです。最近は自治体業務システムの標準仕様対応やガバメントクラウドへの移行支援を中心に活動しています。

松本 侑也 (Yuya Matsumoto)は、パブリックセクターの自治体担当のソリューションアーキテクトです。最近ではガバメントクラウドへの基幹システムの移行や、生成系AIの活用支援を中心に活動しています。