개념
서면 인가 없이는 시작하지 않는다
침투 테스트와 불법 침입을 가르는 것은 기술이 아니라 문서 다. 같은 요청을 보내도 승인 범위 안이면 업무이고, 밖이면 법적 문제다. 국내에서는 정보통신망법이 정당한 접근권한 없는 침입과 장애 유발을 금지하고 있고(해당 조문은 법령 원문 확인), 사내 시스템이라도 승인 없는 테스트는 징계 사유가 된다. 그래서 이 레슨의 첫 문장은 이렇게 고정된다.
대상·기간·허용 행위가 서면으로 정해지지 않았으면 도구를 켜지 않는다. 구두 승인, 슬랙 메시지, "팀장이 알고 있다"는 말은 인가가 아니다.
QA가 이 원칙을 아는 것이 왜 중요한가. 실무에서 범위를 벗어나는 사고는 악의에서 나오지 않고 선의에서 나온다. "여기까지 봤는데 저것도 확인해 보고 싶어서", "스테이징이 아니라 운영인 걸 몰라서", "연동된 외부 결제 게이트웨이도 우리 시스템인 줄 알고". 세 가지 모두 RoE에 한 줄만 있었으면 막혔을 일이다.
범위 합의서(Rules of Engagement)에 들어가는 것
RoE는 계약서의 부속 문서이거나, 사내 테스트라면 승인 요청서의 본문이다. 최소한 아래 항목이 있어야 한다.
| 항목 | 담기는 내용 | 빠지면 생기는 일 |
|---|---|---|
| 대상 자산 | 도메인·IP 범위·앱 패키지명·API 베이스 URL. 범위 밖 자산을 명시적으로 열거 | 공용 인프라나 SaaS를 건드려 제3자 피해 |
| 환경 | 운영/스테이징 중 어디인가, 데이터가 실제 개인정보인가 | 운영 데이터가 테스트 산출물로 유출 |
| 기간과 시간대 | 시작·종료 일시, 업무시간 외 수행 여부 | 피크 시간대 부하로 장애 |
| 허용 행위 | 스캔 강도, 취약점 실증(PoC) 허용 범위, 계정 탈취 시도 허용 여부 | "어디까지 해도 되나"를 매번 물어봐야 함 |
| 금지 행위 | 서비스 거부(DoS) 시도, 데이터 파괴·변조, 실제 고객 계정 사용, 사회공학, 물리적 침입 | 복구 불가능한 피해 |
| 계정과 권한 | 테스트용 계정 목록과 각 계정의 역할 | 테스터가 실계정을 쓰거나 가입 절차에서 막힘 |
| 비상 연락과 중단 조건 | 담당자 연락처(주·부), 즉시 중단 트리거, 장애 시 에스컬레이션 경로 | 새벽에 장애가 나도 누구에게 전화할지 모름 |
| 데이터 취급 | 발견 과정에서 접근한 데이터의 보관·파기, 산출물 전달 경로, 비밀유지 | 취약점 정보와 고객 데이터가 메일로 떠돌아다님 |
| 결과물과 일정 | 보고서 형식, 중간 보고 시점, 재검증 포함 여부 | 조치 후 재확인을 별도 계약으로 다시 사야 함 |
두 가지를 특히 강조한다. 첫째, 금지 행위를 적는 칸이 허용 행위보다 중요하다. 허용은 해석의 여지가 있어도 금지는 명확하다. 둘째, 중단 조건(stop condition) 이다. "응답 지연이 평시의 몇 배를 넘으면", "장애 알림이 뜨면", "결제 흐름에 영향이 관측되면" 즉시 중단하고 연락한다는 규칙을 숫자로 적어 둔다.
절차 — 여섯 단계
체계마다 이름이 조금씩 다르지만 골격은 같다. NIST의 기술적 보안 시험 가이드(SP 800-115)나 OWASP 웹 보안 테스트 가이드 같은 문서가 참조 체계로 쓰인다.
1 사전 합의 범위·RoE 확정, 승인 서명, 환경·계정·데이터 준비
2 정보 수집 공개 정보·문서·스펙 확인, 표면 목록화
3 탐색 자동 스캔 + 수동 탐색으로 후보 도출
4 검증 후보를 실제로 재현해 영향 확인 (허용 범위 안에서)
5 보고 발견 사항·영향·재현 절차·권고 조치 정리
6 재검증 조치 후 동일 절차로 다시 확인, 잔여 위험 기록QA가 주로 관여하는 구간은 1, 5, 6 이다. 2~4는 전문 인력의 영역이지만, QA가 만들어 둔 테스트 데이터와 환경 정보가 그 구간의 속도를 결정한다.
외부 업체를 쓸 때 QA가 준비하고 확인할 것
외부 모의해킹이 지연되는 이유의 대부분은 취약점이 어려워서가 아니라 준비가 안 돼서 다. 아래를 테스트 시작 최소 한 주 전에 끝내 둔다.
- 환경 격리 확인 — 대상이 스테이징이면 외부 연동(결제·문자·푸시·이메일)이 샌드박스로 향하는지 실제로 확인한다. "설정상 그럴 것"이 아니라 한 건 보내서 어디로 가는지 본다
- 데이터 준비 — 개인정보를 쓰지 않고도 의미 있는 시나리오가 가능한 수준의 가명·합성 데이터. 결제·정산이 걸린 흐름은 금액이 작은 정상 케이스를 미리 만들어 둔다
- 계정 매트릭스 — 역할별 계정(일반·관리자·판매자·차단된 계정 등)과 각 계정으로 할 수 있는 일. 레슨 2에서 만든 매트릭스를 그대로 넘기면 된다
- 엔드포인트 인벤토리 — OpenAPI 스펙, 관리자 화면 목록, 배치·잡 목록, 모바일 앱 빌드. 문서에 없는 엔드포인트가 있으면 미리 말해 준다
- 모니터링 사전 공지 — 보안 관제·인프라·SRE에 기간과 출발지 IP를 알린다. 공지 없이 시작하면 관제가 차단해 테스트가 무의미해지거나, 진짜 침해와 구분이 안 되는 사고 조사가 시작된다
- WAF·봇 차단 정책 — 켜고 할 것인지 끄고 할 것인지, 아니면 둘 다 할 것인지를 정한다. 켠 상태로만 하면 "막혔음"만 남고 근본 결함을 못 찾는다
- 로그 보존 연장 — 테스트 기간의 접근 로그·감사 로그 보존 기간을 늘린다. 재현 대조에 필요하다
- 백업과 복구 리허설 — 데이터 변조가 허용 범위에 있다면 복구 경로를 먼저 확인한다
보고서를 읽는 법
심각도 산정 — CVSS를 어떻게 다루나
CVSS(Common Vulnerability Scoring System)의 현재 판은 v4.0(2023-11 공개) 이다. 점수와 등급의 대응은 다음과 같다.
| 등급 | 점수 구간 |
|---|---|
| None | 0.0 |
| Low | 0.1 ~ 3.9 |
| Medium | 4.0 ~ 6.9 |
| High | 7.0 ~ 8.9 |
| Critical | 9.0 ~ 10.0 |
v4.0에서 실무적으로 가장 중요한 변화는 어떤 지표 묶음으로 계산한 점수인지 이름으로 구분하게 한 것 이다.
| 표기 | 사용한 지표 | 의미 |
|---|---|---|
| CVSS-B | Base | 취약점 자체의 성질만. 환경 무관 |
| CVSS-BT | Base + Threat | 실제 악용 정보까지 반영 |
| CVSS-BE | Base + Environmental | 우리 환경의 완화·중요도 반영 |
| CVSS-BTE | Base + Threat + Environmental | 셋 다 |
벤더 보고서에 적힌 숫자는 대개 CVSS-B 다. 즉 "우리 환경을 모르는 점수"다. 그래서 QA·보안 담당이 해야 할 일은 점수를 의심하는 것이 아니라 환경 지표를 채워 다시 계산하는 것 이다. 그 결과 등급이 내려가면 근거를 남기고, 올라가도 마찬가지로 남긴다. 조정 없이 벤더 점수를 그대로 티켓 우선순위에 쓰면, 내부망 전용 관리 도구의 Medium이 고객 노출 API의 Medium과 같은 대우를 받는다.
주의: 점수는 우선순위 보조 도구 이고, 우선순위 자체는 아니다. 자산 중요도, 노출 범위, 조치 난이도, 규제 요구가 함께 들어간다.
재현 가능성과 실제 영향
발견 사항 하나를 받으면 다음 다섯 질문을 순서대로 던진다.
- 재현되는가 — 적힌 절차로 우리가 다시 만들 수 있는가. 못 하면 절차를 보완해 달라고 요청한다. 재현 안 되는 항목은 조치할 수도, 재검증할 수도 없다
- 전제 조건이 무엇인가 — 관리자 계정이 이미 있어야 하는가, 같은 네트워크에 있어야 하는가, 사용자가 특정 링크를 눌러야 하는가. 전제가 비싸면 위험도 낮아진다
- 영향이 무엇인가 — 무엇을 읽거나 바꿀 수 있게 되는가를 데이터·금액·권한 단위로 쓴다. "정보 노출 가능"이 아니라 "타인의 주문 상세와 배송지를 조회 가능"이다
- 보상 통제가 실제로 막는가 — WAF, 속도 제한, 감사 로그, 승인 절차가 있다고 주장하면 막히는 것을 관측한 증거 를 요구한다. 확인되지 않은 보상 통제로 등급을 낮추지 않는다
- 결합했을 때 어떻게 되는가 — 단독으로는 Low인 정보 노출이 다른 Low와 묶여 계정 탈취 경로가 되는 경우가 실제로 나온다. 레슨 1의 공격 트리가 여기서 쓰인다
오탐과 중복 정리
| 분류 | 판정 근거 | 보고서에 남기는 방식 |
|---|---|---|
| 오탐(false positive) | 재현 불가 + 코드·설정으로 해당 없음이 확인됨 | "오탐" + 확인 방법. 삭제하지 말고 남긴다 |
| 대상 외 | 범위 밖 자산·제3자 서비스 | 범위 밖 표시 + 소유자에게 전달 여부 |
| 이미 인지 | 기존 티켓·예외 승인 존재 | 기존 항목 링크 |
| 중복 | 같은 근본 원인이 여러 엔드포인트에서 관측 | 근본 원인 1건으로 묶고 영향 받는 위치를 목록으로 |
| 유효 | 위 어디에도 해당 없음 | 조치 대상 |
중복 정리는 숫자를 줄이려는 작업이 아니다. 같은 미들웨어 누락이 엔드포인트 40개에서 잡혔다면 티켓 40개가 아니라 한 곳을 고치는 티켓 1개 + 회귀 케이스 40개 가 맞는 형태다. 반대로 원인이 다른 것을 "인가 문제"로 뭉치면 일부만 고쳐지고 나머지가 살아남는다.
조치 우선순위와 재검증
우선순위는 심각도만으로 정하지 않는다. 실무에서 쓰는 네 축이다.
영향 유출·변조되는 데이터의 민감도와 범위
노출 인터넷 공개 / 인증 후 / 내부망 전용
난이도 공격에 필요한 전제 조건의 비용
비용 조치에 드는 시간과 회귀 위험이 네 축으로 "지금 고친다 / 이번 스프린트 / 다음 분기 / 예외 승인"의 네 트랙에 배분한다. 중요한 것은 각 트랙에 기한과 담당자가 붙는다는 점 이다. 기한 없는 "추후 조치"는 조치가 아니다.
재검증(retest)은 조치가 끝난 뒤 원래 절차로 다시 확인하는 것 이다. 세 가지 함정이 있다.
- 다른 절차로 확인한다 — 개발자가 "고쳤다"며 보여주는 화면은 재검증이 아니다. 최초 발견 절차를 그대로 재실행한다
- 한 곳만 확인한다 — 중복으로 묶은 항목은 묶인 위치 전부에서 확인한다. 표본으로 끝내려면 표본 기준을 적어 둔다
- 회귀를 안 만든다 — 재검증에 성공한 케이스는 자동화 회귀 스위트로 옮긴다. 옮기지 않으면 다음 리팩터링에서 되살아난다
조치가 불가능하거나 비용이 과할 때는 예외 승인 으로 처리한다. 예외 문서에는 최소한 이것이 들어간다.
- 대상과 승인 범위, 승인자(조치 담당자보다 상위 결정권자)
- 수용하는 위험의 내용 — "무엇이 일어날 수 있는지"를 한 문장으로
- 보완 통제 — 탐지·모니터링·수동 승인 등 대안과 그것이 동작하는지 확인한 증거
- 재검토 기한 — 기한 없는 예외는 영구 면제가 되어 다음 심사에서 문제가 된다
이 문서가 곧 잔여 위험(residual risk) 기록 이다. 레슨 6의 인증 심사에서 그대로 요구되는 증적이다.
QA와 침투 테스트의 분업
| QA가 맡는 것 | 전문 인력이 맡는 것 | |
|---|---|---|
| 목적 | 알려진 통제가 계속 동작하는지 | 아직 모르는 경로를 깊게 찾기 |
| 주기 | 릴리스마다, CI에서 상시 | 연 1~2회, 큰 변경 후 |
| 산출물 | 자동화 회귀 케이스, 판정 기준 | 발견 사항 보고서, 공격 경로 서술 |
| 깊이 | 설계된 시나리오 안 | 범위 안에서 창의적 탐색 |
두 활동은 서로를 먹인다. 침투 테스트에서 나온 발견은 QA의 회귀 케이스가 되고, QA가 만든 계정 매트릭스와 인벤토리는 침투 테스트의 준비 시간을 줄인다. "모의해킹을 했으니 보안 회귀는 필요 없다" 는 말과 "회귀가 있으니 모의해킹은 필요 없다" 는 말은 둘 다 틀렸다.
실무에서 왜 필요한가
첫째, 보고서를 판정하지 못하면 조치가 멈춘다. 발견 40건이 그대로 40개 티켓이 되면 개발팀은 우선순위를 알 수 없고, 결국 만만한 것부터 처리하다 기간이 끝난다. QA가 오탐·중복·범위 외를 걸러 유효 12건으로 정리하면 그 12건은 실제로 고쳐진다.
둘째, 인증 심사와 발주 검수가 절차의 존재 를 묻는다. 취약점을 몇 건 찾았는지가 아니라, 점검 계획·수행 기록·조치 확인·예외 승인이 한 줄로 이어지는지를 본다(레슨 6).
셋째, 사고 대응과 구분이 된다. 사전 공지와 RoE가 있으면 관제가 테스트 트래픽을 식별할 수 있다. 없으면 같은 트래픽이 침해 사고로 접수돼 조사와 보고 절차가 돌아간다.
넷째, 재검증과 회귀를 연결하는 사람이 QA뿐이다. 외부 업체는 계약 기간이 끝나면 떠난다. 발견을 상시 자산으로 만드는 일은 남는 조직이 한다.