같은 지적이 다시 나오지 않게

보안팀이 CSPM(클라우드 설정 점검 도구)으로 4개 클라우드를 점검해 지적 목록을 주면, 제가 주 담당자로서 분류와 조치를 주도했습니다.

첫 해 조치율은 약 60%였습니다. 라이브 서비스에 영향을 줄 수 있다는 이유로 조치가 미뤄지는 항목이 있었기 때문입니다.

① 서비스 영향도 기준으로 분류

칸을 누르면 처리 방식이 나옵니다.

② 막을 수 없을 때는 보완 통제로 합의

특정 포트를 전면 차단하라는 지적이 있었지만, 그 포트를 서비스가 실제로 쓰고 있었습니다.

“차단 / 유지” 둘 중 하나가 아니라, 위험을 줄이는 다른 방법을 제시했습니다.

• 접근 출발지를 필요한 IP 대역으로만 제한
• 웹 경로에는 WAF(웹 방화벽) 규칙 추가

노출 범위가 “인터넷 전체”에서 “필요한 대역”으로 줄어 보안팀도 받아들였고, 개발팀은 서비스 변경 없이 적용할 수 있었습니다.

③ 반복 지적은 Terraform 기본값으로

지적을 사람이 매번 고치면, 새 리소스를 만들 때 같은 문제가 다시 생깁니다. 그래서 원인을 “사람이 깜빡함”이 아니라 “기본값이 안전하지 않음” 으로 보고, Terraform 모듈의 기본 설정 자체를 바꿨습니다. 코드 리뷰 체크리스트도 함께 만들었습니다.

기본값 예시(설명용)

# 관리 포트를 인터넷 전체(0.0.0.0/0)에 여는 것을 코드 단계에서 막음
variable "admin_ingress_cidrs" {
  type = list(string)
  validation {
    condition     = !contains(var.admin_ingress_cidrs, "0.0.0.0/0")
    error_message = "관리 포트에 0.0.0.0/0 허용 금지. 필요한 대역만 지정하세요."
  }
}

# 디스크는 기본으로 암호화
resource "aws_ebs_volume" "this" {
  encrypted = true
  # ...
}

④ 배포 파이프라인에 관문 추가

GitLab CI/CD와 Jenkins 파이프라인에 Terraform validate(문법·설정 검사)와 plan(변경 미리보기) 단계를 필수 관문으로 넣었습니다. 모듈의 검증 조건에 걸리는 변경은 이 단계에서 실패해 배포로 넘어가지 못합니다.

개발자 코드 변경 → terraform validate (실패하면 배포 중단) → terraform plan → 리뷰·체크리스트 확인 → apply 배포

감사 조치율이 첫 해 약 60%에서 이듬해 85% 이상으로 올랐습니다.

새로 만드는 리소스는 처음부터 안전한 설정으로 시작합니다.

보안 담당자가 “안 된다”로 끝내면 대화가 끝나고, 대안을 들고 가야 실제로 조치가 일어납니다.

한 번 조치하는 것보다 다시 생기지 않는 구조가 중요하고, 그 구조는 개발팀이 받아들일 수 있을 때 유지됩니다.