「セキュリティ対策はシステム開発で不可欠だが、設計書でうまく表現できている開発現場はまだ少ない」――。
ラックの永井英徳氏（エンタープライズ・セキュリティサービス事業部セキュリティディレクションサービス部長 兼 第一グループ部長）はこう指摘する。よく見られるのが、「クロスサイトスクリプティングの脅威には、Aフレームワークを利用することで対処する」などと、個別の脅威ごとに対策を記述するケースという。しかしこれでは、「システム全体として必要なセキュリティ対策を網羅できているのか判断しにくい」（永井氏）。
とはいえ、機能に関する設計書に、想定しうるあらゆる脅威の内容と対策を書き込むのも問題だ。記述が膨大になり、読みにくい設計書になってしまう。後工程の開発メンバーの作業ミスを招く恐れがある。セキュリティ要件が変わったときの修正作業の負荷も大きい。
このような問題意識のもと、ラックの永井氏は、セキュリティ対策の網羅性の担保しやすさと、読み手にとっての分かりやすさを両立する「セキュリティ設計書」を考案した。すごい設計書と呼べるもので、目的別に「アクセス相関図」「セキュリティ要件一覧」「ガイドライン」という3点セットを作成している。
アクセス相関図で「どこの何を守ればよいか」、セキュリティ要件一覧で「どう守ればよいか」を整理。ガイドラインは開発に迷わないようにするものだ。セキュリティ対策に関連するAPI（アプリケーション・プログラミング・インタフェース）は要件とリンクさせている。「後でセキュリティ要件が変わったときもどのAPIと関連するのかが分かるので、修正しやすい」（永井氏）という。
どこを守るかを網羅するアクセス相関図
1つめのアクセス相関図は、システムを開発するに当たり、どこを守る必要があるかを理解しやすくするための表だ（図1）。システムが取り扱うデータの流れを分析し、起こりうる脅威を検討する。
縦軸の1列目「利用者」は、システムで取り扱うデータにアクセスする様々なアクター（ユーザーやシステム）を記入する。一般のユーザーに当たる「システム利用者」や、システムの運用を担当する「システム運用管理者」などだ。外部公開するWebサーバーなどがあれば、それらにアクセスする顧客などのアクターも記入する。
2列目の保存場所は、その名の通りデータを保存している場所を洗い出す。データベース（DB）のテーブルのほか、各種のログ、帳票、設定ファイルなどが当てはまる。3列目の「システムが保存する情報」にはデータの内容を記入する。
横軸には、データにアクセスする経路や通信プロトコルを記入する。永井氏はまず経路別に「外部」と「内部」に分けた上で、通信プロトコルごとに項目を用意している。
この表の各セルに、誰が、どの経路からどんなデータにアクセスするのかを記入する。書き込みや参照があるデータは、内容に応じて「CRUD（登録・参照・更新・削除）」を、またアクセスさせないデータには「×」を記入する。「DB設計書のCRUD図をシステム全体に広げたようなもの」と永井氏は説明する。
表形式にすると、「それぞれのアクターがどのデータにどの経路からアクセスしてくるのか。その際にどんな行動を取れるのかを網羅的に把握しやすい」（永井氏）。把握することによって、どのデータを守らなければならないのか、設計書の読み手である関係者が判断できるという。
