お金にまつわる話し

Page content

今回のネタは、これまでとちょっと違った毛色のネタである。

ネタの背景

日本人あるあるだと思うが、 これまでほとんど 「お金を運用する」 ということを やってこなかった。

何となく「運用ってのは金持ちのすること」みたいな感覚があったし、 はっきり言って 「お金のリテラシー」 が低かった。

なお、「ほとんど」と付けている通り、全く経験がない訳ではない。 実は 10 数年前にデビューしていたりする。 ただ、そのデビューしたタイミングがアレだったのが、運が悪かったと言えるだろう。 デビューがもうすこし遅ければ、 今頃は精神的にも金銭的にも、少しは楽になっていたかもしれない。

10 数年前と言えばピンと来る人もいると思うが、 具体的にはいわゆる リーマンショック の起きた年だ。 リーマンショックが起きる数ヶ月前に始め、 モロに 「お金の運用の洗礼」 を受けている。

そんな訳で、リーマンショックで精神的なダメージを受け、 「自分には運用は合わないな」と感じて今に至る。

まぁ、何だかんだ塩漬けにしまくって、最終的にはプラスになったんだけど、 それでもデビュー時に受けたそのショックは、 運用に対するモチベーションを下げるには十分過ぎた。

そんな訳でもう何年も運用からは手を引いていたのだが、

  • 近年の物価上昇による相対的な現金(日本円)の価値の下落
  • もうそろそろ引退後のことを考え始めないといけない年齢

の合せ技で、「お金の運用」について真面目に考えるようになった。

最近はネット上でお金の運用に関するそれなりにまともな情報も 入手できるようになってきていて、勉強するには困らない。 もちろん、そういった情報はポジショントークが入っているのは認識している。

「リーマンショックを経験していること」 は、 そういう意味で役立っていると思う。

集めた情報で改めて運用の勉強を独学で進めつつ、 今回は銀行、保険屋、FP(ファイナンシャルプランナー) と相談してみた。

なお、今回いろいろとお金の運用に関する情報を仕入れたが、 まだまだ完全に門外漢なレベルでしかないので、ここでは運用方法に関しては触れない。

じゃぁ、なんの話をするのか？と言うと、セキュリティの話である。

念の為に断っておくと、 自分はセキュリティを専攻していないということを前提に、以降を読んで欲しい。 セキュリティには、片足の先っちょを突っこんでいる程度だ。 あくまで単なるブログのネタである。

何のセキュリティ？

セキュリティと言ってもさまざまだが、 今回は次について考える。

「お金の運用を相談する相手が、悪意ある第三者でないことがどうやって担保されているか？」

もう少し具体的に言うと、 今回の運用に関する相談は、実店舗に行って対面で行なったのではなく、 「オンライン相談」 というものを使ってみたのだが、

  • その相談相手が本当に相談するべき相手なのか？
  • オンラインであることを悪用した悪意ある第三者ではないのか？
  • こちらが想定している相談相手であることをどうやって担保しているのか？

ということを考える。

○×銀行の場合

今回相談した○×銀行では、公式 HP からオンライン相談を予約できる。

銀行がオンラインでの振込などが出来る独自のサービスを提供するようになって久しいが、 このオンライン相談はそのサービスのアカウントとは連動せずに、 誰でも予約することが出来るようになっている。

個人的には、そのアカウントと連動した方がセキュリティ的に良い気がするんだが、 そうすると間口を広げたいという銀行側の意図から外れるから、 あえてしていないのではないかと想像する。

相談の予約をオンラインですると、以下の手順で担当者とリモートで相談することになる。

  1. 銀行側からメールで予約日時の確認メールが来る
  2. 予約日時になると、担当者から電話がくる
  3. 担当者から公式 HP にあるオンライン相談の接続番号発行操作を促される
  4. 手順に従って発番する
  5. 番号を電話の相手に伝える
  6. オンラインの Web 会議が繋る
  7. オンラインで説明を受ける
  8. 次回以降は電話での対話だけで、オンラインは繋がない
  9. 電話は 0120 から始まる常に同じ番号、同じ担当から掛ってくる

手順としては以上である。

うーん、大丈夫なんだろうか？本当にこれでしっかりと担保されているんだろうか？ ちょっと考えてみる。

ここで重要なことは、 「電話の相手が正式な銀行員に間違いないかどうか？」 だ。

電話が掛ってくるのは 2) である。 この 2) の段階では、まだ相手が正式な銀行員だという保証はない。

次の 3) では「公式 HP」の発番システムを使っているので、 これ自体は問題ないだろう。

公式 HP は当然 https であり、その証明書も問題ない。

なお、ここでは以下については スコープ外とする。

  • 公式 HP がクラックされて HP が書き換えられている
  • 証明書の認証局がクラックされている
  • うちの PC の CA 証明書、 DNS がクラックされている
  • うちのブラウザがクラックされている

これらが否定されると、オンライン自体がもう信用ならないので考えない。

次に 4) で発番する。これもクラックされていないことが前提であれば問題ない。

次の 5) で、発番された番号を電話の相手に伝え、 次の 6) で Web 会議が繋がる。

ここで疑問が浮ぶ。

  • はたしてこの番号は何なのか？
  • この番号を相手に伝えて大丈夫なのか？

たとえば、これが単なる電話番号のようなものだとしたら、 それを相手に伝えてしまえば、誰でもこちらと繋ぐことが出来てしまう。 つまり、相手が正式な銀行員である保証はない。

ここが、 このオンライン相談システムの肝だ。

ということで、 5), 6) がどのように実現されているかを考えてみる。

公式 HP サーバ内に閉じたシステムで実現されている場合

まず最も単純なのが、 このシステムが○×銀行の公式 HP サーバ内に閉じたシステムで実現されている場合だ。

これによって、任意の番号に繋ぐ権限を持つ人を ○×銀行内の人間に制限することが出来る。 たとえ第三者がその番号を知っても、その番号で相手に掛けられなければどうにもできない。

もちろん、 このシステムがそういう制限をしていることが前提 だが、 ここでは当然制限していると考える。 仮に制限していないとしたら、ヤバ過ぎる。。。

以上のように 3) 〜 6) の手順によって、 相手が○×銀行内の人間であることが担保される。

実は、このオンライン相談では、通話に関しては Web 会議ではなく常に電話を使う。

手順の 8) にあるように、次回以降は Web 会議つなげることすらない。

「Web 会議があるのに電話なのか」と心の中で思ったが、 Web 会議に繋げたのは、 電話を掛けてきた担当者の身元保証に利用している のがメインのようである。

もちろん「映像を見せながら金融商品について説明する」ことにも利用しているが、 どちらかというと前者の方が重要だろう。

それに、毎回 Web 会議に繋げなくても電話だけで相談できる、 というのは顧客にとってもメリットなのだろう。

また 9) にあるように、次回以降の電話は同じ電話番号&同じ担当なので、 一度身元の保証できているので、その手順を省いても大丈夫ということだろう。 0120 の番号から電話掛って来ているので、 その電話番号から掛っている限りは、 「いつの間にか担当者が銀行を止めていた」ということもない。

なお、以上の身元保証のことに関しての説明などは、当然ながら無い。

Web 会議システムが公式 HP サーバ外で実現されている場合

実は、この Web 会議システムは公式 HP サーバ内に閉じたシステムではなく、 別の会社が運営しているサービスだったりする。

具体的には、ベルフェイス株式会社が提供する「bellFace」というシステムだ。

よって、先程考えたような単純なケースではない。

じゃぁ、bellFace ってなんやねん。ってことになる。

<https://bell-face.com/>

HP を見ると、どうやら主に金融会社向けの電話面談システムを扱うシステムのようだ。

トップページにメジャーな金融会社のロゴを多く掲げているので、 その業界では実績があるツールなのだろう。

まぁ、それは置いておいて、問題はセキュリティが担保されるかどうか？だ。

全般的なセキュリティに関しては、次の URL で確認できる。

<https://corp.bell-face.com/security/>

こういうサービスをやっているので、 セキュリティに関する情報を公開するのは当然なのだろう。

このページに 「接続元 IP アドレス制限」 がある。

説明は、以下の通り。

「bellFaceへ接続するIPアドレスを制限できます。また、制限はご契約単位で設定できます。」

言っていることは、極普通だ。

ただ、具体的に何をどう制限するかは良く分からない。

常識的に考えれば 任意の番号に掛けられる端末のIPアドレスを限定する 、 いうことだろう。

さらに、それだけではなく、 ある金融機関向けに発番された番号に対し、別の金融機関から接続する 、 なんてことも出来ないように制限されているはずだ。

ここで、もう少し具体的に実現方法を想像してみる。

○×銀行の発番システムへのアクセスは、以下のリンクにアクセスすることになる。

https://user.bell-face.com/client/container/common?&pl=https%3A//user.bell-face.com/client/slide_entry/common&w=AAAA&h=BBB&logo_site_key=aaaaaaaaaa

上記にアクセスすると、Web 会議接続用の発番が出来る。

そして、その番号を相手に伝えると、 このページを介して相手との Web 会議がつながる。

なお、 ベルフェイス株式会社の bellFace のサービス案内 HP からも、 この発番システムへアクセスできる。

その時の URL は以下だ。

https://user.bell-face.com/client/container/common?&pl=https%3A//user.bell-face.com/client/slide_entry/common&w=BBBB&h=CCCCC

この 2 つの URL を見ると分かる通り、以下のクエリーが異なるだけだ。

  • w
  • h
  • logo_site_key

このクエリーによって、契約を切り替えているということなんだろう。

セキィリティにはあまり関係ないが、 このシステムで発番すると金融機関のロゴが表示される。 logo_site_key パラメータはその名前から想像するに、 表示する金融機関のロゴを指定する ID だと思われる。

○×銀行のまとめ

いくつか運用面で条件はあるが、 それらはセキュリティを考える上で実施しないとヤバいレベルの内容なので 実施しているだろう。 ということで、セキュリティは担保されている」という判断である。

なお、 「どうして Web 会議を使わずに電話を使うのか？」に対し、 電話だけで相談できる方が顧客のメリットになる、という話をしたが、 ○×銀行側の bell-face への課金を減らす意味もあるのかなぁ？と思ったりもする。

ただし、bell-face の料金設定が分からないので、あくまで想像でしかない。

追記

発信者の電話番号についてだが、 発信者IDスプーフィングによって発信者の電話番号を偽装することが可能らしい。

この「発信者IDスプーフィング」のハードルがどの程度のものかは不明である。 ただ、少なくとも誰でも出来るレベルのものではない、ということらしいので、 ここでは一旦スコープ外とする。

なお、発信者IDスプーフィングで発信者の電話番号偽装が出来てしまうと、 以下については全く保証が出来ない ということになる。

また 9) にあるように、次回以降の電話は同じ電話番号&同じ担当なので、
一度身元の保証できているので、その手順を省いても大丈夫ということだろう。
0120 の番号から電話掛って来ているので、
その電話番号から掛っている限りは、
「いつの間にか担当者が銀行を止めていた」ということもない。

身元を保証するには、毎度 4) からやり直す必要がある。

△○保険の場合

次に△○保険の場合だが、これは銀行のケースと比べて単純だ。

具体的な手順は以下。

  1. 保険屋からメールで web 会議システムへの URL が通知される
  2. URL にアクセスして web 会議システムに接続する
  3. この web 会議システム内で担当者と話す

ここで Web 会議システムの URL は、保険屋の独自ドメインである。

この会議システムの URL へのアクセスを次のように制限することで、 セキュリティが担保できる。

  • アクセスできる IP アドレスを保険屋が管理する IP アドレスに限定する
  • ただし、保険屋が管理する IP アドレス以外からもアクセス可能にする。
  • 保険屋が管理する IP アドレス以外からアクセスされた場合は、 先着 1 アクセスに限定し、識別するためにトークンを発行する。
  • 以降のアクセスで、このトークンが付加されていないアクセスは拒否する

なお△○保険の場合は、○×銀行とは異なり常にこの Web 会議に繋げて相談をする。

FP の場合

FP はオンラインではなく、家の近くでの対面だった。

名刺をもらったが、その名刺が本人のものかどうか？を確認する手段がない。

対面なら大丈夫か？という気がしなくもないが、 全くの別人が成りすましている可能性もある。

ある意味、セキュリティ上一番問題があるかもしれない。。。

まとめ

実は face to face が一番危険かもしれない、という結果になった。 そう考えるのはオレだけだろうか？

なお、個人的には金融機関の Web サービスは、 自ドメインだけで実現する方が良いと考えている。 他ドメインがあればあるだけ、リスクが大きくなる。

OSS を使うな、と言っているのではない。 OSS を自ドメインでホストすれば良いだけだ。

なにはともわれ、 運用がうまくいくと良いなぁ。 (これが言いたいだけ)