最も重要な対策は何でしょうか？
信頼できる最小限のベースイメージを使用する
適切にメンテナンスされ、アプリケーションに必要なパッケージ、ライブラリ、ユーティリティのみを含むベースイメージを使用します。これにより、攻撃対象領域が縮小され、パッチを適用しやすくなります。
導入前にイメージと依存関係をスキャンする
アーティファクトがパイプラインの後続工程に進む前に、スキャンによって既知の脆弱性、露出した機密情報、明らかな設定ミスを特定する必要があります。これだけでコンテナセキュリティのすべてを確保できるわけではありませんが、回避可能なリスクを早期に軽減するうえで、最も実用的な制御策の1つです。
Kubernetesマニフェストとインフラストラクチャ・アズ・コード（IaC）をセキュリティ上重要なアーティファクトとして扱う
ワークロード定義（Kubernetes、Pod、権限など）、Helmチャート（パッケージ化されたKubernetes構成）、Terraform（クラウドリソースやネットワークなどのインフラストラクチャをプロビジョニングするためのツール）、その他の導入アーティファクト（システムの立ち上げに使用されるあらゆる構成）は、実行時よりもはるかに前の段階で、権限、ネットワーク、公開範囲に関する問題を引き起こす可能性があります。
クラスタで最小権限の原則を徹底する
KubernetesのRBACは、ユーザー、サービスアカウント、ワークロードに対して慎重に設計する必要があります。過剰なアクセス権限は、不正使用や権限昇格のリスクを高めます。
アドミッションコントロールとポリシー適用を使用する
セキュリティルールは、導入時に自動的に適用することで、より効果的になります。アドミッションコントロールを使用すると、リスクのあるリソースがクラスタに受け入れられる前に阻止できます。また、ポリシーエンジンは、チームや環境をまたいで要件を標準化するのに役立ちます。
ネットワークをセグメント化して影響範囲を縮小する
ネットワークポリシーには、アプリケーションの実際の通信方法を反映させるとともに、不要な東西トラフィックを制限する必要があります。
実行時の動作を監視する
ビルド時のスキャンでは、実行時の問題をすべて検出できるわけではありません。実行中のコンテナ内におけるプロセスの動作、接続、リソース消費、ポリシーからの逸脱、疑わしいアクティビティを引き続き可視化する必要があります。そのため、実行時監視では、イメージの状態だけでなく、実行中のアプリケーション、オーケストレーターのアクティビティ、コンテナ間の通信も監視する必要があります。
調査に十分なログを記録する
コンテナ環境とKubernetes環境では複数のレイヤーでログが生成され、このテレメトリは検知とインシデント後の調査に重要です。
DevSecOpsチームは、デリバリーを遅らせることなく、これらの制御をどのように適用すべきでしょうか？
最も効果的なのは、適切な制御を適切な段階で適用することです。
ビルド段階では、イメージの衛生管理、依存関係のスキャン、シークレットの検知、ソフトウェアの来歴に重点を置きます。
導入段階では、マニフェストの検証、ポリシー適用、アドミッションコントロールに重点を置きます。
実行時には、動作監視、アラート通知、ドリフトの検知、調査態勢の整備に重点を置きます。
段階的なアプローチが重要なのは、すべての問題を同じゲートで扱うべきとは限らないためです。チェックによっては導入を阻止すべきですが、それ以外はレビュー、修正、または実行時監視のトリガーとすべきです。成熟度の高いチームは、修正必須の違反とリスクの低い問題を分けることで、セキュリティをボトルネックにすることなく、確実に適用できるようにします。段階的なアプローチは、イメージとインフラストラクチャコードに品質ゲートを設け、それをライフサイクル全体の実行時チェックおよびコンプライアンス制御と組み合わせることで、最大の効果を発揮します。
日常業務における優れたプラクティスとは、どのようなものでしょうか？
適切に運用されている環境では、コンテナセキュリティはリリースサイクルの最後に実施する独立したイベントではなく、ソフトウェアをビルドして出荷するプロセスの一部です。開発者は承認済みのベースイメージを把握し、CIパイプラインはチェックを自動的に実行し、プラットフォームチームはクラスタのガードレールを明確に定義します。また、セキュリティチームは個別のレビューだけに頼らず、傾向、例外、繰り返し発生する弱点をレビューします。
こうした運用のリズムが重要なのは、制御が予測可能な形で適用されてこそDevSecOpsが成功するためです。セキュリティ要件が後工程になってから問題点として持ち出されるのではなく、ツールやワークフローに組み込まれていれば、チームはその要件をはるかに受け入れやすくなります。
チームは何を定期的にレビューすべきでしょうか？
優れたコンテナセキュリティプログラムは、導入するだけでなく、継続的に維持管理する必要があります。チームは以下の点を定期的にレビューする必要があります。
- 承認済みのイメージのうち、現在も使用されているものはどれか
- 古い脆弱性が新しいビルドに引き継がれていないか
- セキュリティポリシーの例外が時間の経過とともに増えていないか
- サービスアカウントとロールに過剰な権限が付与されたままになっていないか
- ネットワークポリシーがワークロードの実際の通信方法と引き続き一致しているか
- 実行時のアラートが有益な調査につながっているか、それとも単なるノイズになっているか
- インシデント対応とインシデント後のレビューに十分なログが記録されているか。
こうした点をレビューすることで、制御の逸脱を防止できます。レビューを行わなければ、適切なセキュリティポリシーであっても、時代遅れになったり、一貫性なく適用されたりする可能性があります。
組織が陥りがちな誤り
よくある誤りの1つは、セキュリティ対策を過度にシフトレフトし、実行時のセキュリティはもはや重要ではないと考えることです。シフトレフトは有効ですが、コンテナは動的であるため、導入後にしか現れない疑わしい動作、権限の悪用、制御の不備を検知するには、実行時の可視性も依然として重要です。
もう1つの誤りは、セキュリティポリシーをデリバリープロセスに組み込むのではなく、外部のレビュー手順として扱うことです。開発者がプロセスの最後でしか違反を知らされない場合、是正に時間がかかり、対立を招きやすくなります。
3つ目の誤りは、コンテナを取り巻くプラットフォームのセキュリティを確保しないまま、コンテナだけを保護しようとすることです。DevSecOpsチームはイメージの品質を向上させることができますが、クラスタレベルのアクセスコントロール、アドミッションポリシー、ログ、セグメンテーションについては、引き続きプラットフォームチームやセキュリティチームとの緊密な連携が必要です。
実践的なDevSecOpsチェックリストには、何を含めるべきでしょうか？
実用的なチェックリストには、通常、以下の項目が含まれます：
- 承認済みのベースイメージとイメージの来歴
- CIでのイメージおよび依存関係のスキャン
- マージまたはビルド前のシークレット検知
- セキュリティ設定に関するマニフェストとIaCのレビュー
- 最小権限に基づくRBACとサービスアカウントの設計
- 導入時のガードレールとなるアドミッションコントロール
- ワークロードを分離するためのネットワークポリシー
- コンテナおよびクラスタのアクティビティの実行時監視
- ログの一元管理と調査態勢の整備
- ポリシー、例外、古くなったルールの定期的なレビュー。
重要なポイント
DevSecOpsチームにとってのコンテナセキュリティのベストプラクティスは、入力を保護し、導入時のガードレールを適用し、実行時の動作を監視するとともに、問題が本番環境のリスクとなる前にエンジニアリングチームが修正できるよう、評価ループを十分に短く保つというデリバリーモデルです。
DevSecOpsパイプラインにコンテナセキュリティを組み込む
効果的なDevSecOpsには、ソフトウェア開発プロセスに組み込まれて機能するセキュリティ制御が不可欠です。Kaspersky Container Securityを使用すると、チームはコンテナイメージの検査、稼働中のコンテナにおける脆弱性の検出、リソース消費量と通信の監視、セキュリティチェックとコンプライアンスチェックの自動化を行うことができます。
出典および参考資料：
