今回は、この中から組織向け10大脅威のうち6位に挙げられている「予期せぬIT基盤の障害に伴う業務停止」について取り上げる。5位までの項目は、標的型攻撃やランサムウェアなどここ数年の上位ランクの常連だが、2020年版の6位は昨年16位からのトップ10入りだ。その背景も含めて解説していきたい。

情報セキュリティといえばサイバー攻撃やウイルス被害などを想像しがちだが、自然災害や事故、トラブルなども、個人や企業が対峙しなければならない脅威だ。サイバーセキュリティは、単なるシステムの問題から、企業経営や社会生活にもかかわる問題に変わってきている。

システム障害等による業務停止は、サイバー攻撃で起きる場合もあるが、多くの企業において、システムの停止は業務・営業の停止、縮退を意味し、経営を直撃する。発生した場合のインパクトが小さくない。セキュリティ対策は、経営戦略や業務プロセスの一部として組み込むべきものとして、その立ち位置も変わってきている。

10大脅威の結果：昨年大きな問題になった項目がランクイン

まず、「情報セキュリティ10大脅威 2020」の結果は以下のとおりだ。

個人では「スマホ決済の不正利用」がこれまでにない項目でありながら1位にランクしている。企業向けでは、5位までは昨年と同様な項目の入れ替えだが、「予期せぬIT基盤の障害に伴う業務停止」が10位以下から6位に入ってきた。この2つに共通するのは、2019年にどちらも大きな社会問題を引き起こした点だ。

詳細は省くが、スマホ決済については、2019年にPayPay、7Pay、dポイントなどの不正利用が相次いで発生した。IT基盤の障害では、2019年8月に発生したAWS東京リージョンにおける大規模障害があった。業務システムやサービスサイトにAWS基盤を利用していた多くの企業が、システムダウン、サービス停止などの影響を受けた。

IT基盤の障害は自然災害・BCPの視点で考える

「10大脅威」が指摘する「IT基盤の障害」は、なにもAWSのトラブルだけを述べているわけではない。クラウドだろうがオンプレミスだろうが、ITシステムの故障、トラブル、バグなどに起因するシステムダウン全体を指す。その発生原因として、自然災害、データセンターなどの設備障害、ハードウェア・ソフトウェア障害の3つを挙げている。これらの障害は、オフィス内のサーバーラックやサーバールームで稼働しているシステムでも、クラウドで稼働しているシステムでも、どちらでも発生しうるものだ。

ただし、一般的にAWS、Azureといったパブリッククラウドサービスのデータセンターの信頼性は非常に高いと言われている。稼働率では99.99％以上だ。

では、なぜ2020年にこの脅威が取り沙汰されたのか。ひとつは1年前のAWSのトラブルの影響が広範囲にわたったため、クラウドのリスクを改めて喚起する理由が考えられる。しかし、そのリスクはサイバー攻撃や内部犯行などとは質が違う。クラウドは、システム全体の信頼性、セキュリティ、柔軟性を高めてくれ、クラウドシフトが当たり前になっているが、クラウドの障害は、利用している企業側では予測・制御ができないという特徴がある。

つまり、現代において、IT基盤の障害は、地震や洪水のような自然災害と同じレベルでリスク管理をしなければならないということを意味する。滅多に起きないが、起きたときの備えは必須であり、対策を考えていない経営者は無能のそしりは免れないだろう。

文書に記載された事例によれば、データセンターの電源障害、プライベートクラウドサービスのシステム障害、台風による停電による通信障害などが指摘されている。AWSの障害は、東京リージョンのあるデータセンターの空調システムの障害が原因だった。

もちろん、オンプレミスやデータセンターのハウジングやホスティングサービス、ASPなどを利用していても、同様な障害は発生しうるので注意が必要だ。

ただし、オンプレミスシステムやIaaS（イアース）系サービスで構築するシステムは、機器の運用やメンテナンスは自社や契約ベンダーが行う（iDCのファシリティは除く）ので、障害原因が、自社に起因する場合も少なくない。

2つの対策アプローチでIT基盤リスクをコントロールする

対策アプローチは、2つある。ひとつは、システム設計や構築という側面からのもの。もうひとつはBCM（事業継続性管理・BCPのマネジメント）やDR（災害復旧）の視点での対策や備えだ。

システム構築でのアプローチは、バックアップや冗長構成といった対策が有効だ。メンテナンスや運用でも、事故やトラブルを回避する手順や仕組みを導入する。インシデント対応を想定した、ソフトウェアのインストール、アンインストール手順、バックアップ、スナップショットからのリストア手順を考慮したシステム設計が重要だ。 これを確実にするには、設計や構築時にモジュールの構造化、カプセル化を高め、疎結合のシステムを目指すことも重要だ。

BCMでは、災害時のプロセスに、ネットワークやクラウド基盤の障害によるダウンも組み込む。別系統のバックアップシステム、保管場所の地理的分散などは基本だが、IaaS、PaaSとしてクラウド基盤を利用する場合、仮想サーバー、仮想内部ネットワーク、仮想ストレージを、要件に応じて二重化、冗長化したFT構成が必要だ。パブリッククラウド（AWSやAzureなど）の場合、地理的な分散が指定しにくい場合があるが、可能な範囲で、物理データセンターを指定してシステムを構築する。

SLA（サービスレベルアグリーメント）を確認し、どこまでをSLAで吸収するのか、システム構築側で吸収するのかも戦略を立てておくことを推奨する。

いずれにせよ、重要なのは、データのバックアップと、サーバーイメージのバックアップだ。これがしっかり管理され無事であれば、システム復旧の大部分は、ダッシュボードや管理コンソール上で行える可能性が高い。

構築や運用のコスト（予算・時間）とセキュリティ強度、システムの信頼性を考えたら、いまやクラウド基盤以外に業務システムを構築する合理的な理由はなくなりつつある。災害などで予期せぬクラウドのダウンがあったとしても、企業はそれをうまく管理していく能力が求められている。