長引くコロナ禍を背景に、企業ではリモートワークが定着し、どこからでもアクセスできるクラウドの活用が加速しています。そこでみなさんに考えていただきたいのは、クラウドにデータを保存するのは本当に安全なのか？ということです。
社内システム同様、クラウドでもシステム障害が避けて通れないことは、多くのみなさんにとって懸案事項でしょう。たとえば2019年8月には、Amazon Web Services（AWS）で日本に続きアメリカでも障害が発生し、顧客データが消失する事件が起こりました。直近では2021年12月にも、AWSのデータセンターでたびたび障害が発生し、Slack、Asana、Epic Gamesなどのサービスに影響が出ました。
クラウドベンダーが所有するデータセンターを利用してクラウドサービスを提供する企業にとっては、障害対策や負荷分散によってシステム障害を回避できれば理想的ですが、費用対効果の面から対応を見送る企業も多いのが実情です。
私たちはなんとなく、クラウドなら安心だと思いがちですが、こうした過去の例のようにクラウドも万全ではなく、データ消失というセキュリティリスクがあることを忘れてはいけません。
この記事では、クラウド上にデータを置くことのリスクと、企業がクラウド上のデータ消失を防ぐための対策とポイントをご紹介します。
目次
１．クラウド上にデータを保存するのは安全？データ消失のリスクの高さと可能性
クラウドを利用する場合、災害対策、障害対応、セキュリティ面など、サービス提供者によって一定レベルの安全性が保証されています。しかし、クラウドだから100％安全、というわけではありません。障害が発生した場合、復旧までの間、サービスが利用できないこともありますし、保存したデータが一部または全部、消失するリスクもゼロではないのです。
こうしたリスクは、大きく分けて
の2種類に分けられます。
1-1. 利用者に原因があるデータ消失リスク
データ消失リスクのもっとも多い原因は、利用者による設定ミスや操作ミスです。
クラウドは、コンピュータリソースをネットワーク経由で利用できるサービスです。IaaS（Infrastructure as a Service）*やPaaS（Platform as a Service）*のように、インフラのリソースやアプリケーション開発環境をインターネット経由で利用するサービスの場合、保存されているデータへのアクセス権限設定、セキュリティ確保のためのファイアウォールの設定などを利用者自身が行う必要があります。ここで設定ミスを起こすと、データの削除や機密情報の流出といったリスクが発生します。
私たちに最も身近なクラウドサービスは、オフィスソフト、Webメール、オンラインストレージ、グループウェアなど、クラウドサーバーにあるソフトウェアをインターネット経由でユーザーが利用するサービス、SaaS（Software as a Service）*ですが、このSaaSにおいて最もデータ消失のリスクが大きいのは、利用者が間違えて削除してしまうケースです。
* SaaS（Software as a Service）：ユーザーにソフトウェアをインターネット上で提供するサービス。
* PaaS（Platform as a Service）：主にプログラムの開発環境やデータベースをインターネット上でエンジニアなどに提供するサービス。
* IaaS（Infrastructure as a Service)：サーバーOSなどハードウェアからインフラまでを提供するサービス。
1-2. クラウド環境やクラウドサービス提供側に原因のあるデータ消失リスク
クラウドは、クラウドサービス事業者が保有するサーバー群で構築されているため、
●サーバーの故障や災害時のハードウェア損壊などによるデータ消失のリスク
●クラウドサービス事業者の設定・操作ミスなどによるデータ消失、サービス停止のリスク
などが想定されます。
データ消失以外では、システムダウンやサイバー攻撃などによる顧客情報や企業の機密情報などの漏えいリスクも、企業の存続を左右しかねない、重大なセキュリティ課題です。
1-3. クラウドでのデータ消失事例
過去に起こったクラウドでのデータ消失事故には、
●人的ミスが原因で起こったもの
●ソフトウェアの誤作動やバグが原因で起こったもの
●火災や停電によるもの
など様々な原因がありました。
10年ほどさかのぼりますが、レンタルサーバー会社で更新プログラムのバグとバックアップの不備を原因とする大規模なデータ消失が発生した事故を覚えていらっしゃる方も少なくないはずです。
| 発生日 | 原因 | 詳細 |
|---|---|---|
| 1. 利用者に原因があったデータ消失事故 | ||
| 2020/11/1 | 人為的ミス | ふくい産業支援センターが運営するWebサービス「ふくいナビ」 ・原因：サーバー管理者の手続き上の不備 ・詳細：2020年10月31日を更新期限とするクラウドサーバーの賃貸借契約を、期限前の同年10月13日に更新したが、サーバー管理者のNECキャピタルソリューションの社内手続きの不備により更新処理が反映されずに貸与期間が終了。クラウドデータが完全に消えてしまった。 |
| 2020/8/7 | ソフトウェアの誤作動 | キヤノンが運営する写真保存用クラウドサービス「image.canon」 ・原因：ソフトのバージョン切り替え時の誤作動 ・詳細：ユーザーが保存した静止画・動画データの一部が消失。原因はソフトウェアの誤動作。同社が7月30日、image.canonのサービスをコントロールするソフトを新バージョンに切り替えた際、短期保存ストレージ用のプログラムコードが長期保存ストレージ機能でも作動してしまい、長期保存用データの一部が消失した。 |
| 2012/6/20 | ソフトウェアのバグ | レンタルサーバー会社のファーストサーバー ・原因：脆弱性対策のための更新プログラムのバグ ・詳細：2012年6月、ファーストサーバ（2019年4月にIDCフロンティアと合併）は脆弱性対策のための更新プログラムのバグに気づかないまま、本番環境のサーバーで起動、対象外のサーバーでファイル削除コマンドを実行し次々とデータを消去。本番系、待機系に加え、同じサーバー内にあるバックアップ系のHDDも消去。ウェブサイトやメール、顧客情報やスケジュールなど様々なデータが失われた。被害顧客件数は5698件、ほとんどが復旧不可能だった。 |
| 2.クラウド環境やサービス提供側に原因があったデータ消失事故 | ||
| 2021/3/10 | 火災 | OVHのデータセンターでの大規模火災 ・原因：OVHクラウドが運用するデータセンターの火災 ・詳細：データセンター4棟のうちビルが1棟全焼、1棟は一部焼失。オンライン人気サバイバルゲーム『Rust』などの非常に広い範囲でサイトが落ちたり、サービスが使えなくなるなどの障害が発生。EU地域のサーバーは全滅が確認され、データは回復不能と発表。 |
| 2019/8/31 | 停電 | AWS ・原因：データセンターでの停電とその後のバックアップの発電機の故障 ・詳細：いくつかの仮想サーバーインスタンスが消失し、クラウドでホストされているボリュームも破壊され、EBSスナップショットから手作業でデータを復元した。 |
★データ消失だけではない、クラウドのセキュリティ面でのリスク
ここではデータ消失の事例のみご紹介しましたが、機密情報への不正アクセスや情報漏洩のケースはさらに多く発生しています。最近では、2020年12月から2021年初旬にかけて、Salesforce利用者によるアクセス権などの設定不備に起因した不正アクセスや情報漏えいが、複数の大手上場企業や約20もの自治体から相次いで報告されています。
Salesforceサイトおよびコミュニティにおけるゲストユーザのアクセス制御の権限設定について
２．クラウド上のデータ消失を防ぐために利用企業がとるべき対策
クラウドをより安全に利用し、データ消失を防ぐために企業がとるべき対策、そのもっとも大切なものは、
の２点です。
この章ではもっとも身近なクラウドサービスであるSaaSを例にとって、「バックアップ」「可用性」「セキュリティ基準」という3つの観点での対策をご紹介します。
2-1. 独自にバックアップを取る
サービス事業者まかせにはせず、重要なデータはローカルまたは別のクラウドにバックアップしておくことをお勧めします。データの最終的な保護責任は利用者にあります。
最近では多くの企業が、オフィスソフト、Webメール、オンラインストレージ、グループウェアをクラウドで利用しています。しかし、こうしたSaaSのデータを別の場所にバックアップしている人は、意外と少ないのです。
もしSaaSのデータのバックアップを取っていない企業が
★間違えてデータを削除してしまったら
★システム障害やサービス事業者側のミスでデータが消えてしまったら
データが復元できなくなってしまう可能性があります。
| ★間違えてデータを削除してしまったら |
|---|
| ●ゴミ箱にある場合は、一定期間は保存されているので、復元可能な場合がある （保存期間はサービスによって異なります） |
| ●一定期間を過ぎたら復元できなくなる |
| ★システム障害やサービス事業者のミスでデータが消えてしまったら |
|---|
| ●SLA(Service Level Agreement)*の範囲内でサービス事業者が対応する |
| ●データの復元が不可能なこともある |
「クラウドにデータを置いておけばバックアップは必要がない」「クラウドサービス事業者がバックアップをとっているだろう」と安心するのは危険です。SLAの範囲内であればサービス事業者がバックアップを取り、復元することも可能ですが、場合によっては復元できないケースもあります。
サービス利用規約「損害賠償の制限・免責等」に、地震や台風といった大規模災害や、データセンター施設の火災などにより広範囲に設備が破損して回復が困難な場合や、OS/アプリケーションの不具合、誤操作などの論理的な障害についてはデータの保証は行わない、といった主旨のことが明記されている場合があるのでご注意ください。
* SLAはサービスレベルの指標です。SaaSの場合には、サービス稼働実績や稼働率が一定基準を下回っていないか、といったサービスの信頼性を測ることができます。
2-2. 自社の基準に合うサービスを利用する
自社の求める基準を満たすサービスを利用しましょう。その主な基準とは、
①可用性
②セキュリティ
です。
2-2-1. 可用性
何らかの原因でシステム障害が発生した場合でも、システムを停止させることなく稼働できるサービスを選択しましょう。
判断材料は可用性（Availability）です。機器の故障や停電、災害時でもシステムを停止させることなく稼働し続けること、またはその指標のことをいいます。可用性は「一定時間のうち、システムを稼働可能な時間の割合（％）」を意味する「稼働率」で表現され、特にクラウドサービスにおいてサービスの品質を判断するSLAの基準値として用いられます。
可用性を計測し数値で表現する際に使われるのが「稼働率」です。稼働率は、運用時間のなかでシステムが正常稼働していた時間の割合のことを指します。たとえば運用時間が100時間で、そのうち99.9時間は正常に稼働していたのであれば、稼働率は「99.9÷100＝0.999（99.9％）」です。この数値が100％に近いほど、稼働率が高いシステムと言えます。
稼働率は、「MTBF（Mean Time Between Failure）」「MTTR（Mean Time To Repair）」という2つの指標でより詳しく計算することも可能です。
| 稼働率の指標 | 意味 |
|---|---|
| MTBF | 平均故障間隔：故障が発生してから、次の故障が発生するまでの平均的な間隔 |
| MTTR | 平均修復時間：システムに障害が発生してから修復が完了するまでにかかる平均的な時間 |
ビジネスの中核を担う重要なシステムの場合、ほんのわずかな停止時間でも大きな損害が生じかねません。最近では99.999％という、限りなく100％に近い稼働率を保証するサービスも登場しています。止められないシステムでは、ダウンタイムの大幅な削減を期待できる、こうした高い稼働率のサービスを選択する必要があります。
また、高い可用性を確保する方法のひとつとしては「冗長化」があります。通常のシステム構築費用よりコストがかかりますが、重要なシステムの場合は可用性の向上を目的として導入する企業が少なくありません。
2-2-2. 高度なセキュリティ基準を満たすサービスを利用する
クラウドサービスを利用する際には、事業者がクラウドに特化した情報セキュリティ対策を、継続して適切に行っているかどうかを確認した上で選定する必要があります。自社の求めるセキュリティレベルに応じた、高度なセキュリティ基準を満たすサービスを選択しましょう。
クラウドサービスでは、より高いセキュリティをめざし、堅牢なセキュリティを証明する基準を定めています。クラウドサービスに特化したセキュリティ基準には、主に以下の6種類があります。
- ISMSクラウドセキュリティ認証(ISO27001／ISO27017)
- CSA STAR認証(CSA Security)
- StarAudit Certification
- FedRAMP
- SOC2（SOC2＋）
- CSマーク
| 名称 | 形態 | 内容 |
|---|---|---|
| 世界で通用するもの | ||
| ① ISMSクラウドセキュリティ認証 | 第三者認証 | ISMSクラウドセキュリティ認証(ISO27001／ISO27017)は、ISO/IEC 27017:2015はISOより発行されたクラウドセキュリティに関する国際規格で、クラウドサービスの提供および利用に関する情報セキュリティ管理のためのガイドライン。 |
| ② CSA STAR認証 | 内部監査可 | CSA STAR認証(CSA Security)は、Cloud Security Alliance (CSA、クラウドコンピューティングのセキュリティを確保するための米国業界団体)によるセキュリティ成熟度を評価する制度で、ISO/IEC 27001アドオン規格。 |
| ③ StarAudit Certification | 第三者認証 | EuroCloud Europe (ECE)による認証制度。CSP（クラウドソリューションプロバイダ）の情報、法的事項、セキュリティとプライバシー、データセンター、運用プロセス成熟度、クラウド形態の6つの領域に分類し、それぞれ星の数を3つから5つまでを評価する。 |
| ④ FedRAMP | 第三者認証 | 米国政府機関がクラウドサービスを調達するにあたって採用している共通認証制度。製品やサービスに対するセキュリティ評価、認証、継続的監視に関する標準的なアプローチを示している。 |
| ⑤ SOC2 （SOC2＋） | 第三者認証 | SOCは「Service Organization Controls」の略で米国公認会計士協会(AICPA)が定める、委託会社の内部統制やサイバーセキュリティについての内部統制保証報告の枠組み。SOC報告書は数種類あり「SOC2」「SOC2＋」では、企業が監査してほしいサービスやシステムを対象に、セキュリティや可用性などの統制を評価します。具体的には「セキュリティ」「可用性」「処理のインテグリティ」「機密保持」「プライバシー」の5つの指標があり、この中から任意の項目について評価を受けるもの。 |
| 日本で通用するもの | ||
| ⑥ CSマーク | 内部監査可 | 日本の特定非営利活動法人日本セキュリティ検査協会(JASA)による情報セキュリティ監査制度で、その認定マークがCSマーク。認証段階にはゴールド(第三者認証)とシルバー(自主監査)があり、レベルや目的に応じて対象を選択できる。 |
グローバル展開を進める企業では、世界中で通用する①～➄のセキュリティ基準への準拠が必要です。
また、国内で主流となるのが⑥のCSマーク（クラウドセキュリティ・マーク）です。経済産業省が策定した「情報セキュリティ管理基準」 に基づいているため、その取得は国内クラウドサービス事業者に必須と言えます。これらを判断基準にサービス選定を実施することをお勧めします。
３．データ消失における責任の考え方
クラウドサービス契約時におさえておくべきポイントとは：
クラウドでは、インフラやプラットフォームをサービスとして利用する場合（IaaS/PaaS）であっても、ソフトウェアをサービスとして利用する場合（SaaS）であっても、基本的にデータ保存の責任は利用者側にあることを忘れてはいけません。
クラウドサービスにおける責任範囲は以下のように定義づけられています。
| クラウドサービスにおける責任範囲 |
|---|
| ・IaaSの場合 |
| クラウドベンダーの責任範囲はハードウェア基盤のみ。 OS、ミドルウェア、アプリケーション、データは利用者の責任 |
| ・PaaSの場合 |
| クラウドベンダーの責任範囲はハードウェア基盤、OS、ミドルウェアまで。 アプリケーション、データは利用者の責任 |
| ・SaaSの場合 |
| クラウドベンダーの責任範囲はハードウェア基盤、OS、ミドルウェア、アプリケーションまで。 データは利用者の責任 |
＜責任範囲のイメージ＞
多くのクラウドサービスでは、サーバー、ストレージ、ネットワークなどの機器が二重化（冗長化）され、サーバーで障害があった場合にでも自動復旧が可能であるとしています。
ただし、サービス利用規約をよく読むと、免責の箇所に「サイバーテロ、自然災害、第三者による妨害等、不測の事態を原因として発生した損害については、本規約の規定外の事故であることから、本サービスの提供が困難な不可抗力とみなし、当社は一切責任を負いません。」という文面があることに気づくでしょう。
※データ保証の適用範囲は、契約するサービスやSLAによって異なるため、事前に十分な確認が必要です。
４．クラウド上のデータを保護する方法～Microsoft 365の例
この章では、クラウドのデータを保護するために具体的にどうしたらいいか、広く企業に利用されているクラウドサービスであるMicrosoft 365のデータバックアップを例にご紹介します。
結論から言うと、Microsoft 365標準機能でもデータの復元ができますが、できないこともあります。
それをカバーするにはバックアップソフトを利用するのが安全です。
4-1. Microsoft 365の標準機能でできること、できないこと
Microsoft 365に含まれるメールサーバサービス「Exchange Online」やファイル共有サービス「SharePoint Online」などには、削除されてしまったデータを復元する機能が標準で備わっています。しかし、この標準機能では常にデータが復元できるわけではありませんし、ユーザー企業によるデータ復元には限度があります。
Microsoft 365のデータ削除には
・データを回復可能な状態に保つ「ソフト削除」
・完全にデータを消去する「ハード削除」
の2種類があります。
| ●ファイル同期サービス「OneDrive for Business」でのデータ復元： | 削除されたファイルはOneDrive for Businessの「ごみ箱」から93日以内であれば復旧できます。 |
| ●メールサーバサービス「Exchange Online」でのデータ復元： | 削除されたメールを「削除済みアイテム」のフォルダーに移動し、あらかじめ定められた期間内であれば 復元可能です。 |
データを「ハード削除」した場合、エンドユーザーのメールボックスは完全に削除され、Microsoft 365の標準機能で対象のデータを復元することはできません。
4-2. お勧めしたいのはArcserve UDPを利用したMicrosoft 365のバックアップ
Microsoft 365のバックアップにお勧めしたいのは、バックアップソフトウェアの「Arcserve UDP」です。理由は２つあります。
①Microsoft 365の標準機能だけでは不十分なデータ保護をArcserve UDPが実現するから
②バックアップデータへのランサムウェア対策に有効だから
4-2-1. Microsoft 365の標準機能だけでは不十分なデータ保護をArcserve UDPが実現
Microsoft 365の標準機能でできないことをご紹介しましたが、それだけではありません。
標準機能だけでは物足りない理由は以下の5点です。
これらをすべてカバーできるのが「Arcserve UDP」です。なかでも最大の理由は、データ保護の方法が簡単で確実な点です。
Microsoft 365の標準機能では、Exchange Online、クラウドストレージのOneDriveや社内共有向けSharePointなど、サービスごとに異なるバックアップ方法やリカバリが必要となり、非常に煩雑ですが、Arcserve UDPを使うと、まとめて、簡単かつ迅速にバックアップとリカバリが可能です。特にバックアップやリカバリが必要な緊急時には、簡便に操作できることが非常に大切です。
4-2-2. バックアップデータへのランサムウェア対策に有効
重要なデータについては、クラウド上に保存したデータを上書きできない「オブジェクトロック」を採用しているクラウドにバックアップすることをお勧めします。これを実現するのがバックアップソフトウェアの「Arcserve UDP」です。
Arcserve UDPは、オブジェクトロックが有効になったAmazon S3、Wasabi Hot Cloud Storage、Nutanix Objects をサポートしています。Arcserve UDPを利用すると、Microsoft 365やオンプレミスのデータをこれらのオブジェクトストレージサービスに2次バックアップ（バックアップの複製を送る）することができます。オブジェクトロック機能を利用することで、保存されたバックアップデータを改ざんしたり削除したりすることができなくなり、ランサムウェアなどの脅威からバックアップデータを守ることができます。
※詳細は「ArcserveによるMicrosoft 365のデータ保護方法」をご覧ください。
※Arcserve Japanでは、Microsoft 365のバックアップ、ランサムウェア対策、クラウドバックアップなどをテーマにした様々なオンラインセミナー（無料）を実施しています。ぜひご参考になさってください。
まとめ
この記事でご理解いただけたように、オンプレミス同様、クラウドにもデータ消失のリスクが潜んでいます。これを避けるために利用企業がとるべき対策は３つあります。
1. バックアップを取る
2. 可用性の高いサービスを利用する
3. 高度なセキュリティ基準を満たすサービスを利用する
重要なことは、クラウドサービス事業者まかせにはせず、自分たちでバックアップを取ることです。
バックアップの方法にはいろいろありますが、万が一の場合にデータをすぐに復元することができるかどうか、これがもっとも気になるところです。
クラウドのデータが消えてしまって動揺しているときに、煩雑な手順でのデータ復元は困難だと思います。操作が容易でわかりやすいArcserve UDPなら、いざという時に心強いですね。
転ばぬ先の杖として、クラウド上のデータもバックアップをとっておくことを強くお勧めします。
コメント