セキュリティ要件をどうRFPに盛り込むか：Webシステムのセキュリティ要件（2） （2/2 ページ）

[丸山 司郎（株式会社ラック），＠IT]

セキュリティ要求仕様のレベル

　JNSAのセキュリティ要求仕様は、できるだけ多くの発注者が、これを参考にして実際にセキュリテ ィに関する要件をシステム提案依頼に含められるようにすることを目的としている。ここで問題となるのは、発注者、受注者の双方で、セキュリティに関するリテラシーのレベルがさまざまだということである。

　そこで、JNSAのワーキンググループでは次の3つのタイプのセキュリティ要件を提示し、RFPを作成する人に、自社にとって一番使いやすいものを選択してもらう方式とすることにした。それぞれの具体的な要件については直接参照してもらうとして、ここでは、各タイプの特徴を説明し、それぞれが持つ発注者、受注者にとってのメリット、デメリットを説明したい。

1対策手法の視点

　技術的な視点、あるいはシステムを開発するベンダ側の視点から作成した要求仕様であり、現状で一般的に検討されているセキュリティ対策を列挙するような形式となっている。

　提案を依頼する側が、提案を行う側の視点で要求仕様を作成するということ自体に矛盾があるが、情報セキュリティ対策に関する「一般常識」が醸成されていない現在においては、RFPを記載する発注者が理解できるのであれば、現実解としては有効なものと考えている。

2現象面の視点

　システムの開発を委託する発注者側の視点から作成した要求仕様であり、本来あるべき姿を目指したものである。

　この場合、記載事項をどこまで具体化できるかが課題となる。例えば、現実には十分な対策が不可能であるDoS攻撃への対策については、開発ベンダ側に、「要求仕様には記載されているが実現できない要件」として説明する責任が発生してくる。しかし、ベンダが営利を目的して提案を行っている中で、これを説明するのはかなり困難であろうと考えられる。

3脅威モデルの視点

　システムの開発を委託する発注者側、つまり、システムのオーナーがWebシステムを所有するに当たって、想定されるリスクを列挙したものである。パターン2の「現象面の視点」を推し進めたものであり、発注者からすると受注者側に丸投げする形態となる。しかし、取りあえずこのレベルからでも始めるべきであるという意味も込めて提示している。

　各パターンの特徴をまとめると、以下のようになる。RFPを作成する人が、おのおのの特徴を理解したうえで、分かりやすく、使いやすいパターンを選択してもらえればと考えている。

	発注者		受注者
	メリット	デメリット	メリット	デメリット
対策手法の視点	-	網羅性が不明	提案しやすい	他社との優位性を出しにくい
現象面の視点	分かりやすい	-	-	できないことの説明が必要
脅威モデルの視点	簡単であり、書きやすい	提案にばらつきがあり、評価が困難	-	提案内容によっては責任範囲が広くなる

特定Webシステムを想定したRFPの記載例

　それでは実際に、RFPに記載するセキュリティ要求事項を検討してみよう。まず、対象となるシステム要件を以下のように仮定する。

ウエブアップ社　Webシステムの全面改訂

概要： A社は、売上高10億円、従業員数50名の製造業である。もともと社内のシステムに詳しい人間が、社内システムの運用管理と併せ、自社のWeb サイトも作成運用してきたが、システムの償却期限到来に合わせ、外部の開発業者に委託して、Webシステムを刷新するとともに、自社製品の紹介、販売にも可能なシステムの構築を検討することとなった。

　以上の前提を基に、パターン2「現象面の視点」を使った、RFPセキュリティ要件を挙げる。

　まず、システムの類型を考えると、インターネットへの公開は行い、広く一般への宣伝を目的とするのと同時に、自社製品の販売を考えることから、ユーザー登録を前提とした会員制サイトを構築することになる。ここでWebを使ったユーザー登録が必要となることから、個人情報をWebシステムで保有することとなり、機密情報を取り扱うということになる。

• インターネットなどの外部公開 　　あり
• 機密情報（個人情報、決済情報など）　　 あり
• システムの利用者 　　-

　以上の条件を基に、JNSA「Webシステム　セキュリティ要求仕様（RFP）」の中の、「パターン2：　現象面の視点からの必須度マトリクス」を参照し、該当する列を抜き出す。そして、「任意」もしくは「推奨」となっている部分の必要性を吟味して、以下のようなセキュリティ要求仕様を作成してもらいたい。

1. システムダウン・レスポンス低下防止策

・DoS、DDoS攻撃によるシステムダウン、レスポンス低下	任意
・アクセス集中によるシステム／サービスのダウン、レスポンス低下	任意
・OSのバグやセキュリティホールを利用した攻撃によるシステムダウン、レスポンス低下	推奨
・不正侵入による悪意あるシステムダウン	必須
・故意／過失による高負荷処理に耐えられる構成	推奨

2. なりすまし・否認防止策

・ユーザーIDやパスワードの推測、盗聴	必須
・セッションハイジャック	必須
・クロスサイトリクエストフォージュリ	必須
・事後否認の防止	推奨

3. 漏えい対策

・通信経路上の盗聴	必須
・万一、データ盗難が起きた場合における安全策	推奨
・正常な操作（権限を有する操作）における情報漏えい	必須
・人的ミスによる情報漏えい	推奨

4. 改ざん防止対策

・通信経路上での通信データの改ざん	必須
・コンテンツやデータの改ざん	必須
・各種ログファイルの改ざん	必須

5. ユーザーへの被害対策

・クロスサイトスクリプティング	必須
・フィッシング	必須
・ウイルス・ワーム・スパイウェア等のユーザー・閲覧者への感染	必須
・迷惑メール対策（本システムが迷惑メールの発信に悪用されないこと）	必須

6. 脆弱性対策

・Webアプリケーションの脆弱性を利用した不正アクセス	必須
・OSやミドルウェア等のパッチを適用するための適切な構成・対策	必須
・脆弱なサービスや設定による不正アクセスを防ぐ（要塞化）	必須

7. 内部者対策

・内部者による故意の情報漏えい・改ざん等の防止	推奨
・内部者による故意の情報漏えい・改ざん等の抑止	必須
・内部者のミスオペレーションに起因する漏えいや設定ミス等の防止	必須

8. 全般的な対策

・攻撃検知・防御機能	推奨
・ログ・監査証跡の取得。システムのログ、アクセスログ、操作ログなどについてそれぞれどの項目・操作について取得するかを明確化すること	必須
・バックアップデータの保護策	推奨

9. セキュリティ運用

上記すべての対策に関して、セキュリティを維持・向上するための運用設計を行うこと	必須

事件に遭遇してからでは遅い

　 筆者は仕事上、昨年より多発している、インターネットからの攻撃による個人情報流出事件などで緊急出動を行い、対応や復旧の支援をしている。その中で、出動先のほとんどの人から、「アプリケーションで必要とされるセキュリティ対策を前もって分かっていればよかった」という意見をもらっている。このような事件が減少していくために、JNSAワーキンググループで検討してきた成果が少しでもお役に立てば幸いである。

著者

丸山 司郎株式会社ラック　JNSA セキュアシステム開発ガイドライン作成ワーキンググループリーダー

著者紹介

▼著者名　丸山 司郎（まるやま しろう）

株式会社ラックにおいて、情報セキュリティ全般に関するコンサルティングを担当しており、昨年からは個人情報漏えい事件などの緊急対応のマネジメントを行っている。主たる業務経験として、金融機関における大型汎用機システムの開発・保守を担当してきたことから、近年のWebシステムにおけるセキュリティ対策の脆さについて危惧をいだいている。

「Webシステムのセキュリティ要件」バックナンバー

• セキュリティ要件をどうRFPに盛り込むか
• Webシステム開発でセキュリティが軽視される理由