ガバメントクラウドの調達公示への考察 -前編 -
10/4 に以下の URL に「デジタル庁におけるガバメント・クラウド整備のためのクラウドサービスの提供－令和 3 年度地方公共団体による先行事業及びデジタル庁 WEB サイト構築業務－」が公示されました。
こちらについて、記事が非常に長いため、以下の記事を2分割したものの前編がこちらとなります。後編と併せて御覧ください。
まず、最初にこれだけの規模感・数のテナントを管理するであろうマルチクラウドは日本のどこでも運用されていない（と思われる）ため、考慮点を網羅することは難しいですが、ガバメントクラウドの運用に備えて先んじて検討して、先行事業の検証内容に生かしていくことが継続的に必要だと考えます。ここではガバメントクラウドに求められる機能といった公開されている情報から、私個人の見解を述べていきたいと思います。そのため、内部的に検討が進んでいること等があり、それらが公開されていないということであれば、そこまでは考慮しておりませんし、考慮できないため、その前提で考察を述べていこうと思っております。また、毎度のことながら、どこかを悪く言ったり、自分たちが有利になろうという意図ではありませんので、予めご了承ください。
マルチクラウド運用
ガバメントクラウドは、公募公告における目的の項の以下文言からマルチクラウドになることが想定されます。つまり、性質の異なるクラウドサービスを複数運用していくことが大前提にある取り組みであることが想像されます。この複数クラウドの運用については、先にも述べましたが、この規模での運用を先んじで実施している先駆者が見当たらないため、参考となる情報が少ない中で非常に難しい運用定義になると考えています。
本公告はクラウドサービスの適正かつ確実な提供を確保するため、公募参加者に対し、その確実なサービスの提供を証明する書類等の提出を求めるものであり、デジタル庁が当該提出された書類等の審査においてクラウドサービスの提供が可能と判断した者すべてと契約の締結を行うものである。
責任分界点
まず、クラウドサービスの利用という観点でも、クラウドサービス事業者との責任分界点は常に課題になりがちです。さらにそこに複数クラウドを考慮した運用を立て付けなければならない点において、難易度が上がっていきます。
今回は地方自治体のシステム標準化におけるプラットフォームとしてのガバメントクラウドの検討であることを前提に課題を整理していきたいと思います。1700以上の自治体が様々なクラウドタイプ（IaaS/PaaS/SaaS）を組み合わせて利用して、それらが複数クラウド上で運用されていくことは、管理者にとっては並大抵のことではないはずです。そういった点も踏まえて、以下の点について、整理していくこととします。
1. どんなシステム構成パターンがあり得るか
2. 誰が責任を追うのか
3. どこまで責任を追うのか
まず、いくつかのシステム構成パターンにおいて、今のままでは責任分界点が曖昧になる可能性があります。例えば、マルチパッケージベンダー構成による 17 業務システムの調達が行われた場合を想定します。1 つのクラウド上で実現されたとしても、権限分掌の観点などから、各アプリケーション事業者間で同じテナントを利用するのではなく、別々のテナントを利用することになると思われます。同じテナント上に複数のアプリケーション事業者を混在させることは設計・運用管理の観点でかなり複雑になるはず。そもそも、同一テナント内での権限分掌設計・設定を誰がやるかもどんなベストプラクティスになるかも、誰が主体となって、どんなリソースの提供の仕方をするか次第になるからです（後述でも別途この問題について触れようと思います）。そのため、アプリケーション事業者ごとに提供するテナント内は自由に構成させたほうが画一的な権限分掌が見込めるのではないかと思います。
どちらのケースにせよ、クラウド内でのテナント間をつなぐネットワーク（例えば、AWS でいう Transit Gateway）は、誰が責任を持つかの議論が必要となります。この部分を、複数のアプリケーション事業者のうちの 1 つが担当するにしても、他のアプリケーション事業者からの変更や障害対応等の要求に相応の SLA で応えて対処をしなければならなくなります。このままでは、迅速性や責任分界点の観点で望ましいやり方とは思えません。また、ガバメントクラウドと庁舎間のネットワークについても、この課題は波及していきます。このように担当するアプリケーション事業者が増えれば増えるほど、責任分界点が非常に難しくなっていきます。
直近で公表された以下の「クラウドサービス提供における情報セキュリティ対策ガイドライン（第 3 版）」にもクラウドサービス利用における責任についての記載がある（P.22 以降）。
責任共有モデルにおけるクラウドサービス事業者とクラウドサービス利用者の責任範囲・内容は一律に決まるものではなく、クラウドサービスの内容やクラウドサービス利用条件・環境ごとに、両者で責任範囲と内容について合意し、契約で明⽰することが重要である。また、双方の責任範囲において、クラウドサービス利用者がセキュリティ上のリスクを判断できるように、クラウドサービス事業者はクラウドサービス利用者に対して、クラウドサービスの内容やクラウドサービス利用条件・環境等について適切に情報提供をする必要がある。
また、IaaS/PaaS/SaaS のどれを利用しているかによっても責任範囲は変わり、それらの組み合わせになった場合は複雑化します。以下では、クラウド利用数とアプリケーション事業者数によるシステム構成ケースを整理し、どのように課題が顕在化しやすいか考えていきます。
1. シングルクラウド・シングルベンダー
このケースにおいては、シングルベンダーが庁舎とのネットワークも担当すれば問題は起きにくいと思われる。
2. シングルクラウド・マルチベンダー
先の例の通り、テナント間の接続とクラウドと庁舎の接続で、責任分界点が曖昧になる。
3. マルチクラウド・マルチベンダー
更に複雑化する。テナント間の接続の問題がクラウドごとに発生し、クラウドと庁舎の接続も複数になるため、責任分界点の定義が非常に難しい。
以上のように、責任分界点が複雑化する恐れが大いにあるため、どのようにこの課題をクリアするかを考える必要があります。テナント間及びクラウド間の接続を、デジタル庁が介在するということであれば統一的な運用が可能になるが、府省のシステムに加え 1700 以上の自治体のシステムを単一の運用チームでホストするのは難易度が高いと思われます（特に、ガバメントクラウドの対象クラウドごとに技術チームが必要となり、24 時間体制の構築が必要になるため）。では、これを自治体側が制御できるかというとかなり難しいと考えます。つまり、このような全体の責任を持ち、システムとして成立することを補助する業者が介在しないとこの問題は解決しないのではないかと考えています。特にシングルクラウド・シングルベンダーであれば、そのアプリ事業者が全てを担当することも考えられるが、アプリ事業者がそこまでやりたくない、もしくはそこまで自社システム以外に精通していないというケースもあるはずです。
統合運用業者の必要性
このように、クラウド間ネットワーク、クラウド内相互接続および全体としての正常性に責任を持つ業者を別途調達しないと、インフラだけ提供する国との役割分担で漏れるところが多くなります。それを補う役割を期待する位置づけのものを調達する必要があると思われます。デジタル庁は、ガバメントクラウドを提供したから、その上にあるものは全て自治体側でやってねということになると、アプリ業者からすると今までに比べて、インフラの中の見えるものが変わってくると思われるため、責任を取れる範囲が限定化されてしまい、契約上、自治体職員に全体の正常性の確認が押し付けられてしまう可能性があるのではないかと考えています。これらは本来の自治体職員が考える範囲を減らすという目的にも反するところになってしまうので、何らかのガイドが必要なのではないかと思います。
リソース妥当性・リソース引き渡し先の検討
今から述べる 2 点は、全体の運用にも関わる部分になります。ガバメントクラウドが誰に対して提供されるものなのかが重要です。こちらもいくつかの検討パターンが存在します。
1. 自治体＝クラウド管理者
自治体に 1 つの基盤（アカウント）として提供して、そこを各アプリ事業者が利用するケース
2.アプリ業者＝テナント管理者
アプリ事業者に、担当する自治体単位で必要になる基盤を引き渡し、アプリ事業者はその上にアプリケーションを構築し、自治体に引き渡すケース
3.アプリ業者＝業者用クラウドリソース管理者(IaaS)
アプリ事業者に担当する自治体数分のトータルリソースを提供して、アプリ事業者が自治体ごとのシステム区切りを作って運用するケース
4.アプリ業者＝業者用クラウドリソース管理者(SaaS)
アプリ事業者がアプリケーション層で SaaS 化してマルチテナント化している場合は、アプリ事業者にガバメントクラウドのリソースを必要に応じて渡さなければならないケース
このようにいくつかのケースが存在します。3,4 に関しては、アプリケーションの作りについて、アプリ事業者に口をだすことは難しいため、両パターンに備えなければならないと思われます。また、2 番目については、自治体単位でどれだけ使っているかを測るには、複数のアプリ事業者の利用料を足し合わせないと見えなくなってしまうことになります（利用するクラウドが複数だった場合にはどうなるであろうか）。
また、ガバメントクラウドの利用促進の目的であるコスト削減を実現するためには、ガバメントクラウド全体の最適化は常に行われるべきです。しかしながら、上記のいずれのケースにおいても、引き渡すべき必要なリソースの妥当性を判断することは非常に難しいです。アプリ事業者から求められる想定リソースが妥当なのかを事前に判断することは更に難しい。また、アプリ事業者からすればインフラ部分についてはコスト負担しないため、安全に舵を切ったサイジングになりがちで大きめに見積もることになると思われます。ただ、先述の通り、これが過大なのかを事前に判断する術がありません。自治体規模によってテンプレート的なものは存在するが、利用頻度などによって異なってくるためです。
使わなければ料金がかからないようにする、もしくは使わない・使っていないリソースは縮小するなどといった手段が考えられるが、後述の予算計上の箇所が重要となってくる。また、使わない・使っていないリソースは縮小するといった方策については、どのタイミングの情報をもって、どれくらい削減できるか、それを誰がどのような判断基準で判断するか、そしてそのレビューの機会をどれくらいの頻度で持つかを定義しなければならない。さらに言えば、これを 1700 以上の自治体のシステムそれぞれに対して、最適化を年に 1 回実施したとしても、365 日のうち 1 日に 5 件程度回さなければならない計算となり、実質自動化しなければ難しい。マルチベンダー・マルチクラウド構成になった場合には、計算ロジックがさらに複雑になることが想定される。
セキュリティの状況変化に応じた動的追従
リソースと同様に 1700 以上の自治体のセキュリティ状況を常に見ておくことは難しいと考えると、デジタル庁が管轄するのではなく、各地方自治体に管理分掌をしなければならなくなります。ガバメントクラウドとしてのインフラ基盤としてのセキュリティはISMAPによる認証があるにしても、そのインフラをどのように利用しているかに対してセキュリティホールは生まれるため、インフラを提供したからセキュリティは各自でという運用ではガバメントクラウドの目的であるセキュリティ向上は見込みにくい。OS・アプリケーション領域及びクラウドの設定にまつわるセキュリティにも引き続き考慮が必要です。そして、クラウド上の構成や設定は常に変わっていきます。半年や定期的なレビューといったやり方では、現代の脅威に遅れを取ってしまう可能性が高い。そのため、ガバメントクラウド利用によってセキュリティ向上を目的とするのであれば、各地方自治体にセキュリティの内容について一任するのではなく、全体のセキュリティホールをデジタル庁が常に見ておく運用が望ましいと考えます。つまり、ガバメントクラウド全体におけるセキュリティに関する変更イベントが発生するごとに自動的にレビューされ、必要に応じてアラートが上がるというような仕組みが必要になのではないかと思います。
こちらも総務省が提示している「クラウドサービス提供における情報セキュリティ対策ガイドライン（第 3 版）」に参考となる記載があります。
Ⅱ．４．３．情報セキュリティポリシーの遵守、点検及び監査
Ⅱ．４．３．１．【基本】 レビュー
> 各情報資産の管理責任者は、自らの責任範囲における全ての情報セキュリティ対策が、情報セキュリティポリシーに則り正しく確実に実施されるように、定期的に及び脅威の変化や設定・構成変更等の状況変化に応じてレビュー及び⾒直しを行うこと。また、組織の情報セキュリティのための方針群及び標準に関し、システムや提供するクラウドサービスが、定めに従って技術的に遵守されていることをレビューすること。
アカウント提供単位と制限・権限管理
先述の権限分掌の運用も検討する必要があります。先程のユースケースごとにどのような権限を自治体 or アプリ業者に引き渡すかを定義しておく必要があります。また、管理権限も多くの項目があり、例えば、サービス利用範囲の制限をするか否か、利用金額の制限をするか否かなども検討項目になるべきです。事前にヒアリングしたサービスだけを許可するのか、予算さえ許せばその他のサービスを利用できる権限を渡すのかも定義する必要があります。
後にも述べる予定ですが、予算を超えた場合にシステム停止してそれ以上の予算を超過させないという手段もあるが、自治体のシステムに於いてはシステム停止に繋がる恐れがあるので、そういった手段は取りづらいと考えます。加えて、予算を段階的に見せてアラートを上げる方法もあるが、段階をどのように定義するのか、障害期間や障害対応方法にもよるが、代替手段による一時しのぎなどの利用料は当初の想定よりも増減することが想定されるため、どう定義するのかをよく検討する必要があります（こちらは詳細について後ほど述べます）。
自治体とのネットワークアドレス設計
先行事業の時点では、クラウドと自治体の接続は専用線が想定されています。これに対していくつかのポイントを述べていきます。
1. 専用線は地域によって導入できるタイムラインが大きく異なります。つまり、すぐに引けるエリアもあれば、下手をすると数ヶ月以上かかる地域もあるため、クラウドの迅速性に比べて回線が追従できないケースが出てくることが想定されます。そのため、LGWAN やガバメントネットワークといった自治体が引き込んでいるネットワークもしくは VPN 等のインターネット網を利用したセキュアなネットワーク構成が望ましいと考える（このあたりは地方自治体の三層分離モデルも関連してきますが、それに関してはまた別途）。
2. 専用線を前提とした場合、マルチパッケージが別々のクラウドで構成されている場合、自治体からは各クラウドに専用線を引く必要があり、クラウド間連携は全て庁舎をまたぐ構成になる。そのため、Equinix のようなクラウドハブ的なソリューションや SDWAN のような仕組みを考える必要がある。もちろんそのような場合においては、クラウド間で適用できるセキュリティ項目・レベルが異なるため、どのように構成するかは各事業者の判断に委ねられるところとなってしまう。クラウドサービス間のネットワークを統合的にセキュリティを掛けるような NOC やセキュリティクラウドサービスの検討が必要となってくる。
3. 最後が、ネットワークアドレス体系についてです。
これもどのように全体設計がされているかに依ります。既存の自治体側ネットワークアドレス体系とクラウド側のIP アドレス体系の間には、整合性が取れていなければいけません。これがマルチパッケージ構成になった場合、パッケージ間のネットワークアドレス体系にも整合性が必要となり、アプリ事業者間の調整が必要になります。ほとんどのクラウドサービスでは、既存で利用していたネットワーク体系をそのまま持って行けるところは少なく、IP アドレス調整が困難になることが想像されます。これらを防ぐために、NAT 構成などを利用することが考えられるが、結局 NAT 構成の外側の IP アドレスと庁内の間には整合性が必要になる。さらに、これは専用線であった場合の話なので、自治体内で整合性が付けばよいが、LGWAN 等の広域専用ネットワークを組んだ場合には、自治体間・アプリ事業者間でのネットワーク整合性を取らなければならない。
自治体においてはセキュリティクラウドなどで既に経験済みの内容になるかと思われるが、それも都道府県内での話となり、今回はそれをも更に超えた枠組みになっていくため、全体の整合性を管理するような運用者・組織を準備することが良いと思われる。ただし、アプリ事業者が SaaS モデルで構成していた場合には更に困難を極めることになるだろう。
マルチクラウド運用の課題まとめ
このように、ガバメントクラウドをマルチクラウドとして運用する場合には、述べてきたような課題が考えられる。このようなことに対する考慮はガバメントクラウドの調達内にも見当たらないのと、先行事業での検証項目として明示もされていないため、このあたりがどうなるのかについては、引き続き注視が必要であると考えています。
1. 責任分界点
2. リソース妥当性・リソース引き渡し先の検討
3. セキュリティの状況変化に応じた動的追従
4. アカウント提供単位と制限・権限管理
5. 自治体とのネットワークアドレス設計
こちらの後編は以下にありますので、続けてお読みください。
また、まとめてお読み頂ける場合は、以下を御覧ください。