情報セキュリティ

7payでの不正使用---セキュリティの弱いWebシステムを見分ける方法

こんにちは、合同会社たいがの小西です。梅雨が続く季節ですが、みなさまはいかがお過ごしのことでしょうか。

さて、本来は今回、ガイドブックに関する最後のお話をさせていただくつもりだったのですが、目下、セブンイレブンのキャッシュレス決済である7payの、アカウント乗っ取りによる不正使用が騒がれています。

中小企業の皆さまにおいては、本件で「会社として」被害に遭われたケースはほとんどないと思いますが、これを他山の石として頂きたく、私の思うところを書かせていただきます。

（もし万一、個人として被害に遭われた方がいらっしゃいましたら、本当にお気の毒でございます。
セブンイレブン関連会社である株式会社セブン・ペイは、全額賠償すると言っておりますが、それは当たり前のこと、被害に遭われた方の対応コスト(問い合わせ、IDやパスワードの変更、クレジットカードの変更手続きなど）も考慮して頂きたいものです）

7payの事故概要

このセキュリティ事故について、ご存じない方のために概要を申し上げます。
「7pay」900人に不正アクセス 被害5500万円か
コンビニ最大手、「セブン‐イレブン」のスマホ決済サービス、「7ｐａｙ」の運営会社は、およそ900人が第三者による不正アクセスの被害に遭い、被害額はおよそ5500万円に上る可能性があると発表しました。会社では、「7ｐａｙ」へのチャージと新規登録を停止し、原因の究明を急ぐとしています。
「7ｐａｙ」は、セブン‐イレブン・ジャパンが、今月１日からサービスを始めたスマホ決済サービスで、およそ150万人が登録していますが、利用者から身に覚えのないチャージがあり、勝手に商品を購入されたなどという連絡が相次いでいます。
以上はNHKのWebニュースからの引用ですが、「なりすましによるアカウント乗っ取りと、不正使用」です。

現時点では原因は判っていませんが、このサービスを提供したセブン・ペイの社長の記者会見のまずさや、セブン・ペイ社の構築したシステムの作り自体にも問題があること（これは後述します）が指摘されています。

決済サービス会社とは思えないセキュリティ知見のなさ

「痛い」セブン・ペイ経営陣の記者会見

この7payというサービスは、いわゆるキャッシュレス決済です。

キャッシュレス決済とは文字通り、現金を使わずに支払うということで、経済産業省も「キャッシュレス・ビジョン」と称して推進しています。

現金取引は現金という非常に重要な現物を扱うので、受け渡しや管理に手間がかかります。従って、現物のやり取りを減らし効率化するという考え方に基づいています。

ポイントは、キャッシュレス決済のような仕組みは、完全にITの領域であることです。
ですから、経営管理者はITの知見がないと務まりませんし、ITの知見の中には、当然「セキュリティ」も範疇に入ります。

特に「決済」はお金の支払いです。ですから、通常のシステムよりも、強固なセキュリティ・コンプライアンスの知見と、それに基づくシステムの実装力が必要なのです。

そのうえで・・・
こうした7payのセキュリティについて、当然記者会見で注目が集まった。ところが、「どうして二段階認証を採用しなかったのか」という報道陣の質問に対して、7Payの小林強社長が「二段階認証？」と聞き返し、さらには「二段階云々」と発言。運営会社トップがキャッシュレス決済の安全の基本を知らないという”ITオンチ”ぶりを露呈する事態となった。
(「7pay不正利用で露呈したセブン＆アイの「ITオンチなのに自前主義」」DIAMOND onlineMOND onlineより)
とのこと。

これを読んだとき、私ははじめ「えっ、うそだろ？」と思ったのですが、翌日、「7pay、二段階認証を導入へ　チャージの上限額も見直し」となったことから、「ほんとだったのか・・・」と正直、がっかりしたのです。

「二段階認証」とは、私がこのブログで何度か書いた「多要素認証」の一形態です。

そこでも書きましたが、二段階認証とは、「認証=自分がなりすましではないことを証明するために、パスワードだけに頼らない」ための方法です。

私は、IT以外の一般の会社の経営者の方が「二段階認証」や「多要素認証」を知らなかったとしても、無理はないと思います。
しかし、決済サービスの経営陣が、こんな基本的な知識を知らないというのはNGです。
百歩譲って社長がITの知見に乏しいなら、ほかのITに知悉した経営陣が記者会見に出て、話すべきだったと。

というのは、先ほど申した通り、人のお金を扱うサービスを営む会社であること、かつ、この種の仕組みは完全にITの世界だからです。

ちなみに、私の社会人としての一歩は銀行員であり、そこで私はシステム部に所属し、決済業務のシステム構築にも携わりました。

ITの知見・経験に加え、セキュリティやコンプライアンスの知見と、それをITに組み込む方法の基礎を諸先輩からみっちり学びましたが、それは今でも本当に役立っていますし、ご教示いただいた諸先輩方にも本当に感謝しています。

そういう面からも、この記者会見は非常に残念だと思いました。

<実は、この記者会見は、リスクが現実化してお客様に損害を与えることになった際の「説明責任」の観点からも問題があると思うのですが、それは話が拡散するので、またの機会にお話ししたいと思います>

認証の重要性を判っていない仕組み

また、このシステムでは、認証に関し、少し考えられない「仕組み」がありました。
（ちなみに、この仕組みも、現在では修正対応済ですが）

どんなWebサイトでも、お客さまがパスワードを失念した場合の機能があります。

何度も言いますが、パスワードとは「自分が知っていること」で自分を証しする仕組みです。ですから、そのパスワードを再設定するときには、きわめて当たり前のことですが、
「パスワードを失念したのは他ならぬ自分である」
ための証しが必要です。

というのも、悪意ある第三者は、お客さまが設定したパスワードを故意に変更し、お客さまのアカウントになりすまし、悪用する可能性があるからです。

ですから「パスワードを失念したのは他ならぬ自分である」ことを証明するために、お客さまはご自身のIDや誕生日など、自分しか知らない（はずの）ほかの情報を入力するのです。

7payでのIDはお客様のメールアドレスでした。そこで、下図のように会員ID(メールアドレス)と生年月日・登録時の電話番号を入力させる仕組みにしていたのですが、下図のように、「送付先メールアドレス」という項目があります。


7payクレジットカード不正利用：第三者乗っ取りがあり得る致命的な2つの弱点(Yahoo!Japanニュースhttps://news.yahoo.co.jp/byline/mikamiyoh/20190704-00132766/より引用）

7payの仕様では、登録時のID・生年月日・電話番号が合っていれば、送付先メールアドレス宛にパスワード再設定画面のリンク(URL)を送り、お客さまはそのリンクから新たなパスワードを再設定する仕組みになっていたのです。

で、これが上の記事にもあるように、セキュリティ的に非常に問題なのです。

なぜ問題か、というと、悪意ある者Aが、あるお客さまのメールアドレス・生年月日・電話番号を知っていたら、「送付先メールアドレス」に、A自身のメールアドレスを入力すれば、再設定画面のリンクは悪意ある者のメールアドレスに送付されるので、Aはお客様のパスワードを故意に変更することができるのです。

これはまさに「アカウント乗っ取り、なりすまし」です。

※なお、事故原因はいまだ分かっていないので、この仕組みを悪用して不正が行われたかどうかは、現時点ではわかっていません。
しかし、過去に問題があると言われてた、この仕組みを導入したことが、「本当に、セキュリティを考慮したシステム設計を行ったのか？」という疑念につながっているわけです。

で・・・メールアドレスや生年月日、電話番号などは、名簿業者が扱っていますよね。正当に入手したものかどうかはともかく・・・だから比較的入手は簡単なわけです。

7payの場合は「送付先メールアドレス」のような機能は持たず、最初に登録したIDであるメールアドレス宛に送るべきなのです。

ちなみに、これは既にかなり昔に、この仕組みを悪用されたことが何度もあったので、IT屋ならわかっていて当然のルールです。

セブン・ペイ社は
「お客さまの利便性のために、送付先アドレス欄を設けた」
と言っていましたが、別のメールアドレスに送付することもできる「利便性」と、セキュリティをちゃんと秤にかけて判断したのか、きわめて疑問です。

率直に言いますが「そのリスクを知らなかった」のだと思います。
→この「仕組み」が騒がれた翌日に、送付先アドレスを表示しないよう修正したのは、その傍証だと思います。

セキュリティの弱いWebシステムを見分ける

7payの事故例は
「大企業の看板がある企業のシステムといえども、安心はできない」
という事実を浮き彫りにしました。

では、私たちは、どのようなWebシステムがセキュリティが弱い、と判断したらいいでしょうか？

Webを構築するITエンジニアであれば、IPAの「安全なウェブサイトの作り方」をはじめ、セキュリティに強いエンジニアの方の著作などで知見を得ています。

しかし、それはあくまでシステム内部の作り方の話であり、「外から見た見分け方」ではありません。

「外から見た観点」でわかりやすいのは、その会社が、ISMS(情報セキュリティマネジメントシステム）やプライバシーマークの認証を取得している、などがあります。

しかし、これら認証は、あくまでも
「会社、あるいは部門として、セキュリティ管理や個人情報管理に"取り組んでいます"」
を示すものであって、
「お客さまに対し、セキュリティ対策や情報漏洩対策を、具体的なシステム的な仕組みとして、導入、運用管理しています」
を示すものではないのです。

もちろん、私はISMSやプライバシーマークを否定するものではなく(私はこれらの審査員補資格を持っています)、これらの認証は、自社のセキュリティに対する取り組みを社会に示すうえでは有用なものです。

自社のセキュリティ管理に取り組んでいるということは、お客さまへのセキュリティ対策もしっかりしている「可能性が高い」と言えますから。

が・・・いくらISMSやPマークを取得している企業でも、セキュリティ事故が皆無とは言えません。むしろ
セキュリティ認証を取得したり、セキュリティポリシーを導入し対策を行っている企業や組織ほど、セキュリティインシデントが多く発生しているという分析結果が浮かび上がった
(「【サイバーセキュリティ・ミステリー】 「セキュリティ体制を整えれば整えるほどセキュリティ事故は多発」 学術研究結果 近日公表」より抜粋)
という研究結果もあるくらいですから・・・

ですから、見分けるのは本当は難しいのですが(セブンペイ社のパスワード変更の際の「送付先メールアドレス」などは、使ってみないとわかりませんから）、ここではごく基本的な観点で、「セキュリティの弱いWebシステムを見分ける」のポイントを申し述べます。

ちなみに、ここで「Webシステム」と言っているのは、インターネットバンキングやクラウドシステムのような「インターネットを経由して使うシステム」と理解してください。

外から見て「セキュリティの弱いWebシステム」と私が考えるのは、以下の3点です。
  1. パスワードが16文字以内で英数字のみに制限している
  2. 通信の暗号がされていない
  3. 本人認証に多要素認証を提供していない

1. パスワードが16文字以内で英数字のみに制限している


パスワードは暗号化されてシステムに保存されます（正確には暗号化ではなく「ハッシュ化」、興味のある方は「[セキュリティ] ハッシュ化と暗号化は違いますよ！！」をお読みください）。
ですから、お客様のパスワードは、システムを提供する側も分りません。

<なお、今時、パスワードをハッシュ化して保存していないのはNG。ただし、それは外から見てもわかりません・・・>

現在のパスワードハッシュ化は、入力されたパスワードの文字数がいくつでも、固定の長さに暗号化できますから、長さ制限は必要ないのです。

にも拘わらず、16文字以内に制限しているというのは古いシステムです。
かつ、英数字のみで記号が使えないのも（内部のシステム的な事情は実は少しは理解できますが）、セキュリティ的にNGです（本当にパスワードをハッシュ化しているのか？という疑問も沸きます）。

ですので、このようなパスワード制限があるシステムであれば、そのWebサイトはセキュリティレベルの弱いシステムということになります。
但し、このWebサイトが後述する通信の暗号化と多要素認証を使っていれば、問題はありません。

2. 通信の暗号化(HTTPS)がされていない

Webシステムの通信は、HTTPという通信プロトコルでやりとりされます。
そして今は、常時暗号化通信(HTTPS)が標準となっています。

下図の通り、chromeブラウザでは、暗号化されている場合はアドレスバーに鍵マーク、及び、アドレスの先頭に「https」と表示されます。
一方、暗号化されていない場合、アドレスバーに「保護されていない通信」と表示されます。

暗号化されていない、というのは通信の盗聴に対し、何の防御もされていないということです。

皆さまがWebサイトでID、パスワードを入力する際、パスワードが暗号化されているか、いないかで、安心感も大きく変わると思います。
また、皆さまがお客様の情報をクラウドなどのインターネット環境に置いている場合、その情報を閲覧するのに暗号化されていないということは、盗聴される恐れがあるわけです。

何より、先のパスワードと同じく、今はWebにおいては常時暗号化通信が標準なので、それができていないサイトというのは、「セキュリティに対する構え」という点で大きな疑問があります。

3. 本人認証に多要素認証を提供していない

私は以前の記事で、認証では
「パスワードだけに頼らない」
を申し上げました。
そこでお勧めしたのが、多要素認証です。

前の記事では多要素認証の例として、ワンタイムパスワードやSMS認証を挙げました。
それ以外にも、インターネットバンキングでは俗に「電子証明書」と呼ばれているようですが「クライアント証明書」というものがあり、これも多要素認証です。

クライアント証明書とは、分かりやすく言うと、皆さまが使うWebシステムに対して示す身分証のようなものです。
インターネットバンキングで言えば、その証明書に、証明書の発行者(金融機関）や所有者（皆さま）、有効期限、また暗号化キーなどの情報が登録されているので、まさに身分証です。

以前に認証の3要素のお話をしましたが、クライアント証明書は
「自分しか持っていないものを見せることによって認証する」
であり、インターネットバンキングでは、この証明書がインストールされたパソコンでしか、取引することはできません。

このように、ID/パスワード+それ以外の要素を組み込んで認証するのが多要素認証です。

少なくとも、お金に関わる取引をWebサイトで行う場合には、多要素認証が提供されたWebサイトを使うことを強く推奨します。

もう、インターネットバンキングでは、多要素認証が提供されていない銀行はないと思いますが（全て調べたわけではありません）、会社の備品等の注文などで、口座やクレジット番号を登録する必要がある場合には多要素認証が提供されていることを確認してください。

もし、多要素認証が提供されていないWebサイトでお取引せざるを得ない場合には、口座引落や、クレジット引落のための登録などは極力避け、振込もしくは代引き等で決済されることをお勧めします。

また、お金が伴わない仕事であっても、お客さまの個人情報等を預けているクラウドなどの場合には、多要素認証が提供されているシステムを選ぶべきだと考えます。

結局、上記3点をクリアしていないWebシステムは、総じて「セキュリティに対する構え」が甘いのです。

従って、皆さまにおかれては、Webサイト利用にあたっては、「会社を守る」という観点で、最低でも、この3点にご留意頂きたいと思います。

それでは、次回もまた、よろしくお願い申し上げます。