フレームワークは答えではなく質問のリストだ

一言でいうと

CIS・NSA/CISA・MITRE ATT&CKは、互いに競合する標準ではなく、役割の異なる道具です。 CISは設定のチェックリスト、NSA/CISAは設計ガイド、ATT&CKは攻撃者の行動の辞書です。そして、この3つを実際の証拠につなぐのが監査ログです。

なぜ必要なのか

「うちのクラスターは安全か」に答えるには、基準が必要です。基準がなければ、点検は人によって違い、昨年と今年を比較することもできず、外部に説明することもできません。

フレームワークの価値は、網羅性と共通言語です。見落としを減らし、異なる組織が同じ言葉を使えるようにします。ただし、フレームワークが「この通りにすれば安全です」と言ってくれるわけではありません。 質問の一覧であって、正解集ではありません。

どう動くのか

CIS Kubernetes Benchmark: 設定チェックリスト

各項目が「この設定はこの値になっているか」を問う、具体的なチェックリストです。コントロールプレーンのファイル権限、 apiserverのフラグ、etcdの設定、コントローラーマネージャー/スケジューラー、kubelet、ポリシーまで、領域ごとに分かれています。

項目ごとにAutomated / Manualの区分があります。自動で点検できるものと、人が判断する必要があるものです。
Level 1 / Level 2もあります。L1はほとんどの環境に適用でき、L2はセキュリティのために機能性を一部犠牲にする強化項目です。
kube-benchのようなツールが、この点検を自動化します。

CISを使うときの注意点は、マネージドクラスター(EKS/GKE/AKS)には、かなりの項目が適用されないことです。コントロールプレーンのファイルにアクセスできないからです。そのため、マネージド向けの別のベンチマークが用意されています。「項目をいくつ通過したか」という数字よりも、各項目がなぜあるのかを理解することが、試験でも現場でも重要です。

NSA/CISA Kubernetes Hardening Guidance: 設計ガイド

チェックリストではなく、「このように設計せよ」という記述式のガイドです。5つの軸にまとめられます。

Podセキュリティ: 非root実行、イミュータブルなファイルシステム、イメージスキャン、アドミッションポリシー
ネットワークの分離と強化: ネームスペースの分離、NetworkPolicy、コントロールプレーンへのアクセス制限、保存時・転送時の暗号化
認証と認可: 匿名の無効化、強力なユーザー認証、RBACの最小権限
ログの監査: 監査ログの有効化、ログのクラスター外への送出、アラートの構成
アップグレードと設定管理: 定期的なパッチ、不要なコンポーネントの削除、定期的な脆弱性の点検

CISが「この値は正しいか」を問うなら、NSA/CISAは「この構造は正しいか」を問います。両者は補完関係にあります。

MITRE ATT&CK for Containers: 攻撃者の行動の辞書

防御者の視点ではなく、攻撃者が実際に行う行動を、戦術(Tactic)と技術(Technique)として一覧にしたものです。コンテナのマトリクスにおける戦術の流れは、おおよそ次のとおりです。

초기 접근 → 실행 → 지속성 → 권한 상승 → 방어 회피 → 자격증명 접근
        → 탐색 → 측면 이동 → 영향

このコードブロックの韓国語は、順に、初期アクセス、実行、永続化、権限昇格、防御回避、認証情報アクセス、探索、ラテラルムーブメント、影響という戦術の名前です。

ここに含まれる代表的な技術は、前のモジュールで見たものとそのまま重なります。公開されたAPIを通じた初期アクセス、コンテナのデプロイを通じた実行、特権コンテナを通じた脱出、コンテナAPIを通じた認証情報アクセス、クラスターのリソースの探索です。

ATT&CKの使いどころは、検知の設計です。「私たちはこの技術を検知できるか」を技術単位で問えば、ログの収集とアラートルールが具体化します。CISが予防の側なら、ATT&CKは検知の側です。

監査ログ: 3つのフレームワークを証拠につなぐもの

コンプライアンスにおいて、監査ログが果たす役割は3つです。

証明: 「私たちはこの統制を運用している」ことを、記録で示します
調査: インシデントが起きたときに、何があったのかを再構成します
検知: 進行中の攻撃のシグナルを見つけます

Kubernetesの監査ポリシーは、4つのレベルで記録量を調整します。

レベル	記録する内容
`None`	記録しない
`Metadata`	リクエスト元・動作・リソース・時刻。本文なし
`Request`	メタデータ + リクエスト本文
`RequestResponse`	メタデータ + リクエスト + レスポンス本文

SecretのようなリソースにRequestResponseを設定すると、監査ログそのものがシークレットの漏えい経路になります。そのため実務のポリシーでは、通常、Secret/ConfigMapはMetadataでしか残さず、RBACオブジェクトの変更のような機微なものはRequestResponseで残します。

そして、何を残すかと同じくらい重要なのが、拒否(deny)を残すかです。権限の探索は、失敗の繰り返しとしてしか現れません。短時間に1つの主体が、異なる対象に何十回も拒否されるパターンが、そのまま列挙の試みのフィンガープリントです。拒否を記録しなければ、そのシグナルは存在しません。 逆方向も役に立ちます。デプロイ後に拒否ログが突然消えたなら、チェック自体がなくなった可能性を疑う必要があります。

最後に、ログはクラスターの外へ送る必要があります。侵害されたクラスターの中のログは消されるかもしれず、 Podもすでになくなっているかもしれません。

現場での姿

著者のブログが示したRBAC監査の手順は、CISの項目を実際のクエリに置き換えた好例です。

kubectl auth can-i --list --as=system:serviceaccount:production:app-deployer -n production で、特定の主体の実効権限をまとめて確認する
kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name=="cluster-admin")' で、cluster-adminのバインディングの主体を全件調査する
そして周期。四半期ごとのRBAC権限レビューで過剰な権限を持つ主体を特定し、 月次のポリシー違反レポートで違反リソースの状況を確認する

ここで強調したいのは、周期が決まっていることです。コンプライアンスが1回の点検ではなく、運用のルーティンだという意味です。

ワイルドカード権限についての著者の論拠も、そのまま引用に値します。 resources: ["*"]やverbs: ["*"]を使うと、現在はもちろん、将来追加されるリソースに対しても無制限のアクセスを許可することになります。「いまは安全だから大丈夫」という反論を、正確に断ち切る論理です。

ポリシーエンジンの運用原則も、コンプライアンスの観点から読むとよいでしょう。 Policy as Codeで管理し、変更前に必ずdryrunで影響を評価し、障害時の緊急復旧手順を事前に準備します。そして著者の最後の一文です。「RBACとポリシーエンジンは技術的な道具ですが、これを効果的に運用するには、組織のアクセス制御ガバナンスと連携する必要があります。」

次のラボですること

最後のラボでは、クラスター全体のRBAC監査を自分で実行します。 *権限を持つClusterRoleを探して一覧にし、escalate・bind・impersonateを持つものを検知し、kubectl auth can-i --list --as=でServiceAccountの実効権限を確認し、最小権限のRoleを新しく作成して望むことだけができ、残りはできないことを測定で証明したうえで、その根拠をまとめた監査レポートを書きます。