「クラウド活用は万能薬ではない」――2つのクラウド移行事例で起きたセキュリティ課題とその原因：失敗、成功事例に学ぶクラウドネイティブセキュリティの勘所（2）

セキュリティに対する不安からクラウド移行に踏み切れない企業や、クラウド移行したもののクラウドセキュリティに依然として懸念がある企業に向けて、クラウドで実現するセキュリティ対策を事例とともに解説する本連載。今回は、セキュリティに関する課題が生じた2つのクラウド移行事例を解説します。

[小峰和巳，キンドリルジャパン]

　セキュリティに対する不安からクラウド移行に踏み切れない企業や、クラウド移行したもののセキュリティに依然として懸念がある企業に向けて、クラウドで実現するセキュリティ対策を事例と併せて解説する本連載。初回は、クラウドネイティブセキュリティが注目される背景や、セキュリティの取り組みの現状、現在、注目を集めているキーワードを整理しました。

　今回は、筆者が所属する組織で扱ったクラウド移行事例の中でも、セキュリティに関してトラブルが起きた2つの事例を紹介します（※なお、本記事の内容は個人の見解に基づくものであり、所属組織の総意ではないことをご了承ください）。

事例1：クラウド移行と同時に実施したソフトウェアのバージョンアップに伴い、ソフトウェアの動作が変わった

　1つ目は、オンプレミスからパブリッククラウドサービスに移行を推進したプロジェクトです。このプロジェクトは、パブリッククラウド移行後も原則としてインターネット接続を認めない閉域環境にすることがクラウド移行の要件となっており、これによりセキュリティの問題が生じました。

　オンプレミス環境で長年同じソフトウェアを利用しており、システム全体をパブリッククラウドへ移行させた結果、ソフトウェアのバージョンアップが必要となりました。エージェントのインストール方法や、ソフトウェアアップデート後の挙動も変わっており、Webサイトと通信しなければエージェントのインストールが不可能でした。

　オンプレミスのシステムなら、ソフトウェアのエージェントをインストール、アップデートする方法は幾つか考えられますが、このプロジェクトのように、パブリッククラウド上にシステムを移行し、インターネット接続を前提としない閉域環境にしていた場合、同様の問題が生まれる可能性があります。

　ソフトウェアのバージョンアップに伴う影響に関して、十分に事前調査すれば回避できることもありますが、それぞれのバージョンでソフトウェアの挙動がどう変わるかといった情報は全て網羅的に公開されているわけではなく、ソフトウェアを本格稼働させてみて初めて分かるケースも存在します。

　このケースは一時的にではありますが、インターネット接続ができるようにファイアウォールの設定を変更し、エージェントのインストールを実施しました。ソフトウェアのアップデートに関する運用をどのように進めるかは、継続検討課題となりました。

事例2：クラウドサービス側の責任分界点範囲において行われたバージョンアップが、ユーザー側に影響を及ぼした

　2つ目は、1つ目の事例と同様、オンプレミスで長年システムのアップデートが実行されておらずハードウェアの故障が相次ぎ、やむを得ず、クラウド移行を実施したプロジェクトで発生した課題です。

　こちらのプロジェクトではクラウド移行が無事に完了し、運用フェーズに入っていました。しかし、運用方針がクラウド移行後に変わっておらず、OSのパッチを当てていませんでした。そのため、OSより下位のソフトウェアのバージョンアップがクラウドサービス側で行われた際に、OSに不具合が生じ、ユーザー側に影響を及ぼしました。

2つのケースから得られる教訓

　今回紹介した2つの事例のように、クラウド移行の背景の一つとして、現行システムでのOSのバージョンが古く、サーバ機器としても保守切れになっており、オンプレミスでの環境維持が難しいというケースはあるでしょう。

　しかし、クラウドはパラダイスではありません。クラウド移行後にクラウドサービス側の責任範囲において行われる作業が、ユーザー側の責任範囲に及ぶケースもあります。

　クラウドを利用する際によく言及される「責任分界点モデル」において、「サービス提供側の責任範囲は、ユーザーが考慮しなくてよい部分」とされていますが、逆に言うと、サービス提供側の責任範囲はサービス提供側の論理や都合が通される部分といえます。ユーザーは、その影響を考慮する必要があります。

　責任分界点の下位に位置しユーザー側から見えない部分の変更作業の影響を、上位は受けることがあります。このブラックボックスを許容できるかどうかは、サービス利用側の許容力に大きくかかっているのです。

　IaaS（Infrastructure as a Service）で利用するOS、開発言語、ミドルウェア、PaaS（Platform as a Service）として提供されるサービスは、OSより下位のハイパーバイザー、ファームウェアなどクラウドサービス側の提供範囲のバージョンアップに応じてユーザー側でバージョンを上げるしかないケースが存在します。

　この場合、事前にユーザー側でバージョンアップの対応が必要であり、オンプレミスでよくある「バージョンアップせずに塩漬け」することは難しいです。そしてユーザー側でバージョンアップをせずに放っておくと障害が発生する可能性もあります。まさに2つ目の事例が、その障害に巻き込まれたケースでした。

おわりに

　仕事柄、「メインフレームで構築したシステムをクラウド移行したい」という相談を受ける機会が増えてきています。

　メインフレーム上で作成されたプログラムをクラウドに移行させる場合、クラウドサービス側の都合でOSや開発言語、ミドルウェアのバージョンアップが必要となったときに、ユーザー側でそれを受け入れられるのかどうかを考慮する必要があります。

　定期的なバージョンアップを前提としていないシステムをクラウド移行させる場合、クラウド事業者側の変更に応じて、システムの運用中に、バージョンアップの影響を調査したり、改修をしたりするというのは現実的ではありません。

　中長期的にはシステムそのものを、クラウドに適した形に作り替えるつもりで挑む必要があります。ここまで苦労してメインフレームで構築してきたシステムを本当にクラウド移行させたいのか。クラウド移行する本当のメリットは何なのか、クラウド移行を始める前によく検討する必要があります。

　クラウド活用はトレンドである一方、万能薬ではなく、われわれが選ぶことのできる情報戦略の中のオプションの一つにすぎません。

　メインフレーム、オープンサーバ、クラウドそれぞれのメリット／デメリットを考えて採用すべきものであり、自社にとって何がベターなのか、自社の事業戦略やIT戦略に沿って選んでいく必要があります。

　「クラウドファースト」が注目されてはいますが、優先されるべきは自社の経営戦略であり、戦略をサポートするのが情報システムです。システムは適材適所で選択すべきです。本記事を通じて、これまでもこれからも求められる重要なスタンスだと覚えておいていただければ幸いです。

筆者プロフィール

小峰和巳（こみね かずみ）

キンドリルジャパン Application Data ＆ AI事業部 マネージャー

Cloud Migration & Modernizationのエキスパートとして数々のパプリッククラウドへの移行案件をリード。これまでは、メインフレームを扱うプロジェクトの運用保守に参画、同じプロジェクトの中でメインフレームのリニューアルを実施、続いてメイフレームからオンプレミスサーバへのダウンサイジングプロジェクトに参画、IaaSのサービス提供側、SaaSのサービス提供側にてサービス運営や拡販、新規サービスの事業企画を経験。ITインフラ業界の進化過程を辿るようなキャリアを積む。2019年にBBT大学大学院にてMBAを取得、経営者目線で事業拡大を目指す。