ガバメントクラウドの利用について、デジタル庁では「ガバメントクラウド推奨構成」を公開しています。
このガバメントクラウド推奨構成の AWS 編には、ガバメントクラウドにシステム構築するにあたってのセキュリティの考え方が書かれているため、これらの記載のうち、自治体情シスが押さえておきたいセキュリティのポイントをピックアップして解説します。
本記事は ガバメントクラウド Advent Calendar 2025 の 12 日目の投稿となります。
システム構成の全体像
まずは前提となるガバメントクラウドを含めた自治体基幹業務システムの構成の全体像を見ていきます。
ガバメントクラウド推奨構成では、推奨するシステム構成を以下のとおりとしています。
- 地方公共団体が共同利用方式（ベンダーの AWS アカウントで各自治体の環境を構築して運用管理する方式）をとる
- 共同利用する団体間の分離方式は「アプリケーション分離」（団体ごとに VPC を分離せずアプリケーションとデータベースを論理的に分離する方式）とする
ガバメントクラウド推奨構成（AWS 編） P14 から引用
ベンダーの AWS アカウントの VPC にアプリケーションを構築し、自治体にサービスのエンドポイントを公開するような構成を推奨しています。
しかし、実際にはアプリケーション分離方式は多くないようです。AWS アカウントをベンダーが保有する共同利用方式とすることには変わりありませんが、アカウント分離方式（団体ごとに AWS アカウントを分ける方式）かネットワーク分離方式（AWS アカウントは分けず VPC で団体の環境を分ける方式）の構成が多いと思われます。
それではシステム構成を踏まえて、ガバメントクラウド推奨構成の中で自治体情シスが抑えておきたいセキュリティのポイントについて見ていきます。
伝送データ及び蓄積データの暗号化
各標準準拠システムに共通する非機能要件の標準 には、ガバメントクラウドにおける伝送データ及び蓄積データの暗号化について要件が規定されています。
伝送データの暗号化は自治体のクライアントからガバメントクラウド上のアプリケーションの間の暗号化を、蓄積データの暗号化はサーバーやデータベース、オブジェクトストレージに保存されるデータの暗号化を、それぞれ指していると考えられます。
通信経路の暗号化
ガバメントクラウド推奨構成では、クライアントとガバメントクラウド上のアプリケーションの間を End-To-End で暗号化することまでは必須要件としていないようです。具体的には以下のような記述となっています。
Elastic Load Balancer で通信の暗号化・復号に対応する。必要に応じて VPC 内の暗号化も検討する。
ガバメントクラウド推奨構成（AWS 編） P24 から引用
つまり、アプリケーションの前段に Elastic Load Balancer を配置し、Elastic Load Balancer で暗号化通信を終端、Elastic Load Balancer からターゲットのアプリケーションまでの間（VPC 内の通信）は平文で通信してもよいと解釈できます。
Application Load Balancer で HTTPS を終端し、Application Load Balancer からターゲットのアプリケーションまでの間は HTTP で通信するという構成が考えられます。
Application Load Balancer での HTTPS の終端であれば、マネージドサービスだけで通信の暗号化を実現できるため、運用は楽になるかと思います。
ちなみに当初の非機能要件の標準では、自治体のオンプレミスのエンドポイントまでの暗号化が要件になっていたので、VPC のアプリケーションサーバーから自治体オンプレミスのプリンターに帳票印刷データを送る場合は暗号化しなければならないとされていたのですが、2025 年 9 月 30 日の改定でこの要件は緩和されました。
ガバメントクラウド推奨構成（AWS 編） P79 から引用
ストレージの暗号化
次は蓄積データの暗号化について見ていきます。ガバメントクラウド推奨構成には以下の記述があります。
EC2・S3・RDS 等に蓄積されるデータは利用者が管理するカスタマーマネージドキーによって暗号化して保存し、鍵は AWS Key Management Service (AWS KMS) で管理する。
同じく ガバメントクラウド推奨構成（AWS 編） P24 から引用
EC2 や RDS で使うストレージである EBS や、S3 バケットは AWS KMS で管理するカスタマーマネージドキーで暗号化することが推奨されています。
EBS の暗号化は、デフォルトキーか AWS KMS で作成したカスタマーマネージドキーで行います。
S3 バケットはデフォルトで SSE-S3 という AWS がキーを管理する方式で暗号化できますが、AWS KMS のカスタマーマネージドキーで暗号化することもできます。(SSE-KMS)
AWS KMS カスタマーマネージドキーを使うメリットは、ストレージの暗号化に使う鍵に対するアクセスコントロールを行えること（キーポリシー）、任意でキーを有効化・無効化できることです。
大阪リージョンへのバックアップ
ガバメントクラウドでは東京リージョンと大阪リージョンのみ使用できます。東京リージョンにシステムを構築している場合、大阪リージョンに DR サイトを用意することは理想的です。
しかし、DR サイトを維持管理することはコストの面から非常に難しいと考える自治体は多いと思います。
ガバメントクラウド推奨構成では、システムの EC2 の AMI と EBS スナップショット、CloudFormation テンプレートを大阪リージョンにバックアップし、東京リージョンの障害時には復旧後にバックアップからシステムを復元する例が記載されています。
ガバメントクラウド推奨構成（AWS 編） P31 から引用
東京リージョン障害時のシステムの可用性は保てませんが、データの全ロストは防げるため、求める可用性の許容範囲とかけられるコストとの比較で、バックアップのみ大阪リージョンに取得するという判断はあるかと思います。
ファイル連携のアクセス権限
オブジェクトストレージのアクセス権限
標準準拠システム間のデータ連携はオブジェクトストレージを介したファイル連携となっており、共通機能の標準仕様 のファイル連携に関する詳細技術仕様書の中で、オブジェクトストレージのバケット単位でアクセス権限を管理することが規定されています。
ガバメントクラウド推奨構成では、AWS の S3 をオブジェクトストレージに使う場合のアクセス権限は、バケットポリシーで管理することが例として挙げられています。
ガバメントクラウド推奨構成（AWS 編） P41 から引用
S3 バケットのバケットポリシーに、アクセスを許可する IAM ロールを設定する方法が考えられます。
AWS 以外の環境から S3 バケットにアクセスする方法
AWS 環境同士の S3 バケットのアクセス権限は IAM ロールとバケットポリシーで行えますが、AWS 以外の環境から S3 バケットにアクセスさせる場合は簡単にはいきません。
AWS 以外の環境から S3 バケットへアクセスするためのクレデンシャルを取得する方法を構築することが理想ですが、これを実現するのはハードルが高いです。
そこで、Transfer Family の SFTP サーバーを S3 バケットと連携し、AWS 以外の環境には SFTP サーバーのエンドポイントを提供する方法が考えられます。
これにより AWS 以外の環境からでも、SFTP のプロトコルで認証認可と通信の暗号化が実現できます。
ガバメントクラウド推奨構成（AWS 編） P28 から引用
ガバメントクラウド接続回線の LGWAN 接続系・マイナンバー利用事務系の考え方について
自治体の三層分離のセキュリティ対策では、LGWAN 接続系とマイナンバー利用事務系を分離して運用することになっています。
ガバメントクラウド環境でもそれは同様ですが、LGWAN 接続系とマイナンバー利用事務系でそれぞれガバメントクラウドに接続回線を用意すると、通信回線のコストが二重にかかることになってしまいます。
ガバメントクラウド推奨構成では、ガバメントクラウド接続回線上で LGWAN 接続系とマイナンバー利用事務系の通信が混ざることを許容する記載となっています。
接続元（各団体拠点等）・接続先（ガバメントクラウド内 VPC）でのフィルタリングやルートテーブルでのルーティングにより、マイナンバー系通信と LGWAN 系通信のネットワークを分離し、三層分離を実現する。
ガバメントクラウド推奨構成（AWS 編） P77 から引用
ルーティングテーブルやファイアウォールのポリシーで適切に LGWAN 接続系とマイナンバー利用事務系の通信を分離していれば、ガバメントクラウド接続回線は両系で共用しても問題ないと考えられます。
まとめ
ガバメントクラウド推奨構成から、自治体情シスも知っておきたいセキュリティのポイントを挙げてみました。
基幹業務システムに求められるセキュリティの要件を AWS でどのように実現するかが読み取れると思います。
自団体の AWS 構成図を改めて見てみると、ここのロードバランサーは暗号化通信のためなんだな、などが分かって面白いと思います。