前回は、攻撃経路別にWebサイトの安全性を高める施策についてまとめた。ここでは、アプリ発注者・開発者の必修事項、開発マネジメントにおけるセキュリティ施策についてまとめる。
１ 開発マネジメントにおけるセキュリティ施策の全体像
開発マネジメントは、開発体制と開発プロセスの両面から押さえる必要がある。開発プロセスのフェーズ（企画・発注から運用まで）ごとに以下の10項目に分けて、発注者と受注者の双方の立場から見ていく（発注者：発、受注者：受と表記）。
- プロジェクト開始以前：受−開発体制の強化（開発標準の策定、開発者の教育、セキュリティ担当者の育成）
- 企画：発−重要なセキュリティ機能の検討、RFPなどにより概算把握、セキュリティ予算確保。受−RFI回答でセキュリティの重要性をアピール
- 発注：発−セキュリティ要件の明確化、RFPの作成・提示、ベンダー選定。受−セキュリティ要件の実現方法、開発体制・テスト手法の説明、開発標準などの説明
- 要件定義：受−セキュリティ要件の確定、プロジェクトセキュリティ標準の作成
- 基本設計：受−セキュリティ機能は要件からウォータフォール型で詳細化、セキュリティバグは方式設計として開発標準の詳細化
- 詳細設計：受−設計レビューにより開発標準遵守のチェック
- プログラミング：コードレビューにより開発標準遵守のチェック
- テスト：受−セキュリティテストにより脆弱性の把握、機能テストによりセキュリティ要件の妥当性確認
- 検収：発−セキュリティ要件は検収工程で確認する
- 運用・保守：発−脆弱性情報監視、パッチ適用
２ 開発体制
開発体制は、開発標準という文書（モノ）と訓練されたチーム（人）の両面から整備する必要がある。
開発標準の策定
よい開発基準の条件
- 厚すぎないこと（実効性の高い項目にしぼる）
- 参照すべきページがすぐ見つかること
- 実施すべき内容が明確であること
- 継続的に改善していること
記載すべき重要項目
- 脆弱性ごとの対処方法
- 認証、セッション管理、ログ出力などの実装方式
- 各フェーズでのレビューとテストの方法（いつ、誰が、何を、どうやって）
- 出荷（公開）判定基準（誰が、いつ、どの基準で許可するか）
教育−セキュリティ担当者の育成
- 開発標準自体の工夫（前述）
- チーム内の開発標準教育（事件事例の紹介、主要な脆弱性の原理と影響、遵守すべき事項）
- 設計レビュー、コードレビューによる遵守状況チェック
３ 開発プロセス
企画段階の留意点
開発に必要な予算を見積もり、確保することが重要。そのためにRFI（Request For Information;情報提供要求書）を作成して、ベンダーにアプリケーションの概要と重要情報一覧を示し、セキュリティ向上のために重要な施策と概算の情報提供を依頼する場合がある。
発注時の留意点
RFP（Request For Proposal;提案依頼書）を作成して、提案と見積を要求すること。セキュリティ要件もRFPに記述する。例えば以下のように具体的に要求するとよい。
- 対処の必要な脆弱性名を列挙する
- 検収方法・基準を明示する
- 追加で必要な対策があれば提案するよう求める
- セキュリティテスト方法の提案を求め、テスト結果を成果物として要求する
- 検収後に発見された脆弱性の対応方法と費用負担を明確にする
- 開発体制についての説明を求める
- 開発標準とセキュリティテスト報告書のサンプルを要求する
要件定義時の留意点
このフェーズ以降は作業の主体が受注者となる。要件定義においても、セキュリティ機能とセキュリティバグを分けて整理することが重要である。セキュリティ機能は、発注仕様から要件を定義する。セキュリティバグ対策は、受注者（開発会社）の開発標準をベースとする。開発者の再教育が必要となり開発コストが上昇するからである。以上を含め、具体的には以下の5つを中心に検討するといいだろう。
- 認証、アカウント管理、認可の要件
- ログ管理の要件
- その他のセキュリティ機能についての要件
- 基盤ソフトウェアの選定とパッチ適用の方針決定
- 開発標準のセキュリティ要求に対するギャップ分析
基本設計の進め方
- セキュリティ機能に対する具体化
- 方式設計として開発標準の詳細化、テスト方式の決定
- 画面設計時のセキュリティ機能の確認（CSRF対策の必要な画面の洗い出し、HTTPSにするページの洗い出し）
詳細設計・プログラミング時の留意点
基本設計に従って設計、開発する。レビューは抜き取りでもよいので実施すべき。
セキュリティテストの重要性と方法
- 専門家に脆弱性診断を依頼する
- 専用ツールを用いて診断する
- 自力で診断する→以下に例を紹介
ウェブ健康診断仕様の紹介
ウェブ健康診断とは、地方自治情報センター（LASDEC）が地方公共団体向けに実施しているWebサイトの脆弱性診断である。精密な脆弱性診断を受診する必要があるかどうかを診断するための簡易検査という位置づけになる。特徴は以下の通り。
- 危険度の高い脆弱性12項目を網羅している
- 診断仕様、判定基準、抜き取り基準が明確に定義されている
- Fiddlerなどの無償ツールのみで診断できる
- 本番稼働サイトの診断を前提とした安全性の高い診断仕様である
- 脆弱性の影響の大きさや範囲は判定しない
- あくまで簡易検査であり、高度な手法については検査しない
受注者側テスト
- ソースコード検査：目視あるいは検索ツール（grepなど）を使ってソースコードを調べるもの。SQLインジェクション脆弱性、ディレクトリ・トラバーサル脆弱性、OSコマンド・インジェクション脆弱性の調査に向いている
- ツールによるブラックボックス検査
- 手動によるブラックボックス検査
発注者側テスト（検収）
- 受注者のセキュリティ検査報告書を精査する（書類チェック）
- 第三者（専門家）に検査を依頼する
- 自ら検査する
運用フェーズの留意点
- ログの監視：iLogScannerなどのログ解析ツールの運用により、攻撃の予兆を把握できる場合がある
- 脆弱性対処：プラットフォームとアプリケーションで対処の方法が異なる。プラットフォームでは脆弱性情報を監視して、適時の対処（パッチ適用など）を行うことが重要。アプリケーションでは定期的な脆弱性診断やログ分析により早期解決すること
最後に
発注者側としては、RFPなどにセキュリティ要件とセキュリティバグに関する要求を記載するとともに、検収としてセキュリティ検査を実施することが求められる。開発者側としては、開発ガイドライン作成と開発メンバーの教育による体制の整備と、安全なアプリケーションを作り込む開発プロセスの整備が重要となる。
14回にわたって、徳丸 浩著「体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践」についてまとめた。著書は、脆弱性が生まれる原理と対策の実践について、実習環境を作成しながら体系的に学ぶことができる。SQLインジェクション、クロスサイト・スクリプティング、セッションハイジャックなど、Webプログラマが知っておくべき攻撃と防御の知識を解説している。興味を持った方は、ぜひ読んでみてほしい。
 |
