ITエンジニア必読書『徳丸本』が8年ぶりの改訂へ 「第3版」のポイントを筆者が解説：「個人情報漏えい」から「事業被害」へのシフトに対応（2/2 ページ）

[高橋睦美, 編集：石川俊明，＠IT]

自問自答を続けてきた「セキュリティ要件」も整理して記述

　徳丸本第3版では、このように注目度の高い脆弱性の解説が盛り込まれるとともに、冒頭でも言及したように、安全なWebサービスを作るための「セキュリティ要件」に関する記述が大幅に加筆される予定だ。

　これまで、セキュリティ要件の検討が不足したまま開発が進み、サービスとしてリリースされた結果、不正利用が発生してサービス終了に追い込まれた「残念なWebサービス」が幾つか存在してきた。そうした事態を防ぐには、発注段階からセキュリティ要件を明確にし、それに沿って開発を進めるべきという考え方が浸透しつつある。

　だが「そもそも、セキュリティ要件は誰がどう決めるのかが、実はあまりはっきりしていません。発注仕様書に書いてある場合もありますが、『個人情報が漏れないように作りなさい』というような、当たり前であいまいなことが書いてあるだけです。これだけでは見積もりもできなければテストもできず、セキュリティ要件とはいえないでしょう」と徳丸氏は課題を提起した。

　そこで第3版では、徳丸氏自身、初版を出版した当時から自問自答を続けてきたテーマであるセキュリティ要件を、以下の4つの観点に整理し説明する予定だという。

1. セキュリティバグ（SQLインジェクションなどの狭義の脆弱性）
2. 汎用（はんよう）セキュリティ機能の実装（認証・認可機能やログ機能など）
3. 業界の規制・ガイドライン（「PCI DSS」やキャッシュレス推進協議会のガイドラインなど）
4. アプリケーション固有の脅威への対策

　このうち、1から3までの観点については、どのようなWebアプリケーションにも共通するもので、徳丸本でも言及されてきた。問題は4点目の「アプリ固有の脅威への対策」だと徳丸氏は述べた。

誰もリストにしてくれない、自分で分析するしかないのがアプリケーション固有の脅威（徳丸氏の講演資料より）

　Webアプリケーションには、登場当初の「CRUDを簡単に作れる、掲示板みたいなもの」というイメージがつきまとってきた。それゆえに、アプリケーションごとの固有のリスクを把握する必要性がなかなか認識されにくい背景があった。

　しかし今やWebアプリケーションは、生活にもビジネスにも深く関わり、レストランでの注文にも、チケット販売にも活用されている。「こうなると、転売業者がbotを使って人気商品を大量に買い占める問題のように、細かくばらせば既知の課題かもしれないけれども、Webシステム全体として見るとビジネスロジック全体の問題をどう防ぐかという課題が浮上します」（徳丸氏）

　これこそが、1〜3の問題のようにこれまで「リスト化」されてこなかった、「アプリケーション固有の脅威」だ。徳丸本第3版では、このアプリ固有の問題に言及し、それぞれのビジネスロジックに固有の脅威を洗い出す道具としての「リスク分析」にも触れていく予定だという。

　「アプリケーション固有の脅威をできるだけ早く検討・対策を実行し、もしお金がかかるのであれば予算も手当しておくべきです。シフトレフトで、上流で実施すべき重要な事柄と言えるでしょう」（徳丸氏）

リスク分析を通してアプリケーション固有の脅威と対策を定義

　アプリケーション固有の脅威に限らず、観点1や2を検討する際に参考になるのが「OWASP ASVS 5.0」だ。この中には「初めにリスク分析をして要件を決めるべき」という記述もある。

　例えばセッションタイムアウトの時間一つ取っても、オンラインバンキングのようなサービスの場合、3時間では「長過ぎる」と言えるが、頻繁に利用されるSNSでは利便性が損なわれてしまう。「必ず守るべき項目は抑えつつ、各Webサイトの裁量で決めるべき部分もあり、後者を検討する上でリスク分析が必要になります」と徳丸氏は説明した。

　そのリスク分析だが、まず「われわれのアプリケーションのゴールは何か」という目指す姿について合意した後、資産・機能の洗い出し、脅威の洗い出し、影響度・発生可能性の評価、対応方針と対応の検討を経てセキュリティ要件を定義するという流れが一般的だ。

　徳丸氏はこの際のポイントとして、「情報資産だけでなく、機能や機能にひも付く事業被害を洗い出すこと」を挙げた。そこにはビジネス・経営的な観点も求められてくる。

　「サービスの目指す姿の合意においては、DevやOpsに加え、Biz、つまり事業主体が非常に重要です。『全てのセキュリティは経営マターだ』と考えるのであれば、ここに事業側の責任者を連れてくる必要があります」（徳丸氏）

　脅威の洗い出しにおいては、「なりすまし」「否認」「サービス妨害」なども考えられるWebサービスの特性を考えると、「STRIDE」という脅威分析モデルが参考になるという。

　ただ、先述した「転売業者がbotを使って大量購入するケース」のように、テクニカルな脆弱性というよりも正規の機能を悪用される脅威は、こうした枠組みからはみ出てしまう。「こうした事柄は、無理にこじつけてSTRIDEに載せるぐらいだったら言葉で書き、『STRIDEプラス1』でビジネスの問題として考える方がいいのではないでしょうか」（徳丸氏）

　徳丸氏はさらに、リスク分析における4種類のアプローチと、「回避」「低減」「移転」「受容」というリスク対応の4つの方針を紹介した。このプロセスを実施する際には、最終的には人間が判断を下す必要があるが、AIを壁打ちに利用するのも非常に便利だという。

　こうした説明に続けて、ワークショップという名の通り、「レストランにおけるモバイルオーダーシステム」を例にして脅威の洗い出しと評価をする時間が設けられた。

　脅威の洗い出しをしようにも、中には、「脅威と言ってもなかなか分からない」という人もいるだろう。そうした場合のヒントとして徳丸氏は、「Webサービスに関わる関係者にはどのような人がいるかを想像し、それぞれの立場で考える」「過去に発生した事例を調べ、蓄積しておく」といったポイントを紹介した。

　またアプリケーション固有のリスクと言っても、パーツに分解していくと他でも似たようなインシデントは起こっている。このため、隣接領域で発生した事例を把握し、参考にするのも有効だとした。

　脅威の評価においては、「もしこうした事象が発生したらどれくらい困るのか」を3段階程度で分類し、発生可能性と掛け合わせてリスクの度合いを評価していく。ワークショップでの例で言えば、「悪意ある顧客が、他人のテーブルのQRコードを読み込んで注文する脅威の影響は中程度、発生可能性は高」といった具合だ。

　その上で、解決策を検討していくことになる。このとき「セキュリティ原理主義」に走らず、ビジネス的な視点も考慮しながら、場合によっては一定のリスクを受容したり、システム的な改善だけでなく運用での回避も念頭に置くこともポイントだとした。

　「『運用で対応』というと批判されがちですが、必ずしもそうとは限りません。運用で効率的に対応できるのであればそれも選択肢の一つです」と徳丸氏は述べた。

　ただ「こうして列挙した対策がそのまま要件定義書に載るわけではない」とも同氏は説明した。対策をそのまま記載してしまうと、「なぜそれが必要か」という観点が失われてしまうためだ。

　「対策と要件を区別し、対策を、満たすべき状態としての要件に変換していきます」（徳丸氏）

　だがこれも、あまりに抽象的な記述になっては、何をどうしたらよいのか分からなくなり意味がなくなるため、あくまで「検証可能」な形で記述することがポイントだという。「要件からテストまでを一気通貫でできるようにする記述が望ましい」と徳丸氏は説明した。

対策を「満たすべき条件と検証方法」の形に言い換える（徳丸氏の講演資料より）

　そして、開発の「ど頭」である最上流のステップでリスク分析をすることにより、その結果に基づいて固有の要件を追加したり、汎用的なセキュリティ機能についてもどの程度満たせばよいかの水準を選択したりできる。「アジャイル開発といえども、サービスの全体像を踏まえてどのようなリスクがあるかを上流で考えなければいけません」（徳丸氏）

　徳丸本第3版では、こうしたリスク分析の指標として、OWASP ASVS 5.0の他、フランス国立情報局が作成した「EBIOS」というフレームワークを紹介し、説明していく予定だ。

　これまではどうしてもふんわりとした議論に陥りがちだったセキュリティ要件だが、アプリケーション固有の脅威も含めた4つの観点で整理することでより考えやすくなる。その際には、ビジネス・事業責任者も巻き込んで検討することが重要だ。

　徳丸氏はこのように説明した上で、「日頃からリスクや脅威に対する思考を鍛え、習慣化しておくことが大切です。単純なものでも、短時間でもよいので、ぜひ手を動かしてみてください」と述べ、新版を参考にしながら実践してほしいと講演を締めくくった。