あんしん・あんぜんなWebサイト運営のために
Rakuten-CERT representative 福本佳成
■はじめに
皆さん、こんにちは。Rakuten-CERTの福本です。
いよいよ12月に突入です。
ECサイトの場合、年末に向けてトラフィックが急増し、ビジネス的には年間でも最も重要な時期を迎えます。システム運用でも監視体制が強化され、ちょっとした予兆でも僕のところに警戒情報がエスカレーションされてきます。「絶対にサービスを落とせない」という皆の緊張感を感じつつ、日々の業務にあたっている今日この頃です。
さて、今日はRakuten-CERTについてご紹介をしたいと思います。
初めてRakuten-CERTの名前を聞く方も多いかと思いますが、Raktuen-CERTは楽天グループのCSIRT ※1です。
楽天には、以前からインターネットサービスのセキュリティ対策のために、セキュリティ対応組織は必然的に存在していました。2007年にその組織をCSIRTと明確に定義し、2008年には日本シーサート協議会、そしてFIRSTにも加盟させていただきました。
今、なぜわざわざ既存の組織をCSIRTとして定義する必要があったのか？ ということを聞かれたりもします。それは、ボットネットが台頭するなど、近い将来他のCSIRTと相互協力したインシデント対応体制が必要となると思っていたのと、国内でもCSIRT間で連携する機運が高まって来ていたこともあって、他組織とセキュリティの相互協力関係を作り上げるには絶好のタイミングだと思ったからです。そういうわけで、楽天はCSIRTを定義してPOC ※2も明確化し、これまで他のCSIRTとも連携を深めて参りました。そんなRakuten-CERTの役割について、少しお話していきたいと思います。
■Rakuten-CERTの役割 ～安全なソフトウェア開発のために～
Rakuten-CERTは楽天グループのインターネットサービスのシステムセキュリティに関するインシデント対応をコーディネーションするための組織ではあるのですが、リアクティブ対応だけがRakuten-CERTの役割ではありません。Rakuten-CERTの中核となる部署、システムセキュリティグループではプロアクティブな対応として、楽天の開発部での安全なソフトウェア開発のための仕組化とその支援を行っています。楽天の開発では以下の開発時のセキュリティ対策が仕組化されており、システムセキュリティグループではそれぞれのセキュリティ対策を運営しています。
[入社時の教育]
コンピュータサイエンスを学んだ学生でも、Webサイト開発における安全なプログラミング手法を学ぶ機会はそれほど多くなく、安全なソフトウェア開発のためには企業責任において実践的なセキュリティ教育が必要だと考えています。
楽天のプログラマは必ず全員がプログラマ向けセキュリティセミナーを受講して、スキル確認テストに合格しなければなりません。また、年一度の更新テストにも合格する必要もあります。ちなみに、楽天では優秀者の中からセキュリティマイスターを選出していてセキュリティ教育に協力をしてもらっています。現場でセキュリティ有識者が増えることは非常にありがたく、すごく協力的で本当に助かっています！ ちょっと自慢です（笑）。
[要件定義フェーズ]
基本、セキュリティ実装でやるべきことは前述した教育で学び、それを実践してもらっています。ただし、例外的な外部委託開発の場合は、楽天と同じセキュリティ品質を担保するために、セキュリティRFPを使って委託先にセキュリティ要件を明示することになります。そして実装できているかの確認も行っています。このセキュリティRFPの作成ツール、機能要件などに応じて自動的に必要な項目だけに絞ったセキュリティRFPを生成できる便利なツールで、システムセキュリティグループが開発・メンテナンスをして開発部隊に提供しています。
[設計フェーズ]
新しいサービス技術を導入する時などはシステムセキュリティグループのセキュリティ専門家が脅威分析に協力することもあります。これによって仕様上の脆弱性を未然に防ぎ、デザインエラーによる手戻りをなくします。でも、たくさん依頼が来ると僕がパンクするので、レビューできるエンジニアがもっと欲しいです……（苦笑）。
[QAフェーズ]
脆弱性テストツールをQAテストで使い、結合テスト後に脆弱性がないかのチェックを必ず行います。これは開発現場かQA専門部隊がやります。単純なエスケープ漏れとかはシステマティックに検出ができます。僕たちはこの仕組みが有効に機能しているかを管理しています。今はブラックボックステストでやっていますが、そろそろソースコードの静的解析ツールも成熟してきているようなので、そういうのも面白そうですね。
[監査フェーズ]
QA後にセキュリティ専門家による実査が入ります。ツールは単純なエスケープ漏れを漏れなく探すのは得意ですが、ロジックがからむような脆弱性を検出するのは弱いです。そこも含めて最後は人（専門家）がチェックします。なお、この時点で単純な脆弱性が見つかる場合は、開発プロセスの何処かに問題を抱えていることになり、プロセス改善につなげなければならないと思っています。また、この結果はシステムセキュリティグループにより経営層、各マネージャに対して品質・リスク報告されます。そして安全性が確認されてから新しいサービスがリリースされることになります。
ということで、このような対策を日々運用しているわけですが、最近はより安全なソフトウェア開発のため、セキュアディベロップメントを成長させる仕組みを考えています。以前はどちらかと言うと開発後の安全性チェックに対策の重きを置いていたのですが、ここ数年は前工程で脆弱性発生を抑止するための活動を強化しています。最後に悲劇的な監査結果が出ると、開発現場だけでなく、さすがに僕たちもキツイですからね（苦笑）
基本的には自社開発でやっているので、脆弱性を生み出す根本原因を解決し、成長していくことで脆弱性を作りこまない開発体質を作り上げることができるはずで、それがセキュリティ品質の向上だけではなく生産性向上、さらには資産価値向上にもつながるとも考えています。
なぜなら、要件を織り込んで開発され、各ポイントで安全性をチェックされたソースコードは監査後の修正作業の確率も少なく修正時の工数もあまりかかりません。また、場当たり的な改修をしてないソースコードは再利用もしやすく、結果的にソフトウェア資産価値が向上するというメリットもあると考えます。実際に安全性が確認されたモジュールを再利用して開発したサービスも多々あるのですが、その場合のセキュリティ品質は極めて良いという結果が出ています。まあ、当然といえば当然の結果かもしれないですけどね。
楽天は開発1000人体制で毎日ものすごい量のプログラムを開発するわけですが、そのような環境においてもこのようなセキュリティ対策の仕組みによってあんしん・あんぜんなサービス開発が行われ、安全性が担保されています。今後も多くのユーザさんに楽天のインターネットサービスを安心して使ってもらえるよう頑張っていきたいと思います。
■最近、思っていること
ちょっと話題は変わりますが、最後に最近、思っていることについてお話したいと思います。
これまではPCクライアントのセキュリティ問題についてはユーザー責任で、自社のWebサイトの安全性を高めればいいと思ってきたのですが、どうもそろそろその考えを改める必要があるのかなと思っています。というのも、近年のマルウェアのターゲットが変化してきていて、Webサイトの認証情報を搾取して、そのWebサイトを悪用する方に向いて来ていているように思います。また、今後はますますその傾向が強まるのではないかと危惧しています。そうなると、Webサイト側でも黙っている訳にもいきません。
このようなID theft ※3に対して、楽天ではユーザ保護の観点で、Webサイト側でできる対策として、第二認証によるチェックや不正ログインの検知後のアカウントロックの仕組みを導入しています。今後は楽天グループの金融系サービスのノウハウを活かして、金融が得意としている不正利用のモニタリング技術を応用した、インターネットサービスでの不正利用検知ができるのではないかとも思っています。そして、この分野では楽天技術研究所との共同研究も可能性として考えられるかもしれません。楽天グループのシナジー効果を出すことで、より先進的な対策が実現できると思うので、ぜひトライしてみたいテーマですね。
また、ユーザーさんのPCのクリーン活動も外部と相互協力して実施することによって、今以上の対策効果が出せるのではないかと考えています。サービス側でアカウントロックをしてもマルウェアへの対策をしないと結局再発してしまいますので、根本へのアプローチも必要です。外部との協力関係としては、例えば、サイバークリーンセンターさんと連携して、不正ログインされたアカウントのPCのクリーニングを促すとかはどうでしょうか。ネット全体ではPCクリーン活動の幅が広がり、そしてサイバークリーンセンターではネット上で発生しているインシデントの全体像が見えるようになるので、これまでよりも対策方法も検討もしやすくなったりするかもしれません。いろいろメリットがありそうな気がしますね（っていってみるテストですｗ）。それでは。
have fun.
※1 CSIRT：Computer Security Incident Response Team
※2 POC：Point Of Contact
※3 ID theft：identity theft