530. 보안 조직 분리 정책 위반(SoD, Segregation of Duties)의 SW 통제 로직

핵심 인사이트 (3줄 요약)

1. 본질: 직무 분리(SoD, Segregation of Duties)는 "절대 권력은 절대 부패한다"는 철학 아래, 아무리 뛰어난 관리자라도 단독으로 회사 자금이나 핵심 시스템 코드를 결재/수정/삭제할 수 없도록, 하나의 권한을 물리적으로 두 명 이상의 다른 부서 사람에게 찢어놓는 거버넌스의 코어 룰이다.
2. 가치: 외부 해커의 화려한 기술(제로데이 등)보다 훨씬 파괴적이고 막기 힘든 **'합법적 권한을 가진 내부자(스파이, 횡령범)의 공격'**을 구조적으로 원천 차단한다. "내가 기안하고 내가 승인하는" 사기극을 막아내어 기업의 수백억 횡령 사고와 법적 감리(Compliance) 실패를 예방한다.
3. 융합: 종이 결재판의 시대를 끝내고, 소스 코드가 합쳐지기 전 무조건 동료 2명의 승인을 요구하는 Git의 'Branch Protection (2-Man Rule)', 그리고 결제 시스템의 승인 프로세스를 찢어놓는 **MSA 분산 워크플로우(Saga/Temporal)**와 결합하여 인프라 레벨의 완벽한 기계적 통제망을 이룬다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

• 개념: SoD(직무 분리)는 하나의 위험한 작업을 수행할 때, 그 작업을 시작하는 자(Maker)와 승인하는 자(Checker)를 100% 다른 사람(다른 Role)으로 강제 분리하는 정책이다. A가 돈을 보내는 버튼을 누르면, 돈이 나가지 않고 B의 화면에 알람이 뜬다. B가 승인(Approve) 버튼을 눌러야만 비로소 돈이 나간다. A와 B의 역할은 절대 한 사람이 가질 수 없다.

• 필요성: 한 개발자가 10년째 급여 시스템을 혼자 만들고 관리하고 배포까지 다 했다. 어느 날 그가 빚쟁이가 되자, 자기 급여 계좌의 0을 하나 더 붙인 코드를 몰래 짜서 아무런 제지 없이 라이브 서버에 배포했다. 회사 돈 수십억이 털렸다. **"시스템의 맹점을 가장 잘 아는 건 그 시스템을 만든 사람"**이다. 아무리 WAF(방화벽)가 튼튼해도 정문을 여는 마스터키를 혼자 들고 있는 내부자는 1초 만에 회사를 멸망시킬 수 있다. 인간의 양심을 묻고, 기계적인 감시와 견제의 족쇄(Checks and Balances)를 코드에 박아넣는 것이 모든 대기업 보안의 출발점이다.

• 💡 비유: 직무 분리(SoD)는 핵잠수함의 **'핵미사일 동시 발사 키'**와 똑같습니다. 핵미사일을 쏘는 버튼이 1개라면, 함장이 갑자기 미쳐서 혼자 버튼을 누르고 세계 대전을 일으킬 수 있습니다. 그래서 발사 키를 함장 1개, 부함장 1개로 쪼개어 목에 걸어줍니다. 미사일을 쏘려면 두 사람이 방의 양 끝에 서서 동시에 자기 열쇠를 꽂고 돌려야만 발사됩니다. 둘 중 한 명이 "이건 미친 짓이야!"라고 거부하면 미사일은 절대 나가지 않습니다.

• 등장 배경 및 발전 과정:

  1. 회계 장부의 시대: 원래 IT 용어가 아니라 회계/재무에서 왔다. "돈 통 만지는 놈이랑 장부 적는 놈을 분리해라"는 고전적인 은행의 횡령 방지 룰이었다.
  2. 모놀리식 IT의 독재자 (Sysadmin): 2000년대 IT 인프라에선 root 계정 하나를 가진 시스템 관리자가 신(God)이었다. 그가 DB 지우면 끝.
  3. 클라우드와 DevSecOps의 분할 통치 (현재): IT 시스템이 복잡해지고, 소스코드 한 줄이 100억의 가치를 가지게 되면서, "개발자는 코드를 짜되 배포를 못 하고, 운영자는 배포는 하되 코드를 못 건드리는" CI/CD 파이프라인의 거대한 권력 찢기(IAM Role 분리)가 데브옵스의 생존 헌법으로 진화했다.

• 📢 섹션 요약 비유: SoD 위반은 **'경찰관이 판사 역할까지 혼자 다 하는 것'**입니다. 경찰(개발자)이 도둑(코드)을 잡아 와서, 자기가 직접 징역 10년이라고 재판 판결(배포 승인)까지 내려버리면 억울한 사람(버그)이 감옥에 가도 막을 자가 없습니다. 기소하는 자와 판결하는 자의 룰을 엄격하게 나누는 것이 삼권분립이자 소프트웨어의 정의(Justice)입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. SoD의 3대 핵심 분리 영역 (어디를 찢을 것인가?)

아키텍트는 시스템을 짤 때 다음 3가지 영역에서 권력이 합쳐지는(Toxic Combination) 것을 현미경으로 찾아 썰어버려야 한다.

1. 개발(Dev)과 운영(Ops)의 분리
   • 개발자는 Test 환경까지만 접근(Read/Write)할 수 있다. Production(라이브 서버)에는 접근조차 불가능해야 한다.
   • 라이브 서버 배포는 오직 파이프라인 기계(Jenkins)나, 권한을 받은 별도의 운영팀(Ops)만이 버튼을 누를 수 있다. (개발자가 자기가 짠 백도어를 몰래 실서버에 올리는 짓 원천 차단)
2. 보안(Security)과 감사의 분리
   • 보안팀이 방화벽 룰(Policy)을 세팅한다. 그런데 그 룰이 잘 지켜지고 있는지 감시하는 로그(Audit Log)를 보안팀이 또 볼 수 있다면? 보안팀이 방화벽 열고 놀다가 자기가 로그를 지우면 완전 범죄다. (527장 연계)
   • 로그를 삭제하거나 열람하는 권한은 보안팀이 아닌, 완전히 독립된 '감사(Audit) 부서'만 가지게 찢어놔야 한다.
3. 업무(Business) 로직의 Maker-Checker 모델
   • 결제 시스템을 짤 때, 1,000만 원 이상 이체 시 1번 직원이 transfer() 함수를 부르면 상태(Status)가 PENDING(대기)으로 멈춘다. 다른 직원이 로그인해서 approve()를 때려야만 COMPLETE(완료)로 넘어가는 유한 상태 기계(State Machine) 아키텍처를 비즈니스 로직 최하단에 강제로 심어야 한다.

2. SoD 위반 탐지 아키텍처 (Access Matrix)

권한을 분리했다고 끝이 아니다. 주니어 퇴사하고 시니어 들어오며 룰이 꼬인다.

• 권한 매트릭스 (Access Matrix):

  • 세로축에 유저(User), 가로축에 권한(Permission)을 둔 엑셀표(DB)다.
  • 아키텍트는 룰을 건다. Rule 1: 만약 User_A가 [송금_기안] 권한을 가졌다면, 시스템은 물리적으로 User_A에게 [송금_승인] 권한이 들어가는 것을 막아라(Mutual Exclusion).
  • IAM(Identity and Access Management) 솔루션에 이 상호 배제(Conflict of Interest) 로직을 넣어, 관리자가 실수로 A에게 두 권한을 동시에 주려 하면 UI 화면에서 시뻘건 에러를 뱉으며 체크박스 클릭을 튕겨내 버리는 기계적 통제가 필수다.

• 📢 섹션 요약 비유: 이 과정은 화학 공장의 **'반응 금지 물질 분리 보관'**과 똑같습니다. A 약품(개발 권한)과 B 약품(배포 권한)은 각자 있을 땐 좋은 일꾼이지만, 두 개가 한 사람의 주머니에 합쳐지는 순간 핵폭발(횡령/해킹)이 일어나는 맹독성 결합(Toxic Combination)입니다. 시스템은 관리자가 실수로라도 이 두 약품을 같은 상자에 넣으려 할 때 뚜껑이 안 닫히게 강제로 밀어내는 방폭 설계입니다.

Ⅲ. 융합 비교 및 다각도 분석

1. RBAC (역할) vs SoD (직무 분리)

초보자들은 "Role 잘 나눴으니까 SoD도 된 거 아니야?"라고 착각한다.

과목 융합 관점

• 데브옵스 (GitOps와 2-Man Rule 융합): 인프라를 테라폼 코드로 짜는 시대(IaC)다. 개발자가 테라폼으로 "DB 방화벽 0.0.0.0으로 다 열어줘"라고 짜서 Git Push를 때린다. 젠킨스는 이걸 그대로 AWS에 배포한다? SoD의 완벽한 붕괴다. 아키텍트는 깃허브(GitHub) 레포지토리에 **Branch Protection Rule**을 걸어버린다. 개발자가 짠 테라폼 코드는 무조건 Pull Request(PR)로 막히고, 개발자 본인이 아닌 최소 1명 이상의 다른 시니어 개발자나 보안 담당자가 Approve(승인) 버튼을 눌러야만(Checker 역할) 젠킨스가 코드를 물고 가도록 파이프라인의 허리(허브)를 뚝 끊어 분할(Segregation)시켜야 데브섹옵스가 완성된다.

• 클라우드 / IAM (권한 경계와 OPA): AWS IAM 정책을 짤 때 SoD를 위반하기 십상이다. 개발자에게 "S3 버킷을 만들 권한"은 주되, "S3 버킷을 삭제할 권한"이나 "버킷 권한 룰을 바꿀 권한"은 분리해서 관리자에게 넘겨야 한다. 하지만 1만 개의 IAM 룰을 눈으로 비교할 순 없다. 아키텍트는 CIEM(Cloud Infrastructure Entitlement Management) 스캐너나 OPA(Open Policy Agent)를 돌려서, "A라는 사람에게 쥐여진 100개의 권한 조각들을 짬뽕해 보니, 결국 혼자서 DB 지울 수 있는 절대 권력이 완성되는데?"라는 룰셋 충돌(SoD Violation)을 기계가 미리 엑스레이 찍어 잡아내는 거버넌스를 구축해야 한다.

• 📢 섹션 요약 비유: RBAC가 호텔에서 **'손님은 1층, 직원은 2층, 사장님은 3층 카드키를 나눠주는 것'**이라면, SoD는 사장님이라도 금고가 있는 3층 방에 들어갔을 때 '금고 다이얼은 경비팀장이 돌리고, 열쇠는 사장님이 꽂아야만' 돈을 꺼낼 수 있게 사장님의 절대 권력을 반으로 쪼개서 분산시켜 버리는 권력 해체술입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

1. 시나리오 — '슈퍼 개발자'의 편리함이 낳은 내부자 로직 조작 대참사: 스타트업에서 5년 차 시니어 개발자가 신(God)으로 군림했다. 그는 자기가 짠 코드를, 자기가 리뷰 승인하고(Git), 자기가 젠킨스 버튼을 눌러서, 자기가 권한을 가진 라이브 서버 DB로 배포했다. 아무도 그의 코드를 검사하지 않았다. 어느 날 그가 퇴사하면서, 경쟁사로 고객 이메일을 매일 밤 전송하는 백도어 배치(Batch) 코드를 몰래 심어두고 배포해 버렸다. 3달 뒤 발견됐지만, 이미 수백만 고객의 데이터가 털린 뒤였다.

   • 아키텍트의 해결책: 개발/운영/보안 직무 통폐합에 따른 견제(Checks) 상실이다. 스타트업이라 인력이 없다는 건 변명이 안 된다. 아키텍트는 1) 개발자가 운영 DB에 접속하는 권한을 원천 차단하고 오직 로그(Log)만 볼 수 있게 눈을 가려야 한다. 2) Git Branch에 Require review from Code Owners 옵션을 걸어, 아무리 천재 개발자라도 자기 코드를 스스로 Merge(합병)하지 못하게 시스템적으로 마우스를 묶어버려야 한다. 3) 배포 권한은 개발자가 아닌 릴리즈 매니저(RM)나 기계적 룰(Tag 생성 시 배포)에 위임하여 완벽한 SoD 트라이앵글을 완성해야 회사가 1인 독재에 멸망하지 않는다.

2. 시나리오 — 휴면 계정 부활과 퇴사자 계정 재사용을 통한 SoD 우회 (꼼수): 회사가 SoD를 완벽히 짰다. 기안자(A)와 승인자(B)는 무조건 달라야 결제가 나간다. 그런데 B가 퇴사했다. 시스템 관리자인 C가 악마가 되었다. C는 A의 계정으로 100억짜리 기안을 냈다. 그리고 퇴사자 B의 껍데기 계정(휴면 계정)을 몰래 부활(Enable)시킨 뒤 자기가 로그인해서, B의 이름으로 승인(Approve) 버튼을 눌러 100억을 꿀꺽했다. 시스템은 "A가 기안하고 B가 승인했으니 SoD 완벽 준수!"라며 돈을 송금해 줬다.

   • 아키텍트의 해결책: 계정 생명주기(Identity Lifecycle) 관리와 낡은 고아 계정(Orphaned Account) 방치다. SoD 룰은 계정이 철저히 통제될 때만 성립한다. 아키텍트는 IAM(Identity Access Management) 시스템과 사내 인사망(HR)을 API로 100% 엮어버려야 한다(Automated Provisioning). B가 퇴사하여 인사망에서 '퇴직'으로 찍히는 0.1초의 찰나에, B의 회사 계정, VPN 권한, K8s 접속 권한 등 모든 IT 권리가 1초 만에 기계적으로 완전 삭제(Revoke)되도록 뼈대를 구축해야만 유령 계정을 통한 SoD 우회 사기극을 막을 수 있다.

도입 체크리스트

• 비즈니스적: 마이크로서비스 간 분산 트랜잭션(Saga Pattern)에서 SoD를 구현했는가? 모놀리식 시절엔 트랜잭션 1개 안에 if(A!=B)를 짜기 쉬웠다. MSA 시대엔 "기안"은 주문 서버에서 났고, "승인"은 결제 서버에서 난다. 아키텍트는 2개 서버에 찢어진 행위를 엮어서 SoD를 검사하기 위해, **상태 머신 오케스트레이터(AWS Step Functions, Temporal.io)**나 카프카(Kafka) 이벤트 소싱을 융합해야 한다. "주문 서버에서 날아온 Maker ID"와 "결제 서버에서 처리하려는 Checker ID"를 중앙 오케스트레이터가 대조하여, 같으면 트랜잭션을 강제 롤백(Compensation)시켜버리는 분산 환경용 SoD 거버넌스를 설계해야 한다.
• 기술적: 긴급 장애 대처 (Break-glass) 시나리오 시 SoD 예외 처리 룰이 있는가? 새벽 3시에 서버 DB가 뻗어서 회사가 1초에 1억씩 손해 보고 있다. 고치려면 DB 마스터 권한이 필요한데, SoD 룰 때문에 팀원 2명이 모여서 결재 버튼을 눌러야 열리게 해놨다. 한 명은 전화를 안 받는다. 서버 복구를 못 해서 회사가 망했다(보안 결벽증의 최후). 아키텍트는 이런 재난 상황을 위해 **'유리 깨기(Break-glass) 비상 계정'**을 만들어둬야 한다. 평소엔 비활성화지만, 위급 시 누구나 깰(사용할) 수 있다. 단, 이 유리를 깨는 순간 **CISO와 전 임원의 폰으로 비상 사이렌 알람이 울리고, 깬 놈이 시스템에서 친 모든 키보드 타이핑이 100% 동영상/텍스트로 녹화(감사 트레일)**되는 무시무시한 사후 책임(Accountability) 조건하에서만 SoD를 일시 우회하도록 숨통을 틔워줘야 한다.

안티패턴

• "슈퍼 관리자 (Super Admin) 계정 하나로 돌려쓰기": 회사에 1개밖에 없는 admin 계정 아이디와 비번을 슬랙(Slack) 공지방에 올려놓고, 개발자, 인프라, CS팀 10명이 그냥 그 계정 하나로 다 접속해서 일하는 야만적인 안티패턴. 누가 사고를 치고 돈을 빼갔는데 로그를 까보면 전부 [Action: admin] 이라고만 찍혀있어서 범인을 특정(Non-repudiation)할 수가 없어 수사가 종결된다. 모든 권한은 무조건 '개인(Individual)의 고유 계정'에 매핑되어야 하며, 공용 계정 사용은 기업 해킹 1순위 자살 행위다.

• 📢 섹션 요약 비유: 공용 계정 쓰기는 회사 건물 들어올 때 '경비실에 둔 마스터 출입증 1개'를 돌아가면서 목에 걸고 들어가는 것과 같습니다. 도둑질이 일어나서 CCTV를 까보니 "마스터 출입증"이 털어간 걸로 찍혀있습니다. 근데 그걸 철수가 걸었는지 영희가 걸었는지 알 길이 없습니다. 모두가 용의자이자 모두가 무죄가 되는 환장의 미궁입니다. 무조건 각자 얼굴과 이름이 박힌 내 출입증을 찍게 강제(1인 1계정)해야만 SoD와 감사(Audit)의 시곗바늘이 돌아가기 시작합니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• 머신러닝 기반 권한 꼬임 실시간 분석 (Identity Analytics): 현재는 권한 매트릭스를 사람이 엑셀로 짠다. 미래엔 회사가 1만 명으로 커지면서 "A는 B팀 소속인데 C프로젝트를 파견 갔고 D권한을 받았네?" 인간의 뇌로 SoD 충돌을 계산할 수 없다. AI가 매일 밤 전사 1만 명의 IAM(권한 덩어리) 그래프를 노드 연결로 분석한다. "어? 홍길동이 가진 권한 50개를 머신러닝으로 조합해 보니까, 얘 마음만 먹으면 DB 지우고 로그까지 삭제할 수 있는 완벽한 사기(Toxic Combination) 루트가 뚫렸네!" 라며 AI가 선제적으로 권한을 강제 회수(Revoke)해 버리는 인지형 신원 보안 시대가 열리고 있다.
• 블록체인 다중 서명 (Multi-Sig Wallet) 아키텍처의 웹2.0 편입: SoD의 궁극적 형태는 코인 세계의 다중 서명(Multi-Sig) 지갑이다. 금고의 돈(코인)을 빼려면 이사 5명 중 3명의 프라이빗 키(Private Key)가 블록체인 스마트 컨트랙트에 동시에 입력되어야만 트래픽이 돌아간다. 이 100% 수학적이고 위변조 불가능한 블록체인 기반의 다중 승인 로직이, 코인을 넘어서 일반 기업의 '서버 배포 스위치'나 '개인정보 엑셀 다운로드 버튼'의 코어 뼈대로 편입되며 완전한 탈중앙화 락(Lock) 체계를 선도할 것이다.

참고 표준

• NIST SP 800-53 (Access Control - AC-5 Separation of Duties): 미국 정부가 "사기 치기 좋은 직무(돈 만지기, 보안 로그 지우기)는 무조건 두 명한테 찢어 줘라"라고 못을 박아버린 전 세계 거버넌스 최고 헌법 조항.
• K-ISMS 인증 심사 기준 (2.5.2 직무 분리): 대한민국 정보보호 관리체계의 심사 기준. "운영과 개발을 분리했어? 보안과 감사를 분리했어?" 이 질문에 시스템적 증거(Git 옵션, DB 권한 분리 화면)를 못 내밀면 인증서가 날아가 비즈니스 문을 닫아야 하는 현실적인 채찍.

보안 조직 분리 정책 위반(SoD) 통제는, 소프트웨어 공학이 **"내 옆에서 같이 야근하며 라면을 먹는 동료조차 100% 잠재적 해커(위협)로 간주해야만 하는, 가장 슬프고도 가장 완벽한 제로 트러스트(Zero Trust)의 인간학적 실천"**이다. 우리는 해커가 항상 후드티를 입고 러시아나 중국의 어두운 방안에 있을 거라 착각한다. 하지만 통계적으로 가장 치명적이고 액수가 큰 해킹은, 우리 회사 방화벽 안쪽에서 가장 선량한 얼굴을 하고 마스터키(root)를 쥐고 있는 핵심 개발자의 손끝에서 터져 나왔다. 기술사는 인간의 선의와 양심에 시스템의 운명을 걸지 않는다. 아무리 천재적인 리더일지라도 그의 손에 권력이 100% 독점되는 순간 시스템은 썩어 들어간다(Single Point of Compromise). 그렇기에 아키텍트는 깃허브(Git) 머지(Merge) 버튼에, DB 엑세스 터미널에, 결제 승인 API 한가운데에 "타인의 허락(Approve) 없이는 단 1바이트도 움직일 수 없는 차가운 기계적 족쇄"를 설계해야 한다. 쪼개고 나누어 견제하게 만드는 권력 분립의 미학, 그것이 배신과 탐욕의 늪에서 기업을 영원히 살려내는 가장 위대한 아키텍처적 독재다.

• 📢 섹션 요약 비유: SoD(직무 분리) 룰을 어기고 슈퍼 권한을 주는 것은, 은행에 **'금고 문도 딸 수 있고, CCTV도 끌 수 있고, 경보기도 해제할 수 있는 만능 리모컨'**을 1명의 지점장에게 쥐여주는 짓입니다. 지점장이 선량하면 일처리가 빛처럼 빠르고 편합니다. 하지만 지점장이 도박에 빠지는 순간 은행은 하룻밤 사이에 공중분해 됩니다. 진정한 아키텍처는 불편하더라도 금고 열쇠, CCTV 열쇠, 경보기 열쇠를 각기 다른 3명에게 찢어서 나눠주고, 서로가 서로를 감시(견제와 균형)하게 만들어, 3명이 동시에 미치지 않는 한 절대 범죄가 일어날 수 없게 물리적 한계를 긋는 민주주의적 통제망입니다.

📌 관련 개념 맵 (Knowledge Graph)

👶 어린이를 위한 3줄 비유 설명

1. 유치원에서 내가 대장이라서 "간식 상자 열쇠"도 내가 가지고, "몇 개 먹었는지 적는 장부"도 내가 가졌어요. 그러면 내가 맘대로 10개를 훔쳐 먹고 장부에는 1개 먹었다고 거짓말(사기) 칠 수 있겠죠?
2. 이걸 안 선생님이 규칙을 찢어놨어요. "철수는 열쇠로 상자만 열어!(Maker)" 그리고 "영희는 철수가 몇 개 꺼내는지 옆에서 보고 장부만 적어!(Checker)"
3. 이렇게 나쁜 맘을 먹지 못하게, 아무리 똑똑하고 힘센 사람이라도 절대 혼자서 모든 일을 다 할 수 없게 권한(역할)을 반으로 쪼개서 서로 감시하게 만드는 똑똑한 규칙을 **'보안 직무 분리(SoD)'**라고 부른답니다!