コンテナーのセキュリティ対策を行っていますか？不正なクラウド リソースを管理するセキュリティ チームに所属している場合、コンテナー セキュリティが何かは知っているけれど、頭痛の種となるセキュリティ トリアージに関する悩みを軽減したいと思っているのではないでしょうか。
この投稿では、スケーラブルな環境でのコンテナーのセキュリティ、その環境へのデプロイがコンテナー セキュリティのロールアウトにどのように影響するか、また、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 のようなオンプレミス/インコロケーションのオプションなど、イメージ リポジトリに何を使用しているかを確認してください。レジストリのダイナミクスとセキュリティ管理によっては、1 つのツール オプションが他のものより理にかなっているかもしれません。例えば、AWS ECR は、静的脆弱性スキャンを提供する。他のいくつかのオプションは、イメージのソフトウェア構成分析 (SCA) スキャンもバンドルしています。
コツは、チームに適した S/N 比のツールを見つけることです。例えば、静的なスキャンは必要だけど、誤検知は最小限に抑えたい、除外項目を作成できる機能が欲しい、など必要事項に適しているか確認することです。
どの静的脆弱性スキャンツールと同様に、脆弱性の共通脆弱性評価システム (CVSS) スコアは出発点にすぎません。特定の脆弱性の悪用可能性、想定するリスク、攻撃対象領域、およびそれらの要因が、環境に大規模にデプロイされたイメージをアップグレードまたは変更した場合の潜在的な影響を上回るかどうかを判断できるのは、あなたとあなたのチームだけです。
言い換えれば、スキャン ツールの利用により、イメージの一部に (CVSS スコアリングによる) 存在する高度の、あるいは重大な脆弱性を検出する可能性があります。それでも、これらの脆弱性は悪用できないかもしれません。というのも、影響を受けるイメージは、外部からのアクセスがない環境内の仮想プライベート クラウド (VPC) の内部でのみ使用されるからです。ただし、イメージが内部に保持され、本番環境に使用されないようにする必要があります。したがって、そのイメージの使用とそれが内部ワークロードのみに留まるのを防ぐガードレール、監視、ゲートが必須です。
最後に、すべてのワークロードに浸透し、使用されているイメージを想像してみてください。 エンジニアリング チームが安全にデプロイするには、そのイメージをアップグレードする作業に数回のスプリント サイクルが必要となり、ライブラリの依存関係を解明するときにサービスのダウンタイムが必要になる場合があります。2 つの例 (内部専用イメージとアップグレードが困難な広範なイメージ) の脆弱性評価に関しては、前者では脆弱性の優先順位を下げ、後者は修正に向けた進捗状況をゆっくりと追跡することをお勧めします。
Docker のセキュリティ チームは、セキュリティ チームが直面する 2 つの最大の障害、時間とリソースについて熟知しています。特にチームがコンテナー セキュリティへの取り組みを始めたばかりの場合、本番環境、開発環境、ステージング環境全体にわたるすべての脆弱性を優先順位付けして修復できない可能性があります。 したがって、本番イメージに関してできること、また実行しなければならないことから始めましょう。
生産と非生産
適切な承認と自動化のワークフローを経たコンテナー イメージのみを運用環境にデプロイする必要があります。成熟した CI/CD ワークフローと同様に、これは、非運用環境での徹底的なテスト、運用環境にリリースする前にスキャンし、クラウド リソースのタグ付け、バージョン管理、運用環境へのイメージのデプロイを承認できるユーザーに関する適切なロールベースのアクセス制御などを使用して、既に運用環境に存在するイメージの監視とガードレールを意味します。
これは根本的には、これまでインフラストラクチャや DevOps チームのクラウド アカウントの作業に足を踏み入れたことのないセキュリティ チームがそうすべきであるということです。 DevOps 文化によって、開発者がクラウドでインフラストラクチャ、スケーリング、サービスの決定を処理する際に変化をもたらしたように、DevSecOps 文化とセキュリティ エンジニアリングを備えたセキュリティ コミュニティでも同じ変化が起こっています。 コンテナー セキュリティは、この交差点の真ん中に存在するようなことです。
この作業では、環境の環境にコンテナー セキュリティを最適化するという点でツールの選択が重要であるだけでなく、インフラストラクチャ、エンジニアリング、DevOps チームと協力する能力がさらに重要になります。繰り返しになりますが、本番環境のデプロイメントを適切に管理し、それらの本番環境のデプロイメントとリソースに関連付けられた適切な自動化と監視を行うには、セキュリティ チームがこの領域に慣れ、この交差点に慣れる必要があります。優れたツールは、特にこの分野に不慣れなセキュリティ チームにとって、コラボレーションの文化を育む上で大きな違いを生むのに役立ちます。
最適なコンテナー セキュリティ ツールは
よく考えられたツールの選択と同様に、最も重要なのは、ツールが提供する追加機能の数ではなく、ツールが組織のニーズやギャップに適合するかどうかである場合があります。
特効薬となると期待されるコンテナー セキュリティ ツールは避けてください。代わりに、チームが今日の小さな課題を克服し、将来のより大きな課題に向けて目標を構築するのに役立つツールを考えてください (セキュリティ関係者は、特効薬になると期待されている市場に出回っているツールは、単に何かを売っているだけであり、刻々と変化する脅威の状況では現実的ではないことを知っています)。
つまり、コンテナー セキュリティ用のツールは、エンジニアにとって不要な情報や視覚的な混乱をもたらすツールではなく、ワークフローを可能にして信頼を構築し、エンジニアリングからセキュリティ、DevOps に至るチーム間のコラボレーションを促進する必要があります。ここで Docker Scout が役立ちます。
Docker Scout とは
Docker は、コンテナーのセキュリティを強化するための製品である Docker Scout を提供しています。Scout は、コンテナー イメージで発見された脆弱性のリストを提供し、反復的な小さな改善スタイルで修復のためのガイダンスを提供します。あるデプロイメントから次のデプロイメントまでのスコアを比較し、改善を示すことで、克服不可能と思われる脆弱性やリスクの圧倒的な攻撃ではなく、チームに達成感をもたらすことができます。
Docker Scout を使用すると、イメージとマーカーの目標を設定して、反復的な改善を行うことができます。運用イメージと開発イメージまたはステージング イメージに対して異なる目標を定義して、各環境が必要なレベルのセキュリティを確保できるようにします。
結論
ほとんどのセキュリティ問題と同様、コンテナーのセキュリティにも特効薬はありません。企業のコンテナー イメージの保護に必要な技術的、運用的、組織的な要素は、多くの場合、チーム、機能、責任の間の境界に存在します。これにより、すでに複雑な問題がさらに複雑になります。この複雑さによって生じる負担をさらに増やすのではなく、チームが協力して、目標、リスク、優先順位がどこに重なり、共存するのかをより深く理解できるツールを探す必要があります。
さらに重要なことは、何が提供できるのかを明確にし、提供していない分野でもサポートを提供できるコンテナー セキュリティ ソリューションを探すことです。
DevOps とコンテナー セキュリティに取り組み始めたばかりのセキュリティ チームのメンバーであっても、これらのセキュリティ対策にしばらく携わっていたとしても、Docker はサポートを提供し、より安全で安定した開発環境の構築を支援します。 Docker は開発者の環境をより良いものにしようと努めています。
Docker Scout に関するご質問やデモのご要望は、エクセルソフトにお問い合わせください！
エクセルソフトは Docker の Preferred Reseller として、Docker Business を販売しています。2022 年 1 月 31 日以降、中・大規模組織による Docker Desktop の利用には有料サブスクリプションが必要となっています。詳細は、弊社 Web サイトをご確認ください。
*本記事は、Docker 社が提供している以下の記事から抜粋・転載したものです。
