契約実務

SaaS利用者/事業者が知っておくべきクラウドセキュリティの確かめ方と高め方 —第2回 クラウドセキュリティの考え方


今回は「クラウドはセキュリティが不安」と言うフレーズを出発点に、関連する論点について検討します。最近はこのような言葉を聞く機会も少なくなってはきましたが、クラウドサービスが出始めた初期の頃には頻繁に聞くことがありました。この言葉の意味する所を分析した上で、クラウドサービス利用者・クラウドサービス事業者それぞれで実施すべきことを考えてみます。

「クラウドはセキュリティが不安」なのか

まずは、クラウド(ここではとりわけパブリッククラウドの意味)はオンプレミスよりもセキュリティが劣るのかについて考えてみます。

これはもちろん「オンプレミスを管理する自社」と「当該クラウドサービス事業者」それぞれの取組状況に寄るというのが答えではあるのですが、クラウドサービス事業者もこのような不安に対応するためそれなりの投資・対応をしており、金銭的・業務的なスケールメリットも考慮すると、一般論として「クラウドサービス事業者はセキュリティが劣る」とは言えないと考えます。

実際にIPAの情報セキュリティ10大脅威 2021のような指標を見ても、クラウドサービス自体についての脅威やリスクは挙げられていません。

とりわけ、当初IaaSを中心的なサービスの一つとして発展してきた

  • Amazon Web Services
  • Google Cloud Platform
  • Microsoft Azure

のような大手プラットフォーマーは、スケールメリットを効かせることができる度合いも大きく、大量のセキュリティ認証を取得したり、ユーザーに向けてWebサイトやホワイトペーパーで情報発信をしたりしています。「クラウドこそ安全」(笹沼 穣/矢野敏樹 インフラクラウドの契約と法律実務 ビジネス法務 21(6), 103-107, 2021-06)といった主張がされることもあります。そして今日では、多くのSaaSはこれら大手プラットフォーマーの用意した環境の上で動いています。

また、これらプラットフォーマーはユーザーとも強い信頼を構築できているように感じます。

例えば、以前ある有力なSaaS企業でサービス障害が発生した際、「弊社が利用しているAmazon Web Servicesの障害の影響で…機能が利用できない状況が発生しております。」というリリースを出したことがありました。Twitterなどでは広報系などの一部アカウントから表現が他責的であるとの批判が見られたものの、「AWSで障害なら仕方ない」といった同情的な論調のコメントも一定数見受けられました。これは、私にはAWSを始めとしたインフラクラウドへの信頼が高まっていることを実感する契機になりました。

クラウド推進の動向

実際に、日本政府も数年前よりクラウド重視の方向性を明確に示しています。

政府情報システムにおけるクラウドサービスの利用に係る基本方針」では、

「政府情報システムは、(中略)クラウドサービスの利用を第一候補として、その検討を行うものとする」

というクラウド・バイ・デフォルト原則を採用しており、クラウドサービスの利用メリットとして以下が列挙されています。

  • 効率性の向上
  • セキュリティ水準の向上
  • 技術革新対応力の向上
  • 柔軟性の向上
  • 可用性の向上

このうち「セキュリティ水準の向上」では、

「多くのクラウドサービスは、一定水準の情報セキュリティ機能を基本機能として提供しつつ、より高度な情報セキュリティ機能の追加も可能となっている。また、世界的に認知されたクラウドセキュリティ認証等を有するクラウドサービスについては、強固な情報セキュリティ機能を基本機能として提供している。多くの情報システムにおいては、オンプレミス環境で情報セキュリティ機能を個々に構築するよりも、クラウドサービスを利用する方が、その激しい競争環境下での新しい技術の積極的な採用と規模の経済から、効率的に情報セキュリティレベルを向上させることが期待される。」

との記載がなされています。クラウドサービスを使うとセキュリティ水準が向上する…と真正面から読み過ぎるのは危険で、「クラウドなら安全」のような思考停止は批判されるべきものだと考えますが、言わんとしていることは理解できるものです。

「クラウドはセキュリティが不安」の意味

では、今日においてそれでもなお使われることがある「クラウドはセキュリティが不安」という言葉は、どのような意味に捉えれば良いでしょうか。

これは「事実としてどちらの方がセキュリティレベルが高いか」を言っているのではなく、その担当者が、

「セキュリティレベルを担保できていることの説明コストが高いと感じる」
「私ではクラウドサービスのセキュリティレベルが担保されていることを社内に説明できない」

と言っていると理解すべきではないでしょうか。

例えば自社環境・社内システムを利用する場合、自社の気心の知れたエンジニアからセキュリティについてアドバイスを受けることができるかもしれません。社内的に説明が必要な場合、同席をお願いすることもできるかもしれません。

他方で外部のクラウドサービスを利用する場合、セキュリティを含めてサービスがパッケージ化されている結果、機能として提供されているものを除いては基本的に個別のアレンジができません。担当者としては、当該パッケージ化されたプロダクトについてセキュリティを評価し、自組織が要求する水準を満たしているかを自身で評価しなければなりません。

ここに不安があるのだとすれば、それは、

  • クラウドサービス利用者における何らかの能力の不足
  • クラウドサービス事業者における何らかの情報提供の不足

のどちらかに原因があると考えるのが妥当です。

クラウドサービス利用者における何らかの能力の不足

それでは「クラウドサービス利用者における何らかの能力の不足」とは何でしょうか。今回は一定の観点を設定した上で、論点になりそうなところ・議論すると面白そうな所を探っていきましょう。

オーソドックスな考え方ではありますが、得てして業務上の問題というのは組織と個人の両方に存在することが多いものです。そこで、組織の観点と個人の観点に分解して考えてみます。組織・個人それぞれの観点で「クラウドはセキュリティが不安」という言葉が出てくる背景を推測すると、

  • 組織の観点
    • クラウドサービス一般を管理するための制度が不足している
  • 個人の観点
    • 当該クラウドサービスのセキュリティを理解するための知識が不足している(知識を有する者は存在するが偏在している)

ということが言えそうです。それぞれ詳述します。

組織の観点

「クラウドサービス一般を管理するための制度」については、関連する重要な話題があるのでご紹介します。

令和2年改正個人情報保護法の意見募集結果(通則編)の中にNo.468というものがあります。

事業者(⊃クラウドサービス利用者)は外部事業者(⊃クラウドサービス事業者)の運営するサーバに個人データを保存する場合、まずこれらのクラウドサービスを網羅的に捕捉した上で

  • A国(サーバの運営事業者が存在する国)の名称
  • B国(サーバが所在する国)の名称
  • A国、B国の制度等
  • 必要な安全管理措置

を把握・管理する必要があるというものです。

現状においてこれらを全く確認せずにクラウドサービスの利用を許容している企業は殆どないと思いますが、とはいえ対象クラウドサービスの網羅性やチェック項目の網羅性については悩ましい・自信がない部分があるのではないでしょうか。

この意見募集結果(通則編)No.468に対応するためには、利用するクラウドサービスを網羅的に拾い上げ、個人データの取扱い有無含めて必要な内容をチェックして、OK/NGを判断する制度を組織として作り回していくしかありません。

本連載ではそのような制度の一例として、「第6回 クラウドサービスにおけるの個人情報、プライバシーの考え方」において「個人情報及びプライバシーに係るリスク分析、評価、対応検討を行う手法」であるPrivacy Impact Assessmentを取り上げます。経済産業省の「DX 時代における 企業のプライバシーガバナンスガイドブック ver1.1」などでも取り上げられており、色々な場面で言及がなされることも増えてきた手法です。著者の経験も踏まえて、具体的な運用方法や取組みを定着させるコツについてもお伝えします。

個人の観点

次に個人の観点、「当該クラウドサービスのセキュリティを理解するための知識が不足している(知識を有する者は存在するが偏在している)」という点です。

ここは本連載の趣旨を踏まえ、法務を中心とした管理部門におけるセキュリティ教育・学習について検討を行います。

セキュリティ含めたテクノロジー領域では、新しい概念が出現してデファクトスタンダードとされる考え方が数年単位で移り変わっていくことが良くあります。オンプレミスからクラウドへの変化はまさにその代表例の一つですが、

  • ウォーターフォール / アジャイル
  • RDB / NoSQL
  • モノリシック / マイクロサービス
  • サーバ / サーバレス
  • 境界型防御 / ゼロトラスト

などもその例として挙げることができます。

これらは黎明期に「イケてる新しい考え方」として、時に既存の考え方への痛烈な批判と共に紹介されます。新しい概念に“No”“レス”“ゼロ”のような言葉が入りがちであることもこのような背景があると考えます。

そして、それらの批判的なスタンスが次第にバズワード/マーケティングワード的な要素を帯びていき、「既存の考え方と両立可能なものである」「提唱者の本心は“No”“レス”“ゼロ”ではない」「使い分けが重要」といった啓蒙活動を経て、最終的にデファクトスタンダードが新しい考え方に移っていく…というのが比較的よくみる流れです。

非技術者としては、このような大きな文脈から理解をしていくとテクノロジー領域の新しい概念を理解しやすいのではないかと思います。

また、非技術者が網羅的に最低限の知識を獲得するための手段としては、私は資格試験の勉強が適していると考えています。これらの内容について、「第4回 クラウドサービス利用者におけるクラウドセキュリティの確かめ方」で検討を行います。

クラウドサービス事業者における何らかの情報提供の不足

今度は、クラウドサービス事業者側の視点から「クラウドサービス事業者における何らかの情報提供の不足」を解消する方法を考えてみます。こちらについても分析の観点を設定します。

例えば平時・有事というのはどうでしょう。情報提供に利用者が求める内容という意味でも、情報提供時に事業者に求められるメンタリティという意味でも、両者は大きく異なるので良さそうです。

平時の情報提供

平時においてクラウドサービス事業者が実施すべき情報提供は、一定の網羅性をもったセキュリティについての情報開示です。

網羅性の担保のさせ方としては、認証を取得すること(第三者確認モデル)や、自社でホワイトペーパーやセキュリティチェックリストを公開すること(自己宣言モデル)があり得ます。

この点については、

  • 「第三者確認モデル」と「自己宣言モデル」の優劣や使い分けについての整理
  • 実務上よくみるセキュリティチェックシート運用に対する批判・提言

を次回「第3回 総務省ガイドラインの読み方・使い方」でしたいと思います。

なお、「第三者確認モデル」「自己宣言モデル」の説明を含め、クラウドサービス利用者とクラウドサービス事業者間の信頼(トラスト)の構築については崎村夏彦先生の『デジタルアイデンティティー 経営者が知らないサイバービジネスの核心』  第9章 信頼、ブランド、そしてトラストフレームワーク が非常に参考になったので一読をお勧めします。全体として読みやすく記述されている本ではありますが、第9章は前提知識があまりなくても十分理解できる内容になっています。

有事の情報提供

インシデントの発生時に対外的にどのように振る舞うべきか、どのように情報提供を行うべきかというのは非常に難しい問題です。皆、真正面から嘘をついたり誤魔化そうとすることは殆どありませんが、利害関係者の色々な思惑が絡み合います。

例えば以下のようなコメントについてはどう思うでしょうか?

インシデント発生時、とりわけ何かを外部に発信することを検討する時には、この「逆に良くない」という主張をする人が頻繁に現れます。

しかし、我々はこの種の主張が本当にユーザーを向いて出たものなのかをシビアに考える必要があります。私も含め、多くの人はインシデントなどのストレスがかかる状況では「ユーザーのため」と言いながら自己弁護的な行動をとってしまいがちだからです。意識を統一できないままに行った外部発信は連鎖的な炎上を引き起こしかねませんし、逆に問題提起を黙殺するようなことがあれば真に会社のことを思う社員の離反に繋がります。

これらの問題を回避する一つの解決策は、事前に(皆の頭が冷静な時に)基準や運用ルールを定めてしまうことです。

詳細は「第5回 クラウドサービス事業者におけるクラウドセキュリティの高め方」で検討します。

終わりに

今回は「クラウドはセキュリティが不安」というフレーズを分析しながら、クラウドサービス利用者・クラウドサービス事業者で実施すべきことについて、観点を設定して大枠の検討を行いました。個別の論点については後続の連載にご期待いただければと思います。

次回は総務省が発行しているガイドラインを取上げ、具体的な中身も検討しながらその使い方を検討していきます。

参考文献

連載記事一覧

著者紹介

世古 修平(せこ しゅうへい)
インハウスハブ東京法律事務所、インターネットサービス企業 Privacy Counsel、IPA独立行政法人 情報処理推進機構 試験委員。
弁護士(第二東京弁護士会)、CISSP。
Twitter: @seko_law

契約のデジタル化に関するお役立ち資料はこちら

こちらも合わせて読む

電子契約の国内標準
クラウドサイン

日本の法律に特化した弁護士監修の電子契約サービスです。
さまざまな外部サービスと連携でき、取引先も使いやすく、多くの企業や自治体に活用されています。