1장. 로그인 기능보다 위협 모델을 먼저 만든다

ContractHub에는 세 인물이 있다. alice는 ACME의 검토자, bob은 ACME의 승인자, mallory는 OTHER의 관리자다. 계약 C-1042는 ACME 소유다. 쉬운 데모는 MANAGER 역할만 검사하지만, 그러면 OTHER의 관리자가 ACME 계약을 읽거나 승인하는 수평 권한 상승이 생긴다. 우리가 막을 것은 “비로그인 사용자” 하나가 아니다.

먼저 보호 자산을 적는다. 계약 본문과 첨부 파일, 상대 회사 연락처, 승인 이력, 서명 상태, 계정 복구 수단, 세션과 토큰, 감사 로그가 자산이다. 공격자는 익명 인터넷 사용자뿐 아니라 탈퇴한 직원, 다른 테넌트의 정상 사용자, 탈취된 브라우저 세션, 잘못 구성된 CI, 과도한 권한의 운영자일 수 있다.

데이터 흐름마다 신뢰 경계를 그린다.

브라우저 --cookie+CSRF--> Spring Security filter chain
모바일/외부 API --Bearer--> JWT resource server
filter chain --Authentication--> service method policy
service --tenant 조건--> database
결정 --비밀 제외--> audit sink

각 경계에는 실패 질문을 붙인다. 쿠키가 복사되면? Origin이 다르면? 서명은 맞지만 aud가 다른 JWT라면? 역할은 맞지만 회사가 다르면? 승인 직전에 계약 상태가 바뀌면? 로그에 토큰이 남으면? 이 질문이 이후 테스트 이름이 된다.

실습 완료 조건은 그림이 아니라 표다. 자산, 행위자, 진입점, 오용 사례, 예방 통제, 탐지 신호, 복구 담당자를 한 줄씩 연결한다. 통제가 없는 위험은 숨기지 말고 미수용으로 표시한다.