情報の価値に応じてメリハリを付ける

 対策を検討するときは,情報を重要度や価値に応じて分類し,リスクの大小を見極めてメリハリを付けます。メリハリを意識したヒアリングの実践例が,図1です。留意したいのは,機密性と可用性がトレードオフの関係になりやすいということです。例えば,USBキーによる情報の持ち出しを考えてください。すべての情報の持ち出しを全面的に禁止すれば,機密性は高まりますが,重要でない情報の持ち出しまで不可能になり,可用性は下がってしまいます。

図1●情報の価値に基づき機密レベルを設定するヒアリングの例
図1●情報の価値に基づき機密レベルを設定するヒアリングの例
Webシステムで取り扱う情報を確認,それぞれの情報の価値を確認,それぞれの情報に機密レベルを設定――の順に実施する。機密レベルが明確になれば,取るべき脅威の緩和策(=セキュリティ対策)は明確になりやすい
[画像のクリックで拡大表示]

 このようにトレードオフを選択しなければならない場面では,「リスク」を考慮します。情報の重要性が高い,漏洩したときの被害が甚大である,攻撃の再現が容易で誰もが実施できる――といったケースはリスクが高いととらえ,可用性を犠牲にしてでも,機密性の確保を優先すべきです。

 図1の例では最初に,Webシステムで取り扱う情報を利用者や発注者に認識してもらい,それぞれの情報ごとに価値を判断してもらっています。そうした価値を,具体的なコストに換算すると対策を立てやすくなります。例えば顧客情報の漏洩であれば,顧客への事情説明や謝罪のために担当者の業務が何日止まり,機会損失はいくらに相当するかなどを考えてもらうようにします。このようにして情報の価値を検討したら,3~4段階程度の機密レベルに分類し,機密レベルが高いものから優先的に対策します。

 情報を機密レベルごとに分類することで,自然に機密性と可用性のトレードオフが決まるはずです。例えば,機密レベルが高い顧客情報テーブルについては,特別な権限保有者しかアクセスできないようにしたり,顧客情報テーブルを暗号化したりして,機密性を優先します。一方,顧客情報以外のテーブルについては,可用性を保つために暗号化は見送ることも考えられます。その場合,データベース全体の暗号化はしないというセキュリティ対策も明確になります。

対策のポイントは三つの観点

 洗い出したセキュリティ要件に合わせて適切な対策を実施します。対策は開発段階ですべて完了するわけではなく,運用段階で着手するものもあります。要件定義→基本設計→詳細設計→実装→テスト→運用という,Webシステムのライフサイクル全体を通じて,対策を検討しなければなりません(図2)。

図2●システム・ライフサイクルにおけるセキュリティ対策
図2●システム・ライフサイクルにおけるセキュリティ対策
上流から下流に至る各工程で対策しないと,セキュリティを維持することは難しい。特に,セキュリティ・ポリシーの設定からアーキテクチャ設計までを軽視すると,カットオーバー後のシステム改修で脆弱性が紛れ込むといったトラブルを起こしやすい
[画像のクリックで拡大表示]

 セキュリティ要件からシステムの仕様を検討する際,「物理的」「技術的」「運用管理」という三つの観点を持つことが肝心です。基本設計フェーズで実施するアーキテクチャ設計で説明しましょう。

 物理的対策としては,データベース・サーバーを専用ルームに隔離するといったファシリティ設計や,ファイアウォールや侵入検知システム(IDS)を設置するといったネットワーク設計を試みます。例えば,不必要なTCP/UDPポートをファイアウォールで遮断して不正アクセスを防いだり,回線上でデータを盗み見されないようにSSL(Secure Sockets Layer)で暗号化したり,といった対策を検討します。

 技術的対策は,システム基盤(ファシリティ,回線,ハードウエア,OS,ミドルウエアなど)だけでは実現できない,アプリケーション上の対策を指します。例えば,認証やアクセス制御の方式設計,データベースに格納する個々のデータの暗号/復号方式などを決定します。運用管理における対策として,セキュリティ・ポリシーやセキュリティ要件を満たす運用ルールを取り決めます。サーバー・ルームへの入退出の管理方法や,セキュリティ・パッチの適用方法,バックアップ・データの取得方法と保管方法――などを明確にします。アクセスや操作の痕跡を記録したログの監視体制も必要でしょう。

 こうした設計内容に基づき,詳細設計で仕様を掘り下げ,実装とテストを進めます。実装に当たっては,技術的対策として,コーディング規約などで脆弱性が混入しにくいように規制する一方,アプリケーションそのものが脆弱にならないように「セキュア・プログラミング」を徹底します。テスト・フェーズでは,物理的対策と技術的対策の両面から,既知の攻撃に対する脆弱性やバグがないかを検証します。運用管理対策として,運用設計と合致しているかどうかを受け入れテストでチェックしましょう。

 物理的対策,技術的対策,運用管理対策は,それぞれ別個に実施するのではなく,相互補完的な関係にあります。例えば,物理的対策や技術的対策として,アクセス履歴をログに記録していても,運用管理対策であるログの監視や分析が不十分では,セキュリティは保てません。相関する対策がきちんと実施されてこそ,セキュアなWebシステムを実現できるのです。

高安 厚思(たかやす あつし) オープンストリーム テクニカルコンピテンシーユニット 主管システムズアーキテクト
銀行系シンクタンクでオブジェクト指向技術の研究に携わった後,大手SI業者でアーキテクチャ構築やプロセス研究を担当。現職ではSOA(Service Oriented Architecture)を中心とする研究開発とアーキテクチャ構築に従事している

椎野 峻輔(しいの しゅんすけ) システム・コンサルタント(セキュリティ監修)
大手SI業者でシステム構築を経験後,ベンチャー企業に転身。システム導入コンサルティングから,開発・運用,セキュリティ診断まで,幅広い領域を担当する