TypePadビジネスの脆弱性検査への取り組み
サービス安全性確保のためのセキュリティ対策
今回は TypePad ビジネス 開発の現場で QA チーム（品質検査管理部門）でおこなっている脆弱性検査への取り組みとして、検査ツール導入から検査実施までの流れをご紹介します。
- 脆弱性とは
- 脆弱性検査の実施：検査とは「誤検知」との戦い
- 再検査の実施タイミングを判断
- たくさんの人が安心して利用できるサービスにするために
脆弱性とは
脆弱性とは、悪意の第三者が攻撃の糸口として利用できるかもしれないアプリケーション上の問題のことをさし、一般的には「セキュリティホール」とも呼ばれています。
脆弱性にはクロスサイトスクリプティングや SQL インジェクション、バッファオーバーフローなどいろいろな種類があり、その種類ごとに攻撃のパターンがいくつもあります。
それらすべてのパターンを手作業で検査することはできないため、中・大規模のアプリケーションになると専用の検査ツールを使用して、脆弱性検査をおこなうのが一般的です。
しかし商用の検査ツールはたいてい高額なため、簡単には購入できません。わたしたちは導入当時の経理担当責任者などとも相談しながら、ツールの選定・購入をおこないました。
脆弱性検査の実施：検査とは「誤検知」との戦い
脆弱性の検査で一番大変なのは、それが「本当の脆弱性」かどうかを検証するところです。
脆弱性の検査ツールでは、脆弱性を攻撃するようなリクエストを擬似的に送信し、そのレスポンスを分析して判定します。しかしレスポンスはアプリケーションの実装方法に依存するところがあるため、高価な検査ツールといえどその分析は完璧というわけではありません。誤検知もそれなりの数あがります。
特に、TypePad ビジネスのように5年以上継続して開発が続いているアプリケーションでは、たいていの脆弱性はすでに修正されているため、検査を実施してもほとんどが誤検知というのが実際のところです。
しかし、どうせ誤検知だからと放っておけ、というわけにもいきませんので、検査で発見された問題は時間をかけて検証します。これは本当に時間のかかる作業であるため、誤検知をなるべく少なくするように、あらかじめ検査ツールのチューニングをおこなっておくことが開発効率を維持するためにはとても重要になります。
チューニングでは、たとえば不要な検査を少なくしたり、検証箇所を狭めたりするなど、検査項目の設定や調節をおこないます。この作業を下手におこなうと「本当の脆弱性」を見逃してしまう恐れがあるため、慎重に作業する必要があります。
TypePad ビジネスでは、開発を担うエンジニアとプロダクトマネージャーを集めて、相談しながら不要な検査の選定をおこなっています。
再検査の実施タイミングを判断
脆弱性の検査は一回おこなえば済むわけではありません、おもに以下二つの要因に対応するため、タイミングを見計らいながら再検査を実施しています。
一つめの要因としては、攻撃手法の変化にあわせて、新たな種類の脆弱性が見つかったときです。
検査ツールでは「現在すでに認識している」種類の脆弱性しか検査することができないため、もしも新たな種類の脆弱性が見つかったときには、その脆弱性についての検査項目を追加してからおこなうことになります。
二つめの要因としては、アプリケーションに大きな改変をおこなうなど、新たに加えた処理の安全性を確認するときです。
とはいえ、新たな脆弱性要因が増える度に検査をおこなうわけにはいきません。検査の負荷が大きくなりすぎてしまい、製品開発の効率性を損なってしまう場合があるためです。
そのため、適切なタイミングで再検査を実施するということが非常に大切です。いつ実施するのか、そのつど製品開発チーム全体で意見を交換し、判断しています。
たくさんの人が安心して利用できるサービスにするために
以上が、シックス・アパートが TypePad ビジネスの安全性確保のためにおこなっている脆弱性検査の概要です。
実際のところ脆弱性の検査は地味で楽しい作業ではありませんが、たくさんの人が安心してご利用いただけるよう、心を込めて検査しています。
これからも TypePad ビジネスと一緒に、素晴らしいブログライフをお過ごしください 
コメント