【ガバメントクラウド】マルチクラウドにおけるファイル連携の課題点（OCI視点強め）
悩みの種
私は日々悩んでいる。マルチクラウドでの連携どうしようかと。
各ベンダとの連携に関する調整フェーズに突入しており、困難を極めている。各社システムが想定する連携方式が必ずしも一致しているとは限らず、ほぼ100%調整が発生している。連携先システムの数、つまり全システムと調整が発生する。
悩みに悩んで少しハゲてきた。一人で悩んでも進まないので、0.8版としてこれを公開して、皆様と一緒に課題を整理して対応策を検討していきたい。そうすれば同じようなことで禿げそうになっている同志の皆様はハゲずに済むし、私もハゲがいがあるというものである。
建設的な指摘はウェルカムだ、共闘しようぞ！！
本記事の目的
先日共闘プラットフォームにて議論になった「マルチクラウド間のファイル連携」に関する悩みや課題について、具体的にどのような部分が課題になっているのか例示しながら整理します。
課題だらけで正直先もよく見えないですが、ただ現状批判をするのではなく、最終的には解決案や方法論の提示などができたらと考えています。
そのためにも、本記事の内容についてのご意見・ご提言などを多くの有識者方や同じ境遇の方などに頂けることが目標です。パブリックコメント感覚で、記事へのコメントやXなどでの反応をいただけると幸いです。必要に応じて頂いた反応を踏まえた次回作を執筆します。
前提
本記事は、ガバメントクラウドにおいて、主にOCI上に庁内データ連携機能を構築する場合の課題について触れています。マイノリティ向けの記事になるかと思いますがご了承ください。
また、システム標準化・ガバメントクラウドなど、業界固有の言葉の説明は省略します。また本記事で前提とする知識は以下のとおりです。
・自治体システム標準化、ガバメントクラウドの基本的な知識
・共通機能-庁内データ連携に関する基本的な知識
・地方公共団体情報システム共通機能標準仕様書【第2.3版】
・ファイル連携に関する詳細技術仕様書【第2.2版】
・ガバメントクラウド利用概要（OCI編）
・機能別連携一覧
・OCIに関する基本的な知識
※本記事は、2024年7月22日現在の情報をもとに執筆しています。
連携基盤は誰がどこに置くのか
他システム連携に関する仕様は、共通機能仕様書の中に「庁内データ連携」として定められています。ここでは便宜上、庁内データ連携用のオブジェクトストレージ若しくはファイルサーバを連携基盤と呼称します。
「地方公共団体情報システム共通機能標準仕様書に関するリファレンス」には、住記ベンダや最初に業務を導入するベンダが扱うCSP上に連携基盤を作ることが例示されています（図１）。また、マルチクラウドの場合は連携基盤をどちらかのCSPに寄せるのが一般的です。
住記ベンダがAWSならAWS上に庁内データ連携用のオブジェクトストレージが作られますし、住記ベンダがOCIなら以下略、です。
仕様書のファイル連携パターン
機能別連携一覧には、20業務間の連携は原則ファイル連携と定義されています。一部の共通機能系業務（住登外宛名など）においてはAPI連携を利用することになっています。
本記事では主に20業務間の連携（つまりファイル連携）にフォーカスを当てます。次の図２は、ファイル連携を実現するにあたり取り得る選択肢を整理した図です。
仕様書には、データの保管場所として「オブジェクトストレージorファイルサーバ」、接続方法として「API or SFTP等の暗号化通信」が定義されています。この組み合わせの中で「①CSPが提供するツール（API）を用いたオブジェクトストレージ利用」が原則とされています。
また、いずれの場合も「保存データ」「通信経路」双方の暗号化が要求されています。
なお便宜上、以下「SFTP等」を単に「SFTP」と表現しますが、仕様書上は暗号化できるプロトコルなら許容されていますので、SCP・SFTP・FTPS等に適宜読み替えてください。
マルチクラウドにおけるそれぞれの連携パターンの課題
図２の各パターンの課題を整理してみます。
①オブジェクトストレージにAPIでアクセスする
同一CSP間なら何ら問題ないと思います。異なるCSPのオブジェクトストレージへAPIアクセスする場合はハードル高いです。もはやラスボスです。詳細は後述します。
②オブジェクトストレージにSFTPでアクセスする
技術的には特段問題なく対応可能です。
ただし、ガバメントクラウドにおいては次の点が課題となっています。
顧客秘密キーが必要だが、ガバメントクラウドではCSPユーザを独自に払い出せないため、権限管理が難しい。
そもそもガバメントクラウド利用概要（GCAS）には、顧客秘密キーは利用禁止とされている。
図３はガバメントクラウド利用概要（OCI編）のキャプチャですが、AWS編においてもアクセスキーの利用が禁止されています。
つまり、オブジェクトストレージへの直接的なSFTP接続は実質禁止されている状態です。
一方で、連携基盤がAWSにありS3をOCIから利用するようなマルチクラウドの場合は、AWS Transfer Familyを利用することで、クライアント側はSFTPを利用でき、認証認可はAWSに任せておけるため、検討の余地があると思います。（本記事では詳しくは触れません）
OCIについては、oracle Manafed File Transfer（MFT）を利用する検討もしましたが、APIキーが禁止されているなどにより、結論的にはガバメントクラウドでは利用できなそうでした。
そもそもファイル連携にオブジェクトストレージ使うとか言い出さなかったらこのような事になっていなかったのでは？？
③ファイルサーバにSFTPでアクセスする
ファイル連携に関する詳細技術仕様書には「既存システムなど、オブジェクトストレージ利用が困難な場合において、ファイルサーバを構築することを許容する」と書かれているため、オブジェクトストレージとファイルサーバは並列な関係ではなく、原則はオブジェクトストレージであることが読み取れます。ただし実装ハードルはそれほど高くはないと考えられるため、マルチクラウド＆マルチベンダとなる自治体においては、このパターンが一番現実的かも知れません。
③が現実解な気がしてきました。が、ここでは一番強敵そうな①についてもう少し深掘ってみます。
オブジェクトストレージへのAPIアクセス（①）のパターン
ここからは、①「オブジェクトストレージにAPIでアクセス」について深掘りたいと思います。
メトリクスで整理します。例としてAWSとOCIのマルチクラウドを想定します。連携基盤用のバケットが置かれるCSPとクライアント側（アクセス元）のCSPに分けたとき、下図の３パターンに分類できます。
図５－１、５－２を整理すると以下のようになります。
（A）AWS上のオブジェクトストレージをAWSから利用する ←同一CSPのため今回は割愛
（A）OCI上のオブジェクトストレージをOCIから利用する ←同一CSPのため今回は割愛
（B）AWS上のオブジェクトストレージをOCIから利用する
（C）OCI上のオブジェクトストレージをAWSから利用する
ガバメントクラウドでは、マルチクラウド（BやC）でのファイル連携において、一般的なプラクティスが利用できません。マルチクラウドとなるだけで一気に連携難易度が上がったように感じますね。
BやCに対応するためには、オブジェクトストレージを操作するAPIを利用するための（AWS－OCI間の）認証認可を橋渡ししてくれる仲介役が必要と考えます。ここではその役割を担う機能を仲介アプリと呼称します。この後もう少し詳しく言及します。
ガバメントクラウド特有の制約
マルチクラウドにおけるファイル連携の課題について整理するために、ガバメントクラウド特有の制約についても見てみましょう。
ガバメントクラウドではユーザの払い出しができない
ガバメントクラウドでは、GCASユーザによるSSO認証を実施する関係で、ガバメントクラウド（AWSやOCIなど）内に任意のIAMユーザを作成できません。
APIキーや顧客秘密キーが使えない
前述の図３のように、APIキーや顧客秘密キーが利用できないとされています。
APIキーは、OCI CLIを使用する場合などに利用しますが、この制約によりOCI CLIが使用できず、OCI CLIによるオブジェクトストレージのAPI操作もできないことになります。
顧客秘密キーは、オブジェクトストレージへのアクセスやS3互換APIを利用する場合などに利用しますが、この制約によりOCIが提供する「外部からのオブジェクトストレージアクセスツール」が利用できないことになります。
AWSも同様にアクセスキーが使えない
オブジェクトストレージアクセス時に利用するキーが利用できない制約は、OCIだけでなくAWSでも同様に禁止されています。
マルチクラウド連携の最難関 C：OCI上のオブジェクトストレージをAWSから利用する
ガバメントクラウドでの制約も踏まえると、図２が「オブジェクトストレージにAPIでアクセス」、図５が「OCI上のオブジェクトストレージをAWSから利用する」となる場合が最難関の連携パターンなのではないかと感じています。
※類似の「AWS上のS3をOCIからAPIにて利用する」については今回は割愛します。
実現するにあたり取り得る方法をいくつか整理します。
１．OCIが提供する「S3互換API」を利用する
２．クライアント側にOCL CLIをインストールして利用する
３．オブジェクトストレージの事前認証済みリクエストを利用する
４．認証認可とファイル操作を行ってくれる仲介アプリを構築し、利用する
先に結論ですが、現時点では実質的に④しか選択肢がないのではという状況です。
①S3互換APIを利用する
S3互換APIを使う上での課題は次の2点です。
顧客秘密キー問題
S3互換API利用には顧客秘密キーが必要です。顧客秘密キーはOCIのIAMユーザごとに発行するトークンで、ユーザのポリシーが適用され、リソースへのアクセス制御を行います。
前述の通りガバメントクラウドでは顧客秘密キーの利用は禁止されている点が最大の課題です。
なお仮にこの点が緩和されたとしても、先述の制約の通りガバメントクラウドではIAMユーザを任意に払い出せません。20業務の各ベンダ・各システム用のユーザ作成ができないため、連携に必要な最小権限ポリシーが適用された顧客秘密キーが生成できず、権限制御が困難と考えています。
コンパートメント問題
ガバメントクラウドは複数の自治体を1テナンシにホストする、いわゆる共同利用方式が推奨されています。各自治体をコンパートメントで分離して構築する構成です。
S3互換APIは、AWS側にコンパートメントの概念が存在しないため、予め指定したコンパートメントへのアクセス権を持ちます。
つまり、共同利用方式を構成する自治体が複数ある場合でも、S3互換APIがアクセスできるコンパートメントは単一のコンパートメントとなります。連携基盤を同一のコンパートメント上に存在しなければならないことになり、別途権限制御を検討する必要があります。
よって、現時点ではS3互換APIはガバメントクラウドで使えないです。
②クライアント側にOCL CLIをインストールして利用する
クライアント側からOCI CLIを利用する上での課題は、APIキーが禁止されている点です。
課題
IAMユーザを勝手に作れないため、他システム・他ベンダ用のAPIキー管理ができない。（API専用ユーザが作れない）
ガバクラ利用概要で示されている「トークンベース認証」はインターネットに繋がらないと使えない。（マイナンバー系NWはインターネットへ接続できない）
よって、OCI CLIもガバクラで使えないです。
③オブジェクトストレージの事前認証済みリクエストを利用する
事前認証済みリクエストは、クライアント側が資格情報を持たずともオブジェクトストレージにアクセスできる方法で、リクエスト発行したIAMユーザに紐づくアクセス制御がなされます。
課題
ユーザの払い出しが行えず、適切なアクセスコントロールが難しい。
高頻度で発生する連携（最短でリアルタイム連携）に対しても途切れることなくリクエスト発行が行えるのか。
（現時点では事前認証済みリクエストはコンソール上からの手動発行のみとなっている）
よって、事前認証済みリクエストもガバクラでは現実的ではないです。
④認証認可とファイル操作を行ってくれる仲介アプリを構築し、利用する
OCI上のオブジェクトストレージに対してOCI外からのリクエストに応答しファイル操作をしてくれるツール（前述の仲介アプリ）を作ることで、オブジェクトストレージアクセス時の課題となる認証認可とファイル操作の両方を解決しようとする方法です。
言い換えると、認証認可基盤を構築したうえで独自APIによってオブジェクトストレージに対するファイル操作を行うような機能群を構築することになるため、当初想定されていたAPI連携を応用してファイル連携を行うようなイメージかも知れません。
感覚的にはとても面倒なのではと感じます。クライアント（利用者）向けAPIはインターフェースが規定されていないため、仲介アプリの構築者ごとの独自IFとなることが想像されます。クライアント側はこの独自IFに対応する必要があり、この点が面倒と感じる一因です。
しかし現実的には（オブジェクトストレージをAPIで利用するためには）この方法しか有力案が無いのではないでしょうか。
仲介アプリは救世主となるか
OCIオブジェクトストレージへAWSからアクセスしたい場合、仲介アプリは本当に救世主になるのでしょうか。
仲介アプリを構築するリソースが各ベンダーにあるのか（そもそも誰が構築するのか）
クライアント側が仲介アプリIFへ対応するためのリソースがあるのか（仲介アプリIFは独自仕様となることが想定されるため、仲介アプリ開発側からのIF開示が無ければクライアント側も対応できない）
2025年までに仲介アプリ開発・クライアント側対応の双方の対応が終わるのか
このような課題があると感じており、2025年までに対応ができるのか、険しい道のりです。
オブジェクトストレージをAPIで利用する際の課題まとめ
ここまで、主に「マルチクラウドにおいて他CSPのオブジェクトストレージをAPIにて利用する」場合の課題について言及しましたが、要約すると、以下のガバメントクラウド特有の課題が問題を複雑にしているのではと感じます。
APIキーが利用禁止である
顧客秘密キーが利用禁止である
CSPユーザーを独自に払出しできない
これらは、本来は不正アクセスや意図しない権限譲渡を防止するための制約だとは思います。一方でガバメントクラウドは5CSPが認定されていますので、マルチクラウドとなる可能性も十分にあり得るので最適なアプローチではない気もします。
これら制約が緩和もしくは解消されれば、もう少しやりようがあるのかもしれません。
じゃあどうしたら良いのか
連携基盤がAWS・OCIどちらの場合でも通用する最大公約数的な現実案は「③ファイルサーバを構築しSFTP等でアクセスする」のように感じます。
よって、最終的にはファイルサーバ利用を視野に入れて交渉するのが良いのかなと感じています。
また、連携基盤がAWSの場合はTransfer Familyも一考の価値はあると思います。選択肢を持って建設的な交渉ができるといいですね。
一方で国が推奨する「①オブジェクトストレージをAPIにて利用する」方法の実現に向けても、現在自治体やベンダー間で協議が続いていることと思います。
大切なことは、自治体・関係ベンダー間でしっかり調整していき、どういったパターンが最適か判断していくことと思います。
最後のまとめ
制約と不確定要素が多い中で2025年まであと1年もありません。そんななかで自治体・ベンダー間で調整をしていく必要があります。
ファイル連携のパターンは、図２のように3つに分類できました。
①オブジェクトストレージにAPIでアクセスする
②オブジェクトストレージにSFTPでアクセスする
③ファイルサーバにSFTPでアクセスする
「①オブジェクトストレージにAPIでアクセスする」については、本記事では「OCI上のオブジェクトストレージをAWSから利用する」場合について課題を整理しました。結論的には、現状では仲介アプリによる認証認可の橋渡しが必要だが、実装コストやスケジュール面、調整事項が多いなどにより現実的ではない、という課題が見えてきました。
「②オブジェクトストレージにSFTPでアクセスする」については、直接的にオブジェクトストレージへ接続することはガバメントクラウドの制約により実現できないことがわかりました。ただしS3の場合は、Transfer Familyを利用することでAWS外からでもオブジェクトストレージ（S3）へアクセスできる方法があります。OCIについては現時点ではそのような代替手段はないと思われます。
「③ファイルサーバにSFTPでアクセスする」については、実装ハードルが低いため、マルチクラウド・マルチベンダー下における妥協案になり得ると考えています。
今回は、共闘プラットフォームにて議論になったマルチクラウドにおけるファイル連携の課題について整理してみました。あらゆる仕様や制度が確定しない中で、稼働を見据えていつまでに仕様凍結をしなければならないのか、判断を迫られていますが、本記事が皆様の何かの気付きになれば幸いです。
なお執筆にあたり内容には細心の注意を払っておりますが、万が一、本記事において事実誤認などありましたら、お手数ですがご指摘いただけると幸いです。
また冒頭にも書きましたが、ぜひ有識者の皆様からのご意見も頂けたらと思います。
この記事が気に入ったらサポートをしてみませんか？