クラウドイノベーションでインターネットを保護する

Clarke Rodgers (00:10):
インターネットが登場する以前、セキュリティ上の懸念がよりシンプルで明確だった時代があったというのは信じがたいことです。過去 40 年間で世界は大きく変わり、今ではオンライン接続が私たちの生活やビジネスの中心となっています。それに伴って、より大きな機会が得られますが、同時により大きなリスクも生じます。

私は AWS の Director of Enterprise Strategy である Clarke Rodgers です。Executive Insights で、AWS セキュリティリーダーとの一連の対話のガイドを務めています。

本日は、AWS Deputy CISO、Vice President、Distinguished Engineer である Paul Vixie にお話を伺います。Paul は、インターネットの進化の初期から数多くの影響を及ぼしてきた人物であり、AWS Security に独自の視点をもたらしています。今回は、インターネットをより安全なコミュニケーションの場にするためのセキュリティリーダーの役割についてお届けします。お楽しみください。

Clarke Rodgers (00:57):
Paul、今日はこのような場にお越しいただき、ありがとうございます。あなたはかなり長い間、インターネットの分野に携わっていますね。それがどのように始まり、どのようにして今日の状況に至ったのかについて、特にセキュリティの観点からお話を伺えますか?

Paul Vixie (01:11):
セキュリティは後から生まれた概念です。信じられないかもしれませんが、セキュリティの話はかなり後からのことになります。これは米国政府のネットワークとして始まりました。少なくとも初期には、軍によって使用されることはありませんでした。プロトコルはキネティック攻撃などに対する強力な保護を提供するように設計されているという神話がありますが、それは真実ではありません。それは常にベストエフォート型のシステムでした。適切に機能すれば、多くの人が恩恵を受けることができますし、機能しなければ、より強化されたネットワークでは発生しないような致命的な障害が発生する可能性がありました。

Clarke Rodgers (01:48):
どの時点で「セキュリティが考慮されていない」ことに気づきましたか? そして、どのように対応する必要があると思いましたか?

Paul Vixie (01:56):
私はかなり早い段階から警鐘を鳴らし始めました。最初に懸念したのはスパムでした。純粋な政府のネットワークでは、望ましくないトラフィックを送信することで利益を受ける人はいなかったため、認証も必要なく、人々が望ましくないトラフィックを送信することを防止する機能もありませんでした。

そのため、私は 1992 年から警鐘を鳴らし始めました。そして、独立してコンサルティングなどを行った後、最初のスパム対策プロジェクトも立ち上げました。これが最初のスパム対策企業となりました。そして、私たちの分散型レピュテーションシステムは、この種のものとしては初めてのものでした。そのシステムについて特許を取得しておけばよかったのですが。私がスパムと戦うために立ち上げた会社は訴えられて消滅しましたが、そのシステムは今でも広く使用されています。会社はなくなりましたが、アイデアとテクノロジーはすべて生き続けているのです。このことは、私が正しかったということを示しています。

Clarke Rodgers (02:57):
大手のクラウドサービスプロバイダーだけでなく、お客様の企業でもセキュリティがより真剣に受け止められているのを目の当たりにして、どのようなことを好ましく受け止めていますか?そのことは希望をもたらしてくれますか?

Paul Vixie (03:13):
私には希望がありますが、私たちが取り組んでいることは小規模すぎますし、遅すぎて、失望も感じています。しかし、市場全体が目覚めて問題に気づくまで待つ必要があります。一企業や一個人として警鐘を鳴らすだけでは足りないのです。

私に希望をくれる 1 つのことは、Amazon で働き始めてから知ったテクノロジーの数々です。規模が大きい場合には、一般化できる問題や、デプロイできるソリューションがいくつかありますが、小規模な事業を営んでいる中小企業にはそれは難しいことがわかりました。例えば、他の VM よりも AWS の VM をセキュアにするために Graviton プロセッサで行ったことは、私たち以外は誰もやっていません。

Nitro チップセットと Nitro Hypervisor に関しても、私たちだけです。例えば、Log4j の脆弱性が見つかったとき、影響は当社にも及びましたが、数 10 時間内にすべてのお客様にパッチを提供できました。なぜなら、当社はそうするための方法を認識し、それをグローバルかつ迅速にデプロイするのに十分な規模を備えているからです。その一方で、全員がそれぞれの業務に対する責任を負うような、あまり一元化されていないシステムを考えてみてください。お察しのとおり、サプライチェーンが対処するまで待たなければなりません。

「なので、私が希望を感じているのは単純に、このインターネットというものが重要なインフラとなり、グローバルなデジタル神経システムのようなものとなり、世界経済の源となったことで、人々がそれをより真剣に受け止め始めたからです」

そして、トランジスタが 1 個あたり 1 USD で購入できた初期の頃に、私たちがわずかな資金で行っていたことの多くは、徐々に廃れつつあります。そして、当社が OSI プロトコルよりも迅速に市場参入するのに役立った面倒な課題に独自に対処するという選択肢を除くと、当社が提供するようなクラウドを利用することしか、この問題を解決する方法はありません。

Clarke Rodgers (05:09):
今後数年間を見据える中で、当社のような企業だけでなく、当社のお客様がセキュリティやコンプライアンスワークロードを改善する際に役立つと思われる、特に注目している特定のテクノロジーや方法論はありますか?

Paul Vixie (05:31):
社内で間違いなく心強いことの 1 つは、コンテナの動向です。10,000 個のコンテナすべてを 1 つのチップ上で動作させ、負荷のスパイクが発生した場合には 1 秒あたり数千個を起動することができる一方で、誰かに依頼してソフトウェアエンジニアリングの方法を完全に変更してもらう必要がないという事実は、心強いことです。なぜなら、そのモデルに置き換えれば、パッチ適用など、現在抱えている問題から逃れることができるからです。

パッチ適用を必要としない日はありません。しかし、パッチ適用を専門とするチームがいない限り、週に 1 回、月に 1 回など、それは後回しになってしまいます。そして、パッチ適用を実行する際には、「なんてことだ。このパッチをシステムに適用するには、他にもアップグレードしなければならないものがある。つまり、すべてをテストラボに入れなければならない」ということに気づくかもしれません。 そのため、パッチ適用が本当に必要であることが判明してから、最終的にシステムにそのパッチが適用されるまでに数か月かかる可能性があります。

►  ポッドキャストを聴く: Vulnerability Management in a Zero Day Security Scenario

そのようなことを続けていては、すべてが適切に機能する『スタートレック』のような輝かしい未来にたどり着くことはできないでしょう。Lambda、Kubernetes、Firecracker のいずれであっても、コンテナのようなものを使用することで、ビルドパイプライン、いわゆる CI/CD を構築して、イメージを作成し、テストを実行する機会を得られます。そして、それに合格すれば、それをサービスに落とし込めばよいのです。

内部に入り込んでパッチを自己適用できるような十分なオンボーディングツールとロジックを備えた VM を用意する必要はありません。それが私たちが今日行っていることです。それはスケールしないでしょう。既にいくつかの弱点が見られます。私はそのような環境で生きてきたので今でもその方法を用いていますが、他の人には推奨しません。なぜなら、その方法を採用する理由がないからです。「これから何かを構築して、その後はそれに触れないようにする」ことについて合意を形成できれば、多くのメリットが得られるのです。

したがって、人間を関与させないようにするという考えは、もう 1 つの心強い考えです。考えたのは人間で、構築したのも人間ですから、このようなことを言うのは気が引けますが、時間の経過に伴って弱体化しない安全性を実現したいのであれば、人間が関わる要素を今すぐ減らす必要があります。

人間と、お客様に提供される価値との間に存在するソフトウェアとハードウェアの量は、かつてないほど増えています。それにもかかわらず、私たちの理解はあまり進んでいません。つまり、その量が増えるにつれて、理解できる部分が少なくなっているのです。それではうまくいきません。複雑さによって望ましくない結果が生じないようにする方法を考え出す必要があります。そして繰り返しになりますが、それはより強力な規律を設けることと、人間を関与させないことにかかっています。

「考えたのは人間で、構築したのも人間ですから、こう言うのも悲しい気がしますが、時間の経過とともに弱体化しない安全性を実現したいのであれば、人間が関わる要素を今すぐ減らす必要があります」

Clarke Rodgers (08:18):
ヒューマンアクセスとネットワークに関する考え方を踏まえつつ、ゼロトラストの考え方は長年にわたって進化してきました。ゼロトラストについて、AWS の観点から、社内でどのように考え、実装すべきかなどの点について、また、お客様の観点からゼロトラストをどのように考えるべきかについて、お考えをお聞かせいただけますか?

Paul Vixie (08:39):
ゼロトラストに不可欠な主要要素は正しく理解されていません。例えば、ゼロトラストについて話している人が、「すべてをオンラインに置き、すべてを到達可能にして、サービスとサーバー自体を保護するのです。境界を設定せずに、ネットワークを保護しましょう」と言っているのを耳にしたことがあります。 それはゼロトラストの要点ではありませんし、機能するものでもありません。ファイアウォールは必要です。ゼロトラストが意味するのは、ファイアウォールの内側に入ったときに、境界内にいるからといって、特別に信頼されているわけではない、ということなのです。

つまり、到達可能であることが信頼されていることを意味するという仮定は成り立たなくなるのです。以前は「外側はカリカリ」「内側は柔らかくてトロトロ」というように言われていました。 外側がカリカリであっても、内側が柔らかくてトロトロのネットワークは望ましくありません。したがって、ID、認証、許可を大規模かつ自動で処理するシステムが必要です。例えば、ここで私たちが話をしている間、Amazon クラウドでは 1 秒あたりに数十億件の認証イベントが発生しています。

また、最近の結果をキャッシュして、「1 秒前に許可を持っていたのであれば、おそらくまだ許可を持っているでしょう」というような、安っぽいトリックは一切用いていません。そんなことはしていないのです。私たちは毎回チェックしています。ある時点で私たちは覚悟を決め、「これに満たないのであれば、ジョブゼロとしてのセキュリティを適切に実現できません」と言いました。

しかし、繰り返しになりますが、ほとんどのシステムは大規模に機能するきめ細かいアクセスコントロールを備えていないため、内側に入れば望むことは何でもできるという考えで設計されています。私たちはそれを変えようとしています。また、さまざまな認証基準が存在しています。当社のサービスは最初期に世に出たもので、非常に大規模なものですが、決して業界標準になることを意図したものではありませんでした。他のクラウドも同様のサービスの提供に取り組んでおり、生まれ出ようとしている業界標準もいくつかあります。

サービスチームと話し合ったわけではありませんが、私の知る限り、当社はそのような運用を希望するお客様が、確実にそれを実現できるようにサポートするでしょう。

Clarke Rodgers (10:49):
ここ 1 年ほどは生成 AI がニュースにぎわせており、ほぼ毎日ニュースフィードにあがってきているように思われます。セキュリティの専門家の観点から、そのことについてどうお考えですか? セキュリティの専門家は、保護や調査などに生成 AI をどのように利用すると思いますか?

Paul Vixie (11:10):
騒ぎ立てるのをやめ、「生成 AI の現実的な応用に目が向けられるようになるとどうなるだろう」と考える必要があります。 場合によっては、私たちにもわかりません。生成 AI はかなり新しいテクノロジーであり、このテクノロジーのために多くのハードウェアやソフトウェアが生み出されています。そして、そのツールがどのような影響をもたらすのかは、そのツールの作成者以外のユーザーが使用するまで、実際にはわかりません。おそらくレンチメーカーは、レンチがハンマーとして使用されることを想定していなかったでしょうが、状況によってはうまく機能する可能性があります。

生成 AI について騒ぎ立てるフェーズが終わり、ニュースの見出しが別の話題に取って代わられるようになった後に、このテクノロジーが真に何を可能にしてくれるのかは未だ明確になってはいません。そうは言っても、私たち Amazon は、少なくとも過去 12 年間にわたって、AI ベースのソリューションの研究、開発、デプロイを行ってきました。したがって、これは私たちにとって完全な驚きではありませんでした。

私たちには既に、CodeWhisperer システムという生成 AI 手法を使用した例がありますが、見出しになっているようなものとはまったく違うシステムです。私には、あらゆる種類のシステムで同じことが起こっているように見えます。例えば、異常検出を実行する際には、システムからのテレメトリフローを調べ、何か問題が発生している可能性を示すイベント、または誰かが攻撃していることを示している可能性のあるイベントを調べます。このテクノロジーのおかげで、それらをより適切に相互に相関させることが可能になるでしょう。繰り返しになりますが、私たちが見ているのは、このテクノロジーによって可能になることのわずか 1% 程度だと感じます。

►  動画を視聴する: The State of Generative AI

私は大げさに騒ぐのを好まず、最初から真剣に取り組めばいいのにと思う一方で、ここには本当のメリットがいくつかあることも理解しています。私は、「これが一般的に利用可能になり、一般的に理解されてるようになった今、お客様により良いサービスを提供するにはどうすればよいのか」という質問に対する答えを出そうとしている AWS Security 内のいくつかのチームと協力しています。

Clarke Rodgers (13:14):
そして、テクノロジーの観点から、生成 AI ツールを使用して、多くの単調な作業をこなさなければならない人間のセキュリティ担当者をサポートする方法も考えていますよね。

Paul Vixie (13:25):
はい。製品を宣伝するつもりはないのですが、Amazon のクラウドでの最大の成功は常に、お客様による導入と構築を可能にするワークフローであり続けてきました。そのため、大規模言語モデル分野で私たちが最初に行ったことの 1 つは Bedrock でした。そのアイデアは、大規模言語モデルを使用する場合、トレーニングコストも支払ってもよいと考えるだろうか、 モデルを構築しなければならないことを許容できるだろうか、という疑問に端を発していました。

なぜなら、これを実行するには、何千時間、あるいは何万時間という非常に高コストの計算時間がかかる可能性があるからです。そして、さまざまな事前構築済みモデルをメニューから必要に応じて選択できる一方で、それを自分のシステムにコピーするのにコストがかからないのであれば、VPC にロジックを配置することだけでなく、これらのサブスクリプションモデルにアクセスできることを認識している API に直接アクセスできる当社のクラウド環境でどのようなことでも実行できるのです。

そして、当時は認識しておらず、ここで働き始めて知ったのですが、当初の前提、すなわち、クラウドの前提は、伸縮自在な量のコンピューティングとストレージを備えており、本当に必要なだけ使用できて、アクセスペナルティがないということでした。このことが、当社の成長を支えたのです。そして今、私たちはそれを生成 AI の内部でも実現できるようにしました。これにより、市場のそれぞれの分野で非常に野心的なユーザーが、LLM なしで当社のクラウドでいつも実行していたことを、当社のクラウドと LLM を使用して実行できるようになります。これはすばらしいことです。この機能の真の力は、お客様がこの機能を使用して何を実現したのかによって決まるからです。

Clarke Rodgers (15:13):
そして、お客様からは長年使用してきたすべてのセキュリティツールや他の側面から信頼をお寄せいただいており、その信頼は Bedrock や今後登場する可能性のある他のツールにも同じようにお寄せいただけるでしょう。

Paul、今日は貴重なお話をお聞かせいただき、ありがとうございました。

Paul Vixie (15:26):
すばらしい時間でした。このような機会をいただき、感謝します。