LINE Engineering
Blog

LINE Engineer Insights vol.5「セキュリティ室シニアエンジニアに聞く、LINEのスパム対策と今後の展望」

LINE Engineering Blog 2017.07.06

LINE で働くエンジニアに色々と話を聞いていく「LINE Engineer Insights」の第5弾です。当コーナーはインタビュアーに LINE で働くエンジニア @tokuhirom を迎え、エンジニア同士でざっくばらんにお話を伺っていくというものです。今回も、LINE のエンジニアは一体どんな人達なのか、その内面に迫っていきたいと思います。
第5弾はセキュリティ室 アプリケーションセキュリティチーム所属の石田暁久に、LINEのスパム対策やセキュリティのツール開発などについて聞いてきました。

LINEのセキュリティチームはどんなチーム?

―― tokuhirom
宜しくお願いします。最初に、入社時期と現在メインでやってらっしゃる仕事を聞かせていただけますか?

―― 石田
入社は2011年の10月なので今年で6年目です。セキュリティ室のアプリケーションセキュリティチームに所属していて、主にスパム対応と各種Abusing対応をやっています。
編集部注:Abusing とは不正行為のこと。LINE上で行われる無意味なメッセージ送信や、スタンプを大量に送ったりアカウントを乗っ取る目的で他ユーザーにコンタクトをとるといった行為などを指します。

―― tokuhirom
アプリケーションセキュリティチームはどういった構成なんでしょうか?

―― 石田
構成としては大きく4つです。リスクアセスメントと呼ばれるリリース前の脆弱性診断をやるパート、企画段階からセキュリティチェックを行うコンサルティングパート、ゲームのセキュリティやAbusing対策をするパート、LINEアプリに関するスパムやAbusingなどの対応をするパート、となります。ただ、それぞれのパートに名前がついているのではなく、アプリケーションセキュリティチームの中で大まかに役割が分かれている感じです。後は兼任で bug bounty の運営や最新のセキュリティ技術を研究する業務もあります。

―― tokuhirom
どういうバックグラウンドを持っている方達がいらっしゃるんでしょうか。

―― 石田
中途だとセキュリティ系の会社や部署で働いていたエンジニアの方が多いですね。新卒で入社された方などは元々セキュリティ関連の研究を学校でやっていたという方が多いですが、全く関係ないところから入ってきた人もいてわりとユニークなメンバーが多い印象です。例えば、東大の大学院を卒業して流体力学のシミュレーションを研究テーマにしていたんですが、セキュリティに興味があってLINEでアルバイトをしているうちにセキュリティ室の室長である林マンギさんに見込まれてそのまま入社された方もいます。今もすごく活躍されていてUnity Metadata Loaderというセキュリティツールを作ったり、AVTOKYO JPというイベントでトークしていたりします。

私の場合は新卒でセキュリティ専門会社に入ってそこに6年くらいいたんですけど、そこでサーバーやネットワークを対象とした脆弱性診断を主にやっていたんですが、時代の流れで少しずつWebアプリケーションの脆弱性診断の方が比重が大きくなっていました。私は当時Webアプリケーションを開発した経験がなく、Webアプリケーションの脆弱性診断をやるためにはまず開発の経験が必要という考えがあったんです。それで、セキュリティの専門会社だけどSIの部署もあったので「開発の経験も積ませてほしい」と言って開発をやらせてもらっていたらそっちの方が面白くなっちゃって。

新卒で入社したその会社を辞めてからいくつかのSIerを経て、開発をしながら個人的にセキュリティの勉強も続けていたらある時セキュリティに詳しい開発エンジニアって貴重だよねって言われて、それならセキュリティをもう少し伸ばしていきたいなと思うようになりました。そんな時にLINEの前身である当時の NHN Japan では、開発もできてセキュリティもできる人材を募集していたので応募して入社したという経緯です。

―― tokuhirom
LINEのセキュリティチームって、ゲームの Abusing する人しかいなかった状況からかなり変わってきたんでしょうか?以前はゲームの脆弱性診断しかやっていなかったイメージがありますけども。

―― 石田
たしかに4年くらい前のタイミングではゲームのリリースが続いたのでゲームの診断を多くやっていましたけど、基本的には以前からほぼ全てのLINEサービスをセキュリティチームが診断しています。ただゲームの診断業務が多かったのはその通りなので、業務内容の比率が変わったといった感じだと思います。

LINEのトークルームに対するスパム対策手法

―― tokuhirom
ここからは LINE のスパム対策についてお伺いしたいんですが、スパム対応というのは具体的にどういった手法で行われているんですか?

―― 石田
LINEでチャットメッセージをやり取りしているトークルームで発生するスパム対策については Rule based Filtering と Machine Learning based Filtering を組み合わせた手法で行っています。スパマーの行動や通報内容を分析して特徴を抽出し、ブロックします。

―― tokuhirom
一番気になるのは、トークルームって人同士のやりとりの場合は内容が見えないと思うのですが、その中でどうやってスパマーを判定しているんですか?
編集部注:LINE上でやりとりされるデータは電気通信事業法における「通信の秘密」に該当し、エンドツーエンドの暗号化の適用等、LINE社員であってもユーザー同士のチャットメッセージのやり取りは見ることが出来ないような対策を施しています。通信の秘密などに関してはこちら、エンドツーエンド暗号化については以下のエントリをご覧ください。
メッセージの安全性新時代:Letter Sealing
メッセージの安全性のさらなる強化:Letter Sealingの適用拡大


―― 石田
メッセージ内容が見えなくても対策法はいくつかあって、単純なフィルタリングルールだと例えば「短時間に大量のメッセージを送ったらブロックする」というものがあるんですけど、他にも「スパマーと受け取るユーザーとのソーシャルな関係」を見て、あまりにも遠い関係なのにいきなりメッセージを送ってきた場合はスパマーと判断される材料になることもあります。

スパマーはほとんど自動化してスパムを送ってきているので、例えばデバイスにAndroidのエミュレーターを使っていたり、設定するディスプレイネームがわかりやすかったり、特徴があるんですよね。そういった特徴を拾ってフィルタリングルールを適用しています。通報機能によりスパムを受信したユーザーからスパムメッセージ内容を当社に送信していただいた場合にはメッセージ内容を確認できますので、通報メッセージに対してはテキストマイニングで、通報イメージについては TensorFlow を使ってディープラーニングで似た画像を引っ掛けてブロックしたり、機械学習で情報を蓄積していったりということをやっています。そして通報されたものの中で、これらのフィルタリングルールに引っかからなかったものに関しては、LINE Fukuoka の監視パートが Monitoring System を利用して対応されます
スパマーをブロックするシステム・アーキテクチャの概略図

スパムの画像をどのようにフィルタリングするか

―― tokuhirom
画像の中身も、通報されればLINE側でフィルタリング可能ということなんですか?

―― 石田
通報されたものに関しては可能ですね。
これはセキュリティチームの愛甲さんがやっている部分なんですけど、スパマーが送ってる画像というのが決まってるというか、ほとんど同じようなものをいつも送るんですね。ですので、その画像をまず登録しておいて、それと似たようなものをディープラーニングを使って取って来る。そして似ている画像だったらスパマーと判定するというような形でやっています。通報されていないものに関してはメッセージと同様に内容が確認できないため、このような対策は行えません。
編集部注:愛甲さんは LINE のセキュリティ室所属のエンジニア。SPAM対策やリリース前の製品(Webアプリ、ゲームなど)のセキュリティ診断が主な業務。

―― tokuhirom
機械学習ベースで通報内容をフィルタリングするのと、あとはソーシャルグラフなどでやっていると。さらにはデバイスにAndroidのエミュレーターを使っていたり、設定されたディスプレイネームをベースに通報前の内容に対してフィルタリングを行っているということですか?

―― 石田
はい、あとは通報件数、ブロック率、友だちの人数といった情報も見てますね。もちろんそれだけでは false positive(誤検知)が出てしまうので、最終的には色々なルールと組み合わせてブロックするかどうかを判断しています。

スパム通報の意外な内訳、スパマーの本店支店説

―― tokuhirom
実際にユーザーから通報されるケースは多いんですか?

―― 石田
多いですね。通報件数の約30%は日本のユーザが通報しています。その内約20%はスパム通報なんですが、残りの10%はスパムではない通報です。日本の場合はこのスパムではない通報の割合が特に多いです。

―― tokuhirom
それは結構な割合ですね。「こいつムカつくから通報しちゃおう」みたいな感じなんですかね。

―― 石田
おそらくそうだと思います。割りとカジュアルに通報する印象がありますね。

―― tokuhirom
スパムの内容は日本以外だと内容が違ったりするんですか?

―― 石田
日本のユーザーと台湾のユーザーを狙ったスパマーが昔から多いんですが、国によって傾向も違いますね。日本のユーザーを狙ったものは出会い系サイトへの誘導がほとんどで、台湾は偽ブランドへの誘導とか車のローン融資、学習教材を売りつけるような広告スパムの内容が多いです。

例えば台湾ですと、何も対応をしていないのに急に通報件数が下がることがあって現地の方に話を聞いてみたら「今日はドラゴンボートフェスティバルという祝日でお休みなんですよ」というような話があって。そういえば過去の事例を見ると土日は通報が少ないなと思い当たって、台湾の場合は土日祝日はスパムも休むんだなということがわかりました。でも日本をターゲットにしたスパマーは土日もやっていたりして。「真面目か」みたいな(笑)

私の経験則でいうと、スパムの件数は日本が下がると台湾が上がって、日本が上がると台湾が下がるんですよ。なんか相関関係があるみたいなんですよね。これは想像なんですけど、スパマーの台湾本店と日本支店みたいなのがあって共通のノルマをクリアしないといけないので台湾が下がっても日本は上がったりするのかなと。色々と想像してみているんですが真相はわかりません。

―― tokuhirom
スパム対策をしていく上で、スパムとしてブロックできている件数と配信されてしまっている件数の割合はデータとしてあったりしますか?

―― 石田
スパムとしてブロックできている件数は把握していますが配信されてしまっている件数を正確に出すのは難しいですね。代わりにグローバルの通報件数ベースでKPIを設定しています。

―― tokuhirom
スパムじゃない通報も多いですよね。それで通報件数をKPIにされると結構しんどいのでは?

―― 石田
結構しんどいです(笑)。2014年のKPIが「グローバルの通報件数を10%以下にする」となっていました。なかなか厳しい目標でしたけど、様々な対策を施した結果何とか10%以下にできた期間もありました。スパム対策を本格的に開始したのが2013年後半ですが、今はその当時のグローバル通報件数の15%以下を安定して維持しています。
通報された件数が多いエリア別分布図

トークルーム以外でのスパム対策状況

―― tokuhirom
最近、LINEの友だち追加のところに「電話番号で友だち追加されました」でスパムっぽいアカウントが出てる時があるんですけど、こういうのって対策してるんですか?

―― 石田
例えば、電話番号での友だち追加を大量に行ったらブロックするなど様々な対策をしています。昔は「短時間に大量に友だち追加して短時間にスパムを送ったらそのアカウント捨ててはい次」みたいなスパマーの行動が多かったんですけど、最近はランダムな時間に少人数を友だち追加したり、スパムメッセージを数回しか送信しなくなったのでフィルターには引っかかりにくくなってしまいました。1アカウントでのスパムメッセージの送信件数が少なくなった事は私たちの対応の成果といってもいいかなという気がしていますが、イタチごっこですね。

―― tokuhirom
CAPTCHA をすごい入れるとか、登録フローを面倒くさくするみたいなことをしていくしかないけどユーザビリティにも影響するから悩ましいですよね。タイムラインのスパム対策はどうですか?

―― 石田
はい、実は6月から私もタイムラインスパム対策に関わるようになりまして、今ちょうど現状把握をしているところです。私たちの方でトークルームはかなりブロックしてたのでスパマーが最近あまり力を入れてこないなと思ってたんですけど、どうやらタイムラインの方に活動範囲を変えていたのがわかりました。私たちが持っているトークルームでのスパム対策のナレッジを活用してタイムラインの方も対策をやりましょうという感じで進んでいます。具体的なタイムラインスパマーの行動としては、公開ポストに対してスパムのコメントをつけて、さらにその人に対して mention を設定することでその人にスパム広告を気づかせるというパターンが多いようです。

―― tokuhirom
それはなかなか対応しづらいですね。

―― 石田
そうなんです。まずは現状の把握とスパマーの行動分析を最優先で行い、簡単にできる対策から始めています。


ユーザビリティとスパム対策のバランス

―― tokuhirom
トークルームの対策に比べると既にあるノウハウで何とかできそうな感じもしますけどね。

―― 石田
既存のノウハウでの対策も検討していますが、まず実施した対策としてはトークルーム側でメッセージ送信をブロックしていたスパマーをタイムライン投稿できないように一括でブロックしました。そうしたらだいぶ効果があったようでスパムの件数も減少しました。

―― tokuhirom
使いまわしてたんですね。一般的なブログとかのスパムと同じで、URLが入ってたら CAPTCHA を入れないとコメントできないとか、友達じゃなかったら CAPTCHA を入れないとダメとかそういう感じですよね。こちらとしてはオープンにやり取りして楽しんで欲しいのに、スパムが起因でダメってなっちゃうと厳しいですよね。

―― 石田
そうなんですよね。オープンなコニュニケーションの場として活用してほしいので CAPTCHA とかを入れてユーザビリティを下げるような対策は避けたいんですが…。とても悩ましいです。

―― tokuhirom
友だちの友だちの範囲くらいまでじゃないとコメントつける時には CAPTCHA が必要、くらいは許容範囲のような気がしますけど。今後はタイムラインチームと連携してタイムラインのセキュリティもやっていくということですか?

―― 石田
そうですね。室長の構想ではスパムに限らずAbusing対策の専門パートみたいなのを作って、今まで貯めてきたノウハウを横展開していこうという狙いがあるみたいです。

―― tokuhirom
そもそも Abusing のスパム対策をやってる部署がセキュリティ部門にいるということを社内でも知らない人が多そうですよね。セキュリティの部署って主にニコライさんみたいな人が外向けに結構出てますけど、スパム対策となるとスパマーに対策を知られることになるので、社外で発表するわけにもいかないですからね。なので社内の勉強会でそういったことを共有するといったことを積極的にやっていってもよいかもしれません。
編集部注:ニコライさんは LINE のセキュリティ室所属のエンジニア。新しいサービス、機能のセキュリティ設計、コンサルティングとリリース前のリスク評価に関わっている。外部講演など多数。

―― 石田
社内限定で開催されているエンジニア向け勉強会 Tech Talk というがあって、Anti-spam/abusing というテーマで話をしました。スパムやAbusingに対してどのような対策をしているのか、サービス担当者が気をつけなければいけないことはどんなことかといったことを共有したんですが、なかなか評判がよかったので次回も何かやりたいなと思っています。


スピード感を求められるLINEの開発現場で運用フローを作り上げる

―― tokuhirom
石田さんが LINE でスパム対策やAbusing対策のを担当するようになった経緯を教えてもらえますか?

―― 石田
今のタイムラインの状況と同じだと思うんですけど、LINEが沢山の方に使っていただけるようになった一方でトークルームの方でスパムが発生していて「なんとかしろ」と指令が出ていて、細かい経緯は覚えていないんですけど色々と発言していたら巻き込まれていって、いつのまにか専任になったという感じで今に至ります。

当時は今のような分析環境もないし、調査したいけどデータがどこにあるかわからない、担当者が誰かもわからないで、本当に手探りの状態だった上にうちの会社ってスピード感がすごく求められるので苦労しましたね。とにかく関係しそうな人にいきなり「こんにちは、石田と言います。スパム対策をやっているんですけど、このデータはどこにありますか?」とかLINEで聞きまくりました。そんな事を繰り返しやっていたら自然と周りの人が色々助けてくれるようになって。スパマーの分析内容とか対策案についてLINE上で半日ぐらい議論して、この対策はイケそうだとなったら関係各部署と調整して2,3日後にはリリース。その後効果測定をして結果しだいでまた次の対策を考えるみたいな運用フローを作り上げました。

―― tokuhirom
結構短期間の話ですよね。

―― 石田
はい。いつもそんなスピードで進行できるとはかぎらないんですけどもだいたいそんな感じです。あとスピードを阻害する要因として「リソースがない」って言われることがあります。でもリソースが空くまで待ってられない時もあるので、そういう時はSIerでの経験を活かして可能な範囲で自分で開発しています。例えば、スパムの分析システムなどは自作していますね。

―― tokuhirom
SIでの経験が強みになってるんですね。同じチームの中では開発メインというよりセキュリティメインでやってきた人が多いんですか?

―― 石田
そうですね。どちらかといえばセキュリティメインでやってきた方の方が多いと思いますね。

―― tokuhirom
この会社は結構、自分でガンガン他のチームの人と調整してやっていかないとなかなか成果が出せないような気がします。

―― 石田
その通りですね。実は初めはそのやり方がうまくできなかったんですが、スパム対策をやり始めてから完全に吹っ切れました(笑)。吹っ切れてしまえば、あとは自分からどんどん話しかけて他のチームと調整しながらスピード感をもって進行できるようになったと思います。このスタイルに慣れてしまうと逆に「このやり方じゃないと遅すぎて無理」と感じるようになりました。

―― tokuhirom
そのスパム対策のシステムというかフローが出来上がるまでどれくらいの期間かかったんですか?

―― 石田
常に改善していくので期間というと難しいのですが、フローの原型みたいなのは1-2ヶ月ぐらいで出来上がったと思います。今とほぼ同様のフローが出来上がるまでには1年ぐらいかかりました。

分析環境としてのElastic Stack

―― tokuhirom
最近注目してる技術とかスパムの手法などはありますか?

―― 石田
技術と言えるかどうかわからないんですが、去年くらいから Elastic Stack を使って分析するようにしていて、ユーザーの属性を含む通報情報データを全部 Elasticsearch に放り込んで Kibana で可視化して分析して、その結果をフィルターに反映するっていうのをやっています。
Elasticsearch 2系の時はすごく重かったし Kibana の可視化機能もそんなによくなかったんですけど、5.4 がリリースされてから Kibana 上で Machine Learning の機能が使えるようになったので今それを試しているところです。Machine Learning の機能を活用して国別の通報件数で異常値を検知したら、LINE Notify経由でLINEに通知する仕組みも作りました。
―― tokuhirom
結構社内でも Elastic Stack の anomaly detection 使ってみてるっていう話はちょこちょこ聞きますね。 HipChat に #elastic みたいなチャンネルがあって話題が出てたりします。サービスメトリクスの anomaly detection 的な、異常値検知をやろうとしているんですけど、なかなかうまくいかないみたいです。

―― 石田
自分も試している段階ですが「どうしてこの時に異常値として検知されたんだろう」とかあって、まだ色々と探っている段階ですね。

―― tokuhirom
実装の詳細を聞いてなかったんですけど、普段開発は何の言語でやっているんですか?

―― 石田
Python が多いですね。

―― tokuhirom
最近 Python を使ってる人を募集してた時期がありましたね。PyConにスポンサーしようとしていて、誰か話をしてくれということを言っていて。結局 Python の BotSDK の話をしてもらうことで落ち着いたと思いますけど。セキュリティチームで Python を使っている人が特に多いというわけではないんですよね?

―― 石田
いいえ、割とセキュリティの人は Python を使ってちょっとしたツールを作るっていうのは多いですね。他の言語を使ってる人はあんまりみたことがないです。ただ、Pythonも使うというだけで、それぞれ得意な言語を別に持っているといった印象ですけれど。

―― tokuhirom
NLP とかマシンラーニングの人だと「Python はライブラリが充実してて便利」みたいな話があるじゃないですか。セキュリティの人だと使いやすいツールがあったり Python が他と違って使いやすい要因があったりするんですか?

―― 石田
詳しい理由は分かりませんが、セキュリティ関連の分析ツールの Plugin などは Python で書かれている(サポートされている)ことが多いです。脆弱性の実証コード(PoC)もPython製のものをよく見ますね。特別というわけではないですが、セキュリティ系の技術者はPython使いが多いかもしれません。

―― tokuhirom
多分観測してる範囲が違うからだと思いますけど、個人的には PoC を Python で作ってるのあまり見たことなかったです。HTTP系の PoC とかだと未だに Perl で書いてあるやつとかもあったりします。Slowloris のやつは確か Perl で書いてますね。って、Slowloris ってもう8年前ですね!! 最近は Python が多いんですねえ。

横断的なAnti-abusing専門組織設立と展望

―― tokuhirom
今はスパム対策のシステムは石田さん一人で開発しているんですか?

―― 石田
いえ、私が開発しているのは通報関連のシステムだけです。通報データの分析システムと統計システム、通報後のスパマー検知・ブロックシステム、監視システムとの通報データ連携システムなどになります。その他は様々な部署の開発担当者がいます。また開発以外にもスパム対策に関する様々な調整やデータ分析、各種問い合わせ・相談対応など業務範囲は多岐にわたりますので、どれくらいの人が関わっているかを正確に出すのは難しいですね。ただ、セキュリティ室でスパム対策をやっているのはほぼ私ひとりで、一部を愛甲さんに手伝ってもらっているといった感じです。

―― tokuhirom
画像スパムを検知する部分は愛甲さんに手伝ってもらっていると。

―― 石田
はい、通報イメージと通報メッセージからスパマーを検知する部分をお手伝いしてもらいました。今後はタイムラインも対象に入ってくるから二人だと無理っていうことで、他のパートからも人を入れてもらう予定です。今後もし横断的なAnti-abusing専門組織を作るなら人を増やさないと無理ですよね、という話は部署内でしています。

―― tokuhirom
社内の他の案件の話を聞いてると「Abusingは LINE Fukuoka の監視パートで全部見る、以上」みたいな感じが多いと感じますけど。

―― 石田
タイムラインのスパム対策も今はそうなんですよ。トークルームのスパム対策の場合は、なるべく機械的に自動でブロックして人間が見ないと難しいものだけを LINE Fukuoka の方で見てもらう対応をしていますので、そのような方向性に変えるように今まさに話し合って進めている状態ですね。

―― tokuhirom
サービスを開発する側の人からすると、Abusing対策に開発リソースを割く余裕もないし、あんまり割きたくないんで、人でなんとかなるならそれでっていう感じになりがちなんですよね。

―― 石田
そうなんですよね。なので、横断的なAbusing専門組織ができたら、自動ブロックシステムの構築や分析システムの開発、abuserの分析や対策案の立案といった abusing対策を全面的にサポートするので、サービス担当の方にはなるべくクリエイティブな業務に専念していただけるような環境を作れたらいいなと思ってます。

LINE Engineer Insights Abusing Spam Security Elastic Stack

LINE Engineering Blog 2017.07.06

Add this entry to Hatena bookmark

リストへ戻る