契約実務

SaaS利用者/事業者が知っておくべきクラウドセキュリティの確かめ方と高め方 —第5回　クラウドサービス事業者におけるクラウドセキュリティの高め方

2021.10.20更新

今回はクラウドサービス事業者の立場から、どのようにセキュリティを高めていけば良いのかを検討します。こちらについては本連載の第2回「クラウドセキュリティの考え方」において、以下のような検討を行いました。

クラウドサービス利用者が、「クラウドはセキュリティが不安」と言う背景には、クラウドサービス事業者における何らかの情報発信の不足があるのではないか

そこで今回は

クラウドサービス事業者で「実施すべきこと」は何か
「実施すべきこと」を前に進めるためには何が必要か
「実施すべきこと」の情報発信はどのように行うべきか

を順番に検討していきます。

なお、全体的にクラウドサービス事業者に限らず、セキュリティ/プライバシーに取り組む全ての事業者に共通する話ができたかなと思いますので、記載されている事例をぜひご自身の会社に置き換えながらお読みいただければと思います。

クラウドサービス事業者で「実施すべきこと」は何か

トラスト

「クラウドサービス事業者で「実施すべきこと」は何か」との問いに答えるためには、「クラウドサービス事業者は、なぜセキュリティやプライバシーに取り組まなければならないのか」との問いに答えなければなりません。

これを突き詰めていくと、「そもそもセキュリティ/プライバシーとは何か」との議論に立ち入らなければならず本連載の目的や私の限界を超えてしまいます。そこでトップダウンでの思考はやめにして、身近な例からボトムアップで考えてみることにしましょう。

恐らく皆さんもよくご存知の話題だと思いますが、利用規約の閲覧率に関する話を取り上げます。公正取引委員会の「デジタル広告の取引実態に関する中間報告書」では、SNS等を利用する際に利用規約をどの程度読んでいるかという調査を行なっており、「全部読んでいる」と回答しているのは11.9%です。

公正取引委員会「デジタル広告の取引実態に関する中間報告書」　https://www.jftc.go.jp/houdou/pressrelease/2020/apr/digital/200428betten.pdf

では、なぜ多くのユーザーは利用規約も読んでいないのにそのサービスを利用できるのでしょうか。「ユーザーは頭が悪い」「怠慢だ」と言うのは簡単ですが、それでは自己否定ですよね（ですよね？）。

大多数のユーザーが利用規約も読んでいないのにそのサービスを利用できる理由、それはそのクラウドサービス事業者を信頼している…より正確にいうと「少なくとも提供する情報を管理させるに足りる程度には、そのクラウドサービス事業者のセキュリティ/プライバシーを漠然と信頼しているから」ではないか、というのが私自身の思考を振り返ってみての答えです。

そのクラウドサービス事業者に情報を提供することのリスク
クラウドサービス事業者のセキュリティ/プライバシーへの信頼

を天秤にかけ、後者に傾くか否かを無意識に判断していると言うことです。私も病歴等のリスクが高い情報を提供するサービスはそれなりに利用規約等を読みますし、見慣れない事業者や良い噂を聞かない事業者のアプリは信頼が置けず利用を躊躇します。

別の例を挙げます。いわゆる炎上事案が起こると解約率や利用率の数字は顕著に悪化します。しかし炎上事案が起ってもなおサービスの利用規約を読み直さないのが（私を含めた）大多数のユーザーであり、ここでもユーザーは「その会社を信頼できるか」という抽象的な評価基準に基づき行動を決定しているように思います。

また、少し前のアップデートから細かく表示されるようになったAppleの位置情報同意についても同様のことが言えます。人々はそのアプリケーションに自分の位置情報を利用させるか否かを瞬時に判断していますが、ここでも利用規約等を確認することはありません。ここで行われる判断の基準になっているのも「その会社を信頼できるか」ではないでしょうか。

https://support.apple.com/ja-jp/HT207092

抽象的な話が続いたのでそろそろまとめます。

「なぜクラウドサービス事業者はセキュリティやプライバシーに取り組まなければならないのか」
- データの活用が成功に大きな影響を及ぼすクラウドサービスにおいて、事業を推進していくためにはユーザーとの信頼関係を構築・強化していかなければならないから
クラウドサービス事業者で「実施すべきこと」は何か」
- ユーザーとの信頼関係を構築・強化していくこと

というのが、現時点での私の考えです。

なお上記の説明では、「サービスの信頼性」を判断するに際して「クラウドサービス事業者」の信頼性を用いるというねじれが発生しています。このねじれ現象については、後続の章で「コーポレート」「プロダクト」という言葉を使いながら言及しますので心に留めておいていただければと思います。

コーポレート

それでは次に、信頼関係を構築・強化していく上で必要なことを考えます。
ここでは大きく「コーポレート」「プロダクト」という2つの視点を設定して検討します。コーポレートとは言葉通り会社レベルの大きな取組み、プロダクトはより個別的な特定サービス/システムについての取組みの話です。

コーポレート視点で注意すべきことは、その対象範囲が非常に多岐にわたるということです。
セキュリティではweakest link（a chain is no stronger than its weakest link. くさりは一番弱いところ以上に強くなれない）のような言葉が使われ、1つの分野に偏らない網羅的・多層的な対策の重要性が強調されます。これはプライバシーにも同様のことが言えます。ユーザーとの信頼関係を構築していくためには、会社の様々な取り組みの基礎となるような、網羅性のあるセキュリティ/プライバシーの取組みが求められます。

そして網羅性を担保するために用いられるのがフレームワークです。参考になるフレームワークとして、セキュリティ領域としてはCybersecurity Framework、プライバシー領域としてはPrivacy Frameworkがあります。

例えばCybersecurity Frameworkでは、対応すべき内容を以下のような5つの「機能(Functions)」に定義した上で、より詳細な実施事項を「カテゴリー(Categories)」「サブカテゴリー(Sub categories)」として定めています。コーポレート視点では、このようなフレームワークに基づいて網羅性を担保することが効果的です。

Cybersecurity Frameworkにおける5つの機能(Functions)
- 特定(Identify)
- 防御(Protect)
- 検知(Detect)
- 対応(Respond)
- 復旧(Recover)

重要インフラのサイバーセキュリティを改善するためのフレームワーク（IPA訳） https://www.ipa.go.jp/files/000071204.pdf

プロダクト

続いて、プロダクト視点でユーザーとの信頼関係を構築していくために必要なことを検討します。コーポレート視点で網羅的・一般的な対応ができていることを前提に、当該プロダクト固有の対応を検討するのがこの段階です。
ここではby Designという考え方をご紹介します。

Security by Design

Security by Designは、例えばNISCでは「情報セキュリティを企画・設計段階から確保するための方策」（情報セキュリティを企画・設計段階から確保するための方策 (SBD(Security by Design))）と定義されています。シフトレフトなども同趣旨の表現として使われることがありますが、これはウォーターフォール的な工程を左から右に配置した場合に、より左（開発ライフサイクルの初期）の段階でセキュリティを考慮することを推奨することから名付けられたものです。

セキュリティ・バイ・デザイン入門 https://www.ipa.go.jp/files/000055823.pdf

例えばGoogleのガイドの中では「プロセスの最後にセキュリティの問題をテストするのではなく、セキュリティを日常業務の一部に組み込むことで、より良い結果を達成できることが示されています。これは、セキュリティテストとコントロールを開発、QA、運用の日常業務に統合することを意味します。」といった説明とともに、改善方法や注意点が説明されています。（DevOps 技術: セキュリティのシフトレフト）

Privacy by Design

Privacy by Designという考え方もあります。世間的な認知としてはGDPRの25条 Data protection by design and by defaultが契機となって広まった印象があります。

Privacy by Designはその構成要素となる基本原則が示されています。

Proactive not reactive; preventive not remedial
Privacy as the default setting
Privacy embedded into design
Full functionality – positive-sum, not zero-sum
End-to-end security – full lifecycle protection
Visibility and transparency – keep it open
Respect for user privacy – keep it user-centric

また、Privacy by Designを実現するための手段としてPrivacy Impact Assessmentという手法があります。DX 時代における企業のプライバシーガバナンスガイドブックでは「個人情報及びプライバシーに係るリスク分析、評価、対応検討を行う手法」と定義されており、以下の通り説明されています。

システム要件定義を検討する前からプライバシーリスクを評価して対策を講じ、リリース判断のタイミングでそのリスクがきちんと低減されているのか、残存リスクがあればリリース後の対応を事前に考えておくことで、プライバシーリスクを対応することができる。また、外部サービスを導入する場合や、自社でパーソナルデータを取得せず、外部からデータを購入する場合などにおいては、契約の法務審査や購入審査のタイミングで、法務部やプライバシー保護組織と、プライバシーリスクを評価することも有用だろう。

この点については、先日「2021年度経済産業省・総務省・JIPDEC共催第2回企業のプライバシーガバナンスセミナー」が行われ、登壇された各企業の発表や、パネリストの先生方からコメントがされていました。
おそらくどの企業も現状の取組みには課題があることを前提とした発表で、私も「自分の立場とは少し違うな」と思うところもありましたが、参考になる部分も多くありました。パネリストの先生方の、良いところを指摘しようという姿勢も印象に残りました。

なぜby Designが重要か

「XX-Tech」や「アジャイル○○」のように何でもby Designと付くと冷めてしまう方も多いとは思います。しかし、セキュリティやプライバシーのようにリスクベースの判断が馴染む領域（「これをすれば/しなければ正解」のような単独の選択肢がある訳ではなく、ケースに応じて最適解を探る必要がある領域）では、by Design的な考え方が非常に重要なのです。

なぜなら、セキュリティやプライバシーへの対策は、組織としての文化や個人としての理解度が伴わないと「言われたからやる」「炎上するからやる」「面倒くさいからやる」になりがちで、本質的な対応にならなずむしろ害になることが多いからです。

少し具体的な例を挙げて検討しましょう。

例えば、あるアプリケーションがユーザーから同意（位置情報の取得、通信の秘密…etc）を取得するケースを考えてみます。これに対応しようとした時に、

法律やガイドラインに書いてあるからと、リリース間際になって無理矢理1st viewに収めたような無味乾燥な長文ポップアップとチェックボックスを用意する

ことで要求事項をクリアすることもできれば

アプリ、もっと言えばビジネスの設計段階からプライバシー部門が関与して、そのプロダクトが位置情報や通信内容を利用する必要性やユーザーメリットがしっかり伝わるようなコミュニケーションを設計してもらい、その理解を前提として簡潔な同意文言に加えて詳細な説明へのリンクを貼る（Layered Noticeと言います）

こともできます。

前者は誰も幸せにならない対応で、後者は皆が幸せになる対応だと考えますが、後者を検討することができるためにはそれを「良いもの」だと考えられる組織的な文化や担当者の理解が前提として必要です。この文化・理解を醸成していくためにby Design的な取組みの積み重ねが必要なのです。私として取り組んでいる「by Design的な取組み」の具体的な流れは後段の「プロダクト担当としての立回り」でご説明します。

さて、ここで思い出していただきたいのが冒頭で述べたねじれ現象（＝ユーザーは、「プロダクトの信頼性」を判断するに際して「コーポレートの信頼性」を指標として用いている）についてです。結局多くのユーザーは「特定の法律で要求される同意取得プロセスが、法律に沿って実装されているか」といったプロダクトレベルでの話など気にしていないのです。

先程の同意取得の例で言えば、ユーザーは最終的に

到底理解できないような長文ポップアップとチェックボックスを押し付けてきたユーザーに不誠実な企業

というメッセージか

順を追って必要なことだけを簡潔に説明してくれたユーザーに誠実な企業

というメッセージを受け取っていて、このプロダクトレベルで発信される無数のメッセージの積み重ねが「コーポレートとしての信頼性」という指標の変動に繋がっているのではないでしょうか。

「実施すべきこと」を前に進めるためには何が必要か

それでは、今まで述べた「実施すべきこと」を前に進めるために必要なことを検討します。

対経営（コーポレート視点）

サイバーセキュリティ経営ガイドラインの中には以下のような記載があります。

また、セキュリティ投資は事業継続性の確保やサイバー攻撃に対する防衛力の向上にとどまるものではなく、IT を利活用して企業の収益を生み出す上でも重要な要素となる。セキュリティ対策の実施を「コスト」と捉えるのではなく、将来の事業活動・成長に必須なものと位置づけて　「投資」と捉えることが重要である。
自社ではサイバー攻撃を受けていないとして、セキュリティ投資を行わないことはありえない。
セキュリティ投資はやむを得ない費用であると認識している企業が圧倒的に多数である。また、成長投資と考えている企業においては７割以上の企業が必要なセキュリティ予算を確保できているのに対し、やむを得ない費用と考えている企業においては４割程度に留まっている。このことからも、経営者がリーダーシップを取り、企業の成長のためにセキュリティ投資 を行っていくことが、サイバー攻撃への耐性を高めることに繋がる。

強い論調は危機感の現れだと思いますし、意図しているところには私も賛成するところです。今回冒頭で述べたことも、結局は「トラスト」の構築・維持が企業成長につながるという考えが背景にあります。

他方で、このようには考えない経営層が多数であることも理解でき、経営的視点からは投資というよりは特別損失（の軽減）と考えることも自然なことのように思います。

私が見聞きしてきた経営層でセキュリティ、プライバシーを重視している方に共通するのは、やはり自分で痛い目をみているということです。中にはインシデント発生当時の新聞記事を社長室に飾って、自分を戒めているという方もおられました。

インシデントは本当に辛いものです。大切に関係を構築してきたユーザーに損害を与えてしまうという意味ではもちろんですが、実際に対応する過程で「中の人」も肉体的・精神的に疲弊していきます。疲弊した結果、健康を害して休職・退職してしまったり、会社に失望して転職してしまう同僚も多く出ます。この辺りを実体験として経験している経営層は意識が高い…より直接的にいえば必要なお金はきちんと付けてくれる傾向が強いと感じます。

では幸いなことにインシデントを経験していない企業では、どのように対応すれば良いのでしょうか。
まず最初に考えてみる価値があるのは、「インシデントを経験していない」という前提が間違いである可能性についてです。以前あるクローズドな国際会合で、ある日本企業が「弊社では今年はインシデントがなかった」という趣旨の発言をした際、ヨーロッパの企業の代表者から「それは検知できていないだけだ。御社の規模でインシデントがなかったなど普通あり得ない」と痛烈に批判されていたことがありました。真実は私にはわかりませんが、この指摘は会合でも肯定的に捉えられていて非常に印象に残っています。

「インシデントを経験していない」「インシデントなど起こっていないはずだ」という前提を覆して経営層にインパクトを与えるためには、ペネトレーションテストやレッドチーム演習などを行い、そこでの報告書をしっかり上まであげるというのは有効な一つの手段になると思います。

また、以前ある勉強会では「致命傷にならない程度のインシデントが定期的に起こることが重要」という趣旨の話がされていました。不謹慎ながら意図は理解できるなと、笑いながらも納得してしまったことがあります。流石に意図的にインシデントを起こすことはあり得ませんが、同じ方向性の取組みとして他社のインシデント事例を適時に社内に共有することは効果的です。その意味でも第4回の連載で述べたニュース（炎上）起点での学習はおすすめです。

対事業部門（プロダクト視点）

続いて、対事業部門視点です。ここではガバナンスの話をしていると必ず出てくるスリーラインディフェンスについての話をしながら、対事業部門・対プロダクト視点で私が普段持っている問題意識や、辿り着いた結論についてお話しします。

スリーラインディフェンス

スリーラインディフェンスは、リスク管理の体制を第1線（事業部門）、第2線（管理部門）、第3線（内部監査部門）という3つのグループに分類する考え方です。核となる部分が明瞭で理解しやすく、ガバナンスについての検討を行うとよく言及されるフレームワークです。

PwC：3つのディフェンスライン https://www.pwc.com/jp/ja/knowledge/column/viewpoint/grc-column001.html

またスリーラインディフェンスの話をしているとこの原則形態では対応が難しいケースというのが出現し、得てして1.5線や2.5線などの造語の下で色々なアレンジが語られます。

「事業部門が相談に来ない」

「事業部門が相談に来ない」という言葉は管理部門から比較的よく聞かれますし、「〇〇部門は敷居が高いと思われている」といった言葉を聞くこともあります。
しかし、事業部門はその専門領域（法務、セキュリティ、プライバシー…）における勘所を網羅的に把握しているわけでは当然ありませんし、事業部門が最終的なリスクオーナーとはいえ各専門領域について高い習熟度を求めるのも酷な話だと思います。

独立性や牽制という意味合いで第2線が第1線から独立していることは非常に重要だとは思いますが、「アドバイスを提供する」「敷居が高いと思われている」というような態度で待っているだけでは情報は集まってきませんし、結果として「対策不十分なままでのリリースと炎上」や「〇〇に案件を潰されたという恨みごと」が量産されることになります。

プロダクト担当としての立回り

それを1.5線と呼ぶかどうかはともかくとして、私は管理部門（法務、セキュリティ、プライバシー…）でもプロダクトごとに担当者を置き、

ビジネス上の狙いなど前提となる制約事項を自ら受け取り
担当する専門領域において収集すべき情報の全体像を自ら定義・収集し
リスクマネジメントを事業部門と共に行なっていく

ことが理想的な管理部門側の動きなのではないかと考えています。

このような動きを可能にするためには管理部門側のリソース含め色々な前提事項があるとは思いますが、相談ベースの受け身な対応では上述のような不幸な出来事の量産を止められないのではないかと思います。

「実施すべきこと」の情報発信はどのように行うべきか

情報発信については平時・有事という分類を行い、平時の情報発信については第3回で解説を行いました。そこで、今回は有事における情報発信にフォーカスして検討を行います。

個人情報の定義

連載第4回では、「公然の秘密」として個人情報の定義が誤解されている現状に対して問題提起を行いました。個人情報を独自の定義で理解しているために、法律上の漏えい等に該当するにもかかわらず、該当しないものとして取り扱おうとしているケースに出くわすことがあります。

とりわけ、「漏えい等をした部分単体では個人情報には該当しないが、自社としてはユーザーIDに紐付けて管理している結果個人情報に該当する情報」が漏えいしたような場合に、個人情報の定義を誤解されている人たちから反発が生じ得ます。
こちらは誤解というよりは「べき」論かもしれませんが、例えば以下のようなものです。

「個人情報の保護に関する法律についてのガイドライン（通則編）の一部を改正する告示案」に関する意見募集結果 https://public-comment.e-gov.go.jp/servlet/PcmFileDownload?seqNo=0000223334

社内からこのような意見が出た場合真正面から戦うべきですが、この段階になって「あなたの個人情報の定義は間違っています」と指摘をしてもなかなか話が上手く進みません。個人情報保護委員会も以下の通り否定してくれていますが、これを示したとしてもぎくしゃくした雰囲気が残ってしまいます。
やはり、漏えい等が起こる前に個人情報の定義は正しく理解してもらうべきです。