프레임워크는 답이 아니라 질문 목록이다

한 줄 요약

CIS·NSA/CISA·MITRE ATT&CK 는 서로 경쟁하는 표준이 아니라 역할이 다른 도구입니다.
CIS 는 설정 점검표, NSA/CISA 는 설계 가이드, ATT&CK 는 공격자 행위 사전입니다.
그리고 이 셋을 실제 증거로 잇는 것이 감사 로그입니다.

왜 이게 필요했나

"우리 클러스터는 안전한가"에 답하려면 기준이 있어야 합니다. 기준 없이는 점검이 사람마다 다르고,
작년과 올해를 비교할 수도 없고, 외부에 설명할 수도 없습니다.

프레임워크의 가치는 완결성과 공통 언어입니다. 빠뜨림을 줄이고, 서로 다른 조직이 같은 말을
쓰게 합니다. 다만 프레임워크가 "이대로 하면 안전하다"고 말해 주지는 않습니다.
질문 목록이지 정답지가 아닙니다.

어떻게 동작하나

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 — 설계 가이드

점검표가 아니라 "이렇게 설계하라"는 서술형 가이드입니다. 다섯 축으로 정리됩니다.

1. 파드 보안 — 비루트 실행, 불변 파일시스템, 이미지 스캔, 어드미션 정책
2. 네트워크 분리와 강화 — 네임스페이스 분리, NetworkPolicy, 컨트롤 플레인 접근 제한, 저장/전송 암호화
3. 인증과 인가 — 익명 비활성화, 강한 사용자 인증, RBAC 최소 권한
4. 로그 감사 — 감사 로깅 활성화, 로그를 클러스터 밖으로, 경보 구성
5. 업그레이드와 설정 관리 — 정기 패치, 불필요 컴포넌트 제거, 주기적 취약점 점검

CIS 가 "이 값이 맞나"를 묻는다면 NSA/CISA 는 "이 구조가 맞나"를 묻습니다. 둘은 보완 관계입니다.

MITRE ATT&CK for Containers — 공격자 행위 사전

방어자 관점이 아니라 공격자가 실제로 하는 행동을 전술(Tactic)과 기법(Technique)으로 목록화한 것입니다.
컨테이너 매트릭스의 전술 흐름은 대략 이렇습니다.

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

여기 담긴 대표 기법들이 앞 모듈에서 본 것과 그대로 겹칩니다 —
노출된 API 를 통한 초기 접근, 컨테이너 배포를 통한 실행, 권한 있는 컨테이너를 통한 탈출,
컨테이너 API 를 통한 자격증명 접근, 클러스터 자원 탐색.

ATT&CK 의 쓸모는 탐지 설계입니다. "우리는 이 기법을 탐지할 수 있는가"를 기법 단위로 물으면
로그 수집과 경보 규칙이 구체화됩니다. CIS 가 예방 쪽이라면 ATT&CK 는 탐지 쪽입니다.

감사 로그 — 세 프레임워크를 증거로 잇는 것

컴플라이언스에서 감사 로그가 하는 일은 셋입니다.

1. 증명 — "우리는 이 통제를 운영하고 있다"를 기록으로 보인다
2. 조사 — 사고가 났을 때 무슨 일이 있었는지 재구성한다
3. 탐지 — 진행 중인 공격의 신호를 찾는다

쿠버네티스의 감사 정책은 네 단계 로 기록량을 조절합니다.

| 레벨 | 기록 내용 |
| --- | --- |
| None | 기록 안 함 |
| Metadata | 요청자·동작·리소스·시각. 본문 없음 |
| Request | 메타데이터 + 요청 본문 |
| RequestResponse | 메타데이터 + 요청 + 응답 본문 |

Secret 같은 리소스에 RequestResponse 를 걸면 감사 로그 자체가 시크릿 유출 경로가 됩니다.
그래서 실무 정책은 보통 Secret/ConfigMap 은 Metadata 로만 남기고, RBAC 오브젝트 변경 같은
민감한 것은 RequestResponse 로 남깁니다.

그리고 무엇을 남기느냐 만큼 중요한 것 — 거부(deny)를 남기는가.
권한 탐색은 실패의 반복으로만 드러납니다. 짧은 시간에 한 주체가 서로 다른 대상으로 수십 번
거부당하는 패턴이 곧 열거 시도의 지문입니다. 거부를 기록하지 않으면 그 신호는 존재하지 않습니다.
반대 방향도 유용합니다 — 배포 후 거부 로그가 갑자기 사라졌다면 검사 자체가 사라졌을 가능성을
의심해야 합니다.

마지막으로, 로그는 클러스터 밖으로 보내야 합니다. 침해된 클러스터 안의 로그는 지워질 수 있고,
파드는 이미 사라졌을 수 있습니다.

현장에서 만나는 모습

저자의 블로그가 제시한 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 권한 리뷰로 과도한 권한 보유 주체를 식별하고,

월별 정책 위반 리포트로 위반 리소스 현황을 확인

여기서 강조점은 주기가 정해져 있다는 것입니다. 컴플라이언스가 한 번의 점검이 아니라
운영 루틴이라는 뜻입니다.

와일드카드 권한에 대한 저자의 논거도 그대로 인용할 만합니다 —
resources: ["*"] 나 verbs: ["*"] 를 쓰면 현재는 물론 미래에 추가될 리소스에 대해서도
무제한 접근을 허용하게 됩니다. "지금은 안전하니 괜찮다"는 반론을 정확히 끊는 논리입니다.

정책 엔진 운영 원칙도 컴플라이언스 관점에서 읽으면 좋습니다 —
**Policy as Code 로 관리하고, 변경 전 반드시 dryrun 으로 영향을 평가하고, 장애 시 긴급 복구 절차를
사전에 준비한다.** 그리고 저자의 마지막 문장 — "RBAC 과 정책 엔진은 기술적 도구이지만,
이를 효과적으로 운영하려면 조직의 접근제어 거버넌스와 연계해야 합니다."

다음 실습에서 할 것

마지막 실습에서 클러스터 전체 RBAC 감사를 직접 돌립니다.
* 권한을 가진 ClusterRole 을 찾아 목록으로 만들고, escalate·bind·impersonate 를 가진 것을
탐지하고, kubectl auth can-i --list --as= 로 서비스어카운트의 실효 권한을 확인하고,
최소 권한 Role 을 새로 만들어 원하는 것만 되고 나머지는 안 되는지 측정으로 증명한 뒤,
그 근거를 묶은 감사 리포트를 씁니다.