クラウドのコアコンセプトと偽物のクラウド
SalesforceのCRM、GoogleのGMailとGoogle Map、AWSのS3とEC2といった当時広まりつつある何か新しい潮流について、エリック・シュミット氏が「クラウドコンピューティング」と呼んだのが2006年、NISTと呼ばれる米国立標準技術研究所が「The NIST Definition of Cloud Computing（NISTによるクラウドコンピューティングの定義）」を公開したのは2011年でした。
Web2.0と同様に裾野が広がり続け全体像をつかみにくかった新しいナニカに、おおむねみんながスタンダードとみなす呼び名とコアコンセプトの定義といった「共通言語」が与えられたことは、それ以降の議論や活用をずいぶんとスムーズに、活発にしたのではないかと思います。ところでクラウドとは何であるかを示す「NISTによるクラウドの定義」の少し前ぐらいには、クラウドとはなにではないかを示す「偽物のクラウド」という言葉も使われていました。
「偽物のクラウドに騙されるな」
私が「偽物のクラウド」という言葉を意識したのは、ガートナー社の亦賀忠明氏のプレゼンを取り上げた「偽物のクラウドに騙されるな」という2014年の記事ででした。最近、この言葉に再び興味を持って簡単に調べていたのですが、別の記事でその具体的な内容がまとめられていました。一部、引用します。
現在のクラウド市場には、本物のクラウドと偽クラウドが混在している。(略)すし屋に例えて考えると分かりやすい
本物のクラウドは事前にメニューが示される標準サービスのみで、自動化によって低コストを実現している。すし屋でいえば梅の回転ずしに当たり、「Amazon Web Services」（AWS）がこの典型例だ。それに対しメニューはなく、顧客の注文を受けて構築を行う銀座の高級すし店型クラウドは、「クラウドではなくアウトソーシング」だと指摘する。
この偽物のクラウド、あるいはゴーストクラウドという言葉、遡ると2010年にはSalesforce社のマーク・ベニオフ氏が同社の年次イベント「Cloudforce 2010」の基調講演で使っているのが見つかりました。
偽物のクラウド、ゴーストクラウドがある。それは、効率が悪く、ソフトウェアの民主化を行わず、経済性が低い。
別の記事によれば、この時ベニオフ氏が偽物のクラウドと呼んだのは（当時の）Oracleだったようですが、そのOracle社は、現在、間違いなく本物のクラウドと呼べるだろうOracle Cloud Infrastructureを提供し、ガートナー社が2021年のCloud Infrastructure & Platform Servicesマジッククアドラントで取り上げたわずか7社のうちの1社になっています。私が見つけた最新の「偽物のクラウド」という言葉の使用例は、Oracle社のリサ・シュワルツ氏に2022年6月の文章でした。
偽のクラウド・ベンダーにはない、真のクラウド・プロバイダの優れた点(略)あなた自身が作業可能です。クラウド・アプリケーションを即時に管理、構成、カスタマイズ、およびメンテナンスできます。アプリケーションに変更を加えるたびに、高額なコンサルタントを雇う必要はありません。
こうして見ていくと、言えることが二つあります。一つは2010年から現在（2022年）までの長くにわたって、「偽物のクラウド」問題があると認識され続けていること。もう一つは「本物のクラウド」はソフトウェアを民主化し、注文を受けて構築するのではなく、利用者自身で作業可能であり、そうでないものが偽物だとみなされていることです。
クラウド移行の価値の80％は俊敏性と生産性
2010年から12年間にわたり本物のクラウドと偽物のクラウドの違いとされているものは、NISTの定義で言えばクラウドコンピューティングの5つの基本特性に挙げられている「オンデマンド・セルフサービス」と、おそらく「迅速なスケーラビリティ」でしょう。オンデマンド・セルフサービスには、まさに次のような説明があります。
ユーザは、各サービスの提供者と直接やりとりすることなく、必要に応じ、自動的に、サーバーの稼働時間やネットワークストレージのようなコンピューティング能力を一方的に設定できる。
顧客の注文を受けてから構築（設定）を行う、利用者自身で作業できないクラウドは、NISTによるクラウドコンピューティングの定義にも沿わなそうです。でもそれは、なぜ「偽物のクラウド」と呼ばれるほど、重要なのでしょうか。先週のAWS Innovate Modern Appication Editionのオープニングセッションでのスライドの一枚には、次のように大書されていました。
“クラウド移行により得られる価値の90％以上をインフラコストの削減以外が価値が占める”
そのソースとなっているIDCによる2018年のホワイトペーパー「Fostering Business and Organizational Transformation to Generate Business Value with Amazon Web Services」によれば、内訳は次のようになっています。
ビジネスの生産性向上効果：47%
ITスタッフの生産性向上効果：32%
リスク軽減：13％（ダウンタイム削減による従業員生産性向上を含む）
ITインフラコスト削減：8％
IDCによれば、ITインフラチームとサポートチームは、日々のサポート業務からビジネス重視のプロジェクトに重点を移せます。開発チームは、合理化された統一IT環境とITリソースの容易なプロビジョニングの恩恵を受け、より俊敏な開発が可能になり、より短い時間で多くの機能を提供できるようになります。組織は、こうした俊敏性とパフォーマンスの向上を活用して、より多くのビジネスを生み出し従業員を活性化します。こうしたビジネスの生産性向上とITスタッフの生産性向上が、クラウド移行の価値の80％弱を占めます。
ITインフラとサポートチームを日々のサポートから解放するのも、開発者に容易なプロビジョニングの恩恵をもたらすのも、オンデマンド・セルフサービスと、それを支える迅速なスケーラビリティでしょう。だから、この二つを欠くクラウドサービスは、クラウド移行の価値を得にくいという意味で「偽物」と言われているのでしょう。定義に沿ってないから、ではなく。
運用による「偽物のクラウド」の再生産
クラウドの価値において「俊敏性」が、基本特性において「オンデマンド・セルフサービス」が重要だとしたら、実はもう少し気を付けることがあります。ベースがAWSなどの「本物のクラウド」だとしても、それが利用者の手に届くまでの間に、偽物のクラウドに変わってしまうことがある、ということです。例えば、AWSをAWSと直接契約するのではなく、リセラーの「請求代行サービス」で調達している場合、次のような機能制限がありがちです。
rootユーザー（AWSアカウントの管理ユーザー）は使用不可。この場合、rootユーザー認証を必要なタスクは、セルフサービスでは行えません。一般には、フルアクセスとみなされる管理者ジョブ（AdministratorAccess）機能権限が付与されたIAMユーザーが提供され、これで利用します。なお、この点はほとんどのリセラーで共通だと思います。
Organization（AWSアカウントの統合管理）は利用不可。Organizationsの機能によって可能になる、セルフサービスでのメンバー（子）アカウントの新規作成やSCPによる管理はできませんし、Organizationsを前提とするサービスは使えないことが多いです。多くのリセラーがこのようになっていますが、Classmethod、Cloudpack、ServerworksのAWS請求代行サービス アドバンスドなど、追加のOrganizationオプションを提供しているものもあります。
IAM（権限管理）は利用不可。ときには、管理者ジョブ機能ではなく開発者パワーユーザージョブ（PowerUserAccess）機能権限が付与されるケースがありますが、大きな違いはIAMの権限がほとんど与えられていないことです(※)。例えばAWSではEC2、RDS、コンテナなど様々なリソースに適切な権限を持つロールを作成して付与しますが、これがセルフサービスではなく顧客の注文によりベンダーが行うことになります。
AWSやリセラーと開発者の間に、IT管理部門やインフラ管理チームが入るようであれば、ここでも機能制限が加えられることがあります。「IAM（権限管理）は利用不可」の制約は、こちらで加わることの方が多いかもしれません。いずれにせよ、セルフサービスでできないことには「人によるやりとり」「人による判断」「人による作業」ステップが必要になり、その分だけ俊敏性は損なわれます。それがクラウドの価値をすりつぶすレベルになったなら、それはあなたにとって「偽物のクラウド」環境になります。
Gartnerが2021年に発表したMagic Quadrantと2015年のものと比べると、非常に掲載対象が絞られています。すでに多くの人にとって「偽物のクラウドでは」と思うようなベンダーは淘汰されているかもしれません。でも本物のクラウドであっても開発者の手に届くまでに「運用上の制限」が加わり、偽物のクラウド化する可能性は考えられます。経路上に「『効果』はビジネスインパクトで量る」という慣習をもたない組織があれば、セキュリティやガバナンスを自分たちの至上のミッションだと考えて、偽物のクラウドの再生産に陥るリスクがありそうです。
偽物のクラウドが見落としがちなもの
偽物のクラウド化を避けるための考え方も、クラウドコンピューティングのコア・コンセプトに含まれていて、ここに立ち戻ることが有効でしょう。
（IaaSでは）通常、利用者は、各仮想マシン上のゲストオペレーティングシステムと、その上のすべてのソフトウェア層の操作に対する完全なコントロールを維持する。この構造は、ソフトウェアスタックに対するかなりのコントロールを利用者に与える一方で、これら従来からのコンピュータリソースをセキュリティと信頼性が確保されるように運用、アップデートおよび設定する責任は、最終的に利用者が負うことになる。
簡単に言えば、利用者の利用範囲においては、セキュリティやガバナンスも利用者が責任を負います。権限が利用者に委譲されるときには、責任も利用者に移動するということです。AWSやAzureは「責任共有モデル」を提示していますが、これも同じ考え方を示しています。クラウドサービスの多様化によりIaaS、PaaS、SaaSというカテゴリわけが難しくなった現在、AWSはこれを次のように表現しています。
AWSはクラウドのセキュリティ（Security “of” the Cloud）に責任を持つ
利用者はクラウド内のセキュリティ（Security “in” the Cloud）に責任を持つ
偽物のクラウド化の背景にありがちなものの一つは、利用者にセキュリティを委ねるのが怖い、または利用者がセキュリティ事故を起こしても提供者が責められる（時には責任を取らされる）に違いない、といった心配です。しかし、ここでリスクテイクするかしないかということは、本来の意味でクラウドコンピューティングに踏み出すか否かということと同じなのだと思います。
きっとクラウド利用者は、自分たちの権限がどこまであればクラウド移行の価値に満足できるか、その見極めをあらかじめすると良いのでしょう。自分たちの基準において「偽物」のクラウドを使い始めてしまうと、使った分だけ引き返すためのコストが大きくなるのでできるだけはやめ、できたら使い始める前に。クラウド提供者は、利用者に責任を委ねる勇気と、時に利用者を突き放す勇気について検討をあらかじめすると良いのでしょう。
おわりに
ここまでをまとめると、クラウド移行の価値の80％近くにクラウドコンピューティングの生む俊敏性が関わっていると言われます。そうだとすれば、この俊敏性を生むオンデマンド・セルフサービスはとても大事な特性で、これを欠くものはしばしば「偽物のクラウド」と揶揄されてきました。提供者は利用者にセキュリティ責任を委ね、利用者はセキュリティ責任を引き受けるというリスクテイクの難しさは、偽物のクラウドが生まれる一因でしょう。
過去最大級の個人情報漏洩事件といえる2019年のキャピタルワン事件では、クラウド提供者であるAWSは「キャピタルワン社が説明している通り、加害者はキャピタルワンのファイアウォールの設定ミスを攻撃した」と断言し、利用者であるキャピタルワンのCEOは「脆弱性はクラウドに固有のものではなく、オンプレミスのデータセンターでも発生しえた」もので「今後もクラウド戦略に全面的にコミットする」と発言しています。また顧客による集団訴訟にはキャピタルワンが和解金を支払うことで合意しています。
AWSは責任を委ねる勇気と時に利用者を突き放す勇気を見せており、キャピタルワンは責任を引き受ける勇気と引き受けた責任を果たす姿勢を示しています。両社はクラウドの権限と責任をどこまでだれが持つべきか、自分たちが考える本物のクラウドとはなにかを、提供者と利用者の双方の立場から示しているように思えます。
（注釈）
※管理者ジョブ機能を付与するリセラーでも、請求代行のためにセルフサービス性を損なわない程度のわずかなIAM権限制限は行われることがあります。例えばこの点に関するServerworksのFAQが参考になるでしょう。
参考
本文中からリンクした記事のほかに、キャピタルワン事件については特にMIT Sloan（マサチューセッツ工科大学スローン経営大学院）のA Case Study of the Capital One Data Breachを参考にしました。2020年5月に出された論文で、どのようなセキュリティ侵害だったかだけでなく、同社が取り組んでいたと思われるNIST Cyber Security Frameworkに照らし合わせてどのようなコントロールができていなかったか、同社内にどのような組織的問題があったかなど、広範な知見と教訓がまとめられています。