企画・設計の段階からセキュリティを考慮する「Security by Design」は、以前からある概念だが、近年、デジタルビジネスの進展に伴いサービス仕様の不備に起因する事故が多発したことを背景に再認識され、注目を集めている。
デジタルビジネスにおけるSecurity by Design成功のカギは、リスクシナリオの洗い出しにある。サービス仕様の不備に起因するリスクや、新技術にまつわるリスクを網羅的に洗い出すには、事故事例・攻撃事例を集めたデータベース（事例DB）や、脅威モデリングといったフレームワークを活用して分析する。
デジタルビジネスでは要件が頻繁に変更され、また、技術の進歩、業界動向の変化、攻撃手法の多様化も激しいため、リスクシナリオやそれに基づくセキュリティ対策方針は継続的に更新・改善していく必要がある。
1. Security by Designとは何か
内閣サイバーセキュリティセンター（NISC）の定義によれば、「情報セキュリティを企画・設計段階から確保するための方策」とされている。つまり、システム開発の後段でセキュリティ対策を講じるのではなく、システムの企画や設計の初期段階からセキュリティ対策を考慮し組み込むことである。
Security by Designという言葉は、2000年前後にはすでに各政府機関や民間企業によって使われている。また、2007年には、情報セキュリティ政策会議によってまとめられた「セキュア・ジャパン2007」の中で電子政府等の情報セキュリティ強化のための具体的施策の1つとして取り上げられてもいる。
このように、Security by Designは、概念としても用語としても新しいものではない。従来のシステム開発においても、セキュリティはシステム構築の1要素として取り入れられてきた。しかし、デジタルビジネスの進展に伴って、「セキュリティはサービス仕様であり、機能を提供するための本流である」と捉える機運が高まっている。Security by Designは、このトレンドを支援するための考え方として、新たな脚光を浴びつつある。その背景を、ビジネス、システムそれぞれの観点から概観してみよう。
◆ ビジネスリスクに対応するためのSecurity by Design
昨今、ビジネスのデジタルトランスフォーメーション（DX）化に伴い新たなサービスが次々と登場している。特にキャッシュレス化の波に後押しされ、ポイントサービスや新たな決済サービス、会員獲得を目的としたキャンペーンサイトなどが多くリリースされている。こうした新しいサービスを提供するデジタルビジネスでは、企画段階で十分に考慮しておかなければ防ぐことが難しいリスクシナリオが存在する。
◆ システムリスクに対応するためのSecurity by Design
従来型のシステム開発では、開発ガイドラインの遵守と、リリース前のセキュリティ診断によってセキュリティを保証するというプロセスが広く取られていた。まず、全社共通に守るべきルールを開発ガイドラインとして規定する。たとえば、SQL（データベースに対してデータの操作や定義を行うための問い合わせ言語）インジェクションやクロスサイトスクリプティングのようなコーディング上の脆弱性を作りこまないようにすること、パスワードの最低文字数や文字種について安全な仕様を採用すること、アカウントハッ「キング対策には知識認証に加えて所有物認証や生体認証を検討すること一などを記述する。そして、そうした共通ルールが正しく実現されているかどうかをリリース前にセキュリティ診断で確認するというアプローチである。
「ローコード」「ノーコード」という、プログラミング量を抑えてアプリケーションを構築できるツールも普及しつつある。このツールでは、十分にテストが重ねられた共通部品がツールによって提供されるため、これらを組み合わせるだけでアプリケーションが構築でき、通常はコーディング上の脆弱性はほとんど発生しない。
2. Security by Designを実現するために
Security by Designの重要性を理解したところで、それをどのように実現すればよいのだろうか。実現のカギは、リスクをいかに網羅的に洗い出せるか、にある。
「システムのリスク評価や網羅的なセキュリティ対策はこれまでも実践されているではないかと思われる方も多いだろう。しかし、この場合のリスク評価やセキュリティ対策とは、セキュリティ管轄部署が作成するセキュリティ考慮事項のリストをもとに、自システムに必要な対策項目をチェックし、対策を実施する、ということを指しているケースが多い。
共通のルールセットを事前に作成するこうしたアプローチは、セキュリティのベースラインを構築する上では非常に重要である。しかし、これだけでは、デジタルビジネスに特有のリスクに対処しきれない。
◆ システム設計に関連するリスクの洗い出し
それぞれのサービスに内在するセキュリティリスクを考慮するには、まず、サービスで取り扱う情報を情報資産として一覧化し、情報の重要度をもとにリスクを検討する。
メールアドレス、氏名、住所などの個人情報や、ID・パスワードなどの認証情報、ECサイトでは購買情報などの利用者の履歴情報など、これらすべての情報が、その重要度と共に一覧に挙げるべき情報である。特に、個人情報と利用者の履歴情報は、サービスの特性やサービス事業者のポリシー、社会情勢の変化によって重要度の評価が異なる場合がある。そうした事情を見落とし、「重要な情報を取り扱っている」という事実を認知できていなかったために第三者へ情報を漏えいさせてしまう事例も後を絶たない。情報の一覧化と重要度の決定は、サービスのオーナーであり、取り扱う情報やユースケースをよく知るビジネスの担当者が責任を持たなければならない。
情報を一覧化し、その重要度が確認できたら、次に各情報資産を扱うユースケースや機能ごとに、想定されるリスクシナリオを洗い出す。リスクを網難的に洗い出すためには、各種の脅威分析フレームワークを利用した脅威モデリングを実行することの有効性がよく知られている。
たとえば、それぞれの情報に対するアクセス経路ごとに、 ｢なりすまし（Spoofing）」「改竄（Tampering）」「否認（Repudiation）」「情報漏えい（In formation Disclosure）」「サービス停止（Denial of Service）」「特権昇格（El evation of Privilege）|の各脅威について検討する方法は、各脅威の頭文字をとって「STRIDEフレームワーク」と呼ばれ、マイクロソフトも推奨している脅威分析手法である。ほかにも「Attack Trees」「Attack Libraries」などの脅威モデリングの分析手法がある。
◆ ビジネス企画にかかわるリスクの洗い出し
デジタルビジネスのビジネス企画にかかわる仕様の不備は、前述の脅威分析フレームワークでは十分に洗い出せない場合がある。たとえば、先に挙げした「販促サービス特典の不正な大量取得」は、フレームワークで見出すことが困難な例である。
このような未知の脅威の分析に関しては、他社の被害事例を参考にリスクシナリオを作成することが効果的である。そのため、常に最新の被害事例や事故事例を収集し、データベース（事例DB）として蓄積した上で、これらの事例を参考にしながらリスクシナリオを組み立てていく。
事例を集めるといっても、被害を受けた会社が、必ずしもその手口などを詳細に明らかにするとは限らない｡このような場合には、構築しようとしているサービスで、過去の事故や事件と同様の被害を与えるとしたらどのような手口を用いればよいかを考える。つまり、攻撃者の観点でのユースケースを作り上げるのである。
また、すべての情報資産に対する未知の脅威を詳細に検討するのはコストが膨大になり、難しい。金銭被害の程度や個人情報などの重要情報にかかわる被害を考慮し、特に守るべき情報資産に集中してリスクシナリオを検討するという手法も考えられる。
◆ リスクシナリオに対する対策案の検討
対策すべきリスクシナリオのリストが完成したら、次は対策業の検討に移る。対策案の検討に当たっては、システム全体で整合性が取れた対策とするために、セキュリティ対策にかかわる考え方の全体像を整理する｡そして、具体的な対策検討に際しては、複数の観点から対策を検討する。たとえば、一般的な「予防」「検知 ｣「回復｣といった観点から方式を検討する。
「予防」とは、発生し得るリスクシナリオを防止することである。たとえば、情報を暗号化することで漏えいした場合の影響を小さくすることや、その情報へのアクセスを制御することなどである。
「検知」とは、リスクシナリオが実際に発生した場合に、その発生を検知することである。たとえば、不正侵入検知（IDS）による自動的な検知やログの分析などである。
「「回復」とは、リスクシナリオが発現した後に、その影響から復旧し、対象のサービスを継続することを指す。たとえば、データのバックアップや災害復旧用のシステムの構築が考えられる。
◆ リスクシナリオと対策の検討タイミング
リスクシナリオの洗い出しと対策案の検討はいつ実施すべきであろうか。検討開始は、そもそものビジネス企画の段階である。そこからシステムアーキテクチャの検討までの間に継続的に実施し、さらにその中でも随時改善を図っていく。
また、対策案を検討する際には、ビジネス上のリスクシナリオをシステムによって対策するだけでなく、逆にシステム上の課題をビジネス的な判断によって解決できる場合があることを意識したい。
システム設計に当たっては、定期的なシステムメンテナンスによる利用不可時間の設定などの制約事項を設けることは珍しくない。これは、ビジネスとして譲歩することにより、システムのメンテナンスにかかわるシステム課題を解決する例である。
セキュリティリスクについても同じことがいえる。場合によっては、ビジュネス判断を前提とした対策や緩和が有効となる。たとえば、個人情報の厳重な保護にはコストがかかるため、そもそも個人情報を必要最小限しか持たないようにサービス要件を変更することなどが考えられる。このように、システムとビジネスの課題を双方向に解決するために、企画段階からの継続的な検討が重要である。
◆ リスクシナリオと対策のドキュメント化
リスクシナリオとその対策が整理されたら、その内容をドキュメント化し、また、継続的に改善していく。
特に、どういったリスクシナリオが存在していて、それらに対してどのような対策をどのレイヤー、どの観点で実行するかを明示する。
これらの整理された情報をドキュメント化することで、実際にシステム構築を担う担当者がセキュリティ観点では何を考慮して作業すべきかを具体的に理解できるようになる。また、経営層などの意思決定者にも、デジタルビジネスのリスクとその対策状況が明示される。
図表：レイヤーごとに可視化したリスクシナリオ、対策の整理の例
※出所：NRIセキュアテクノロジーズ
このように、ドキュメントによる可視化を経てはじめて、デジタルビジネスのセキュリティ対策が効果的に実現される素地が整うといってもいい。
◆ リスクシナリオと対策の有効性を維持する
サービスやシステムに大きな改善・変更が発生する場合は、ドキュメントにその内容を反映する。特に、デジタルビジネスにおいては、サービスのユースケースが目まぐるしく変化することも多い。取り扱うデータの種類が増えたり、機能が追加されたりする都度、ドキュメントの内容を確認し、変更の要否を確認することを忘れてはならない。
当初は、金銭を直接的には取り扱っていなかったシステムやサービスに、ペイメント機能や口座連携の機能が追加されたことをきっかけにセキュリティ事故が続出したことは記憶に新しい。それまでの身元確認や認証をそのまま利用していたために、守るべき対象として新たに追加された金銭などの情報資産に対する適切なリスクの考慮がもれ、必要な防御策が取られていかった例である。システム改修をする際には、機能変更や追加する箇所だけではなく、既存機能を含めたリスクの見直し作業をしなければならない。
セキュリティリスクを継続して見直すには、脅威モデリングに対する習熟、最新のセキュリティ知識、他社の被害事例といった知見が必須のため、セキュリティ専門家による支援が有効である。一方で、サービスで取り扱う情報やサービスのユースケースを最もよく知っているのはサービスの開発担当者自身である。セキュリティ専門家へのアウトソースと内部の開発担当者の適切な役割分担は、Security by Design成功の重要なカギの1つである。
3. ITロードマップ
◆ 2022〜2023年度
すでに一部の部門でSeurity by Designを採用している事業者が、その取り組みを組織全体に広げ始める。特に、セキュリティインシデントの影響が大きい金融業界やデジタルビジネス先進企業において、Security by Designをサービス開発プロセスの一部として社内標準にする動きが始まる。
しかし、ビジネスリスクや新規技術にかかわるリスクまでは踏み込まず、システムの脆弱性にかかわる開発ガイドラインの策定やチェックリスト運用など、事前に画一化されたルールにより何とかSecurity by Designを実現しようとする企業がまだ大きな割合を占める。
図表：Security by Designのロードマップ
※出所：NRIセキュアテクノロジーズ
◆ 2024〜2025年度
ビジネスのデジタル化が進展するにつれ、Security by Designの実践において、デジタルビジネスに特有のビジネスリスクとシステムリスクを、共に検討することの重要性がいっそう高まる。
また、2021年現在、ローコード・ノーコードなどの技術の検討が多くの企業で始まっている。トライアル利用を通じた包括的な利用ルールの策定も始まっており、2024〜25年度には利用が本格化しているだろう。これらの技術を利用することで新しいシステムの構築が比較的容易になり、ビジネス部門担当者によるシステム構築の例が増加する。特に、大企業やデジタルビジネス先進企業においては、新しいサービスの立ち上げなど、スピードが求められるシステム開発では内製化が広がり、システム開発のスピードが加速する。
しかし、ローコード・ノーコードなどの技術を利用する一方で、Security by Designの検討が十分ではない事業者において、ビジネスや仕様の不備を企画・設計段階で検出しきれず、個人情報の漏えいなどの大規模なインシデントにつながってしまう事例の発生が予想される。
迅速で、かつ、セキュアなシステム開発の要求に対応するため、組織内でSecurity by Designを担うセキュリティ人材の育成に力を入れる傾向が強くなる。たとえば、大企業など人材に比較的余裕のある会社においては、人材育成も視野に入れ、それまでは専門会社に依頼していたセキュリティレビューについても内部人材で実施するというプロセスの内製化が進む。従来のシステム担当者はビジネスを、ビジネス担当者はシステムを、それぞれ理解するという、「相互乗り入れ」の必然性がいよいよ高まる。
◆ 2026年度以降
Security by Designの取り組みは、事前に脆弱性を検知し、対策ができるというかたちで実を結び、しっかり取り組んでいる事業者は、セキュリティ事故の被害を大きく抑えることに成功する。
これを受けて、サービス開発プロセスの一部としてSecurity by Designを社内標準にする動きは、デジタルビジネス先進企業に限らず、一般の企業にも広がる。サービスの特性に応じて、Security by Designの標準的な実行プロセス、方法論が数種類に集約され、採用のハードルが下がることでよりいっそうの広まりをみせる。
4. 実現に向けた課題
Security by Designに対応できる人材には、ビジネスとシステム双方の知見が必要となるが、すべての重要システムを網羅できるだけの人材の確保は容易ではない。また、それらの人材を活用するための、セキュアな開発プロセスの構築も十分に検討されているとはいえない。
人材育成に力を入れている大企業であってさえ、人材の確保は大きな課題となる。業務を熟知し、かつエンジニアとしての技術的素養を持つ人材の育成には時間がかかる。従来、ゼネラリスト人材の育成を重視してきた事業者が、エンジニアのキャリア採用に力を入れ始めているのは、技術的素養を持つ人材を自社で育成することが困難であることの証明とも考えられる。
また、ビジネス企画にかかわるリスクを洗い出すために、他社の被害事例から、攻撃のためのユースケースを組み立てるには、セキュリティの最新動向にかかわる広い知識が必要である。これは、ビジネスとシステムを熟知しているだけでは必ずしもカバーされない可能性がある。このため、必要に応じて、外部の専門人材などを活用することも考慮する。
さらに、人材を効果的に活用するためにも、セキュリティ確保のための開発プロセスが社内で確立されている必要がある。
たとえば、リスクシナリオを最初に検討するタイミングをビジネス企画の立案段階と規定したとき、巻き込むべき関係者はどの役割のメンバーで、最終的な意思決定はどの役割が実施すべきか、プロトタイプのビジネス企画をインプットとして、リスクシナリオや対策といったアウトプットはどの粒度まで検討すべきか、といったことはさらに事前に考えておかなければならない。
こうしたプロセスが定義されてはじめて、果たすべき役割が明確化され、メンバーはその価値を効果的に発揮できるようになる。 同時に、組織としても、不足している人材や今後強化すべきスキルを可視化できるようになる。
Security by Designを支えるプロセスの構築、人材の確保に早い段階から力を入れていた企業とそうでない企業の間で、デジタルビジネスのスピードに大きな差異が生まれていくことが予想される。 5年後のシステム開発を見据えた人材育成や体制確保・プロセスを構築することがSecurity by Design、ひいては、デジタルビジネスの迅速な展開の重要なカギとなるであろう。
まとめ
NALをはじめ、すでにデジタル化を進めている企業では、開発プロセスにSecurity by Designを取り入れる動きが広まりつつあるが、今後のデジタルビジネスのさらなる進展に伴い、Security by Designは標準的な取り組みとして広がっていく。
一方で、セキュリティの観点からシステムの企画・設計ができる人材は少なく、その人材を効果的に生かすための役割やタスクを定義した開発プロセスの構築にも時間を要する。これが、Security by Designの普及、ひいては安全なデジタルビジネスの迅速な実現に向けての大きな課題となる。