CCSPのコンテナ・サーバーレスセキュリティ：2026年試験の出題範囲

CCSP完全ガイドシリーズの一部です。

コンテナとサーバーレスセキュリティは、2026年のCCSP CBKで大幅に拡充されました。これらの技術はほとんどのエンタープライズクラウド環境で「新興技術」から「主流インフラ」へと移行しており、試験内容もその変化を反映しています。

本記事では、試験で問われる具体的な概念と、CCSPがコンテナ・サーバーレスセキュリティの問題をどのように構成しているかを解説します。

ドメインの配置

コンテナとサーバーレスセキュリティのコンテンツは主に2つのドメインに登場します。

• ドメイン3（クラウドプラットフォームおよびインフラセキュリティ） — コンテナランタイムセキュリティ、オーケストレーション（Kubernetes）、インフラレベルのコントロール
• ドメイン4（クラウドアプリケーションセキュリティ） — コンテナイメージセキュリティ、DevSecOpsパイプラインとの統合、Infrastructure as Code（IaC）セキュリティ

この区分は試験のアーキテクチャを反映しています。ドメイン3はコンテナを実行するプラットフォームを扱い、ドメイン4はアプリケーションのパッケージングとデプロイメントパイプラインを扱います。

コンテナセキュリティ

イメージセキュリティ

イメージスキャン：コンテナイメージはベースイメージとレイヤーから構成されます。脆弱性スキャンは各レイヤーをインストール済みパッケージの既知のCVEで検査します。CCSPが問うのは以下の点です。

• いつスキャンするか（ビルド時、レジストリへのプッシュ時、デプロイ時）
• スキャナーが何を評価するか（OSパッケージ、アプリケーションの依存関係、レイヤーに埋め込まれたシークレット）
• ガバナンスの判断：重大な脆弱性発見時にデプロイをブロックするか、補完コントロールでリスクを受け入れるか

イメージの署名と検証：サプライチェーン攻撃はビルドとデプロイの間にコンテナイメージを侵害する可能性があります。イメージの署名（Notary、Cosign、Docker Content Trust）とデプロイ時の検証により、イメージが改ざんされていないことを保証します。CCSPはこれをサプライチェーンコントロールとして問います。

レジストリセキュリティ：コンテナレジストリ（ECR、GCR、Docker Hub、プライベートレジストリ）はイメージを格納するアクセス制御されたシステムです。レジストリセキュリティにはアクセス制御、脆弱性スキャンとの統合、コンテントトラスト、イメージ保持ポリシーが含まれます。

最小ベースイメージ：フルOSディストリビューションで構築されたイメージは、最小ベースイメージ（Alpine Linux、distrolessイメージ）で構築されたものより攻撃対象領域が広くなります。これはドメイン3での設計原則の問題です。

ランタイムセキュリティ

コンテナの分離：コンテナは仮想マシンとは異なり、ホストカーネルを共有します。これが分離モデルと攻撃対象領域に影響します。ハイパーバイザーレベルの分離（VM）とカーネル名前空間による分離（コンテナ）は、基礎的なコンテンツです。

特権コンテナ：rootとして実行されるコンテナや昇格した権限を持つコンテナは分離モデルを弱体化させます。CCSPが問う原則は——特権コンテナを避け、必要最小限の権限を使う——であり、特定のオーケストレーション設定の詳細ではありません。

ランタイム保護：実行中のコンテナで異常な動作（通常と異なるシステムコール、予期しないネットワーク接続、ファイルシステムの変更）を検出する動作モニタリングツール。これらは多層防御モデルにおける検知コントロールです。

Kubernetesセキュリティ

Kubernetesは主要なコンテナオーケストレーションプラットフォームであり、ドメイン3で相当なコンテンツが割かれています。

デフォルトのサービスアカウント権限：デフォルトでは、KubernetesのPodにはほとんどのワークロードが必要とする以上の権限を持つサービスアカウントが割り当てられます。CCSPは「デフォルトのサービスアカウント権限を無効にする」を試験の答えとして使うことで有名です。これは最小権限を直接実装し、一般的な権限昇格パスを排除するからです。繰り返し問われる内容です。

ネットワークポリシー：Kubernetesはデフォルトで無制限のPod間通信を許可します。ネットワークポリシーは分離ルールを強制します——どのPodがどのポートで他のどのPodと通信できるかを制御します。ネットワークポリシーはマイクロセグメンテーションコントロールです。

アドミッションコントローラー：KubernetesのアドミッションコントローラーはオブジェクトがPersistされる前にAPIリクエストを傍受します。ポリシーを強制します。特権Podのブロック、リソース制限の要求、イメージ署名要件の強制などです。アドミッションコントローラーはAPIレイヤーでの予防コントロールです。

RBAC（ロールベースのアクセス制御）：KubernetesのRBACは誰がどのリソースでどのアクションを実行できるかを制御します。APIリソースへの最小権限アクセスという原則はRBAC一般と同じです。問題は適切なロール設計を問うものであり、RBACのYAML構文ではありません。

Podセキュリティ標準：ワークロードにセキュリティプロファイルを強制するための現在のKubernetesのメカニズム（非推奨となったPodセキュリティポリシーの代替）。3つのレベル：Privileged（特権）、Baseline（ベースライン）、Restricted（制限）。

etcdセキュリティ：Kubernetesはクラスタのステートをetcdに格納します。etcdには資格情報、設定、シークレットが含まれます。etcdの保存時暗号化とアクセス制御は、データセキュリティコントロールとして問われます。

コントロールプレーンセキュリティ：Kubernetes APIサーバーはコントロールプレーンの入口です。そのアクセス制御、TLS設定、監査ログはセキュリティアーキテクチャの問題で問われます。

サーバーレスセキュリティ

サーバーレスコンピューティング——AWS Lambda、Azure Functions、Google Cloud FunctionsなどのFunction as a Service（FaaS）——は共同責任モデルを変化させ、特定のセキュリティ上の考慮事項をもたらします。

共同責任モデルの違い

サーバーレスでは、CSPが実行環境、OS、ランタイム、インフラを管理します。顧客は関数コード、関数の権限、処理されるデータを管理します。これはより制約されたセキュリティ対象範囲ですが、一部の従来のセキュリティコントロールが完全にCSP側に移行します。

関数レベルのアクセス制御

各関数は特定のタスクに必要な権限のみを持つべきです。これは関数レベルで適用された最小権限です。CCSPの問題はサーバーレスアーキテクチャのシナリオでこの原則を問います。

イベントソースセキュリティ

サーバーレス関数はイベント（APIコール、キューメッセージ、データベースの変更、ストレージイベント）によってトリガーされます。イベントソースは信頼境界です——関数の不正なトリガーは脅威です。イベントソースの検証と認証はセキュリティコントロールです。

コールドスタートと一時的な実行

関数はスピンアップし、実行し、終了します。メモリ内で永続的な状態を維持しません。これはシークレット管理（長期的な資格情報キャッシュが不可）、フォレンジクス（一時的な実行によりログキャプチャが重要になる）、監視設計に影響します。

ベンダーロックインリスク

サーバーレス関数はプロバイダー固有のイベントモデル、IAMとの統合、APIコントラクトと深く結びついていることが多いです。CCSPはドメイン1（クラウドアーキテクチャ）とドメイン6（法律/リスク）でベンダーロックインを扱っており、契約上のポータビリティ要件も含まれます。

Infrastructure as Code（IaC）セキュリティ

IaCセキュリティはドメイン3と4にまたがり、Terraform、CloudFormation、Bicepおよび類似ツールのセキュリティをカバーします。

• 静的解析：デプロイ前にIaCテンプレートをスキャンして設定ミスを発見（セキュリティグループの開放、パブリックアクセス可能なS3バケット、暗号化設定の欠落）
• Policy as Code：Open Policy Agent（OPA）やHashiCorp Sentinelなどのツールが、IaCの変更が適用される前にセキュリティポリシーを強制する
• ドリフト検知：展開済みインフラがIaCテンプレートから乖離している場合の特定（権限のない手動変更や攻撃を示す可能性がある）
• IaC内のシークレット：ハードコードされた資格情報やAPIキーを含むIaCテンプレートはサプライチェーンリスク

試験問題のパターン

コンテナセキュリティに関するCCSP問題は典型的に以下の構造をとります。

• コンテナやKubernetesを使用したクラウドアーキテクチャシナリオを提示する
• セキュリティ要件（分離、アクセス制御、サプライチェーンの完全性）を特定する
• その要件に最も適したコントロールを問う
• 別の懸念に対処するもっともらしいが不正確な答えを含める

ガバナンス優先の原則が適用されます。「最も優先すべきコントロールはどれか」と問う問題は通常、複雑な技術コントロールではなく、最小権限またはデフォルトの設定ミスに関する答えが正解です。「デフォルトのサービスアカウント権限を無効にする」という問題パターンはこれを示しています——過剰な権限を削除することが最優先の初期ハードニングステップです。特権昇格を根本から防ぐからです。

次の記事：CCSPの2026年給与水準 | CCSP AI/MLセキュリティ