TOP＞情報セキュリティ＞ 開発工程別で必要となるセキュリティ施策
crack
クラッカーから企業Webサイトを守り抜け！

第４回：Webサイトのセキュリティを維持・向上する施策
 著者：NRIセキュアテクノロジーズ  木村 尚亮   2006/11/30
前のページ  1  2  3
開発工程別で必要となるセキュリティ施策

   セキュリティ診断で発見される脆弱性は、開発の上流工程（要件定義、設計フェーズ）で対策を検討していなかったために埋め込まれる問題が多いといえます。

   上流工程からセキュリティ対策を考えることで、脆弱性の修正コスト（出戻り）も抑えることができます。また、上流工程で考えられた仕様が脆弱性として埋め込まれた場合は、リリース直前、もしくはリリース後に実施したセキュリティ診断で問題を指摘されても、もはや手遅れで修正ができない、といったことがしばしば見受けられます。具体的な脆弱性の例としては、「アカウントロック機能がない」「リマインダ機能の本人確認を第三者が知りうる情報（生年月日など）だけで行っている」などがあります。

   開発の各工程で必要となるセキュリティ施策、埋め込まれる脆弱性の例をについて工程別に見ていきたいと思います。
開発
フェーズ		 必要なセキュリティ施策 埋め込まれる脆弱性の例
要件定義
  • 脅威の洗い出し
    (リスク分析)
  • セキュリティ要件定義の
    作成
  • アカウントロック機能がない
  • 脆弱なリマインダ機能
  • 脆弱なパスワードが許容される
設計
  • セキュアな実装方式の検討
  • 設計書の第三者レビュー
  • 他人のセッションIDが推測できる
  • パスワードがデータベースに
    平文保存
実装
  • コーティング規約、
    実装方式の周知
  • ソースコードのレビュー、
    静的評価
  • SQLインジェクション
  • クロスサイトスクリプティング
  • 関連チェック不足によるなりすまし
配備
  • サーバ構築ガイドラインの
    準拠性チェック
  • セキュリティ診断の実施
  • ディレクトリリスティング
  • 詳細なエラーメッセージの表示

表2：開発工程別のセキュリティ施策、埋め込まれる脆弱性の例

   要件定義フェーズでは、脅威の洗い出し（リスク分析）を行った上で、必要なセキュリティ対策（セキュリティ要件）を網羅する必要があります。漏れなく必要なセキュリティ要件を洗い出すためには、「第3回：Webサイトの内部からの脅威を防ぐための施策」で紹介した各種基準が参考になります。

   設計フェーズでは、要件定義フェーズで決定したセキュリティ要件をシステムにどのように実装するかを具体的に考え、設計書に落とし込む必要があります。完成した設計書は実装フェーズへ移る前に、セキュリティ要件を満たすための設計として妥当であるか、そもそも要件定義に漏れはないか、といった観点で社内の有識者（開発に携わらない第三者）にレビューを受けることを推奨します。

   社内のレビューだけでは不安な場合、外部のセキュリティコンサルタントにレビューを依頼するという方法もあります。筆者も、システム開発の設計フェーズでこのようなレビューに参加することがありますが、設計内容についてヒヤリングをしていく中で、開発者が実装すべきセキュリティ対策を誤解していたり、要件定義が不十分（まだ決まっていない）だったりすることが判明することも少なくありません。

   また、個別のセキュリティ対策についても、システムの特性を聞いた上で、どのレベルまで行うのが一般的か、他システムでの事例などを踏まえて議論することで、開発側の抱えていた悩みが解消し、自信を持って実装に移れるようになります。このようなレビューを1度行ったシステムを実装後に診断すると良好な結果がでる、という効果がでています。

   実装フェーズでは、脆弱性を埋め込まないための「コーディング規約」を作成し、開発者に周知徹底してからコーディングに入る必要があります。なぜ規約にある個々のセキュリティ対策が必要なのかを開発者に理解してもらうために、「ガイドライン」の読み合わせも行っておいたほうがよいでしょう。

   また、ソースコードのレビューを行い、OSコマンドインジェクションやSQLインジェクション、クロスサイトスクリプティングなど、実装時に作り込まれる可能性がある脆弱性をチェックしておくべきです。最近では、セキュリティの観点でチェックを行ってくれるソースコードチェックツールも提供されはじめています。開発を進める過程では、このようなツールの使用も視野に入れつつ、日々安全なコードが書かれているかを網羅的に確認することを薦めます。

   配備は、開発環境から本番環境への移行フェーズです。OS、ミドルウェア、データベースなどのガイドラインを元にサーバのセキュリティ設定（ハードニング）を漏れなく行う必要があります。また、このフェーズでは、前工程で十分に検討してきたセキュリティ対策が正しく実装されているか、セキュリティ診断を実施し、確認してください。
終わりに

   Webサイトの安全性を高めるために、セキュリティ対策が進んでいる企業の組織的な取り組みについて説明してきました。今回、紹介した施策が実を結ぶまでに時間と労力がかかるのは事実ですが、実際にこのような取り組みを地道に行い、効果がでている企業があるのも現実です。

   特に数多くのWebサイトを抱える企業では、セキュリティ診断を継続して実施していても一向に改善が見受けられず、組織で取り組むべき抜本的な施策が必要なのではないかと、考えている担当者もいると思います。そのような担当者に今回紹介した施策が参考になれば幸いです。

   また、開発担当者からは、上層部や顧客の理解が得られずにセキュリティ対策が実施できない（後手に回る）という声をよく聞きます。今回の連載では、Webサイトのセキュリティの実態から、セキュリティレベルを高めていくための必要な個別な施策、組織として必要な施策を説明してきましたので、説得の材料としても活用いただければと思います。

   本連載をここまで読んできて、自社の所有するWebサイトのセキュリティ対策状況を管理できていない場合には、実情を明らかにするという観点で効果に即効性のあるセキュリティ診断サービスを活用し、まずは現状を把握することからはじめるアプローチをお薦めします。
前のページ  1  2  3

NRIセキュアテクノロジーズ 木村 尚亮
 著者プロフィール
NRIセキュアテクノロジーズ株式会社   木村 尚亮
1998年に野村総合研究所に入社。入社時より情報セキュリティ事業に携わる。2000年のNRIセキュアテクノロジーズの立ち上げとともに同社へ出向。セキュリティシステムの導入や不正アクセス監視などの業務を経て、現在はセキュリティ診断や不正アクセス調査などの業務に従事している。
INDEX
第4回：Webサイトのセキュリティを維持・向上する施策
  はじめに
  セキュリティガイドラインの作成
開発工程別で必要となるセキュリティ施策