前回と前々回で、楽天の開発プロセスにおけるセキュリティ体制を見てきた。今回は、これまでに実際に楽天で発生したセキュリティのトラブルを取り上げ、具体的にどのように対処してきたかを紹介しよう。

Case1●「かんたんログイン」

　2009年11月、携帯電話の契約者固有IDや端末のシリアル番号で利便性の高いユーザー認証を行う「かんたんログイン」に新たな脆弱性が発見された。かんたんログインは、携帯電話事業者が提供するサービスである。その脆弱性を利用すると、悪意のある第三者が正規ユーザーの個人情報などを不正に取得または更新できてしまうという危険なものだった。

　Rakuten-CERTには新たな脆弱性が見つかると、直ちに楽天のサービス全体で問題がないかを確認する業務フローがある。今回のケースではまず、かんたんログインを利用していて、個人情報の登録・閲覧・変更機能があるサービスを洗い出した。開発グループの兼務担当者と共同で情報収集した。

　結果、脆弱性の影響を受けるサービスが5件ほどあり、このうち個人情報を扱っていて対処が必要なものが1件あることが分かった。この時点で各開発グループでは、セキュリティの兼務担当者と開発エンジニアが対処を始めている。筆者らは兼務担当者と相談して、いくつかあった対策の中から、HTTPリクエストヘッダーの内容を確認する方法がベストだと判断し、実際の修正作業を進めた。

　新たな脆弱性については、開発が進行中のプロジェクトに参加する兼務担当者にも通知されている。あるプロジェクトでは実際にかんたんログインを採用していた。筆者らは、そのシステムを検査工程でチェックしたが、適切な対策がすでに盛り込まれていた。

　今後の開発に向けた改善として、まず脆弱性が発生した原因を探った。今回は、仕様が不明確で自社でコントロールできないシステムに、ユーザー認証を任せたことが原因だと結論づけた。携帯電話事業者はかんたんログインの利用を促進するばかりで技術的な仕様を明らかにしない。脆弱性の有無は携帯電話機が持つ機能によっても変わり、今後の機能拡張を予測することも難しい。当社側の工夫だけでは十分な対策ができないのだ。

　結果、契約者固有IDや端末のシリアル番号による認証（かんたんログイン）のみで個人情報、および個人の特定につながる情報、金融関連情報に直接アクセスすることを禁止とし、それを開発ガイドラインで定義することにした。ユーザーがそれ以外の機能を利用するとき、再度パスワード認証を求める。利便性は低下するが安全性を重視した。