要件定義
要件定義においてセキュリティというと、セキュリティ機能と実装する機能にセキュリティの問題が無いかを確認する必要があると思う。そこで、おのおの考えてみる。
機能要件のセキュリティ
機能の安全性を考慮する際、リスク分析するというのがあるが、これを行うのは非常に難しいし、手間がかかる。
そこで、アプリケーションで取り扱うデータのアクセス権をまず最初に定義し、各機能が取り扱うデータに対するアクセス権と先に定義したアクセス権で矛盾が無いかを確認する。これにより、比較的簡易に機能の安全性を確認することが出来ると思われる。また、誰が、どのデータにどう言ったことを行うかを明確にすることで、要求仕様の曖昧さを減らすことが出来るだろう。
それでは、どのような資料が必要か考えてみる。
データのアクセス権定義
まずはデータのアクセス権を定義するため、以下のような作業が必要と思われる。
- データの洗い出し
対象のアプリケーションで使用するデータが何かを洗い出す必要がある。この段階では、詳細な項目(アカウントの名前、住所、メールアドレスといったもの)は出せなくてもよいと思う。たとえば、個人情報、決済情報、注文情報、商品情報といった具合でも問題ないだろう。ただし、明確にアクセス権が異なるものについては同じ項目であっても分割しておいたほう(例えば、決済情報のうち、Cセキュリティコードは取り扱いが異なるので分けて考えるほうがよい)が後の作業が楽になる。 - ロールの洗い出し
対象のアプリケーションを使用するユーザーのロール(役割)を洗い出す必要がある。このロールをもとに各データのアクセス権を決定していけばよい。注意しないといけないのは、このユーザーのロールを洗い出す際、対象のアプリケーションのユーザーではない人や各ロールの補集合も洗い出すことである。また、アプリケーション管理者だけでなく、サーバー管理者もロールとして洗い出しておく。サーバー管理者であれば、仮に複合可能な暗号でデータが保存されていたとしても、閲覧することは可能だからである。 - データ管理者の定義
各データの管理者(大抵はそのデータを作成、登録したもの)を決める。 - アクセス権の定義
各データごとに洗い出したロールに対するアクセス権(読み込み、書き込みができるか)を決定する。なお、データ管理者には読み書きのアクセス権を通常与えるため、特に定義する必要はないと思われる。
この際、対象のデータを検索条件とする場合も読み込み権限が必要であることに注意が必要である。これはデータの内容を直接見ることはできなくても、検索条件としてデータの有無を調べることでそのデータが存在するかどうかを調べることにより、結果としてデータの内容を直接見ることと同じ効果を得られるからである。
アクセス権の定義はISMSで定義されている物を参考にすればよいだろう。
以上の作業を行うと、例えば、以下のような表ができる。
データ項目名 | データ管理者 | 一般ユーザーのアクセス権 | 一般ユーザー以外のアクセス権 | 対象店舗管理者のアクセス権 | 対象店舗以外の店舗管理者のアクセス権 | アプリケーション管理者のアクセス権 | サーバー管理者(システム)のアクセス権 |
個人情報 | ユーザー | なし | なし | 読み込み/書き込み | なし | 読み込み/書き込み | 読み込み/書き込み |
決済情報 | ユーザー | なし | なし | なし | なし | なし | なし |
注文情報 | ユーザー | なし | なし | 読み込み/書き込み | なし | 読み込み/書き込み | 読み込み/書き込み |
商品情報 | 店舗管理者 | 読み込み | 読み込み | 読み込み/書き込み | 読み込み | 読み込み/書き込み | 読み込み/書き込み |
店舗情報 | 店舗管理者 | 読み込み | 読み込み | 読み込み/書き込み | 読み込み | 読み込み/書き込み | 読み込み/書き込み |
機能要件の定義
機能要件はRFPに通常記述する。この際、以下のことを明確に記述する必要がある。
- 誰が(どのロールが)
- 何を(どのデータ項目を)
- どうする(読み込むのか、書き込むのか)
これらをRFP提出の際に表にしておくとわかりやすいのではないだろうか?
例えば、以下のようになるだろう。
機能名 | 誰が | 何を | どうする |
ユーザー登録 | ユーザー | 個人情報 | 編集する(書き込み) |
商品検索 | 誰もが | 商品情報 | 検索する(読み込み) |
決済情報登録 | ユーザー | 決済情報 | 編集する(書き込み) |
商品購入 | ユーザー | 注文情報 | 書き込む |
決済情報 | 参照する | ||
商品情報登録 | 店舗管理者 | 商品情報 | 編集する(書き込み) |
このように機能を書き出し、対象となるデータのアクセス権と必要な権限が矛盾していないか確認する。矛盾していた場合、機能変更、機能を実装しない、アクセス権を見直すなどの対策を行う必要がある。どうしても実装したい場合、RFPに記述しておき対策を受注者に検討してもらうという方法もある。この矛盾をどうするかに対する回答を出してくるかどうかで発注先を選定する基準にもすることができるだろう。
先の例の場合、特に矛盾がないように見えるが、「商品購入」機能において、ユーザーが保存した「決済情報」を参照するためには「システム」=「サーバー管理者」も「決済情報」を参照する必要がある。しかし、先のデータのアクセス権の定義では「サーバー管理者」にも「決済情報」はアクセスを許可していないため、矛盾する。これでは機能が提供できない。
この例では、「クレジットカードのセキュリティコード」も「決済情報」として想定していたとする。「クレジットカードのセキュリティコード」はカードの保持者以外には知られてはいけない情報であるため、ユーザー以外のロールにはアクセス権を付与していなかった。そこで、「決済情報」から「クレジットカードのセキュリティコード」を除外し、それ以外についてのアクセス権をもう一度定義しなおすことで、矛盾を解消することにする。
データ項目名 | データ管理者 | 一般ユーザーのアクセス権 | 一般ユーザー以外のアクセス権 | 対象店舗管理者のアクセス権 | 対象店舗以外の店舗管理者のアクセス権 | アプリケーション管理者のアクセス権 | サーバー管理者(システム)のアクセス権 |
決済情報 | ユーザー | なし | なし | なし | なし | なし | 読み込み |
セキュリティコード | ユーザー | なし | なし | なし | なし | なし | なし |
これにより、システムでの読み込みが可能になり、矛盾がなくなり、機能実装を行うことができるようになる。
最初に定義したデータのアクセス権を変更することは、セキュリティホールを作ることになるので、あまり好ましくない。これはどうしても実装したい機能が実装できない場合に限るべきである。
機能要件のセキュリティまとめ
機能要件がセキュリティホールになることを減らすには以下のことを検討し、RFPに資料としておくと発注側も注意すべき点が明確になるため、齟齬が起こりにくくなると思われる。
- 使用するデータのアクセス権を定義する
- 各機能要件において「誰が」「何を」「どうする」かを明確に記述する
- 1.と2.で矛盾が存在しないか確認し、必要に応じて、機能の変更、データ分類の再検討、機能の削除を行う