K-ISMS 와 GitOps 가 충돌하는 6 지점 — 한국 공공기관에서 GitOps 가 실패하는 진짜 이유

작년 가을, 한국 공공기관 한 곳에서 GitOps 도입을 시도했다. 6개월 후 철회 결정. 기술 문제 가 아니라 K-ISMS 인증 통제와의 충돌 이 이유였다.

이 글은 그 6 지점이다. 글로벌 GitOps 자료에는 이 충돌이 전혀 안 나온다 — 한국·일본의 공공섹터에만 해당하는 문제니까.

충돌 1 — 권한 부여자 와 행위자 가 같은 사람일 수 없다

K-ISMS 통제 항목 중 직무 분리 (segregation of duties) — 변경을 승인하는 사람 과 적용하는 사람 이 달라야 한다.

GitOps 의 표준 흐름은:

1. 개발자가 git PR 작성
2. 리뷰어가 승인 (merge)
3. CD 시스템이 자동으로 배포

승인자가 사람 인데 적용자가 자동화 시스템 이라 직무 분리 정신 은 만족된다는 게 글로벌 해석. 한국 K-ISMS 심사관의 다수 의견은 자동화 시스템은 사람의 권한으로 작동 하므로 결국 같은 사람이 둘 다 한 것 이라는 해석.

우회: PR 승인을 2명 이상 으로 만들고, 그 둘 중 하나가 자동 배포의 트리거를 manual 로 누름. 기계가 자동 으로 안 가게 만드는 것.

충돌 2 — 변경 기록 이 git 에만 있는 게 불충분

GitOps 의 가정 — git 이 진실의 단일 출처. 변경 이력은 git log.

K-ISMS 의 변경 통제 통제 — 변경 기록이 접근 통제된 별도 시스템 에 변조 불가능한 형태로 보존되어야 한다. git 자체 는 force-push 가능 하므로 변조 가능 으로 해석됨.

우회: git push 받은 시점에 별도 append-only audit log 에 commit hash 와 author 를 동시 기록. force-push 가 일어나도 audit log 에 원본 hash 가 남음.

충돌 3 — 민감 정보 가 git 에 있으면 안 됨

GitOps 는 환경 설정도 git 에 둔다. 하지만 K-ISMS 는 민감 설정 (DB endpoint, 내부 IP, 인증 키) 이 접근 통제된 별도 secret store 에 있어야 함.

우회: GitOps repository 에는 placeholder 만, 실제 값은 Vault / KMS 참조 만. CD 시점에 주입.

이게 거의 표준이지만, 심사 시점에 placeholder 가 진짜 값을 가리키는 키 인지 각각 검증 해야 함. 자동화하지 않으면 분기 1회 수일 의 작업.

충돌 4 — 접근 권한 회수 가 즉시 안 일어남

K-ISMS — 사용자의 접근 권한 회수 는 퇴사 시 24시간 안 에 일어나야 함.

GitOps — 사용자가 git push 권한 을 잃어도, 이미 푸쉬된 commit 은 그대로 유효. 그 commit 으로부터 자동 배포 가 퇴사 후 일어나는 시나리오 가능.

우회: 퇴사 절차에 해당 사용자가 마지막 24시간 내 push 한 commit 의 별도 검증 을 박음. 또는 24시간 안에 자동 배포되지 않는 staging 단계 를 강제.

충돌 5 — 정기 점검 보고서 가 git 으로 안 만들어짐

K-ISMS — 접근 권한·변경 이력·보안 사건 의 정기 점검 보고서 를 분기 1회 작성.

GitOps 의 git log 만으로는 이 보고서가 자동 으로 만들어지지 않는다. 보고서는 사람이 검토했음을 증명 하는 형태여야 함 — 단순 데이터 dump 가 아니라 서명된 점검 결과.

우회: 분기 1회 자동 데이터 dump 후 사람이 서명하는 워크플로우. 이 과정이 자동화되지 않으면 분기마다 수일 인력.

충돌 6 — 외부 git 호스팅 서비스 사용 자체가 통제 위반

마지막. 가장 불편한 충돌 — K-ISMS 는 민감 자산 이 국내에 보존 되어야 함. github.com 이나 gitlab.com SaaS 에 host 된 GitOps repository 는 민감 자산이 해외에 있음 으로 해석 가능.

우회: 내부 git 서버 (GitLab self-hosted, Gitea, 사내 Bitbucket) 위에서 GitOps. 이건 우회가 아니라 유일한 답.

그래서 GitOps 를 도입할 수 없는가

도입 가능하다. 다만 글로벌 GitOps 가이드를 그대로 따르면 안 된다. 위 6 지점에 대한 6 가지 우회 가 처음부터 설계에 들어가야 한다. 6개월 후에 추가 하려면 기존 GitOps 인프라를 분해 해야 함.

위 6 지점의 우회를 처음부터 박은 한국 공공기관은 우리가 본 한 곳이다. 시간이 더 걸렸지만 (8개월 vs 일반 6개월) 심사 통과는 한 번에.

한국·일본 공공기관·금융사에서 GitOps 도입을 검토 중인 보안·DevOps 리드라면, 글로벌 GitOps 가이드를 펴기 전에 위 6 지점부터 점검하는 게 순서다. 6 지점을 모르는 채로 시작하면 심사 단계에서 알게 되고, 그 시점에는 이미 만들어 둔 GitOps 인프라를 분해하는 것 말고 답이 없다.