475. STRIDE 모델 - Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege

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

1. 본질: STRIDE 모델은 보안 아키텍트가 설계 단계에서 위협 모델링(Threat Modeling)을 할 때, 막연하게 "어디가 털릴까?" 고민하는 대신 기계적이고 누락 없이 모든 보안 위협을 찾아낼 수 있도록 마이크로소프트가 고안한 6가지 궁극의 해킹 공격 분류 체계다.
2. 가치: 스푸핑(Spoofing), 탬퍼링(Tampering) 등 6가지 키워드를 체크리스트로 삼아, 시스템 아키텍처 다이어그램(DFD)의 '신뢰 경계선(Trust Boundary)'을 통과하는 모든 데이터 흐름에 돋보기를 들이댄다. 이를 통해 주먹구구식 뇌피셜(직감) 보안을 수학적이고 체계적인 논리적 방어벽 설계(Secure by Design)로 승격시킨다.
3. 융합: 각 위협(Threat)은 반드시 1:1로 대응되는 **보안 속성 방어 기술(인증, 무결성, 부인방지, 기밀성, 가용성, 인가)**과 완벽한 퍼즐처럼 융합되며, 이후 DREAD 모델(위험도 평가)로 넘겨져 한정된 개발 인력을 어디에 투입할지 우선순위를 정하는 애자일 백로그(Backlog)로 직결된다.

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

• 개념: 세상의 모든 소프트웨어 해킹 기법은 수만 가지(SQL 인젝션, XSS, 패킷 스니핑 등)가 있지만, 그 뼈대(목적)를 추려보면 결국 딱 6가지로 귀결된다. 이 6가지 카테고리의 앞 글자를 딴 것이 STRIDE다. S(신분 위조) / T(데이터 변조) / R(오리발 내밀기) / I(정보 훔쳐보기) / D(서버 터뜨리기) / E(권한 빼앗기)

• 필요성: 개발자들에게 "이 결제 시스템에서 일어날 수 있는 위협을 찾아봐!"라고 하면 1시간 내내 회의해도 "DB 털리면 어떡하죠?", "디도스 오면 어떡하죠?" 2개만 찾고 끝난다. 인간의 상상력에는 한계가 있다. 하지만 칠판에 STRIDE 6글자를 띄워놓고 강제로 1글자씩 대입해 보게 하면? "아, R(Repudiation)을 생각해보니 고객이 결제해 놓고 나중에 안 했다고 우기면 증명할 방법이 없네?"라며 평소엔 절대 상상하지 못했던 '논리적 맹점'을 강제로 쥐어짜 내게 만들어준다.

• 💡 비유: STRIDE 모델은 종합병원의 **'6단계 종합 건강 검진표'**와 같습니다. 의사가 환자의 얼굴만 보고 "어디 아파요?"라고 물어보는 건 하수입니다. 진정한 의사(아키텍트)는 1.혈압, 2.시력, 3.청력, 4.소변, 5.엑스레이, 6.심전도(STRIDE 6원칙)라는 정해진 6개의 매뉴얼을 무조건 한 바퀴 돌립니다. 환자가 괜찮다고 우겨도 무조건 검사합니다. 그래야 숨어있는 췌장암(해킹 결함)을 절대 놓치지 않기 때문입니다.

• 등장 배경 및 발전 과정:

  1. 보안의 예술화 시대: 과거엔 천재 해커 한 명이 직감으로 취약점을 뚫어내는 예술의 영역이었다. 방어하는 쪽도 천재가 없으면 다 뚫렸다.
  2. 마이크로소프트의 공학적 대통일 (1999): MS의 로렌 콘펠더와 프라기트 가그가 "천재가 아니어도, 바보라도 매뉴얼만 따라가면 위협을 다 찾을 수 있게 만들자!"며 이 위대한 분류법을 발명했다.
  3. 클라우드 및 DevSecOps 시대의 코어 (현재): AWS 아키텍처든, Docker 컨테이너 통신이든, 인프라의 껍데기는 수만 번 변했지만 그 알맹이의 보안을 위협하는 6가지 본질(STRIDE)은 20년이 지난 지금도 절대 변하지 않는 만유인력의 법칙으로 쓰인다.

• 📢 섹션 요약 비유: 해커의 공격 방식이 수백만 가지 파편화된 '전투기, 소총, 수류탄, 화살'이라면, STRIDE는 그것들을 **'육군, 해군, 공군'**처럼 최상위 개념으로 분류해 놓은 완벽한 상자입니다. 6개의 서랍장만 있으면 세상에 존재하는, 그리고 미래에 나올 그 어떤 새로운 해킹 기술도 모두 분류하여 집어넣을 수 있습니다.

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

1. STRIDE 6원칙과 대응 방어(Mitigation) 1:1 매핑 ★ (가장 중요)

위협(병)이 있다면 반드시 짝을 이루는 방어(약)가 존재한다. 이 짝짓기 공식은 보안 아키텍처의 절대 진리다.

2. STRIDE의 적용 지점: DFD (Data Flow Diagram)

STRIDE는 무턱대고 들이대는 게 아니라, 아키텍처 다이어그램(DFD)의 '선과 네모'에 정확히 꽂아야 한다.

• 데이터 흐름(화살표, Data Flow): 패킷이 날아가는 공중이므로 해커가 채가기 좋다. ➡ T(변조), I(유출), D(디도스) 발생.

• 데이터 저장소(원기둥, Data Store): 파일이나 DB에 쌓여 있는 상태. ➡ T(변조), I(유출), D(디도스) 발생.

• 프로세스(동그라미, Process): 로직이 도는 서버 자체. ➡ STRIDE 6개 전부 다 발생 가능.

• 외부 엔티티(네모, External Interactor): 외부 사용자나 타사 API. ➡ S(위장), R(발뺌) 특화.

• 📢 섹션 요약 비유: 이 과정은 요리(시스템)를 할 때 독(해킹)이 들어가지 않게 막는 것입니다. 식재료를 배달하는 오토바이(데이터 흐름)에서는 중간에 상하지 않게(T 변조) 냉장차(HTTPS)로 방어하고, 냉장고(데이터 저장소)에 넣었을 땐 도둑이 훔쳐 가지 못하게(I 유출) 자물쇠(암호화)를 채우는 등, 그 부품의 특성에 딱 맞는 맞춤형 검열표를 들이대는 과학적 분석입니다.

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

1. STRIDE (위협 도출) vs DREAD (위협 평가)

두 가지는 자전거의 두 바퀴처럼 연결되어 움직인다. (다음 장 476번 연계)

과목 융합 관점

• 소프트웨어 공학 (보안 요구사항 도출): 개발 초기(기획 단계)에 비즈니스 기획자들은 "사용자가 편리하게 장바구니에 담아야 한다"는 기능적(Functional) 요구사항만 쓴다. 이때 아키텍트가 칠판에 STRIDE를 적어두면, 비기능적(Non-Functional)인 보안 요구사항이 쏟아져 나온다. "T(변조)를 막기 위해 장바구니 금액은 클라이언트 값을 믿지 말고 무조건 서버에서 재계산(Validation)한다." 이 문장 하나가 **개발자들의 코딩 지침서(Secure Coding Guideline)**로 융합되어 내려간다.

• 네트워크 (제로 트러스트 아키텍처): STRIDE 모델은 제로 트러스트(Zero Trust) 사상과 결합하여 극단으로 치닫고 있다. 예전엔 외부 사용자(S 위장)만 의심했다. 지금은 사내망에 떠 있는 '주문 서버'와 '결제 서버' 사이의 내부 통신망(Data Flow)에도 붉은 선을 긋고 STRIDE 엑스레이를 쏜다. "내부망이라도 T(변조), I(유출)가 발생할 수 있어! 무조건 내부 서버끼리도 mTLS로 쌍방향 암호화 통신을 해!"라는 극단적 아키텍처 진화를 이끌어냈다.

• 📢 섹션 요약 비유: STRIDE는 그물을 넓게 던져 바다에 있는 오징어, 상어, 쓰레기통(온갖 위협)을 바닥까지 박박 다 긁어 올리는 어망입니다. DREAD는 덱 위에 쏟아진 것들 중에서 "상어는 즉시 죽이고, 오징어는 팔고, 쓰레기통은 나중에 버리자"라며 가치를 매기는 어부의 칼질입니다. 어망(STRIDE)이 찢어지면 상어(치명적 위협)를 아예 낚아 올릴 수조차 없습니다.

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

실무 시나리오

1. 시나리오 — 권한 상승(Elevation of Privilege) 방어 실패가 낳은 비극: 한 중소기업에서 사내 인사(HR) 시스템을 만들었다. 내 연봉을 조회하는 URL이 http://hr.com/salary?emp_id=102 였다. 직원이 심심해서 URL 끝 숫자를 103으로 1 올려서 엔터를 쳤다. 옆자리 부장님의 연봉이 화면에 떠버렸다(수직적 권한 상승 및 정보 유출). 1시간 만에 전 직원의 연봉이 엑셀로 유출되며 회사가 발칵 뒤집혔다.

   • 아키텍트의 해결책: STRIDE 중 'E(권한 상승)' 위협에 대한 완전한 맹점이다. 개발자들은 로그인(S-인증)만 하면 끝인 줄 안다. 아키텍트는 설계 시 DFD에서 '사용자 -> 웹 서버' 경계선을 짚고, "로그인은 했어도(S 통과), 이 놈이 남의 글을 읽을 수 있나?(E 위협)"를 반드시 찔러야 한다. 그러면 "API 컨트롤러 앞단에 무조건 해당 자원의 소유자(Owner)인지 검사하는 인가(Authorization) 인터페이스 필터를 박는다"라는 전역 방어 로직(AOP/Interceptor)이 코딩 전에 도출되어 대참사를 막을 수 있다.

2. 시나리오 — 부인(Repudiation)의 공포, 삭제된 데이터의 복수: 클라우드 인프라 팀이 퇴근 후 술을 마시다 실수로 AWS S3 버킷(고객 사진 보관소)을 삭제해 버렸다. 다음 날 난리가 났다. 그런데 범인을 잡으려 AWS CloudTrail 로그를 까보니, 모든 직원이 공용 계정인 admin_root 하나로 접속해서 쓰고 있었다. 결국 "누가(Who)" 지웠는지 증명(Repudiation 방어)할 수 없었고 아무도 징계받지 않았다.

   • 아키텍트의 해결책: STRIDE 중 'R(부인)'을 기술적/조직적 아키텍처로 방어하지 못한 죄다. 부인 방지의 핵심은 "발뺌할 수 없는 증거(Audit Trail)"다. 아키텍트는 1) 절대 공용 계정 사용을 금지하고 무조건 1인 1계정(SSO)으로 접속을 분리(Identity 맵핑)해야 하며, 2) 그들이 한 파괴적인 행위(DELETE, DROP)는 지울 수 없는 WORM(Write Once Read Many) 형태의 중앙화된 로그 서버에 영구 박제시켜 "너 어제 밤 11시에 지웠잖아!"라고 증거를 들이밀 수 있는 불가역적 인프라를 설계해야 한다.

도입 체크리스트

• 조직적: '위협(Threat)'과 '취약점(Vulnerability)'을 명확히 구분하는가? 칠판에 적어보라 하면 주니어들은 "버퍼 오버플로우요!"라고 적는다. 이건 취약점(구멍)이다. 위협(해커의 목적)은 "버퍼 오버플로우를 쳐서 ➡ 권한을 탈취(E)하거나 서버를 뻗게 만든다(D)"이다. 원인(구멍)을 막는 것도 중요하지만, STRIDE는 철저하게 **목적(해커가 이루려는 파괴 행위)**에 집중하여, "만약 이 구멍이 뚫리더라도, 결국 권한 탈취(E)를 못 하게 이중 방어막을 설계하자"는 심층 방어(Defense in Depth) 시야를 조직에 심어주어야 한다.
• 기술적: STRIDE-per-Element 방법론을 체화했는가? 그냥 뜬구름 잡듯 6개를 생각하는 게 아니다. DFD의 기호마다 특화된 STRIDE 렌즈를 들이대야 한다.
  • 외부 사용자(네모) ➡ S, R 만 검사.
  • 데이터 흐름(화살표) ➡ T, I, D 만 검사.
  • 프로세스(동그라미) ➡ S, T, R, I, D, E 전부 검사. 이 공식(매트릭스)을 개발팀 책상에 코팅해서 붙여놔야 위협 모델링 회의가 10분 만에 깔끔하게 끝난다.

안티패턴

• "우리 시스템은 사내 인트라넷이니까 S(스푸핑)랑 T(변조)는 안 해도 돼!" (맹목적 신뢰): 해커가 랜섬웨어가 담긴 메일을 여직원에게 보내서 클릭하게 만든 순간, 해커는 사내망 내부의 훌륭한 "내부 직원(Trusted Entity)"으로 둔갑한다. 인터넷과 차단된 사내 폐쇄망이라고 해서 STRIDE를 대충 건너뛰면, 내부 직원의 USB 하나에 회사의 100년 치 기밀(I-유출)이 1분 만에 싹 털려나가는 지옥을 맛보게 된다.

• 📢 섹션 요약 비유: 사내망이라고 STRIDE를 무시하는 것은, **'우리 집 안방이니까 방문도 열어놓고 금고 문도 열어놓고 자는 것'**과 같습니다. 강도가 이미 창문을 뚫고 거실에 들어왔다면, 안방 문이 열려있는 한 당신의 목숨은 날아갑니다. 집문(방화벽)이 뚫렸더라도 안방(DB) 문을 잠그고(S), 금고(데이터)에 비밀번호(T, I)를 걸어두는 이중, 삼중의 방어막. 그것이 STRIDE가 강제하는 다층 방어(Defense in Depth)입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• AI(LLM) 기반의 STRIDE 자동 생성기: 과거 화이트보드 펜으로 DFD를 그리고 손으로 S, T, R, I, D, E를 대입하던 노가다 시대는 끝났다. 개발자가 인프라 코드(Terraform)를 GPT-4에 던져주며 "이 AWS 아키텍처에서 STRIDE 위협 10개를 뽑아주고, 조치 코드(Mitigation)까지 짜줘"라고 명령하면, 인간이 놓친 S3 버킷의 'I(정보 유출)' 위협과 IAM 정책의 'E(권한 상승)' 위협을 1초 만에 식별하여 뱉어내는 1인 보안 컨설턴트(AI) 시대가 도래했다.
• LINDDUN (프라이버시 위협 모델링)으로의 진화: 기존 STRIDE가 '시스템(서버)'을 지키는 것에 혈안이 되어 있다면, 최근 유럽의 GDPR 등 개인정보 보호법이 미쳐 날뛰자 **사용자의 프라이버시(개인정보)**를 지키기 위한 위협 모델링의 진화형인 LINDDUN(Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of info, Unawareness, Non-compliance)이 STRIDE와 쌍두마차로 융합되어 세계 표준을 장악해 나가고 있다.

참고 표준

• Microsoft Threat Modeling Tool: MS가 직접 만들어 무료로 푼 툴. DFD를 드래그해서 그리면, 뒤에서 내장된 STRIDE 엔진이 윙윙 돌아가며 "이 화살표에선 Tampering 위협이 터질 겁니다!"라고 자동으로 목록을 뱉어주는 현업의 교복.
• OWASP Top 10: STRIDE가 큰 틀(카테고리)이라면, OWASP는 실제로 현업에서 가장 많이 터지는 해킹 기법(SQL 인젝션 등)의 구체적인 순위표. STRIDE 6개를 잡고 OWASP 10개를 렌즈로 끼워 쳐다보면 완벽한 엑스레이가 된다.

STRIDE 모델은 보안 아키텍트에게 쥐여진 **'6개의 차가운 수술용 메스'**다. 복잡한 마이크로서비스(MSA)의 거미줄 같은 도면을 펼쳐놓고 "어디서 피가 날까?" 당황하는 개발자들에게, 이 6개의 글자는 어둠 속의 나침반이 된다. 기술사는 막연한 공포심으로 떡칠 된 비싼 보안 솔루션 장비(방화벽, WAF)에 회사의 운명을 맡겨서는 안 된다. 가장 완벽한 보안은, 시스템의 혈관(Data Flow)과 심장(Data Store)을 그릴 때부터 6개의 시나리오(S, T, R, I, D, E)를 차례대로 찌르고 부수어보며 "내부에서부터 면역력을 콘크리트처럼 발라버리는 우아한 논리적 설계"에서 탄생한다.

• 📢 섹션 요약 비유: STRIDE는 건물 보안 요원의 **'손전등(Flashlight)'**입니다. 어두운 지하실(복잡한 아키텍처)에 그냥 들어가면 도둑이 어디 숨어있는지 안 보입니다. 하지만 S(신분 위조)라는 붉은색 빛을 비추면 거짓말쟁이들이 보이고, E(권한 상승)라는 푸른색 빛을 비추면 자물쇠를 몰래 따는 놈들이 반사되어 빛납니다. 이 6가지 색깔의 플래시를 순서대로 한 번씩 다 비춰봐야, 지하실에 숨은 바퀴벌레 1마리(해킹 결함)까지 샅샅이 잡아낼 수 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

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

1. 동생이 내 돼지저금통을 훔쳐 갈까 봐 불안했어요. "어디로 훔쳐 갈까?" 혼자 상상하려니까 머리가 아팠죠.
2. 그래서 똑똑한 선생님이 주신 **'도둑질 6가지 꼼수 리스트(STRIDE)'**를 꺼냈어요! "1.가면 쓰기(S), 2.숫자 고치기(T), 3.오리발 내밀기(R)..." 이렇게 6개였죠.
3. 이 리스트를 보면서 내 돼지저금통을 하나씩 검사해 보니까, "아! 동생이 저금통 뒤에 구멍을 뚫어서 동전을 뺄 수 있겠구나(T, I)!" 하고 생각지도 못한 약점을 완벽하게 찾아내는 돋보기 마법을 **'STRIDE 모델'**이라고 부른답니다!