DevOps におけるコンテナ セキュリティの 9 つのベスト プラクティス

DevOps におけるコンテナーは新しい概念ではありません。これらは、大規模なアプリケーションを含むマイクロサービスを実行するために必要なツールをすべて備えた仮想サンドボックスです。

コンテナは、(開発者として) ランタイムやバイナリ コードなど、アプリケーションの実行に必要なものすべてを一元的に保存できるパッケージング システムと考えることができます。

コンテナは、開発者がアプリケーションをある環境から別の環境に移動するのに役立ちます (アプリをローカル マシンから仮想環境に移行したり、初期段階から運用段階に移動したりするなど)。これにより、開発者と運用環境のさまざまなソフトウェアや構成設定に関連するすべての問題が排除されます。終わり。

コンテナ テクノロジーに関する Statista の レポートによると、世界の組織の 50% がコンテナ オーケストレーションを採用しています。この技術はその利点に基づいて採用が増加していますが、コンテナを放置しておくとサイバーセキュリティ攻撃のゲートウェイを開く可能性があります。

典型的なセキュリティ脆弱性データ ソースである CVE 詳細 には 、この記事の執筆時点で 62 件の Docker に合わせた脆弱性が 記録されています。これには、これらの落とし穴に対処し、DevOps プロセスを成功させるためにコンテナを保護するための開発者のベスト プラクティスが必要ではないでしょうか?

この投稿では、コンテナーのセキュリティの概念を詳しく説明し、いくつかの課題に焦点を当て、コンテナー テクノロジーを使用する際に実行すべきベスト プラクティスについて説明します。

コンテナセキュリティとは何ですか?

コンテナのセキュリティは、セキュリティ プロトコル (ツールとポリシー) を使用してコンテナとその環境を潜在的な脅威から保護する継続的なプロセスです。

チェックを外した場合、脅威はアプリケーション、そのインフラストラクチャ、ランタイム、システム ライブラリ、オペレーティング システム、カーネルなどの機能に損害を与える可能性があります。

コンテナーは一時的 (瞬間的) に利用可能であり、動的なデプロイメントとスケーリングも目的としていることを考慮すると、自動化されたセキュリティーとソフトウェア開発ライフサイクル (SDLC) のすべての段階が必要になります。

こちらもお読みください: 初心者のための Kubernetes Kops の概要

コンテナセキュリティにおける課題は何ですか?

コンテナには多くのメリット (ソフトウェア配信の高速化など) がありますが、主にセキュリティ対策が必要なため (自己セキュリティ機能が欠如している)、課題に無縁ではありません。

これは、コンテナーがホストされたオペレーティング システム (OS) を通じてハードウェアにアクセスするためです。これは、1 つのコンテナーに複数の基盤となるコンテナー イメージが含まれる可能性があることを意味し、攻撃対象領域の範囲が広がり、いくつかの課題が生じます。

1 つ目は 、不正なコンテナ構成です。 開発者はカスタマイズを忘れてデフォルトのコンテナ構成を使用します。これには、アプリケーションにとって理想的ではない可能性のある安全でないポートが公開されている、パスワードや認証トークンなどの資格情報が漏洩している、アクセス許可を過剰に発行しているなどのいくつかの落とし穴があります。コンテナー ランタイム (root として実行する場合)。これらのデフォルト設定をオーバーライドしないと、攻撃の手段が提供されます。

次に コンテナインフラの脆弱性 です。ここでは、アプリケーション コード、ライブラリ、構成などのコンテナに組み込まれたパッケージ、またはホスト オペレーティング システム上のパッケージが脆弱性を引き起こします。脆弱性は、アプリケーションのライフサイクルのどの段階でも発生する可能性があります。たとえば、外部の依存関係がコンテナー イメージに組み込まれている場合、オープンソース ライブラリがアプリケーションの一部としてインストールされている場合、コンテナーのベース イメージがサードパーティのコンテナー レジストリおよびホストから取得されている場合などです。ネットワークやエンドポイントを通じて悪用可能です。

コンテナのワークロードの可視化は、 コンテナの最大の課題の 1 つです。これは、コンテナーの非常に動的な性質により、監視ツールがどのコンテナーが実行されているかを特定したり、そのネットワーク動作を検査したりすることができないためです。視認性の向上により侵害が防止され、侵害が発生した場合の対応時間が短縮されます。

さらに、アプリケーション コードまたはコンテナ ワークロード インフラストラクチャのいずれかで、 CI/CD パイプラインのいずれかのフェーズが安全でない場合、 コンテナは影響を受けやすくなります。開発者がアプリケーションのライフサイクルの最後にセキュリティに取り組むのは一般的ですが、開発のあらゆる段階でセキュリティを管理することで、アプリケーションをこの後退から守ります。

コンテナセキュリティの課題を解決できるツールはどれですか?

セキュリティ ツールを使用してコンテナのセキュリティと整合性を確立することで、デプロイされたエンタープライズ ソリューションの安全性を確保できます。これらのツールは脆弱性をスキャンし、攻撃、バグ、または問題がないか常に監視します。

オープンソースのコンテナ セキュリティ ツールを探している場合でも、商用化されたタイプのコンテナ セキュリティ ツールを 探している場合でも、目的はすべて同じです。これらはすべて、コンテナー インフラストラクチャを監査し、一般的な脆弱性とエクスポージャ (CVE) に対して実行することによって動作します。

ここでは、Pingsafe Editors Choice、Datadog Cloud SIEM、Anchore、Sophos Cloud-Native Security、Bitdefender GravityZone、Sysdig secure、Aqua Security、RedHat Advanced Cluster Security for Kubernetes など、試すことができるツールをいくつか紹介します。

こちらもお読みください: 脆弱性を見つけるための 11 のコンテナ セキュリティ スキャナ

コンテナセキュリティのベストプラクティス

コンテナのセキュリティには上記のような課題がありますが、アプリケーションのライフサイクルのすべての段階でコンテナのセキュリティを最適化するために実装できる最良の規則の内訳を以下に示します。

画像の保護

コンテナーを作成するには、コンテナー イメージを使用します。わずかな構成ミスや悪意のあるアクションによって、運用中のコンテナに脆弱性が引き起こされる可能性があります。これに対抗するには、次のようにします。

• 信頼できるイメージを使用する – イメージを最初から作成しない場合は、常に信頼できるソースからのイメージを使用することを選択します。 Docker Hub などのパブリック リポジトリには、マルウェアや構成ミスを含むイメージが含まれています。
• 必要なコンポーネントのみを含める – アプリケーションに必要のないコンポーネントがある場合は、それらを削除することをお勧めします。たとえば、UNIX システムは自然に「 awk 」および「 sed 」バイナリを提供します。
• コンテナー イメージにアプリケーションを含める – コンテナー イメージは、オペレーティング システム (OS) のサブセットと実行中のアプリケーションを保持します。コンテナーに取り込まれたすべてのツールとライブラリは、潜在的な脅威となります。これを解決するには、コンテナ イメージにアプリケーションを含めるのが最善です。これは、必要な依存関係をすべて備えた静的にコンパイルされたバイナリを通じて行われます。

脆弱性と管理のスキャンを自動化する

コンテナーとホストの定期的な脆弱性スキャンと管理は、アプリケーションのライフサイクルのどの段階でも脆弱性を検出するのに役立ちます。

この場合、コード スキャンを実行してバグを検出し、静的アプリケーション セキュリティ テスト (SAST) を実行してアプリケーション コードの脆弱性を見つけることができます。ソフトウェア構成分析 (SCA) は、オープンソース ソフトウェア コンポーネントを可視化し、文書化されたオープンソースの脆弱性と相互参照できるソフトウェア部品表を生成します。

さらに、イメージ スキャンにより、コンテンツとコンテナー イメージの構築プロセスが影響を受けやすいか分析されます。 Clair のようなツールを使用すると、既知の脆弱性をスキャンできます。あるいは、コンテナの動作に基づいてセキュリティ リスクを指摘する動的アプリケーション セキュリティ テスト (DAST) を採用します。 DAST ツールは、ホスト スキャンを実行して、コンテナーのホスト コンポーネント (ホスト カーネルと OS) の構成ミスを検査することもできます。

上記の対策はコンテナのライフサイクルの進行中のプロセスで採用されていますが、「シフトレフト」の哲学を受け入れることもできます。これは、開発ライフサイクルの開始時からセキュリティを実装することを意味します。このアプローチを選択する場合に適したツールは Trivy です。

コンテナレジストリの保護

コンテナー レジストリは、イメージを保存して配布するための効率的な一元的な方法です。多くの場合、組織はパブリックまたはプライベートのレジストリに数千のイメージを保存します。すべてのチーム メンバーと共同作業者が脆弱性のないイメージを使用できるようにするための対策がいくつかあります。

まず、ユーザー アクセス制御 (プライベート レジストリ用) を実装することで、誰がイメージを公開してアクセスできるかを確立します。これは基本的なセキュリティ対策ですが、権限のないユーザーが画像を公開、変更、削除することを防ぎます。

次の対策は、画像に署名することです。これにより、すべての画像が署名者と関連付けられ、侵害された画像の代替が困難になります。 Docker Content Trust テクニックを使用して、レジストリとの間で送受信されるデータにデジタル署名を追加できます。最後に、 イメージを (継続的に) スキャンすると、 重大な脆弱性の検出に役立つことを覚えておいてください。

コンテナの監視

可観測性ツールを使用して、コンテナーのワークロードの可視性を最適化できます。このツールは、すべてのコンポーネントの脆弱性を監視およびテストでき、コンテナ化された環境でのリアルタイムのイベント ログを有効にする必要があります。

可観測性ツールは、コンテナ スタックのすべてのコンポーネントからのメトリクスとログを監査し、異常がないか分析することで脅威を検出します。このアプローチを使用すると、構成ミスが特定されたときにすぐに修正できます。

リソース使用量メトリクスを収集するには、cAdvisor や kube-state-metrics などのツールを使用します。コンテナーのアクティビティやクラスターのパフォーマンスを監視するには、Grafana や Prometheus などのツールを使用します。

コンテナ間のネットワーク トラフィックを分析する場合は、Wireshark または tcpdump を使用します。 (AKS) などのマネージド Kubernetes サービスを使用している場合は、Azure Monitor を使用してリソースとセキュリティの脅威を追跡します。

さらに、Azure Log Analytics は AKS リソースを収集して分析できます。 Amazon EKS を選択した場合、Amazon CloudTrail はログ記録と監視に適しています。 Amazon Cloud Watchを使用します。

ネットワークセキュリティの実装

ネットワーク セキュリティ制御対策は、コンテナへの不正アクセスを防ぐのに役立ちます。ここで採用されている基準は、コンテナを分離し、必要なサービスのみへのアクセスを制限するネットワークのセグメント化です。

Kubernetes 上でコンテナ化されたアプリケーションを実行している場合は、K8s ネットワーク ポリシーを使用して、クラスター内の受信および送信ポッド トラフィックを構成できます。これにより、ラベルに基づいて特定のポッドへのトラフィックが制限されます。

ポッド通信用にトランスポート層セキュリティ (TLS) を強化できます。 API サーバーと他のコンポーネント間の安全な通信には、TLS または Secure Sockets Layer (SSL) 技術のいずれかを選択できます。クラスターへのトラフィック入力も制限したい場合は、ロード バランサーが良いソリューションです。

クラスターにマイクロサービスがある場合は、Meshery などのサービス メッシュ ツールを通じて安全なトラフィックを確保できます。 リンカードとか。 最後に、クラスターをホストするためにクラウド プロダーを使用している場合は、ネットワークを保護します。

Azure Kubernetes Service (AKS) を使用している場合は、トラフィック管理にネットワーク セキュリティ グループ (NSG) を使用します。 Amazon Elastic Kubernetes Service (EKS) を使用している場合、最適なのは Amazon Virtual Private Cloud (VPC) セキュリティ グループです。

表面攻撃の削減

攻撃の表面を最小限に抑えることには 2 つの利点があります。サービスの速度が向上し、セキュリティ侵害の可能性が低くなります。

マルチステージ ビルドを使用すると、表面攻撃が少なく、起動時間とパフォーマンスが向上した軽量イメージを作成できます。これを行うにはいくつかの解決策があります。 Linux を使用している場合は、Alpine Linux、BusyBox、または Tiny Core Linux を使用できます。

Ubuntu の場合は、Ubuntu Minimal があります。また、特別な Docker イメージである Scratch (本質的にはオープン コンテナ) を使用して、最初から最小限のイメージを構築することもできます。

コンテナ権限の制限

ここで採用されている原則には、特定のタスクを実行するための最小限の許可を提供することが含まれます。コンテナーを root として実行すると、パッケージのインストールやオペレーティング システムへの読み取り/書き込み操作権限など、さまざまな操作権限がユーザーに付与されます。

リスクは、侵害された場合、攻撃者がコンテナ ランタイムへの権限の昇格を利用できることです。その場合、実行可能な解決策は 2 つあります。コンテナをルートレス モードで実行したり、LINUX カーネルの機能をコンテナのワークロードに必要な機能のみに制限したりできます。

秘密を安全に管理する

コンテナーと Docker 構成ファイルにはシークレットが含まれていない必要があります。シークレットには、証明書、パスワード、アプリケーション プログラム インターフェイス (API) キー、トークンが含まれます。これがベスト プラクティスではありますが、これらのシークレットがビルド プロセスやソース コード イメージにハードコーディングされていることがよくあります。

このような場合、機密データはコンテナに入り、コンテナが削除された場合でも中間コンテナ層にキャッシュされます。このような場合、最良のアプローチは、 AWS Secrets Manager や Vault などのシークレット管理ソリューションをデプロイして、シークレット認証情報を保存および管理することです。

チームに力を与える

セキュリティ対策の最後として、セキュリティのベスト プラクティスについてチームを教育することが重要です。これは、チームのプレーヤー全員がセキュリティの脅威を特定して対応できることを意味します。

これを実現する良い方法は、チームのオンボーディング プロセスにコンテナ セキュリティを追加することです。実践的なトレーニング、継続的な学習、定期的なセキュリティ評価を提供することで、DevOps チームに最新のセキュリティ トレンドを提供することで差別化を図ることができます。

最終的な考え

コンテナのセキュリティは、ソフトウェア開発ライフサイクルの重要な継続的なプロセスです。このクエリに対する最善のアプローチは、アプリケーション コードからコンテナ ランタイム、ホスト オペレーティング システム、および基盤となるネットワーク インフラストラクチャにセキュリティを直接組み込むことです。

これを実現するには、コンテナーの検証を含む戦略的計画に従い、信頼できるソースからのコンテナーのみを使用します。コンテナの強化を実行して、コンテナ内に必要なサービスのみが含まれるようにします。監視ツールを通じて簡単に実行できるログ記録方法を導入します。ネットワークをセグメント化して、コンテナーをインフラストラクチャー全体から分離します。

サービスを介したデータの入出力を検証するには、必ずイメージに署名してください。さらに、定期的にスキャンと侵入テストを実施して脆弱性をチェックし、直ちに修正措置を講じる必要があります。また、テクノロジーの状況が進化するにつれて、常に最新のセキュリティ慣行を最新の状態に保ってください。

次に、セキュリティを自動化する方法を確認してください。