arists.net

恐怖の機能「ユーザー認証」

個人情報漏洩、パスワード漏洩、あれも漏洩、これも漏洩・・・

何万件のユーザー情報が漏洩、損害賠償がどうたら、というニュースをしばしば見ます。

人様の情報をお預かりする、というのは非常にリスクのあることです。これらは個人情報保護法で規制されています。本業でも（基本、名刺に載っているレベルの業者の連絡先情報くらいしか無くて、悪い人の役に立つような個人情報など全く保有していないのですが）個人情報保護法対応はきちんとしています。

YourRecipeの製作中もログイン機能なかったら全く使い道ないと薄々気づいていたのですが、こんな怖い機能を自分で実装するのか？やれるのか？ユーザー情報抜かれてえらい目に合わないか？・・そもそも情報抜かれるほどユーザー様を獲得できるのか？？？最後の問題が解決しなければ他はどうでも良い話ですが、万が一のことを考えて、責任逃れができる安全なログイン機能をどの様に実現できるか、検討しました。

作りたくなかったので借り物の機能を検討

「ソーシャルログイン」です。

一言で言えばSNSやgoogleアカウントなどでログインできるようにしてユーザー情報を拝借して利用する、という感じでしょうか。最近いろいろなサービスで見かけますが、いとも簡単にユーザー登録ができてしまって、知らない間に送られてくるダイレクトメールがずんずん増えていきます。

ソーシャルログインならユーザー側としても抵抗感無くユーザー登録できる（ユーザー登録のための情報入力が無いことに起因する）でしょうし、いろいろなサービスでも使用されているので安心な感じがします。

というわけで仕様を色々確認していたのですが、気になったことがいくつか。

• 拝借できるデータが結構多い
• 機能が多過ぎて把握するのが大変
• 仕様変更への対応などメンテナンスの手間がかかる

１つ目は、SNSサービスによるのですが、中には電話番号や郵便番号まで入手可能なサービスもあるようです。そんな個人情報は不要です。もちろん見なければよいだけの話ですが、「見ようと思えば見れる」状態すら持っておきたくないです。

２つ目は、いろいろなサービスに対応できるように機能が多いのですが、これらを全部把握しておかないと、落とし穴に気づかずにセキュリティが脆弱な状態を作ってしまうリスクがあります。APIのサーバーにhttpリクエストで情報を取りに行ったりするようなので、下手な使い方をするとアプリの外からでも情報を抜くことができるかもしれません。ちょっと危険な感じがします。

３つ目に、外部のAPIを利用するので、その仕様変更を適宜確認して必要に応じて修正しなければけないようで、それは結構大変だな、と。かと言って有償の外部サービスを利用するのはもったいない。

結局自分で作ることに

目的は「保存されたレシピにユーザー名をつけてその人以外見れなくすること」なので、ユーザーの区分さえできればよく、個人情報は不要です。

目的に対してソーシャルログインは機能が多すぎて、安全に運用するのにかえって手間がかかりそうなので、余計なデータをもらわないシンプルなものを自分で作って、自分で把握できる状態にしておいたほうが良いと判断しました。

どの様に作ったのか

バカにされないユーザー認証のしくみ

「史上最悪のログイン処理コード」というのがネットでめっちゃいじられていました。こうならないように、ユーザー認証の仕組みを整理します。

絵を見ながら雑に一文にまとめると、クライアントからユーザーIDとパスワードをもらって、ユーザー情報のデータベースにいる人かどうかを確認して、いる人ならsessionというチケット的なものを渡して、サービスを利用してもらう、という流れです。

危険の回避をどこまでどの様にやるか

この仕組みの中で危険そうなポイントが主に３箇所あります。

• 危険①：ユーザーID、パスワードがインターネットの大海原を流れて来る
• 危険②：サーバー内部にユーザーID、パスワード、その他の情報リストを持っている
• 危険③：sessionIDがインターネットの大海原を行ったり来たりする

１つ目の危険は、ログインしたいクライアントから、ユーザーIDとパスワードがインターネットを経由して送られてくることです。インターネットを流れる情報はどこからともなく盗み見られるリスクがあります（wi-fiの電波を捕まえられる赤い服の人とか）。これはSSL認証を使用する（https://...になるやつ）ことで暗号化してから送信できるので、許容できるレベルまでリスクを下げられると思います。（電波を捕まえても読めない）

２つ目の危険は、サーバーでユーザーのパスワードやその他の情報をまとめて保管していることです。個人情報保護法でも、こういう個人情報がリスト化されたものを「個人データ」と読んで厳重に管理するように規制されています。サーバー内にある保管情報なので、サーバーに不正アクセスされなければ漏洩しないのですが、いろんな手段で不正アクセスを試みる悪い人がたくさんいますので、（2023年2月時点で当サイトのお客様はほぼ100%不正アクセスを試みる方です。不正が成功することはありませんが。）不正アクセスをされないようにすることと、リスクのあるデータを持たないことの両面から対策が必要と思います。

当サイトでは、主に以下の様な不正アクセス対策と管理データのリスク低減を実施しています。別に自慢するようなことではなく、ごく基本的な対策ですが、何事も基本が大事です。当たり前のことをきっちりとやります。

• 必要なポート以外はファイヤーウォールで閉止
• SSH（サーバーにリモートアクセスするやつ）のポート番号変更
• webアプリからDBサーバーへのSQLインジェクション対策（入力文字のエスケープ等）
• ユーザーの個人情報は原則受け取らない（メールアドレスだけはパスワード再発行などで必要なので仕方なく受け取ります）
• ユーザーパスワードは暗号化（ハッシュ、ソルト）したものだけを保存し、平文で保存しない（万が一漏洩しても使えない）

３つ目のsessionというのは、前述しましたが、ユーザー認証が確認できたときに渡すチケットのような使い方をしています。（実際はもう少し機能があります。）これが漏洩したらそのユーザー様のアカウントに不正にアクセスできてしまうのですが、session自体がサービス利用中のみ有効な一時的なものであることと、ログイン認証時と同様SSL認証で暗号化された状態でやり取りされるので、リスクレベルは許容可能な範囲だと考えます。

結果

一応、最低限の対策はできていると思いますが、決してこれで十分！というわけではなく、やろうと思えばもっといろいろなことができると思います。こと安全に関しては絶対はなく、必ずリスクは残るので（家に飛行機が突っ込んでくるリスクだってゼロではない）、リスクを十分に許容できる範囲を決めてそこまでしっかりと対策することが肝要です。

安全はとても大事なので、ここだけは真面目に勉強して、しっかり対策しながら運営していきたいと思います。

まとめ

何よりも、トラブったら面倒くさい。