✅ [개념정리] OWASP Top 10 파헤치기 (4/10): A04 - 안전하지 않은 설계 (Insecure Design)

안전하지 않은 설계란 "개발 초기 설계 단계부터 보안 위협을 충분히 고려하지 않아 발생하는 문제"를 말해. 이건 코드 한 줄을 잘못 짜는 '구현(implementation)'의 실수라기보다는, 애초에 건물의 '설계도(design)' 자체가 잘못된 것과 같아. 보안 기능이 없거나, 있더라도 허술하게 설계된 모든 경우가 여기에 해당되지.

 

---

Part 1: 안전하지 않은 설계(Insecure Design)란 무엇일까? 🤔 – "첫 단추를 잘못 끼우다"

이 취약점은 코드상의 버그(bug)가 아니라, **설계상의 결함(flaw)**이라는 점이 중요해.

🏦 은행 건물 비유로 쉽게 이해하기

• 안전한 설계: 은행을 짓는 건축가가 처음부터 두꺼운 벽의 금고, CCTV, 비상벨, 현금 수송차량 전용 출입구까지 모두 설계도에 반영해서 짓는 것.
• 안전하지 않은 설계: 건축가가 오직 미관과 고객 편의성만 생각해서 사방이 유리로 된 멋진 은행을 지었어. 다 짓고 나서야 "아차, 보안!" 하면서 뒤늦게 CCTV를 달고 경비원을 세우지만, 건물 자체의 유리벽과 금고의 부재라는 근본적인 설계 결함은 쉽게 해결할 수 없지.

이처럼, '안전하지 않은 설계'는 나중에 보안 패치를 덧대는 것만으로는 해결하기 어려운, 아키텍처 수준의 근본적인 보안 문제점을 의미해.

---

Part 2: 어떤 설계 실수가 있을까? (안전하지 않은 설계의 유형)

• 유형 1: 허술한 비즈니스 로직 설계
  • 시나리오: 한 온라인 쇼핑몰에서 "신규 가입 1회용 50% 할인 쿠폰" 이벤트를 열었어. 그런데 쿠폰을 적용했다가, 취소하고, 다시 적용하는 과정을 반복하면 중복으로 할인이 적용되는 설계상의 허점이 있었어!
  • 문제점: 쿠폰을 적용하는 코드 자체에는 버그가 없었지만, "쿠폰은 한 번만 사용되어야 한다"는 비즈니스 규칙을 강제하는 설계가 빠져있어서 회사에 금전적 손실을 입혔어.
• 유형 2: 위협 모델링(Threat Modeling)의 부재
  • 시나리오: 사용자가 프로필 사진을 업로드하는 기능을 만들 때, 개발팀은 정상적인 이미지 파일만 올라올 것이라고 가정했어. 하지만 공격자가 100GB짜리 거대 파일을 업로드해서 서버의 디스크를 가득 채우거나(Denial of Service), virus.exe 같은 악성 파일을 업로드하는 경우를 전혀 고려하지 않았지.
  • 문제점: 기능을 설계할 때 "만약 공격자가 이 기능을 악용한다면 어떻게 할까?"를 미리 고민하고 대책을 세우는 '위협 모델링' 과정이 누락된 거야.
• 유형 3: 안전장치 없는 기능 설계
  • 시나리오: 비밀번호 찾기 기능을 설계할 때, 아이디나 이메일 주소만 입력하면 바로 임시 비밀번호를 발급해 주도록 만들었어. 본인인증을 위한 추가 질문이나, 이메일로 인증 링크를 보내는 등의 2차 검증 절차가 전혀 없었지.
  • 문제점: 기능은 설계된 대로 완벽하게 동작하지만, 그 설계 자체가 보안적으로 매우 취약한 거야. 공격자가 다른 사람의 아이디만 알면 계정을 쉽게 탈취할 수 있어.

---

Part 3: 어떻게 처음부터 안전하게 설계할까? (대응 방안)

"나중에 고치지 말고, 처음부터 잘 만들자!"가 핵심이야.

1. 보안 중심 소프트웨어 개발(Secure SDLC) 문화 정착: 보안은 개발 마지막에 하는 검수 과정이 아니야! 기획, 설계, 개발, 테스트, 배포, 운영까지 소프트웨어 개발의 모든 생명주기에 보안 활동을 자연스럽게 녹여내야 해.
2. 위협 모델링(Threat Modeling) 생활화: 새로운 기능을 설계할 때마다, 공격자의 입장에서 "이 기능을 어떻게 악용할 수 있을까?", "어떤 데이터가 위험에 처할 수 있을까?", "어떤 보안 통제가 필요할까?"를 미리 식별하고 평가하며 대책을 수립하는 과정을 거쳐야 해.
3. 안전한 설계 패턴(Secure Design Patterns) 활용: 바퀴를 새로 발명할 필요는 없어. 이미 업계에서 검증된 안전한 설계 패턴들을 적극적으로 배우고 적용해야 해. (예: 중앙 집중식 접근 제어, 모든 통신 구간 암호화, 장애를 대비한 설계 등)
4. 재사용 가능한 보안 라이브러리 및 컴포넌트 사용: 인증, 암호화, 세션 관리처럼 중요한 보안 기능은 직접 만들려고 하지 말고, 전문가들에 의해 검증된 안전한 라이브러리, 프레임워크, 컴포넌트를 사용하는 것이 훨씬 안전해.

---

[마무리하며 ✨]

오늘은 네 번째 취약점인 '안전하지 않은 설계'에 대해 알아봤어. 이 항목은 우리에게 **"보안은 개발 초기 단계부터 시작되어야 하는 '문화'이자 '프로세스'"**라는 중요한 메시지를 던져주고 있어.

코딩 실력도 중요하지만, 그에 앞서 "어떻게 하면 더 안전한 시스템을 만들 수 있을까?"를 고민하는 보안 설계 마인드를 갖추는 것이 미래의 보안 전문가에게는 더욱 중요한 역량이 될 거야!

다음 시간에는 다섯 번째 취약점, "A05: 보안 설정 오류 (Security Misconfiguration)" 에 대해 자세히 알아볼게! 기대해도 좋아! 😊