플랫폼 엔지니어링 10 - 보안과 거버넌스

가드레일과 게이트의 차이

전통적인 보안 프로세스는 게이트 방식으로 동작한다. 개발자가 무언가를 만들고, 보안 리뷰에 제출하고, 3주를 기다리고, 지적 사항을 받고, 수정하고, 다시 제출하고, 또 기다린다. 프로세스의 끝에서 한 번에 검증하는 구조이기 때문에 속도가 느리고 병목이 될 수밖에 없는 것이다.

플랫폼 엔지니어링은 이러한 게이트를 가드레일로 전환한다. 프로세스의 끝에서 막는 대신, 전 과정에 걸쳐 안내하는 방식이다.

가드레일이 제대로 구축되면 안전한 방법이 곧 가장 쉬운 방법이 된다. 개발자가 보안을 의식적으로 신경 쓸 필요 없이, 골든 패스를 따르기만 해도 자연스럽게 보안 요구 사항을 충족하게 되는 것이다.

시프트 레프트 보안

시프트 레프트란 보안 점검을 개발 라이프사이클의 뒷단계에서 앞단계로 옮기는 것을 의미한다.

전통적:      코드 --> 빌드 --> 테스트 --> 배포 --> 보안 리뷰 (너무 늦음)
시프트 레프트: 보안 점검 <-- <-- <-- <-- 모든 단계에 내장

구체적으로 살펴보면, IDE 단계에서는 린터가 커밋 전에 시크릿 유출을 감지한다. Pre-commit 훅은 자격 증명이 버전 관리 시스템에 유입되는 것을 차단하는 역할을 한다. CI 단계에서는 의존성 스캔, 정적 분석(SAST), 이미지 스캔이 자동으로 실행된다. 배포 시점에는 어드미션 컨트롤러가 정책을 강제 적용한다.

이 모든 과정이 빠르고 자동화되어 있기 때문에 보안 이슈를 며칠이 아닌 몇 초 만에 발견하고 수정할 수 있게 되는 것이다. 문제를 늦게 발견할수록 수정 비용이 기하급수적으로 증가한다는 점을 고려하면, 앞단계로 옮기는 것이 왜 중요한지 이해할 수 있다.

Policy as Code

수동 리뷰는 팀과 서비스가 늘어날수록 확장되지 않는다. 사람이 모든 배포를 일일이 검토하는 것은 물리적으로 한계가 있기 때문이다.

Policy as Code는 보안 규칙을 자동으로 실행되는 코드로 표현하여 이 문제를 해결한다. OPA(Open Policy Agent)는 범용 정책 엔진으로 다양한 환경에 적용할 수 있고, Kyverno는 Kubernetes 네이티브 정책 도구로 클러스터 환경에 특화되어 있다.

# Kyverno: root 실행 금지
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-root
spec:
  rules:
    - name: check-runAsNonRoot
      match:
        resources:
          kinds: [Pod]
      validate:
        message: "컨테이너는 root로 실행할 수 없습니다"
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsNonRoot: true

규칙을 한 번 코드로 작성하면 이후로는 자동으로 적용된다. 사람의 기억이나 체크리스트에 의존할 필요가 없어지는 것이다. 규칙이 코드이기 때문에 버전 관리도 가능하고, 변경 이력을 추적하는 것도 가능하며, 리뷰와 테스트를 거쳐 배포할 수도 있다.

공급망 보안과 시크릿 관리

작성한 코드가 아무리 안전해도 의존성에 취약점이 있으면 전체 시스템이 위험해진다. 코드는 의존성만큼만 안전한 셈이다.

SBOM(Software Bill of Materials)은 빌드 시점에 모든 구성 요소의 목록을 생성하여 무엇이 포함되어 있는지를 투명하게 보여준다. 이미지 스캐닝은 배포 전에 알려진 취약점을 잡아내는 역할을 한다. Cosign은 이미지가 변조되지 않았음을 서명으로 검증하고, 의존성 고정(dependency pinning)은 버전을 명시적으로 잠가서 공급망 공격을 방지한다.

시크릿 관리 역시 플랫폼이 다뤄야 하는 중요한 영역이다. 시크릿은 반드시 안전한 저장소에 보관해야 하며, 코드에 포함되어서는 안 된다. Vault는 중앙 집중식 시크릿 저장소로 가장 널리 쓰이고, Sealed Secrets는 Git에 암호화된 형태로 시크릿을 저장할 수 있게 해준다. External Secrets Operator는 외부 저장소의 시크릿을 Kubernetes로 자동 동기화하는 역할을 한다.

플랫폼 팀이 이 모든 도구를 표준 파이프라인에 내장하면, 각 팀은 별도로 설정할 것 없이 기본적으로 보안이 적용된 환경에서 작업하게 되는 것이다.

RBAC

환경별 접근 제어도 플랫폼이 기본으로 제공해야 하는 영역이다. dev와 staging 환경에서는 자유롭게 배포할 수 있지만, 프로덕션 환경에서는 승인 절차를 거치도록 구성하는 것이다. 각 팀은 자기 팀의 네임스페이스에만 접근 권한을 갖게 되어, 다른 팀의 리소스에 실수로 영향을 미치는 상황을 방지할 수 있다.

새로운 팀이 온보딩되면 네임스페이스와 역할이 자동으로 생성되어야 한다. 일주일째 큐에서 대기 중인 인프라 요청 티켓을 통해서가 아니라, 플랫폼의 셀프서비스를 통해 즉시 처리되어야 하는 것이다.

다음 내용

개발자가 올바른 행동을 매번 기억하는 것에 의존하는 보안 모델은 조직 규모가 커지면 반드시 실패한다. 골든 패스에 스캐닝, 정책 적용, 시크릿 관리가 기본으로 내장되어 있으면 마찰 없이 컴플라이언스를 확보할 수 있는 것이다.

다음 포스트에서는 플랫폼 팀을 구성하는 방법을 다룬다.