Sysdigでコンテナセキュリティモデルをマスターする

私の名前はエリック・カーターです。 私はSysdigのプロダクトマーケティングチームに所属しています。 私は、当社の主要なセキュリティアーキテクトであるAlexと一緒に参加しています。 彼を連れて行きました。 彼はスケジュールに載っていなかったけど、それは彼が難しい質問に答えることができるからだよ。 コンテナのセキュリティについて少しお話ししたいと思います。 ここにいる人のうち、ほとんどが開発者であると認識している人はどれくらいいますか? DevOpsのような人は、それが違うと考えるなら? セキュリティや運用など、他に何かありますか? さて、私たちは良い人たちを混ぜ合わせています。

今日の目標の一部は、コンテナのセキュリティ問題に関して業界で見られることについて少し話すことです。 また、コンテナを構築するときに実行できるいくつかのベストプラクティスについても説明します。 私たちは、私たちが右シールドと呼ぶのが好きなもの、つまりコンテナが稼働しているときに、あなたができることのいくつかを少し掘り下げますか?

私たちは、おそらくほとんどの人がニュースを見たり聞いたりしたことを思い出していただきたいのですが、Sysdigと Docker Scout の統合により、セキュリティ問題やCVEなど、最初に修正すべき点を考えるのに苦労している可能性のあるものの優先順位付けに追加の支援を提供しました。 私たちがランタイムインサイトと呼んでいるものは、それを助けることになるので、そのメッセージも配信します。

コンテナセキュリティモデル

コンテナのセキュリティモデルについてお話ししますので、コンテナ担当者やセキュリティ担当者がいる場合は、心配しないでください、あなたは正しい場所にいます。 素晴らしい。

ここでは、私たちが行うべきことの一部、つまりコンテナセキュリティモデルと呼んでいるものについて説明します。 うまくいけば、それはあなたにとって役に立ちます。 先ほど述べたように、シフトレフト/シールドライト、およびライフサイクル全体にわたるいくつかのベストプラクティスについて説明します。

セキュリティ上の問題はいくつか考えられますが、その 1 つはコンテナの内容に基づいています。 もしかしたら、コンテナを構築するときにはおそらく正しいことではないようなことをしたことがあるかもしれません。 また、必ずしも何をしたかではなく、周囲の環境において、おそらくそこにあるべきではないアクセスを可能にするもの、つまり人々があなたのドアを覗いたり、裏口を通ったりすることができるなど、重要なこともあります。 コンテナ、Kubernetes、クラウドなど、業界では多くのことが起こっており、コーディングから実行まで、さまざまなことに対応する必要があります。 なぜなら、私たちは以前よりもはるかに頻繁にデプロイしているからです。 ここでの数字は基本的に、 60%の企業がこれを1日に何度も、または数日ごとに行っていたと報告しており、それを4秒ごとに行っていることと比較しています。

シフト左

私たちは物事についていかなければなりません。 ペースを落とさずに物事に優先順位を付けるにはどうすればよいでしょうか? 発生する可能性のある問題をどのように検出し、対応しますか? まず、シフトレフトについて話しましょう。 皆さんの中には、私と同じように、この言葉を聞くと目を丸くしてしまう方も多いかもしれませんが、これは重要な概念であり、基本的には、私たちが発展しているとき、最も早い段階から正しいことをするということです。 これらのことをできるだけ早く修正してください。 ですから、私たちにできることはたくさんあります。 私たちはそれらをロールスルーするつもりです。 1つは、私たちが止められなかったり、プロジェクトが遅れたりしていないことです。 私たちは後でそのようなことを防ぎたいのですが、それは後でやろうとするとコストがかかるからです。 より良いことはそれを処理することです。 皆さんの多くがおそらく取り組んでいるセキュリティ問題にはどのようなものがありますか? 1つは、画像をスキャンしているときに報告されるCVEが非常に多くログに記録されていることです。 昨日、皆さんの何人かに出会いましたが、「こんなことをしているとは思えない」と言いました。 ですから、それは懸念事項ですが、できる場所はたくさんあります。 その方法のいくつかについてお話しします。

もう一つは、私たちが自社の顧客を調査したばかりのレポートの1つです。 SysdigはSaaSプラットフォームを運営しており、多くのお客様がコンテナ志向です。 実際に root としてコンテナを実行しているお客様の数を調べました。 さて、時にはそうする必要があるので、それについては後で説明しますが、私たちが見ていたコンテナの 83%はルートとして実行されており、これは非常に寛容であり、おそらく正しいことではありません。 その理由については、後ほど説明します。

私たちが見ているもう一つの問題は、アレックスがこれについて話すと思いますが、私たちが始めるイメージは、ベースイメージとしてイメージをつかみ、それを使って構築を始めるのはとても簡単なので、そこには夜も眠れないようなものがあるということです。

基本的には、画像の内容を見ると、そこにはおそらく最高ではないものがかなりたくさん含まれているということです。 あなたはインターネット上のランダムな場所からNginxから始めています。 それを全体的なインフラで使用すると、時間を節約できますが、通常はまだ知らないものが含まれているため、最初に行うべきことはスキャンすることですよね? 構成的にも脆弱性的にも、気になる可能性のあるものはすべて 90%程度で見つかります。 つまり、クリプトジャッキングやシークレットの埋め込み、その他のプロキシに関することなど、うまくいかない可能性があるということです。 しかし、そのコンテナ内のものの約 10%は、実際に実行が開始されるまで表示されません。

つまり、 90%というのは素晴らしいことですが、それでも 10%のリスクや脅威は、その特定のコンテナで実際にワークロードを実行するまで現れません。 なぜ重要なのかというと、その多くがかなり大きな影響を与えるため、エリックが話していたレポートでは、クリプトマイナーが1ドルを生成するために、おおよそ53のリソースを消費していることが示されていますよね?そのため、XMリグがその画像の内部にベイクされているのは、大きな問題です。 したがって、開発される時期、リポジトリにある時期、クラスターに受け入れられる時期というコンテキストでこれらのことを見ていないと、さまざまな主要な領域を見逃していることになります。 そして、その開発ライフサイクルがあるため、そのことを念頭に置く必要があります。

これは、私たちの組織に多くの企業が持っている脅威調査チームがあり、彼らがこれらのことを発見し、興味深いブログをたくさん書いて、「私たちはこのようなことが起きているのを目の当たりにしている。そして、その多くが 10%の分野で起こっている」と述べていることに起因しています。

ビルド プラクティス

ビルドの実践について少しお話ししましょう。 これについては、すぐに説明します。 コードとその方法を示すつもりはありませんが、これのいくつかは簡単なことです。 信頼できる情報源を使用してくださいよね? 私たちは、既知のパブリッシャーや信頼できるソースから、認定パブリッシャーに対して正しいことを行ったDocker Hubなどのイメージを取得し、それらのリポジトリでスキャンされているものも取得して、彼らに何が起こっているのかを把握したいと考えています。 今週、お客様からの電話を聞いていました。 そして、そのうちの1人が「はい、私たちはヘルムチャートを使って何かを展開しています。」と言いました。そこには、この画像を引っ張ってこい、セキュリティですべてのものをランダムに迂回し、スキャンされていない場所から取得するという行がありました。 これらはあなたが避けたい種類のものです。ただ、それが信頼できることを確認してください。

それはすべてあなたがあなたの情報源を知っていることを確認することであり、それを行うにはさまざまな方法があります。 本当に簡単に実現できる方法の1つは、画像の分布がどうなっているかということです。 それはランダムなUbuntuイメージですか? UBIの画像ですか? それはChainGuardのような営利団体から来ていますか?これに対処する方法はいくつかありますが、そのアプリケーションの構築を開始するときに、全体的により良い姿勢を保つことができます。

1つ明らかなことは、不必要な特権を避けることです。 あなたがそれを助けることができるなら、rootとして実行しないでください。 さて、見てください、それが必要なときがあります。 実際、そのコンテナを特権として実行するために必要な適切なレベルの洞察を得るために、私たちが行っていることがいくつかありますよね? しかし、それが必要な場合は、環境内で他のことをしないように、それを正当化することもできます。

それに加えて、他に何か付け加えることはありますか? 私は本当にそうではないという意味です。ただし、注意してください。 少なくとも、コンテナを誰として実行するかを指定していることを確認する必要があります。 好きなように走らせるだけではいけません。 特定のユーザー名や、それらのために使用するものを指定してください。 本当に、本当に簡単に手に入るのは、その特定の容器の姿勢が限られていることを確認することです。 権限はクマですよね? それらは必ずしも対処するのが最も楽しいことではなく、私たちは皆、一日を過ごすためだけにchmod 777 を行ってきましたが、おそらく本番環境ではそれを行うべきではありません。

素晴らしい、そして、私が間違っている場合は私を修正しますが、初めて画像を取得するとき、それは本質的にルートとして設定されていますよね? 通常、ユーザーとして実行されている画像がたくさん表示されます 1000、 大丈夫ですが、 ユーザー 0、 はい よりも優れています。

次はもう少しトリッキーだと思います。 しかし、私のイメージにたどり着くのは、依存関係やその他のパッケージで継承される可能性のあるもの、または先ほどNginxの話をしたかもしれませんが、私が使用しないものがすべて含まれています。 それらのものが脆弱であるとき、あなたはこれが、私たちが呼ぶところの肥大化、正しいイメージを持っています。 あなたはそれについて注意したいです—あなたの画像をスリムに保ちます。

これはマルチステージビルドです—この概念がよくわかりませんか? 基本的には、必要なときに必要なものを重ねていくという意味です。 例えば、ある時点で必要になる可能性のあるものをすべて備えているものを必ずしも手に入れに行く必要はありません。 非常に単純なものから始めて、必要なレイヤーのそのイメージに必要なものを展開してください。 基本的には、そのことを最小限にとどめることが大切です。 それを持っていない、太陽の下ですべてを持っている。 おそらくコンテナにnetcatは必要ありません。 はい、それはかっこいいですが、露出スポットでもあるので、あなたがあなたの勤勉さをしていることを確認してください。 理にかなった方法で物事を行う。 スリムに保ちます。最小限に抑えてください。

既知の最小限の画像から始めることができますが、このディストリビューションレスの概念もあります。 結局のところ、アプリに必要のないポートのようなものをたくさん公開したくありませんよね?

敵があなたに近づき、間違ったことをする方法を減らすためにできることはたくさんあります。 私たちは正しいことをすることについて話しているのです。 資格情報をハードコードしないでください。 これが鍵ですよね? もし外部ストアのようなものを使えるのであれば、たとえそれが好都合であっても、内部に秘密のようなものを入れたくありません。 おそらくやらない方がいいでしょう、なぜなら、誰かがそれに到達するとすぐに、彼らは他のことを始めることができるからです。

これは、早期に、そして頻繁に始めるためのベストプラクティスです。 私が何度見たかわかりませんが、開発者が自分のラップトップで行っていることが、それをシンプルにしているからです。 彼らはテストに合格することができました。彼らはすぐに荷物を運ぶことができました。 それは便利です、誤解しないでください、しかしあなたは最初にそれらの衛生状態を実践する必要があります。 そうしないと、事故が起こります。 悪意があることはほとんどありません。 ユーザーは、オフィススペースで自分のファンタジーを追体験し、あなたから小銭を盗むようなものではありません。 彼らはただ自分の仕事をしようとしているだけですよね? そして、あなたが悪い習慣や悪い衛生状態を知っていること以外、誰も本当に悪いわけではないので、人々が最初から正しい方法でそれを行うことができるようにすることが重要なのです。

明らかに、次の質問は、機密情報を含めないでください。 私たちは本当に良いブログを持っていますので、最後に紹介します。 でも、そこには何かしらのものが入っていて、もうそこにはないと思っていたんですが、実はまだレイヤーの1つに下がっているんです。 そのようなものは、あなたが望まない機密の性質のものがまだそこにあるかもしれません。

オンサイトまたはどこかでプライベートレジストリを使用している人は何人いますか? それがあるのは良いことですが、それを保護するために適切な種類の権限やものを使用していることも確認してください。 それと通信するための適切な種類の安全なプロトコルを使用するなど。 ええ、つまり、いくつかのレジストリを持つことを恐れないでください。 あなたは、すべてのアーティファクトを捨てて、太陽の下のすべてがそこに入り、そして、あなたがあらゆる種類の黄金のイメージをすべて保持するものがあるかもしれませんよね? 本番環境で実行されているものは、開発ブランチがあるレジストリとは異なるレジストリから来ている可能性があります。 これにより、プロセスを通じて物事を宣伝する際に、ある程度の厳密さを持つことができます。

自動チェック

これは、私たちが重要だと考えているいくつかのことについて少しです。 あなたがビルドの観点からそれについて考えていなかった場合、あなたはまた、これらのもののいくつかの自動化の能力を知っています。 万が一忘れてしまった場合に備えて、リンターのような何かを所定の位置に置くことで、正しいことをしていない場合に警告を発することができます。 つまり、 Haskell Dockerfile Linterというものがあり、実際に行き過ぎる前に、これらの問題の一部をあなたに公開するのです。

だから、おそらく最善の方法で設定されていないこれらのことに対しては、あまり何もできないことがわかります。 一部の画像スキャナーは、Sysdigがこれらのものの一部を見るように、これらの洞察も提供します。 たとえば、この画像はルートとして設定されています。 例えば、パイプラインを経由する何かが進行するのを実際にブロックすることができますが、そのレベルの可視性が自動的に行われるようにすることで、単に脆弱なものを読み取るだけでなく、そうでしょう? 設定がオフになっていること。

さて、自分の組織では、実際にはスキャンを行っていない、または少なくとも画像が十分に行われていないと考えている人はどれくらいいるでしょうか? ええ、見ました。 それはあなたのビジネスの性質や、あなたが働いている規模やスピードによるものかもしれませんが、これを何らかのレベルや形で行うのは良いことです。 ご存知のように、それらを組み込むレジストリはたくさんあります。 それはそこにあり、おそらく先に進んでそれを使用するのは良い考えです - それがクラウドや岸壁の何かであろうと、あるいはそれ以外のものであろうと。 また、スタンドアロンのツールでも利用できます。 私たちはSnykという組織と提携しています。現在、Docker Scoutと提携しています。 そして、これらは、物事がスキャンされていることを確認するために配置できるものです。 スカウトがこれをやっていることは知っています。私たちは、これが私たちが推奨するもの、これに対処するためにあなたがただぶつけることができるものだと言います。

素晴らしいのは、このマイナーなリビジョンにアップグレードするだけで、実際にはこれだけの問題が解決されるという読み出しが出てくることです。 ワンショットのように、セキュリティの観点からははるかに良い状態になります。 ですから、これらのことは時間を節約するという点で非常に重要で役立つことであり、アレックスがこれについて多くの点を指摘するのを手伝ってくれることを私は知っています。 それは安全であるだけでなく、時間を節約することでもあります。

次のスライドは、これを如実に表しています。 CI/CDパイプラインやJenkinsなどを使用している人はどれくらいいますか? ええ、それはあなたの一部であり、まだそれをしていない人もいるかもしれません。 しかし、スキャンの一部をそれに押し込むことを考えてみてください、そうすれば、Jenkinsのような何かに乗っているときに、これらの読み取り値がすぐに得られるようになります。 そして、それが実際にレジストリリポジトリに流れ込む前に、それらに対処しているのです。 また、それだけでは終わらないとも考えています。 つまり、レジストリのスキャン、構築中のスキャンなどです。 そこにたどり着くのに役立つツールはたくさんありますので、これらの問題に迅速に対処でき、後で誰かに肩を叩かれることはありません。 そして、ランタイムに関することも考慮する必要があります、そして私はあなたにそれを取ることを任せます。

これが本当に重要になるのは、アプリケーションが何を使用しているかを正確に把握できたらいいと思いませんか。 開発者の視点から見ると、多くの場合、ある種の基本イメージから始めて、その上にアプリケーションの実行に必要なものを重ねています。 そして、本番環境にデプロイしています。 必然的に、CVEや脆弱性、そして修正しなければならないことのリストが、2週間、3週間、4週間後に大量に手に入ることになります。 その多くは、実際には活用していない画像、いわばパッケージの数から来ています。 現在、Sysdigのような人々と、ランタイムスキャンの概念を行っている他の人々との間に、素晴らしい技術が登場しています。 これは、単にイメージを再度取得するだけでなく、イメージ内のライブラリを調べて、それをコンテナによって実際に実行されているものに関連付けることです。

したがって、カスタム イメージをビルドすると、そのイメージ内のどのライブラリを実際に使用してアプリケーションを強化しているかを把握できます。 最終的には、基本的に、これらの 15、20 パッケージ、これらの 30、 40、 50 ライブラリが私のコアアプリケーションを構成すると言うことができます。 そして、ここには他のライブラリやイメージ、パッケージなどがあり、それらは一度も呼び出されることはありませんが、脆弱性があります。

2つのことをしましょう。 レポートを作成し、使用中のものと使用されていないものの間に線を引きましょう。 使用中のものを修正し、明日は、アプリケーションによって実際に呼び出されたことのない脆弱なものをすべて削除しましょう。 つまり、セキュリティ担当者は、アプリケーション内で実際に実行されているものだけに範囲を限定しているため、 50 ページにも及ぶ脆弱性のリストを提供していないということです。 次のイテレーションサイクル、次のパッチ適用サイクルでは、フットプリントが大幅に削減されます。 そのため、初回はまだかなり長いですが、修正する代わりに、使用していない綿毛をすべて取り除いています。 そして次回は、アプリケーションによって実際に使用されているものに関するレポートのみを取得します。 これにより、開発者の時間を節約できます。セキュリティ担当者の時間を節約できます。それはあなたが本当に気にしていることをするためにあなたの一日の中でより多くの時間を与えます - それはあなたがすでにやったことをパッチするだけでなく、あなたの会社に価値を付加することです。 ですから、そのランタイム要素は本当に興味深いもので、基本的には、その画像内の潜在的なリスクを絞り込み、実際に重要なことだけを進めることができるようにする方法です。

非常に良いです、そしてそれに細かいポイントを置きましょう。 これも、なぜこれが難しいのか、そしてなぜこのようなCVEレポートが返ってくるのかに圧倒される可能性があるということでわかったことです。 そこにはたくさんのものがあり、多くのお客様が初めてスキャンする画像を使用し、重要度の高いものや重要なものがたくさんあります。 そして、これにどう対処すればいいのか、という感じです。 その課題の一部は、日々、ログに記録されるCVEがますます増えていることです。 そこで、ランタイム要素の出番です。 だって、こういうモグラたたきのシナリオになっちゃうから。

しかし、私たちは深刻度を見たいと思っています - 多くの人は、高値と重大性だけに対処するでしょう。 彼らは、エクスプロイトがあるかどうかを知りたがっています。 いいえ、それは脆弱ですが、私たちがこれまでに誰かがこれを悪い目的に使用する方法を見たことがありません。 それを知ることは重要であり、インターネットに公開されているものに基づいて優先順位を付けることができるためです。 それには別の用語がありますが、思い出せません。 とにかく、net-net、それは到達可能ですか? 修正はありますか? 既知の修正がない場合は、その脆弱性に対して他に何を保護するかを把握するか、既知の脆弱性が悪用されている動作を監視したいと考えています。 そして、この新しい次元が「Is it in use」を追加しています。 そして、それがSysdigの信条であり、Sysdigについて他に覚えていることが何もないとしても、それは良いことです。

Sysdigの

最後に、Alexがプラットフォーム全体についてお話ししますが、ランタイムに関するすべてのことを可視化するのに役立っています。 そして、それを優先順位付けに役立てています。 多くの皆さんは、開発者であれば、この図の左側にいるかもしれませんが、一部の構成では、権限について話しましたが、作業内容によっては、この概念を使用して使用しています。 使用中は、何を優先しないかを決定するのに役立つか、何をシフトして変更するかを決定するのに役立ちますよね? では、パブリッククラウドのようにコンテナを実行している人は何人いるのでしょうか? だから、私はこれらすべての権限を与えられてきましたが、それらを決して使用しないか、または私の仕事をする必要がないかのようです。 私たちは、あなたがそれを理解し、シフトし、変えることができるようにお手伝いします。

電話側では、お客様の一人が「ねえ、あなたは私にたくさんの時間を節約している」と言っています。 そして、それがアレックスが言っていたことの正味です。 昨日ブースで受けた質問を取り上げてみて、私が話した皆さんの多くが、Sysdigの秘密のソースをどうやって知るのか、コンテナ以外にも何かが動いているかどうかを知るのか、という質問を受けました。 どのパッケージが実行されているかは、どうすればわかりますか?

私たちの計装方法は、ほとんどのものとは少し異なります。 私たちは、インフラストラクチャから詳細を引き出すために、一種のボトムアップアプローチを採用しました。 その多くは私たちの家系から来ています。 Sysdigは約 10 年前に設立され、Wiresharkの共同開発者によって設立されました。 また、Wiresharkは、インフラストラクチャを所有している場合、パケットを取得してアプリケーション内で何が起こっているかを確認するための素晴らしいツールでした。 私たちが解決しようとした問題は、インフラやスイッチなどを所有していないクラウドで、どのようにそれを実現するかということでした。 スパムポートにアクセスできないのですが、どうしますか? 私たちが考え出した解決策は、クラウドで最も一般的でない分母は、私たちが実行しているオペレーティングシステムでした。

カーネルに入り込み、システムコールをインターセプトできれば、パケットと同じレベルの粒度が得られます。 ですから、実際には、ある意味ではより詳細に把握できると言えるでしょうが、net-netは、すべてのシステムコール、すべてのプロセス、すべてのファイルアクセスを確認でき、それをライブラリ、パッケージ、それが何から来たのかに関連付けることができるということです。 そのため、ランタイムワークロードに関する非常に詳細な情報を取得し、そこで何が起こっていたかを確認できるようになりました。 その後、次のステージに進み、「これは素晴らしい、実行中のワークロードのデータをすべて確認できる。クラウド自体はどうだろう」と考えました。 使用している他のSaaSサービスはどうですか?

私たちは、システムコールのインターセプトについても同じアーキテクチャを採用し、Kubernetesの監査ログ、AWSのクラウド証跡ログ、GCPの同様のログ、Oktaのログなど、あらゆる種類のソースを調べて、悪意のあるアクティビティやストリーミングデータの概念を探すことができるようにしました。 つまり、私たちが使用するエンジン全体は、入ってくるすべてのデータを見て、異常な活動を見ているということですね。 これは、Snort がパターンやパケットを見たのとほぼ同じだと考えることができます。 Sysdigは、パターンやシステムコール、監査ファイル、ログファイルなどを調べています。 涼しい。

ここで短いストロークに取り掛かります。 ただ容器側に細かいポイントを乗せるためだけに。 コンテナは左側のように見える場合があります。 しかし、どれが使用されているかを教えて、時間、お金、労力を大幅に節約し、現在経験している疲労の一部を減らすことができるとしたらどうでしょうか。 最後の瞬間に、見逃した場合でも、これはDocker Scoutのようなものを活用し始める計画の一部です。 これがDockerの人々と一緒に持ち込むものであり、昨日これを発表できたことを非常に嬉しく思います。 繰り返しになりますが、同じ価値提案です。 おそらく最も重要なのは、安全な画像をより迅速に提供することです。

つまり、この情報は Vex (脆弱性交換) の形で Docker Scout に送信されたり、Docker Scout によって引き出されたりして、次のような可視性が得られます。 ネットネットは、実際に何が影響を受けるのかを明確に把握できるようにすることです。なぜなら、誰かがそれにたどり着くことができるからです。 そして、そこに眠っているのは何でしょうか? それが重要で、私たちは、あなたが恐怖で見つめている瞬間を見るのが大好きで、その後、影響を受けたものだけを見せてくれると、その数がずっと管理しやすくなり、私たちはずっと幸せになります。

左シフト/シールド右

以上が、SysdigとDocker Scoutについてお伝えしたい重要なメッセージです。 最後に、先に述べたように、左にシフト/右にシールドします。 シールドライトとは? 一部の人にとっては、これはあなたのドメインにあります。一部の人にとっては、それはあなたのドメインにありません。 しかし、いずれにせよ、これは重要な概念です。 Alexは、ランタイムの脅威検出は、実際には、構築したものがDockerノードまたはある種のクラスタで実行されているときにすべてですよね? 私たちはそのことを見守りたいのです。 世界最高の脆弱性管理を行っても、一部の悪い行動を防ぐことはできません。 それは私たちが監視したいことでもあり、これは私がその脆弱性を修正できない場合のセーフティネットになる可能性があります、私は誰かがそれを悪用しようとするときに予想される結果がどうなるかを監視するつもりです。

重要なのは、これらのランタイムの脅威にどのように対処するか、そして自分の環境で何が潜在的にリスクにさらされているかをどのように把握するかということです。 その概念は、実行中のコンテナがあり、公開されているものがある場合、クリプトマイニングのようなものを探す必要があるということです。 データの悪用を探す必要があります。 基本的には「ここにランダムなMITRE用語を挿入する」を探す必要があります。 そのためのランタイム脅威ソリューションを持つことができることは、かなり興味深いことであり、むしろ必要です。 これはEDRのようなもので、クラウド用と考えてください。私たちは、稼働中のものがリスクにさらされず、露出しないようにするために、そのスペースに適合させようとしています。 次に、そのデータを取得して開発者に返し、アプリケーションを構築している人々に返還することで、基本的にはより良い作業を行い、重要なことにより多くの時間を費やせるようにしています。 Dockerのような人々と提携することで、開発者はそのデータを早期に取得し、頻繁に取得して、将来の潜在的なリスクを回避できます。 すごい。

私たちが会社として持っている全体的な目標は、可能な限り多くの人々の時間を効果的に節約することであるため、脆弱性管理について吐き気を催すほど話しました。 他の柱に関しては、クラウドインフラストラクチャ内のユーザー権限やリソースアクセスなどについて言えば、それほど違いはありません。 クラウドトレイルなどのランタイムログを見ると、ユーザーが何をしているのか、何にアクセスしているのか、何に触れているのかを確認でき、それらのさまざまな役割に対して適切な権限とデータセットを提案できます。

したがって、ランタイムコンテキストでユーザーアクセスを見ることができれば、このユーザーは実際にはこれらの領域にアクセスしたことはなく、これらの権限セットを使用したこともなかったと明らかに言えます。 それらを引き離しましょう。 ユーザーを信頼していないわけではありませんが、そのユーザーの資格情報が公開されると、トークンが公開されます。 彼らが影響を与えることができるのは、その爆発半径ですよね? では、そのランタイムデータに基づいて、これらのことを制限しましょう。

結論

いくつかの質問をお受けします。 安全を確保しながらも、イノベーションを起こす時間を確保しましょう。 昨日、Dockerのホームページから盗んだのは、最初から安全なソフトウェアを構築することです。 私たちは皆、精神的にそれを望んでいます。 面倒なことではありませんよね? そして、私たちが前進するにつれて、Docker Scoutが支援している多くのことが重要なのです。 左にシフトし、右にシールドします。 どちらも重要です。 シフトライトはあなたの範囲にはないかもしれませんが、本番環境の実行環境に関心のある人のためのものです。 ですから、私たちが助けることができるかどうか私たちに知らせてください。 私たちは、私たちが残したいくつかの瞬間にあなたが持っている質問をし、そこに私たちを訪問することをあなたに招待します。 すでにお持ちの方も多いと思いますので、よろしくお願いいたします。

さて、これで終わりです。 聴衆の中にいてくれてありがとう、私たちのブログにはもっと広範な詳細がたくさんあります。 大丈夫です。 涼しい。 どんな質問でも。

質疑応答

大丈夫です。 そのため、セキュリティチームが大きな問題を抱えていることは、多くの人が知っているかもしれません。 これは、さまざまな理由でコンテナ化と長年の敵対関係にあり、これまでコンテナ化にはセキュリティが強く欠けていたようです。 そして、SysdigとDocker Scoutがコンテナスキャンのために登場することになると、トンネルの終わりに光が見えてきたように思えます。 私の質問は、ISO 2701、CMMCのようなセキュリティフレームワーク標準は、SysdigとDocker Scoutで満たされるのでしょうか?

部分的には、私がこれら2つのことを実行していると言うことはできません、したがって私は準拠していますが、それらはあなたが準拠している理由を示すためのあなたの成果物の一部です。 スキャンやレポート作成、データセットの取得以外の制御や作業が必要になりますが、これらは制御フレームワーク内の成果物であり、これらの標準に準拠するために使用するものです。

さて、これによりセキュリティチームは少し満足します。

そして、私たちがこの製品を使って全範囲にわたって行ってきたことの1つ、つまり、スキャンを試みる時点からポスチャ管理、ランタイムに至るまで、それは物に依存するということです。 ポスチャーの途中で、 27001へのISOのレポートがあり、ところで、通常はクラウドベース、オンプレミス、OpenShiftなどの環境を確認します。 でもねえ、これが赤で、これがあなたが忘れていた緑です。 ここでは、あなたがやっていないこと、走っていない具体的なことを紹介します。 切り替えたいことがいくつかありますが、それが正しく行われていない可能性があります。 それもありますが、スキャンの面では、ISOに準拠する必要がある場合は、これらを用意する必要があります。 ランタイム側では、このことが私たちがあなたに与えたこのポリシーをトリガーする場合、あなたはおそらくISOやPCI、または満たそうとしている標準に違反していることを知っておく必要があります。

結局のところ、特にコンテナの脆弱性管理に関連するコンプライアンス仕様には、多くの所有権があるということです。 おそらく、この特定のスキャンでは、この環境では 50 クリティカルしか発生しないという問題に対処しなければならなかったでしょう。 それ以上のものがあれば、監査などは失敗するでしょう。 そのため、特定のクリティカル、特定の高い脆弱性のリスクを軽減するために多くの時間を費やすことになりますが、そこで使用中のコンセプトが重要になります。 基本的に、これは高い脆弱性であることを証明できます。 それは実際には呼ばれていないので、この特定の理由に基づいて、私たちのフレームワークで高いものから中程度のものまでリスクを軽減することができます。 そして、さらに良いことに、次にスキャンしたときには、最初に物を取り除くことになるので、そこにはありません。 ですから、これらの政策の多くは、基本的にはクリティカルをカウントし、高値をカウントし、限界は何か、なぜなら、私たちが持つことができるかどうかはある程度許容されるからです。 ばかげていますが、監査人はそう見ています。

ところで、コンテナ側が横にずれていて、警備員が参加しないことがあったという点については、私も同意見です。 特にこの 18 カ月間で、その状況は変化しています。 例えば、セキュリティチームが増えているように、それは組織の規模などによって異なるかもしれませんが、彼らはクラウドネイティブ、特にクラウドに真剣に取り組んでいます。

ですから、シフトレフトが本当に重要になるのは、セキュリティチームと早期にコンテナ開発を連携させることができれば、彼らがそれをよりよく理解するようになるため、あなたの生活ははるかに良くなるでしょう。

そこでは、eBPFを使ったスライドの1つを見せました。 それについて2つの質問をしたいと思います。 それが単なるプローブである場合、それは何かの強制を行うようなものですか、それとも単なる可観測性ですか? 次に、たとえば、Ciliumも実行され、カーネルレベルでも動作している場合、それはどのように共存しますか?

eBPFの場合、すべてが独自の小さなメモリ空間で実行されます。 それはほとんど - それは悪い例えです - しかし、JVMのようなものだと考えてください。 eBPFは、コンテナ化された小さな場所で実行され、隣接するeBPFアプリケーションに干渉しないため、共存できます。 それは何も悪いことではありません。 Sysdig側から見ると、読み取り専用のプロセスとして実行されているため、データを引き出すときに行っているのはノンブロッキング読み取りです。 したがって、eBPF自体の内部には直接的な強制はなく、カーネルへの適切なアクセスを行うべきではありません。 それはとても、とても怖いことなので、そんなことをする人から逃げることをお勧めします。 Nvidiaがあなたを作るからではないかもしれませんが、そこでの核となる信条は、私たちが目にするものに対するすべての反応、すべての執行が事後またはそれに沿って行われるということです。

Sysdigのインターフェースには、コンテナドリフトポリシーがあります。 これは、コンテナが実行された後に突然何か新しいものが追加されたコンテナがある場合、そのコンテナを停止するか、プロセスを強制終了するか、またはそもそも実行されないようにするかを選択できることを示しています。 その場合、コンテナが何かを行い、システムが投票を呼びかけ、Sysdigがそれを見て、エージェントがそれを読み、ああ、この特定のことに対して「防止」アクションがあると言うのです。 私はptraceか何かでそれを殺しに行くつもりです、そしてそれでそれはすべて一直線に行われます。 これは特にカーネルでは起こっていません、なぜなら私たちはカーネルに書きたくないからです。 それは理にかなっていますか? ええ、それは理にかなっています。

そして、2番目の質問ですが、PCIなどのコンプライアンスパックについて言及されました。 例えば、CISOが独自のコンプライアンスを持っているとします。 例えば、銀行のアプリケーションであり、cidデータがあり、そのデータやこれが何らかのネットワークを介してアクセスされたかどうかを確認したいとします。 あなたはあなた自身のポリシー施行と一緒に来ることができますか?

ええ、ある程度、Sysdigで行うすべてのことはオープンソースに基づいているので、ランタイムエンジンはFalco、cspmエンジンはすべてregoで書かれており、コントローラーからのエンフォースメントもすべてregoで行われています。 ですから、これらすべてがオープンスタンダードなのです。

ですから、多くの場合、自分のポリシーを持ち込んで実行することができます。 製品には、すべてのものを自分で完全に持ち込むことができない特定の領域がありますが、特定のコントローラーの要件に合わせて存在するものをカスタマイズできます。 なぜなら、正直に言うと、それは非常に複雑な構文言語であり、ほとんどの部分で失敗するようなことを人々に実行させたくはないからです。 そのため、高度にカスタマイズ可能なポリシーが多数あり、基本的な取り組みとして使用することができます。

ところで、あなたがeBPFについて尋ねたので、私はあなたとあなたがそれを受け取っていないならここにいる誰かにオファーをしたいです、かなり分厚い本があります。 ですから、今日はそれを手に取るのにふさわしい日かもしれませんので、eBPFのコンセプトについて家に持ち帰ることができます。 Sysdigの問題ではありません。 それは本当にeBPFについてです。 ですから、私たちはLinuxカーネル自体の中で非常に早い段階でeBPFに深く関わっていました。 私たちの従業員の中には、そのコードの多くを創り出し、Linuxに変換し、それを実行するのを手伝っている人たちもいました。 それについては、とても楽しいリソースがあります。 逆に言えば、飛行機の中でよりよく眠れるようになるかもしれません。 ところで、eBPFは、知らない人のために説明すると、拡張されたBerkeley Packet Filterですが、今ではパケットとはほとんど関係ありません。 これは、カーネルレベルでこれらの小さなプログラムを取得して実行する方法です。

ご来場いただき、誠にありがとうございます。 皆様、ありがとうございました。

さらに詳しく

• コンテナのセキュリティとそれが重要な理由
• コンテナとは 
• Docker デスクトップの最新リリースを入手します。
• 質問がありますか? Docker コミュニティがお手伝いします。
• ドッカーは初めてですか? 始めましょう。
• Docker Newsletter を購読してください。