データセンター／クラウドサービスの選び方2021（Part 3）

クラウド移行の本格化

　「クラウドファースト」という言葉が盛んに語られたのは2013～14年頃だったようだ。企業ITシステムでオンプレミスではなくクラウドを第一に検討する、という意味で、クラウド移行が本格化していくことの象徴のように使われた言葉ではあるが、今になって振り返ってみれば、やはり当時のクラウドファーストはかけ声倒れという感があった。当時も既にクラウドは魅力的な選択肢となってはいたが、既存システムの移行を行なう場合の負担の大きさや、新しい環境について学び、習熟するコストを考えると「簡単には移行できない」と考えるユーザーは少なくなかったし、実際にその時点での判断としてオンプレミス環境を継続するという判断も普通にあり得た。

　一方、現在急速に進行しつつあるクラウド移行は切実さの度合いがかなり異なっている。Zoomに代表されるような新しいツールやサービスは基本的にSaaS型で提供されるようになっており、さらにそれを利用して業務を遂行する従業員は基本的に在宅勤務、という状況では、オンプレミス環境を従来通りに活用することはむしろ困難、ということにもなりかねない。たとえば、業務用端末一つとっても要件がガラリと変わってしまったりする。緊急対応として従業員の個人所有のPCを業務端末して使うことを認める、という対応を行なった企業も少なからずあったようだが、あらかじめBYOD（Bring Your Own Device）対応を行なっていた場合はともかく、緊急対応ということであればある程度のセキュリティリスクを甘受せざるを得なかった、という経験談も聞こえてきた。

　より大きなレベルの話としては、ネットワークトポロジーの見直しが進んだことも大きな変化の一つとして挙げられるだろう。従来の境界型セキュリティの限界は以前から指摘されていたが、これまでは「マルウェアなどの侵入を境界型セキュリティで完全に防御することは不可能」という指摘であり、対応策としてはEDRなどのような境界を突破して侵入してくる脅威があることを前提として、それを補う対応策を講じるべき、というものだった。言い換えれば、境界型セキュリティの基本的なアーキテクチャはそのままにしつつ、境界には穴もありうると考えた対策も行なう、という形だ。

　しかしながら、昨年急遽実施された在宅勤務では、多くの企業で「従業員と業務端末が境界の外側に移動してしまった」形になった。境界型セキュリティの大前提である、「守るべきリソースが境界の内側にある」状態が維持できなくなってしまったため、この状態では境界型セキュリティは不十分どころか全く機能していないと考えざるを得ない。もちろん、オンプレミスの社内システム／業務アプリケーションやデータなど、重要なIT資産が相変わらず境界の内側に存在していることは間違いないので、境界型セキュリティが完全に無効になったわけではない。しかしながら、従業員／業務端末というシステムの中では防御が手薄な要素が外に出てしまったインパクトは大きく、何らかの対応を講じる必要があるのは明らかだ。こうした状況から急遽脚光を浴びる形となったのがCASB（Cloud Access Secuirty Broker）やSASE（Secure Access Service Edge）といったクラウドセキュリティのコンセプトや、ゼロトラストネットワークアクセスなどの新しいセキュリティモデルである。日本においても、SCSKがSASEプラットフォーム「Catoクラウド」の販売を開始するなど、さまざまなCASB/SASE製品が販売されている。

　日本では大企業を中心に、セキュリティのためにはインターネットは極力使わないようにすべき、という考え方でシステムが設計されてきていた。専用線接続を活用し、ハイパースケーラーが提供するクラウドサービスに関しても専用線接続できるサービスを活用し、業務関連のトラフィックがインターネットを流れることがないようにすることに拘ってきたのだ。とはいえ、在宅勤務環境で社員全員のトラフィックを閉域網に閉じ込めるのは簡単ではない。準備が間に合った企業では、VPN接続で社員をいったん社内ネットワークに収容し、オフィスにいるときと同じ状況にしてから外部のリソースにアクセスする形にすることで「基本的に閉域網内で業務が完結する形」を作ることができたが、VPN接続回線の増強が間に合わないなどの理由でこうした対応ができなかった企業も少なくない。

　対策としては、クラウド上で提供されるVPN接続サービスを利用することや、クラウドセキュリティ主体に移行し、CASBやSASEを活用しつつ業務トラフィックがインターネットに出て行くこともある程度許容していく、という方針に転換することなどが考えられる。長い目で見れば、従来の「オンプレミスを中心に、クラウドも活用する」、という形から、「クラウドをベースに、どうしてもオンプレミスに置きたいリソースだけを厳選してオンプレミスに残す」という形に発想を逆転させる必要があるだろう。長らく言葉としては言われつつけてきた「クラウドファースト」が本来の意味で普及するのはようやくこれから、と考えて良さそうだ。

図1：SCSKが販売するSASEプラットフォーム「Catoクラウド」。WANの最適化機能とネットワークとセキュリティ機能を統合したクラウド型プラットフォームとして提供する（出典：SCSK）

コンテナを巡る動向

　コロナ禍によってDXが加速し、企業と消費者の接点はもちろん、企業内の従業員の業務遂行に関しても高品質なアプリケーションを用意できるかどうかが企業の競争力を直接左右する状況になってきた。新たなアプリケーションの開発を迅速に進める上では、最新のアプリケーションの開発トレンドであるアジャイル開発やコンテナの活用などが重要になる。こうした新しい開発手法に関しては懐疑論や慎重論も出てきがちであり、組織の規模が大きくなるほど採り入れるのに時間が掛かる傾向があるが、開発者はおおむね新しいトレンドには敏感な傾向があるし、最新のトレンドに関しては関連情報やノウハウも急速に蓄積される。ITベンダー各社が続々とKubernetes関連ビジネスに参入していることもあり、もはやアプリケーション開発においてコンテナの動向を無視するという選択は考えにくいという状況になっている。

　ITベンダー各社の取り組みの多くは、Kubernetesのサポート、特にKubernetes環境をマネージドサービス／PaaSとして提供する取り組みが目立つが、IBMでは2019年に買収したRed HatによるKubernetesプラットフォーム製品であるOpenShiftをベースに、従来オンプレミス向けに提供していたミドルウェアやアプリケーションをコンテナ化し始めている。また、同社のクラウドサービスで利用可能な機能をオンプレミス環境やプライベートクラウド向けに提供する取り組みも「OpenShiftが稼働する環境」をターゲットに開始している。先行する取り組みといえるAWS OutpostsやMicrosoft Azure Stackなどでは、基本的に「ソフトウェアスタックをプリインストールしたハードウェア（ラック）」という形で提供される形になるのに対し、IBMではコンテナで提供することから、それこそ他社のクラウド環境やハイパースケーラーのインフラを活用できる。コンテナ化によってソフトウェアの可搬性がどれほど向上するか、IBMが率先して実証して見せたような形だ。

　こうしたアプリケーション開発のトレンドの変遷は、当然ながらインフラの構成にも影響を及ぼしていくことになる。実のところ、これまでの仮想サーバー中心のITインフラは、かつて物理サーバー上に構成していたソフトウェアスタックを仮想化したものの、サーバーという単位で見た場合には従来の考え方がほぼそのまま保存されていたとも言える。サーバーという単位でワークロードを分割し、サイロ化された環境で稼働させるという考え方だ。もちろん、仮想化によってハードウェアと切り離されたことにより、仮想サーバーに対して割り当てるリソース量を柔軟に調整できるようになるなどの進化はあったが、アプリケーションの開発に関しては従来の考え方のままでもなんとかなっていた。

　一方、コンテナ／マイクロサービスが一般化してくると、仮想サーバー単位でITリソースを考える必要は必ずしもなくなり、リソースプール上にコンテナを必要なだけ配置して実行する、という考え方が自然にできるようになってくる。この場合の物理的なインフラとしては、HCIが選択しやすくなってくるかもしれない。HCIに関しては、もともとVDIのための物理インフラとしてまず活用されたという経緯から、コロナ禍対応の一環としてVDIの導入を検討するユーザー企業からの注目が高まっている面がある。もっとも、VDI自体は導入に数ヶ月～半年程度を要する大規模プロジェクトになるのが一般的であるため、現時点でVDI採用のために急速にHCIが伸びている、とまでは言えないが、今後コンテナ・アプリケーションが主流になると考えた場合には、逆に従来型の三階層システムに拘る理由もなくなっていくように思われる。

災害対策の現実解

　直近のニュースとして、フランスでデータセンターの大規模火災が発生したことが報じられている。詳細な情報は分からないのだが、報道を見る限り、4棟のうちの1棟が全焼、もう1棟にも大きな被害が生じた模様だ。残る2棟には火災の被害は及ばなかったようだが、サービスは停止したとのことだ。一般的には、データセンターのファシリティは現実的には最も安全な場所であり、よほどのことがない限りデータセンターに収容したIT機器が全滅するような状況にはならないものと期待されるが、こうした事態も起こる可能性はゼロではない、ということが再確認された形だろう。

　データセンターファシリティが全焼するような状況を想定すると、ユーザーとして取り得る対策は遠隔サイトへのバックアップくらいだろう。ここで考えておくべきポイントは、バックアップに必要な時間とリストアに必要な時間は同じではないということだ。現在のバックアップシステムは高度に洗練されており、様々な工夫を凝らしてバックアップデータを最小化する努力を積み重ねている。そもそも変更差分しかバックアップしないし、その差分データにさらに重複排除処理やデータ圧縮を重ね、現実的には「これ以上小さくはならない」という限界に近いところまでデータ量を減らしている。

　一方で、システムのリストアに必要な完全なデータセットのサイズは巨大化している。システムの規模が大きくなっていることや、データ量がどんどん増え続けていることが理由だ。リストアの際には基本的にはシステムが完全に使えない状態になってしまっていることを想定するので、バックアップとは異なり「差分データ」という考え方は基本的には通用しない。フルバックアップデータを使う必要があるのだが、このサイズが数百GB～数TBになることは珍しくなくなっている。この場合、このサイズのデータをネットワークを介して転送するために必要な時間もコストもかなり膨れあがることになる。緊急時と言うことでコストには目をつぶるとしても、遠隔サイトからバックアップデータをコピーするだけで数時間を要する、という状況が起こりうることから、RPOはゼロに近いところまで短縮できる一方、RTOは数時間～1日程度を見込まざるを得ないというアンバランスな状況になっているのが一般的だ。

　こうした状況を踏まえて現在普及しつつある対策としては、遠隔に保存したバックアップデータをコピーして戻すのはあきらめ、バックアップサイトでシステムの運用を再開する、という手法がある。バックアップベンダーの中には、バックアップデータを格納したストレージを仮想サーバーのネットワークストレージとして直接マウントしてしまい、バックアップデータからシステムを直接立ち上げる、といった手法をサポートする例が目立つようになってきている。この場合、ネットワーク経由で大量のデータ転送が発生することにはなるものの、システムの起動に必要なデータが優先しして転送される一方、すぐにはアクセスされないデータに関しては後回しにされることから、まず全データを転送してからリストア作業を始めるのに比べると、システムの再稼働／サービス再開までの時間を短縮できる。

　さらに、バックアップサイト側でシステムを立ち上げてしまい、ネットワークアクセスを本番サイトからバックアップサイトに切り替えてしまうことも考えられる。この場合は、本番サイトが再開できる状態になったら少しずつワークロードを戻していくことになる。サービスが再開しても、バックアップデータを書き換えてしまうわけにはいかないので、バックアップデータから直接システムを立ち上げる際にはデータの書き換え／書き込み処理は元のバックアップデータに直接反映するのではなく、別の場所に保存しておくなどの対応が必要になるため、こうした機能を利用できるバックアップシステムを導入していることが大前提にはなるが、今後広く普及していくことが見込まれる。

ゼロトラストへの転換

　コロナ禍においては、セキュリティ分野も大きな影響を受けた。コロナ禍では全世界規模で大規模な社会混乱が起こった形であり、フィッシングやBEC（Business Email Compromise：ビジネスメール詐欺）などの手法を活用するサイバー犯罪者にとっては「騙しやすくなるチャンス」でもあるためだ。2020年のセキュリティ状況についてはセキュリティベンダー各社が続々とレポートを発表しているが、共通して指摘されるのは、攻撃対象が製造業などに拡大している点と、ランサムウェアが高度化／悪質化している点、さらにはサプライチェーン攻撃と呼ばれる手法が大きな被害を出している点などだ。

　コロナ禍によってDX／デジタル化が進捗したが、これによってこれまで以上に広範なシステムがネットワーク接続されるようになり、攻撃者が標的とすることが可能になった。また、ランサムウェアに関しては、データを暗号化してアクセス不能にするだけだと、バックアップがあれば身代金を支払うことなくシステムの復旧が可能になることから、暗号化する前の段階でまず機密データを盗み出しておき、これをインターネット上の情報漏洩サイトで公開すると脅迫する二段構えの攻撃が増えてきている。昨年末に国内の著名ゲーム会社が被害に遭ったことが報じられたのも、この手法によるデータ漏洩だった。

　最後に、サプライチェーン攻撃に関しては、かつては防御の堅い親会社に侵入するために比較的手薄な子会社や取引先にまず侵入し、そこを踏み台にする、という攻撃をイメージしていたが、昨今話題になっているサプライチェーン攻撃は、企業が広く利用しているソフトウェア製品などの脆弱性を突く攻撃だ。広い意味での取引先／納入業者に相当すると考えればこうした表現も納得できるが、実質的にはソフトウェアの脆弱性を悪用される攻撃ということである。

　攻撃手法が高度化し、被害が大規模化する傾向がある中で、企業側では従来の境界型セキュリティの限界を認識し、ゼロトラストの導入に取り組み始めている。現時点では単一の製品を導入すればゼロトラストが実現できる、と言ったものではないため、導入は簡単ではないし、機能的も現時点で期待される全ての要素が完備されているわけではないこともあって、最初から完全を目指すのではなく、長期的な視点で段階的に取り組んでいく必要があるだろう。まず大前提となるのはユーザーのアイデンティティ管理だ。クラウドの活用が拡大していることを考え合わせると、この分野でもクラウドを活用することを検討する価値があるだろう。この分野ではグローバルで支持を拡げているOktaが日本でも本格的に事業展開を開始しているほか、日本IBMもIDaaSとしてマネージドサービス型で国内データセンターで提供開始することを発表するなど、急速に環境が整いつつある。

　全般的には、クラウドの活用範囲をさらに拡大しつつ、オンプレミスに残さなくてはならないリソースをより精緻に見極めていく必要があるだろう。その意味でも、日本国内においてもDXの進展が一気に加速することになることはほぼ間違いなさそうだ。

図2：日本IBMはIDaas「IBM Security Verify」を2021年4月から東京リージョンで提供開始する（出典：日本IBM）