共有写し
こんにちは。 クリスチャン・デュピュイが、Sysdigのアレックス・ローレンスを紹介します。 今回は、Sysdig runtime insightsで構築した統合についてお話しします。 一種のコンテキスト設定として、これは何についてですか? 基調講演で、私たちは大量のデータを取得し、そのデータを内側のループで開発者のコンテキストに取り込むことを使命としていることをご覧いただきました。 それこそが、私たちが Docker Scoutで達成しようとしていることです。 目標は、開発者がサプライチェーンのセキュリティを常に向上させるためにローカルで作業する際に対処しなければならない認知的過負荷、つまりノイズを大幅に削減することです。 そして、その素晴らしいパートナーシップの1つがSysdigです。
そして今、基調講演で示したものよりも少し深く掘り下げたいと思います。 それでは、アレックスにSysdigをお見せしましょう。 Sysdigは、ScoutユーザーとしてScoutからアクセスするすべての人に無料トライアルを提供しているので、自分のインフラストラクチャでこれを試すことができると思います。 アレックス、それを取り除いてください。
ありがとうございます。 基本的に、今日の私の目標は、たくさんのスライドであなたを退屈させず、ランダムなことを話すことでした。 Sysdigのインターフェースの内部をお見せして、本当にライブのものに焦点を当てようと思っていましたよね? 今、何が起きているのか? 次に、最後にDockerに返して、Docker側への統合を示します。
目次
Sysdigインターフェース
これがSysdigのインターフェースです。 重要なのは、環境全体、CNAPPポートフォリオ全体で何が起こっているかということです。 これはクラウドアクティビティのビューですよね? したがって、これはクラウド構成に対して実際に起こっていることになります。 そして、私はこれをいくつかの異なる方法で見ることができます。 今は、アカウントやリージョン、リソースの種類などで見ています。 しかし、多分私はマテオのアカウントまたは誰かのアカウントが正しく機能していないのではないかと疑っています。 そして、それは私にライブ検索をさせることができます。 マテオみたいなのをここでやってもいいし、マテオのものだけを見せてくれる。 そうすれば、私はMateoだけを気にしていると言えます、多分アクションを削除します。 したがって、deleteと入力し始めると、Mateoの削除にフィルタリングされますよね? 基本的に、クラウドで発生しているすべてのイベントを調べて、非常に具体的なものを探すことができますよね? このコンテキストで何かが削除されるたびにわかります。 Mateoを削除したり、削除したりして、すべてのイベントに戻って、削除アクションを探して、ライブですべてのものをふるいにかけ始めることができますよね?
そうすることで、今何が起きているのかという視点が生まれます。 そして、この時点で私は何を気にすべきですか? データを取得して、さまざまなパラダイムで見ることができます。 つまり、クラウドのアクティビティについてでした。 AWS、Google、Azureなど、すべてのクラウドでユーザーが何をしているのかなど、具体的に見て、人の視点から見ることができます。 そして、私は私が望むものを見ることができるその全く同じ検索をすることができます。 私がここに置いた文字列用語は、クイック検索を行います。
クラスターを作成した場合は、クラスターの削除やリードの削除を見つけて、クラスターに対して実行されたアクションを具体的に探すことができます。 そうすることで、非常に斬新でスピーディーな方法でそれらすべてに目を通すことができます。 また、これをユーザーやクラウドのものから切り離すように再編成したり、Kubernetesやコンテナで起こっていることを具体的に調べたりすることもできます。 ポッドまたはワークロードだけに絞り込むことができます。
どうしたんですか。
基本的には、今自分の環境で何が起こっているのか、現時点で本当に気にすべきことは何かを視覚的に探ることができます。 これは、特定のクラスターから拒否されているものも示し始めているので、ちょっと楽しいです。 したがって、スキャン評価に失敗したためにコンテナが拒否されたイベントが発生していることがわかります。 ですから、もし私が誰かにコンテナを作らせたとしたら、そのコンテナは理由が何であれ、適切なものが渡ってきませんでした。 実際にその失敗に関するイベントが発生し、本番環境にプッシュしようとしているものが認められていない詳細レベルも確認できます。 つまり、ライブデータと、それが実際に行っていることのほとんどが重要なのです。
これらはすべてこのイベントセクションから来ていますが、非常に視覚的な方法で見て、インフラストラクチャが実際にどのように見えるかというコンテキストで探索できます。 この視点では、すべてのイベントでより伝統的な視点を与えてくれるようなものです。 これについて興味深いのは、物事のさまざまな詳細にかなり深く入り込むことができ、さらにいくつかの強力なフィルターにアクセスできることです。
フィルタリングと優先順位付け
私がこれを気に入っていることの 1 つは、セキュリティ組織を運営していて、靴下の懸念がある場合や、マッピングしている特定の MITRE の懸念がある場合、または PCI コンプライアンスがある場合です。 これらのさまざまなコンプライアンス仕様のフィルターを追加し始めると、それらのさまざまなフレームワーク内でライブ違反を探すことができます。 今のところ、一番近いのは6時間前のものなので、 10 分前のものはありませんが、この特定の仕様に準拠していることを保証する必要があると言えます。 イベントを総合的に見て、特定の仕様に準拠しているかどうかを確認しましょう。 右。 そのため、チームごとに異なる方法で、さまざまなユースケースでそのデータを使用できます。
私たちがここで行っている他のことの多くは、より有意義な方法でお客様の生活に溶け込むことです。 私が言いたいのは、エンドユーザーとしてセキュリティ組織と取引する場合や、その逆の場合、異なる方言を話していることが多いということです。 同じ言語を話しているのに、違う言葉を使っているか、その言葉の意味が普段使っているものと違う。
ここでの非常に良い例の 1 つは、たとえばポスチャ管理に関するものです。 これは、私たち全員が気にかけなければならない重要な分野です。 重要なのは構成であり、強化され、適切な方法でセットアップされていることを確認することです。 そして、ほとんどの場合、仕様を見ています。 繰り返しになりますが、PCIやNISTなど、Kubernetes、コンテナ、Dockerなど、あらゆるものに関するベストプラクティスです。 結局のところ、通常、設定ミスに関するレポートを受け取ることになります。
セキュリティの専門家としての私の仕事は、基本的に、チームが修正するために最も重要だと思うことを優先することです。 そして、私は彼らにこのレポートを与えるつもりです。 私はそれをPDFとしてダウンロードし、壁越しに彼らに手渡して、これらすべてのことを修正してくださいと言うつもりです。 そして、彼らは基本的に、セキュリティは私にやるべきことの膨大なリストを与えてくれた、と言うでしょう。 設定ミスをいちいち調べに行かなければなりません。 どうやって修正すればいいのか、調べに行かないといけない。 どうすればいいんでしょう。
ですから、多くのツールが、よし、いいね、間違っているものや理解しにくいものを氾濫させたくないと言っています。 それでは、rootとして実行することなどを見てみましょう。 ですから、ちょっとした指示をくれて、その後、従うべきものを手に入れることができます。 しかし、ツールが運用チームと同じ言語を話せたらいいと思いませんか? または、開発者と同じ言語を話しますか? 私たちがやろうとしていることは、それをさらに一歩進めて、オーケー、この仕様はできている、まだコンテナをrootとして実行すべきではない、と言うことです。
それでは、環境全体ですべてのルートコンテナを見つけてみましょう。 これらのうちの1つをハイライトすれば、実際に特定のリスク、それに違反している特定のコンテナを見ることができます。 なぜ彼らがrootとして実行されているのかがわかります。 この場合、ユーザーが誰であるかを誰も設定していないので、デフォルトでrootになっています。 それを修正しましょう。 私たちは、 1、000 、 1 、または私たちの価値が私たちの会社で使用するものは何でも、これを実行することができます。 そして、そうすると、実際にパッチが生成されます。 右。 私はここに来て、Jiraやチケットシステムを開くと、クラスターに直接適用して先に進むことができる仕様を実際に含めることができます。 あるいは、もう一歩踏み込んでもいいかもしれません。 必要に応じて、実際にリポジトリに直接統合し、ワークフローで直接プルリクエストを開くことができます。
これの良いところは、繰り返しになりますが、私は誰かに「これらのものを直せ」と報告しているだけではないということです。 セキュリティの専門家は、価値はこうあるべきだと言っています。 この仕様を採用するか、この PR を確認してクラスターに適用することをお勧めします。
実行可能なイベント
ここでの目標は、設定ミス、イベント、環境で実際に目にしているものに関するすべての会話を、エンドユーザーが実際に実行できるようにすることです。 なぜなら、私たちが最も避けたいのは、人々が何もしないような大きくて巨大なレポートを提供することだからです。
ランタイム コンテキストの例では、これらの素晴らしく楽しいイベントがすべてインサイト ビューに表示されました。 しかし、そのようなもので実際に何ができるでしょうか? というわけで、ここでのイベントです。 さっそく探しに行こう。
私が見たいのはKubernetesのアクティビティの下にあると思うので、ターミナルに関連するものを探しに行きます。 ここには、ターミナルシェルとコンテナと呼ばれるイベントがあります。 これは、おそらく私たち全員が人生でやったことのあることです。 私たちは皆、コンテナに入り、シェルを開き、構成を変更しました。 ほとんどの場合、それで問題ないでしょう。 しかし、本番環境では、おそらくそのように行うべきではありませんよね? ですから、そのことを独自に意識し、そのような種類のイベントに注意する必要があります。 しかし、それが続いた場合、実際にはどうなるのでしょうか?
自分のイベントを調べてみると、いろんなことが起きているのがわかります。 特に探しに行きましょう。 私はここでこれを探しに行くことができます—私たちはそれを強調するだけです。 良い点は、私たちの世界でこれらのイベントを見つけた場合、インストゥルメントの方法はノードのかなり深いところにあるため、特にそれに関する多くのサポートデータが得られることです。 この場合、誰かがrootとしてシェルとしてログインしていることがわかります。 彼らは実行コマンドを実行し、Bashでいくつかのデータをプルダウンしました。 基本的に、やってはいけないことをたくさんやったんですよね。
これにより、すべてのプロセス全体をレビューできます。 しかし、プロセス名、それを実行した親プロセス、親を介して渡された引数、PID、何が起こったのか、誰がそれをしたのか、コンテキストが何であったのか、さらにはクラウドレベルのデータやKubernetesデータなど、あらゆる種類のメタデータについても、多くのコンテキストを取得することができます。
これが重要な理由は、イベントに関する堅牢なメタデータ セットを提供できれば、イベントを実用的なものにできるからです。 私は、この名前空間にあった、このユーザーによる、このポッドによる、これが何であれ、と言うことができます。 私はこれについて何かをしに行く必要があります。 私はこれを取りに行って、もっとやらなければなりませんよね。 これにより、イベントでかなりの量のデータを取得でき、実際にそれを使って何かをすることができます。 繰り返しになりますが、単に壁越しに何かを投げるのではなく、より多くのサポート特性を与えようとしています。
もう一つ、皆さんにとって非常に重要なことは、私たちがDockerで行っていることと、このランタイムデータやコンテキストのすべてをどのように取り込んで、より意味のあることをするのかということです。 脆弱性でこれを開始すると決めたのは、実行時にデータを再び取得し、それを使って何か斬新なことをする方法でした。 そのため、実行中のすべてのクラスタを確認し、設定ミスや、さらに重要なことに、それらのクラスタの脆弱性を、実際にどのようにデプロイされたかなどのコンテキストで探すことができます。
セキュリティの観点
ここでの良い点は、これがセキュリティの専門家や運用担当者にとって非常に役立つことです。 確かに、このインターフェース、この世界観は、開発者にとって最良のユースケースではありません。 開発者が来て、「これが実行されている環境で、どの名前空間でライブで見たいのか、そのコンテキスト内で脆弱性を探したい」というようなことはあまりありません。 そうする人もいるかもしれませんが、そこは彼らが住んでいる場所ではありませんよね。 これは開発者の日常ではありません。
Sysdigの視点から見ると、それは私たちが追いかけている人ではなく、Docker Scoutのような人が使っている人であり、他のベンダーが利用している人です。 そこで、ここにあるデータをすべて取り入れて、さまざまな方法で見るのを面白くしました。 「修正済み」とか「エクスプロイトあり」とか「使用中、修正済み」とか、そういうものを探しに行くことができます。
これにより、基本的には、多数の脆弱性を取り上げて、最も重要なもの、つまり現時点で最も重要なものに絞り込むことができます。 私はこれのレポートを生成し、それを人々に渡して作業に取り掛かることができるので、それは素晴らしいことです。 基本的に自分の時間に優先順位を付けることができます。 そうすることで、現時点で最も重要なことに集中できます。
しかし、この「使用中」のデータを取得して、開発者が実際に関心を持つワークフローにプラグインできたら素晴らしいと思いませんか? 彼らが作業しているターミナルに貼り付けて、ローカルでスキャンを行っていたり、ある種のIDEを使用したり、Docker Scoutプラグインを使用したり、日常生活で使用しているツールのようなものを貼り付けることができれば、それは彼らが日常生活で持っているある種のツールです。 それで何ができるのか、そこでどのように活用できるのか?
そのため、Dockerなどと提携して、このデータをプラットフォームから取り出し、開発者のプラットフォームに直接取り込むことで、開発者が分析を行うときに、「ああ、わかりました。このコンテナでは、コンテナまたはビルドしたイメージで実際に使用されているパッケージがわかります」と判断できるようにしました。 これらは私が気にする必要があるものです。 他のすべては、そのイメージから引き出す必要があります。 もうあんなことしなくていいのに。 もう修正する必要はないはずです。 私は特にこれらのものだけを気にすべきです。 ですから、システム側では、これはある種のものです。 それはすべて、運用担当者にアクセス権を与えるというこの特定のビューに関するものです。
開発者の視点
ScoutのDockerは、このデータを取得し、開発者の視点からより興味深いものに見せてくれました。 ですから、ここからはクリスチャンに任せて、そのことについて、彼らが持っているビジョンや、それが経験するサイクルについて、そしてそれを日常生活に取り入れる方法について、もっと話してもらいます。
ありがとう、アレックス。 その前に、実は皆さんに質問があります。 皆さんはどうやってこれを行いますか? 例えば、テキストパッケージデザインの背景にあるテクノロジーはどのようなものですか?
これに使用するテクノロジーは、実際のインフラストラクチャ自体で実行されるエージェントです。 これは、私たちがいるすべてのノードのカーネルをトラバースするすべてのシステムコールを調べます。 そして、これらの呼び出しをコンパイル中のライブラリとパッケージに関連付け、それらの呼び出しを自分で行っています。 コンテナで使用されているパッケージを正確に把握し、コンテナ自体のどこから来たのかを正確に知ることができます。 そして、それはすべてのエコシステム、すべての言語で機能します。
統合
質問に入る前に、この統合をどのように構築するか、そしてこれを使って今すぐ何ができるかについて少しお話ししたいと思います。 Sysdigには、私たちが呼び出すようなAPIがあります。 そして、その手始めとなるのは、 Docker Scout にログインすることです。 開始する場所は、統合セクションにあります。 そして、下にスクロールすると、ここにSysdigのタイルが表示されます。 そして、この特定のケースでは、このSysdigタイルが構成されているので、これを管理することができます。 新しいものを追加したいと言うことができます。 そして、Sysdigエージェント(Sysdigインフラストラクチャ)の設定方法を説明するドキュメントへのリンクが表示され、AlexがAPIを介して導入したランタイムインサイトを公開します。 そのため、APIトークンのようにプラグインする必要があります。 クラスター名と環境を選択すれば、良いスタートを切ることができます。
これを効果的に行うと、2 つのことが起こります。 ここで別の組織に切り替えましょう。 開発者がどこにエネルギーを注ぐべきかについてより良い選択をするために、Sysdigから収集しているものは2つあります。 これは基調講演で示したとおりです。 このビューには、組織内で誰かがプッシュしたすべてのイメージが効果的に一覧表示されます。 これは私のテストアカウントなので、バジリオン画像ではありません。
ここには、環境によって絞り込むために使用できるドロップダウンがあります。 今や環境は、Sysdigが私たちに伝えることができるものになりました。 これらのイメージは、特定のワークロード名として特定のクラスターで実行されています。 これらに名前を付けたり、論理的にグループ化したりできます。 つまり、このクラスターを本番環境、この他のクラスターをステージングと呼ぶか、Sysdigが報告した名前を維持することができます。 次に、リストを絞り込んで、開発者やこの種の情報に関心のある人々が、環境Xで現在実行されているイメージを非常に簡単に知ることができます。それはすでに大きな価値だと思います。 次に、さらに一歩進んで、使用中のパッケージ情報の出番です。
VEXの紹介
ここで一歩下がって、 VEXという概念について紹介したいと思います。 VEXはVulnerability Exploitation eXchangeの頭文字をとったものです。 これは、ソフトウェアのプロバイダーが、特定のパッケージ(サブコンポーネントを含む)のコンテキストで特定のCVEに関する情報を公開して、「影響を受けている、影響を受けていない、調査中」と表示できるようにする新しい仕様です。 したがって、たとえばNPMプロジェクトなどのDockerイメージのコンシューマに実際に指定できます。 いわば、影響を受けていることを確認しています。 そして、顧客や消費者に何を期待するかについて、インラインで声明を出すことができます。 次に利用可能なバージョンにアップグレードしてほしい、などと言うことができます。
この場合、この特定のCVEは、特定のDockerイメージのコンテキストで対処したいと思います。 そのDockerイメージの中で、私は1つの特定のパッケージを見ています。 Scoutは既にVEXをサポートしています。 VEXはデータベースにアップロードすることができ、内部的にも役に立ちます。 また、特定のCVEの影響を受けていないことを効果的に伝えたいとおっしゃる場合は、無視してかまいません。 すでに緩和策が講じられています。 または、たとえば、私が影響を受けていて、全員が次に利用可能な基本イメージ バージョンにアップグレードする必要があると言うことができます。 このテクノロジー、この統合を使用して、これらのVEXステートメントを自動的に作成し、Scoutオーガニゼーションにパブリッシュします。
Sysdigから得られるデータは、基本的にポジティブとネガティブのVEXステートメントにマッピングされます。 使用中のパッケージについては、これらのパッケージが使用されていると言えます。 Sysdigは、これらは実際にロードされ、ランタイムであるとのことでしたので、私たちは「大丈夫、あなたは影響を受けます」と言いました。 使用されていない他のパッケージについては、実行時に読み込まれないため、影響を受けないと言います。 そして、それはその時点からあなたが利用できるVEXステートメントです。
VEXは、これらのステートメントで何をするかを指定したり、強い主張をしたりしません。 あなたはそれらを受け入れる必要がありますか? これは、結局のところ、信頼と、これらの発言がどこから来ているのかということです。 私は彼らを信頼する必要がありますか? 受け入れる必要はありますか? Sysdigの場合、彼らが私たちの統合を購入し、これが使用されていないことを告げるとき、それは非常に強いシグナルであり、非常に強い意味を持っています。 誰かがDocker Hubやその他のレジストリに公開したインターネット上のランダムなVEXステートメントを信用しないでください。 この情報がどこから来ているのかを必ず検証してください。
オフィシャルイメージに関しては、Scoutの一員としてオフィシャルイメージチームと積極的に協力し、これらのイメージのVEXステートメントを提供しています。 もちろん、この特定のケースでは、これは信頼でき、Docker Scoutのインストールの一部であり、このデータを実際に調べる必要があります。
この情報を使用しようとすると、どのように見えますか? スカウトコマンドを実行できますが、これには実質的に2つの見方があります。 一番上までスクロールしましょう。 これは、ノイズに加えて、パッケージが使用中であることを示す非常に高いシグナルです。 その脆弱性を真剣に検討すべきですよね? つまり、下にスクロールすると、これはSysdigが構成されているクラスターにデプロイしたテストイメージの1つです。 そして、下にスクロールすると、基盤となるパッケージが実行時に読み込まれるため、これらのCVEを実際にすべて確認する必要があることがわかります。
これは、この「使用中のパッケージ」がここで示していることです。 これはSysdigの統合によるもので、そのCVEのパッケージの修正バージョンに更新することをお勧めします。 繰り返しになりますが、これはVEXステートメントです。 他のソースから入手することもできますが、この場合、Sysdigの統合を使用することで、ランタイム情報から直接取得することができます。 さらに下には、影響を受けていないビジーボックスがたくさんあることがわかるので、これはシェルです、それは必要ない、と言うのは非常に簡単です。 アレックスが言ったように、私はおそらくこれを削除する必要があります、または私が本当にそれを見始めるべきである別の指標を見るまで、これを無視しても問題ありません。
ここにはさまざまなフィルターオプションがあるので、ざっと見ることができます。 全部覚えてるわけじゃないんですけどね。 VEXの作者がいて、これは、コンシューマとして信頼したいVEXパブリッシャーを指定できる、という最初の試みです。 この場合、Docker/Sysdig integrationという文字列を入れると、Sysdigからのステートメントのみが受け入れられることになります。 ランダムなVEXステートメントが見つかったとしても、それは適用されないので、CVEは期待どおりに報告されます。 ローカルファイルシステムからVEXをロードする方法などもありますが、それはこの話の範囲外です。
ほぼ想定していた内容だと思います。 ご不明な点がございましたら、 質問はありません、すべては明らかです。 誰がこれを試しますか? 手の見せ方。 ワン、ツー、スリー、右。
結論
は じめにページ へのリンクを見つけることができるかどうか見てみましょう — それはおそらく役に立ちます。 Sysdigは無料でお試しいただけます。 Sysdigと連絡を取るためのフォームに記入してください。 とてもロータッチだと聞きます。営業担当者と直接話すことはできませんが、トライアルを受けて、そこから受け取っていきます。 セットアップは非常に簡単です。 すべてコンテナ化されているので、非常に簡単に進めることができ、製品をいじって楽しい方法で使用できます。 完ぺきですね。 ありがとうございました。
さらに詳しく
自分に合ったサブスクリプションを見つける
今すぐ専門家に連絡して、Dockerサブスクリプションのコラボレーション、セキュリティ、サポートの完璧なバランスを見つけてください。