マイナンバー制度を考える（２）
コンビニ交付サービスの交付ミスの原因
次に問題となった交付ミスが発生した原因について考えます。詳しいトラブル情報は入手できませんでしたが、昨年の日経XTECHの解説記事（※4）にだいたいの原因が推察できる説明があります。これを読む限り、元々設計に潜在していた問題が一部構成要素の不具合によって現れた結果のように私には思われます。
（※4）「他人の住民票が誤発行される謎バグの真相、富士通Japanの「稚拙」設計に専門家も驚く」 （https://xtech.nikkei.com/atcl/nxt/column/18/01157/041800084/ [有料記事]）
以下、少し詳細になりますがそう考えられる理由について解説します。
（１）処理の流れ
処理の流れを少し詳細に書き下してみます。コンビニ交付サービスの処理フローは、この記事とJ-LISなどから公開されている資料などから理解した限りでは次のようになっているとおもわれます。
a. キオスク端末で住基カード（カード搭載アプリ）かマイナンバーカード（JPKI利用）で本人確認を行う
b. タッチパネルのメニューで申請する証明書を選択し、条件や通数等を指定して発行申請する
c. 発行申請は、J-LISが運営する証明書交付センター（広域交付サーバ等）によって宛先の自治体が利用する証明発行サーバ（事業者がサービス提供、今回のトラブルでは富士通、MICJET）に伝送
d. 証明発行サーバは、届いた依頼の印刷順序を管理し、依頼内容に基づいて住民情報を取得して証明書として印刷、PDF化し証明書交付センターに返却
e. 証明書交付センターは、返却されたPDFを請求元のキオスク端末に伝送
f. キオスク端末が証明書を印刷
暗号化のプロセスについては、詳しい説明が見つけられなかったので割愛していますが、今回の障害とは直接関係しないでしょう。
（２）トラブルの直接原因
記事によると、今回のトラブルの直接の原因は、「d．」の証明発行サーバで証明書を印刷する際に、複数の依頼が異なるキオスク端末から届いている状況で発生しました。おそらく何多重分かの印刷ジョブが走行できるように調整されていたと思いますが、それがいっぱいになるとそのあとに届いたジョブは待ち行列で保留されて、先行ジョブが終わると順に待ち行列からジョブを取り出して処理するといった仕組みになっていたのだと思います。
トラブルが発生した時にも先行ジョブの印刷が終わるまで処理を待っていたジョブがありました。しかし、「複数の申請が同時に行われたためアクセス集中により負荷がかかり」、「印刷イメージファイルの作成に時間がかかった」ため（順番待ちの時間も含めて処理時間がかかりすぎたんでしょう）、本来は保留しているジョブの印刷要求はキャンセルして利用者に再度実行してもらうよう表示するところ、この制御を行う管理プログラムに後続の処理のロックを外してしまうバグがあったとのこと。後続ジョブは先行ジョブが終わる前に印刷を完了し、先行ジョブの出力結果を上書きします。先行ジョブは、後続ジョブの出力結果を自分の出力結果としてユーザーに返却してしまった、というようにトラブル理由が説明されています。
ここには、二つのトラブル要素があります。ひとつは、印刷の順序制御の問題、もうひとつは、印刷に使うファイル名称（中間ファイルないし出力結果のPDF名称でしょうか）がすべて同一のものであったことです。この不具合は、プログラムバグと説明されていますが、インフラ側の設定値とか潜在的なタイムアウト値などが関係していたかもしれません。
（３）設計の問題について
証明発行サーバ内の管理方法はこの説明からはいまひとつはっきりしませんが、少なくとも「a.」 で本人確認した結果はそのあとの処理でトランザクションの ユーザーID や アカウント・コードなどとして使われていないことがわかります。あるいはそれらの紐づけのためにも使われていません。
住基カードやマイナンバーカードは、申請者が誰であるかを確認し（認証）、取得できる証明書が誰に対してのものかを確認する（認可）ために使われているはずですが、この認証と認可（個人情報へのアクセス権限確認）が終わって以降は、証明書に印刷するデータを抽出するための属性情報としてだけ用いられていると想定されます。実は、これがこの問題の本質で、印刷待ち行列の取り扱い不備の問題は派生的な問題に過ぎません。
なぜなら、もし、ユーザーID や アカウント・コードなどの形で認証結果が一連の処理全体にわたって管理されていたならば、自治体側の証明発行サーバで出力された処理結果は、印刷の順序が前後したからといって取り違えが起きる余地はなく、当然のこととして請求元のユーザーに返却されるはずだからです。メールを使っていて他人あてのメールが自分に届いたら驚くと思いますが、これと同じことが起こったのがこのトラブルです。こういったことを起こさないために行うオンライン処理の管理をオンライン・トランザクション管理（この場合、トランザクションとは、業務的に意味のあるひとつの処理を意味します。）といいますが、このサービスにおいては住民のユーザーIDやアカウント・コードなどを使ったオンライン・トランザクション管理機能が設計されていなかったとみて間違いないでしょう。
当然ですが、住民は自分のカードの番号にひもづいた処理は一連のものとして管理されているものと思っています。手作業で申請書を処理していた時代のことを考えても、窓口にきているのが誰で、いま処理している申請書が誰のもので、台帳のデータが誰のもので、出力した結果が誰のものかは常に意識して事務を進めているはずです。システムの実装で同じようなことを実現するのがトランザクション管理システムです。こうした確認なしに処理を進めても問題が起きないようにするために、徹底した順序制御、先入先出（FIFO）管理を行っていただけと考えてよいと思います。順序が狂ったことで、取り違えが生じたのはそのためです。
J-LISが運用する広域交付サーバについて考えます。障害内容から考えると、中央の広域交付サーバでも申請者と返却されたPDFの中味が合っているかどうかは確認されていないはずです。広域交付サーバは証明書の発行依頼のトランザクションを宛先のサーバに連携はするものの、トランザクションの回付をしているだけで、宛先や内容の保証については端末や証明発行サーバの責務として切り離されていたとみられます。端末側は一時点では電子証明書で確認済みのユーザーが待機していることが保証されているので、当該端末から申請されたものに対する返信が当該自治体の証明発行サーバから帰ってくれば本人のものであるに違いないからでしょう。
つまり、このサービス全体のトランザクション管理のポイントは各証明発行サーバに集中されていて、広域交付サーバはリモート端末から発行されるジョブの受け渡しと結果の配信をするネットワーキング部分だけを担当しています。リモートからのジョブ投入に関するネットワーキング部分と、証明書印刷に係る印刷サーバ部分から構成されるアーキテクチャです。トランザクション管理がもし広域交付サーバで行われていたとすると、富士通社製の当該証明発行サーバに限らず、他社のサービスするサーバでも同様の問題が発生してもおかしくはないわけですから、この見立てで問題ないでしょう。そしてその責務範囲に関する限り、広域交付サーバは想定どおりの動作をしたと考えてよいと思います。
では、証明発行サーバにおけるトランザクション管理の問題とは何でしょうか。トランザクション処理の設計においては、ACID属性が必要であるということが古くから言われています。1983年にACIDという呼び方が提唱されたとされていますが、考え方自体はそれよりも古くから存在し、オンライン・トランザクションシステムを設計する際の常識として長年技術者の間で共有されてきたものです。
ACIDのそれぞれの文字は次のような意味を持ちます。
Atomicity（不可分性）：
トランザクションに含まれるタスクはすべて実行されるかすべて実行されないかのどらかであることが保証されていなければなりません。
Consistency（一貫性）：
トランザクションの開始と終了に際してデータベースの整合性が保たれることが必要です。
Isolation（独立性）：
同時に実行されたトランザクションは相互に干渉せず独立に処理されなければなりません。
Durability（持続性）：
成功したトランザクションの結果については、永続性が保証される（つまり、参照、登録、更新、削除したデータがそのまま維持されること）必要があります。
ACID属性の観点から考えた場合、このサービスのトランザクションは、基本的にはデータベースの参照トランザクションなので、一応 Consistency と Durability は保たれていると考えたとしても、Atomicity と Isolation には問題が生じています。証明書発行依頼のデータは正しく渡された一方で、返却されたデータとの間に矛盾があれば、普通のトランザクション管理機能の下では、atomicityの原則に従って、この印刷トランザクションは破棄されなければなりませんでした。それだけでなく、同時に実行された別人のトランザクションとの間に干渉が発生して結果が入れ替わったわけですから、isolationの原則も崩れており、トランザクション管理が完全に破綻しています。というよりも、トランザクション管理を意識した設計がなされていた形跡がないと言ったほうが実情に合うのかもしれません。トランザクション管理機能を備えているミドルウェアを使っている感じもしませんので、手組の部分が多いのではないでしょうか。設計書を見たわけではありませんが、結果から見るとそのようにしか思えないのです。
情報が限られているのでどうしても推測が混じりますが、もう少し詳細にみていきます。
まず、証明書発行依頼を受けた広域交付サーバです。これは、既に述べたように、端末側ないしサーバ側で指定したアドレスに対して処理を振り分けることしかしていないはずです。つまり、処理を振り分けたらこのトランザクション（と言えるとすればですが）はその都度終わっています。端末から発出されて証明発行サーバに行って帰ってくるまでの間トランザクションは維持されていません。つまり、送信した証明発行依頼が正常に帰ってくるかどうかを管理する機能はここにはありません。単に送信元の端末やサーバが指定している宛先に処理を伝送するだけの機能です。
次に、証明書発行依頼が宛先自治体の証明発行サーバに届くと、これを待ち行列に入れて順次処理し、先行する処理が終わるまでは後続の処理はロックしておき処理終了したものから順に返却するのが通常の動きとされています。改めて確認すると、広域交付サーバがトランザクション管理をしないのですから、本来的には、この証明発行サーバでトランザクション管理がなされる必要があります。しかし、ここでも証明書の印刷依頼をしてきたジョブの順番と依頼元のキオスク端末のアドレスだけを管理していて、PDFの印刷結果が返ってくると、キューを調べて、待ち行列の一番先頭にあるジョブの発行元にファイルを返却していただけだと考えられます。印刷の順序性が崩れたことで発行する証明書が入れ替わるとすれば、そのような簡単な仕組みしかなかったと考えるほかありません。
せめて印刷ジョブにIDを振って、PDFファイルの出力依頼をしたジョブIDと印刷ファイルを何等かの形で紐づけていれば印刷プログラムのロックが外れるような問題があったとしてもこの問題は発生しなかったはずです。もっとシンプルに、普通のオンライン処理のように、依頼からPDFの返却までの一連の処理において依頼者の ユーザーID か Account ID を使って認証、ジョブ連携、印刷、PDF返送と連続する処理をひとつに紐づけていれば、このような問題は起こりえません。そういう仕組みを持たずに、依頼した順番に結果が返ってくることを信頼して設計していたとしか考えられないわけです。それが、印刷関連のファイル名を決めうちにしていたことのもつ意味です。
通常の印刷環境ではプリンター１台に対して印刷要求するクライアントが複数台いても、もらった順番に処理することで何も問題は発生しません。印刷物をもっていくのはユーザーの責任です。しかし、このシステムでは複数の印刷要求するクライアントに対して、印刷処理をするサーバは複数台になるうえ、印刷したPDFファイルを正しく依頼者まで返却する必要があるわけです。そのような環境であることは百も承知で、複数のプリンターからくる要求を一つの印刷キューのみ（単一の印刷ファイル名称のところで排他制御していたようなので、この部分に単一の待ち行列ができます）でFIFO制御しても問題ないという設計判断をしていたということになります。
日経XTECHの記事では、富士通の担当していた証明発行サーバ側の問題として説明されていて、実際にそうなのかもしれませんが、サービス全体としてみた場合のオンライン・トランザクション・アーキテクチャが十分に詰められないまま分散開発してしまったのではないかという疑いも残ります。富士通以外の企業による証明発行サーバの設計が、同じ轍を踏んでいないかどうかは詳しく設計を調べなければわからないでしょう。
（４）負荷予測に関する課題の考え方
このトラブルについては、印刷の負荷上昇が引きがねになったという説明が含まれているため、事前の負荷テストでなぜ発見できなかったのかという疑問の声もありました。私も初めそう考えました。実際、負荷テストで想定していなかった負荷が発生したことが理由だと言われれば、そう考えても不思議ではありません。システムは無限のキャパシティを想定して開発されるわけではありませんから、どこかで上限値を持ちます。また、プラットフォーム（ハードウェアおよびシステム・ソフトウェア）やソフトウェアの設計、ストレージの空き領域や作業域の拡張性などのハードウェアのキャパシティの制約など、潜在的な限界値のようなものがあって高負荷の時に思うように動作できなくなることがあります。テストの結果を見ながら、場合によっては、他のサービスへの影響を抑制するために設定値であえて性能を制限することもあります。設計者の見落としやマニュアルにも明記されていないような限界値はゼロにはできないので、安定性に対する要求の高いシステムでは、しっかりしたシステムテストが非常に重要になります。
あるいは、開発時には、（キャパシティ的に）現在のような使われ方を想定していなかった等ということもあったかもしれません。開発した後になって非機能要件が変更されたが、改めてシステムテストを実施する環境も用意できずにそのまま運用継続したことで不具合を生じた、といった類の問題は案外あるものです。特に、検証環境に対する投資をできるだけ控えたがる顧客などではありふれた話でしょう。総合テストやシステムテストなどと呼ばれる最終テスト段階で負荷テストを行う意味のひとつは、このような潜在的な問題も含めて想定する運用のピークでもシステムが乗り越えられるのかどうかを確認することが目的なわけですが、フルセットで本番同等の環境が準備できない場合は部分的な構成でのテストで済まさざるを得ません。
ただ、コンビニ交付サービスのトラブルについては、想定外負荷を理由にしてしまうと本質をとらえそこなってしまいます。想定外の負荷やそれによる動作不具合はアンラッキーですが、その場合でも個人情報の取り違えを起こすことはあってはなりません。これはシステムの構造、設計の問題で、負荷テストのシナリオの問題ではありません。
日経XTECHの記事が正しいならば、コンビニ交付サービスには普通の意味でのトランザクション管理が実装されておらず、ほとんどローカルな共有プリンターの印刷サーバの「ノリ」で設計されていると言っても過言ではありません。記事のタイトルにある「稚拙な」が何に対してのものかは記事からは判読しかねるのですが、トラブルの内容を分析する限り、とても大規模システムの大量トランザクションを管理するシステムとは思えない設計といわざるをえません。
キオスク端末はいわば自治体窓口の代替です。したがって、窓口に立つ自治体職員と同様に、証明書類を請求する住民の情報を大切にする必要があるし、それを保護したうえで一連の事務処理を回すのがオンライン処理の鉄則です。こうしたことを実現する仕組みは、メインフレーム時代から連綿と受け継がれており、普通のWebトランザクションでも、非同期オンラインやオンラインバッチでもオブジェクトの処理でも、トランザクション管理には、様々な手法があります。技術自体はありふれたもので入手困難といったこともありません。住基ネットの時代の設計とはいえ、いくらでもやりようはあったはずです。それなのに、なぜこうなったか。実は、この原因となったことは住基ネットの仕組みそのものに内在されていると考えています。つまり、技術者の設計にばかり原因をおしつけていいのかどうかという問題です。次にこの点について説明したいと思います。
2024/09/15
この記事が気に入ったらサポートをしてみませんか？