「セキュリティ対策は大事だ」。そう分かっていても、どこかで「メインはシステム本体の開発、セキュリティは二の次」「セキュリティ対策は後から考えればよい」といった意識を持っていないだろうか。そんな意識が、セキュリティ設計に思わぬ間違いを生み、システムの脆弱性を作り込む。
悪人になって攻撃
一つ目の間違いは、システムの機能を利用者視点でしか考えないというものだ。要件定義において、利用者に提供する機能はきちんと洗い出したとしても、その機能が悪用されたらどうなるかを逐一チェックしているだろうか。セキュリティ設計は本来、悪意を持った者がシステムを利用しようとするのを防ぐ対策を考えること。業務要件をまとめるための正規利用者の視点でシステムを見ている限り、起こり得るリスクは洗い出しきれない。
正規利用者に提供する機能を洗い出すには「ユースケース図」がよく用いられる。ユーザーや外部システムを表す「アクター」を配置し、そのシステムの利用法である「ユースケース」、つまり業務要件を記入していく手法だ。
同じ図に、悪意のあるユーザーを登場させれば、リスクを洗い出し、対策を立てられる。そんな考え方でセキュリティ要件を洗い出す手法が「ミスユースケース図」。それを実際の現場で活用しているのがみずほ情報総研の金子浩之氏（情報セキュリティ評価室 室長）である。金子氏は「ミスユースケース図を使えば、社内犯罪などの可能性まで洗い出して対策を練ることができる」と効果を説明する。
ミスユースケース図では通常のアクターとユースケースに加え、システムで守りたい資産と、それを狙う不正ユーザーをアクターとして書き入れる（図3）。次に不正ユーザーが資産を狙うリスクを考え、対策とセットにして書き加えていく。
図3は、複合機に保存される文書を守るためのセキュリティ対策を洗い出したものだ。守りたい資産として「機密性のある文書」を書き入れ、それを狙う不正ユーザーを図中に配置している。資産が狙われるリスクとしては、「正規ユーザーになりすまして不正閲覧」が考えられる。対策となるセキュリティ要件「ユーザー認証機能」とセットで図に記入する。ユーザー認証機能を設ければ、「ユーザー情報（IDとパスワード）」という守りたい資産が新たに出てくる。これも書き入れる。
こうして不正ユーザーの視点で図を眺め、「ユーザーが離席時に不正操作」「パスワードをクラックする」といったリスクを洗い出し、対策と一緒に記入していく。これで必要なセキュリティ要件を漏れなく洗い出せる。
