STRIDE 항목을 완화책과 검증 시험으로 어떻게 바꾸나요?

각 STRIDE 항목을 공격 전제 → 보호 자산 → 완화 → 관찰 가능한 기대 결과로 바꿉니다. 환불 API의 권한 상승이라면 “T1 일반 사용자가 T2 주문 환불을 요청”이 공격 전제이고, 보호 자산은 원장과 환불 권한입니다. 완화는 서버가 인증 주체와 대상 tenant·owner·현재 상태를 읽어 조건부 갱신하는 것입니다. 시험 결과는 거절, 원장 불변, 최소 감사 증적처럼 확인 가능한 형태로 씁니다.

TOCTOU까지 포함하면 조회 때 허용됐다는 사실만으로 부족합니다. 주문이 version=12,status=pending일 때 권한을 통과시킨 뒤 배송 worker가 version=13으로 바꾸고 재개하는 시험을 둡니다. UPDATE ... WHERE version=12 AND status='pending'가 0행이면 성공으로 보고하지 않고 최신 상태를 확인해 충돌 또는 금지 전이로 처리합니다. API뿐 아니라 batch worker와 관리자 도구도 같은 PEP를 통과해야 합니다.

완화 코드가 있다는 결과만으로 완료라고 하지 않습니다. 정상·다른 tenant·변조 body·서명 실패·중복 event ID·권한 회수·경합을 각각 실행하고 최종 자산 상태를 봅니다. HTTP 코드나 provider retry 횟수는 문서에서 고정해야 하며 예시를 표준으로 오해하지 않습니다.

예를 들어 webhook 변조의 완화는 “서명 검증”에서 끝나지 않고 원문 bytes 보존, 허용 key version, timestamp 창, event ID 유일성, inbox commit을 모두 포함해야 합니다. 각 항목에 실패를 주입했을 때 어느 저장소가 변하지 않아야 하는지까지 지정하면 완화가 단순 설정값이 아니라 회귀 시험으로 남습니다.

검증표에는 실행 전제도 적습니다. 테스트가 실제 provider를 호출하지 않는다면 서명 검증기와 inbox를 대역으로 두었다고 밝히고, 실행한 범위와 설계상 예상 결과를 구분합니다. 완화책이 여러 서비스에 흩어져 있으면 하나가 누락될 때 어떤 공격 경로가 열리는지 trace ID와 상태 불변 조건으로 연결합니다. 이 추적성이 있어야 설계 변경 때 기존 시험을 다시 실행할 수 있습니다.