Everything You Need to Know to Get Started With Container Security

コンテナの利用はここ数年間で飛躍的に増加しています。コンテナテクノロジーは数十年前から存在していますが、企業でコンテナファーストの開発や運用モデルの導入が具体化したのは、2013 年に発売された Docker がきっかけでした。

この増加には、セキュリティ上のリスクも伴います。何百万ものイメージから選択できるため、コンテナのセキュリティを確保するには専門技術が求められます。コンテナに適用されるセキュリティには、次のような多くのレイヤーがあります。

• 内部のコンテナイメージとソフトウェア

• コンテナ、ホスト OS、ホスト上の他のコンテナとの連携

• ホスト OS

• コンテナネットワークとストレージリポジトリ

• ランタイム環境 (ほとんどの場合は Kubernetes クラスター)

各レイヤーにそれぞれガイドが必要なため、このガイドでは最初にイメージとコードに焦点を当てます。1 つのコンテナイメージには数百件から数千件の脆弱性が含まれている可能性があり、組織ではセキュリティインシデント (データ侵害など) や生産性の低下 (使用するイメージの増加に伴って、脆弱性のトリアージから評価までにかかる時間の長期化) が生じるおそれがあります。

コンテナセキュリティとは

従来、アプリケーションセキュリティは専門のセキュリティチームが担当していましたが、コンテナの定義とビルドの方法によって、その責任は開発者や DevSecOps チームに委ねられるケースが多くなっています。

このような責任の移転に加えて、コンテナのアップデートやデプロイを時短化するには、CI でコンテナをスキャンし、イメージのベストプラクティスに従って、何百もの脆弱性を発見するスキャンに対処する以上の、具体的なセキュリティの方法論が求められます。

以前、私たちは Docker のコンテナセキュリティのガイドを作成しました。実践的なガイダンスについては、コンテナイメージを保護するための 3 つの具体的な手順をご確認ください。今回の記事では、安全なコンテナイメージのビルドとコンテナの実行のために企業で行われている DevSecOps のプラクティスの概要を説明し、Snyk Container、Snyk IaC、およびSysdigとの提携など、開発から実行まで包括的なコンテナセキュリティを提供する技術ツールを紹介しています。

コンテナのセキュリティが重要となる理由

コンテナセキュリティが重要となるのは、コンテナイメージに最終的にアプリケーションを実行することになるすべてのコンポーネントが含まれているためです。コンテナイメージに脆弱性が潜んでいると、本番環境でのセキュリティ問題のリスクと潜在的な深刻度が高まります。そのため、本番環境もモニタリングする必要があります。イメージの作成は脆弱性や権限の昇格なしでもできますが、発生している事象のランタイムモニタリングを行う必要はあります。

さまざまなエコシステムにおけるコンテナセキュリティの概要

Docker コンテナのセキュリティ

数千万人のユーザーと数千億件のイメージプルという Docker の膨大なユーザーベースは、アプリケーションの開発方法がコンテナ化によって変わりつつあることを示しています。セキュリティの責任はますます開発者側に移ってきています。Linux パッケージ、ユーザー権限、ネットワーク設定、オープンソースツール、またはアクセス管理の脆弱性を見つけて修正するために、Docker イメージをスキャンしてから Docker Hub や他のレジストリにプッシュすることが重要です。このようなスキャンは、出荷前にアプリケーションとインフラの脆弱性の問題を発見して対策を講じるのに役立ちます。

Kubernetes コンテナセキュリティ

Kubernetes は、クラスター、ワークロード、およびコンテナの安全性を高めるのに役立つ無数のセキュリティコントロールを提供します。注意すべき点として、Kubernetes をデプロイする際には、セキュリティコントロールは一切設定されないため、Kubernetes では自身で設定を行う必要があります。さらに、Kubernetes は安全なクラスターの作成に役立つコントロールや機能を提供していますが、多くの場合、デフォルトのセキュリティ設定だけでは十分ではありません。ワークロードを安全にデプロイするには、Kubernetes の専門知識が必要です。詳細については、Kubernetes セキュリティのベストプラクティスに関するページをご覧ください。

GKE コンテナセキュリティ

Google Kubernetes Engine (GKE) は、ワークロードを保護する多数のツールを提供しています。GKE のセキュリティは、アクセスコントロール、ワークロード、およびその他のセキュリティ機能の設定により、レイヤー方式で確保することをお勧めします。GKE は、基盤となるインフラストラクチャを管理する標準モードと、GKE がインフラをプロビジョニングして管理するオートパイロットモードで実行できます。Snyk コンテナの Kubernetes との統合により、ユーザーは GKE のワークロードのセキュリティ確保を標準またはオートパイロットで実行し、コンテナイメージとアプリケーションコードの両方で脆弱性を発見し、Kubernetes 設定をスキャンして問題を検出できます。

AKS コンテナセキュリティ

Microsoft Azure Kubernetes Service (AKS) は、GKE と同様に、Azure Policy との統合や常に高速なアップデート/パッチなど、堅牢なセキュリティ機能を備えています。ただし、クラスターコンポーネントを新しいバージョンにアップグレードするには半手動のプロセスが必要となり、クラスターの作成時にネットワークポリシーを有効にする必要があります。GKE と同様、Snyk では Kubernetes 設定 とコンテナをスキャンし、AKS リソースをデプロイする際に自動モニタリングを有効にできます。

EKS コンテナセキュリティ

Amazon Elastic Kubernetes Service (Amazon EKS) は、強力なセキュリティ機能をデフォルトで備えており、AWS の共有責任モデル (コンテナセキュリティのさまざまな要素に誰が責任を持つかを定義するモデル) で運用されています。通常、AWS はクラウド「自体」のセキュリティに責任を持ち、お客様はクラウド「内部」のセキュリティに責任を持ちます。  上記の他の Kubernetes オプションと同様、Snyk は Amazon EKS や Amazon Elastic Container Registry (Amazon ECR) と簡単に統合でき、Kubernetes 設定とコンテナをスキャンし、Amazon EKS にデプロイする際に自動モニタリングを有効にすることができます。

コンテナセキュリティについての 5 つのベストプラクティス

安全なコンテナイメージの作成には、5 つの重要なステップがあります。これらをもう少し詳しく検討して、このアプローチで安全なコンテナイメージを作成する方法について確認しましょう。

1. コードと依存関係のセキュリティを確保する

2. 信頼できるソースの最小限のベースイメージから始める

3. ベースイメージとコードの間のすべてのレイヤーを管理する

4. アクセス管理を使用する

5. コンテナインフラのセキュリティを確保する

1.コードと依存関係のセキュリティを確保する

コンテナ化は、クラウドネイティブアプリケーションをよりすばやく提供できる方法です。そもそもコンテナを作成する理由の 1 つはその点です。コンテナによってアプリケーションコードの意味が拡張されたとはいえ、開発者によって最も直接的にコントロールできるのがコードであることに変わりはありません。オープンソースの依存により、簡単にプロプライエタリコードを少なくできるため、ソフトウェア構成分析 (SCA) および静的アプリケーションセキュリティテスト (SAST) ツールと統合スキャンを実装してコードと依存関係の分析プロセスを自動化することが重要です。また、コンテナをスキャンして Git のコミットやリポジトリの問題を直接キャッチすることもでき、開発プロセスによっては、この方が適しているかもしれません。

2.信頼できるソースの最小限のベースイメージから始める

携帯性や高速ダウンロードのためにはサイズを小さくすることが重要ですが、脆弱性の原因となる可動部の数も少なくできます。各コンテナイメージには、作成したコードと、アプリケーションを実行するために必要な最小限の追加パッケージを含めることが理想的です。ただし、実際には多数のアプリケーションが存在することになるため、コンテナイメージを管理しやすくするための妥協点を探る必要があります。

ベースイメージの選択については、コンテナのベースイメージをホスティングしている信頼できるベンダーが多数存在します。圧倒的に人気があるのは Docker Hub で、利用可能なイメージは 380 万以上、リポジトリは 700 万以上、月間約 110 億回のプルがあります。Docker のオープンソースや「ドロップイン」ソリューションのリポジトリとして、Docker がまとめたセットとして公開している Docker 公式イメージもあります。Docker では、Verified Publisher (認証済み管理者) によって直接管理される高品質のイメージも提供されています。Verified Publisher に関する Docker のガイドラインは、独自のコンテナイメージのベストプラクティスを定義する際の絶好の出発点となります。

Docker Hub にアクセスし、公開されているイメージの中から自分のユースケースに一致するものを見つけるのは簡単ですが、それが Docker の公式イメージプログラムからのものか、Notary などのデジタル署名をチェックしてソースとコンテンツを確認できるかなど、その出所に注意を払い、ある程度の品質保証を管理することが重要です。

3.ベースイメージとコードの間のすべてのレイヤーを管理する

ベースイメージには特別な配慮が必要です。ベースイメージに含まれるものはすべて、その上に自分のイメージを構築する際に継承されます。たとえスリムなイメージで始めたとしても、コードに加えてツールやライブラリを追加し、必要なインストールを行わないと動作しない可能性があります。これらすべての脆弱性をモニタリングする必要があります。

この中間レイヤーは直接コントロールできるのが良いところです。ただし、開発、テスト、および本番環境へのデプロイと、注意を向ける場所に優先順位を付けることが重要です。それぞれの段階で必要なツールは異なるかもしれませんが、イメージが本番に向かうにつれて、絶対に必要でないものはすべて取り除いていきます。

最小限のベースから始めて、必要なツールだけを追加することで、後でこれらのツールを Dockerfile から取り出してリビルドするだけで、簡単に削除できます。また、マルチステージビルドを使用して、これらのすべての段階を単一の自動ビルドプロセスに取り込むこともできます。また、中間レイヤーにインストールされているツールやサポートパッケージに脆弱性が発見されることもありますが、本番環境のイメージに含めない場合は無視しても問題ありません。マルチステージビルドのその他のベストプラクティスについてのブログ記事もご覧ください。

4.アクセス管理を使用する

コンテナのコンテキストでは、アクセスとは特定のユーザーが特定のコンテナリソースに対して特定の操作を実行できることを意味します。一般的なアクティビティは、作成、読み取り、更新、または削除 (CRUD) 操作に分類されます。アクセス管理の詳細は、コンテナのプラットフォームによって異なります。たとえば、Kubernetes では、ユーザーはクラスターの外に常駐しています。つまり、管理者は、TLS 証明書、OAuth2、またはその他の認証方法を使用して、クラスターの外で ID を管理する必要があります。

シークレットとネットワークアクセスは、最小権限の原則に基づいて運用します。管理者アクセスは、インフラの構築に限定します。コンテナがすべてのリソースに完全にアクセスすることを防止するには、コンテナに特定の役割と責任を割り当て、その役割を促進、強化、およびモニタリングするツールを使用します。

5.コンテナインフラのセキュリティを確保する

コンテナイメージや実行中のコンテナのセキュリティを確保するだけでなく、コンテナの実行に必要なインフラスタックを管理する必要があります。これには、Docker Hub のようなコンテナレジストリから Kubernetes による本番環境のオーケストレーションまで含まれます。

コンテナレジストリは、コンテナの保存・共有のための安全な場所を作成して共同作業を促進するように設計されていますが、脆弱性やマルウェアが入り込み、シークレットが公開されてしまうことがあります。多くの場合、セキュリティ機能が組み込まれており、レジストリに接続するときは常に TLS などのセキュリティプロトコルを使用します。  同様に、Kubernetes には、クラスターとネットワークの両方のレベルでセキュリティコントロールを作成して適用するためのツールが含まれています。詳細については、コンテナレジストリのセキュリティに関する記事をご覧ください。

コンテナは、常に安全なシステムまたはクラウドサービスで実行する必要があります。サービスの場合、レジストリへのアクセスにはロールベースのアクセス制御 (RBAC) を使用する必要があります。

もうひとつ、ハッカーは CI/CD パイプラインの初期段階に注目しています。開発初期段階のセキュリティ確保を怠らないようにしましょう。アプリケーションとコンテナを開発するときは、アプリケーションで使用する前、そしてデプロイメントの前にコードをスキャンすることが重要です。さらに、最小権限の原則 (POLP) を適用し、開発パイプラインでセキュリティチェックとコントロールを自動化することが重要です。

Snyk コンテナを使用してコンテナを保護する

コンテナには何百万もの脆弱性が存在するため、脆弱性を発見して優先順位を設定し、対策を実施することは開発者にとって大きな負担となっています。Snyk コンテナでは、コンテナで実行されている元のソースコードにアクセスできない場合でも、アプリケーションとコンテナの脆弱性を一緒に検出して修正することにより、一般的な脆弱性レポートのノイズをカットできます。

Snyk コンテナは常に新しい脆弱性をスキャンし、コンテキストと悪用の可能性に基づいて修正に優先順位を設定し、オープンソースの依存関係の問題を明らかにし、脆弱性を Dockerfile コマンドとマッチングすることで、開発者が修正を導入しやすくしています。2021 年には 1 億 3000 万件を超えるコンテナテストで Snyk コンテナが使用され、5600 万件の脆弱性が Snyk コンテナユーザーによって修正されました。

Snyk コンテナは、Snyk IaC と連携してコンテナの設定のセキュリティを確保でき、AKSや GKE など多数の Kubernetes プラットフォーム、Docker Hub、GCR、Quay などのコンテナレジストリ、Amazon Linux や Ubuntu その他多数のコンテナベースの OS と統合できます。脆弱性スキャンの統合により、開発者は適切な最小限のベースイメージを識別して使用でき、アップデートプロセスを自動化して脆弱性をすばやく除去できます。

Snyk コンテナは、他の Snyk プラットフォームと同様に、開発者ファーストのアプローチで構築されており、DevSecOps のカルチャーをサポートしています。IDE に統合し、マージ前にプルリクエストをスキャンし、修正のガイダンスを提供し、自動テストを CI/CD パイプラインに適用することができます。コンテナを実行すると、既存の脆弱性や新たに公開された脆弱性にさらされていないか、デプロイメントが継続的にモニタリングされます。その後、アラートは Slack、Jira、メール、またはその他の方法で送信され、DevSecOps で脆弱性をすばやく特定して対策を講じることができます。

Snyk と Sysdig の提携がもたらすコンテナランタイムセキュリティ

Snyk コンテナの早期イメージフィードバックでは、70% 以上の脆弱性を排除できますが、ランタイムの脆弱性の 30% は未知のまま残る可能性があり、数百件もの脆弱性が、数千のコンテナと無数のクラスタに存在する場合もあります。これらの脆弱性を発見し、修正するのは骨の折れる作業です。実行中のコンテナでどのパッケージが使われているのか、実行されたパッケージにどのような脆弱性があるのかをランタイムで見分けることは困難です。本番環境を管理するセキュリティチームと運用チームは、開発チームに脆弱性の修正を依頼する前に、まず脆弱性を発見しなければなりません。また、開発者はシステムの専門知識を持っていないため、従来の脆弱性ツールでは問題を見つけて修正するのに数か月かかることもあります。

Snyk は Sysdig と提携し、何がランタイム環境に影響を与えているかについて、より多くのコンテキストを提供することで、ランタイム環境の問題解決を支援しています。この提携により、DevOps の全プロセスにわたるセキュリティソリューションが実現します。Snyk と Sysdig プラットフォームの組み合わせにより、開発環境のコードからクラスターを実行するインフラまで、すべてのセキュリティを確保できます。

Snyk と Sysdig の提携により、コンテナのセキュリティがランタイム環境にどのように拡張されるかについては、この発表の記事をご覧ください。

コンテナセキュリティのまとめ

コンテナセキュリティは幅広いテーマで、ベースイメージのセキュリティについてだけでも、検討すべき課題は数多くあります。イメージのセキュリティの確保については、以下の留意点があります。

• 信頼できるプロバイダーのベースイメージを使用し、デジタル署名で信頼性を検証します。

• 基本的なオペレーティングシステムパッケージと選択したフレームワークのみを含む最小限のベースイメージを選択し、それを基に構築していきます。

• イメージの脆弱性は早期に、また頻繁にチェックします。

• デスクトップ、CI、レジストリに保存されたイメージ、クラスターで実行されているコンテナなど、ソフトウェアのライフサイクル全体をスキャンします。

• スキャンツールを選ぶ際は、スプレッドシート形式の基本的な脆弱性レポートにとどまらず、軽減策のアドバイスやベースイメージの推奨など、問題の修正に役立つ情報を開発者に提供し、セキュリティゲートの構成に必要な柔軟性のあるものを選びましょう。

コンテナイメージのライフサイクル全体でセキュリティを確保する場合、Snyk コンテナは、開発者ファーストでコンテナセキュリティを自動化し、セキュリティと生産性の適切なバランスを図ることで、イメージと実行コンテナのセキュリティを高めるのに役立ちます。

コンテナセキュリティの用語集

• コンテナスキャン:コンテナイメージ内のパッケージと依存関係をスキャンして、コンテナの脆弱性を発見するプロセス。

• コンテナモニタリング: コンテナ化されたアプリケーションやアーキテクチャの指標の収集と健全性の追跡管理。

• Kubernetes: クラスタ全体でコンテナ化されたアプリケーションをオーケストレーションするために、もともと Google で開発されたオープンソースシステム。

• K8s:Kubernetes の略称。

• Docker: 世界で最も普及しているコンテナプラットフォーム。Docker は、コンテナの作成と実行に関するツールやプロセスを民主化し、開発者がこれらのテクノロジーを簡単に使えるようにしたものです。

• Dockerfile: Docker イメージをビルドするために必要な設定を含むテキストファイル。

• Google Kubernetes Engine (GKE): GKE は、Google Cloud 上で Kubernetes のワークロードを実行するための Google の管理サービスです。

• AKS: Microsoft Azure のマネージド Kubernetes サービス。当初は汎用的な Azure Container Service としてスタートし、Kubernetes がコンテナオーケストレーションプラットフォームとして主流になった時に AKS に進化しました。

• AWS EKS: AWS 上で Kubernetes ワークロードを実行するための、Amazon Web Service のマネージド Kubernetes サービス。AWS EKS は、単独で使用することも、AWS Fargate などの他のサービスと組み合わせて使用することもできます。AWS Fargate では、基本的にすべての Kubernetes インフラが隠され、ユーザーは自分の Kubernetes ポッドだけに集中できます。

• コンテナイメージ: 実行中のコンテナを作成するための一連の命令を含む静的ファイル。

• コンテナレジストリ: コンテナイメージの保存と共有を容易にするコンテナイメージリポジトリおよび管理ツール。

• コンテナランタイム: ホスト OS 上でコンテナを作成、実行、管理するソフトウェア。

• シフトレフト: 開発ワークフローにセキュリティを組み込むカルチャーと一連のツール。

• DevSecOps: DevSecOps とは、開発、セキュリティ、運用の略で、ソフトウェアのデリバリーライフサイクルにおけるセキュリティを自動化するアプローチです。

コンテナセキュリティについてのよくある質問