名前はバレてもいい。本当に守るべき個人情報の話

最近、情報漏えいのニュースが本当に多いですよね。

9月から10月にかけて、タイムズカー、ソースネクスト、Studioなど、よく使われているサービスで公表が続きました。JPCERT/CCも10/8に、9月前後から国内組織で不正アクセスによる漏えいが相次いでいるとして注意喚起を出しています。

「利用者はパスワードを変えましょう」という記事はたくさん出ているので、今回は少し違う目線で書いてみます。僕たちは、お店や小さい会社向けにWebサイトや業務システムを作っている側です。漏えいのニュースを見るたびに、「作る側として、そもそも何を持たない・つながないべきか」を考えています。

今回は、その中で僕たちが大事にしている3つの考えをまとめてみます！

01｜連携は「便利」の数だけ、漏れる場所が増える

最近のサービスは、何でもつなげられます。「Googleでログイン」「スプレッドシートに自動で書き出し」「Slackに通知」「LINEと連携」。作る側も、つい「つなげられます」を機能として並べたくなります。

でも、連携をひとつ増やすたびに、どこかに「鍵」がひとつ増えます。APIキー、アクセストークン、Webhookの URL。そしてその鍵は、自分の管理していない場所に置かれることも多いです。

それがよくわかったのが、10月のStudioの件でした。Studioは、ホームページ制作でよく使われるサービスです。公式の案内によると、流出した可能性のある情報には、アカウント情報やフォームに送られた内容に加えて、こんなものが含まれていました。

• API連携に登録された外部サービスのAPIキーやトークン
• Googleスプレッドシート連携の認証情報
• Webhook通知のURL

しかも、暗号化して保存していたものも、復号に必要な鍵が同じ不正アクセスで読み出されたため、内容を知られた可能性がある、とされています。

ここで大事なのが、外部サービスのAPIキーは発行元のサービスで管理されているので、Studio側では無効にできないという点です。利用者が自分で、つないでいたサービスそれぞれで鍵を作り直す必要がありました。Studioの案内には、スプレッドシート連携の認証情報とシートのIDが一緒に流出した可能性があるので、鍵が更新されるまでの間にシートを見られたり編集されたりした可能性も否定できない、とも書かれています。

タイムズカーの件でも、漏えいした情報の中に「連携サービスID」（JR西日本グループのWESTER IDなど、計9件）が入っていました。

つまり、連携は「つないだ先の数だけ、漏えいの影響が広がる」ものです。なので僕たちは、こう考えるようにしています。

• その連携がないと困る人が、本当にいるかを先に確かめる。「あったら便利そう」では足さない
• 足すなら、どこに何の鍵があるかを一覧にしておく。漏れたときに、どれを止めればいいかすぐわかるように
• 使わなくなった連携は、鍵ごと消す。画面から機能を消しても、鍵が残っていたら意味がない

GoogleのOAuthのポリシーにも、アプリが機能を変えて使わなくなった権限は、できるだけ早くトークンを取り消すように、と書かれています。

02｜権限の選択を、利用者に任せない

OAuth（「〇〇でログイン」や「〇〇と連携」のときの仕組み）では、つなぐときに「このアプリに次の権限を許可しますか？」という画面が出ます。

正直、あの画面をきちんと読んで判断している人は少ないと思います。僕たちも含めて、だいたい「許可」を押します。早く使いたいので。

だから、権限の選択を利用者に任せる設計は、結局「全部許可」になりやすいと考えています。「必要な権限だけ選んでください」と画面に並べても、選ぶ側には何が必要かわかりません。わからないなら、全部チェックしておくのが一番安心に見えてしまいます。

なので、権限を絞るのは作る側の仕事です。

GoogleのOAuth 2.0のポリシーには、はっきりこう書かれています。

• アプリは、利用者が選んだ機能に必要な最小限のスコープ（権限の範囲）だけを要求しなければならない
• たとえば、Gmailでたまにメールを送るだけのアプリが、メール全体にアクセスできるスコープを要求してはいけない
• できるだけ、その機能を使うタイミングで、理由を説明してから権限を求める（インクリメンタル認可）

僕たちが気をつけているのは、こんなところです。

• 最初のログインで全部の権限をもらわない。その機能を使うときに、その機能の分だけもらう
• 「読むだけ」で足りるなら、書き込みの権限はもらわない
• 権限を細かく選ばせる画面は作らず、こちらで必要最小限に決めておく。そのかわり、なぜその権限が要るのかを一言で書く

社内でも同じで、AIのボットや自動化に業務システムをつなぐときは、人のアカウントを貸さず、ボットごとに別の鍵を作って、必要な操作だけできるようにしています。どれか一つが漏れても、その鍵だけ止めれば済むようにです。

03｜名前や生年月日に過剰反応するより、「何を聞くか」を決める

ここは少し言い方が難しいんですが、僕たちの考えを書きます。

漏えいのニュースでは、「氏名、生年月日、住所が流出」と並びます。もちろん良いことではありません。ただ、名前や生年月日は、実生活ではそもそもけっこう知られている情報です。名刺に名前は書いてありますし、誕生日は職場や友だちが知っていますし、SNSに書いている人もいます。

だから、名前や生年月日を「秘密」として扱う設計にしないことの方が大事だと考えています。生年月日で本人確認をする、生年月日を合言葉にする、という作りにしていると、漏れたときに困ります。IPAも、パスワードに生年月日や名前を使わないように、と書いています。そもそも秘密ではないからです。

逆に、本当に考えないといけないのは、そもそもそれを聞く必要があるのかです。

本人確認書類は「確認したら持たない」

わかりやすいのが運転免許証です。タイムズカーの件では、運転免許証の画像などの本人確認書類が漏えいしたアカウントが約160万件ありました（アカウント情報の漏えい全体は約660万件）。

パーク24の10/16の発表によると、本人確認書類の画像は、会員期間中と退会後7年間持っていたそうです。目的は、登録時の本人確認に加えて、不正利用への対応やお問い合わせ対応などでした。今回、これを見直して、会員登録が終わったら画像を持たないルールに変え、今持っている画像も10月末までに削除するとしています。

免許証を確認する必要がある業務はあります。でも、「確認すること」と「画像を持ち続けること」は別の話です。持っていなければ、漏れようがありません。

聞く項目は、使い道とセットで決める

僕たちがフォームや会員登録を作るときは、項目ごとにこう考えています。

• この項目は、何に使うのか。使い道が言えない項目は聞かない
• 利用者が気にせず入れられる項目か。気にする項目（免許証、勤務先、家族構成など）ほど、本当に必要かを問い直す
• いつまで持つのか。使い終わったら消せるか
• 任意の項目を「なんとなく」増やさない。「あとで分析に使えるかも」は理由にしない

これは個人情報保護法の考え方とも合っています。法律では、個人情報の利用目的をできる限り特定しなければならないとされていて（第17条）、個人情報保護委員会のガイドラインでは、「事業活動に用いるため」「マーケティング活動に用いるため」のような書き方は具体的とはいえない、と例が挙がっています。良い例は、「○○事業における商品の発送、関連するアフターサービス、新商品・サービスに関する情報のお知らせのために利用いたします」のように、本人が「何に使われるか」を想像できる書き方です。

フォームに「この項目は〇〇のために使います」と一言添えるだけでも、利用者は安心して入力できます。作る側も、使い道が書けない項目に気づけます。

お店のフォームも「預かっている」

Studioの件では、Studio製のサイトのフォームに送られた問い合わせや予約の内容も、流出した可能性がありました。Studioの案内では、フォームで個人情報を受け取っていたお店や会社が、送った人への通知をしないといけない場合がある、とされています。不正アクセスの場合は、対象者が1人でも通知が必要になることがある、とも書かれていました。

自分でシステムを作っていなくても、フォームで聞いた時点で、その情報を「預かっている」ことになります。聞く項目が少なければ、それだけ漏れる情報も、通知で説明することも少なくなります。

04｜まとめると「持たない・つながない・聞かない」

僕たちが作る側として考えていることを、まとめるとこうなります。

• つながない：連携は「ないと困る」ものだけ。鍵の場所を把握して、使わなくなったら鍵ごと消す
• 権限を絞る：選択を利用者に任せず、作る側で最小限に設計する。必要なときに、理由と一緒に求める
• 聞かない・持たない：名前や生年月日を秘密扱いする設計をやめて、そのかわり「何を聞くか」「何に使うか」「いつ消すか」をはっきりさせる

漏えいを完全に防ぐことは、どんな会社でも難しいです。だから、漏れても困らないように、最初から持つものを減らしておく。それが作る側にできる一番確実な対策だと思っています。

情報漏えいについて、作る側の目線で書いてみましたが、いかがでしたでしょうか？

フォームや連携の見直しで相談したいことがあれば、気軽に声をかけてください！