이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 클라우드 환경 보안 설정을 담당하면서 기본기를 다진 경험이 있습니다. 처음에 IAM 정책을 와일드카드로 넓게 열어뒀다가 최소 권한 원칙이 왜 중요한지를 보안 스터디에서 배운 뒤 즉시 수정했습니다. 각 서비스가 실제로 쓰는 리소스만 허용하도록 역할을 분리했고, Security Group 규칙도 포트 단위로 제한했습니다.
설정 변경 이력을 남기는 것도 보안의 일부임을 그때 처음 실감했는데, 이후로는 인프라 변경을 IaC 코드로 관리해 PR로 리뷰받는 방식에 익숙해졌습니다. 지금도 새 클라우드 리소스를 만들 때 권한 범위를 먼저 정의하는 습관을 유지하고 있습니다.
클라우드 보안 설정을 강화하는 과정에서 어디까지가 충분한 보안인지 기준이 모호해 어려움을 겪었습니다. IAM 정책을 좁혔는데도 실제로 충분한지 규제 기준에 맞는지를 혼자 판단하기 어려웠습니다. 팀 내 보안 담당 선배에게 도움을 요청해 ISMS-P 인증 기준에서 클라우드 보안 통제 항목이 어떻게 구성돼 있는지 설명을 들었습니다. 액세스 로그 수집, 이상 접근 탐지, 암호화 키 관리가 각각 별도 통제 항목으로 분류된다는 것을 그때 처음 구조적으로 이해했습니다. 이후 스스로 보안 설정을 점검할 때 ISMS 체크리스트를 기준으로 빠진 항목을 확인하는 방식을 쓰게 됐습니다. 혼자 감으로 설정하는 것과 기준을 알고 설정하는 것은 접근 방식 자체가 다르다는 것을 배운 경험이었습니다.
팀 프로젝트 인프라 점검 중 S3 버킷이 의도치 않게 퍼블릭으로 열려 있던 것을 발견했습니다. 처음에는 파일 업로드 편의를 위해 정책을 넓게 열었는데, 그 설정이 버킷 전체에 적용돼 있다는 것을 나중에야 확인했습니다. 즉시 퍼블릭 액세스 차단 설정을 활성화하고, 프리사인드 URL 방식으로 임시 접근 권한만 발급하는 방식으로 교체했습니다. 조치 후에는 AWS Config를 활성화해 버킷 설정이 변경될 때 자동으로 규칙 위반을 감지하도록 했습니다. 이 경험으로 클라우드에서는 편의를 위해 연 설정이 보안 취약점이 되는 경우가 많다는 것을 직접 느꼈고, 변경할 때마다 영향 범위를 명시적으로 확인하는 습관이 생겼습니다.
보안은 최초 설정보다 이후 변경을 통제하는 것이 더 어렵다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 코빗 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.