契約実務

SaaS利用者/事業者が知っておくべきクラウドセキュリティの確かめ方と高め方 —第3回　総務省ガイドラインの読み方・使い方

2021.09.22更新

今回は、総務省発行の「クラウドサービス提供における情報セキュリティ対策ガイドライン」（以下、「総務省ガイドライン」という。）の検討を通じて、クラウドサービス利用者とクラウドサービス事業者がどのようにセキュリティについての共通認識を構築していくべきかを検討します。

事前に総務省ガイドラインを読んでいただく必要は必ずしもありませんが、ご興味を持っていただけた場合には後ほど一読いただくと良いと思います。

総務省ガイドラインとは
評価
クラウドのセキュリティチェック
終わりに
参考文献
連載記事一覧
著者紹介

総務省ガイドラインとは

総務省ガイドラインは「安全・安心なクラウドサービスの利活用推進のため」に「実施することが望ましい情報セキュリティ対策について記載」したものであると説明されています。

令和3年7月17日（土）から同年8月15日（日）で意見募集を行なっていたため、良い機会であると考え本連載で取り上げることにしました。

概要

ガイドラインの全体構成は以下のようになっています。

Ⅰ．序編
Ⅱ．共通編
Ⅲ．SaaS 編
Ⅳ．PaaS/IaaS 編
Ⅴ．IoT サービスリスクへの対応方針編

ANNEX1 クラウドサービスのパターン
ANNEX2 対策一覧
ANNEX3 クラウド事業者が過度の責任を負わないための注意点
ANNEX4 【事例集】調査テンプレートの記入例

「Ⅰ．序編」で考え方や概念の説明がなされた上で、「Ⅱ．共通編」から「Ⅴ．IoT サービスリスクへの対応方針編」にかけて分類別に「望ましい情報セキュリティ対策」が整理されています。

読み方

具体的な読み方については、ガイドラインの中で以下のように提案されていますので「Ⅰ．序編」「Ⅱ．共通編」と読み進めていくのが良いと思います。

「Ⅱ．共通編」以降では「実施することが望ましい情報セキュリティ対策」がそれぞれ記載されています。各項目には、それが【基本】対策なのか【推奨】対策なのかの種別と合わせて、具体的な実現方法が【ベストプラクティス】として記載されています。

要件だけを読んでもイメージが湧かないと読み流してしまいがちですが、この【ベストプラクティス】の部分を拾い読みしていくと、しなければいけないこと・できていないことがイメージしやすく、必要性を理解しながら読み進めていくことができます。

評価

後段でもう少し掘り下げた議論をするためにも、総務省ガイドラインに対する私の評価を記載しておきます。

総務省ガイドラインは、「望ましい情報セキュリティ対策」に関しての共通理解・議論の土台を作るためのツールとして利用価値の高いものだと考えています。以下では、私の考える総務省ガイドラインの「良い点」「改善を求めたい点」を挙げながらその理由を説明します。

まず良い点から見ていきましょう。

国内外には既に複数の信頼できるガイドライン・フレームワークがあり、これらは事業者が自主的にセキュリティ水準を高めていく上でとても参考になるものです。しかし、現状国内において「望ましい情報セキュリティ対策」に関しての共通理解・議論の土台と言えるレベルで利用可能なものがあるか…というと難しいと思っています。

クラウドサービス利用者・事業者双方に普及させ利用してもらうということを考えると、総務省ガイドラインの良い点として列挙した要素は重要であると考えます。

一方、改善を求めたい点が2点あります。

1つ目は、権威性を分散させないために各省庁などで発行している類似の文書と統合・連携を図って欲しいという点です。色々な省庁が微妙に対象スコープが異なるガイドラインを複数出していると、権威性が分散してしまい結局それぞれが参考情報に止まってしまいます。

などなど、少なくともクラウドサービスのセキュリティに関する要求事項を提示しているような文書類とは統合・連携していただけると良いのになと感じています。

2つ目は、既に存在する世界的なガイドライン・フレームワークと歩調を合わせるために「望ましい情報セキュリティ対策」の出自を相互参照できる形で整理して欲しいという点です。総務省ガイドラインは「ISMAP管理基準、ISO/IEC27017(2016)及びNIST SP800-53 Rev.55を参照」して作成されているとのことですが、各要件の出自や関係性は明記されていません。総務省ガイドラインには期待をしていますが、今後独自に要求事項を検討してグローバルスタンダードを目指すわけではないと思うのでこの辺りは意識して欲しいです。

クラウドのセキュリティチェック

さて、クラウドサービス利用者が総務省ガイドラインに基づいてクラウドサービスのセキュリティを検証したり、クラウドサービス事業者が顧客に説明してくれていれば良いのですが、現状はそのような利用が可能なほどの認知は獲得できていません。

では、利用者はクラウドサービスのセキュリティをどのように検証し、事業者はどのように顧客に説明しているのでしょうか。実務上行われている取組みに目を向けてみましょう。クラウドサービス（ここではとりわけtoBのクラウドサービス）の利用開始に際しては、クラウドサービス利用者・事業者間で当該クラウドサービスについてのセキュリティチェックが行われれることがあります。

現状

セキュリティチェックとして行われている代表的な方法としては以下の3種類が挙げられます。

①セキュリティ認証の取得・公開
②クラウドサービス利用者から送付されるチェックシートへの事業者による回答
③クラウドサービス事業者自ら公開するホワイトペーパー・チェックシートの利用者による検証

問題点

次に、これら3種類の方法にはそれぞれどのような問題点があるのかを検討します。

①セキュリティ認証の取得・公開

何らかのセキュリティ認証を取得して、それを公表するケースが該当します。公共系では「政府が求めるセキュリティ要求を満たしているクラウドサービスを予め評価・登録」するためのISMAPという制度もスタートしています。

セキュリティ認証の長所として、一定の網羅性のあるフレームワークに基づいていること、第三者によるチェックが入ること等々が挙げられます。

しかし、現状ではこれらセキュリティ認証を取得していることの確認のみを持ってセキュリティについての確認義務を果たしたと評価しているケースはあまり多くありません（実際、後述するチェックシートなどでも「セキュリティ認証を取得していますか？」のような質問の後に個別の確認項目が並んでいます）。補強資料として非常に有用なものではありますが、単独では十分な保証を提供できていないことがセキュリティ認証の問題点ということができると考えます。

これはなぜでしょうか。例えば

セキュリティ認証の種類によって網羅性に一長一短あること
クラウドサービス利用者側に各種セキュリティ認証についての理解が不足しており、「そのセキュリティ認証によって何が認証されているのか」がわからないこと

などは理由として挙げられるかと思います。

しかし、私はもう少し心理的な要素…踏み込んで言えば「クラウドサービス利用者側も何らか認証取得の経験はあり、そこに存在するある種のフィクションに自身でも気づいているから」という要素が根底にあるのではないか…と考えています。

ある組織が「Aという要件を守れています」と主張するときに、自らの名前でそれを発信する場合と第三者に認証してもらう場合とで、要件を満たしに行く際の目標値（あらゆるケースで文句の付けようがない上限値 / 中央値 / なんとかチェックを切り抜けられるその場しのぎの下限値）に差異が生じるのではないでしょうか。

②クラウドサービス利用者から送付されるチェックシートへの提供事業者による回答

次は、いわゆるセキュリティチェックシートです。ここでは「クラウドサービス利用者が、それぞれ自社として必要であると考えるセキュリティ要件をチェックリスト形式で記載し、クラウドサービス事業者に回答の記入を求める」という運用を想定します。実務上は、①と併用する形で広く利用されている方法だと思います。国外企業だとシステム化している所もあります。

私はこのチェックシート運用に強い問題意識を持っています。端的に言えば、これはセキュリティチェックにおける免罪符的な運用がされているだけで、あまり実質的なセキュリティリスクのコントロールに役立っていないように感じるからです。

例えば、以下のような問題点が挙げられます。

クラウドサービス利用者視点
- 1体1でのチェックであり、回答内容に対する正確性は相手を信頼するしかなく、虚偽や不正確な回答に対する制裁が弱い
- 遵守できていないチェック項目が存在する場合でも、「他に選択肢が無い」「契約交渉が終了間際」等で交渉余地が少ないケースが多い
- チェック項目が少なくフォーマットはサービス共通であり、部分的にしかセキュリティリスクの評価ができていない
クラウドサービス事業者視点
- 逆に）チェック項目が多すぎる又は詳しすぎるケースがあり、（内部監査や親会社ならともかく）とてもその粒度で外部に開示できない
- クラウドサービス利用者それぞれからそれぞれ独自フォーマットのチェックシートが大量に送られてくるため業務負荷が非常に高い

これらの問題点の多くはすぐに解決できるものではないと考えていますが、例えば要件設定の根拠（「○○ガイドラインに基づいて設計しています」などの注意書きや、各要件で想定しているリスクシナリオなど）がクラウドサービス利用者・事業者間のコミュニケーションに含まれてくると、もう少し意味のあるものになるのかなと感じています。

もし仮に「チェックシートはコンサルが（親会社が）作ってくれたものをずっと使っているだけで、要件の背景や意図はわからない」のだとしたら、その儀式はクラウドサービス利用者・事業者双方にとって非常に不幸ですよね。その際、総務省ガイドラインを開いてみると要件の背景・意図を理解するのに役立つかもしれません。

③ホワイトペーパーや自社で用意したチェックシートの公開

個人的に一番有望だと考えている選択肢です。クラウドサービス事業者として、頻繁に回答を求められるような項目についてはチェックシート形式で開示してしまうのが良いと考えています。参考としてSmartHRさんやクラウドサインさんの例を挙げておきます。クラウドサービスレベルのチェックリスト（経産省）や安全なウェブサイトの作り方セキュリティ実装チェックリスト（IPA）を用いており、良い取組みだと思います。

この選択肢における問題点は、網羅性と制裁に関するものです。ホワイトペーパーはマーケティング的な要素もあり、どうしても自社が対応できている特定の部分を押し出す形になりやすいため、網羅性に難があります。情報発信自体は奨励されるべきことですが、「できていないこと」を明示的に書かないことが多いために間違ったユーザーの期待を醸成しかねません。

以前尊敬するエンジニアから

特定条件でしか働かないセキュリティ機能は、セキュリティ観点では無いよりマシではなくむしろ有害である
利用者の期待と現実のギャップが脆弱性としての深刻度につながる

という趣旨の話を聞いて非常に納得したことがあります。網羅性や制裁についての制約条件が無い中では、事業者のモラルに寄る所が大き過ぎるのが問題点だと考えます。

解決の方向性

現状行われているセキュリティチェックの方法について、それぞれ問題点を見てきました。それでは、これらの問題点を踏まえた上で、考えられる解決の方向性としてはどのようなものがあるでしょうか。私として2つの方向性を提示してみますので、皆さんのご意見もぜひお聞かせ下さい。

第三者確認モデル
まずは、第三者によるセキュリティ認証単独でチェックが完了することを目指す方向性です。仮にISMAPが広く浸透した場合には、民間分野でもISMAPの結果を利用するというのは一つのあり得る流れだと思います。ISMAPについては、現状における厳格な運用を維持したまま、（IaaSなどと比べて相対的に小規模な事業者も多い）SaaS領域での認証取得の流れを維持・拡大できるのかに注目しています。走り出しで色々と課題も多いようですが、良い制度として定着することを期待しています。

また第三者確認モデルにおける別の方向性として、VisionalさんのAssuredのような取組みにも注目しています。ISMAPより柔軟で、なおかつしっかりクオリティを確保できる、クラウドサービス利用者・事業者に広く浸透して信頼も獲得できるようであれば面白そうです。

自己宣言モデル
次に、クラウドサービス事業者による情報発信に軸足を置いて進める方向性です。この場合には、

使いやすいクラウドセキュリティについてのフレームワークの普及
一定の情報発信の義務化
虚偽や不正確な発信に対する制裁

が必要になると考えています。

1点目としては、まさにこの機能を総務省ガイドラインに期待しています。クラウドサービスに求められる「望ましい情報セキュリティ対策」が利用者・事業者参加の下で議論され、国際的なフレームワークとも調和した形で総務省ガイドラインとして定められると良いなと思っています。

2点目は個人情報という文脈ではありますが、令和2年改正個人情報保護法第27条が「安全管理のために講じた措置」など一定の情報発信を義務付けています。「安全管理のために講じた措置」については、措置が十分な網羅性を持っていることを担保するために一定のフレームワークに基づい説明するのが現実的な選択だと思います。現状だと個人情報保護法ガイドライン（通則編）の別添を参照する企業が多そうですが、総務省ガイドラインなどが参照されるようになると面白いなと考えています。

なお少し細かい話にはなりますが、27条1項が規定しているのは「保有個人データ」についてです。そのため、toCのSaaS企業がユーザーから受け取った個人データに対する安全管理措置は同条の直接的なスコープですが、toBのSaaS企業が他の企業から委託等で受け取った個人データは、同条の直接的なスコープではないとされることが多いと思います。この辺りは今後の改正を見守りたいと思います。

最後に3点目が制裁です。制裁としては現状レピュテーションとしての制裁があると思いますが、米国におけるFTC法のような取扱いも（独禁法、景表法、個人情報保護法…等々どれで対応するのかはともかく）あり得ると思っています。情報開示が一定程度進んでからの話だとは考えますが、実効性を担保する意味でも制裁の検討は避けて通れないと考えています。

終わりに

今回は総務省ガイドラインを取り上げながら、クラウドサービス利用者・事業者におけるセキュリティチェックのあり方について取り上げました。最後の「解決の方向性」では２つの方向性を提案しましたが、どちらの方向性においてもこれらを真に「解決」するためには、認証を鵜呑みにせずホワイトペーパーを批判的に検討できるような知識・理解が求められます。

そこで、初回のサブタイトルである「第三者認証に依存しない担当者になる」ための具体的な方法として、次回はクラウドサービス利用者側の担当者がどのようにセキュリティを学んでいくべきかについても検討します。