V3: コンテナ
管理目標
コンテナベースのソリューションの主要コンポーネントはコンテナそのものです。それらにはサービスやアプリケーションロジックが含まれているだけではなく、他のシステムやコンテナと連携してデータを交換します。データは往々にして機密性が高く、的確な保護を求められます。
検証対象のコンテナソリューションが以下の上位要件を満たすことを確認します。
コンテナが最小限の権限で動作していることを確保すること。
コンテナ内のサービスを堅牢化し、攻撃対象領域を最小限に抑えること。
使用時にコンテナテクノロジのセキュリティ機能を活用すること。
セキュリティ検証要件
# | 説明 | L1 | L2 | L3 | 導入バージョン |
3.1 | root ユーザーが初期化時を除いて使用されておらず、完了時に権限が削除されていることを検証します。 | ✓ | ✓ | 1.0 | |
3.2 | ユーザー名前空間が有効であることを検証します。 | ✓ | ✓ | 1.0 | |
3.3 | 各コンテナ内に新しいユーザーが作成され、コンテナ内のすべての操作を実行するために使用されていることを検証します。 | ✓ | 1.0 | ||
3.4 | コンテナのニーズに基づいて特定 (非標準) の seccomp プロファイルが各コンテナに適用されていることを検証します。 | ✓ | 1.0 | ||
3.5 | コンテナが実行時に追加の権限を付与できないこと ( | ✓ | ✓ | ✓ | 1.0 |
3.6 | 名前とタグの代わりにハッシュを使用して、すべてのベースイメージが明示的に指定されていることを検証します。 | ✓ | 1.0 | ||
3.7 | 本運用で使用する前に各イメージの署名が検証されていることを検証します。 | ✓ | 1.0 | ||
3.8 | 必要なソフトウェアパッケージのみがイメージにインストールされていることを検証します。 | ✓ | ✓ | ✓ | 1.0 |
3.9 | ルートファイルシステムが読み取り専用モードでマウントされていることを検証します。 | ✓ | ✓ | 1.0 | |
3.10 | コンテナが (トラブルシューティングなどで) アクティブにアクセスされた後、それが削除され、イメージの新しいインスタンス (コンテナ) に置き換えられていることを検証します。 | ✓ | ✓ | 1.0 | |
3.11 | ソースが完全に信頼されていない限り Dockerfile は | ✓ | ✓ | ✓ | 1.0 |
3.12 | SSH や RDP などのリモート管理サービスが無効であるか、コンテナ内にインストールされていないことを検証します。 | ✓ | ✓ | ✓ | 1.0 |
3.13 | etcd などの公開サービスが完全に信頼されたシステムでのみ利用可能である、もしくは認証が必要であることを検証します。 | ✓ | ✓ | ✓ | 1.0 |
3.14 | コンテナ内で許可されるプロセス数が厳密に定義されており、 | ✓ | 1.0 | ||
3.15 | 監視または管理に使用されない限り Docker ソケットがコンテナ内にマウントされていないことを検証します。Docker ソケットへのアクセスが必要な場合は、読み取り専用アクセスで十分かどうかを確認し、それに応じてコンテナのアクセスを制限します。 | ✓ | ✓ | ✓ | 1.0 |
Last updated