概要
タイトル | 説明 |
---|---|
D01 - 安全なユーザーマッピング | ほとんどの場合、コンテナ内のアプリケーションはデフォルトの管理者権限である root で動作します。これは最小権限の原則に違反しており、もし攻撃者がアプリケーションからコンテナへの脱獄に成功した場合、その活動をさらに拡大する可能性が高くなります。ホストの観点からはアプリケーションは root として実行すべきではありません。 |
D02 - パッチ管理戦略 | ホスト、コンテナテクノロジ、オーケストレーションソリューション、およびコンテナ内の最小限のオペレーティングシステムイメージにはセキュリティバグがあるかもしれません。それが公に知られるようになった際、セキュリティ体制にとってこれらのバグにタイムリーに対処することが不可欠です。上記すべてのコンポーネントについて、本運用に移行する前に定期的なパッチと緊急パッチをいつ適用するかを決定する必要があります。 |
D03 - ネットワークセグメンテーションとファイアウォール | ネットワークを前もって適切に設計する必要があります。オーケストレーションツールからの管理インタフェースと、特にホストからのネットワークサービスは重要であり、ネットワークレベルで保護する必要があります。 |
D04 - 安全なデフォルトと堅牢化 | ホストとコンテナのオペレーティングシステムとオーケストレーションツールの選択に応じて、不要なコンポーネントがインストールされたり開始されたりしないように注意する必要があります。また、必要なすべてのコンポーネントを適切に構成してロックダウンする必要があります。 |
D05 - セキュリティコンテキストの維持 | 一つのホスト上の本運用コンテナを他のステージでの未定義または安全性の低いコンテナと混在すると、本運用へのバックドアが開く可能性があります。また、たとえば一つのホスト上でフロントエンドとバックエンドサービスを混在させると、セキュリティに悪影響を与える可能性があります。 |
D06 - 秘密の保護 | ピアまたはサードパーティに対するマイクロサービスの認証と認可には秘密を提供する必要があります。攻撃者にとってこれらの秘密は潜在的により多くのデータやサービスにアクセスできる可能性があります。したがって、パスワード、トークン、秘密鍵、証明書は可能な限り保護する必要があります。 |
D07 - リソース保護 | すべてのコンテナが同じ物理 CPU、ディスク、メモリ、ネットワークを共有しています。一つのコンテナが意図的かどうかにかかわらず制御不能になったとしても、他のコンテナのリソースに影響を与えないように、これらの物理リソースを保護する必要があります。 |
D08 - コンテナイメージの完全性と起源 | コンテナ内の最小限のオペレーティングシステムがコードを実行し、オリジンからデプロイメントまで、信頼できるものである必要があります。すべての転送と保存時のイメージが改竄されていないことを確認する必要があります。 |
D09 - 不変パラダイムの準拠 | 多くの場合、コンテナイメージは一度セットアップおよびデプロイすればそのファイルシステムやマウントされたファイルシステムに書き込む必要はありません。このような場合、コンテナを読み取り専用モードで起動すると、セキュリティ上の利点が高まります。 |
D10 - ログ記録 | コンテナイメージ、オーケストレーションツール、およびホストに対して、システムおよび API レベルでセキュリティ関連のすべてのイベントをログ記録する必要があります。すべてのログはリモートにあり、共通のタイムスタンプが含まれており、改竄防止が必要です。アプリケーションもリモートログ記録を提供する必要があります。 |
Last updated