퀴즈: 시크릿 취급

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

1. 애플리케이션이 시작할 때 `.env` 를 읽고 곧바로 그 파일을 삭제합니다. 시크릿이 보호됩니까?

   1. 보호된다. 파일이 이미 지워졌으니 나중에 들어와도 누구도 읽을 수 없다
   2. 보호된다. 환경변수는 커널이 암호화한다
   3. 보호되지 않는다. 값이 환경변수에 들어갔다면 `/proc/<pid>/environ` 으로 프로세스가 사는 동안 계속 읽힌다
   4. 파일 권한이 600 이었다면 보호된다

2. Dockerfile 에서 `ARG NPM_TOKEN` 으로 받아 `.npmrc` 를 만들고 마지막에 `rm ~/.npmrc` 로 지웠습니다. 안전합니까?

   1. 안전하지 않다. 파일은 하위 레이어에, 값은 빌드 히스토리에 남는다
   2. 안전하다. 마지막 레이어에 파일이 없다
   3. 안전하다. ARG 는 이미지에 남지 않는다
   4. 안전하다. squash 옵션 없이 빌드했다면 문제없다

3. 빌드 중에 사설 레지스트리 자격증명이 꼭 필요할 때 올바른 방법은?

   1. `ARG` 로 받아 쓰고 마지막에 `rm` 으로 파일을 지워 흔적을 없앤다
   2. `RUN --mount=type=secret,id=npmrc,target=/root/.npmrc` 로 BuildKit secret mount 를 쓴다
   3. `ENV` 로 값을 넣고 빌드가 끝난 뒤 `docker image rm` 으로 중간 이미지를 정리한다
   4. 베이스 이미지에 미리 넣어 둔다

4. 저장소에 커밋된 API 키를 발견했습니다. 조치 순서로 올바른 것은?

   1. 히스토리 정리 → 폐기 → 영향 조사
   2. 폐기 → 영향 조사 → 히스토리 정리
   3. 영향 조사 → 히스토리 정리 → 폐기
   4. 히스토리 정리만 하면 충분하다

5. 키 로테이션이 계획서대로 되지 않는 가장 흔한 근본 원인은?

   1. 키 길이가 짧아서
   2. 시크릿 저장소가 없어서
   3. 코드가 '유효한 키는 정확히 하나'라고 가정하고 있어서
   4. 로테이션 주기가 너무 길어서

6. 시크릿 탐지 도구의 한계로 **틀린** 설명은?

   1. 사전 커밋 훅은 `--no-verify` 로 우회되므로 훅은 편의 장치이고 통제 장치는 서버 검사다
   2. 규칙은 `AKIA`, `sk_live_` 처럼 형태가 뚜렷한 값에 잘 듣고 사내 자체 형식은 놓치기 쉽다
   3. 스캐너가 통과했다면 그 저장소에 시크릿이 없다는 것이 보장된다
   4. 스캐너는 코드 저장소만 보고 위키, 이슈 첨부, 채팅 로그는 보지 못한다