KCSA — 쿠버네티스 보안 어소시에이트 · 모의고사 · 퀴즈

KCSA 모의고사 A

LabHub 에서 이어서 보기

문항 60개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

클라우드 네이티브 보안의 4C 모델에서 안쪽부터 바깥쪽 순서로 올바른 것은?
1. Code → Container → Cluster → Cloud
2. Container → Code → Cloud → Cluster
3. Cloud → Cluster → Container → Code
4. Cluster → Cloud → Code → Container
공동 책임 모델에서 관리형 쿠버네티스 사용자가 여전히 책임지는 영역으로 올바른 것은?
1. 컨트롤 플레인 노드의 운영체제 패치
2. etcd 인스턴스의 물리적 보안
3. 워크로드의 RBAC 설정과 파드 보안 수준
4. apiserver 바이너리의 취약점 수정
최소 권한 원칙을 쿠버네티스에 적용한 예로 가장 적절한 것은?
1. 모든 파드에 cluster-admin 을 주되 감사 로그로 사후 추적한다
2. 워크로드마다 전용 ServiceAccount 를 만들고 필요한 동사와 리소스만 허용한다
3. 네임스페이스를 하나만 두고 모든 워크로드를 그 안에서 관리한다
4. 권한을 넉넉히 주고 문제가 생기면 그때 줄인다
심층 방어(defense in depth)를 쿠버네티스에서 실천한 예로 가장 적절한 것은?
1. 가장 강력한 통제 하나를 골라 그것에만 집중 투자한다
2. 이미지 스캔, 어드미션 정책, 파드 보안 표준, 네트워크 정책, 런타임 탐지를 겹쳐 둔다
3. 클러스터를 외부에서 접근할 수 없게 막으면 다른 통제는 생략한다
4. 취약점이 발견된 뒤에 대응 절차를 만든다
쿠버네티스에서 공격 표면이 넓어지는 설정으로 보기 어려운 것은?
1. apiserver 를 인터넷에 그대로 노출하는 것
2. 익명 접근(`--anonymous-auth=true`)을 켜 두는 것
3. 노드에 SSH 를 열어 두고 키를 공유하는 것
4. 워크로드마다 별도의 네임스페이스를 두는 것
공급망 보안에서 SBOM 이 하는 역할로 가장 정확한 것은?
1. 빌드 파이프라인에 서명을 붙여 위조를 막는다
2. 아티팩트에 들어간 구성 요소와 버전 목록을 남겨 새 취약점이 공개됐을 때 영향 범위를 즉시 찾게 한다
3. 실행 중인 컨테이너의 시스템 콜을 감시해 이상 행위를 탐지한다
4. 이미지를 암호화해 레지스트리에서 내용을 읽지 못하게 한다
제로 트러스트를 클러스터 내부에 적용한다는 말의 의미로 가장 적절한 것은?
1. 클러스터 안에 들어온 트래픽은 이미 검증된 것으로 보고 내부 통신은 열어 둔다
2. 위치가 아니라 신원과 정책으로 매 요청을 판단하고 내부 통신도 인증과 인가를 거치게 한다
3. 모든 외부 접근을 차단하고 내부 사용자만 클러스터를 쓰게 한다
4. 방화벽 규칙을 촘촘히 짜서 경계를 강화한다
클러스터 보안 사고 대응에서 침해된 노드를 발견했을 때 순서로 가장 적절한 것은?
1. 노드를 즉시 삭제해 흔적을 정리하고 새 노드를 붙인다
2. 노드를 cordon 하고 증거를 보존한 뒤 워크로드를 옮기고 자격증명을 회수한다
3. 노드를 재부팅해 정상 상태로 되돌린 다음 원인을 조사한다
4. 먼저 클러스터 전체를 재설치하고 나중에 로그를 본다
apiserver 의 `--authorization-mode` 에 `AlwaysAllow` 가 포함되면 어떤 일이 벌어지는가?
1. 인증에 성공한 요청은 RBAC 규칙과 무관하게 모두 허용된다
2. 인증되지 않은 요청만 허용되고 인증된 요청은 RBAC 을 따른다
3. RBAC 규칙이 없을 때만 허용되고 규칙이 있으면 그것을 따른다
4. 감사 로그에 기록된 주체만 허용된다
kubelet 의 `--anonymous-auth=true` 가 위험한 이유로 가장 정확한 것은?
1. kubelet 이 apiserver 에 익명으로 접속해 노드 등록이 실패한다
2. 노드의 kubelet API 에 자격증명 없이 접근할 수 있는 경로가 열린다
3. 파드의 ServiceAccount 토큰이 발급되지 않는다
4. 컨테이너 런타임이 이미지 서명을 검증하지 않게 된다
etcd 를 보호하기 위한 조치로 효과가 가장 적은 것은?
1. 클라이언트와 피어 통신 모두에 상호 TLS 를 강제한다
2. etcd 포트를 컨트롤 플레인 노드 사이로만 열고 나머지는 차단한다
3. 저장 시 암호화를 켜서 Secret 이 평문으로 남지 않게 한다
4. etcd 데이터 디렉터리의 파일 이름을 알아보기 어렵게 바꾼다
쿠버네티스의 저장 시 암호화(encryption at rest)에 대한 설명으로 올바른 것은?
1. apiserver 가 etcd 에 쓰기 전에 암호화하고 읽을 때 복호화한다
2. etcd 가 스스로 암호화하며 apiserver 는 관여하지 않는다
3. kubelet 이 파드에 마운트하기 직전에 복호화한다
4. 클라이언트인 kubectl 이 전송 전에 암호화한다
KMS 프로바이더를 쓰는 저장 시 암호화가 `aescbc` 같은 로컬 키 방식보다 나은 점은?
1. 암호화 알고리즘이 더 빨라 apiserver 지연이 줄어든다
2. 데이터 암호화 키를 외부 KMS 가 감싸므로 키가 설정 파일에 평문으로 남지 않는다
3. etcd 백업 파일을 자동으로 복호화해 준다
4. Secret 이외의 리소스까지 자동으로 암호화 대상에 넣는다
apiserver 의 인증 방식으로 쿠버네티스가 제공하지 않는 것은?
1. 클라이언트 인증서
2. OIDC 토큰
3. ServiceAccount 토큰
4. 리소스별 접근 제어 목록(ACL) 파일
바운드 ServiceAccount 토큰(projected token)이 기존의 Secret 기반 토큰보다 안전한 이유는?
1. 토큰이 더 긴 문자열이라 추측하기 어렵다
2. 만료 시간이 있고 특정 파드와 대상(audience)에 묶여 있어 유출 시 쓸 수 있는 범위와 기간이 좁다
3. 토큰이 etcd 에 저장되지 않아 apiserver 도 검증할 수 없다
4. 토큰이 파드 안에서만 생성되어 apiserver 가 발급에 관여하지 않는다
kube-scheduler 와 kube-controller-manager 의 `--bind-address` 를 루프백으로 두라고 권고하는 이유는?
1. 다른 노드가 그 컴포넌트에 접속해야 하는데 대역폭을 아끼기 위해
2. 지표와 디버그 엔드포인트가 노드 밖에서 접근 가능한 상태로 노출되지 않게 하려고
3. 컴포넌트가 apiserver 에 접속할 때 지연을 줄이려고
4. 리더 선출을 노드마다 독립적으로 수행하려고
컨트롤 플레인 컴포넌트의 `--profiling=true` 를 운영에서 끄라고 하는 이유는?
1. 프로파일링이 켜지면 감사 로그가 남지 않기 때문
2. profiling 엔드포인트가 내부 상태를 드러내고 부하를 유발할 수 있기 때문
3. 프로파일링이 인증을 우회하도록 설계되어 있기 때문
4. 프로파일링을 켜면 RBAC 규칙이 초기화되기 때문
kubelet 의 `--read-only-port` 와 `--authorization-mode=Webhook` 의 관계로 올바른 것은?
1. 읽기 전용 포트는 인가 웹훅을 거치지 않으므로 웹훅을 켜도 그 포트는 따로 닫아야 한다
2. 인가 웹훅을 켜면 읽기 전용 포트도 자동으로 보호된다
3. 읽기 전용 포트를 닫으면 인가 웹훅이 동작하지 않는다
4. 두 설정은 서로 배타적이라 함께 쓸 수 없다
어드미션 컨트롤러가 인증·인가와 다른 지점으로 가장 정확한 것은?
1. 요청자가 누구인지 다시 확인해 신원을 이중으로 검증한다
2. 요청의 내용을 보고 변형하거나 거부해 오브젝트가 지켜야 할 조건을 강제한다
3. 요청을 etcd 에 저장한 뒤 사후에 검사해 위반을 보고한다
4. 요청의 속도를 제한해 과부하를 막는 것만 담당한다
ValidatingAdmissionWebhook 의 `failurePolicy: Ignore` 가 만드는 위험은?
1. 웹훅이 응답하지 않으면 검사 없이 요청이 통과해 정책이 조용히 비워진다
2. 웹훅이 응답하지 않으면 클러스터의 모든 쓰기가 멈춘다
3. 웹훅이 거부한 요청도 강제로 통과된다
4. 웹훅이 오브젝트를 변형할 수 있게 되어 예상 밖의 값이 저장된다
컨트롤 플레인 노드에서 정적 파드(static pod) 매니페스트 디렉터리의 쓰기 권한이 중요한 이유는?
1. 그 디렉터리에 파일을 쓸 수 있으면 apiserver 를 거치지 않고 원하는 파드를 실행시킬 수 있다
2. 그 디렉터리가 손상되면 etcd 데이터가 함께 사라진다
3. 그 디렉터리의 권한이 파드의 securityContext 기본값을 결정한다
4. 그 디렉터리를 통해 클러스터의 감사 정책이 배포된다
파드 스펙의 `automountServiceAccountToken: false` 를 쓰는 이유로 가장 적절한 것은?
1. API 를 호출하지 않는 워크로드에 토큰을 두지 않아 탈취 시 쓸 거리를 없앤다
2. 파드가 API 서버에 접속하는 속도를 높인다
3. ServiceAccount 를 아예 만들지 않아도 되게 한다
4. 파드가 다른 네임스페이스의 Secret 을 읽을 수 있게 한다
NetworkPolicy 를 하나도 만들지 않은 네임스페이스의 기본 통신 상태는?
1. 같은 네임스페이스 안에서만 통신이 허용된다
2. 모든 파드가 모든 파드와 자유롭게 통신할 수 있다
3. 모든 통신이 차단되어 있고 정책으로 열어야 한다
4. 인그레스는 열려 있고 이그레스만 차단되어 있다
NetworkPolicy 로 막을 수 없는 것은?
1. 특정 라벨을 가진 파드에서 들어오는 인그레스
2. 지정한 CIDR 이외로 나가는 이그레스
3. 허용된 연결 안에서 오가는 HTTP 요청 본문의 내용
4. 특정 포트와 프로토콜로 들어오는 연결
`securityContext.runAsNonRoot: true` 만 설정하고 이미지가 root 로 실행되도록 만들어져 있으면?
1. kubelet 이 사용자를 자동으로 비특권 사용자로 바꿔 실행한다
2. 컨테이너가 시작을 거부당하고 파드가 실행되지 않는다
3. 경고만 남고 root 로 그대로 실행된다
4. 이미지가 다시 빌드되어 사용자만 바뀐 상태로 실행된다
`allowPrivilegeEscalation: false` 가 실제로 막는 것은?
1. 컨테이너가 호스트의 네트워크 namespace 를 쓰는 것
2. 자식 프로세스가 setuid 바이너리 등으로 부모보다 더 많은 권한을 얻는 것
3. 파드가 다른 네임스페이스의 오브젝트를 읽는 것
4. 컨테이너가 볼륨에 쓰기를 수행하는 것
리눅스 capability 를 다룰 때 권장되는 방식은?
1. 모두 drop 한 뒤 꼭 필요한 것만 add 한다
2. 기본값을 그대로 두고 문제가 생기면 그때 drop 한다
3. NET_ADMIN 과 SYS_ADMIN 을 미리 add 해 두어 예외를 없앤다
4. privileged 를 켜서 capability 를 신경 쓰지 않게 한다
`hostPID: true` 를 설정한 파드가 갖게 되는 능력은?
1. 노드의 모든 프로세스를 볼 수 있고 접근 가능하면 그 프로세스에 신호를 보낼 수 있다
2. 노드의 파일시스템 전체를 읽고 쓸 수 있다
3. 노드의 네트워크 인터페이스를 그대로 쓸 수 있다
4. 노드의 커널 모듈을 적재할 수 있다
Secret 을 환경변수 대신 볼륨으로 마운트하라고 권하는 이유로 가장 적절한 것은?
1. 환경변수는 자식 프로세스로 상속되고 크래시 덤프나 프로세스 정보로 노출되기 쉽기 때문
2. 환경변수로 주입한 값은 암호화되지 않고 볼륨은 암호화되기 때문
3. 환경변수는 길이 제한이 있어 인증서를 담을 수 없기 때문
4. 환경변수로 주입하면 apiserver 가 Secret 을 평문으로 저장하기 때문
쿠버네티스 Secret 의 base64 인코딩에 대한 올바른 이해는?
1. 대칭키 암호화의 일종이라 키가 없으면 읽을 수 없다
2. 단순한 인코딩이라 누구나 되돌릴 수 있고 기밀성을 제공하지 않는다
3. 해시 함수라 원본을 복원할 수 없다
4. 전송 구간을 보호하기 위한 서명 방식이다
RBAC 에서 `get`, `list`, `watch` 를 모두 허용할 때 특히 주의할 점은?
1. list 와 watch 는 오브젝트 전체를 돌려주므로 이름을 몰라도 내용을 통째로 읽을 수 있다
2. get 만 있으면 이름을 알아도 내용을 읽을 수 없다
3. watch 는 읽기가 아니라 쓰기 동사로 분류된다
4. 세 동사는 resourceNames 로 제한할 때 모두 동일하게 동작한다
감사 로그(audit log)의 레벨 중 요청 본문과 응답 본문을 모두 기록하는 것은?
1. Metadata
2. Request
3. RequestResponse
4. None
ResourceQuota 와 LimitRange 를 보안 관점에서 쓰는 이유는?
1. 네임스페이스 하나가 클러스터 자원을 독점해 다른 워크로드를 굶기는 일을 막는다
2. 파드가 다른 네임스페이스의 오브젝트를 읽지 못하게 막는다
3. 컨테이너 이미지의 취약점을 검사한다
4. 파드 사이의 네트워크 통신을 제한한다
감사 로그를 apiserver 노드의 로컬 파일로만 남길 때의 약점은?
1. 그 노드를 장악한 공격자가 자기 흔적을 지울 수 있다
2. 감사 로그가 etcd 를 가득 채워 클러스터가 멈춘다
3. 감사 로그가 평문이라 전송 중 도청된다
4. 감사 로그의 시간대가 노드마다 달라진다
STRIDE 의 Spoofing 위협에 대응하는 쿠버네티스의 통제로 가장 적절한 것은?
1. ResourceQuota 로 네임스페이스 사용량을 제한한다
2. 감사 로그에 요청을 기록한다
3. readOnlyRootFilesystem 으로 파일 변조를 막는다
4. 상호 TLS 와 강한 인증으로 요청자의 신원을 검증한다
컨테이너 탈출(container escape)로 이어질 가능성이 가장 높은 설정은?
1. 파드에 리소스 limits 를 지정하지 않은 경우
2. 파드가 ClusterIP 서비스로 노출된 경우
3. 파드가 privileged 로 실행되며 호스트 경로를 마운트한 경우
4. 파드의 복제본 수가 하나뿐인 경우
공격자가 파드 안에서 코드 실행에 성공했을 때 가장 먼저 노리는 것으로 알려진 대상은?
1. 마운트된 ServiceAccount 토큰과 환경변수 속의 자격증명
2. 컨테이너 이미지의 레이어 구조와 빌드 시각 정보
3. 노드의 커널 버전과 배포판 이름 같은 시스템 정보
4. 파드에 붙은 라벨과 어노테이션의 메타데이터
클라우드 메타데이터 서비스로의 접근을 파드에서 막아야 하는 이유는?
1. 메타데이터 서비스가 파드의 로그를 외부로 전송하기 때문
2. 메타데이터 서비스가 파드의 DNS 해석을 가로채기 때문
3. 메타데이터 서비스 접근이 노드의 CPU 를 크게 소모하기 때문
4. 메타데이터 서비스에서 노드에 붙은 클라우드 역할의 자격증명을 받아 클러스터 밖 자원까지 넘볼 수 있기 때문
권한 상승 경로 중 '노드 접근을 통한 상승'에 해당하는 것은?
1. RBAC 의 bind 동사를 이용해 더 강한 ClusterRole 을 자신에게 연결한다
2. 어드미션 웹훅을 등록해 새로 만들어지는 파드를 변형한다
3. CRD 를 등록해 새 리소스 종류를 추가한다
4. 노드에 스케줄된 다른 파드의 Secret 볼륨을 kubelet 의 디렉터리에서 읽는다
공급망 공격 중 '의존성 혼동(dependency confusion)'을 가장 정확히 설명한 것은?
1. 빌드 서버가 감염되어 산출물에 악성 코드가 삽입되는 것
2. 이미지 태그를 바꿔치기해 다른 이미지를 배포하게 하는 것
3. 내부 전용 패키지와 같은 이름의 패키지를 공개 저장소에 올려 빌드가 그것을 당겨 가게 하는 것
4. 레지스트리 자격증명을 훔쳐 이미지를 몰래 내려받는 것
클러스터에 지속성을 확보하려는 공격자가 어드미션 웹훅을 노리는 이유는?
1. 웹훅이 감사 로그를 남기지 않아 흔적이 사라지기 때문
2. 웹훅이 etcd 에 직접 접근할 수 있기 때문
3. 웹훅이 노드의 커널 파라미터를 바꿀 수 있기 때문
4. 웹훅이 새로 만들어지는 모든 오브젝트를 변형할 수 있어 지워도 다시 심을 수 있기 때문
이미지에 취약점 스캔을 붙였는데도 놓치기 쉬운 위험은?
1. 베이스 이미지에 포함된 오래된 시스템 라이브러리
2. 애플리케이션 의존성의 알려진 CVE
3. 이미지 안에 커밋된 자격증명 같은 비밀값
4. 이미지에 포함된 취약한 인터프리터 버전
임시 컨테이너(ephemeral container)를 디버깅에 쓸 때 보안상 유의할 점은?
1. 대상 파드의 namespace 를 공유하므로 그 파드의 프로세스와 파일에 접근할 수 있다
2. 대상 파드를 재시작시키므로 서비스가 잠시 끊긴다
3. 대상 파드의 이미지가 교체되어 원래 버전을 알 수 없게 된다
4. 감사 로그에 남지 않아 사용 이력을 추적할 수 없다
런타임 탐지 도구가 빌드 시점 검사와 다르게 잡아낼 수 있는 것은?
1. 이미지에 들어 있는 취약한 패키지 버전
2. 매니페스트의 잘못된 securityContext 설정
3. 실행 중 컨테이너가 셸을 띄우거나 예상 밖의 파일에 접근하는 행위
4. Dockerfile 에 남은 하드코딩된 토큰
Pod Security Admission 의 세 모드 중 `warn` 이 하는 일은?
1. 위반 파드를 거부하고 이유를 응답에 담는다
2. 위반 사실을 감사 로그의 어노테이션으로만 남긴다
3. 위반 사실을 요청자에게 경고 메시지로 돌려주되 생성은 허용한다
4. 위반 파드를 생성한 뒤 일정 시간이 지나면 삭제한다
Pod Security Standards 의 세 프로파일 중 `baseline` 의 위치로 올바른 것은?
1. 아무 제약이 없는 가장 느슨한 프로파일이다
2. 가장 엄격해 비특권 실행과 capability 제거까지 요구한다
3. 알려진 권한 상승을 막되 흔한 워크로드가 대부분 통과하도록 만든 중간 프로파일이다
4. 네임스페이스가 아니라 파드마다 개별 지정해야 하는 프로파일이다
PSA 를 네임스페이스 라벨로 적용할 때의 한계로 올바른 것은?
1. 네임스페이스를 새로 만들면 라벨이 자동으로 사라진다
2. 라벨을 붙여도 kubelet 이 무시할 수 있다
3. 한 네임스페이스에는 하나의 모드만 지정할 수 있다
4. 이미지 출처나 레지스트리 같은 파드 보안 표준 밖의 조건은 검사하지 못한다
이미지 서명 검증을 어드미션 단계에서 강제하면 얻는 것은?
1. 이미지 안의 취약점이 자동으로 제거된다
2. 이미지 크기가 줄어 배포가 빨라진다
3. 신뢰하는 파이프라인이 만들지 않은 이미지가 클러스터에 들어오지 못한다
4. 이미지가 실행 중에 변조되어도 즉시 탐지된다
외부 시크릿 관리 시스템(Vault 등)을 연동해도 남는 위험은?
1. 외부 시스템이 값을 암호화해 저장하지 않는다
2. 쿠버네티스가 외부 시스템을 지원하지 않아 연동 자체가 불가능하다
3. 외부 시스템을 쓰면 시크릿 회전을 할 수 없게 된다
4. 값을 가져올 권한을 가진 워크로드가 침해되면 결국 평문 시크릿에 닿는다
노드 자체를 강화하는 조치로 가장 적절한 것은?
1. 노드에 개발자용 SSH 계정을 만들어 두어 조사에 대비한다
2. 노드에 특권 컨테이너를 상시 띄워 두어 문제를 즉시 고칠 수 있게 한다
3. 불필요한 패키지와 서비스를 제거하고 kubelet 설정 파일의 권한을 좁힌다
4. 노드의 방화벽을 꺼서 진단을 쉽게 한다
gVisor 나 Kata Containers 같은 샌드박스 런타임을 쓰는 이유는?
1. 컨테이너 이미지의 크기를 줄이기 위해
2. 컨테이너 시작 시간을 단축하기 위해
3. 여러 노드의 컨테이너를 하나로 묶어 관리하기 위해
4. 호스트 커널과 워크로드 사이에 층을 하나 더 두어 커널 취약점의 영향을 줄이기 위해
RuntimeClass 의 역할로 올바른 것은?
1. 파드가 쓸 수 있는 최대 CPU 와 메모리를 정한다
2. 파드가 접근할 수 있는 네트워크 대역을 정한다
3. 파드가 어떤 컨테이너 런타임 설정으로 실행될지 고르게 한다
4. 파드의 이미지를 어느 레지스트리에서 받을지 정한다
멀티 테넌트 클러스터에서 테넌트 사이의 격리를 강화하는 조합으로 가장 적절한 것은?
1. 네임스페이스만 나누고 나머지는 기본값으로 둔다
2. 모든 테넌트를 하나의 네임스페이스에 두고 라벨로만 구분한다
3. 테넌트마다 별도의 kubeconfig 파일만 나눠 준다
4. 네임스페이스, RBAC, NetworkPolicy, 쿼터, 그리고 필요하면 노드 분리까지 함께 쓴다
OPA Gatekeeper 나 Kyverno 같은 정책 엔진이 PSA 위에 필요한 이유는?
1. PSA 가 어드미션 단계에서 동작하지 않기 때문
2. PSA 가 네임스페이스 단위로 적용되지 않기 때문
3. PSA 가 파드 이외의 리소스와 조직 고유 규칙을 다루지 못하기 때문
4. PSA 가 위반을 거부하지 못하고 경고만 남기기 때문
CIS Kubernetes Benchmark 를 가장 정확히 설명한 것은?
1. 공격자의 행위를 전술과 기법으로 분류한 지식 베이스다
2. 쿠버네티스 취약점에 번호를 부여하는 공식 데이터베이스다
3. 클라우드 제공자가 준수해야 하는 법적 규제다
4. 클러스터 구성 요소의 설정을 점검하는 항목별 권고와 검증 절차의 모음이다
NSA/CISA 쿠버네티스 하드닝 가이드가 강조하는 축으로 보기 어려운 것은?
1. 파드 보안 강화와 네트워크 분리
2. 인증·인가와 감사 로깅
3. 지속적인 업데이트와 취약점 점검
4. 단일 벤더 제품 도입을 통한 표준화
MITRE ATT&CK for Containers 를 실무에서 쓰는 방법으로 가장 적절한 것은?
1. 클러스터 설정이 기준을 충족하는지 항목별로 점검하는 체크리스트로 쓴다
2. 취약점의 심각도 점수를 계산하는 공식으로 쓴다
3. 알려진 공격 기법 목록에 대해 우리 탐지와 통제가 어디까지 닿는지 지도로 그린다
4. 감사 로그의 보존 기간을 정하는 규정으로 쓴다
컴플라이언스 자동화 도구가 클러스터에서 하는 일로 가장 적절한 것은?
1. 발견된 위반을 자동으로 고쳐 클러스터를 즉시 기준에 맞춘다
2. 규제 기관에 보고서를 직접 제출한다
3. 위반이 발견되면 해당 워크로드를 삭제한다
4. 정해진 기준에 대해 현재 설정을 주기적으로 검사하고 통과·실패를 증거와 함께 남긴다
감사 정책(audit policy)을 설계할 때 흔한 실수는?
1. 읽기 요청은 기록하고 쓰기 요청은 제외하는 것
2. 네임스페이스별로 서로 다른 레벨을 지정하는 것
3. 모든 리소스에 가장 자세한 레벨을 걸어 저장 비용이 폭발하고 민감한 값까지 로그로 새는 것
4. 인증 실패 요청을 기록 대상에 포함하는 것
보안 기준을 통과했다는 보고서가 있는데도 사고가 나는 이유로 가장 설득력 있는 것은?
1. 보안 기준이 서로 모순되는 항목을 담고 있기 때문
2. 기준을 통과하면 로그를 남기지 않아도 되기 때문
3. 기준을 통과한 클러스터는 감시 대상에서 제외되기 때문
4. 기준은 점검한 시점의 설정만 보증하고 그 뒤의 변경과 기준 밖의 위험은 담지 못하기 때문