クラウドアーキテクチャの概要

クラウドアーキテクチャは、クラウド内にあるコンポーネントおよびサブコンポーネントから構成されます。これが一般的な説明ですが、クラウドアーキテクチャに含まれるのはテクノロジだけではありません。NIST SP 500-292では、クラウドコンシューマ、プロバイダ、オーディタなどのエンティティに重点を置いています。これらのエンティティなしでこのテクノロジを利用することはできません。 

クラウドアーキテクチャは、役割、活動、コンポーネント、およびサブコンポーネントの4つのレベルに分類することができます。クラウドアーキテクチャについて議論する場合には、誰が、何を、どのように、どのツールを使って行うかを明示できる必要があります。

アーキテクチャが優れたフレームワーク

アーキテクチャが優れたフレームワークを構築するには、多大な労力が必要です。このプロセスでは多くのことを検討しなければなりません。最初に、以下のような多くの質問に答える必要があります。

• お客さまにとっての、内部的および外部的なビジネスの優先事項は何ですか? 
• クラウドおよびコアビジネスの構造に影響を与える脅威の状況はどのように判断しますか?
• データ、特に機密データはどこにありますか? またそれはどこに流れていますか?
• クラウドへのシステムの展開が正しく行われることをどのように確認しますか?
• クラウドへのこの移行に関して、ソフトウェア開発者、ITスタッフ、および従業員にはどのような追加のトレーニングが必要ですか?
• すべてのシステムが正しく設定されていることを保証するためにどのようなメカニズムを使用しますか?
• セキュリティレベルを維持するためにすべてのクラウドシステムに適用するアップデートやパッチの管理に、どのツールを使用しますか?
   

このリストはまだ続きます。クラウドによりビジネスにもたらされる利益よりも損害の方が大きくならないように、アーキテクチャは正しく巧みに構築することが重要です。

役割

顧客、プロバイダ、ブローカ、キャリア、オーディタの役割については、こちらを参照してください。

クラウドアーキテクチャ内の活動により、SaaS、PaaS、およびIaaSへのアクセスと利用形態が決まります。これには、オーケストレーション、監査、およびセキュリティも含まれます。

• オーケストレーション – クラウドを使用するビジネスの目標を達成するための、クラウド環境の調整された管理。
• 監査 – クラウドプロバイダのセキュリティ、パフォーマンス、およびコンプライアンスの分析を含みます。これは外部の第三者により実行されます。
• 機密性から完全性そして可用性まで、セキュリティは常に確保する必要があります。
  • 機密性 – 機密データを秘匿すること。権限のあるユーザのみがアクセスできるようにします。
  • 完全性 – データまたはシステムが改ざんされておらず、データまたはシステムを信用できるという信頼度を提供します。
  • 可用性 – 必要なときにデータおよびシステムにアクセスでき、使用できることを保証します。
    
•  

クラウドアーキテクチャのコンポーネントは、特定の目的を達成するために選択されています。この目的を達成するためにどのようなアクション、手順、タスク、およびプロセスを実行する必要がありますか? クラウドでは、まずビジネスにとってパブリッククラウドとプライベートクラウドのどちらが、またはその組み合わせが最適なのかを決定する必要があります。ハイブリッドクラウドでは、プライベートクラウドとパブリッククラウドが結合されます。また、マルチクラウドという新たな用語は、つながっていないが、パブリックとプライベートの両方の特性を持つクラウドを指します。

コンポーネントに関してもう1つ説明しなければならないのが、相互運用性と移植性です。

• 相互運用性とは、2つの異なるシステムが特定の状況下で通信し、データを送受信する能力です。
• 移植性とは、データを手動で再作成または再入力することなく、1つのクラウドから別のクラウドへと移動する能力です。
   

ビジネスの目的の観点からこの2つを慎重に検討することは、クラウドの設計の開始時から重要です。これらの概念を最初から考慮しないと、ビジネスが不十分または不適切なアーキテクチャに閉じ込められることになりかねません。

サブコンポーネント

サブコンポーネントにより、企業はサービスレベルアグリーメント（SLA）の管理の問題や、迅速なプロビジョニングおよびリソースの変更などの課題に対処することができます。 

• SLAの管理 – 企業はプロバイダからサービスを受けていることを確認するために自社で指標を監視しますか? それとも、サービスブローカなどの 第三者が必要ですか? サービスブローカは最初の契約の交渉を支援し、サービス指標の監視やサービスの追加に関して、サービスを継続的に管理します。
• 迅速なプロビジョニング – クラウドは、従来の変更管理方法は適さない、まったく異なる環境です。クラウドインフラストラクチャへの変更を管理するために自動化ツールを実装すべきでしょうか?
• リソースの変更 – 設定の更新や、修理用に一部の機器を取り外すことが必要になります。
   

クラウドセキュリティのアーキテクチャ

クラウドセキュリティのアーキテクチャでは、セキュリティ要素がクラウドアーキテクチャに追加されます。クラウドセキュリティでは常に、クラウドプロバイダとクラウドコンシューマとの間で責任共有が発生します。責任の分担は、IaaS、PaaS、SaaSのいずれのタイプのクラウド構造が使用されているかによって異なります。 ISO、NIST、およびクラウドセキュリティアライアンス（CSA）により想定されている責任の分担はありますが、最終的にはクラウドプロバイダと利用者により決定され、契約に記載されます。

クラウドの利用者は、クラウドのいずれの形態でも、使用した場合の影響を確実に理解するために、リスク評価を行う必要があります。自社のデータセンター内で独自のクラウドを構築しているのでなければ、契約には誰にどの責任があるのか、または最低でも、クラウドプロバイダに何を期待できるのかが記載されている必要があります。

クラウドソリューションの設計または使用時に検討すべきいくつかのセキュリティコントロールを以下に示します。

• 多要素認証（MFA） – すべてのアカウントでMFAを使用することが強く推奨されます。 
• データ分類 – クラウド内に存在するデータが何であるか、またその機密度を理解することが重要です。データストレージに含まれる個人を特定できる情報などを調べるためのツールがあります。このようなツールまたは手動のプロセスを使用できますが、いずれにしてもこれを行う必要があります。
• 識別と認証 – クラウドを使用しているかクラウド内に存在するすべての主体からのアクセスを制御することが重要です。これにはユーザや管理者だけでなく、他のソフトウェアやデータにアクセスするソフトウェア、API、機能も含まれます。
• 管理者向けの専用の制御されたアカウントの作成 – ビジネス用の主要アカウントは管理者が使用するアカウントであってはなりません。そのアカウントが侵害されると、すべてが失われる可能性があります。
• ログ – 可能な限りすべてをログに記録し、疑わしいか危険な状況について管理者に警告するように指標を設定します。