보안 테스트 심화 — 위협 모델링·인증/인가 우회·API·모바일 보안·침투 테스트·국내 규제

학습 목표

이 모듈 한 줄 요약 — "도구가 못 찾는 것을 사람이 찾는 법". 보안 검사 도구는 누군가 이미 규칙으로 정리해 둔 취약점만 찾는다. "쿠폰을 두 번 적용할 수 있다", "탈퇴한 회원의 배송지가 다른 계정에서 조회된다" 같은 것은 절대 못 찾는다. 우리 서비스에만 있는 규칙이 깨진 경우이고, 그 규칙을 아는 쪽은 도구가 아니라 사람이기 때문이다.

⚠️ 여기서 다루는 것은 우리 시스템을 우리가 점검하는 법이다. 남의 시스템을 건드리는 것은 범죄다. 범위와 승인을 글로 받는 절차가 레슨 5의 주제다.

모듈 16에서 OWASP Top 10과 SAST·DAST·SCA를, 모듈 23에서 SonarQube·Fortify 같은 도구와 스캔 리포트 분류를 배웠다. 거기까지는 이미 알려진 취약점 목록을 도구로 훑는 일 이다. 이 모듈은 그다음을 다룬다. 도구가 알려주지 않는 것 — 우리 시스템에서 무엇이 공격 대상인지, 그 대상을 어떤 순서로 건드려 봐야 하는지, 그리고 나온 결과가 정말 위험한지 를 스스로 판단하는 일이다.

보안 테스트에서 가장 흔한 실패는 취약점을 못 찾는 것이 아니라, 찾은 것을 판정하지 못하는 것이다. 스캐너가 Critical이라고 표시한 항목이 내부망 전용 관리 API의 이야기여서 실제 위험이 낮을 수 있고, Low로 분류된 정보 노출이 다른 결함과 결합하면 계정 탈취로 이어질 수 있다. 그래서 이 모듈은 위협 모델링(STRIDE·공격 트리) 으로 테스트 대상을 먼저 뽑아내는 것에서 시작해, 인증·인가 우회, API, 모바일 앱이라는 세 영역에서 점검 항목을 테스트 케이스로 옮기는 방법 을 연습하고, 침투 테스트의 절차와 보고서를 읽고 검증하는 법으로 마무리한다.

마지막 레슨은 국내 규제다. ISMS-P 인증기준, 개인정보 영향평가, 전자정부 소프트웨어 개발보안 가이드는 한국에서 일하는 QA가 반드시 만나는 세 가지 요구이고, 세 가지 모두 결국 "그 통제가 실제로 작동하는지 확인한 증거를 내놓으라"는 요구다. 이 모듈은 규제 조문을 외우게 하지 않는다. 조문을 점검 케이스와 증거 형식 으로 번역하는 연습을 시킨다.

이 모듈에서 다루는 모든 활동은 자기 조직이 소유하거나 서면 허가를 받은 시스템 을 대상으로 한, 범위가 합의된 방어적 테스트를 전제로 한다. 레슨 5에서 이 전제를 계약 문서 수준으로 구체화한다.

완료 후 할 수 있는 것

• 데이터 흐름도(DFD)에 신뢰 경계를 그리고, STRIDE 여섯 범주로 요소별 위협을 뽑아 테스트 대상 목록으로 바꿀 수 있다
• 공격 트리로 하나의 목표(예: 타인 주문 조회)를 달성하는 경로들을 분해하고, 경로별로 가장 저렴한 공격을 먼저 검증할 수 있다
• 권한 상승·IDOR·세션 탈취 시나리오를 재현 가능한 테스트 케이스(계정 매트릭스·기대 응답 코드·판정 기준)로 설계할 수 있다
• OWASP API Security Top 10(2023)의 10개 항목을 API별 점검 케이스로 옮기고, BOLA와 BFLA를 구분해 검증할 수 있다
• OWASP MASVS v2.x의 8개 통제 그룹을 기준으로 모바일 앱의 저장·통신·플랫폼·복원력 항목을 점검하고 MASTG 테스트와 연결할 수 있다
• 침투 테스트의 RoE(범위 합의서)를 검토하고, 보고서의 발견 사항을 재현성·영향·악용 가능성 기준으로 재판정하며 재검증(retest)을 설계할 수 있다
• ISMS-P 인증기준의 해당 항목을 우리 서비스의 점검 케이스로 옮기고, 개인정보 영향평가 대상 여부를 판단하며, 개발보안 가이드의 보안약점 유형을 리뷰 체크리스트에 넣을 수 있다
• 취약점 하나를 두고 "실제 위험인가"를 공격 전제 조건·영향·보상 통제의 세 축으로 설명하고 심각도를 방어할 수 있다

채용시장에서의 위치

국내 채용시장에서 "보안 QA"라는 단독 직함은 드물다. 대신 세 가지 형태로 수요가 나타난다. 첫째는 ISMS-P 인증 심사를 준비하는 서비스 기업 이 QA 조직에 취약점 점검과 증적 정리를 맡기는 경우, 둘째는 금융·의료·공공 발주 사업 에서 보안성 검토와 개발보안 이행점검이 검수 조건으로 들어가 QA가 그 확인을 담당하는 경우, 셋째는 플랫폼·핀테크 기업의 프로덕트 시큐리티 팀 이 QA 경력자를 뽑아 테스트 설계 역량과 보안 관점을 결합시키는 경우다. 공고 문구로는 "취약점 점검", "모의해킹 결과 조치 관리", "보안 요구사항 검증", "ISMS-P 심사 대응" 같은 표현으로 드러난다.

이 자리에서 약한 지원자는 "Burp Suite를 써 봤다"고 말하고, 강한 지원자는 "모의해킹 보고서 38건 중 14건이 오탐이거나 이미 보상 통제로 막혀 있다는 것을 재현으로 증명해 조치 범위를 줄였다", "결제 API에 BOLA 테스트 케이스를 계정 매트릭스로 넣어 회귀에 포함시켰다" 처럼 판정과 체계를 말한다. 도구 조작은 며칠이면 배우지만, 발견 사항을 위험으로 번역하는 능력은 대체하기 어렵다.

자격으로는 ISMS-P 인증심사원이 국내에서 가장 실효가 큰 편이고, 개발자·테스터 쪽에서는 CEH·OSCP 같은 공격 계열 자격보다 ISTQB·CSTS에 더해 보안 도메인 경험을 증명하는 포트폴리오 가 QA 채용에 더 잘 맞는다. 공격 자격은 전담 모의해킹 인력에게 요구되는 경우가 많다. QA가 보안으로 확장할 때의 차별점은 침투 기술의 깊이가 아니라, 재현 가능한 케이스로 만들어 회귀에 남기는 능력 이다.

한 가지 주의할 점이 있다. 보안 테스트는 허가 범위를 벗어나는 순간 업무가 아니라 법적 문제가 된다. 정보통신망법은 정당한 접근권한 없는 침입을 처벌하며, 사내 시스템이라도 승인 없는 테스트는 징계 사유가 될 수 있다. 이 모듈을 마친 사람의 첫 행동은 도구 설치가 아니라 테스트 범위와 승인 절차를 문서로 확인하는 것 이어야 한다.