コンテナのセキュリティについて考えていますか?たぶん、あなたは不正なクラウドリソースを管理しようとしているセキュリティチームに所属しています。 おそらく、DevOpsスペースで作業していて、コンテナのセキュリティとは何かを知っているが、関係者全員のセキュリティトリアージに関する苦痛を軽減する方法を見つけたいと思うでしょう。
この投稿では、スケーラブルな環境でのコンテナーのセキュリティ、その環境へのデプロイがコンテナー セキュリティのロールアウトにどのように影響するか、Docker がどのように役立つかについて説明します。
コンテナセキュリティとは
コンテナー セキュリティとは、環境で実行する コンテナー イメージ には、 Dockerfile で宣言したライブラリ、基本イメージ、カスタム ビットのみが含まれ、マルウェアや既知の脆弱性は含まれないことを認識することです。 (ゼロデイズも言いたいのですが、それが獣の性質です。
イメージとその背後にある基本イメージの構築に使用されるライブラリは、オープンソースであろうとなかろうと、予想されるソースからのものであり、重大な脆弱性、マルウェア、その他の驚きがないことを知りたいのです。
基本イメージは通常、一般的なイメージ ( Alpine Linux、 Ubuntu、 BusyBox など) であり、他の企業が独自のイメージ レイヤーを追加するためのビルディング ブロックです。 イメージレイヤーは、インストールプロセスのステップと考えてください。 基本イメージを取得し、作成のために新しいライブラリまたはステップを追加するたびに、基本的に新しいイメージが作成されます。
コンテナー セキュリティの最も直接的な部分であるイメージ レイヤーについて説明しましたが、イメージはどのように構築され、それらのイメージ レイヤーのソースは何ですか?
コンテナ画像の出所
ここで、コンテナーのセキュリティが難しくなります: イメージのビルドとソースの追跡プロセス。 イメージ、ライブラリ、および依存するベースイメージには、悪意のあるものではなく、期待どおりのものが含まれているという保証が必要です。 したがって、画像の出所、つまり画像が構築される場所、誰が構築するか、どこに保存されるかを気にする必要があります。
イメージの構築に使用されるインフラストラクチャや自動化 (通常は、GitHub Actions、AWS CodeBuild、CircleCI などの継続的インテグレーション (CI) ツールに注意する必要があります。 イメージ ビルドを実行するすべてのワークロードが、最小限のアクセスと潜在的な攻撃対象領域を備えたビルド環境上にあることを確認する必要があります。 たとえば、GitHub アクションランナーに誰がアクセスできるかを考慮する必要があります。 ランナーからクラウドアカウントへのVPN接続を作成する必要がありますか? その場合、そのVPN接続のセキュリティ保護は何ですか? イメージ パイプラインの機密性と整合性を慎重に検討してください。
より直接的に言えば、クラウドワークロードでコンテナの出所を管理すると、デプロイが容易になりますが、注意しないとマルウェアを大規模にデプロイすることも簡単になります。 クラウドの性質は、必ずしもセキュリティではなく、複雑さを追加することです。
ソフトウェア部品表 (SBOM) の構成証明は、必要なものだけがイメージ内にあることを確認するのにも役立ちます。 SBOM を使用すると、イメージのビルドに使用されるすべてのライブラリと依存関係の一覧を確認し、SBOM 構成証明を表示することで、バージョン管理とコンテンツが期待どおりであることを確認できます。 Docker Engine はこれ docker sbom を提供し、 Docker BuildKit は 0.11 より新しいバージョンでこれを提供します。
SBOM 構成証明に関するその他の考慮事項には、構成証明プロバイダーの信頼と、イメージ内のライブラリの置き換えなどの中間者攻撃からの保護が含まれます。 Docker は、イメージの署名付き SBOM 構成証明の作成に取り組んでおり、イメージ セキュリティのこの部分を強化するために、SBOM に関する強力な保証を作成します。
また、イメージに対するソフトウェア・コンポジション分析 (SCA) を検討して、オープン・ソースのツールとライセンスが期待どおりであることを確認する必要があります。 たとえば、Docker 公式イメージには、ベースイメージの背後に認定された出所のシールがあり、使用している可能性のあるベースイメージに関する保証を提供します。
脆弱性とマルウェアのスキャン
そして、潜在的なCVEとマルウェアはどうですか? これらの問題について、画像を大規模にスキャンするにはどうすればよいですか?
CVE スキャンには多数の静的スキャン ツールが用意されており、動的マルウェア スキャンを提供するツールもあります。 この分野のツールを調査するときは、 Docker Hub、Amazon Elastic Container Registry (ECR)、Artifact Registry、Nexus などのオンプレミス/インコロケーションオプションなど、イメージリポジトリに使用するものを検討してください。 レジストリに設定されているダイナミクスとセキュリティ制御によっては、あるツール オプションが別のツール オプションよりも理にかなっている場合があります。 たとえば、AWS ECR では、静的な脆弱性スキャンがすぐに使用できます。 他のいくつかのオプションは、画像のソフトウェア組成分析(SCA)スキャンもバンドルしています。
秘訣は、チームに適した信号対雑音の組み合わせを備えたツールを見つけることです。 たとえば、静的スキャンが必要で、誤検知を最小限に抑え、除外を作成する機能が必要な場合があります。
他の静的脆弱性スキャンツールと同様に、脆弱性の共通脆弱性評価システム(CVSS)スコアは出発点にすぎません。 特定の脆弱性の悪用可能性、考えられるリスク、攻撃対象領域、およびそれらの要因が、環境に大規模にデプロイされたイメージをアップグレードまたは変更した場合の潜在的な影響を上回るかどうかを判断できるのは、あなたとあなたのチームだけです。
つまり、スキャンツールは、一部のイメージで高いまたは重大な(CVSSスコアリングごとの)脆弱性を検出する可能性があります。 それでも、影響を受けるイメージは環境内の仮想プライベートクラウド(VPC)内でのみ内部的に使用され、外部アクセスがないため、これらの脆弱性は悪用できない可能性があります。 ただし、イメージが内部に残り、運用環境に使用されないようにする必要があります。 したがって、そのイメージの使用に関するガードレール、監視、およびゲーティングを行い、内部ワークロードにのみとどまる必要があります。
最後に、すべてのワークロードに浸透し、使用されているイメージを想像してみてください。 そのイメージをアップグレードする作業には、エンジニアリング チームが安全にデプロイするために数スプリント サイクルかかる場合があり、ライブラリの依存関係を解明するときにサービスのダウンタイムが必要になります。 脆弱性の評価については、内部のみのイメージとアップグレードが困難な広範なイメージの 2 つの例で、前者の脆弱性の優先度を下げ、後者の修復に向けた進行状況をゆっくりと追跡することをお勧めします。
Dockerのセキュリティチームは、セキュリティチームが直面する2つの最大の障害である時間とリソースに精通しています。 チームは、運用環境、開発環境、ステージング環境全体ですべての脆弱性をトリアージして修復できない可能性があります (特に、チームがコンテナー セキュリティの旅を始めたばかりの場合)。 ですから、あなたができることとしなければならないこと、つまりプロダクションイメージから始めましょう。
生産と非生産
適切な承認と自動化のワークフローを経たコンテナー イメージのみを運用環境にデプロイする必要があります。 成熟した CI/CD ワークフローと同様に、これは、非運用環境での徹底的なテスト、運用環境にリリースする前にスキャンし、クラウド リソースのタグ付け、バージョン管理、運用環境へのイメージのデプロイを承認できるユーザーに関する適切なロールベースのアクセス制御などを使用して、既に運用環境に存在するイメージの監視とガードレールを意味します。
根本的には、これまでインフラストラクチャやDevOpsチームの会社のクラウドアカウントの作業の海に足を踏み入れたことのないセキュリティチームがそうすべきであることを意味します。 DevOps 文化によって、開発者がクラウドでインフラストラクチャ、スケーリング、サービスの決定を処理する際に変化をもたらしたように、DevSecOps 文化とセキュリティ エンジニアリングを備えたセキュリティ コミュニティでも同じ変化が起こっています。 コンテナセキュリティが存在するのは、この交差点の真ん中です。
コンテナセキュリティを備えた環境のランドスケープに最適であるという点でツールの選択が重要であるだけでなく、インフラストラクチャ、エンジニアリング、およびDevOpsチームとのコラボレーション能力は、この作業にとってさらに重要です。 繰り返しになりますが、本番環境のデプロイを適切に処理し、それらの本番環境のデプロイとリソースに関連付けられた適切な自動化と監視を行うには、セキュリティチームがこのスペースに精通し、この交差点に慣れる必要があります。 優れたツールは、特にこの分野に不慣れなセキュリティチームにとって、コラボレーションの文化を育む上で大きな違いを生むのに役立ちます。
コンテナセキュリティツール:何を探すべきか
よく考えられたツールの選択と同様に、最も重要なのは、ツールが提供するベルやホイッスルの数ではなく、ツールが組織のニーズとギャップに適合していることです。
特効薬になることを約束するコンテナセキュリティツールは避けてください。 代わりに、チームが今日の小さな課題を克服し、将来の大きな課題の目標に基づいて構築するのに役立つツールを考えてください。 (セキュリティ担当者は、特効薬になると約束されている市場に出回っているツールは何かを売っているだけであり、絶えず変化する脅威の状況では現実ではないことを知っています。
要するに、コンテナセキュリティのためのツールは、ワークフローを可能にし、信頼を築き、エンジニアリングからセキュリティ、DevOpsまでのチーム間のコラボレーションを促進する必要があり、エンジニアにとってノイズや圧倒的なビジュアルの風景になるツールではありません。 そして、ここで Docker Scout が役立ちます。
ドッカースカウト
Dockerのエンジニアは、コンテナのセキュリティを強化するための新製品である Docker Scoutに取り組んでいます。 Scoutは、コンテナイメージで発見された脆弱性のリストを提供し、反復的な小さな改善スタイルで修復のためのガイダンスを提供します。 あるデプロイから次のデプロイへのスコアを比較し、改善を示すことで、克服できないと思われる脆弱性やリスクの圧倒的な砲撃ではなく、チームに達成感を与えることができます。
Docker Scout を使用すると、反復的な改善のために画像とマーカーの目標を設定できます。 運用イメージと開発イメージまたはステージング イメージに対して異なる目標を定義して、各環境が必要なレベルのセキュリティを取得できるようにすることができます。
結論
ほとんどのセキュリティ問題と同様に、コンテナのセキュリティに特効薬はありません。 会社のコンテナイメージを保護するための技術的、運用的、組織的な可動部分は、多くの場合、チーム、機能、および責任の間の境界にあります。 これにより、すでに複雑な問題が複雑になります。 この複雑さによって生じる負担をさらに増やすのではなく、チームが協力して、目標、リスク、優先順位が重なり合って共存する場所をより深く理解できるツールを探す必要があります。
さらに重要なことは、彼らがあなたに何を提供できるかについて明確であり、彼らが提供していない分野で助けを広げるコンテナセキュリティソリューションを探すことです。
DevOpsとコンテナセキュリティの海に不慣れなセキュリティチームメンバーであろうと、これらのセキュリティ水域にしばらく滞在している場合でも、Dockerはあなたをサポートし、より安定した水域に到達するのに役立ちます。 私たちはこの海であなたのそばにいて、私たち自身、私たちの顧客、そして世界中でDockerを使用する開発者のためにスペースをより良くしようとしています。
さらに詳しく
- Docker デスクトップの最新リリースを入手します。
- ドッカースカウトをお試しください。
- Docker のセキュリティについて学習します。
- ドッカー イメージの SBOM を生成します。
- SBOM 認証について学習します。
- Dockerの公式画像をチェックしてください。
- Docker Hub にアクセスします。
- 次のものに投票してください! 公開ロードマップをご覧ください。
- 質問がありますか? Docker コミュニティがお手伝いします。
- ドッカーは初めてですか? 始めましょう。
フィードバック
「コンテナのセキュリティとそれが重要な理由」に関する0の考え