AWS におけるセキュリティの水準を引き上げて、その先を目指す

Clarke (10:27):
AWS のセキュリティに関する業務を遂行するすべてのデベロッパーが自らの業務を開始する際に、必ずしも強力なセキュリティエンジニアリングのバックグラウンドをもっているとは限らないと想像します。これらのデベロッパーが AWS のセキュリティ用に設定した基準に到達するようにするため、どのようなメカニズムを導入していますか? 特にビルダーツールや、お客様向けのセキュリティ製品ではいかがでしょうか?

Eric (10:50):
その質問について考える方法はいくつかあります。まず、Amazon におけるセキュリティはビルダーの規律です。実行すべきことを、すべて実行することは不可能です。チームにエンジニアを追加するだけでは、ビジネスに合わせてスケールすることはできません。したがって、行っている業務のうち、膨大な割合を占めるのはツールの構築です。セキュリティツールを構築しているという点を除けば、Amazon の他のチームで行うのと同じように、それはソフトウェア開発に他なりません。そのため、当社のエンジニアの多くはセキュリティエンジニアではなく、セキュリティのバックグラウンドはありません。これらのエンジニアがチームに参加するために、セキュリティに関する特別な専門知識は必要ありません。セキュリティに情熱を持っているエンジニアもいれば、取り組んでいる仕事や一緒に働いているチームが好きで、業務内容に満足している人もいますが、特にセキュリティに特別な関心があるわけではありませんし、それで問題ありません。

Eric (11:37):
セキュリティの全体的な領域は、一部のビルダーが行った仮定を把握し、それらの仮定を侵害してシステムを予期しない状態にする方法を把握することです。ハードドライブ全体に相当するデータをこのフィールドに詰め込むとどうなるのか、 ダイヤルを 11 まで上げるとどうなるのか、 このフィールドに負の数を入力するとどうなるのか、というようなことを考えます。 そして、私の経験では、そのように考える人々は本質的にそのように考える傾向があり、その精神を教えることは本当に難しいことです。

Eric (12:18):
したがって、その精神を持った人を見つけると、特定のセキュリティ知識のすべてを教えることができるのです。日々のテクノロジーのすべてについて、人々を非常に簡単に強化できます。私が日々行っていることは、私が大学にいた頃には存在していなかったのです。大学で学んだ基礎は今でも適用できますが、具体的なテクノロジーはどれも適用できません。そのため、実際には、特定のセキュリティベントを持つ人々を強化するための非常に堅牢なプログラムを用意しています。

Eric (12:46):
したがって、ご質問に対する回答には 2 つの側面があります。セキュリティに関する知識を強化する必要のない人々がいます。それは標準的な開発業務であり、標準的なビルダーの役割です。これらのビルダーは、その業務に優れた能力を発揮します。そして、セキュリティに関心を示すビルダーもいます。それは素晴らしいことであり、私たちもそれを奨励しています。しかし、それは必要なことではありません。その反対側には、どうすれば物事を壊すことができるかを理解しようと注力する人々がいます。 そして「どうすれば物事を壊すことができるのか?」と尋ねることは、自然に「それらが再び壊れないようにするために、どのように修正すればよいのか?」という疑問につながります。 そして、そこでの業務特有のスキルのすべてを教えることは可能です。

Clarke (14:03):
その点について、あるいはその点の裏返しとして、多くのお客様は、独自の開発コミュニティ全体でセキュリティの専門知識を構築しようとしています。そのため、セキュリティエキスパートを確保して、「常設の開発チーム」に配置し、そのチーム内でセキュリティの水準を設けて、基本的にセキュリティの擁護者のマインドセットを身に付けるようにします。つまり、このアイデアは、セキュリティの専門家の数には限りがあるので、開発チーム全体にそのマインドセットを広げて、最終的には全体の底上げを図るというものです。このことは、AWS と Amazon で似たようなものですか? 私たちが物事をどのように見ているかといったことです。あるいは、セキュリティが私たちの精神に組み込まれているため、「私は自分のアプリケーションのセキュリティについて一定の責任を負っているため、私はプロセスに従います」ということを全社員が認識しているのでしょうか? それがどのように機能するかについて少しお話しいただけますか?

Eric (14:58):
もちろんです。セキュリティは「 0番目の仕事 (job zero) 」です。基本的に、スケーラビリティ、可用性、低レイテンシー、低ジッターと同様に、セキュリティはカスタマーエクスペリエンスの一部であると信じています。それは私たちが構築するすべてものの一部です。そうは言っても、セキュリティの専門知識を備えていることは、一般的ではありません。当社には、望んでいるほど多くのセキュリティエンジニアがいません。当社のすべてのデベロッパーがセキュリティのエキスパートでもあれば素晴らしいことでしょう。私はそのような状況が実現するのを期待していません。セキュリティの擁護者という用語を使用したのは興味深いと思います。なぜなら、これは文字どおり、サービスチームに属するセキュリティのマインドを持つ人々を見つけ、トレーニングを実施し、セキュリティスキルを高めて、サービスチーム全体に影響をもたらすことができるようにサポートする社内のプログラム名だからです。

Eric (16:38):
そして、大きな決断が下される際には、孤独な立場を取って、「ここでの唯一のセキュリティの擁護者として、これはリリースの準備ができていないか、またはこの追加の作業を行う必要があると感じています」と言う必要はありません。 これらの擁護者は、このセキュリティ組織全体に頼ることができます。私たちは Customer Obsession (顧客第一主義) の立場から協力して、お客様にとって何が正しいかを把握できるのです。安全ではないサービスを提供する場合、それはお客様にとって間違った結果となりますが、サービスを提供しない場合は...サービスが存在しないのと同様に、喜んでいただけるお客様はいません。そのため、私たちは適切なバランスを取る必要があります。また、セキュリティの専門知識をサービスチームに採り入れ、サービスチームに深く共感し、AWS セキュリティチームのセキュリティに関する専門知識が引き続きサービスチームにとって共感的なものであるようにしながら、どちらかと言えば監査担当者としての役割を果たすことで、より優れた意思決定を、はるかに迅速に行うことができます。

Clarke (17:28):
そしてそれが状況を軽減すると想像していますが..繰り返しになりますが、私が行っている多くのお客様との会話では、セキュリティ部門は「いいえ」と言う部門であるとみなされています。あるいは、アプリケーションをリリースするために避けなければならない部門であるとみなされています。先ほどお話ししたこのモデルでは、信頼の架け橋が広がっているようであり、当社の場合、「セキュリティは仕事の一部にすぎず、これが Amazon でのやり方です」と誰もが認識しているようです。そして最終的な結果として、より安全な製品が生まれるのです。
 
Eric (18:00):
しばらく前に、私たちはミッションステートメントについて考えていました。AWS セキュリティにはどのような意味があるのか、というようなことです。 そして、私たちが思いついた最高のステートメントは、「ship securely」(安全に提供する) でした。それは 2 つの単語であり、私たちが存在する理由をとても良く捉えていると思います。当社は、セキュリティを行うために存在しているのではありません。当社はアマゾン ウェブ サービスと呼ばれているのであって、アマゾン セキュリティと呼ばれているわけではありません。そして、私たちはこれらのウェブサービスをお客様に提供するためにここに存在しているのです。提供しないということは、実行していないということです。ビジネスが実現しようとしていることを、私たちは行っていないということになります。私たちはビジネスを実現するためにここにいます。私たちはビジネスにとっての理由ではありません。そして、模範的なセキュリティがなければ、このビジネスを行うことはできませんが、私たちはビジネスの 1 つの側面にすぎません。
 
Eric (18:44):
そして私たちにとって最も重要なことは、経営幹部からの支援です。明らかに、セキュリティは非常に重要であり、それはトップダウンで展開されます。つまり、「私たちはセキュリティチームなので、皆さんは私たちの言うことに耳を傾ける必要があります。次のことに留意してください...」と私たちが言う必要はありません。 私はその問題を抱えていません。CEO からトップダウンで、方向性が設定されました。セキュリティが重要であることは全従業員が認識しています。
 
Clarke (20:04):
ありがとうございます。特に AWS 内でコードを記述しているデベロッパーやその他のユーザーによるセキュリティプログラムの測定に関して、AWS の開発コミュニティ全体でセキュリティプログラムの有効性を測定するために使用する主要な指標にはどのようなものがありますか?
 
Eric (20:57):
指標を適用する場面は 2 つあります。
 
Eric (21:43):
チケットが閉じられるまでの時間を測定することは望んでいません。チケットが閉じられるのにかかる時間は、チケットが閉じられるのにかかる時間でしかないからです。しかし、私たちが測定するのは私たちの応答性です。したがって、最初のエンゲージメントには SLA を設けています。例えば、当社では、AWS セキュリティに E メールを送信すると、24 時間以内に人間の担当者からの返信が届く旨を公表しています。私たちはそれを測定します。実際、私が毎週見ているグラフやチャートには、「私たちに E メールを送信した人に応答するのにこれだけの時間がかかりました」と示されています。 応答性は本当に重要です。その理由の 1 つは、応答しなければ人々との信頼を失うからです。そして 2 つ目の理由は、応答性が高いことは、他に良いことが起こっていることを意味する傾向があるからです。
 
Eric (22:25):
同様の考え方を適用するもう 1 つの場面は、チケットが発行されてからの経過時間です。
…
すべてがチケットです。そのため、チケットが発行されてから長い時間が経過していないかどうかを確認するためにチケットシステムに大量のオートメーションが組み込まれており、サービスチームからの応答時間とセキュリティチームからの応答時間の両方を測定します。これにより、チケットが未対応の状態で残っている場合や、サービスチームによって私たちがブロックされていたり、私たちによってサービスチームがブロックされている場合を知ることができるとともに、すぐに対応が必要なチケットをすばやく特定できます。それはまた、内省的・回顧的に、どのプロセスが機能していないか、どの領域で人員を変更する必要があるか、どの領域でより優れたツールに投資する必要があるかを把握するためのデータを提供してくれます。セキュリティに関するプロセスを測定したところ、そのプロセスが適切なセキュリティの結果の実現を促進していることがわかりました。
 
Eric (23:20):
私たちが積極的に測定するもう 1 つのことは、あることを正しく行うことではありません。優れたサービスを設計するためにアプリケーションのセキュリティに多大な時間を費やしていますが、Amazon はリリースしたものをそのままにしておくことは決してしません。私たちは常に機能を追加し、お客様のフィードバックに継続的に対応しており、そのフィードバックに基づいてサービスは急速に変化しています。したがって、私たちの目標は安全にリリースすることではなく、サービスの存続期間を通じてセキュリティを維持することです。最初のアプリケーションのセキュリティレビュー中に行うことは、すぐに古くなり、その価値を失います。したがって、サービスについて常に真であってほしい不変性、ステートメントを特定し、コード内のバリアントでそれらを検証する方法を理解することは、アプリケーションセキュリティプロセスの一部となっています。
 
Eric (24:10):
サービスがこのようにフォーマットされたリクエストを常に拒否する必要がある場合は、その特別にフォーマットされたリクエストでそのサービスを本番稼働環境で呼び出し、それが確実に拒否されるようにする canary が必要です。それから、私たちは canary を測定します。サービスの領域をどの程度カバーしているか、 どの程度の頻度で実行しているか、 どの程度の頻度で失敗しているか、 どの程度の頻度で異常な結果を得ているか、といったことを測定するのです。 そして、これらのプロセスを測定して、私たちのセキュリティスタンスを検証します。これは、提供されるセキュリティを測定するのではありません。それを測定するのは困難なことです。そうではなく、それは、私たちが既に確立したセキュリティの水準におけるリグレッションを測定するものなのです。常に別のセキュリティ問題が発生するため、これは非常に重要です。私たちのチームは革新的であり、これまでセキュリティを確保する必要がなかった新しいエキサイティングなサービスを生み出し続けています。それは私を毎日仕事に駆り立てているもう 1 つの理由です。
 
Clarke (26:00):
素晴らしいです。関連する質問ですが、お客様の観点からお聞きします。非常に先進的なお客様がいらっしゃいます。CI/CD パイプラインを介して本番稼働環境に Infrastructure as Code を実行しています。一方、コンソールのみを使用して、ポイントアンドクリックのアクティビティを実行しているお客様もいらっしゃいます。私の経験から察するに、お客様の大多数が、その Infrastructure as Code「nirvana」にアクセスしようとしている途中の段階にいるのではないでしょうか。 インフラストラクチャの実行に関して、運用上のポイントアンドクリックの側面よりも、エンジニアリングに重点を置くことを強く奨励するために、お客様のリーダーシップにどのようなアドバイスをしますか?
 
Eric (26:42):
私は美しいものを構築したことがありません。私は、AWS のサービスのパブリックマーケットプレイスであろうと、私たちのお客様がサービスチームや他の Amazonian である社内のマーケットプレイスであろうと、私は極めて誇りに思うもの、マーケットプレイスで非常にうまくいったものを構築してきました。しかしこれらはすべてアイデアの核から始まり、お客様を喜ばせることができる最小であると考えたものを構築し、そして、それから可能な限り迅速にイテレーションを行うシステムなのです。これらは、時間とともに成長しました。イテレーションの実行によって、素晴らしいツールを手に入れることができるのです。周辺で働く人々は、それらをフランケンシュタインの怪物だと考えています。すべてが梱包用ワイヤーとダクトテープでできているかのようなごみです。あたかも MacGyver によって作られたもののようです。しかし、現実には、それらは素晴らしいツールなのです。それらは驚くほど効果的です。そして、それらのツールは遂行されている業務のために段階的に構築されたため、本当に必要な状況で役立つのです。
 
Eric (27:42):
誰かが参加する場合、チームに参加する人であれ、お客様と社内のやり方について話す人であれ、私たちが持っている一連のツール、私たちが構築したすべてのメカニズムを見て、圧倒されるのっです。それを再現する方法はないようです。その理由の 1 つは、再現する必要がないからです。これは、私たちの特定のセキュリティ問題を処理するためのものです。そして、2 つ目の理由は、私たちがこれらのものを構築せず、時間をかけて成長させ、すべてが小規模なものから始まったということにあります。つまり、漸進的なアプローチがその理由です。指標について話した際に、リグレッションがないこと、同じ問題を 2 回解決する必要がないことを話しました。日々改善されていきます。毎日、セキュリティの水準を段階的に引き上げ、指数関数的な成長を遂げていくのです。
 
Clarke (29:34):
これを視聴しているお客様のためにまとめると、基本的にそのアイデアは、すべてに対するアプローチを一度に変更するのではなく、エンジニアリングの取り組みから小さく始めて、時間の経過に合わせて成長するものであり、それらをより優れたものとしていくということですね?
 
Eric (29:48):
そのとおりです。その漸進的なマインドセットは常にメリットをもたらします。他方、それは悲観論者ではないセキュリティの専門家によって受け入れられる必要があります。私たちは皆、日々リスクに囲まれています。通りを横断することはリスクであり、車を運転することはリスクであり、ノートパソコンをネットワークに接続することはリスクです。したがって、適切なリスクを取ることに慣れなければなりません。セキュリティは芸術なのです。もっと科学的であるといいのですが。いずれにしても、それは、それらのリスクを管理し、どのリスクが許容可能で、どのリスクを軽減でき、どのリスクがまったく受け入れることができないのかを理解する芸術だと思います。したがって、セキュリティの専門家として、どのような役割でも、不安がある場合には、このリスクがどれほど深刻であるかについて話すことができなければなりません。
 
Eric (30:38):
セキュリティ組織では、セキュリティについて話すとき、私たちが常に使用するフレーズは臨床的で正確です。「これは、これまでで最悪のセキュリティの脆弱性であり、それを修正するために私たちにできることは何もありません」と言ってしまった瞬間に、それは途方もない信頼を失ったことを意味します。議論をすべて終わらせてしまったのです。今後の道についての交渉は終わってしまいました。それをシャットダウンしてしまったのです。それに代えて、「これは本当に心配な問題です。私はこの具体的な影響について心配しています。ここには 3 つの可能性があります。私は最初のものが好みです。それはより費用がかかりますが、このメリットを提供してくれるものでもあります。何をする必要があるかについて話しましょう」と言ったとしたらどうでしょうか。これは臨床的かつ正確であり、会話を開くものです。私の専門知識を活用して、ビジネスについて話し合いましょう。このセキュリティツールを構築しているエンジニアは、それを念頭に置く必要があります。「どうすればビジネスを改善できるのか」と考える必要があるのです。「大変だ、あらゆることがうまくいっていない、すべてひどい状態だ」と考えるべきではありません。