OWASP Top 10: A04:2021 안전하지 않은 설계(Insecure Design)와 STRIDE 위협 모델링 샅샅이 파헤치기 🧐

안녕하세요! 여러분의 안전한 웹 개발 여정을 돕는 보안 길잡이입니다. 👋 오늘은 2021년 OWASP Top 10에 새롭게 등장한 A04:2021-Insecure Design (안전하지 않은 설계)에 대해 알아보고, 이러한 설계상의 허점을 효과적으로 찾아내고 예방할 수 있는 강력한 무기, STRIDE 위협 모델링을 어떻게 활용할 수 있는지 상세히 설명해 드리겠습니다.

 

 

---

🤔 안전하지 않은 설계(Insecure Design)란 무엇일까요?

'안전하지 않은 설계'는 말 그대로 소프트웨어의 초기 설계 단계에서부터 보안을 충분히 고려하지 않아 발생하는 근본적인 보안 취약점을 의미합니다. 튼튼한 기초 공사 없이 지은 건물이 쉽게 무너질 수 있듯이, 설계 단계의 결함은 아무리 코드를 완벽하게 작성하더라도 치명적인 보안 문제로 이어질 수 있습니다. 🏡

예를 들어, 비밀번호 재설정 프로세스를 이메일 링크 클릭만으로 완료되도록 설계했다면, 이는 구현이 아무리 잘 되어도 설계 자체에 허점이 있는 것입니다. 해커가 이메일을 탈취하기만 하면 계정을 쉽게 빼앗을 수 있겠죠? 😨

OWASP에서는 이러한 설계 결함을 예방하기 위해 '설계 기반 보안(Secure by Design)' 원칙과 '위협 모델링(Threat Modeling)'의 중요성을 강조합니다. 여기서 바로 STRIDE가 등장합니다!

---

🛡️ STRIDE 위협 모델링: 설계의 허점을 찾아내는 6가지 렌즈

STRIDE는 Microsoft에서 개발한 위협 모델링 방법론으로, 잠재적인 보안 위협을 6가지 카테고리로 나누어 체계적으로 식별하고 대응할 수 있도록 돕습니다. 마치 6개의 돋보기를 가지고 우리 시스템의 설계도를 구석구석 살펴보는 것과 같습니다. 🔍

각각의 위협이 '안전하지 않은 설계'와 어떻게 연결되는지 하나씩 살펴볼까요?

1. Spoofing (스푸핑: 신원 도용) 🎭

• 위협: 공격자가 다른 사용자나 시스템인 것처럼 위장하는 것입니다.
• 안전하지 않은 설계 예시:
  • 사용자 인증 절차를 아이디와 비밀번호만으로 단순하게 설계한 경우 (다중 인증(MFA) 미적용)
  • 서버 간 통신 시, 상호 인증 절차를 설계에 포함하지 않은 경우
  • 이메일 발신자 주소를 검증하는 로직(SPF, DKIM 등)을 설계 단계에서 누락한 경우
• 고려사항: "우리 시스템은 사용자와 구성 요소의 신원을 어떻게 확인하고 보증하도록 설계되었는가?"

2. Tampering (탬퍼링: 데이터 변조) ✍️

• 위협: 공격자가 시스템을 통과하는 데이터나 저장된 데이터를 악의적으로 변경하는 것입니다.
• 안전하지 않은 설계 예시:
  • 중요 데이터(예: 거래 금액, 사용자 권한) 전송 시, 데이터의 무결성을 검증하는 로-직(예: 해시, 전자서명)을 설계하지 않은 경우
  • 관리자 기능과 사용자 기능 간의 데이터 흐름에 대한 접근 제어 설계가 미흡한 경우
  • 로그 파일이 위변조될 가능성을 고려하지 않고 설계한 경우
• 고려사항: "데이터가 생성, 전송, 저장되는 과정에서 무결성을 보장하기 위한 통제 장치가 설계에 반영되었는가?"

3. Repudiation (부인 방지) انکار

• 위협: 사용자가 자신이 수행한 특정 행위를 부인하는 것입니다. (예: "저는 그 결제 버튼을 누른 적이 없어요!")
• 안전하지 않은 설계 예시:
  • 사용자의 주요 행위(예: 로그인, 중요 정보 수정, 결제)에 대한 로그를 기록하도록 설계하지 않은 경우
  • 누가, 언제, 무엇을 했는지 추적할 수 있는 감사 추적 기능의 설계가 누락된 경우
• 고려사항: "사용자나 시스템의 모든 중요 행위가 부인할 수 없도록 기록되고 추적되도록 설계되었는가?"

4. Information Disclosure (정보 노출) 📂

• 위협: 허가되지 않은 사용자가 민감한 정보에 접근하는 것입니다.
• 안전하지 않은 설계 예시:
  • 에러 발생 시, 시스템의 상세한 내부 정보(예: DB 버전, 코드 일부)를 사용자에게 그대로 노출하도록 설계한 경우
  • URL 파라미터를 통해 민감한 정보(예: 사용자 ID)를 예측 가능하게 설계한 경우
  • 데이터베이스나 파일 시스템에 저장되는 중요 정보를 암호화하지 않고 평문으로 저장하도록 설계한 경우
• 고려사항: "민감 정보가 저장, 처리, 전송되는 모든 구간에서 기밀성을 유지하도록 설계되었는가? 권한 없는 접근을 어떻게 막을 것인가?"

5. Denial of Service (서비스 거부) 🚦

• 위협: 공격자가 시스템의 리소스를 고갈시켜 정상적인 사용자가 서비스를 이용할 수 없게 만드는 것입니다.
• 안전하지 않은 설계 예시:
  • 특정 기능에 대한 사용량 제한(Rate Limiting)이나 자원 할당량 제한을 설계에 반영하지 않은 경우 (예: 파일 업로드 크기, API 요청 횟수)
  • 비용이 많이 드는 API 호출을 아무런 제약 없이 허용하도록 설계한 경우
• 고려사항: "외부의 과도한 요청이나 자원 사용으로부터 시스템을 보호하고 가용성을 유지하기 위한 장치가 설계에 포함되었는가?"

6. Elevation of Privilege (권한 상승) 🚀

• 위협: 일반 사용자가 관리자나 다른 사용자의 권한을 획득하여 허가되지 않은 작업을 수행하는 것입니다.
• 안전하지 않은 설계 예시:
  • 사용자 권한을 단일 역할(예: admin, user)로만 단순하게 설계하여 세분화된 접근 제어가 불가능한 경우
  • 관리자 기능에 접근할 때 추가적인 인증 절차를 요구하도록 설계하지 않은 경우
  • 사용자 입력값을 통해 시스템의 다른 구성 요소에 영향을 미칠 수 있도록 데이터 흐름을 설계한 경우
• 고려사항: "최소 권한 원칙에 따라 모든 기능에 대한 접근 제어가 명확하게 설계되었는가? 권한 상승 경로가 될 수 있는 부분은 없는가?"

---

결론: 안전한 설계는 선택이 아닌 필수! ✅

'안전하지 않은 설계'는 단순히 코딩 실수 몇 개를 고치는 것만으로는 해결할 수 없는, 훨씬 더 근본적이고 심각한 문제입니다. 개발 초기 단계, 즉 설계 단계에서부터 STRIDE와 같은 위협 모델링 방법론을 활용하여 잠재적인 보안 위협을 미리 식별하고 대응 전략을 수립해야 합니다.

개발팀, 기획팀, 보안팀 모두가 함께 머리를 맞대고 "공격자는 우리 시스템을 어떻게 망가뜨릴 수 있을까?"라는 질문을 끊임없이 던지는 문화가 바로 '설계 기반 보안'의 첫걸음입니다. 튼튼하고 안전한 서비스를 만들기 위해 오늘부터 여러분의 설계도에 STRIDE라는 6개의 렌즈를 들이대 보는 것은 어떨까요? ✨