MIXI DEVELOPERS
😎

闇バイト強盗の事案からオンラインサービスの認証強化について考えた話

2024/12/05に公開

ritou です。

MIXI DEVELOPERS Advent Calendar 2024 12/3の記事です(書くのだいぶ遅れましたすみません)

https://qiita.com/advent-calendar/2024/mixi

最近は社内のサービスから利用されるID管理機能を担当しています。

当然ながら、

  • 単一サービスにおけるID管理機能
  • 複数サービスが利用するID基盤が提供する機能

というのは求められる要件も変わります。

どのサービスにも求められる機能もあれば、特定のサービスのみに求められる機能もあります。あることを実現したいとなったときにID基盤がどの機能をどの形で提供するのかというのをよく考えながらやってますよーという話を、今年の春ぐらいに弊社主催のカンファレンスで(諸事情により録画でしたが)ざっくりとお話ししました。

https://speakerdeck.com/ritou/mixi-mtoshe-nei-wai-nosabisuwozhi-eruren-zheng-ji-pan-wozuo-rutameniyatutekitakoto-number-mtdc2024

今回は、少し解釈を広げて他サービスへの影響まで考えたID管理機能の設計について考えてみます。
業務で何かに取り組んだという話ではなく、色々考えている中でこんな考えもあるかなという話です。

認証強化の導入パターン

今回は、最近ホットな話題であるパスキーのような認証強化の導入パターンに注目します。

  1. サービス全体の保護: つまりログイン機能に導入
  2. 特定機能の保護: 重要な機能のみに導入

1はそのままです。ID基盤となると、利用する複数サービス全体を保護することになります。

2は決済などで外部からこうやれと制約が入るとか、同一サービスの他の機能やID基盤を利用する他サービスへの影響を抑えつつ特定機能を保護したい、などの目的で使われるパターンです。

実際は、この適用範囲と「任意のユーザーへの適用なのか全ユーザーに適用するのか」といったところが組み合わせられて最終的な導入形態が決まることが一般的かと思います。ID基盤がやる気出して1をやっていけるようなら最も健全ですが、実際は大体がネガディブな話(この機能がやられて怒られが発生した、金が絡むのでここだけはなんとかしないといけない)から始まることが多く、2が選択されることもあるでしょう。

このような「認証強化の適用範囲として特にお金の入出金、サービスにクリティカルに影響を与える機能に対して部分的な導入パターンが選ばれることが多い」という状況について、別の観点を入れていくと今後は認識を改める必要があるかも?という話です。

ユーザー情報、そのリストの価値を意識する

今回の話を考えるきっかけとなったのは、少し前から話題になっていた闇バイト強盗です。
ニュースなどをみたことある方はご存知でしょうけれども、関東近辺の高齢の戸建て持ちのお金持ちが多いようです。関東に住んではいませんが、正規の警察の方が闇バイト強盗とか特殊詐欺に気をつけてくださいって言って回って来たので、他人事ではないですね。

犯人側ではなく、被害者側に注目します。どうしてこのような人たちが狙われたのかというところで、次のような流れがあるようです。

  1. 闇バイト強盗や特殊詐欺のターゲットとなりうるリストが存在(普通の人->情報屋->名簿屋->悪そな奴らと情報が流れていく)
  2. そのリストには基本的な情報 + 資産価値などの情報が加えられている
  3. このリストの情報は一般企業、知り合いなどいろいろなところから上がってきたものと、アポ電や業者を装った訪問みたいなので補完された結果、強盗に行けるかどうかの判断がされる

参考URL:

https://president.jp/articles/-/87661?page=1

https://www.alsok.co.jp/person/recommend/2237/

https://www.tokyu-security.co.jp/column/security/3/

この辺りの状況をID管理の観点で見ていくと

  • いろんなところから名寄せで集めた情報からリストが作られる: 名寄せ対策は重要だが完全に防げる話ではない
  • 犯罪の最終判断に使われる情報収集は今はオフライン攻撃: 今後はオンラインになっていく可能性はあるし、今あまり使われていないということは伸び代があるということ
  • クリティカルな入出金部分以外の情報も重要な価値を生み出す: 資産状況確認機能みたいなところも保護対象としなければいけない

といった考察ができます。

なんだかんだで今はオフラインでの活動が中心ですが、将来的にターゲットの年齢が下がったり、タンス預金から金融機関に預けましょう、窓口の確認しっかりやりますよとなると「オンラインサービスのユーザー情報のリストの価値が高まること」は明白です。そして、そのリストを構成するのが単一のサービスのものではなく、複数サービスから取得した情報の組み合わせであることも意識すべきです。

ここまでは良い、を改める必要性

認証強化の導入パターンの話に戻ります。前述の通り、今後は複数サービスから取得したユーザー情報のリストの価値が上がると考えられます。

金融系サービスでログインにパスワード認証を利用しつつ入出金などはMFAで守る実装をしている場合、パスワード認証を突破されて不正ログインされたら残高情報や取引履歴はわかります。最終的にお金が取られないなら問題ないとこれまで認証強化の対象から外れていた機能、つまりREAD Onlyの権限でできる部分も、別で作られたリストと組み合わせると価値を生み出す可能性があります。収入がこれだけあるとか、大金を振込ではなく引き出した形跡があるなら手元にあるかもとか、証券系のサービスだったら財産とイコールと見なせる場合もあるでしょう。たとえお金を引き出せなくても、既にあるリストに箔をつける意味では十分なのです。

この手の話でサービス全体を守るべき話で言うと、例えば大人のサービスを利用していることがバレるとプライバシーの問題になるよと言う話がありました。まぁそれも大変ではありますが、この先は他の情報と組み合わせられることで命を狙われるかどうかの判断材料に使われる となると捉え方を変える必要があるでしょう。なるべくアカウントにログインする時点から認証強化し、幅広い情報を守る方向性でいきましょうとする方が健全だと思います。

まとめと、いうかいつもの話

以前から、この手の話には「あるメールアドレスがサービス登録されているかを誰にでも教えてはいけないんじゃないか」という、いわゆるユーザースキャンの是非について主張してきました。

https://qiita.com/ritou/items/00990e00151fad46df1a

これまでは「そうは言うても利便性捨てがたいよな」「Googleもやっとるしそんなにこだわるものかな」みたいな反応が多かったものてすが、最近はリスク判断が必要な仕様として認識されることも増えているようで「これは良くない」「指摘する人はいないのかな」という反応も増えてきました。

その前で言うとパスワードを平文(若干曖昧な表現)でやり取りするサービスがあったわけですが、ある時点では受け入れられていた仕様も時間が経って周囲の状況と共に変化することがあり得ます。その状況に応じて認識を更新しながら、自サービスだけではなく他サービス含めたエコシステムとしての安全性を意識していきたいところです。

以上、おつかれさまでした。

MIXI DEVELOPERS
MIXI DEVELOPERS

Discussion