STRIDE 위협 모델링: 데이터 흐름에서 보안 요구사항 찾기

1장 STRIDE 위협 모델링이란 무엇인가#

보안 설계를 할 때 흔히 다음과 같은 기능부터 생각합니다.

로그인
암호화
방화벽
접근통제
감사로그

하지만 중요한 질문은 기능 목록 자체가 아닙니다.

공격자는 이 시스템을 어떻게 악용할 수 있는가?

STRIDE는 이 질문을 체계적으로 나누기 위한 위협 모델링 방법입니다.

원문에서는 STRIDE를 다음 여섯 가지 위협 범주로 설명합니다.

  • S — 신분 위장
  • T — 변조
  • R — 부인
  • I — 정보 유출
  • D — 서비스 거부
  • E — 권한 상승

이 여섯 관점으로 시스템을 보면 단순한 기능 목록에서는 보이지 않던 보안 요구사항을 발견하기 쉬워집니다.

2장 STRIDE의 여섯 가지 위협#

STRIDE를 한눈에 보면 다음과 같습니다.

flowchart TB
    STRIDE[STRIDE]

    S["S · 신분 위장"]
    T["T · 변조"]
    R["R · 부인"]
    I["I · 정보 유출"]
    D["D · 서비스 거부"]
    E["E · 권한 상승"]

    STRIDE --> S
    STRIDE --> T
    STRIDE --> R
    STRIDE --> I
    STRIDE --> D
    STRIDE --> E

    S --> S1[인증·세션]
    T --> T1[입력·무결성 검증]
    R --> R1[감사로그]
    I --> I1[인가·암호화]
    D --> D1[한도·복원]
    E --> E1[최소 권한·기능 인가]

원문 역시 각 범주에서 확인해야 할 통제를 인증·세션·입력 검증·감사로그·인가·자원 제한·최소 권한 등으로 연결합니다.

3장 S — 신분 위장 Spoofing#

신분 위장은 공격자가 다른 사용자나 시스템인 것처럼 행동하는 위협입니다.

핵심 질문은 다음과 같습니다.

지금 요청을 보낸 주체가 정말 그 사람 또는 시스템인가?

예를 들어 공격자가 다른 사용자의 인증정보를 탈취해 로그인한다면 신분 위장에 해당할 수 있습니다.

확인해야 할 항목은 다음과 같습니다.

사용자 인증
세션 관리
토큰 검증
서버 신원 검증

원문에서는 S 범주의 주요 통제로 인증·세션·서버 신원을 제시합니다.

4장 T — 변조 Tampering#

변조는 데이터나 상태가 허가되지 않은 방식으로 변경되는 위협입니다.

예를 들어 고객이 주문 요청을 보내면서:

원래 금액
100,000원

을:

변조된 금액
1,000원

으로 바꿀 수 있다면 문제가 됩니다.

중요한 질문은:

이 값과 상태를 클라이언트가 임의로 변경할 수 있는가?

입니다.

확인할 통제는:

입력 검증
상태 검증
서버 측 재계산
메시지 무결성 검증

등입니다.

원문은 T 범주의 핵심 통제를 입력·상태·무결성 검증으로 제시합니다.

5장 R — 부인 Repudiation#

부인은 사용자가 실제로 수행한 행위를 나중에 부정하는 상황입니다.

예를 들어 사용자가:

저는 환불 요청을 한 적이 없습니다.

라고 주장한다고 하겠습니다.

이때 시스템이:

누가
언제
어떤 요청을
어떤 결과로 수행했는가

를 확인할 수 없다면 책임추적이 어렵습니다.

따라서 필요한 것은 주체와 행위를 연결하는 기록입니다.

원문에서도 R 범주의 통제로 이를 명시합니다.

6장 I — 정보 유출 Information Disclosure#

정보 유출은 허가되지 않은 사용자가 정보를 볼 수 있는 위협입니다.

예를 들어:

고객 A
→ 자신의 주문 조회

는 정상입니다.

하지만:

고객 A
→ 고객 B의 주문 조회

가 가능하다면 정보 유출 문제가 됩니다.

flowchart LR
    A[고객 A]
    API[주문 API]
    OWN[(자신의 주문)]
    OTHER[(다른 고객의 주문)]

    A --> API
    API -->|허용| OWN
    API -. 차단 .-> OTHER

원문에서는 정보 유출에 대한 통제로 인가·최소 공개·암호화를 제시합니다.

7장 D — 서비스 거부 Denial of Service#

서비스 거부는 시스템 자원을 소진하거나 장애를 유발해 정상 사용자가 서비스를 이용하지 못하게 만드는 위협입니다.

예를 들어 환불 API에 자동화된 요청을 대량으로 보내면:

CPU 사용 증가
DB 연결 소진
외부 결제 API 과부하
정상 사용자 요청 지연

등이 발생할 수 있습니다.

확인해야 할 통제는 다음과 같습니다.

호출 한도
시간 제한
자원 제한
복구 구조

원문에서도 D 범주에 대해 한도·시간 제한·복원을 확인하도록 제시합니다.

8장 E — 권한 상승 Elevation of Privilege#

권한 상승은 사용자가 자신에게 허용되지 않은 권한이나 기능을 얻는 위협입니다.

예를 들어 일반 고객이 관리자 전용 환불 승인 기능을 호출할 수 있다면 권한 상승 문제입니다.

flowchart LR
    USER[일반 사용자]
    API[API]
    ADMIN[관리자 기능]

    USER --> API
    API -. 인가 차단 .-> ADMIN

확인할 것은 다음과 같습니다.

최소 권한
객체 소유권
기능 인가
관리자 기능 분리

원문에서는 E 범주의 통제로 최소 권한·소유권·기능 인가를 제시합니다.

9장 STRIDE는 표를 외우는 것이 목적이 아니다#

STRIDE를 공부할 때 흔히 다음 표만 암기합니다.

범주 의미
S 신분 위장
T 변조
R 부인
I 정보 유출
D 서비스 거부
E 권한 상승

하지만 실제 위협 모델링에서 중요한 것은 시스템 구조에 적용하는 것입니다.

원문도 기능 이름을 나열하는 대신 데이터가 이동하는 경로와 신뢰 경계를 기준으로 분석해야 보안 요구사항을 구체화하기 쉽다고 설명합니다.

10장 먼저 데이터 흐름도를 그린다#

원문은 다음 구성요소가 등장하는 데이터 흐름도를 먼저 만들도록 제안합니다.

  • 사용자
  • API
  • 데이터베이스
  • 외부 결제 서비스

예를 들어 주문 서비스라면:

flowchart LR
    U["사용자"]
    A["주문 API"]
    D["주문 DB"]
    P["외부 결제 서비스"]
    L["감사로그"]

    U -->|"외부 요청"| A
    A -->|"DB 조회·수정"| D
    A -->|"결제·환불 요청"| P
    A -->|"행위 기록"| L

이렇게 시스템 안에서 데이터가 어디로 이동하는지 먼저 확인합니다.

11장 신뢰 경계 Trust Boundary를 찾는다#

데이터 흐름에서 특히 중요한 지점은 신뢰 수준이 달라지는 경계입니다.

예:

인터넷
→
API 서버
내부 API
→
외부 결제사

같은 구간입니다.

flowchart LR
    U["외부 사용자"]

    subgraph INTERNAL["내부 신뢰 영역"]
        API["API"]
        DB["주문 DB"]
        LOG["감사로그"]
    end

    PAY["외부 결제 서비스"]

    U -->|"신뢰 경계"| API
    API --> DB
    API --> LOG
    API -->|"신뢰 경계"| PAY

공격자는 이런 경계를 넘어갈 때 신원·권한·데이터를 속이거나 변조하려고 할 수 있습니다.

12장 각 연결마다 보안 질문을 붙인다#

원문에서는 각 연결에 다음 항목을 표시하라고 제안합니다.

인증 방식
입력 검증
데이터 분류
운영 주체

예를 들어:

flowchart LR
    U["사용자"]
    API["API"]
    DB["DB"]

    U -->|"JWT 인증<br/>외부 입력"| API
    API -->|"검증된 데이터<br/>내부 연결"| DB

이렇게 보면 단순한 화살표가 아니라 보안 조건이 있는 연결로 보이기 시작합니다.

13장 주문 서비스의 신뢰 경계#

원문은 주문 서비스 구조를 다음과 같이 제시합니다.

flowchart LR
    U["사용자"]
    A["API: 인증·인가"]
    D["주문 DB"]
    P["외부 결제 서비스"]
    L["감사로그"]

    U -->|"외부 입력"| A
    A -->|"검증된 요청"| D
    A -->|"제한된 호출"| P
    A --> L

이 구조만으로도 여러 STRIDE 질문을 만들 수 있습니다.

14장 환불 API를 STRIDE로 분석해보자#

원문에서는 환불 API를 실제 적용 사례로 사용합니다.

환불 기능은 단순해 보이지만 여러 위협이 동시에 존재할 수 있습니다.

다른 고객으로 위장
타인의 주문 환불
환불 금액 변조
환불 요청 사실 부인
자동화된 대량 호출
관리자 기능 호출

이를 STRIDE에 연결해보면 훨씬 명확해집니다.

15장 환불 API의 S — 고객 위장#

공격자가 다른 사용자의 인증정보를 이용해 환불 요청을 보낼 수 있습니다.

sequenceDiagram
    participant X as 공격자
    participant API as 환불 API
    participant DB as 주문 DB

    X->>API: 다른 고객으로 위장
    API->>DB: 환불 요청

보안 요구사항은:

강한 인증
토큰 검증
세션 관리

등으로 바뀝니다.

16장 환불 API의 E·I — 타인의 주문에 접근#

로그인 자체는 정상적인 사용자라고 하겠습니다.

하지만 공격자가 URL이나 주문 ID를 바꿔:

내 주문
ORDER-100

에서:

다른 사람 주문
ORDER-101

로 요청할 수 있다면 문제가 됩니다.

이 경우 단순 인증만으로는 부족합니다.

서버는:

이 주문의 소유자가 현재 사용자와 일치하는가?

를 확인해야 합니다.

원문에서도 환불 API 대응으로 서버 측 소유권 검증을 제시합니다.

17장 환불 API의 T — 환불 금액 변조#

다음 요청을 생각해보겠습니다.

주문 금액: 100,000원
환불 금액: 100,000원

공격자가:

환불 금액: 1,000,000원

으로 수정할 수 있다면 문제가 됩니다.

따라서 중요한 데이터는 요청 값을 그대로 신뢰해서는 안 됩니다.

sequenceDiagram
    participant C as Client
    participant API as 환불 API
    participant DB as 주문 DB

    C->>API: 주문 ID + 환불 요청
    API->>DB: 실제 결제 정보 조회
    DB-->>API: 실제 결제 금액
    API->>API: 서버 측 금액 검증

원문 역시 요청 무결성을 환불 API의 대응 요구사항으로 제시합니다.

18장 환불 API의 R — 요청을 부인한다면#

고객이 실제 환불 요청 후:

저는 환불한 적이 없습니다.

라고 주장할 수 있습니다.

그렇다면 다음 정보가 필요합니다.

사용자 ID
요청 시간
주문 ID
환불 금액
요청 결과

즉 단순 애플리케이션 로그가 아니라 누가 무엇을 했는지 연결된 감사로그가 필요합니다.

19장 환불 API의 D — 자동화된 대량 호출#

환불 API가 정상 사용자에게만 열려 있더라도 공격자가 자동화를 통해 반복 호출할 수 있습니다.

flowchart LR
    BOT[자동화 요청]
    API[환불 API]
    PAYMENT[결제 서비스]

    BOT -->|대량 요청| API
    API --> PAYMENT

이 경우:

Rate Limit
거래 한도
Timeout
중복 요청 방지

같은 요구사항을 검토해야 합니다.

원문은 환불 API 대응으로 거래 한도를 제시합니다.

20장 위협은 하나의 STRIDE 범주에만 들어가지 않는다#

원문에서 중요한 원칙 중 하나입니다.

범주별 위협은 서로 겹칠 수 있으므로 하나의 공격을 하나의 칸에 억지로 넣을 필요가 없습니다.

예를 들어 타인의 주문을 환불하는 공격은:

S
신분 위장

일 수도 있고,

E
권한 상승

문제일 수도 있으며,

고객정보가 함께 노출된다면:

I
정보 유출

도 포함될 수 있습니다.

21장 STRIDE의 목적은 위협 이름 붙이기가 아니다#

좋은 위협 모델링은 다음 단계로 끝나지 않습니다.

S 발견
T 발견
I 발견

진짜 목적은 이를 구현 가능한 요구사항으로 바꾸는 것입니다.

원문 역시 환불 API 위협을 다음과 같은 요구사항으로 변환합니다.

서버 측 소유권 검증
요청 무결성 검증
감사로그
거래 한도

22장 위협을 보안 요구사항으로 바꾸는 방법#

예를 들어:

위협
타인의 주문을 환불할 수 있다

를 발견했다고 하겠습니다.

이것을:

보안을 강화한다

라고 적으면 구현할 수 없습니다.

대신:

환불 API는 요청 사용자가 해당 주문의 소유자인지
서버에서 검증해야 한다.

처럼 작성해야 합니다.

23장 좋은 보안 요구사항은 테스트할 수 있어야 한다#

예:

좋지 않은 요구사항#

환불 API를 안전하게 만든다.

더 좋은 요구사항#

다른 사용자 소유의 주문 ID로
환불 API를 호출하면
403 응답을 반환해야 한다.

이렇게 작성하면 개발과 테스트로 연결할 수 있습니다.

flowchart LR
    T[위협]
    R[보안 요구사항]
    I[구현]
    TEST[보안 테스트]

    T --> R --> I --> TEST

24장 STRIDE 분석 결과 예시#

STRIDE 환불 API 위협 보안 요구사항 예
S 다른 사용자 위장 인증·세션 검증
T 환불 금액 변조 서버 측 값 검증
R 환불 요청 부인 감사로그
I 다른 고객 주문 조회 객체 소유권 검증
D 대량 환불 요청 거래 한도·요청 제한
E 관리자 기능 호출 기능 단위 인가

이렇게 정리하면 개발자가 무엇을 구현해야 하는지 명확해집니다.

25장 예방·탐지·대응을 함께 연결한다#

원문에서는 위협마다 예방·탐지·대응 수단을 연결하라고 제안합니다.

예를 들어 계정 탈취 위협이라면:

flowchart TB
    T[계정 탈취]

    P[예방<br/>강한 인증]
    D[탐지<br/>이상 로그인 탐지]
    R[대응<br/>세션 폐기·계정 잠금]

    T --> P
    T --> D
    T --> R

한 가지 통제만으로 모든 문제를 막으려는 것보다 더 현실적인 접근입니다.

26장 통제가 실패했을 때도 생각해야 한다#

보안 통제는 실패할 수 있습니다.

예:

인증 우회
로그 저장 실패
Rate Limit 장애
외부 결제 시스템 오동작

원문에서는 통제가 실패했을 때의 업무 영향과 검증 절차를 남겨야 한다고 설명합니다.

따라서 위협 모델은:

위협
→ 통제

에서 끝나지 않습니다.

위협
→ 통제
→ 통제 실패
→ 업무 영향
→ 복구

까지 보는 것이 좋습니다.

27장 설계가 바뀌면 위협 모델도 바뀐다#

처음 시스템이:

flowchart LR
    U[사용자]
    API[API]
    DB[DB]

    U --> API --> DB

였다고 하겠습니다.

이후 외부 결제 서비스가 추가됩니다.

flowchart LR
    U[사용자]
    API[API]
    DB[DB]
    PAY[외부 결제 서비스]

    U --> API
    API --> DB
    API --> PAY

이제 새로운 신뢰 경계가 생겼습니다.

외부 시스템에 대한:

서버 인증
API 인증
Timeout
오류 처리
데이터 최소 전송

같은 새로운 질문이 필요합니다.

원문에서도 설계 변경 시 데이터 흐름도와 신뢰 경계를 갱신해야 한다고 강조합니다.

28장 취약점 스캔과 위협 모델링은 무엇이 다른가#

원문의 FAQ에서 중요한 차이를 설명합니다.

취약점 스캔#

알려진 결함을 찾는 데 도움을 줍니다.

예:

취약한 라이브러리
열린 포트
알려진 CVE
설정 오류

위협 모델링#

설계 단계에서:

어떤 경로로 악용할 수 있는가
어떤 신뢰를 전제로 하는가
어떤 권한이 필요한가

를 검토합니다.

29장 둘은 경쟁 관계가 아니다#

flowchart LR
    TM[위협 모델링]
    VS[취약점 스캔]
    RISK[위험 판단]

    TM --> RISK
    VS --> RISK

원문처럼 두 활동을 연결하면 발견된 결함이 실제 업무에 어떤 영향을 주는지 판단하기 쉬워집니다.

30장 STRIDE 위협 모델링 실전 순서#

실무적으로는 다음 순서로 진행할 수 있습니다.

flowchart TB
    A[시스템 범위 정의]
    B[데이터 흐름도 작성]
    C[신뢰 경계 표시]
    D[STRIDE 질문]
    E[위협 시나리오 작성]
    F[보안 요구사항 도출]
    G[구현·테스트]
    H[설계 변경 시 재검토]

    A --> B --> C --> D --> E --> F --> G --> H
    H --> B

31장 1단계 시스템 범위를 정한다#

먼저 어디까지 분석할지 결정합니다.

예:

웹 프론트엔드
API
DB
결제 서비스
감사로그

범위가 명확하지 않으면 위협 모델이 끝없이 커질 수 있습니다.

32장 2단계 데이터 흐름도를 그린다#

어떤 데이터가 어디에서 어디로 이동하는지 표시합니다.

flowchart LR
    USER[사용자]
    API[API]
    DB[(DB)]
    PAY[결제사]
    LOG[(감사로그)]

    USER --> API
    API --> DB
    API --> PAY
    API --> LOG

33장 3단계 신뢰 경계를 표시한다#

다음처럼 질문합니다.

외부와 내부는 어디에서 나뉘는가?

내부 서비스끼리 모두 신뢰할 수 있는가?

외부 SaaS는 어떤 신뢰 수준인가?

신뢰 수준이 달라지는 곳이 중요한 분석 지점입니다.

34장 4단계 각 요소에 STRIDE 질문을 적용한다#

예를 들어 API라면:

S
사용자를 위장할 수 있는가?

T
요청 데이터를 바꿀 수 있는가?

R
요청 사실을 부인할 수 있는가?

I
다른 사용자의 정보가 보이는가?

D
대량 요청으로 장애를 낼 수 있는가?

E
허가되지 않은 기능을 실행할 수 있는가?

처럼 질문합니다.

35장 5단계 위협을 시나리오로 작성한다#

단순히:

정보 유출 위험

이라고 적는 것보다:

인증된 사용자가 다른 사용자의 주문 ID를 요청해
타인의 주문 정보를 조회할 수 있다.

처럼 작성하는 편이 좋습니다.

그래야 대응책도 구체적으로 나옵니다.

36장 6단계 보안 요구사항으로 변환한다#

위협:

다른 사용자의 주문을 조회할 수 있다.

요구사항:

주문 조회 API는 현재 로그인 사용자가
해당 주문의 소유자인지 서버 측에서 검증해야 한다.

이 단계가 STRIDE의 실질적인 결과물입니다.

37장 7단계 테스트 조건으로 바꾼다#

요구사항:

주문 소유권을 확인한다.

테스트:

사용자 A로 로그인한 상태에서
사용자 B의 주문 ID를 조회하면
접근이 거부되어야 한다.
flowchart LR
    THREAT[위협]
    REQ[보안 요구사항]
    TEST[테스트 조건]

    THREAT --> REQ --> TEST

보안 요구사항이 실제 품질 관리로 연결됩니다.

38장 STRIDE 분석 시 흔히 하는 실수#

STRIDE 단어만 체크한다#

S 있음
T 있음
R 없음

으로 끝내면 실제 설계 개선으로 이어지기 어렵습니다.

모든 위협을 한 범주에만 넣으려 한다#

원문처럼 하나의 공격은 여러 범주에 걸칠 수 있습니다.

데이터 흐름도 없이 시작한다#

시스템 경계가 보이지 않으면 위협도 추상적으로 남기 쉽습니다.

통제를 너무 추상적으로 쓴다#

보안을 강화한다

보다는:

다른 사용자 소유 객체 접근 시 403 반환

처럼 작성해야 합니다.

39장 STRIDE 체크리스트#

S — 신분 위장#

  • 사용자를 어떻게 인증하는가
  • 세션이나 토큰을 탈취할 수 있는가
  • 서버의 신원을 검증하는가

T — 변조#

  • 요청 값을 클라이언트가 바꿀 수 있는가
  • 서버가 중요한 값을 재검증하는가
  • 상태 변경 권한을 검증하는가

R — 부인#

  • 누가 작업했는지 기록되는가
  • 로그가 행위와 사용자를 연결하는가
  • 감사로그가 보호되는가

I — 정보 유출#

  • 다른 사용자의 객체에 접근할 수 있는가
  • 필요 이상의 데이터를 반환하는가
  • 민감정보는 보호되는가

D — 서비스 거부#

  • 요청 횟수 제한이 있는가
  • Timeout이 있는가
  • 자원 고갈 시 복구할 수 있는가

E — 권한 상승#

  • 관리자 기능은 별도 인가되는가
  • 객체 소유권을 검증하는가
  • 최소 권한 원칙이 적용되는가

STRIDE FAQ#

STRIDE란 무엇인가#

신분 위장, 변조, 부인, 정보 유출, 서비스 거부, 권한 상승이라는 여섯 범주를 이용해 시스템의 위협을 분석하는 모델입니다.

STRIDE는 어디에 적용하는가#

원문에서는 사용자·API·DB·외부 결제 서비스 등의 데이터 흐름과 신뢰 경계를 기준으로 분석하는 방법을 제시합니다.

하나의 공격은 STRIDE 한 범주에만 속하는가#

아닙니다. 여러 위협 범주가 서로 겹칠 수 있으므로 하나의 공격을 한 범주에 억지로 넣을 필요가 없습니다.

위협 모델링 결과는 무엇이어야 하는가#

단순 위협 목록이 아니라 구현과 테스트가 가능한 보안 요구사항으로 이어지는 것이 좋습니다. 원문의 환불 API 사례도 소유권 검증·요청 무결성·감사로그·거래 한도로 구체화합니다.

취약점 스캔과 위협 모델링은 같은가#

아닙니다. 스캔은 알려진 결함 탐색에 도움이 되고, 위협 모델링은 설계 단계에서 악용 경로와 신뢰 가정을 검토합니다.

시스템이 변경되면 다시 해야 하는가#

그렇습니다. 원문에서는 설계 변경 시 데이터 흐름도와 신뢰 경계를 갱신하도록 제안합니다.

핵심 정리#

STRIDE는 다음 여섯 가지 질문으로 시스템을 바라보는 방법입니다.

flowchart TB
    SYSTEM[시스템]

    S["S<br/>다른 주체로 위장할 수 있는가?"]
    T["T<br/>데이터를 변조할 수 있는가?"]
    R["R<br/>행위를 부인할 수 있는가?"]
    I["I<br/>정보가 유출될 수 있는가?"]
    D["D<br/>서비스를 마비시킬 수 있는가?"]
    E["E<br/>더 높은 권한을 얻을 수 있는가?"]

    SYSTEM --> S
    SYSTEM --> T
    SYSTEM --> R
    SYSTEM --> I
    SYSTEM --> D
    SYSTEM --> E

하지만 STRIDE의 핵심은 여섯 단어를 외우는 데 있지 않습니다.

먼저:

사용자
API
DB
외부 서비스

의 데이터 흐름을 그리고,

그 사이의:

신뢰 경계

를 찾습니다.

그 다음 각 지점에서 STRIDE 질문을 적용합니다.

최종적으로는:

flowchart LR
    DFD[데이터 흐름]
    BOUNDARY[신뢰 경계]
    STRIDE[STRIDE 분석]
    THREAT[위협 시나리오]
    CONTROL[보안 요구사항]
    TEST[검증]

    DFD --> BOUNDARY --> STRIDE --> THREAT --> CONTROL --> TEST

로 이어져야 합니다.

원문이 강조하는 핵심도 같습니다. 기능 이름을 단순히 나열하는 것보다 데이터 흐름과 신뢰 경계를 기준으로 위협을 분석하고, 발견한 문제를 인증·인가·로그·무결성 검증·가용성 같은 구체적인 요구사항으로 바꾸는 것이 STRIDE 위협 모델링의 목적입니다.

이 페이지의 목차