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

この記事では、コンテナーのセキュリティ保護を行い、セキュリティの脆弱性が生じるのを回避する方法について説明します。 "コンテナー" は、アプリケーションをパッケージ化してデプロイする効果的な方法です。 アプリケーションとサービスは環境内で分離されているため、運用上およびセキュリティ上の利点があります。 コンテナーは、抽象化によってシステム全体の障害の影響の低減にも寄与します。これにより、アップタイムが確保され、アプリケーションやサービスが侵害される可能性のある攻撃を防ぎます。

コンテナーは通常、ホスト オペレーティング システム上の抽象レイヤー上で実行され、抽象化により、分離のいくつかの障壁と、レイヤー化された防御モデルを適用する機会が提供されます。

また、コンテナー パイプライン、アプリケーション、コンテナー デプロイ環境をセキュリティ保護することで、継続的なコンテナー セキュリティを設定できます。 コンテナー セキュリティを実装する例については、このトピックで説明します。

イメージのセキュリティ保護

未承認のアクセスを防ぐために、イメージがセキュリティで保護された信頼できるレジストリにホストされていることを確認します。 イメージには信頼されたルート CA をもつ TLS 証明書が必要です。レジストリでは、強力な認証を使用するロールベースのアクセス制御 (RBAC) を使用する必要があります。 コンテナーのビルドと配信用に CI/CD を設計する場合は、イメージ スキャン ソリューションを含める必要があります。 画像スキャン ソリューションは、共通脆弱性識別子 (CVE) を特定し、悪用可能なイメージが修復なしでデプロイされないようにするのに役立ちます。

ホスト環境のセキュリティ強化

コンテナー セキュリティの重要な側面は、コンテナーが実行されているシステムと、実行時の動作について、セキュリティを強化する必要がある点です。 コンテナーのセキュリティは、ホストとデーモンを含め、スタック全体に重点を置く必要があります。 非クリティカルなサービスはホストから削除する必要があります。また、非準拠のコンテナーを環境にデプロイすべきではありません。 こうすることにより、ホストへのアクセスはコンテナーを介してのみ行うことになり、制御はコンテナー デーモンに一元化され、ホストが攻撃面から削除されます。 これらのステップは、プロキシ サーバーを使用してコンテナーにアクセスする場合に特に有用です (コンテナーのセキュリティ制御を誤ってバイパスする可能性があるため)。

コンテナー リソースの制限

コンテナーが侵害された場合、攻撃者は、基になっているホスト リソースを使用して悪意のあるアクティビティを実行しようとする可能性があります。 侵害の影響を最小限に抑えるために、メモリと CPU の使用率の制限を設定することをお勧めします。

シークレットの適切なセキュリティ保護

シークレットは、ホストとコンテナーの間で渡す必要がある機密情報を含むオブジェクトです。 シークレットの例としては、パスワード、SSL/TLS 証明書、SSH 秘密キー、トークン、接続文字列、その他、プレーンテキストで送信したり、暗号化されていない状態で保存したりするべきでないデータがあります。 すべてのシークレットをイメージから分離し、コンテナー オーケストレーション エンジンまたは外部シークレット マネージャーを介してマウントする必要があります。

分離を実践する

分離を使用し、特権ユーザーまたはルート ユーザーを使用してコンテナー内でアプリケーションを実行しない。 コンテナーが侵害された場合、攻撃者が特権を簡単にエスカレートできる可能性があるため、特権モードでコンテナーを実行しないようにする必要があります。 コンテナー内のルート ユーザーの UID (一意の識別コード) と GID (グループ識別コード) を知ることにより、攻撃者はホスト コンピューター上のルートによって書き込まれたファイルにアクセスして変更することができます。 また、アプリケーションは、自身が必要とするシークレットにのみアクセスできる、という最小特権の原則を使用する必要があります。 アプリケーション プロセスを実行するアプリケーション ユーザーを作成できます。

ランタイム セキュリティ監視をデプロイする

インフラストラクチャへの攻撃に対する予防措置を講じた後も侵害される可能性は依然としてあるため、悪意のあるアクティビティを防止して検出するよう、アプリケーションの動作を継続的に監視してログに記録することが重要です。 Prometheus などのツールは、インフラストラクチャを監視するための効果的な手段を提供します。

次の手順