キャッシュレス決済サービスに関連した不正引き出し事件が世間を騒がせています。最初はドコモ口座の問題として扱われましたが、連携している銀行側の問題に視点が移り、各種スマホ決済サービスも巻き込んだ大きな問題に発展しています。銀行口座番号と暗証番号がわかれば犯罪が成立してしまう場合があること、SMS認証をしていても銀行の口座を持っている本人を認証する仕組みになっていないことなど、脆弱な箇所があったようです。
これらの仕組みを導入するうえでどのようなセキュリティ対策の検討が行われたのかはわからず、この件での深掘りはしませんが、一般的に企業でITを導入する際のセキュリティ検討プロセスには、疑問を感じることが多くあります。本投稿では上記事件とは別として、IT導入時によくあるセキュリティ検討の問題に触れてみたいと思います。
一般的に業務システムや情報系システムなどの導入では、非機能要件定義の中でセキュリティについての要件を定義します。例えば、以下のようなテーマについて、システムに必要なセキュリティ対策を検討します。
弊社はユーザー企業側の立場で、導入ベンダーが主導する非機能要件定義の場に参加することがよくあるのですが、ほとんどの場合、「パスワードポリシーはどうしますか?」、「データを暗号化できますが、どうしますか?」、「この役割にこの権限を割り当てますが、いいですか?」など、単発の確認の連続になります。しかし、このように聞かれても、適切に判断することは困難です。どのくらいガチガチに設定すべきなのか、ここを緩めたら何がまずくなるのか、などがわからずにとりあえず個別個別で決めてしまうと、結果的にデコボコの激しい、不適切なセキュリティ対策になってしまいます。
足りないのは、リスクという観点です。リスクという観点でのセキュリティ対策の大まかな流れを表現すると、以下のようになります。
この流れの3で、ようやく「認証をどのような方法で行うべきか?」、「データを暗号化すべきか?」などの対策手段が見えてきます。そのため、要件定義の場でいきなりこれらのことを聞かれても、リスクを明確化できていないため、答えるのが困難なのです。
問題は、「上記1~3を誰が行うべきか?」です。以前の投稿「効果的なIT導入に向けて ~「シナリオ」の活用~」でも書きましたが、導入ベンダーとしてのゴールは「製品の導入」です。導入する製品の数々の機能から逆算し、最終的に細かい設定項目を明確にするための設計を行い、その設計につなげるための要件定義を行います。そこにはリスクという発想は少なく、導入するための設計、導入するための要件定義になってしまいます。
上記のようなリスク観点での検討を抜いてセキュリティ要件を定義してしまうと、むやみに多重防御が厚い箇所と、対策が不十分な箇所が生まれてしまい、適切とは言えない環境になってしまいます。導入ベンダー側でリスク観点での検討が行われないことを想定し、ユーザー企業としてこのプロセスを確立し、いつでも実施できるようにしておくことをお勧めします。