ミクシィのアプリケーションセキュリティの代表的な取り組みについて

こんにちは、opera 大好き松岡剛志です。今日は部長職ではなくて、セキュリティチームリーダー立場でブログを書いています。

今回は弊社の様々なアプリケーションセキュリティの取り組みのうち、以下の4つのコンテンツについて書きます。この内容はほとんどが弊社のセキュリティイベントである Scrap Challenge で使われたスライドの焼き直しです。

トレーニング
セキュリティレビュー
コードレビュー
セキュリティチェック

トレーニング

現在ミクシィでは新卒エンジニアに対して1カ月程度の缶詰の教育を行っています。そのコンセプトは以下です。

関係各所、チーム、チーム横断でのタスクに関して　迷惑をかけずに自分で判断できる/あるいは正しく判断を仰げる状態までの成長。
現状の技術的問題点や課題を把握し、改善策や改善のためのプランニングができる。
各項目への知識体系の羅針盤を提供して、自学自習によってより高度な領域まで発展することができる。

このため面白い特徴として「ミクシィでしか使えないこと」の教育は最小限にしています。この辺りはいずれtakaiやyuzuemonが書いてくれるでしょう。

この研修の中に以下のセキュリティのメニューがあります。

どれも可能な限り座学だけではなく、手を動かすことを意識しています。

セキュリティレビュー

私達は自分たちの企画が安全なはずないと考えています。

ミクシィでは社内で規定された一定の情報レベル以上を取り扱う時や担当者が鼻を利かせたとき、社内のセキュリティチームにレビューを行うというルールがあります。我々のサービスはお客様の大切な情報をお預かりしているので、かなり気をつけているところです。しかしながら多くの問題を起こしていることを恥ずかしくも思っております。

セキュリティレビューはマイクロソフト様のSTRIDEの視点で見ることが多いです。違う視点としては以下のような視点で見ることが多いです。

処理するところ、保持するところの確認。
通信経路の確認
プライバシーは守られているか？
入出力情報は必要最低限か？
アビューズについて考えたか？
3rd partyは絡んでいるのか？
etc

セキュリティレビューはJIRA(issue tracking systemの一種)で管理されています。ミクシィのその他のレビューもすべてJIRAで管理されています。これにより案件の漏れや期限の遅れを減らし、一つ一つの判断を判例として残しています。このセキュリティレビューの重要な点として、必ずセキュリティ担当者が2名以上でチェックして全員がokしないと進めません。私達は自分たち自身（セキュリティ担当者）も信用していないのです。

コードレビュー

私達はミクシィのエンジニアの作るコードを信用しません。ゆえにミクシィのコードはすべてレビューを受けないと本番に反映されることが無いようにしています。悪意あるコードが混入するリスクのほかにコードの品質、統一感も重視します。このレビューには様々なチェックポイントがあるのですが、セキュリティ面ではたとえば以下です。