ガバメントクラウドにおけるリポジトリ運用の課題と対策
はじめに
2024年7月、AWS CodeCommitのサービスが終了するのでは、という情報が流れて、AWSユーザを中心に騒ぎとなりました。その状況を振り返りつつ、標準準拠システムの構成管理のあり方について考えをまとめています。
ただし、自治体標準化に関するステークホルダーは複雑で、事業者といっても立場が全く違います（パッケージ開発ベンダもあれば、運用のみを行うベンダもいますし、それぞれの担当とするスコープも異なります）。システム開発においてはアーキテクチャやミドルウェアの制約に依存してCI/CDなどの施策がやりづらい場合もありますし、各事業者の社内のセキュリティポリシー上、インターネット公開された外部SaaSの利用が禁止されているケース等もあります。新しいツールは学習コストもかかります。構成管理システムの選定にはこれらを考慮して決定していきますので、一概にこの方式が望ましい、と決められるものではないため注意が必要です。
なお、本記事では以下については取り扱いません。専門用語はそのまま説明なく用いますのでご承知おきください。
構成管理の基本的な知識（Gitとは、SVNとは、Git Hubとは等）
自治体標準化及びガバメントクラウドの基本的な知識
AWSの基本的な知識
また、AWSやガバメントクラウド等の要件についても随時見直される可能性があります。本記事の内容を業務で活用される場合は、最新の情報を再度確認をお願いします。
CodeCommitの新規停止について
AWSチーフエヴァンジェリストのJeff BarrさんがXにてCodeCommitを含むいくつかのサービスの終了について、投稿しています。
After giving it a lot of thought, we made the decision to discontinue new access to a small number of services, including AWS CodeCommit.
— Jeff Barr ☁️ (@jeffbarr) July 31, 2024
While we are no longer onboarding new customers to these services, there are no plans to change the features or experience you get today,…
慎重に検討した結果、AWS CodeCommitを含む少数のサービスへの新規アクセスを中止することを決定しました。これらのサービスへの新規顧客の受け入れは停止しますが、現在ご利用いただいている機能や体験を変更する予定はなく、セキュリティと信頼性を維持します。また、お客様の進化するニーズにより適したAWSや他社のソリューションへの移行もサポートします。引き続きフィードバックをお寄せください。私たちは常に耳を傾けています。
この件について、クラスメソッドさんのブログに経緯や状況がまとめられています。
・AWS社員によるre:Postの投稿 (既に削除済み) によれば2024年6月6日より新規アカウントでのCodeCommitの利用を制限している
・同re:Postによれば2024年7月25日以前にCodeCommitを利用していたユーザーであればAWSサポートへ新規にCodeCommitを利用したい旨をリクエスト可能
・2024年7月27日に筆者が動作確認した範囲において、これまでCodeCommitを使っていなかったAWSアカウントにおいてリポジトリの新規作成が不可、既存リポジトリがあるアカウントは一切制限無し
・2024年8月2日ごろにマネジメントコンソールにおいても「新規顧客の受け入れを停止したが既存顧客は従来通り利用できる」旨のメッセージが表示される様になった
なお、X上でp0nさんが以下投稿されているように、Organizations内のアカウントであれば過去にCodeCommitリポジトリがないメンバーアカウントでも制限なく新規リポジトリが作成できたようです。
ガバメントクラウドでは特に問題なく利用できる可能性があります。
私用Organizationで試した限り、CodeCommitのリポジトリがあるアカウントもないアカウントも、新規リポジトリを作れた。クラメソさんのシェアされてるエラーメッセージもOrg内にリポジトリがあれば良いように読める。新規メンバーアカウントは試してないけど、re:Postを信じるなら申請すれば使えそう。
— p0n (@pwnp0n) July 29, 2024
なお、AWSでは、既存ユーザ向けにCodeCommitから他のGitホストサービスへの移行手順が紹介されています。
自治体市場における現状のリポジトリ運用の整理
さて、一般的なシステム開発において、ソースコードの構成管理（SCM）はリポジトリを運用することが多いです。最近はGitが一番人気ですが、その他、SVN（Subversion）やかつてのTFS（Team Foundation Server）のTFVCをそのまま利用していることもあるでしょう。
あまり望ましくないですが、人力での構成管理としてファイルサーバを利用しているケースもあるとおもいます。
自治体標準化における「標準準拠システム」の構成管理については概ね以下の状況になっていると予想されます。
構成管理手法
ASP事業者がなんらかの構成管理システムを運用しており、標準準拠システムについても同一環境を継続利用する。
あるいは、ASP事業者は標準準拠システムの開発に合わせて構成管理環境を一新して、新規のリポジトリの運用を開始する。
構成管理対象：
パッケージ資産：業務アプリケーションのシステム本体およびオプションの資産のことを指します。
顧客固有資産：ここまではパッケージ資産をカスタマイズしたもの（標準化後はカスタマイズは抑止されるため、基本的には存在しない）や、特定顧客向けに外付けで開発した資産のことを指します。
構成管理主体：
パッケージ資産：
原則、ASP事業者が構成管理する。
顧客固有資産：
ケース1：ASP事業者が構成管理する。
ケース2：自治体が独自に構成管理する。
構成管理システムを検討する上で参照すべきドキュメント
次に、構成管理システムを検討する上で参照すべきドキュメントについて確認していきます。
情報セキュリティポリシーガイドライン上の定義
第一に確認したいのが総務省の発出している「地方公共団体における情報セキュリティポリシーに関するガイドライン」です。
ここではR5年3月版を参照します。ページ数「iv-20」から説明がされていますので一部抜粋します。
クラウドサービス上で構築するマイナンバー利用事務系の標準準拠システム等における脆弱性の対処を行うために、OS、ミドルウェア及びアプリケーション等の修正プログラム（中略）を実施する場合は、クラウドサービス上のマイナンバー利用事務系と異なる新たなネットワーク(DMZ)を構築し、そのネットワーク内に連携サーバ(略)を配置した上で限定された通信の設定(FQDN のホワイトリスト設定やファイアウォール(FW)によるクラウドサービス上に構築したクライアント及びサーバ等からインターネットへのアウトバウンド通信の制御・インターネットからクラウドサービス上に構築したクライアント及びサーバ等へのインバウンド通信の禁止)を行うとともに、不正なアクセスが無いか日常的な監視(例えば、通常時のネットワークトラフィックの状態を監視し、通常時と異なる場合は、異常と判断し詳細を確認する)を徹底する。ただし、（略）。
一定の制限のもと、インターネット経由で標準準拠システムの修正プログラム適用が認められます。これはとても大きいですね。各社の制限もありますが、GitHubなどの活用が可能です。
ただし、業務システムと直接通信することはできないため、間に更新サーバ・連携サーバの設置が必要です。また、URLフィルタリングなども求められるほか、中から外に取りに行くケースのみ認められると解釈できます。
ガバメントクラウド推奨構成上の定義
これについてはガバメントクラウド推奨構成でも、同様の記載が確認できます。
AWSであれば、本番アカウントとは別に運用管理アカウントを設けること、NAT GatewayやNetwork Firewallなどを組み合わせることなどが記載されていますので、参考にすべきでしょう。基本的にはこの構成に合わせて実装することが望ましいです。
ガバメントクラウドの利用について上の定義
続いて「ガバメントクラウドの利用について」です。現在、２.1版が最新です。
3.2 ガバメントクラウド個別領域の使途等
ガバメントクラウド個別領域利用権限を有する者は、以下の点について厳守する。当該ガバメントクラウド個別領域のクラウドサービスは、検証及び本番稼働、災害対策等の地方公共団体がガバメントクラウド上で業務を行うための利用に限って提供されるものであることから、ASP 又はガバメントクラウド運用管理補助者は標準準拠システム等の開発行為等専ら ASP 又はガバメントクラウド運用管理補助者の利益になる行為に利用してはならない。（以下省略）
また注釈として以下が説明されている。
例えば、標準準拠システム等を開発する行為は、当該開発により完成した標準準拠システム等を他の地方公共団体向けに再販することが ASP の利益となるため、提供される環境内で当該開発行為を実施してはならない。一方、実際のデータをセットアップした上でシステムエンジニアがテストを行う行為は、クライアントの地方公共団体ごとにデータをセットアップし調整を行う必要があり、ガバメントクラウド上で業務を行うため必須の行為であるため、提供される環境内で行うことができる。ただし、ガバメントクラウド等に関連する固有の環境や固有の機能の検証が必要な場合は、実際のデータの導入を前提とせずに提供される環境内で行うことができる。また、地方公共団体職員が操作研修を行う行為は、地方公共団体がガバメントクラウド上で業務を行うために必須の行為であるため、提供される環境内で行う
ことができる。
ガバメントクラウド上ではASP事業者の利益につながる行為は禁止され、標準準拠システムの開発を行ってはならないと定義されています。ビルドサーバはともかくとして、リポジトリサーバについては、開発環境とは別と考えて良いと思います。
ガバメントクラウド概要解説上の定義
続いて概要解説です。
概要解説上、第３章において「開発環境は提供しない」とありますが、CI/CD環境の提供は認める旨の記載があります。CIだけでも認めるのか、CDもセットじゃないといけないのか、等の定義はありません。手動ビルドを行う場合はビルドサーバはNGで、自動ビルドを行う場合はビルドサーバはOK、と考えられると思います。
ガバメントクラウドでは原則として開発環境は提供しないが、CI/CDを実施する利用システムについてのみ開発環境の提供を行う。その場合、インフラ部分のCI/CDについては、ガバメントクラウドで指定するツールやテンプレートを用いてCI/CD環境を構成すること。それ以外のCI/CD環境をインフラ部分に選択する場合は、その合理性がガバメントクラウド管理組織で認められる場合のみとする。アプリケーションのCI/CD環境については、インフラ部分と同じ構成でも、独自の構成でも構わないものとする。
なお、CI/CDについて地方自治体向けの定義はありませんが、政府向けにまとめた以下が参考になるでしょう。
ガバメントクラウド利用概要（AWS編）上の定義
続いて利用概要です。ガバメントクラウド利用概要（AWS編）を見ていきます。
開発環境について概要解説と同様の記載がありますがこちらは省略します。ここでは、CI/CDの実践において一部構成で必要になる「アクセスキー」についての記載を確認します。
ガバメントクラウドでは「予防的統制」として、いくつかの操作が制限されますが、特にアクセスキーの作成が制限される点に注目します。
IAMユーザーの永続的なアクセスキーの作成を禁止するため、特定のSaaS製品の利用や運用に影響が生じる場合がある。利用システムは、早期段階でアクセスキーを利用しない方式を検討する必要がある。参考に以下にアクセスキーの利用が想定されるユースケース例を記載する。
・IAMユーザーの認証情報を用いたAWS CLIの利用
・外部CMSサービスからAWSリソースへのアクセス
・統合運用管理ソフトウェア、ウィルス対策ソフト、ログ監視サービス等のSaaS製品からAWSリソースへのアクセス
・CloudWatchAgentを用いたCSP管理環境外サーバのメトリクスやログの取得
・Amazon SES SMTPインターフェースを用いたeメールの送信
・CSP管理環境外サーバとS3等のオブジェクトストレージとのファイルの送受信
例えばGitHub Actionsなどでアクセスキーを利用してAWS環境にアクセスし、自動デプロイを行うことが考えられますが、これは制限されそうです。ドキュメントにも「早期段階でアクセスキーを利用しない方式を検討する必要がある。」とあります。
構成管理システムはどうするべきか
それでは、標準準拠システムにおいて構成管理システムをどう使うのが良いかを考えます。
なお、現在の構成管理システムが社内のイントラネット上にあり、インターネット接続されていないケースではガバメントクラウドの接続は個別に結線しない限り難しいのでいったんここでは取り扱いません。
先述した構成管理上の定義を振り返ると
一定の制限のもと、インターネット経由で修正プログラムを適用が認められる（OS・ミドルウェア・アプリケーションのいずれもOK）。業務サーバから直接取得することはできない。
推奨構成に従うとベター。
単純な開発環境の構築はNG。CI/CD環境であればOK。方式は問わない
アクセスキーは使ってはならない
と整理されます。パターンに応じて見ていきましょう。
現在の構成管理をそのまま利用する場合（GitHub+GitHub Actions編）
仮に現在GitHubやGitHub Actionsを利用しており、それをそのまま使いたい場合にはどんな課題が考えられるでしょうか。
解釈はいくつかあると思いますが、概ね以下の整理になると思います。
本番アカウントからGitHub上のリポジトリの直接参照はできない（本番アカウントではインターネット接続が一律禁止されるため）。
運用管理アカウント側にGitリポジトリを設置（GitLabやGitHub Enterpriseをホストしてもよいし、単純なGitのBareリポジトリを運用してもよい）し、GitHub上のリポジトリとミラーリングさせることは可能。
GitHub Actionsワークフローでの認証について、アクセスキーが使用できないため、利用は不可能と考えられる。他の手法として、外部IdP連携も考えられるが、こちらもOrganizationsが自由に操作できない以上、実現は困難とおもわれる（ただし、この点についてはデジタル庁に相談すれば例外的に認められる可能性はある）。このため、CDは自前でやるか、CodePipelineなどAWSのサービスを利用する。
なので、もう少しシンプルにまとめ直すと以下の方式が良さそうです。
GitHubのリポジトリをそのまま使う
運用管理アカウント側にGitリポジトリを設置し、GitHub上のリポジトリとミラーリングさせる
GitHubとの通信はガバメントクラウド推奨構成に従う
CD部分は運用管理アカウント側に個別に作りこむ
この方法は制約が多いガバメントクラウド環境下では、比較的実現可能性が高い選択肢と言えるでしょう。ただし、CDの再作り込みは判断が分かれそうです。
リポジトリを変更する場合（ガバメントクラウド以外の環境編）
次に現行のリポジトリ運用を見直す場合です。インターネット経由での接続が可能な場合は、なるべくそれを選んだほうが良いでしょう。基本的には「現在の構成管理をそのまま利用する場合（GitHub+GitHub Actions編）」の最後のまとめを参考に検討とすると良いと思います。GitHubでなくても、セルフマネージドGitとして、GitLabやGitHub Enterpriseオンプレ版などを EC2上に構築・運用することも良い選択です。
変更先もオンプレの場合は先述の通り割愛します。従来通りの運用です。
リポジトリを変更する場合（ガバメントクラウド編）
ではガバメントクラウドに移行させる場合はどうでしょうか。CI/CDとセットでの導入が必須なのは忘れてはいけないポイントです。
そもそも今回のガバメントクラウドの移行にあわせて、このリポジトリをわざわざガバメントクラウドに移管させる必要はありません（認証や閉域接続など、利用における制限がいろいろあるので、不自由な環境での開発はなるべく避けたいと思われる）。一方で、効率化のために以下のようなケースで、ガバメントクラウド上に一部機能を移管させる可能性もあります。
CI/CDパイプラインをガバメントクラウド上で完結させたいケース
CI/CDパイプラインまではやらないが、効率的なシステム保守（パッチ適用の自動化など）のためにガバメントクラウド上にリポジトリを再現したいケース ※アーティファクト（成果物）のみをミラーリングする等も考えられる。
このあたりはASP事業者によってアプリケーションの開発・保守の取り組み状況、開発体制上の優先度などによって判断が変わってくるため、どちらがよいということではありません。
また、移行先についてですが、ガバメントクラウド上での現実的な選択肢としては、セルフマネージドGitとして、GitLabやGitHub Enterpriseオンプレ版などを EC2上に構築・運用することが考えられます。
CodeCommitについては避けたほうが良いと思います。今のところ、ガバメントクラウド（AWS）環境はデジタル庁の運営するOrganizationsの配下のメンバーアカウントが払い出されるようですので、今後も候補のひとつとしてCodeCommitリポジトリを利用することも可能と思われます。ただ、やはりサービスとしては終息に向かっており、他のサービスへの移行手順もAWS社はブログで公開していることから、移管先の候補からは外しておくほうが無難でしょう。
共闘プラットフォーム内での調査結果
現状の状況について、共闘プラットフォームに参加されている事業者に匿名でアンケートをとってみました。ご協力いただいた事業者の皆様ありがとうございました。
ただ、回答数（全体6票、うち事業者は5票）が少なく、それぞれに担当範囲も異なりますので、結果の解釈は注意が必要です。参考程度としてください。
CodeCommitの騒動が標準化プロジェクトに影響ありと答えた回答はなし。
影響あり 0%
影響なし・ほか 100%(5票)
標準化プロジェクトに合わせて、パッケージ資産の構成管理の仕組みを変更するか。
既存の構成管理の仕組みをそのまま利用する 50% (2票)
構成管理の仕組みを変更する（ガバクラ以外） 50% (2票)
構成管理の仕組みを変更する（ガバクラ） 0%
パッケージ資産の構成管理システムと設置場所
オンプレGit 0%
オンプレSCM（Git以外）25% (1票)
セルフマネージドGit（パブリッククラウド）25% (1票)
セルフマネージドSCM（Git以外）かつパブリッククラウド 0%
SaaS型Git 25% (1票)
CSP提供サービス 25% (1票)
顧客固有資産の構成管理主体
ASP事業者が担う 100% (3票)
自治体が独自に管理する 0%
標準化プロジェクトに合わせて、顧客固有資産の構成管理の仕組みを変更するか。
既存の構成管理の仕組みをそのまま利用する 0%
構成管理の仕組みを変更する（ガバクラ以外） 100% (3票)
構成管理の仕組みを変更する（ガバクラ） 0%
顧客固有資産の構成管理システムと設置場所
オンプレGit 0%
オンプレSCM（Git以外）33.3% (1票)
セルフマネージドGit（パブリッククラウド）0%
セルフマネージドSCM（Git以外）かつパブリッククラウド 0%
SaaS型Git 33.3% (1票)
CSP提供サービス 33.3% (1票)
冒頭書いたようにサンプルサイズが小さいため、傾向は推しはかれませんので注意してください。
まとめると、まずCodeCommitの新規停止はさほど影響を感じている人はいませんでした。既存の構成管理は、そのままか、移管するケースでも設置場所はガバクラ以外です。顧客固有資産についてもASP事業者が構成管理するようです。
SCMはGitとGit以外で2:1、オンプレとクラウドで2:1、という比率でした（しつこいようですが、回答数が少ないため参考程度の数値としてください）。
ガバメントクラウド認定要件の見直しについて
最後に余談ですが、CodeCommitの件で気になるのがガバメントクラウドの認定要件です。
この中でマネージドサービス技術要件詳細について2025年度末時点で全要件を満たす必要があります。
現状、 「別紙１_基本事項及びマネージドサービスの技術要件詳細」 に記載する要
件を満たすことが出来ないが、 2025年度末までに全要件を満たす計画を提出し、 デジタル庁がガバメントクラウド対象となるクラウドサービスに加わることが可能
と判断した場合には、 ガバメントクラウド整備事業に係る検証作業等に参加することができるものとする。 なお、 2025年度末までに全要件を満たすことができないとデジタル庁が判断した時点で、 直ちにガバメントクラウドに関する検証作業等の参加資格の対象から除外する。 これにより生じる国及び地方公共団体等のシステムのガバメントクラウド移行に関する諸経費について、当該機関に経済的負担が生じることのないよう対応すること。
そして「別紙１_基本事項及びマネージドサービスの技術要件詳細」に以下の記載があります。
テンプレートをコード管理し、リリースするための、クラウド上にホストされプライベートなGitベースのソース管理サーバを利用できる機能がマネージドサービスとして提供されていること。もしくは、オープンソースベースのサードパーティ製ソフトウェア等と組み合わせて利用できること。かつ、基本事項36から40の統制機能が利用できること。具体的には、サードパーティ製ソフトウェア等を含めてテンプレートを使って自動インストールと構成ができ、利用の制限やリージョンの限定、ログやアラートの収集が自動でできること。以下、4のコードリリース管理機能まで同じ
もしAWS CodeCommitが2025年度末までにサービス終了することになれば、「直ちにガバメントクラウドに関する検証作業等の参加資格の対象から除外する」とされていますので、AWSがガバメントクラウド認定ではなくなります。そのための他のCSPへの移行費用はAWSが負担しなければなりません。
今はまだリポジトリ作成もできるようなので、要件外にはならないと思いますが、AWS本体の判断が気になります。
今後この技術要件詳細が見直されるかどうかはわかりませんが、さくらインターネットさんはこの全要件を達成するために今頑張って開発を進めている最中ですから、AWSに合わせて特定の要件が除外されるようではたまったもんじゃないですよね。もちろん国がAWSを有利にさせるために仕様を作っているわけではないはずなので、そのような心配は無用でしょう。
まとめ
さて、今回の記事では、ガバメントクラウド環境の様々な制約を基に、構成管理手法について考えをまとめました。これからこのタイミングで構成管理システムを見直すことはないと思いますが、保守効率化などの観点から見直せそうなポイントがあれば参考にしてみてください。
最後に、ガバメントクラウドの仕様やルールは随時変更される可能性があるため、定期的に最新情報を確認しましょう。必要に応じてリポジトリ運用方法の見直しが必要になるケースがありえますが、構成管理システムの移管は大変なので、慎重に検討しましょう。