クラウドコンピューティングは、この10年間で最も変革をもたらしたテクノロジーの一つです。 これにより、組織は斬新なアプリケーションやサービスを提供したり、運用方法を革新することができました。 しかし、ITインフラや運用の重要な部分を組織外に移すことは、セキュリティに重大な影響を及ぼすことになります。 今回は、セキュリティコンサルタントのLaura Kankaala（ローラ・カンカーラ）とNick Jones（ニック・ジョーンズ）に、組織が今後も直面するクラウドセキュリティの課題について語っていただきました。
Janne：ようこそ。
Laura: ありがとうございます。
Nick：お招きいただき、ありがとうございます。
それではまず、お二人のクラウドセキュリティに関する経験についてお話しいただけますか？
Laura: 実は、私は以前からクラウドセキュリティに取り組んでいます。自分のキャリアを振り返ってみると、とても好都合な場所でスタートできたと思います。最初に担当したのは従来型のデータセンターモデルで、非常に古いLinuxサーバのシステム管理者のような役割でした。その仕事をする中で、このような環境で運用する良い感覚を養えたと思います。
その後すぐに、クラウドサーバのメンテナンスも行うようになり、AWSやEC2インスタンスなどで構築されたものもすべてメンテナンスしました。その頃にクラウドセキュリティに関心を持つようになったのです。2016年か2017年の頃だったと思います。
今日の世界は、当時とはかなり異なっていると思います。たとえば、クラウドセキュリティは飛躍的な進歩を遂げていますが、時には少し後退してしまうこともありました。
Laura Kankaala, Nick Jones
Nick：私の場合は、ソフトウェア開発者としての短い期間を除いて、キャリアの大半をセキュリティコンサルタントとして過ごしてきました。私がクラウドに興味を持ったのは、お客様の環境をテストしている中で、頻繁にクラウドを目にするようになってからです。そして気がつくと、調べているサーバーは、実はデータセンターにはなく、AWSやAzureでホスティングされていたのです。
私が最初に経験したのは、お客様に、「実はサーバーの一部はAzureにあります。よく知っておいてください。」と非難するように言われたのです。そして「それでは、実際にお見せしましょう。」とコンソールを見せらました。 その後、クラウドは時代の潮流に乗るように頻繁に登場するようになり、専門性が求められるほど拡大して行きました。
それから数年間、私は自分のキャリアをクラウドセキュリティに捧げ始めました。今ではエフセキュアのコンサルティングでクラウドセキュリティチームを率いています。主にAWSに焦点を当てていますが、クラウド環境における悪意のある活動をどのように特定するかという攻撃検知にも取り組んでいます。そこにはオンプレミス環境よりもさまざまな課題があることが分かりました。
なるほど。これは、見せかけの専門家が本物になるまでの、美しくも典型的なコンサルタント物語ですね。こういった話は大好きです。では、クラウドといっても、具体的にはどのようなものを指すのでしょうか？これは愚問で申し訳ありませんが、SaaS とクラウドサービスやクラウドプラットフォームを混同してしまうことが良くありますので、敢えてお聞きします。クラウドとは何でしょうか？
Nick：それらは皆クラウドです。 この言葉は非常に多くのことを表す包括的な言葉なので、私たちが普段話しているクラウドについて、もう少し掘り下げてみる価値はあると思います。
Microsoft 365やDropbox、GmailなどのSaaSは、間違いなくクラウドの傘下になります。エンドユーザーとしては、ほとんどコントロールできないことから、セキュリティの予防的な観点からは、関わり方が希薄になる傾向があります。
そのため、セキュリティを確保する場合、最初はセキュリティ侵害を防ぐために、AWSやAzureなどが提供するインフラストラクチャや PaaS に重点を置く傾向があります。これは、検知と対応を検討し始めると変わっていきます。この点については、後で詳しくお話しします。
Laura: 私やNickがクラウドについて語るときは、IaaS か PaaS について話すことが多いと思います。AWSやAzureなどのプレーヤーがこれに該当します。
しかし、かみ砕いて言えば、実際のクラウドサービス全体をどれだけコントロールできるかという点で、この2つも区別できると思います。インフラをコントロールできますか？設定を変更したり、独自の設定を作成したりできますか？それとも、ほとんど変更できない設定があらかじめ用意されていますか？
基本的にはこのようにして2つを大まかに区別することになりますが、当然ながらこの2つの間には法的な義務やその他の義務が数多くあります。
なるほど。確かNickは数年前に、クラウドが組織の攻撃検知能力に与える影響についてまとめた記事を執筆しましたね。この内容について簡単に説明していただけますか？
Nick：もちろんです。オンプレミスのWindowsネットワークやActive Directory、Linuxなどに慣れている企業にとって、クラウドに関する最大の課題は、攻撃の性質が環境や状況に応じて変化することです。
以前は、ほとんどのWindowsネットワークが類似していたことから、予め攻撃者の試みを想定した一般的な検知機能を構築していました。攻撃者はKerberoastingなどの手法を試みる可能性が高いですし、単純な手口では、Mimikatzのような一般的なセキュリティツールを実行するかもしれません。それらは検知できるので、「これは明らかにまずい。すぐ対処しなくては」ということになります。
クラウドスペースにおける真の課題は、ユーザとしても攻撃者としても、状況をコントロールする能力がはるかに低いため、できることがほとんどないということです。ここで攻撃者がよく行う行為は、正当なアクセスや機能の乱用と呼ばれるものです。
攻撃者は、エクスプロイトを実行したり、リモートアクセス型のトロイの木馬や Cobalt Strike などを展開するのではなく、アクセスキーを盗んだり、ユーザー名とパスワードを搾取して、それらの資格情報を使って何らかのレベルのアクセス権を取得するのが一般的です。そして、それを使ってクラウドプロバイダーが公開しているAPIにアクセスし、環境の把握、データの盗用、権限モデルの操作など、さまざまなことを実行しますが、それらはすべてクラウドサービスプロバイダーが提供する正規の機能を通じて行われます。
ここでの本当の課題は、これらの攻撃が、環境を構築し、長期的に管理するために管理者が取る機能や行動とまったく同じ事を実施しているという点です。 したがって、自らの組織に限らず特定のワークロードや環境において、何が正常なのかを理解し、通常の動作と、この特定のワークロードで起きてはならない動作を区別できるようにする必要があります。また、ほとんどの組織では、実行中の100、200、300件のクラウドワークロードに対して、そのような分析や機能を拡張する能力を備えていません。
それは驚きですね。私はまだLauraが話されたPaaSやIaaSにこだわっていました。ICT部門にサーバーを頼む代わりに、AWSにサーバーを要求すれば、きっとそこでセキュリティも対応してくれるでしょう。しかし、振る舞い検知のような話になると、まったく別の問題になります。
Laura: その通りです。また、ここで強調しておきたいのは、以前のクラウドセキュリティ関連のサイバーセキュリティサウナのエピソードでもまったく同じことを話しましたが、クラウドは本質的に安全なものはありません。何をデプロイし、どのようにメンテナンスするかに大きく依存します。
たとえば、AWSにはデータセンターを運用する責任があります。したがって、私たちは物理的なセキュリティについてはそれほど心配する必要はありません。しかし、クラウドに脆弱なコードをアップすると、インフラ全体が危険にさらされる可能性があります。たとえば、APIキーや管理者アクセスキーがリークされなくても、メタデータインスタンスと呼ばれるものを使って、一時的な資格情報を取得することができます。この資格情報を利用すると、基本的にAWS環境全体を乗っ取ることができます。
まさにNickが話した通りです。この種の「living off the land（環境寄生型）」攻撃手順は、クラウド環境ではさまざまなタイプのサービスが利用できるため、極めて有効です。そして、管理者アクセス権を得ることができれば、未使用の領域にアクセスしてクリプトマイナーなどを起動しない限り、正規の管理者によるアクションとして簡単に難読化することができます。いずれどこかの時点では発見できますが、Windowsのエンタープライズ環境とは少し異なります。
Nick：大変興味深いことは、クリプトマイナーに関しては、ここまで見てきた最も基本的な検知メカニズムの1つがIT部門ではなく、財務部門にあるという点です。財務からIT部門に電話で、「なぜAWSの請求額が先月の10倍なのか？」という問い合わせがあり、その返事は「なんと、クリプトマイナーにやられました。」です。私たちは、このようなケースを何件も見ています。
Laura: はい、その通りです。
では、組織がクラウドに移行する際に、セキュリティ上で必要となる最大の変更点は検知機能になりますか？
Nick：恐らく違うでしょう。検知はクラウドセキュリティの移行の過程における第2段階、または第3段階に相当すると思います。検知できることはとても良いことですが、私たちが一緒に仕事をしている組織の中で、純粋に基本的なこと以上のことをしている組織はほとんどありません。
クラウドへの移行に伴い、多くの組織が直面している真の課題は、1つのクラウド環境のセキュリティを確保することは可能だとしても、35もあるエンジニアリングチームに、小規模なセキュリティチームを適用し、それぞれが独自のプロジェクトを行うとなると、まったく別の問題になります。そのため、できるだけ迅速に移行したいというビジネスニーズに合わせて、クラウド環境で働くセキュリティ担当者を素早く育成する必要があります。
そもそもクラウドを利用する理由は、開発速度を速め、新機能を迅速にリリースし、バグ修正を早く行うことができるようにするためです。リリースの頻度は、これまでの数か月または1年に数回から、場合によっては1日数回になりました。AWSが11.7秒ごとにリリースしているのは有名な話です。このようなリリースサイクルでは、多くの人が慣れ親しんでいるようなセキュリティテストを手作業で行うだけで十分だという考え方自体が非常識ではないでしょうか？
そのため、エンジニアがやろうとしていることに合わせて、セキュリティの仕事の仕方を完全に適応させる必要があります。そのためには、デプロイメントパイプラインの一部を自動化し、基本的なセキュリティチェックを行うことや、開発プロセスの初期段階でセキュリティを構築し、初期設計セッションの一部としてデザインレビューや脅威モデリングを行うことなどが挙げられます。これをスムーズに進めるためには、さまざまなことを変えなければなりません。そして多くの組織がある程度の成功を収めています。しかし、これまで一緒に仕事をしてきたほとんどの人にとって、それは間違いなく挑戦になります。
つまり、最大の問題はクラウドのトランスフォーメーションそのものではなく、組織が同時にDevOpsのような世界に変革していくということですね?
Nick：そうです。ここで重要なことは、クラウドは多くの点でDevOpsの兆候を示しているということです。人々がクラウドに移行しているのは、それがDevOpsの実践につながるからです。また、他にもいくつかのメリットがありますが、少なくともエンジニアリングの観点からすると、ほとんどのエンジニアが手放しで喜んでいるのは、デルがサーバを出荷するまでに4週間も待つのではなく、わずか1～2分で新しいリソースをデプロイできることです。
ITインフラをクラウドに移行することについてお聞きしたいと思います。脅威アクターが悪用し、混乱を招くために何かをクラウドにアップするというような事実があるのでしょうか？
Laura: 私は、物を移動するプロセスだけでなく、純粋なクラウドだけではなく、また1社のクラウドサービスプロバイダーだけでもなく、多くの環境を観測しています。オンプレミスとクラウド、複数のクラウドなどが混在することもあります。そこでは、いろいろなことが起きています。
もちろん、私たちが行っている方法、つまりDevOpsのやり方では、たとえば自動デプロイや開発者に環境自体へのアクセスを広く提供しています。一方、開発面でも良いことがあります。他のチームに連絡してファイアウォールに開口部を作ってもらうなどの面倒なことをあまり気にせずに、自分ですべての作業を行うことができるのです。
しかし、攻撃者の視点で見ると、特定の開発者として、コンピュータ上の資格情報の侵害、フィッシング、マルウェアのいずれかを通じて環境にアクセスできるのであれば、これは間違いなく非常に興味をそそることだと思います。
それだけではなく、継続的インテグレーションや継続的開発の話になると、これまで以上に多くの外部依存関係を組織内に持ち込むことになります。つまり、コンテナのイメージであれ、コードの一部であれ、正式な用語ではないと思いますが、これらのプラグイン機能を自分のコード上に置くことで、たとえば認証や監視などあらゆる目的に使用することができます。私たちは、基本的にこれらの機能を代行してくれるプロバイダーを信頼しています。
そして長期的に見ると、この信頼感こそが私たちに大きなダメージを与えていると思います。非常に良い事例ですが、SolarWindsやOrionの監視ツールにはバックドアがあって、MicrosoftやIntel、政府機関など、機密性の高い環境や大企業へのアクセスを許していました。
Nick：そのとおりですね。ここでもう1つ興味深い事実は、これまで大規模なクラウド侵害を目にしてきましたが、純粋にクラウドへの侵入であったケースはほとんどないということです。クラウドに関連する侵害を受けた組織のほとんどは、クラウド環境への攻撃を可能にするために悪用された他の資産、またはクラウドに隣接する資産やオンプレミスネットワークを介して侵害されています。
特にLauraが述べたように、SolarWindsはまさしく好例でした。彼らは、ゴールデンSAML攻撃と呼ばれる方法で、オンプレミスシステムを利用して認証を行い、クラウドのアカウントに侵入しました。ローカルのオンプレミスで必要なアクセス権を得て、それをクラウド環境へのアクセスに変換したのです。
このような攻撃はよく見られます。他の環境から転じて、あるいはソースコード管理システムや継続的デリバリーシステムなど、クラウドに隣接する二次的な設備を侵害して、クラウド環境を改ざんすることもあります。また、純粋なクラウドの観点からすると、管理者の権限を侵害された場合の防御は明らかに困難になります。管理者は当然、管理者権限を持っているからです。攻撃者がそれを手に入れることができれば、本当にゲームオーバーになってしまいます。
検知の分野で私たちが見てきた課題の1つは、クラウドやオンプレミスのネットワーク、その他のすべてのシステムから得られるさまざまなデータソースと検知結果を、効果的に組み合わせることです。これは長期的な課題になると思います。
そうですね。さらに言えば、たとえばAWSやAzureのアカウントを見て、このアカウントを経由してアクセスする外部のものをすべて除外すれば、このアカウントは安全だということをうまく検証できると思います。
しかし、それこそが問題です。私たちは、他のソフトウェアサービスとの統合だけでなく、オンプレミスや他のクラウドサービスにまで広がる複雑なインフラストラクチャを扱っているからです。また、複数のアカウントを持っている場合、これらのプロバイダー間、あるいは特定のプロバイダー内で可視性を確保することは、少なくとも技術的な観点からは非常に難しいことです。
Janne：それはとても興味深いですね。というのも、クラウドへの移行を検討する際に大きな話題に登ったのが、「コントロールを手放すことになる」というセキュリティ上の懸念だったからです。今Nickは、クラウドに移行したことで侵害された企業は見当たらないので大丈夫だと言いましたね。企業は以前とまったく同じ方法で侵害されていますが、それがクラウドに拡大していることは事実ですか？
Nick：必ずしもすべてがそうではありません。クラウドへの侵害が何件か見られたことは間違いありません。2018年か2019年頃に起きたCapital Oneのケースが有名です。しかし、私たちが目にした侵害の大部分は、既存のシステムに対する侵害であり、それらがクラウドに広がっていったものです。
Active Directoryが典型的な例です。設立から5年以上の企業であればActive Directoryネットワークを持っています。それらは巨大で、非常に複雑で、あらゆる種類の古いものが織り込まれています。適切に保護されているものはほとんどありません。
そのため、クラウドへの認証を構築しても「砂上の楼閣」で、うまくいかないのです。これは、多くの組織で見られる問題です。
Laura: そうですね。このような話をするときには、AWSやAzureをよく引き合いに出しますが、他にも山ほどクラウドプロバイダーが存在しますので、ここで言及しておきます。この2つのビッグネームだけではありません。
たとえば、Shodanなどを通じてインターネットを検索すると、公共のインターネットに直接接続されているMongoDBやこの種の内部サービスなどが存在することが分かります。それらは必ずしもクラウドサービスからのものではなく、多くの場合、SaaSやクラウドプロバイダーからのものであることがわかります。
しかし、ここまでくるとヒューマンエラーどころの話ではありません。このようなものを誤って公開しているとは思いませんが、人々が使用しているサービスなどの設定にはアンチパターンのようなものがあります。
たとえば、AWSは非常に優れたガードレールを提供しており、すべてが、あるいはほとんどがデフォルトで拒否されています。しかし、これがすべてのプロバイダーに当てはまるわけではありません。これは再度検討すべきことだと思います。なぜなら、クラウドを探しているのであれば、どのような種類のクラウドであっても、セキュリティソリューションとして頼りになるものを探すべきで、実際に使用しているシステムやサービス、プラットフォームについて、バックグラウンドで調査を行う必要があると思います。
はい。つまり、それが重要なことですね。IaaSとPaaSについて話しましたが、それらは非常にシンプルでよく理解されている言葉ですが、実際はもっと複雑ですね。これまでに非常に多くの情報流出があったので、私が疑問に思っていたのは、S3バケットを設定して、インターネット全体に情報が漏れないようにすることが可能かどうかということでした。これに関する責任はクラウド事業者が負うべきで、デフォルトで安全性を確保すべきか、それとも「購入したからには使い方を知っておいたほうがよい」ということと、どちらが正しいのでしょうか？
Nick：これは本当に興味深い質問ですね。その理由は、プロバイダーが責任の所在を公式に表明しているからです。これは責任共有モデルとして知られています。どのようなサービスに対しても、「プロバイダーが対応すること」と「ユーザが対応すること」を示しています。
ここでの問題は、プロバイダーがユーザにその情報を自由に見られるようにしており、トレーニングコースやベーシックなクラウド教育で詳細に説明しているにもかかわらず、多くの人が「S3バケット作成する」ボタンをクリックしてしまうことです。そして、その後は何も変えないでしょう。S3バケットさえ使えれば、他に何を気にするでしょうか？
そのため、AWSが行った興味深い変更の1つは、S3バケットのデフォルトを従来のパブリックではなく、プライベートにしたことです。デフォルト切り替え前後でのS3バケットの新規作成数のグラフを見ることができます。作成されたS3の80%がパブリックだったのが、デフォルトを切り替えただけで20%になったのです。
つまり、公式にはプロバイダーの問題ではありませんが、多くの場合、プロバイダーによるデフォルトの設定方法によって、人々の問題を軽減することができるのです。これ以外にも、さらに多くのケースで適切な方法があると思います。
Laura: はい、まったくその通りです。基本的に、プロバイダーがこれらのことを提供しなければならないという決まりはありません。しかし、AWSとS3バケットのケースは、プロバイダーとして、より安全な代替手段の使用を効果的に人々に強いるだけで、インターネットを安全な場所にすることが簡単にできる事を示す、素晴らしい例だと思います。
一方で、多くの人は、サービスの内容や自動化されたツールの種類にもよりますが、自動化されたものをデプロイする場合、構成を常に確認しているわけではないということも事実です。たとえば、あるサービスから別のサービスへと移行する場合などです。
このようなことを禁止するのはプロバイダーの責任であるべきだと思います。アンチパターンという言葉を繰り返しますが、安全でないデフォルトを許可するのはアンチパターンだからです。
そうですね。その数字には驚きました。つまり、これらのバケットの60%は、そもそも公開されるべきではなかったということですね。これは相当な割合で、決して小さな数字ではないですね。
Nick：確かに、これは非常に重要なことだと思います。AWS自身と、Azure、Google Cloud、IBM、Oracleなど、すべての企業が、安全なデフォルト設定に力を入れ、これまで以上に最初から正しい設定が簡単にできるようにしています。
しかし、基本的にこれらのプラットフォームはすべて巨大で複雑であり、多くの未確定要素があります。もし、エンジニアリングチームが理解する時間をかけることができず、納期や予算のプレッシャーなどのために、企業が彼らに時間やリソースを与えない場合、最終的には行き詰まり、失敗することになります。
クラウドの優れた点の１つは、その拡張性にあります。つまり、企業はより多くのコンピューティングパワーを購入するだけですぐに事業を拡大できますが、クラウドセキュリティへのアプローチも同じように拡張可能なのでしょうか?
Laura: イエスでもありノーでもあります。理想的な状況であれば、どのようなものをデプロイしても拡張できると思います。しかし、できることには技術的な制約があります。また、組織体制にも依存します。どのような組織がこれらのシステムを構築しているか、AWSアカウント数や処理方法など、何らかの方法で統合されているのか。ここでもAWSを参照していますが、たとえば、コントロールタワーなどを設置して、複数アカウントの環境でもセキュリティや可視性を確保できるようにしていますか？
しかし、これは難しい状況でもあります。アプリケーションやシステムを開発している人々を巻き込む必要があるからです。そのため時間がかかり、技術的な問題が発生することもあります。これは組織レベルの問題でもあります。セキュリティの基準がどの程度しっかりと伝わっているかなど、コミュニケーションとその明確性に依存します。
Nick：そのとおりですね。もうひとつ注目すべき点は、クラウドのセキュリティには拡張性が高いものもあれば、そうでないものも多いということです。また、典型的な例として、設定ミスを監視することは非常に簡単です。把握しているすべてのAWSアカウントのS3バケットをスキャンしたり、すべてのストレージアカウントやAzureのサブスクリプションをスキャンしたりして、公開されているものを抽出し、書き留めておいたリストと照らし合わせて公開すべきかどうかを検証することが簡単にできます。
それを修正することも課題です。たとえば、公開すべきでないS3バケットが10個あるとします。平均的な組織では、この作業は複数のエンジニアリングチームに分散させており、それぞれが時間的制約を抱えていることでしょう。彼らのところに出向いて「このS3バケットを修正してください。」と言います。彼らは「了解しました。次の予定に入れるので数週間で完了することになります。」と答えるでしょう。望んだ答えではありませんね。
したがって、クラウドセキュリティの拡張に直面している多くの組織における最大の課題は、少なくとも基本的な構成が正しいことを確認するための自動修復機能です。誰かがパブリックに設定したS3バケットを作成したときに、誰も何もしなくても自動的にプライベート設定に変更されるようにするにはどうすればよいでしょうか？「おや、このS3バケットは公開されているから、誰か何とかしてくれないかな。」から始まります。警告には、「このS3バケットは公開されていました。今は公開されていません。変更しましたのでエンジニアリングチームに通知してください。」とメッセージが表示されます。
私たちが協力している多くの企業では、このようなシステムを独自に構築しています。しかし残念なことに、クラウドサービスプロバイダーから得られたデータのみに基づいて行われるのとは異なり、自動修復では、それを使用する組織のビジネス慣行やエンジニアとの連携方法、簡単に使用できる例外システムなど、組織文化に大きく依存するあらゆる種類の事柄を考慮する必要があります。これは、当面の間、私たちが直面する真の課題だと思います。
Laura: ええ、まったく同じ意見です。たとえば、自動修復についてですが、警告や監視などを自動的に行う際には、これらの問題を実際にエスカレーションする人が必要であるというのは、非常に伝統的な問題だと思います。そして、おそらくDevOpsチームは、この自動修復などの機能を自由に使えるようにする過程にあるのだと思います。また、組織的な観点からは、開発者が常にすべてを処理することになってしまうのは問題だと感じています。
単にアプリケーションを開発するだけでなく、自動修復を行って、環境内で発生しているあらゆるものを検出して監視することも考えられます。これらの多くは、昔ながらのコミュニケーションと、それが組織内でいかにうまく行われているかということに尽きると思います。
自動化や新しい働き方が必要なのは分かりましたが、クラウドトランスフォーメーションには新しい考え方も必要なのではないでしょうか？チームは「これ以上アクセスをコントロールすることはできません。ゼロトラストを完全に受け入れなければなりません」。と言うかもしれませんね。
Nick：ゼロトラストに言及してくれてありがたいです。これは、クラウド分野で最もよく使われている流行語の1つです。この言葉は正にバズワードであり、誰もが自分なりの定義を持っています。その核心は、お互いに話しているリソースを信用しないという考え方です。すべてのシステムは、話し相手は信頼できないもの、すべての入力は信頼できないものという前提で設計されます。
多くの組織が、オンプレミスの古くて大規模なファイアウォールやエッジでのVPNを排除する手段として、ゼロトラストを使用しようとしています。目標としては非常に価値があると思いますし、この分野では大変興味深いオープンソースプロジェクトがいくつか生まれています。最も注目すべきは、先日HashiCorpがBoundaryをリリースしたことです。このツールは、インターネットに公開すべきではない軟弱な内部システムに対するゲートキーパーとして機能するように設計されており、ゼロトラストのようなモデルに適合するように設計されています。
しかし、根本的な問題は、アイデンティティ管理が難しいことです。業界としてこの問題を是正してきませんでした。Active Directoryは、常に社内ネットワークの弱点の1つです。たとえば、AWS IAMを見てみると、AWSがアイデンティティ管理とアクセス管理に使用しているモデルですが、これは非常に複雑です。6,000種類ものアクセス許可があり、それをさまざまなものに適用する方法もいろいろあって、基本的に正しく行うのは困難です。
ですから、アイデンティティ管理とアクセス管理の問題を解決しない限り、Gartnerをはじめとする多くの企業が推進しているような、完全にゼロトラスト型のモデルに移行することは幻想にすぎないと思います。とりわけ多くの可視性が失われるからです。
Office 365などのSaaSに関する最大の課題の1つは、Microsoftが提供する基本的なシステムの堅牢化は素晴らしいものですが、これまで利用してきた多くのデータにアクセスできないため、それを検知して対応する能力が大幅に低下することです。このようなゼロトラストの非境界化の設定に移行すると、可視性や監視機能が失われていくので、それを何とか補う必要があります。そうしないと、たった1回のセッションハイジャック攻撃で、データの半分が流出してしまうからです。
Laura: そうですね。ゼロトラストを一言で言えば「誰も信用していない」ということです。境界線を完全になくすことができるということです。でも近い将来にそんなことが起こるとは思えません。このような考え方をサポートしないサービスも数多くあります。デバイスやサービスなどの相互認証を必要としているからです。これは、すべてのアプリケーションやデバイスがサポートするようなものではありません。
また、ユーザにとっては、今日AWSに対して何らかの管理業務を行う際には、徹底した厳格なポリシーとゼロトラストの考え方を実践することが良いと思います。なぜなら、あらゆる管理操作を行うことができる管理APIは、デフォルトでインターネットに公開されているからです。これは以前から変わっていないので実践すべきです。
しかし、まだすべてをインターネットで公開する時期ではありません。人々の間に多くの混乱を引き起こす可能性があります。従業員全員を信頼しているので、単にRDP（リモートデスクトッププロトコル）を社外に出せば良いと考えるかもしれません。しかし、脅威は内部からも発生するので、これは意図してやるべきではありません。
ファイアウォールについてお話ししましたが、内部ネットワークを構築していて、そこにいるすべての人をデフォルトで信頼しているとしたら、それはもう大問題になります。誰でも感染したコンピュータに侵入したりVPNなどに接続できるからです。ゼロトラストのメカニズムは、すでに実施されているセキュリティレベルを向上させる良い方法だと思いますが、決してすべてをインターネットに公開しないでください。
これは、誰もがアジャイル開発を始めたときと同じことですね。アジャイルであるということは、何もドキュメント化する必要がないということになります。
Nick：まさにそのとおりです。
私たちが目にしているトレンドの1つは、組織におけるKubernetesの利用の増加です。このことは、企業のセキュリティ態勢にどのように影響しますか？
Nick：Kubernetesは本当に興味深いものです。これは、2015年頃にGoogleから生まれたコンテナ化とオーケストレーションの技術です。それ以来、大きく進化しています。元々はBorgと呼ばれるものをベースに作られており、Googleの拡張要求に合わせてアプリケーションを拡張するように設計されています。このため、ほとんどの企業が対応していない規模で運用するために、プロジェクトから分離して設計されました。
そして、それは確かにメリットがあります。非常に大規模で複雑な環境を実行している場合は、リソースを共有したり、誰が何にアクセスできるかをコントロールするなど、多くのことが容易になります。
しかし、大規模運用を前提に設計されていることの弊害として、複雑性が増すため、小規模な環境では解決する問題の数と同じくらい新たな問題を引き起こします。本来は必要でないケースで使用していることがよくありますが、長期にわたって管理し、セキュリティを確保しなければならないことを考慮すると、デメリットがメリットを上回っているかもしれません。
Kubernetesのセキュリティに関して、いつも私がするアドバイスは、まず本当に必要なのかを確認すること、そしてクールで新しいおもちゃで遊びたいからといって、それが過度の負担にならないようにすることです。そして、セキュリティチームの中に、Kubernetesの仕組みや未確定要素の組み合わせ方、適切なセキュリティの確保方法などを時間をかけて理解している人がいることを確認してください。なぜなら、膨大な数の未確定要素があるからです。
これは、別のクラウドサービスプロバイダーを採用するのと同じくらい複雑な作業になります。つまり、AWSをすでに導入している上にAzureを追加して、一層複雑にするようなものです。それに気づき留意すべきです。
なるほど。国際的な調査によると、CISOはクラウドセキュリティに関する学習を優先していることが示されています。これは、自組織のIT資産を確実に保護するだけでなく、クラウドの機能を活用する方法を理解するためです。では、CISOはどこから学習を始めるべきでしょうか？
Nick：平均的なCISOにとっては、チームが意図したとおりに業務を遂行し、適正な成果を生み出し、ビジネスの安全性を確保することが基本的に担っている責任です。クラウドのメリットをハイレベルで理解し、社内のエンジニアリング部門との会話を通じて、世界中の同僚がどのように活動しているかを理解することが重要です。基本的には、チームが業務遂行能力を発揮できるようにする責任があります。
もし私がCISOであれば、自分のチームが効果的に活動できるようにするために、セキュリティエンジニアや検知エンジニアをクラウドベースのトレーニングコースに参加させることを優先させるでしょう。どのようなクラウドプロバイダーでも必ず認定プログラムがあります。エフセキュアの通常のアプローチでは、セキュリティ担当者が確実にクラウドを理解できるようにしています。セキュリティチームはすでにセキュリティの実践方法を理解しているので、アーキテクチャ認定、アドミニストレーション認定等の資格取得は、クラウドの技術的な知識をチームに取り込むための優れた方法です。その知識をクラウドの世界に変換するのです。
それから、DevOpsの入門書として「The Phoenix Project」を読むことをお勧めします。比較的短い小説で、DevOps方式に移行したチームの物語が描かれています。先に述べたように、クラウドとDevOpsは密接に関連しているため、DevOpsの真の意味、目標、組織がそれによって解決しようとしていることを理解することで、セキュリティチームはエンジニアの考え方の基礎をよりよく理解することができます。
そして、クラウドセキュリティの重要な点は、エンジニアリングが適正な業務を果たすためにはセキュリティが必須要素であるということです。セキュリティはゲートキーパーではありません。ブロッカーでもありません。私たちはエンジニアに寄り添って、彼らのジャーニーをサポートする必要があります。そのための最善の方法は、セキュリティ側がエンジニアリングの考え方の基礎を理解することです。
Laura: ええ、それはリソースを確保する上でも大きなポイントだと思います。そのため、人員または時間や日数など十分なリソースを確保したうえで、たとえば検知機能や自動修復機能を実現します。
クラウドにはさまざまなサービスがあるので、すべてがすぐに使えると思うかもしれませんが、多くの場合、コードやLambda関数の追加レイヤや、何らかのサーバーレスオペレーションが必要になります。これらの問題を検討するための十分なリソースと人員を組織内で確保することもCISOの役割です。
わかりました。オンプレミスの時代には、時としてシャドーITの問題が起こりました。マーケティング部門のMargaretが、どこかで新しいWebサーバを立ち上げても、セキュリティチームは全く知らないというようなことがありました。今日では、誰もがリモートワークをするようになり、部署やチームごとにさまざまなプロバイダーからサービスを調達し、誰もがさまざまなクラウドプロバイダーにサービスを提供するようになることが容易に想像できます。このような活動をすべて監視するにはどうすればよいのでしょうか？
Nick：一言で答えると、とても難しいです。簡単なことではありません。多くの組織にとって最大の課題の1つは、自らが利用しているすべてのクラウドを見つけることです。合併や買収、新しい部門の設立、マーケティング部門のサードパーティ代理店との提携などがあると、さらに複雑な状況に陥ります。Google Cloudにクレジットカードを登録するだけで、彼らが望むことができてしまいます。
これらを追跡し管理する方法について、興味深いアプローチを取っている組織もあります。最も効果的な方法の一つは、調達部門や財務部門と懇意になり、クラウドの利用に対して課金されているコーポレートクレジットカードのリストを尋ね、請求先となりそうなプロバイダーや担当者のリストを渡して報告を受けることです。すべてのエンジニアリングチームを追跡するよりも、はるかに正確な情報が得られる可能性があります。なぜなら、最終的には必ず誰かがすべての費用を支払っているからです。
それは良いヒントですね。とてもいいアドバイスですね。さて、全体的に見て、セキュリティ面でのクラウド化について、私たちは喜んでいるのでしょうか、悲しんでいるのでしょうか。これは良いことなのか悪いことなのか。別の言い方をすれば、企業はこれをセキュリティへの長期的な投資を行う機会として捉えるべきなのでしょうか。それとも、まだ何とも言えないのでしょうか？
Nick: はい、その通りです。私の考えでは、セキュリティチームにとってクラウド化の大きなメリットは、少なくとも仮想マシンの運用をやめれば、自社のネットワーク管理やサーバーへのパッチ適用などを気にする必要がなくなることです。データセンサリーのような低レベルのセキュリティ業務や運用業務は、クラウド事業者が代行してくれます。
アマゾンやマイクロソフトよりも安全なデータセンターを運営できると考える人はいないでしょう。なぜなら、彼らはそのような規模で仕事をしており、プロセスや手順をしっかりと身につけているので、その分野では誰もが彼らに対抗できないと思うからです。
つまり、セキュリティの一部を世界最高水準の組織に委託しているわけです。そうすることで、自社のビジネスやワークロードに直結したセキュリティ問題に集中することができます。
Laura: 最近では、クラウドプラットフォームを利用する人が増えています。だからこそ、クラウドのセキュリティへの投資は当然のことですし、クラウドサービス事業者の提供するツールを探して、それが役に立つかどうかを確認するのもいいでしょう。また、そうでない場合は、外部のツールが役立つこともあります。
とはいえ、他のセキュリティと同様に、この種の投資は一度限りのものではないと思います。なぜなら、すでに述べたように、あなたがそこで作っているものやあなた自身のアプリケーションには、潜在的に非常に特殊なリスクが伴うからです。そのため、カスタムツールやカスタム検出器を構築する必要があるのですが、それらも同様です。
ですから、クラウドのセキュリティは、社内で開発する可能性もあると考え、将来的にもセキュリティを向上させる方法を模索すべきです。これは、手っ取り早い投資でパッチを当てることができるものではなく、移動する目標のようなものです。
ええ、おっしゃることはよくわかります。いいアドバイスだと思います。でも、この1つのエピソードでクラウドに関するすべての問題を解決できたとは思えないので、少し残念です。でも、今日ここに集まってくれて、この一見とても複雑なテーマについて話してくれた皆さんに感謝したいと思います。
Nick: お招きいただき、ありがとうございました。
Laura: ありがとうございます。
カテゴリ