Threat Model Trust Boundary

위협 모델링은 “무엇을 보호하는가”, “누가 접근하는가”, “어디로 들어오는가”, “어느 선부터 믿지 않는가”를 먼저 정하는 설계 활동이다.
Trust Boundary는 값과 신원이 신뢰 수준을 바꾸는 지점이고, Attack Surface는 공격자가 시도할 수 있는 입력, 상태 변경, 권한 경로의 합이다.
STRIDE와 abuse case는 추상적인 보안 걱정을 요구사항, 테스트, 감사 로그로 바꾸는 도구다.

Asset은 DB row만 뜻하지 않는다. 계정, 세션, token, 결제 상태, 관리자 권한, 감사 로그, 운영 secret, 개인정보 export 파일도 보호 자산이다.
Actor는 로그인 사용자와 비로그인 사용자만으로 부족하다. 고객, 고객센터 직원, 관리자, 배치, 파트너 webhook, 내부 운영자처럼 권한과 의도가 다른 행위자로 나눈다.
Entry Point는 public URL뿐 아니라 OAuth callback, webhook, file upload, admin API, batch input, message queue consumer, error response까지 포함한다.
Trust Boundary는 “이 값은 이제 서버가 믿어도 되는가”를 묻는 선이다. 브라우저, Gateway, Spring Filter, Controller, Service, Repository, DB는 같은 신뢰 수준이 아니다.
Attack Surface는 URL 개수보다 입력 종류, 인증 방식 수, 상태 변경 경로, 권한 예외, parser, redirect, upload, 검색 조건의 폭에 더 크게 좌우된다.
보안 요구사항은 “안전하게 처리한다”가 아니라 “어떤 actor가 어떤 asset에 어떤 action을 어떤 조건에서 할 수 있고, 거부와 로그는 어떻게 남는가”로 써야 한다.

1. Asset Actor Entry Point: 보안 리뷰의 시작점이다. 자산, 행위자, 진입점이 빠지면 모든 방어가 일반론으로 흐른다.
1. Trust Boundary와 Attack Surface: 같은 HTTP 요청도 어떤 경계를 넘는지에 따라 검증 책임이 달라진다.
1. STRIDE와 웹 백엔드 위협 모델링: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege를 웹 기능에 매핑한다.
1. 보안 요구사항을 설계에 반영하는 법: threat를 기능 명세, API 계약, DB 조건, 테스트, 로그 요구사항으로 바꾼다.
1. 보안 리뷰 질문지: 리뷰어가 코드 앞에서 실제로 던질 질문을 자산, 경계, 실패 경로, 로그 기준으로 정리한다.

위협 모델링을 보안팀만 하는 문서 작업으로 보기 쉽다. 다이어그램이나 도구 이름이 먼저 떠오르기 때문이다.
- 핵심은 새 API와 권한 정책을 만드는 개발자가 신뢰 경계를 직접 결정한다는 점이다.
- 보안팀이 없어도 자산, actor, entry point, abuse case, 로그 필드는 기능 설계에 포함할 수 있다.
내부 API는 신뢰해도 된다고 생각하기 쉽다. Gateway 뒤나 같은 VPC 안에 있다는 이유 때문이다.
- 핵심은 내부망이 인증, 권한, 입력 검증, 감사 로그를 대체하지 않는다는 점이다.
- 운영자 도구, batch, webhook, service-to-service 호출도 오남용과 설정 실수를 전제로 설계해야 한다.
Attack Surface를 URL 개수로만 세기 쉽다. 목록화하기 쉬운 대상이 URL이기 때문이다.
- 핵심은 공격자가 바꿀 수 있는 값과 상태 변경 경로가 표면을 넓힌다는 점이다.
- 하나의 API라도 upload, redirect, role 변경, 검색 DSL, callback을 받으면 표면은 커진다.
STRIDE를 외우는 것으로 끝내기 쉽다. 여섯 단어가 체크리스트처럼 보이기 때문이다.
- 핵심은 각 분류를 “이 기능에서 어떤 실패가 생기는가”와 “어떤 테스트와 로그로 확인하는가”로 바꾸는 것이다.
- 분류 이름보다 누락된 방어선을 발견하는 질문이 중요하다.

새 API 설계 전에 가장 먼저 적어야 할 네 가지는 무엇인가?
- 보호 자산, actor, entry point, trust boundary다.
Trust Boundary를 찾는 실무 질문은 무엇인가?
- 이 값이나 신원을 어느 지점부터 서버가 믿으며, 그 판단의 근거는 어디에서 만들어졌는가다.
보안 요구사항이 좋은지 판단하는 기준은 무엇인가?
- 허용 조건, 거부 조건, 로그 조건, 테스트 방법이 모두 검증 가능한 문장으로 적혀 있는지다.
보안 리뷰 질문은 어떤 형태가 좋은가?
- “취약한가”보다 “이 userId는 누가 만들었고 어느 계층에서 소유권을 확인하는가”처럼 추적 가능한 질문이 좋다.

동블