변경통제와 접근통제는 형제!
변경통제, 어디부터 봐야 할까?
우리는 보통 이렇게 나눈다.
App /DB /OS /Network
겉에서 안으로 들어가는 구조처럼 보이지만,
감사 관점에서의 중요성은 조금 다르다.
⸻
변경통제.
중요성의 본질은 ‘데이터’
결국 핵심은 하나다.
데이터가 안전한가?
그 데이터에 누가 접근할 수 있는가?
아무리 접근권한을 철저히 관리해도,
아무리 애플리케이션 변경을 철저히 관리해도,
아무리 형상관리 툴을 잘 써도,
데이터를 직접 만질 수 있다면 이야기는 달라진다.
⸻
그래서 Risk, DB (데이터 직접 통제) 직접 변경 권한자는?
왜냐하면,
DB 권한이 무너지면
다른 통제는 무기력해진다.
⸻
변경통제의 3요소
• 사전 승인
• 변경 이력 관리
• 최소 권한 부여
이 세 가지는 기본값이다.
⸻
그런데 말이다.
아무리
• 접근권한을 분리하고
• 데이터 변경은 승인받고
• 로그를 남기고
• 배포를 통제해도
개발자가 DBA 권한을 가지고 있다면?
그 순간,
승인 없이 직접 수정 가능
로그 우회 가능
통제 무력화 가능
감사인 입장에서 보면,
“통제 설계는 존재하나, 실효성은 없음.”
한 줄 평은 이거다.
DBA 권한이 개발자에게 있다면
변경통제는 서류상 존재할 뿐이다.
⸻
결국 답은
• 권한 분리 (SoD)
• DBA 독립성 확보
• 비상 접근은 통제된 프로세스로만
변경통제는 절차의 문제가 아니라
권한 구조의 문제다.
⸻
우리는 코드를 믿는 게 아니다.
우리는 구조를 본다.
데이터에 닿을 수 있는 손이 누구인가.
그게 감사의 시작이고,
끝이다.