ブログ

Sysdig 2020 コンテナセキュリティのスナップショット:主要なイメージスキャンと構成の洞察

Sysdig 2020 コンテナセキュリティのスナップショット:主要なイメージスキャンと構成の洞察

本文の内容は、2020年8月17日にPawan Shankarが投稿したブログ(https://sysdig.com/blog/sysdig-2020-container-security-snapshot/)を元に日本語に翻訳・再構成した内容となっております。

本日、Sysdig 2020 Container Security Snapshotをご紹介します。

コンテナやKubernetesの採用が増え続ける中、クラウドチームは、DevOpsプロセスにセキュリティを組み込む新しいワークフローを採用する必要があることを認識しています。

DevSecOpsの一種であるSecure DevOpsは、開発から本番までのアプリケーションのライフサイクル全体にセキュリティと監視を組み込むものです。これにより、安全で安定した高性能なアプリケーションを提供することができます。このワークフローは、既存のツールチェーンにプラグインし、DevOps、開発者、セキュリティチーム全体に単一の真実のソースを提供し、効率を最大化します。

本番環境でコンテナを実行している実際のお客様の環境を観察して得られたセキュリティの洞察については、こちらをご覧ください。

トップの配布イメージは何ですか?

最新のソフトウェアは、ゼロから構築されたものではなく、組み立てられたものです。開発者はコンテナ化されたアプリケーションを構築する際に、様々なLinuxディストリビューションのオープンソースベースのイメージを使用するのが一般的です。

Sysdigがスキャンした10万以上のイメージから収集したデータによると、Alpineが現在の開発者に最も人気のあるイメージであることが明らかになりました。これは、Alpineが最小限のフットプリントで知られているからです。しかし皮肉なことに、私たちが見つけた実行中の最大のイメージは、10GBのAlpineベースのイメージでもありました。

20200818-01.png

イメージのサイズはどのくらいですか?

イメージサイズはアプリケーションによって異なりますが、私たちのデータによると、平均的なイメージサイズは376MBです。10GBの大きなアルパインイメージは例外的なものと思われます。大きなイメージは、デプロイメントに時間がかかり、リリース速度が遅くなるだけでなく、攻撃の機会を増やすことにもなります。

20200818-02.png

イメージの一部はいくつのレイヤーで構成されていますか?

Dockerイメージはいくつかの不変のレイヤーで構成されており、それぞれのレイヤーには固有のハッシュIDが付与されています。各レイヤーはDockerfile内の特定の命令に対応しています。これらのレイヤーは、Dockerイメージのビルド中にDockerfile内の命令が実行されると生成されます。

私たちが見ることができるのは、与えられたイメージの平均レイヤー数はおよそ〜9.5であるということです。野生で観測された最大レイヤー数は107でした! (例えば、Dockerfile内のRUN/ADD/COPYコマンドを使って)レイヤーを追加すると、ビルドプロセスのパフォーマンスに影響を与えたり、デバッグが困難になったりします。

20200818-03.png

サードパーティのトップライブラリは何ですか?

開発者は、アプリケーションのビルドやデプロイの際に時間を節約するために、オープンソースのサードパーティライブラリ(非OSパッケージ)からコードを引き出すこともあります。私たちのデータによると、npm は最も人気のあるオープンソースの非OS パッケージです。

20200818-04.png

一般的にイメージはどこから取得されるのですか?

公開されているソースからのイメージは、セキュリティ上の脆弱性をチェックしているものがほとんどないため、リスクが高い場合があります。例えばDocker Hubは、約300万のホスティングされたイメージのうち1%未満を認証しています。しかし、イメージの40%がパブリックソースから抜かれていることがわかりました。

20200818-05.png

どのような種類の脆弱性を考慮しますか?

OSの脆弱性スナップショット。OSの脆弱性のうち、4%が高レベルまたは重大な脆弱性であることがわかりました。これは低いと思われるかもしれませんが、OSの脆弱性が悪用されると、イメージ全体が危うくなり、アプリケーションがダウンしてしまう可能性があります。このため、特にレジストリスキャンの一部としてこの機能を提供しているクラウドプロバイダー(ECR、GCRなど)では、OSの脆弱性をスキャンすることに重点が置かれています。

20200818-06.png

非OSの脆弱性スナップショット:多くのチームがチェックしていないのは、サードパーティ製ライブラリの脆弱性です。非 OSパッケージの 53% に高レベルまたはクリティカルレベルの深刻度の脆弱性があることがわかりました。開発者は無意識のうちに、Python PIPやRuby Gemなど、これらの非OSオープンソースパッケージから脆弱性を引っ張ってきて、セキュリティリスクを導入している可能性があります。

20200818-07.png

リスクの高い設定はどれくらい多いのか?

チームは脆弱性をスキャンする必要性を理解していますが、一般的な設定ミスをスキャンしていない可能性があります。私たちが確認したのは、58% のイメージが root として実行されており、特権コンテナが侵害される可能性があるということです。

20200818-08.png

当社の顧客に話を聞くと、実際には、実行時に危険な設定が検出されたとしても、チームは迅速なデプロイを継続するためにコンテナを停止することはありません。その代わりに、猶予期間内に実行し、セキュリティポリシーからの逸脱を継続的に監視します。

まとめ

今年のデータを見直すと、特に広く採用されているオープンソースのコンポーネントを考えると、DevOpsチームにとってセキュリティを最重要視する必要があることは明らかです。

主要なデータでは、CI/CDパイプラインの早期スキャンの重要性が強調されており、OSパッケージの脆弱性とOS以外の脆弱性の両方について、53%が高/重要度が高い/重要度が高いという結果が出ています。イメージの58%はroot としても実行されており、チームは実行時にコンテナを継続的に監視し、そのようなリスクの高い設定を検出して防止するためのセキュリティメカニズムを実施する必要があります。

チームは最終的に、Secure DevOps ワークフローを採用して、コンテナのライフサイクル全体でセキュリティに確実に対応する必要があります。詳細については、Secure DevOpsを始める方法を読むか、Sysdigの30日間無料トライアルに申し込むことができます。

関連コンテンツ

ご質問・お問い合わせはこちら

top