Quiz: Compliance and Security Frameworks

CIS Kubernetes Benchmark 와 MITRE ATT&CK for Containers 의 역할 차이로 올바른 것은?

• CIS 는 컨테이너용, ATT&CK 는 VM 용 기준이다
• CIS 는 설정이 안전한 값인지 점검하는 예방 중심 점검표이고, ATT&CK 는 공격자의 행위를 전술·기법으로 목록화한 탐지 설계용 사전이다
• CIS 는 법적 강제력이 있는 규정이고 ATT&CK 는 참고용 권고 사항일 뿐이다
• 둘은 같은 내용을 다른 형식으로 표현한 것이다

쿠버네티스 감사 정책에서 Secret 리소스에 RequestResponse 레벨을 적용하면 생기는 문제는?

• 감사 로그가 암호화되지 않아 성능이 떨어진다
• Secret 생성이 거부된다
• Secret 의 실제 값이 감사 로그에 기록되어 감사 로그 자체가 시크릿 유출 경로가 된다
• etcd 저장 시 암호화가 자동으로 해제된다

관리형 쿠버네티스(EKS/GKE/AKS)에 CIS 벤치마크를 적용할 때 주의할 점은?

• 관리형 클러스터에는 CIS 를 적용할 수 없다
• 관리형 클러스터는 모든 항목을 자동으로 통과한다
• 컨트롤 플레인 파일과 플래그에 접근할 수 없어 상당수 항목이 적용 불가이며, 관리형 환경용 별도 벤치마크를 봐야 한다
• 관리형 클러스터에서는 Level 2 항목만 유효하고 Level 1 은 건너뛴다

RBAC 규칙에 resources: ["*"] 를 쓰는 것이 '지금 안전하니 괜찮다'는 반론으로 정당화될 수 없는 이유는?

• 미래에 CRD 등으로 추가될 리소스에 대해서도 자동으로 접근이 허용되므로 권한 범위가 시간이 지나며 저절로 넓어지기 때문
• 와일드카드는 성능을 크게 떨어뜨리기 때문
• 와일드카드는 감사 로그에 기록되지 않기 때문
• 와일드카드로 쓴 규칙은 어드미션 웹훅 검사를 통째로 우회하기 때문

감사 로그에서 한 주체가 10분 동안 서로 다른 대상 300여 개에 대해 거부당한 기록이 보인다. 이것이 의미하는 바는?

• 정상적인 애플리케이션 재시도 패턴이다
• RBAC 설정이 잘못되어 정상적인 요청이 계속 막히고 있는 것이다
• 권한 탐색·열거 시도가 진행 중이라는 신호이며, 거부를 기록하지 않았다면 이 신호는 존재하지 않았을 것이다
• 감사 로그 수집기의 중복 기록 버그다

새 정책을 Gatekeeper 나 Kyverno 에 도입하기 전에 dryrun(또는 audit) 모드로 먼저 돌리는 이유는?

• dryrun 모드가 정책 평가 성능을 측정해 주기 때문
• dryrun 모드에서만 정책 문법 오류가 검출되기 때문
• dryrun 으로 돌려야 감사 로그에 기록되기 때문
• 차단 없이 위반 리소스를 수집해 이 정책을 enforce 로 켰을 때 무엇이 깨지는지 미리 파악하기 위해