図解で１発理解！クラウド利用で知っておくべき責任分界点の誤解と要点

ここでは、クラウドの責任分界点について考えてみます。
過去、クラウドベンダー起因による事故事例も多数発生していますので、実は100%クラウドベンダーに任せるのではなく、利用するユーザー企業側でもデータを安全に保護する必要があります。

クラウドベンダー起因による事故３つの事例 (参考：クラウドセキュリティ～過去事例と現在～)
・Google事故事例
   2003年、非公開のドキュメントが共有されてしまうという不具合発生
   2014年、GoogleDriveを介して共有された一部ファイルが関係のない第三者が閲覧できてしまう問題が発生

・DropBox事故事例
   2011年、任意のパスワードであらゆるユーザーアカウントにアクセスできる障害が発生

・ファーストサーバー事件
   2012年、Zenlogicホスティングのサービスの契約している約5000社の顧客データがすべて消えてしまう問題が発生し、サーバーのデータをバックアップも含めて削除してしまった問題 

これらは、クラウドベンダー側のヒューマンエラーによるものミスと言えます。このような場合、ユーザー側でもデータ保護(バックアップ)をしておくことによって早期対応が可能になります。

クラウドサービスのよくある誤解！
これらはすべて誤解であり、IaaS / PaaS / SaaS によって責任範囲は異なり、ユーザーが責任を持つ領域が必ずあります。責任分界点は、選定先のクラウドベンダーや、サービス内容によっても異なるため、ユーザーは、サービス開始前に確認が必要となります。

柔軟性とコロナ禍でのリモートワークでの利便性、コスト削減などにメリットから、クラウドサービスへの移行が進められていますが、すべてのサービスに置いて、データはユーザーの責任範囲と謳われていますので、いざというときに備えて、バックアップを必ず行いましょう。 

また、クラウドサービス利用時には、トラブル発生時の責任をクラウドベンダーと利用企業(ユーザー)の間で分担し、契約時に責任を負う範囲「責任分界点」を確認しておくことをお勧めします。

参考：サービスレベルアグリーメント
AWS サービスレベルアグリーメント
Amazon EC2、Amazon S3などそれぞれのサービスアグリーメントのリンクです。
Azure サービスの SLA 概要
Azureで提供されるサービスのサービスレベルアグリーメントが記載され、詳細へのリンクがあります。

1. 責任分界点とは

責任分界点とは、企業とお客さまの責任範囲をわけている境界線のことをいいます。

クラウドの場合、「クラウドベンダー」と「利用ユーザー」にあたり、それぞれがどこまでを責任範囲とするのかを定めた境界線のことです。

「クラウド上で発生した問題はすべてクラウドベンダーの責任」とお考えの方ユーザー様もいらっしゃるかもしれません。これは誤解です。IaaS / PaaS / SaaS といったサービスそれぞれで責任範囲は異なり、ユーザーが責任を持つ範囲があります。

万が一、障害が発生した際にクラウドベンダーとユーザーのどちらに責任があるのかは、責任分解点に応じて決まります。見落とされがちな責任分界点ですが、あらかじめ定めておかないと障害発生時にトラブルに発展する危険性があります。

クラウドサービスは大きく「IaaS/PaaS/SaaS」の3種類に分類され、これらのサービスは、それぞれ責任分界点が異なります。

本記事では、これら３種類のクラウドにおける責任分界点について考えていきます。

2. クラウド利用で知っておくべき責任分界点

2-1. IaaS (Infrastructure as a Service) の責任分界点

IaaSにおける責任分界点はOSとなり、ハードウェア、仮想化ネットワーク基盤のインフラはクラウドベンダーの責任、OSから上はユーザーの責任と謳われています。

ユーザーは、使いたいプラットフォームやアプリケーションを自由に選択し構成することができますが、OS、ミドルウェア、アプリケーション、データを管理する必要があります。

サービスベンダーが責任を負うのは、インフラ(Infrastructure)部分のみであり、ユーザーは環境を自由に設計できます。カスタマイズ性は高いと言えますが、クラウドの仮想化基盤上で動作しているOSからすべての広い範囲をユーザーの責任で管理する必要があり、最適な形で利用するには高い専門知識が必要になります。

また、同様に責任範囲は、セキュリティ対策においても、OS、ミドルウェア、アプリケーションに対するパッチ適応や脆弱性対応などは、ユーザー側となるため、対策を講じる必要があります。

参考：IaaSのサービスには主に以下のようなものがあります。

・Amazonが提供する「AWS」 (Amazon EC2／Elastic Load Balancing (ELB)　など)
　AWS責任共有モデル (https://aws.amazon.com/jp/compliance/shared-responsibility-model/)

・Microsoftが提供する「Microsoft Azure」(Virtual　Machines／Load　Balancer　など)
　Microsoft Azureクラウドにおける共同責任 (https://learn.microsoft.com/ja-jp/azure/security/fundamentals/shared-responsibility)

ユーザーは用意されているアプリケーションを利用するだけで、アプリケーション上での設定内容とユーザーデータがユーザーの責任範囲となります。

サービスベンダーが責任を負うのは、動作しているアプリケーションまでのすべての層になります。IaaS、PaaSに比べると、ユーザーの責任範囲は最も小さくなりますが、一方でカスタマイズなどの自由度も非常に小さくなります。

参考：SaaSとして公開されている主なサービスは次のようなものがあります。数え切れないほどSaaSとして公開されていますので代表例をご紹介します。
・Microsoft Office 365などのオフィス関連ソフト
・GmailなどのWebメール
・サイボウズなどのグループウェア
・Arcserve などのバックアップサービス

さて、ここで良く誤解を受けるのが、データの責任範囲のバックアップです。

特に、SaaSでは、データのバックアップサービスを提供しているベンダーが多いのですが、基本的に有償サービスで提供されていますので、提供されているサービスの範囲でどこまで対応できるのかを確認しておきましょう。

クラウドサービスのよくある誤解！
これらはすべて誤解であり、IaaS / PaaS / SaaS によって責任範囲は異なり、ユーザーが責任を持つ領域が必ずあります。責任分界点は、選定先のクラウドベンダーや、サービス内容によっても異なります。

たとえば、データがランサムウェアによって暗号化されても、ベンダーの責任ではありません。

また、すべてのサービス提供において、データはユーザーの責任範囲となりますので、いざというときに備えて、バックアップを必ず行いましょう。

3. クラウド利用でユーザーが責任を持つ範囲とバックアップ

IaaS / PaaS / SaaS 責任範囲を2章で見てきましたが、クラウド責任分界点を境として、ユーザー自身がセキュリティおよびバックアップ対策を行う必要があります。

過去、ユーザー自身で対策を行っておらずセキュリティ事故につながるケースが多数ありました。

参考：【京大発】クラウドのセキュリティ事故の99%は設定ミス。AWS利用企業向けクラウドセキュリティ診断プラットフォーム「Cloudbase」ベータ版の事前登録開始

クラウドサービス利用時には、契約上の責任範囲をきちんとチェックし対策することをお勧めします。

万が一セキュリティ事故が起きたときに備えて、対応をユーザーとクラウドベンダーの間で相互認識し、どちらが責任を取るか明確にするためにも、責任分界点が重要となります。

ユーザー自身がバックアップを行わなくてはいけない理由は、IaaS / PaaS / SaaSでもデータ保護の責任範囲がユーザーにあるためです。守るべきデータがどこにあるのかをきちんと把握し、具体的な課題と対策を行います。

たとえば、Amazon EC2 などのサービスは Infrastructure as a Service (IaaS) に分類されているため、必要なすべてのセキュリティ構成や管理タスクはユーザー自身にあり、バックアップも実行する必要があります。

ただし、クラウドサービスの責任範囲は、サービスの利用環境や契約内容等によって異なる場合があります。

「SaaSに分類されるサービスだから、データだけ見ておけば良い」、といった考え方は、セキュリティ対策の見落としなどにつながります。クラウドサービスの中には、例えば、「Amazon Web Service」や「Microsoft Azure」といったIaaS、PaaSの上にアプリケーション環境を構築し、それを一つのSaaSとして提供している場合があります。また、ユーザー側でも複数のクラウドサービスを利用したりなど、クラウドの利用が複雑化しつつありますので、保護範囲の明確化が必要です。 

クラウドでのデータ消失リスクの詳細は、以下の記事を参考にしていただけます。
クラウド上のデータ消失を防ぐために利用企業がとるべき2つの対策

4. おすすめのクラウド バックアップ サービス

 クラウド環境でバックアップが必要な理由は、

の２つがあります。クラウドでのデータ損失に備えて最適なバックアップを行いましょう。

ここでは、バックアップベンダーが提供する具体的なサービスをご紹介します。
バックアップベンダーであるArcserveが提供するクラウド（Arcserve Business Continuity Cloud）は、4つのポイントでインターネット経由でもしっかりデータ保護・複製しますので安心です。

① Tier Ⅳ 相当（一部 Tier Ⅲ 相当）の高いセキュリティ・対災害性を持つデータセンターで運用しています。
② データの転送時はも保存時も暗号化するため、安全に転送・保存します。
③ ネットワーク障害など転送失敗時は自動リトライし、回線復帰後は未送信分の転送を再開します。
④ フルバックアップ転送は初回のみ、2回目以降は増分だけを圧縮転送。さらに帯域制御機能で日中業務への影響を軽減します。 

4-1. クラウドサービス：Arcserve UDP Cloud Direct

オンプレミスに資産を持たず直接クラウドへバックアップします。ご契約前にBaaS（Backup as a Service）か、DRaaS（Disaster Recovery as a Service）かを選択します。
※参考資料：Arcserve UDP Cloud Direct ご紹介プレゼンテーション

4-2. クラウドサービス：Arcserve UDP Cloud Hybrid

オンプレミス側でArcserve UDPまたは Arcserve UDP Appliance でバックアップを取得し、Arcserveクラウドへ二次保管します。ご契約前にBaaS（Backup as a Service）か、DRaaS（Disaster Recovery as a Service）かを選択します。
※参考資料：Arcserve UDP Cloud Hybrid ご紹介プレゼンテーション

4-3. バックアップソフト：Arcserve UDP

Arcserve UDP の RPS (復旧ポイントサーバ)または、 Arcserve UDP Appliance のバックアップデータをパブリッククラウドサーバーへ２次保管します。オンプレミスにサイト障害が発生した際に、パブリッククラウド上の仮想スタンバイ&インスタントVM を使って業務継続を可能にします。
※参考資料：Arcserve Unified Data Protection 8.x のご紹介
※対応するパブリッククラウドサービスは動作要件をご確認ください。Arcserve Unified Data Protection 8.X 動作要件

・Arcserve UDP の RPS でバックアップデータをパブリッククラウドへ転送

・Arcserve UDP の RPS でバックアップデータをパブリッククラウドへ転送＋災害対策用VMの起動

・パブリッククラウド サーバーのバックアップ
パブリッククラウドを利用したサーバーなどを同じパブリッククラウド内でバックアップを行うことができます。また、上記と同様にパブリッククラウドに「仮想スタンバイ」や「インスタントVM」を利用してバックアップ対象を起動することもできます。

ここでは、クラウドを利用した代表的なサービスをご案内いたしました。

各製品のQ&Aも公開されていますので、ご参考にしてみてください。
Arcserve UDP Cloud Direct よくある質問と回答
Arcserve UDP Cloud Hybrid よくある質問と回答

参考：クラウドサービスの規約関連情報

参考記事：
法人向けクラウドバックアップサービスの選び方・おすすめ製品や相場まで徹底解説クラウドバックアップとは？4つの効果から選び方まで徹底解説！

まとめ

すべてのサービスにおいて、セキュリティ攻撃や障害が発生する可能性があります。

万が一、のサービス停止時やセキュリティ対策を行うためにも、利用するサービスの責任分界点を明確にしておくようにします。

また、クラウドサービス利用時には、トラブル発生時の責任をクラウドベンダーと利用企業(ユーザー)の間で分担し、契約時に責任を負う範囲「責任分界点」を決めておく必要があります。
良く誤解を受けるのが、「データ」の責任範囲のバックアップです。
特に、SaaSでは、データのバックアップサービスを提供しているベンダーが多いのですが、提供されているサービスの範囲でどこまで対応できるのかを確認しておきましょう。

すべてのサービスにおいて、データを守ることはユーザーの責任範囲となりますので、いざというときに備えて、バックアップを必ず行っておくことをお願い致します。