情報セキュリティの脅威はすぐそこに

特殊な商流における「責任」のあり方

GMOペイメントゲートウェイのカード番号流出事件が、あまり大きな話題になっていませんが、事態は重大でかつ複雑なので少しまとめてみたいと思います。

きっかけは3月7日に公開されたApache Struts2の脆弱性(CVE-2017-5638)です。内容はリモートから任意のコード実行が可能というもので、すぐに修正バージョンも公開されています。

一方で複数のセキュリティ系情報企業から8日以降にこの脆弱性を狙ったものとみられる攻撃が増加しているというニュースが流れ始めます。またいくつかの有名サイトでこの時期に緊急メンテナンスが実施されていることも確認されており、対策を行っているところは行ったという状況と見られます。しかし3月10日頃になるといくつかのサイトで不正アクセスに関する被害報告が発表されるようになり、GMOペイメントゲートウェイもこの内のひとつです。

被害の内容は「任意のコード実行が可能」だったということもあり様々で、サイトの改ざんや情報流出が多いようですが、GMOペイメントゲートウェイからはカード番号と有効期限を含む複数の情報が流出しており、述べの件数では70万件近く、カード番号と期限だけが6万件、「クレジットカード番号・クレジットカード有効期限・セキュリティコード・カード払い申込日・住所・氏名・電話番号・生年月日」というフルセットでの流出が622件と、被害は甚大なものとなりました。

脆弱性の公開から攻撃の成功までの期間が3日間である点をどう評価するかですが、成立条件がシンプルでかつ影響が大きいことを考えると、十分な期間だったと言えるかもしれません。

 

一方でApache Struts2そのものに対する評価にも目を向けておかなければなりません。Apache Struts2はJavaアプリケーションフレームワークのひとつですが、シェアはそれほど高くないようです。

むしろ近年重大な脆弱性が度々発見されており、「危険なソリューションだ」という声も聞かれます。一部では採用される事例も多いようですが、危険だという評価がある以上、設計段階でのリスク評価やそれを踏まえた上での運用・対応体制がどうだったのかは気になるところです。機能上の理由などから採用せざるを得ないという事情はあるかもしれませんが、今回のような脆弱性情報に対する対応が十分ではなかった点は反省すべきポイントでしょう。

 

さらに今回の舞台のひとつとなった「都税クレジットカードお支払サイト」の運営体制の不透明さや不親切さは以前から指摘されていました。

サイトのデザインや構成上はあたかも東京都主税局の公式サイトのような立て付けになっていながら、ドメイン名が「zei.tokyo」であり誰でも取得できるものであったり、SL証明書の名義がGMOペイメントゲートウェイだったりと、その実体がよくわからないと話題になっていました。

法律上・制度上の実体は東京都の納税代行をトヨタファイナンスが受託をしており(指定納付受託者)、システムや決済部分をGMOペイメントゲートウェイに再委託しているという構造と思われます。これは住民税の支払いをコンビニで行う場合と似ており、コンビニ本部(セブンイレブンやファミリーマート)が指定納付受託者になっていて、実際の支払いオペレーションをフランチャイズの店舗が行うという構造と商流としては同様のものと考えられそうです。

今回、不幸にしてこのような情報流出事件が起きてしまいましたが、責任の所在について未だわかっていません。少なくともGMOペイメントゲートウェイでは再発防止委員会が設置され、ここで対策が協議され公表されることになると思われますが、トヨタファイナンスや東京都がどのような対応を取るかについてはまだ不透明です。

同じような構造で、コンビニの店員が何らかの不正を行った場合に東京都がその責任を負う必要はありませんが、今回の場合は「東京都主税局の公式サイト」という体裁になっていたことから東京都にも一定の委託・監督責任があると言わざるを得なくなるかもしれません。また脆弱性情報に対応する体制やそれに関わる各社の分担や責任のあり方という側面でも興味深い事例になりそうなので、今後の展開に注目したいところです。