富士通クラウドダイレクトブログ

初心者エンジニア向けTechBlog

富士通クラウドダイレクトブログ

初心者エンジニア向けTechBlog

クラウドの情報セキュリティについて責任分界点から解説する(前編)

この記事は、ニフクラブログで2021-11-08に公開された記事を移転したものです。

こんにちは。富士通クラウドテクノロジーズの鮫島です。

今回はクラウドの情報セキュリティについて、基礎的なところを初心者エンジニア向けに前編・後編に分けて解説します。

年間通じて、コンスタントに寄せられるお問い合わせですがこういうのがあります。

「ニフクラさん(富士通さんのFJ Cloud-V)って、●●●●の認証取得されてますか?」

ちなみに、●●●●は下記のようなものが該当します。

 ・ISMS
 ・SOC2
 ・FISC
 ・ISMAP

※●●●●は認証じゃないぞ!というツッコミはいつも社内で実施しています。

なぜ、このようなお問い合わせがあるのか? それは、クラウドサービスならではの、責任分界点の存在から説明しなくてはなりません。

共同責任モデル、責任共有モデルとも言います。

なぜ責任分界点が生じるのか?

企業のITシステム(サーバーとかネットワーク機器とか電源とかもろもろ)をすべて自社で所有(オンプレミス)している場合、責任の所在はすべてその企業にあります。

クラウドサービスの場合、上記のようにユーザーとクラウド事業者の間で責任分界点が生じます。

サーバーにミドルウェアを載せた状態の仮想マシンを、インターネットを通じてユーザーに貸し出して、ユーザーは、貸し出された仮想サーバーに、自らの責任で OSやソフトウェアをインストールして利用します。これが、IaaSと呼ばれる形態のクラウドサービスです。

とりあえずIaaSを例にしてお話をしますが、ユーザーが自分で直接管理できる領域と、クラウド事業者しか管理できない領域が生じます。 セキュリティの責任範囲が明確に分かれてしまいます。

クラウドと外部監査の受け入れについて

ユーザーが、直接管理できない領域に関して安全性を確認するために

「立ち入り監査は可能でしょうか?」

という流れになるのはクラウド以前の世界なら自然でしょう。

とはいえ、監査には多大なコストがかかります。 データセンターや企業の内部・施設・運用に対する監査は、ユーザー側にも監査を受ける側にも多大な負担がかかります。

そもそも、ほとんどのクラウドサービスは

「データセンターの所在地は非公開」です。

※おもに物理的攻撃、サイバー攻撃のリスク回避のため

クラウドサービスという、仮想化したサーバーをオンデマンドで貸し出す形態なので、仮にデータセンターに立ち入り監査を行ったとしても、自社の仮想サーバーがどの筐体で稼働しているかを特定することも困難ですし、そもそも意味がありません。

ブラックボックスを提供するクラウド事業者を信用する?

とはいえユーザーから見て、物理機器とミドルウェアを載せた仮想マシンの裏側は完全なブラックボックスです。

 万全のセキュリティ対策!
 お客様のデータを心を込めて守ります!

ブラックボックスでは、まったく信用できる材料がありません。

いろいろ危うい企業かもしれませんし…

前述のように、基本的にデータセンターの所在地は非公開であり、外部監査の受け入れは行わないのが普通です。

・本当にデータセンターの場所って安全な立地なの?洪水で浸水しない?
・同じ物理サーバー上の他社の仮想マシンから自社のデータが見えないよね?
・御社の社員が実はデータ覗き見し放題になってたりしないよね?

とか、いろいろ不安が生じると思います。

このギャップを埋める方法は何か?

適切な情報開示と第三者認証

クラウド事業者による、責任分界点に応じた適切な情報開示が重要なポイントになります。

クラウド事業者のサービスが安全に運営されているかどうかを、客観的に判断する材料の一つに情報セキュリティに関する第三者認証の取得監査報告書の公開があります。

つまり、外部からの監査受け入れではなく、クラウド事業者自身が監査を行い(内部監査・外部監査)、認証機関や監査法人がその結果を保証するという方法です。

ポピュラーなところでは、ISMSがあります。

こちらは一般的なISMS(ISO/IEC 27001)認証です。

認証規格:ISO/IEC 27001:2013,JIS Q 27001:2014

上記認証を取得した上で、クラウド固有のリスクを考慮してアセスメントを行う追加認証ISMSクラウドセキュリティ認証(ISO/IEC 27017 )も存在します。

認証規格:JIP-ISMS517-1.0(ISO/IEC 27017:2015)

これは、クラウドサービスならば必須の認証と言えます。

・・・が、情報開示という観点では多くのユーザーにとって十分ではありません。 なぜなら、開示されているのはISMSの認証を取得しました!というお墨付き「認証番号」だけであり、具体的な管理策がどのようなものかは、非公開だからです。

ユーザー企業からクラウド事業者に「当社の要求事項をまとめたセキュリティチェックシートを埋めていただけますか?」という依頼が後を絶たないのはそういった理由もあります。

セキュリティホワイトペーパーの意味

そこで、情報開示の手段として注目すべきは「セキュリティホワイトペーパー」です。 主なクラウド事業者では、セキュリティホワイトペーパーを公開しているはずです。

もちろん、ニフクラでもセキュリティホワイトペーパー(PDF)を公開しています。

ニフクラのセキュリティホワイトペーパーでは、情報セキュリティの三要素である「可用性」「気密性」「完全性」に沿って、管理策を記載しています。

さらに!ISMSの管理策が気になって仕方がないという方に朗報です。 ISMS に基づいた情報セキュリティマネジメントの実施にあたり、リスクアセスメントの結果を考慮し必要な対策を実践していることを分かりやすくするために 「附属 A:ISO/IEC 27001 Annex A」との関連について、簡易版ながら対照表が付属しています。

ISO/IEC 27001 管理策 に該当する箇所が逆引きできます

それだけ、ブラックボックスであるクラウドの安全性を客観的に証明することの困難さが少しでもお分かりいただけたでしょうか?

第三者認証や監査でセキュリティ強度を判断できるのか?

それでも、こういうお問い合わせがあります。 「ISMSの認証は確認しました。SOC2の報告書はありますか?」

これはどういうことか、初心者にわかりやすく説明します。

・ISMSは内部監査の結果を監査法人が判断して認証する
・SOC2は外部監査の結果を報告書として公開する

SOC2のほうが、より客観性が高く感じますね? ただ、SOC2ってそもそも「内部統制の有効性を評価する」ことが主目的だということを理解されている方はあまり多くありません。

「ちゃんと内部統制が効いてるな…これなら大丈夫」というより、「SOC2は外部監査の報告書だから安心感がある」というニーズのほうが多いと思います。

何が言いたいかというと、第三者認証や監査報告書はそれぞれの本来目的に沿った利用をすべきということです。

SOC2に関していうならば、本来は具体的に自社の想定しているクラウドサービス特有の脅威に対して、クラウド事業者の内部では経営者や従業員が組織全体で遵守すべきルールに沿ってサービスを適正に運用しているか?どのような仕組みでリスクを軽減しているか?を確認することが本質です。

セキュリティホワイトペーパーは、そういった情報開示を補足する機能を持つべきものですし、自社特有のセキュリティ要件があれば、お問い合わせいただくことをお勧めします。

ところでISMAPってどうなの?

唐突にISMAPの話が出てきましたが、最近非常にお問合せが増加しています。 ISMAPとは、政府が情報システムを調達しやすくすることを目的としたクラウドサービスの登録制度ですが、実際のところ民間企業がクラウドサービスのセキュリティ評価に活用することも想定されています。

これまでの認証や監査報告書やセキュリティ基準と一線を画す点は、

「日本政府がセキュリティ水準を定めた」ところです。

エンタープライズ利用、特にシステムの停止が社会に影響を及ぼすようなサービスのインフラとして、クラウドサービスを利用する際にISMAP登録サービスを選択することは理にかなっているでしょう。

特にISMAPは、下記の3つの管理策基準に基づいて監査を行っています。

 ・ガバナンス基準
 ・マネジメント基準
 ・管理策基準

つまり、経営者が管理者へのガバナンス、管理者から業務実施者へのマネジメント、業務実施者が個別のセキュリティ対策としてどういった管理策を行っているか?という基準での監査です。

これを、毎年継続して監査を実施して更新する必要があり、SOC2の報告書を求めるユーザー本来のニーズである内部統制が一定の水準にあることが極めて厳格に評価されていると言えます。

ISMAPについては、こちらの記事もご覧ください。

blog.pfs.nifcloud.com

なおニフクラは、現在ISMAP登録サービス申請中です。
ニフクラ/FJcloud-Vは2021年12月20日にISMAPクラウドサービスリストに掲載されました!

後編に続く blog.pfs.nifcloud.com