blog

クラウド移行戦略:ポータビリティ、セキュリティ、総合リスク

この記事では、『Cloud Computing: Concepts, Technologies, and Architectures(クラウド・コンピューティング:コンセプト、テクノロジー、アーキテク...

Jul 15, 2025 · 7 min. read
シェア

クラウド・コンピューティングの紹介の中で、"クラウド・コンピューティングを導入する組織にとって、クラウド・コンピューティングについて無知であることほど危険なことはない "と書かれていますね。クラウド・コンピューティングに関する教育の必要性について詳しく教えてください。クラウド移行戦略を堅実に策定するために、組織は何を知る必要があるのでしょうか?

Thomas Erl:クラウド・コンピューティング・テクノロジーが議論され、広く知られるようになるにつれ、IT業界ではクラウド・コンピューティングの導入が加速しています。クラウド・コンピューティングをIT組織の一部として、あるいはIT組織の延長としてどの程度導入する必要があるのか、また、どの程度のリスクと課題が適切なのかを判断するためには、これらのリスクと課題を明確に理解する必要があります。

クラウドコンピューティング環境に無理やりソリューションを導入して、クラウドコンピューティングの潜在的なメリットをすべて享受することは現実的ではありません。クラウドコンピューティング環境は他の環境とは大きく異なるため、単にクラウド移行を実施することは危険です。

多くのクラウド・コンピューティング・プロバイダーについて語るとき、そのビジネス・クオリティが大きく異なることは明らかです。プロバイダーの中には、合意したサービスレベル契約を守るために懸命に努力するところもあります。一方、信頼性が低かったり、一貫性のない行動をとったりするプロバイダーもいます。彼らはまだヨーロッパのある地域にいるかもしれませんが、半年後には別の地域に移っているかもしれません。また、大企業に買収される可能性もあります。

クラウド移行戦略を策定するには、ベンダーから提供される資料にとどまらず、より包括的な情報を理解する必要があります。例えば、クラウドコンピューティング環境のアーキテクチャを理解し、潜在的なリスクと、そのリスクに組織をさらすことで発生する可能性のある損害を理解する必要があります。これにより、特定のクラウドを適切に評価する能力を向上させることができます。また、クラウドコンピューティングのITリソースを使用できる範囲を決定するだけでなく、組織が必要とするクラウドコンピューティング環境の種類を決定するための独自の基準を設定することができます。

これは重要なことです。なぜなら、従来のITモデルは白紙のようなもので、組織は必要なアーキテクチャーやスペース展開を自由に設計することができます。しかし、パブリック・クラウド・コンピューティング環境は白紙であるだけでなく、実装を第三者に依存しなければならない環境でもあります。この場合、設計の不備や誤った決定が、死角にさらなる問題や課題を生み出す可能性があります。

したがって、機会と危機は隣り合わせなのです。機会を捉え、その可能性を最大化する最善の方法は、リスクを理解し、その原因を分析することです。受け入れることができるリスクについては、それを軽減するために最善を尽くします。セキュリティ上のリスクとは何か、モビリティに関わるリスクとは何か、法律や契約上の問題に関わるリスクとは何か、これらをよく把握することができれば、リスクの予防やリスクへの対処を計画することができます。そこで、クラウド・コンピューティング関連の教育が必要となるのです。

ポータビリティについて話せますか?おそらく、この問題の簡単な紹介から始めて、クラウド移行戦略の一環として組織がこの問題について知っておくべきことについて話すことができるでしょう。

Erl:この質問には2つの側面があります。1つ目はモビリティです。パブリッククラウド環境は、独占的な利益を得ているサードパーティ・ベンダー企業によって管理・運用されているため、ベンダーが特定の環境を独占している従来のITモデルと同様に、モビリティの実現が困難になっています。標準化のレベルが低いことも相まって、ベンダーは、消費者市場がまだそれを求めていないため、それに従わざるを得ないと感じています。そのため、ベンダーは独自の環境を所有することができます。

データやソリューション、その他の種類のIT資産をクラウドに移行する場合、一般的には単一のベンダーとは異なる、真に異なる環境に移行することになります。クラウド・コンピューティングが意図したとおりに機能し、クラウド・コンピューティングがベンダーが提供するすべてのITリソースに接続し、その完全な活用を実現するためには、システムおよび追加される技術アーキテクチャのレイヤーを、環境とは大きく異なる方法で慎重に設計する必要があります。そのため、クラウド・コンピューティング・プロバイダーの基礎となるアーキテクチャとインフラストラクチャー層を十分に理解することが必要です。

その意味するところは、レガシーシステムをクラウドに移行するのであれば、クラウドでも従来のオンプレミス展開と同じように動作し、現在期待されている方法で正確に動作することを確認するために、今すぐ統合テストに資本を投下しなければならないということです。理解しなければならないその他の情報には、予算、影響、スケジュール、結果などがあります。クラウド・コンピューティング・プロバイダーとクラウド・コンピューティング・サービスのプロビジョニング契約を結ぶ前に、これらすべてを把握することが重要です。

投資決定から6カ月、12カ月、あるいは18カ月後に、クラウド・プロバイダーが提供する環境を使いたくないと判断したらどうするのか、ということです。その理由は、プロバイダーのサービスに満足できなかったり、より適切なクラウドプロバイダーを見つけたのでそちらのサービスを利用したり、あるいはシステムをオンプレミス環境に戻したいと考えたりするためです。この場合、どのような影響がありますか?このクラウド環境に向ける労力はどの程度ですか?ベンダーの変更や他の選択をすることの影響は?

これは必ず完了させなければならない分析調査です。クラウド・コンピューティング・プロバイダーとの契約交渉が継続される際に、他の環境に移行したいという希望があれば、それは受け入れるべき損失であり、負担すべき責任であることが明確になるように、文書化され、その数値がリソースおよびコストラインに入力されなければなりません。

時には、企業組織がちょっとした啓示を受けることもあります。例えば、「元のパートナーであるクラウド・プロバイダーのサービスを使わないだけで、50万ドルのコストがかかる」と突然気づくのです。それは受け入れがたいリスクです。クラウド・コンピューティング・プロバイダーを変更する余裕がないという理由だけで、事業の根幹をクラウド・コンピューティング・プロバイダーの手に委ねるようなものです」。これは、クラウド・コンピューティング・サービスをまったく利用しない理由の1つになるかもしれません。

2つ目の分野は統合です。統合テストの部分はもう少し単純です。一般的な理解では、統合テストは組織化して実行する必要がある作業です。一般的にもっと曖昧に理解されているのは、そのクラウドプロバイダーのサービスを使わなくなった場合の影響を分析し、評価するために必要な計画的思考です。特定のクラウドプロバイダーに大きなコミットメントをする前に、どのような組織でもこのことを明確に認識しておく必要があります。

クラウド・コンピューティングの議論では、必ずセキュリティの話題が出てきます。クラウド移行戦略を策定する際に、組織が考慮すべきセキュリティ問題について教えてください。また、クラウド・コンピューティングに関するご著書で言及されている「重複する信頼境界」の問題についてもお聞かせください。

Erl:クラウド・コンピューティングの世界では、セキュリティは、これまで述べてきたITにおける最も一般的な懸念事項です。従来のIT環境では、通常、セキュリティ・アーキテクチャに特定の焦点を当て、責任を持ち、攻撃や脅威に対応するセキュリティ専門家がいます。従来のIT環境では、セキュリティは分離することで容易に対処できるため、このモデルはほとんどの従来のアプリケーションでうまく機能します。

クラウド・コンピューティング環境、特にパブリック・クラウド・コンピューティング環境では、プロジェクト・チーム・メンバー全員が、クラウド・コンピューティング以外の環境での一般的なセキュリティ技術やリスクよりも幅広い理解を持つ必要があります。これは、データがサードパーティのクラウド・プロバイダーの管理外の環境に置かれるためです。ある程度の制御は可能かもしれませんが、完全ではありません。

アプリケーションの開発方法、アプリケーションの使用方法、品質保証、テスト、さらにはプロジェクト管理など、さまざまな意思決定にはセキュリ ティ上の意味があります。もはや完全に管理された環境ではないため、外部からの攻撃に対する脆弱性が存在する可能性があり、これは関係者全員に影響します。クラウドコンピューティング環境における特定の意思決定やデータやアプリケーションの使用方法に影響を与える可能性のあるセキュリティ問題について、十分な理解が必要です。

アクセス制御が制限されている環境に適したソリューションが提供されます。使用される可能性が高い仮想化ITリソースは共有され、物理的なITリソースによってホストされ、多くの異なるクラウド契約者が場所と時間を問わずアクセスできるため、多くの潜在的な問題が発生します。各クラウド・サブスクライバは仮想化されたITリソースに対して独自の信頼境界を持っていますが、これらのITリソースの大部分は同じ物理サーバ上に存在するため、これらの信頼境界は物理アーキテクチャの観点から本質的に重複しています。

物理サーバーが攻撃されたり、危険にさらされたりすると、それらのITリソースやITリソースに関連する他のリソースすべてに影響が及びます。ソリューションの効果がなくなるということだけではありません。データへのアクセス、データの悪用、悪意のある攻撃の試みなどです。攻撃者は、仮想化されたITリソースへの正当なアクセスを獲得し、独自の信頼境界を持つクラウドユーザーの一人である可能性があります。

専用サーバーであっても、セキュリティを確保することはできません。このサーバーが仕事用で、他のクラウドユーザーがアクセスできないことを望む』といっても、クラウドコンピューティング環境におけるより大きなエコシステムの一部であることに変わりはありません。

その結果、クラウド・プロバイダーがセキュリティ管理、セキュリティを確保するための対策、アプリケーションやデータを格納するセキュリティ・デバイスを管理することに対して、一定の信頼が必要になります。同様に、クラウドへの移行が完了した数カ月後に、環境が脆弱であること、攻撃を受けたこと、データが盗まれたり紛失したりしたことに気づくかもしれません。そうなると、『この状況を延々と続けるわけにはいかない、別のプロバイダーを探すべきだ』と言われるかもしれません。『別のプロバイダーにお金を払う余裕があるのか』ということも含めて、ポータビリティの問題に戻ってくるわけです。このようなジレンマに陥りたくないでしょう。

Read next