見出し画像

架空の「ガバメントクラウド認定試験」 #1~#4

はじめに

本記事に掲載されている「ガバメントクラウド認定試験」は、公式なものではありません。これは筆者が個人的に作成した架空の試験問題であり、ジョークとしてお楽しみいただくことを目的としています。

ガバメントクラウドや自治体システムの標準化に興味がある方々向けに作成していますが、難易度はすでにガバメントクラウドの検討に着手されている方を対象としており、一部の用語の説明は省略している場合があります。

なお、本内容は投稿日時点の情報に基づいている点にご注意ください。標準仕様書やガバメントクラウド関連文書群は随時更新されていますので、最新の正確な情報については、必ず公式の資料をご確認ください。


問題

それでは、「ガバメントクラウド認定試験」の問題に挑戦してみましょう。

第1問

ガバメントクラウドにおいて、クラウドとオンプレミスを組み合わせてデータを処理・保存する利用形態(ハイブリッド構成)については、システムの複雑化と高コスト化の要因となるため、その適用を避けることとされています。次のケースのうち、例外的にハイブリッド構成が認められる可能性が最も高いものはどれですか?

A) 災害対策のためにオンプレで縮退運用をおこなう
B) 機密情報保護のために一部データをオンプレで管理する
C) データの多重バックアップ先としてオンプレを指定する
D) 複数のCSPを併用してマルチクラウド構成とする

https://x.com/honeycomb_bnbn/status/1804376369268429107

第2問

地方公共団体のガバメントクラウド利用における、単独利用方式と共同利用方式それぞれのAWSアカウント管理に関する記述のうち、誤っているものはどれか。

A) 単独利用方式の場合、AWSアカウントのルートユーザーはデジタル庁にて作成後、地方公共団体に提供し、以後、地方公共団体が保有して管理する。
B) 共同利用方式の場合、AWSアカウントのルートユーザーはデジタル庁にて作成後、地方公共団体に提供し、以後、地方公共団体が保有して管理する。
C) 単独利用方式の場合、各利用組織及びその開発運用委託業者がAWSアカウントへのアクセスに用いるGCASアカウントはガバメントクラウド管理組織にて発行する。
D) 共同利用方式の場合、各利用組織及びその開発運用委託業者がAWSアカウントへのアクセスに用いるGCASアカウントはガバメントクラウド管理組織にて発行する。

https://x.com/honeycomb_bnbn/status/1804382934474068403

第3問

ガバメントクラウド(AWS)において、インターネット経由でのパッチ適用やウィルス対策ソフトのパターンファイル更新を行う際に、セキュリティ対策としてURLフィルタリング等のために用いられる技術はどれですか?

A) AWS WAF
B) AWS Network Firewall
C) AWS Shield
D) AWS Inspector

https://x.com/honeycomb_bnbn/status/1804409071141032040

第4問

共通機能標準仕様書に基づく庁内データ連携機能のファイル連携についてはオブジェクトストレージ(AWSではS3)の活用が推奨されています。
オブジェクトストレージを利用する場合、バケットの作成単位についての正しい説明はどれでしょう?

A) 共通機能を提供する事業者は、オブジェクトストレージ上に業務IDごとにバケットを作成する
B) 共通機能を提供する事業者は、オブジェクトストレージ上に自治体ごとにバケットを作成する
C) 共通機能を提供する事業者は、オブジェクトストレージ上に業務IDのペアごとにバケットを作成する
D) 共通機能を提供する事業者は、オブジェクトストレージ上にASP事業者単位にバケットを作成する

https://x.com/honeycomb_bnbn/status/1804461193786241205

閑話休題

さて、ここで問題の回答に進む前に、ガバクラ認定試験を作成するに至った元ネタとして、高橋さんのポストをご紹介します。

ぜひこちらもトライしてみてください。

Xの標準化界隈は非常に勉強になる情報や議論が活発におこなわれているほか、ユニークな方が多いのでおすすめです。

回答・解説

それでは回答編です。
なお、回答や解説は筆者本人の見解に基づいて記載されており、国の公式の回答ではありません。事業者・担当者によっても解釈が分かれる可能性がありますので、内容の取扱いには注意してください。

第1問

正解は、Cの「データの多重バックアップ先としてオンプレを指定する」です。

ハイブリッド構成については以下のようにガバメントクラウド概要解説のなかで説明されています。

クラウドとオンプレミスを組み合わせてデータを処理・保存する利用形態(ハイブリッド構成)については、オンプレミスからクラウドへの移行期、データの多重バックアップ、ネットワーク遅延が許容できない場合を除き、システムの複雑化と高コスト化の要因となるため、その適用を避けることとする。各構成の詳細を①~③に示す。

① オンプレミスからクラウドへの移行期
未移行部分がオンプレミス、移行済み部分はクラウドとなる、段階的にガバメントクラウドへ移行するような構成を指す。

② データの多重バックアップ
ガバメントクラウド上のデータをオンプレミスへバックアップするような構成を指す。

③ ネットワーク遅延が許容できない場合
ネットワーク遅延が許容されない部分はオンプレミス、それ以外の部分はガバメントクラウドを利用するような構成を指す。

さらに、主たる環境として利用するIaaS/PaaSのCSPを複数とするマルチクラウドはコストが増大することが多いため、真に必要性がある場合を除いては避けることとする。

ガバメントクラウド概要解説 / 6 必須検討事項 / 6.5 ハイブリッド構成について

上記の説明のうえで、具体的なユースケースごとに「図 6‑8 ガバメントクラウドにおけるハイブリッド構成の許容方針」がまとめられていますので、確認してみてください。

引用:ガバメントクラウドにおけるハイブリッド構成の許容方針

ちなみに、「6.5 ハイブリッド構成」は2024年2月の第5.3版にて追加されたものです。ガバメントクラウド概要解説を最近参照されてなかった方は再度目を通してみてください。
月に1回程度更新されてますので、定期的に確認が必要です。

個々の選択肢への解説をしてみます。

A) 不正解。災害対策は原則禁止の扱いです。ただし、「ガバメントクラウドでは、ディザスタリカバリ環境をクラウド上に構築することを想定している」としつつも、「パブリッククラウドが全面的に利用不能となるような大規模な災害を想定する場合はその限りではない」とされていることから、絶対にNGというわけではありません。

B) 不正解。機密情報保護は、原則禁止の扱いです。ただし、「ガバメントクラウド上への機密情報の保管は、所属する国の行政機関や地方公共団体のセキュリティポリシーに準じて検討すること」とされていることから、絶対にNGというわけではありません。

C) 正解。データの多重バックアップ目的でのオンプレミス環境の利用は、ガバメントクラウドにおいて許容されるケースのひとつです。ただし、「年1回等、複数あるデータバックアップの1つとしての補助的な利用にとどめる」こととされています。

D) 不正解。マルチクラウド構成は、原則禁止の扱いです。ただし「複数のクラウド間でデータ連携を行うようなマルチクラウドは例外的に許容する」とされていることから、絶対にNGというわけではありません。

【参考文書1】
ガバメントクラウド概要解説
6 必須検討事項
6.5 ハイブリッド構成についてhttps://guide.gcas.cloud.go.jp/general/overview-explanation/

【注釈】
GCASガイド自体は非公開とされていますが、「ガバメントクラウド概要解説」については公開サイト内から直接リンクが飛んでいることから、本記事でも引用させていただきました。

該当部分(スクリーンショットは2024年6月22日時点です)

第2問

正解は、Bの「共同利用方式の場合、AWSアカウントのルートユーザーはデジタル庁にて作成後、地方公共団体に提供し、以後、地方公共団体が保有して管理する。」が誤った選択肢です。ほかは正しい選択肢です。

AWSアカウントにおいてルートユーザーは、最も強い権限を持ち、システムの所有者として位置付けられますが、単独利用方式と共同利用方式によって扱いが異なります。ルートユーザと管理者権限を持つAdminユーザーとはまた別ですので注意しましょう。
なお、R6年度以降は、GCASアカウントが主となるため、こちらも注意が必要です。GCASアカウントとAWS間の連携ではAWS IAM Identity Center(IdC)が用いられます。

ユーザ管理については地方公共団体がガバメントクラウドを利用する際のセキュリティ方式設計・セキュリティ運用の観点から非常に重要なため、これらの考え方は理解を深めておく必要があります。

【参考文書1】
ガバメントクラウド利用概要(AWS編)
 2 ユーザー
  2.1 ユーザーの全体像
※GCASガイド参照

【参考文書2】
ガバメントクラウドGCAS移行に備えAWS IAM Identity Centerを理解する

GCASガイドは非公開の扱いとなりますので、直接的な引用は避けています。別途参照してみてください。
サーバーワークスさんはガバメントクラウドに関するブログ記事を多数掲載されています。ぜひ参考にのぞいてみてください。

第3問

正解は、「B) AWS Network Firewall」です。

ガバメントクラウド推奨構成(AWS編)において、インターネット接続における推奨構成が記載されています(P74~76あたり)。

ガバメントクラウド推奨構成(AWS編) 4-2 ガバメントクラウドにおけるインターネット接続

ガバメントクラウドでインターネット接続(マイナンバー利用事務系へのパッチ適用・ウィルス対策ソフトのパターンファイル更新、及びクラウドのManagement Consoleへの接続)を行う際に本構成を参考にすることが求められます。

解説文には「AWS Network FirewallやProxyサーバによるURLフィルタリングを行うことでインターネットとの通信が必要最低限になるよう制御する。」とあり、なんでもかんでもインターネットにつないでよいわけではなく、URLフィルタリングの導入を求めています。
AWS Network Firewallではなく、Proxyサーバ(Squid等)を採用することも可能と解釈できます。

なお、2024年5月22日公開の最新版では、少し構成が旧版からかわっていますので注意してください。

ちなみに、マイナンバー利用事務系におけるインターネット接続利用については「地方公共団体における情報セキュリティポリシーに関するガイドライン」にさらに詳細に規定されていますのであわせて確認することをおすすめします。

【参考文書1】
ガバメントクラウド推奨構成(AWS編) 令和6年5月22日作成
4.2 ガバメントクラウドにおけるインターネット接続
https://www.digital.go.jp/news/ZYzU5DYY/

【参考文書2】
「地方公共団体における情報セキュリティポリシーに関するガイドライン」(令和5年3月28日改定)
https://www.soumu.go.jp/main_sosiki/kenkyu/chiho_security_r03/index.html

第4問

正しい選択肢はCです。

ファイル連携に関する詳細技術仕様書(第2.2版)において以下の記載があります。

① 共通機能を提供する事業者はオブジェクトストレージ上に業務の組み合わせごとのバケットを作成すること。
なお、標準準拠システムのファイル連携で必要となるバケット数については、CSPが提供するサービスの作成上限を踏まえ必要に応じて上限の拡張申請を行うこと。
例)住民基本台帳と印鑑登録の業務の組み合わせに対し、バケットを1つ作成する。

ファイル連携に関する詳細技術仕様書(第2.2版) / 2. バケットについて / 2.1 バケット作成単位

よって、Cの「業務IDのペアごとにバケットを作成する」が正しい答えです。組み合わせをペアと置き換えています。上記の例にもあるように、「住民基本台帳ー印鑑登録」でバケットがひとつ必要です。仮に同じデータを複数業務に配るようなケースでもバケットを分けて格納する必要があります。

バケット数は業務IDの組み合わせから算出できますが、実際には機能別連携仕様上、連携が必要とされているかどうかが次第です。バケット数は最大で3桁になります。
ただし、各ASP事業者によってオブジェクトストレージの利用想定は異なるため(パッケージ特例を適用し、オブジェクトストレージを利用せず直接DB参照などをおこなう可能性があるほか、ファイルサーバ利用も認められる)、すべての団体で必ず同じバケット数になるということはありません。また、独自施策システムや外部システムついてもオブジェクトストレージを利用するかどうかは確認が必要です。
上記をふまえてすべての事業者に方針を確認し、連携一覧を作成し、それぞれ合意するプロセスが必要です。

補足ですが、パッケージ特例については以下の通りです。

また、本仕様書が対象とする共通機能を、一又は複数の標準準拠システムと一 体のパッケージとして提供する場合については、機能配置等の実装方式は本仕 様書に適合する必要はなく、パッケージベンダの責任において提供することとしてもよい。

ただし、一体のパッケージとして提供されていない他ベンダの標準準拠シス テムと連携する場合等の共通機能については、本仕様書に適合する必要がある。

地方公共団体情報システム 共通機能標準仕様書 【第2.3版】/ 1. 共通機能標準仕様書について / 1.4. 標準準拠システムと本仕様書が対象とする共通機能の関係性

これを誰がやるのかは明確に指示はありませんが、オブジェクトストレージ構築主体あるいは地方公共団体の職員がおこなうことになるとおもいます。
マルチベンダの場合は足並みがなかなかそろわず、相当の準備期間が必要になります。場合によっては複数回に分けてバケット作成をスケジュールする必要があるかもしれません。

これらの調整結果をもとに連携一覧は稼働後も継続して整備・改版していくことになります。

ほかにも考えるべきこともたくさんありますので、タスクリストを作って整理しましょう。構成によって異なりますが、参考までに一例を記載してみます。

  1. 連携一覧の整備

    • 連携一覧の作成と維持管理

      • 管理項目の確認(構築開始日、バケット名、ロールID、鍵一覧等)

      • 他社調整(事前説明・配付、内容合意)

      • 改版ルールの決定

  2. 方式設計における調整事項

    • 認証認可方式の決定(特にマルチCSP環境での対応)

    • オブジェクトストレージとの通信方式選択(API、SFTP、CLIなど)

    • ネットワーク構成:通信経路の確保(特にマルチCSP環境での対応では重要)

  3. 環境構築における調整事項

    • IaCの開発

    • 検証環境(疑似本番環境)向けのバケット活用方針 ※権限含む

      • 専用バケットの作成

      • 同一バケット内でのフォルダ分け

      • 本番環境との共用

  4. その他

    • 独自施策システム向け業務IDの採番方法の決定

まずは詳細技術仕様書にさまざまな仕様が定義されていますのでそれを網羅しつつ、不足されている部分は各ASP事業者との調整になるでしょう。
統合運用管理補助者がいればよいですが、不在の場合は地方公共団体の職員さんの負荷が高くなりそうです。

【参考文書1】
ファイル連携に関する詳細技術仕様書(第2.2版)
https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/4d056a04-6eba-4109-9850-a786d3e71971/2cab888a/20240214_policies_local_governments_common-feature-specification_outline_20.docx

【参考文書2】
地方公共団体情報システム共通機能標準仕様書(第2.3版)
https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/4d056a04-6eba-4109-9850-a786d3e71971/7a1137c2/20240430_policies_local_governments_common-feature-specification_outline_02.pdf

【参考文書3】
「地方公共団体情報システム共通機能標準仕様書」に関するリファレンス
https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/4d056a04-6eba-4109-9850-a786d3e71971/c04234f7/20240214_policies_local_governments_common-feature-specification_outline_01.pdf

いずれも回答日時点の最新です。
リンク切れの場合は以下から確認をお願いします。


傾向

第1問

正解はCでしたが、Aが多数派でした。正答率が25.3%と低く、意見が割れていたのが印象的です。解説でもふれたとおり、他の選択肢も認められる可能性があります。

第2問

正解はBで、Bが多数派でした。一番正答率が高く、55.6%の方が正解されていました。

第3問

正解はBで、Bが多数派でした。半分近くの方が正解されていました。

第4問

正解はCで、Cが多数派ではありましたが、Aを選んだ方も多いですね。AとCはまぎらわしいので引っかかってしまった方がいたかもしれません。Aは誤りですのでご注意を。

おわりに

以上、4問を作成してみました。お疲れ様でした。全問正解した猛者はお友達になりましょう。

今回の記事はあくまでも架空の試験問題ですが、今後の自治体システムの標準化・ガバメントクラウド移行に対する理解が深まり、実際の業務で何か役に立つことを願っています。

なお、冒頭・途中にも記載した通り、実際の業務で活用される場合は、必ず最新の公式資料をご確認いただきますようお願いいたします。標準仕様書やガバメントクラウド関連文書群は随時更新されています。また、回答や解説は筆者本人の見解に基づいて記載されており、国の公式の回答ではありません。事業者・担当者によっても解釈が分かれる可能性がありますので、内容の取扱いには注意してください。


この記事が気に入ったらサポートをしてみませんか?