クラウドの障害からデータを護れ~ユーザー部門の学び~
- コラム
- クラウド
クラウドを利用したサービスの障害は、これまでも度々発生してきましたが、その中でも2019年は重大障害が発生しました。自治体クラウドに使われている日本電子計算株式会社の障害では、ついに大量のデータを喪失する事故になりました。
クラウドの利用拡大が予測される中、残念ながら、クラウド利用のノウハウ、技術が確立している状況にはありません。オンプレミスシステムに比べてクラウド利用では、ユーザー部門の判断、責任が一層重くなっています。今回は、クラウド障害でデータを喪失させないため、ユーザー部門として学ぶべきことについて検討します。
1.2019年に発生した主なクラウド障害事例
日本のクラウドで最初に大量のデータを喪失したのは、2012年6月に発生したファーストサーバ株式会社のレンタルサーバ事故※1です。その事故は、「メンテナンス作業のミス」をきっかけに発生しました。それから7年も経過した2019年でも以下のような大規模障害が発生しています。このことから、このようなクラウド障害が無くなることを期待するのではなく、今後も発生することを前提にクラウドを利用することが賢明であることがわかります。自治体クラウド以外は、データ喪失にまで至っていませんが、障害は障害を呼び多重障害となりがちであることから、他のケースもデータ喪失に至るリスクを含んでいたと考えられます。
※1.詳しくは、情報資産管理マガジン「クラウドは万全ではない―バックアップの必要性について」をご参照ください。
(1)Amazon Web Services(AWS)東京リージョン サーバ停止
・障害発生日(日本時間);2019年8月23日
・障害発生範囲;AWS 東京リージョン
・障害発生契機;データセンター制御システム変更によりフェイルセーフが誤作動し、サーバのオ
ーバーヒート(過熱)によりサーバ停止
・障害の直接的原因;データセンター冷却システムのソフトウェア不良
・障害の影響;数時間のサービス利用不可。多くのオンライン決済、オンラインゲームなども利用
不可となる。
・障害が拡大した要因;冷却システムのモード切替え、手動切り替えにも失敗
(2)Office365 メール受信障害
・障害発生日;2019年11月19日
・障害発生範囲;日本、オーストラリア、インドのOffice365ユーザー
・障害発生契機;スパム対策更新の可能性
・障害の直接的原因;メールフローに予想していない影響があった
・障害の影響;メールが受信できない、受信が遅延する影響が約11時間続いた
・障害が拡大した要因;障害原因の推定に時間を要した。
(3)自治体クラウド データ喪失事故
・障害発生日;2019年12月4日
・障害発生範囲;日本電子計算株式会社IaaSサービス Jip-Base
・障害発生契機;ストレージ障害によるサーバ内データの読取り不可
・障害の直接的原因;サーバに使用のSSD(半導体ディスクドライブ)のファームウェア不良
・障害の影響;保有していたデータの15%について、データ回復不能、データ喪失となった。12月
16日時点で、33自治体に影響があった。
・データ喪失に至った原因;バックアップが不完全で回復に使えなかった。バックアップデータが
取れていなかったものと、バックアップは取れていたが、仮想OS経由でありリストアする業務を
特定できないものとがあった。
2.クラウド利用拡大におけるトレンド
日本国内における情報資産管理においては、情報漏洩防止、個人情報漏洩防止等の「情報セキュリティ」については、既に意識も高く、各組織内においても重点的にチェックされています。経済産業省発行のクラウドのガイドラインも「クラウド利用のための情報セキュリティマネジメントガイドライン」であり、情報セキュリティ中心になっています。一方、データを護る、データ喪失を防止する「データ保全」については、情報セキュリティ管理のおまけ程度の扱いで、意識すら低いことが多いのが実情です。
このような状況の中、各社のIT部門においては、RPA,AIなどの新たな課題が多くなったこと、インフラをクラウドに移行することが増えたことで、データ保全の基本であるバックアップ、アーカイブについての見識、経験を持った技術者が減少の一途を辿っております。すなわち、クラウドについては、データ保全のブラックボックス化が進んでいます。
このため、ユーザー部門※2においては、クラウドサービス提供業者やクラウドを使ってサービスを構築するSlerへの依存傾向が進んでおります。
※2.ここでは「ユーザー部門」とは、クラウドを利用して、社内、社外にサービスを提供する直接の責任部門のことを指します。
3.責任共有モデルのインパクト
しかしながら、AWSをはじめとして大手のパブリッククラウド提供サービス業者は、以前より、「責任共有モデル」を前提として、サービス提供を行っています。すなわち、「種々のサービスは提供するが、その稼働率、信頼性は100%ではないので、利用者が必要な稼働率、信頼性になるよう提供しているサービスメニューを組み合わせて構築する。」ことをクラウド使用の前提条件においています。
クラウドを利用すると、データの保全性についての目標仕様を決定するのは、ユーザー部門になってきます。オンプレミスシステムの時代からユーザー部門が仕様を決定し、システム構築し、運用してきたのでしたら、ユーザー部門にも経験、ノウハウが蓄積されているのでこの流れも納得ですが、皆さんの会社ではいかがでしょうか。そんなことまでできている会社は稀なのではないでしょうか。
働き方改革の中で、現状の作業分析をしようとしても、何故、その作業をやるのか、他の方法ではだめなのかについて、業務を遂行するユーザー部門は理解しておらず、「前任者がやってきた通りやっています。」ということは多いのではないでしょうか。データの保全についても同様で、長い歴史の中で問題が発生する度に少しずつ改善をして来たというケース。また、真剣にデータ保全を考えた人が以前いて、仕組みを考えたが、今は退職しその考え方はわからならないまま形だけを踏襲しているというケース。このようなケースが大半であろうと思います。
つまり、現状のユーザー部門のほとんどは、「データ保全」の仕様を出せるだけの力量はないのに、クラウド利用ではそれを要求されるという矛盾が生じています。
4.データ喪失につながるITシステムに潜むリスク
クラウドのみならずオンプレミスシステムにおいても、データ喪失につながるITシステムに潜むリスクについては、ユーザー部門の方にも理解して頂き、「データ喪失防止のため、ユーザー部門はどうすべきか。」という対応策検討の際に、共通認識をもって頂く必要があります。以下は、そのリスクの例です。★印は、補足のコメントです。
(1) どんなソフトウェア、ファームウェアにも不具合は潜在化することがある。
★自治体クラウドでは、SSD障害は運用の想定内とすべきものであった。
(2) どんなハードウェア、装置も故障するものである。
(3) メンテナンスをすると障害が発生するケースがある。
★AWS 東京リージョン サーバ停止、Office365メール受信障害のいずれも、メンテナンス・
システム変更を契機に障害が発生している。
(4) 運用には、人的ミスがつきものである。
★自治体クラウドでは、
・SSDの変更対策パッチがあったが気づかなかった。
・バックアップが取れていないことに気づかなかった。
(5) 基本システムやバックアップストレージを同じ仕組みで多重化し、冗長構成としても、偶発故
障には有効ですが、仕組み自体に問題がある場合は、多重化しても故障を回避できません。
★それに加え、これまでもシステムの多重化をしても切り替え自体に失敗している事故は多い。
(6) SSDには、全体が一度に読みだせなくなり障害モードが存在する。SSDの容量が大規模化して
おり、障害範囲が広がることがある。
★自治体クラウドのSSD障害は、全体が一度に読みだせなくなる障害であった。
(7) バックアップ運用で一番大切なのは回復(リストア)処理である。回復処理の検証が不十分で
あったり、環境が変わったりすることで、バックアップデータの取得に失敗したり、回復処理に失
敗することがある。
★自治体クラウドでは、バックアップデータからの回復が出来なかった。
(8) ISO,JIS認証を取っていることは、データ喪失事故をおこさない保証にはならない。
★過去に障害を起こしたサービスの殆どがISO/JIS認証を取っている。
自治体クラウドの事故を扱った多くの記事では、SSDのファームウェア不良が多く取り上げられましたが、このような不良は想定内であり、それを問題点とするのではなく、その後、データ喪失に至った原因に注目すべきでした。また、AWSのサーバーオーバーヒートでは、過熱が続くとHDD(磁気ディスク装置)のデータ障害が増える可能性がありました。
5.データ保全の必要性のあるデータ・情報を識別する
データ喪失を防止するには、その対象を明確にすることが一番重要です。それを識別するのは、ユーザー部門の責任です。
情報として残すと決めたものの中から、特段に、データ保全の必要なものを抽出します。データの再作成や再取得の容易な中間生成データや補足データでなどは喪失やむなしと判断されることはやむをえません。また処理からの時間経過も考慮する必要があります。処理直後であれば、再作成や再取得可能なデータでも時間の経過とともに難易度が増す場合があるので注意しましょう。
今回の自治体クラウドにおけるデータ喪失事故の場合は、多くが再作成や再取得が容易、もしくは可能なものでした。そのお蔭で重大な事件化は免れています。これは、果たしてユーザー部門が意図的に計画したものであったのでしょうか。知る由もないですが、もし、戸籍データや納税データ、マイナンバーデータに使われていたらと思うと背筋が凍りつきます。
6.データ喪失を防ぐために
クラウドを利用したサービスを提供する場合に、費用に制約もあると思いますが、まず、データ喪失を防ぐ手段を準備し、その後で必要可用性を高める進め方をして頂きたいとも思います。決して、可用性を優先すべきではありません。
では、データ喪失を防ぐためには、どの程度のことが最低限必要でしょうか。上記2でも紹介しましたように、データ喪失が起きる様々なポテンシャルがあります。そのため、データ喪失を防ぐためには、バックアップを確実に行い、リストアの検証を行うことが必須です。
ここで、バックアップデータをどこに置くかも重要なポイントになります。HDD、SSDに置きますとリカバリーにかかる時間は短縮できます。一方、バックアップデータ自体を想定外の障害で喪失する可能性が高まります。しかしながら、磁気テープ、光ディスクのようにデータ登録の後は、データが安定的に保持される電子媒体に置きますと、バックアップデータ自体の喪失からは免れます。ですので、現時点のクラウドの成熟度でしたら、データ保全すべきデータのバックアップデータは、磁気テープまたは光ディスクにおくことが必要です。容量が多い場合は、過去分については、アーカイブし、バックアップ対象から外すと運用が楽になります。
まとめ
ユーザー部門にとっては、クラウドは、ブラックボックス化が進んでいます。そんな中、クラウド障害からデータを護る・データの喪失を防ぐために、ユーザー部門では、次のような理解、取組みを検討頂きたく存じます。
(1) クラウド利用時の「責任共有モデル」を理解する。
(2) データ喪失につながるITの潜在リスクを理解する。
(3) データ保全を必要とするデータ・情報を識別する。データの再作成や再取得が容易なも
のは、データ保全の優先順位が下がります。
(4) データ喪失が許されないデータについては、費用に制約がある場合でも、データ保全性の
確保を最優先すべきである。
(5)バックアップ先のデバイスとしては、バックアップデータ自体の喪失リスクのある磁気ディ
スク、SSDだけではなく、喪失リスクの少ない磁気テープ、光ディスクを利用することが望まし
い。
最後になりますが、ユーザー部門の方がデータ喪失の懸念をもっていても言い出せないこともあります。各社のCIOには、そのような状況にないか丁寧に確認し、重大事故から自社を守っていくことを期待します。