とあるセキュリティの甘いサイト構築をした時の話

人より１０倍早い開発を得意とする、ユゲタです。 仕事で、知り合いから連絡が連絡がある場合、多くがシステム開発やサイト開発の火消し作業が多いのですが、 スケジュールも金額も、かなりの無茶振りが多い事が多いのですが、 そうして頼ってくれる事には、感謝しかないので、文句を言いつつお受けしている現状ですwww

本日の謎掛け

「システム開発の火消し作業」と、かけまして・・・ 「コロナ禍における国会対応」と、ときます。 そのココロは・・・ かんりょう（完了と官僚）のスピードが重要です。

今回案件の概要

詳しいことは書けませんが、前職の最後の部下だった後輩から晩飯を食べていた時に電話が来た時の話です。 その会社で受注した、とあるアパレル関連のECサイトを構築したいけど、自社内開発が、ハードウェア系は強いけどWEB系がめっぽう弱い為、納期を伸ばさないといけないと言われたので、相談と兼ねて実作業もしてもらえないかという相談でした。 そのサイトは、関係者しか見ないので、膨大なアクセスを想定しなくてもいい上、ECサイトだけど、決済機能はつけなくてもいいという事で、一番時間のかかるポイントが排除されているので、スケジュールは問題ないと判断したんですが、 それでも、スケジュールは、公開まで１ヶ月しかないとのこと、この時点で、完了を１週間前にはしておくとすると、３週間ほどしかないということになります。 ちなみに、こちらでの作業受け額は、国内の他会社で見積もりを取った場合と比較して1/4程度の金額だったんですが、ある意味やっつけ作業としてこなすことにしました。

開発時に必ず仕様でトラブルは発生する

とりあえず、概要は伺って、いざ仕様に落とし込もうとしたのですが、あまりにもゆるすぎて、決めることが困難になったんですが、 そもそも、ユーザーの利便性を優先させて、ログイン機能を持たせたくないという先方の意見を優先するがゆえに、 ユーザーに事前告知する「顧客番号」と「氏名」のみで、ECサイトを構築するという無謀さに少し引き気味の僕でした。 ようするに、自分ではない顧客番号でも、サイトを利用できてしまうという状態なんですね。 もちろん、内部で決済機能を持っていないので、金銭的な実害はないにしても、 ショッピングカートや商品お気に入り機能はどは持っているので、そうした個人情報の漏洩の可能性はゼロではないという状態ですね。 本当にその使用でいいかを散々伝え、せめてパスワードを入れるようにしないかという提案もしたが、利便性重視のため、初回の仕様で行くとのこと。 エンジニアとしては、いささか心が痛む、セキュリティの甘いサイトになるが、先方に公開後のセキュリティ漏洩トラブルなどは、一切うちの会社として関与しないという、覚書を書いてもらい、進めることにした。

本来ならどうするべきなのか？

この仕事の話は、ココまででいいのだが、こうしたセキュリティの話は、世の中でゴロゴロ転がっている話でもある。 そして、公開して、不正アクセスの後、情報漏えいして、テレビのニュースなどでさらされて・・・ という結末を迎えたWEBサービスを、何度も見たことがある。 もちろん、パスワード登録をすることになった場合、リテラシの低いユーザーから「パスワードがわからなくなった」という問い合わせが殺到する事も十分に予測できる。 ただ、それとセキュリティ漏洩の話は次元が違う話しで、今回作成するシステムは、いわばセキュリティゼロの状態なので、少なくともセキュリティを担保できるシステムにするにはどうするべきかを僕なりに考えてみた。 条件としては、リテラシの低いユーザーが多数いるサービスでの、ユーザー情報の確保をするセキュリティです。

提案その1. Google,Facebook,TwitterなどのOAuth機能を使う

これはパスワードを入れる必要もなく、SNS系のサービスにブラウザでログインさえしてくれればいいのだが、 そもそも、リテラシの低い人は、こうしたサービスを使っていない事も多く、ログインという言葉自体が理解できない人が多いので、本サイトでパスワードを設けたほうが懸命という事で却下。

提案その2. サイトアクセスをユニークURLで判別

今回のサイト構築は、アパレル会社のキャンペーンの一貫で行うため、ユーザーには、QRコードを郵送でサイトアクセスを促すとの事なので、 それをユニークにして、かつ顧客番号という個別IDが存在するので、サイトアクセスコードをユニークにして、それをサーバー側で紐付ければいいのではないかと考えた。 しかし、顧客番号は、ユーザーごとに伝えるが、QRコードは、ユーザー別にユニークにすると作業が煩雑になるので、アパレル会社から却下とのこと・・・orz

提案その3. ブラウザ識別子を使って判定

最後の手段として、システム側である程度担保できるように、顧客番号と合わせて、ブラウザ識別子として、閲覧するWEBブラウザにそれぞれID番号を発行し、それを紐付けての認証をするということにした。 この仕様は、ユーザーは、最初にアクセスしたブラウザでのみしかアクセスできなくなりますが、他のブラウザで、ログインされることはなくなります。 ブラウザの識別番号は、弊社の技術でそれをユニークIDと紐付けることで、ログインパスワードが不要になるという仕様で、これを採用することにしました。 ただし、完璧な仕様ではなく、欠点としては、本人以外が最初に顧客番号を登録されてしまうと、利用できなくなってしまうというリスクはあるが、その点は、サポート運用でカバーするとのことだったので、今回はこれで決着しました。

まとめ

ITスキルの無い人が、仕様を決定するというのはいかがなものかと思うし、利用人数が少ないからと言って、セキュリティを度外視する思考はいかがなものかと・・・ こうした点も踏まえて、独自仕様になるけど、便利なセキュリティシステム構築をできるようにしておこうと、密かに考え始めました。 最近OAuth2というサービスが流行りはいめているようですが、ユーザー利便性を良くして且つセキュリティを担保するという魅力的なシステムは、まだ世の中に無いようです。 なにかやりようがありそうな気はしますね！！！