プレイブック

包括的なクラウドネイティブセキュリティ戦略を設計する。

→4つのC（Cloud（基盤）、Cluster、Container、Code）全体でセキュリティ制御を実装する。

理由: 外側のレイヤー（例：Cloud）での侵害は、すべての内側レイヤーのセキュリティを損ないます。セキュリティは最も弱いリンクと同じくらい強力です。

リファレンス↗

単一ポイントのセキュリティ障害から保護する。

→複数の重複するセキュリティ制御を異なるレイヤー（例：NetworkPolicies、RBAC、Security Contexts）で実装する。

理由: 1つの制御が失敗したりバイパスされたりしても、他のレイヤーは保護を提供し続け、攻撃者の困難さを増します。

ネットワークロケーションが信頼できる境界ではない環境でネットワークトラフィックを保護する。

→「決して信頼せず、常に検証する」モデルを実装する。通常、mTLSのためにサービスメッシュを使用して、すべてのリクエストを認証および認可する。

理由: ネットワークの内外に脅威が存在する可能性があると仮定し、ネットワーク位置に基づく暗黙の信頼を排除します。

侵害されたIDまたはコンポーネントの被害範囲を制限する。

→すべての主体（ユーザー、ServiceAccount、ノード）に、その機能を実行するために必要な最小限の権限のみを付与する。

理由: 攻撃者が盗んだ認証情報で引き起こす可能性のある潜在的な損害を軽減します。

セキュリティ脆弱性のコストと影響を軽減する。

→自動セキュリティスキャン（SAST、SCA、イメージスキャン）とポリシーチェックをCI/CDパイプラインの初期段階に統合する。

理由: 開発ライフサイクルの早い段階で脆弱性を発見し修正することで、修正コストが最も低くなります。

etcdストレージが侵害された場合に、機密性の高いクラスターデータ（特にSecrets）を保護する。

→kube-apiserverで、`--encryption-provider-config`を使用して、リソースがetcdに保存される前に保存時の暗号化を有効にする。

理由: デフォルトでは、Kubernetes Secretsはetcdでbase64エンコードされているだけです。これにより、ディスク上で真の暗号化が提供されます。

リファレンス↗

etcd通信への不正アクセスと盗聴を防止する。

→クライアント（`--client-cert-auth`）およびピア（`--peer-client-cert-auth`）通信の両方でmTLSを使用してetcdを構成する。

理由: 認証されたコンポーネント（apiserver、その他のetcdメンバー）のみがetcdと通信でき、トラフィックが暗号化されることを保証します。

Kubernetes APIサーバーへの認証されていないアクセスを防止する。

→`--anonymous-auth=false`フラグを設定する。OIDCやx509証明書のような強力な認証方法を使用する。

理由: `system:anonymous`ユーザーを無効にし、すべてのリクエストが認証され、特定のIDに対してログに記録されるように強制します。

セキュリティとコンプライアンスのために、すべての変更とアクセス試行を追跡する必要がある。

→`--audit-policy-file`を使用してAPIサーバーの監査ログを有効にし、ログを外部の不変なロギングシステムに送信する。

理由: インシデント調査、脅威ハンティング、コンプライアンス監査のために、不可欠で改ざん防止可能な証跡を提供します。

リファレンス↗

ワーカーノードの攻撃対象領域を削減する。

→kubeletフラグを設定する：`--anonymous-auth=false`、`--authorization-mode=Webhook`、`--read-only-port=0`。

理由: これにより、kubelet APIへのすべてのリクエストがAPIサーバーによって認証および認可され、安全でない認証されていない読み取り専用ポートが無効になります。

コントロールプレーンコンポーネントからの情報漏洩を防止する。

→本番環境のkube-apiserver、kube-controller-manager、およびkube-schedulerで`--profiling=false`フラグを設定する。

理由: プロファイリングエンドポイントは、攻撃者が偵察に役立つ可能性のある内部パフォーマンスデータやシステム詳細を公開することがあります。

コントロールプレーンコンポーネントを不正なネットワークアクセスから保護する。

→ファイアウォールルール（クラウドセキュリティグループ、iptables）を使用して、APIサーバー（6443）とetcd（2379）ポートへのアクセスを信頼できるソースのみに制限する。

理由: ネットワークレベルのアクセス制御は防御の基礎となるレイヤーであり、攻撃者が機密性の高いコンポーネントAPIに到達することさえ防ぎます。

ユーザーまたはアプリケーションに権限を付与する。

→`ClusterRoles`よりも名前空間スコープの`Roles`を使用する。ワイルドカード（`*`）ではなく、特定の動詞（`get`、`list`）を付与する。

理由: 最小権限の原則に従い、特定の名前空間内で必要なものだけに権限の範囲を制限します。

リファレンス↗

PodがKubernetes APIと通信する必要がない。

→Pod specまたはServiceAccount自体で`automountServiceAccountToken: false`を設定する。

理由: Pod内に不要な認証情報が公開されるのを防ぎ、Podが侵害された場合の攻撃対象領域を減らします。

名前空間内のすべてのPodのベースラインセキュリティ体制を強制する。

→`pod-security.kubernetes.io/enforce: baseline`のような名前空間ラベルを適用することにより、組み込みの`PodSecurity`アドミッションコントローラーを使用する。

理由: サードパーティツールなしで、リスクの高いPod構成（特権コンテナなど）を防ぐ標準化された組み込みの方法を提供します。

リファレンス↗

個々のコンテナセキュリティを強化し、特権昇格を防ぐ。

→Pod specで`securityContext`フィールドを設定する：`runAsNonRoot: true`、`allowPrivilegeEscalation: false`、`readOnlyRootFilesystem: true`。

理由: これらの制御により、rootとしての実行を防止し、新しい特権を獲得するためのメカニズムをブロックし、コンテナファイルシステムを不変にすることで、侵害の影響を大幅に削減します。

クラスター内でゼロトラストネットワークモデルを実装する。

→すべてのPodを選択し（`podSelector: {}`）、イングレス/イグレスルールリストが空であるデフォルト拒否のNetworkPolicyを各名前空間に適用する。

理由: Kubernetesのネットワーキングはデフォルトで許可されます。このポリシーはモデルをデフォルト拒否に反転させ、開発者に必要なトラフィックを明示的に許可するよう強制します。

特定のアプリケーション層間（例：web-to-api）でのみトラフィックを許可する。

→`podSelector`と`namespaceSelector`を使用して、ラベルに基づいてきめ細かいイングレスおよびイグレスルールを定義するNetworkPoliciesを作成する。

理由: 侵害されたPodが明示的に認可されたピアとのみ通信できるようにすることで、攻撃者による横方向への移動を防ぎます。

ユーザーがデバッグのためにコンテナに`kubectl exec`する権限を必要とする。

→関連するRoleまたはClusterRoleで、`pods/exec`サブリソースに対して`create`動詞を付与する。

理由: `exec`アクションは、新しいexecセッションを作成するため、直感に反して`create`動詞によって制御されます。これは一般的な混乱点です。

攻撃者がコンテナにアクセスし、ホストノードを侵害しようとする。

→特権コンテナ（`securityContext.privileged: false`）、ホスト名前空間（`hostNetwork`、`hostPID`）、およびDockerソケットのマウントを禁止する。

理由: これらの設定は実質的にコンテナの分離を破り、侵害されたコンテナにホストへのrootレベルのアクセスを許可します。

既知の脆弱性や悪意のあるコードを含むコンテナイメージのデプロイを防止する。

→CI/CDパイプラインおよびアドミッションコントロールを通じて、イメージスキャン（例：Trivy）とイメージ署名検証（例：Cosign）を実装する。

理由: 多層防御アプローチを提供します。スキャンは既知の脆弱性を検出し、署名はイメージの整合性と出所を検証します。

攻撃者が1つのPodを侵害し、クラスター内の他のPodにアクセスしようとしている。

→デフォルト拒否のNetworkPoliciesを実装し、必要なPod間通信に対してのみ特定の許可ルールを作成する。

理由: 侵害されたPodからの攻撃者の「視界」を制限し、侵害を封じ込め、拡散を防ぎます。

侵害されたPodがインスタンスメタデータサービスからクラウドIAM認証情報を盗むのを防止する。

→メタデータIP（例：`169.254.169.254/32`）へのトラフィックを明示的にブロックするデフォルト拒否のイグレスNetworkPolicyを適用する。

理由: これはクラウド環境で一般的な攻撃経路です。このイグレスパスをブロックすることで、PodからのIAM認証情報盗難のリスクを軽減します。

ノードリソースを枯渇させるサービス拒否攻撃やクリプトジャッキング攻撃から保護する。

→名前空間に`ResourceQuota`オブジェクトを適用して総リソース使用量を制限し、個々のPodに制限を強制するために`LimitRange`オブジェクトを適用する。

理由: 単一のテナントやワークロードが他のリソースを枯渇させないようにし、安定性を提供し、不正使用を防止します。

攻撃者が侵害されたクラスターへの長期アクセスを維持しようとする。

→予期しない`DaemonSets`、`CronJobs`、または特権Podの作成を監視する。これらのリソースを作成する権限を制限する。

理由: 攻撃者は、ノードやPodが再起動されても悪意のあるコードが永続的に実行されるように、これらのワークロードタイプを使用します。

デプロイ前にコンテナイメージに既知の脆弱性がないことを確認する。

→Trivy、Clair、GrypeなどのイメージスキャナーをCI/CDパイプラインに統合し、イメージをスキャンして、重大な脆弱性が発見された場合はビルドを失敗させる。

理由: 脆弱性検出を早期に自動化し（「シフトレフト」）、脆弱なコードが本番環境に到達するのを防ぎます。

信頼された、変更されていないコンテナイメージのみがクラスターにデプロイされることを確認する。

→CIパイプラインでCosignのようなツールでイメージに署名する。デプロイ時に署名を検証するために、検証アドミッションコントローラー（例：Kyverno、Gatekeeper）を使用する。

理由: イメージの整合性（改ざんされていないこと）と出所（信頼できるソースからのものであること）の暗号的証明を提供します。

実行中のコンテナ内の悪意のあるアクティビティ（例：シェル生成、機密ファイルアクセス）を検出する。

→Falcoのようなランタイムセキュリティツールをデプロイする。これはeBPFを使用してシステムコールを監視し、定義されたルールセットに基づいて疑わしい動作を警告します。

理由: 静的スキャンやアドミッションコントロールでは見えないランタイムアクティビティへの可視性を提供します。アクティブな侵害を検出するために不可欠です。

カスタムの組織固有のセキュリティポリシー（例：「すべてのイメージは企業レジストリから来る必要がある」）を強制する。

→OPA GatekeeperやKyvernoのようなポリシーエンジンを検証アドミッションコントローラーとして使用し、RegoまたはYAMLで記述されたポリシーを強制する。

理由: Kubernetesの組み込み制御を超えるセキュリティポリシーの柔軟で宣言的、自動化された強制を可能にします。

クラスター内のすべてのサービス間トラフィックを暗号化し、認証する。

→サービスメッシュ（例：Istio、Linkerd）を実装して、すべてのメッシュ化されたサービスに相互TLS（mTLS）を自動的に提供する。

理由: クラスター内のすべてのトラフィックが暗号化され、サービスが互いのIDを相互に検証することを保証することにより、ゼロトラストネットワーキングを実現します。

標準コンテナよりも強力な分離を必要とする、信頼できないまたはマルチテナントのワークロードを実行する。

→gVisorやKata Containersのようなサンドボックス型コンテナランタイムを使用する。これらはコンテナとホストカーネルの間にさらなる分離レイヤーを提供する。

理由: ホストカーネルの攻撃対象領域を削減し、コンテナエスケープを大幅に困難にします。

カーネルレベルでのコンテナの権限をきめ細かく制御する。

→Seccompプロファイルを使用して許可されたシステムコールをフィルタリングし、AppArmor/SELinuxプロファイルを使用してファイルおよびネットワークアクセスに対する強制アクセス制御（MAC）を強制する。

理由: これらのLinuxネイティブのセキュリティ機能は深い防御層を提供し、侵害されたコンテナプロセスが本質的にできることを制限します。

コンテナイメージ内の攻撃対象領域を削減する。

→アプリケーションとその直接的な依存関係のみを含む最小限の、または「ディストロレス」なベースイメージを使用してアプリケーションイメージを構築する。

理由: 本番環境には不要であり、侵害後に攻撃者によって使用される可能性があるシェル、パッケージマネージャー、その他のユーティリティを削除します。

Kubernetesクラスターがセキュリティのベストプラクティスに従って構成されていることを確認する。

→クラスターをCIS Kubernetes Benchmarkに対してチェックする自動ツールである`kube-bench`を定期的に実行する。

理由: クラスターのセキュリティ体制を監査し、設定ミスを特定するための標準化された、包括的で自動化された方法を提供します。

クラスターはPCI DSSに準拠してクレジットカードデータを処理および保存する必要がある。

→ネットワークセグメンテーションのためにNetworkPoliciesを使用してカード会員データ環境（CDE）を分離し、etcdに対して保存時の暗号化を有効にする。

理由: これらの制御は、ネットワークセグメンテーション（要件1）および保存されたカード会員データの保護（要件3）に関するPCI DSS要件に直接マッピングされます。

クラスターが保護医療情報（PHI）を扱い、HIPAAに準拠する必要がある。

→厳格なRBACを実装し、包括的な監査ログを有効にし、データが保存時および転送時にも暗号化されていることを確認する。

理由: これらの制御は、アクセス制御、監査制御、および伝送セキュリティに関するHIPAAの技術的保護措置に対応しています。

クラスターが侵害された場合でも、コンプライアンスとフォレンジックのために監査ログが保持されることを確認する。

→APIサーバーを構成して、監査ログを外部の書き込み専用/不変のロギングバックエンド（例：SIEMまたはロックダウンされたクラウドストレージバケット）にストリーミングする。

理由: クラスター管理者権限を持つ攻撃者が、ローカル監査ログを改ざんまたは削除して痕跡を隠すのを防ぎます。