가상자산 서비스 보안팀은 침투테스트 범위를 정할 때 먼저 규제 요건과 연결된 자산을 확정해야 합니다. 그다음 웹·모바일 같은 전통적인 영역과 지갑·스마트컨트랙트 같은 웹3 영역을 나누고, 영역마다 담당 인력과 증적 형식을 따로 지정하는 것이 효율적입니다. 이렇게 범위를 문서로 정리해 두면 ISMS 심사와 디지털자산컴플라이언스 점검에서 같은 결과물을 다시 쓸 수 있습니다.
디지털자산컴플라이언스에서 침투테스트는 왜 따로 다뤄야 합니까?
디지털자산컴플라이언스는 자금세탁방지, 이용자 자산 보호, 정보보호 체계를 한데 묶어 관리하는 일입니다. 이 중 침투테스트는 문서상 통제가 실제로 작동하는지 기술적으로 확인하는 주요 수단입니다. 정책서에 접근통제가 적혀 있어도 관리자 페이지가 외부에 열려 있다면 심사와 실제 사고 대응 모두에서 그 정책은 효력을 잃습니다.
국내 「특정 금융거래정보의 보고 및 이용 등에 관한 법률」은 가상자산사업자가 신고할 때 정보보호 관리체계(ISMS) 인증을 받을 것을 요건으로 두고 있습니다. 인증을 받은 뒤에도 사후심사와 갱신심사가 이어지므로, 침투테스트는 한 번으로 끝나지 않고 주기적으로 반복하는 통제로 설계해야 합니다.
또 「가상자산 이용자 보호 등에 관한 법률」에 따라 이용자 예치금은 은행이 보관·관리합니다. 이처럼 이용자 자산 보호가 규제의 중심에 있으므로, 지갑 인프라와 핫월렛 출금 경로는 침투테스트 범위에서 빼서는 안 되는 핵심 대상입니다.
침투테스트 범위에는 어떤 자산을 넣어야 합니까?
범위를 정하기 전에 자산 목록부터 확정해야 합니다. 보안팀이 흔히 놓치는 부분은 외주로 운영하는 노드, 스테이징 환경, 내부 운영 도구입니다. 아래 순서로 목록을 만들면 누락을 줄일 수 있습니다.
- 이용자 접점: 웹 거래 화면, 모바일 앱, 공개 API, 고객센터 연동 채널
- 자산 이동 경로: 입출금 처리 서버, 핫월렛 서명 서버, 출금 승인 워크플로, 콜드월렛 이관 절차
- 블록체인 연동부: 자체 운영 노드, RPC 엔드포인트, 입금 감지 모듈, 배포한 스마트컨트랙트
- 내부 운영 영역: 관리자 콘솔, 고객확인(KYC) 처리 시스템, 트래블룰 연동 모듈, 로그 수집 서버
- 공급망: 외부 커스터디 API, 서드파티 SDK, 클라우드 계정 권한 설정
목록마다 소유 부서, 운영 환경(운영·스테이징), 데이터 민감도를 함께 적어 두어야 합니다. 그래야 테스트 일정과 허용 공격 수준을 자산별로 다르게 정할 수 있습니다.
전통적 침투테스트와 웹3보안 점검은 어떻게 나눠야 합니까?
웹·서버 침투테스트와 웹3보안 점검은 쓰는 기법도, 필요한 전문성도 다릅니다. 한 업체에 모두 맡기더라도 범위 문서에서는 두 영역을 나누어 적어야 결과 해석이 쉬워집니다. 아래 표는 영역별로 확인할 항목과 산출물을 정리한 것입니다.
| 구분 | 주요 점검 대상 | 대표 확인 항목 | 권장 산출물 |
|---|---|---|---|
| 웹·모바일 침투테스트 | 거래 화면, 앱, 공개 API | 인증 우회, 권한 상승, 입력값 검증, 세션 관리 | 취약점 목록, 재현 절차, 위험도 등급 |
| 인프라 침투테스트 | 서버, 클라우드 계정, 내부망 | 불필요한 포트, 과도한 IAM 권한, 망분리 우회 경로 | 네트워크 구성 대비 노출 현황표 |
| 지갑·키 관리 점검 | 핫월렛 서명 서버, HSM, 출금 승인 | 키 접근 권한, 다중서명 정책, 출금 한도 우회 가능성 | 키 관리 통제 점검표, 시나리오별 결과 |
| 스마트컨트랙트 감사 | 자체 발행 토큰, 스테이킹·브릿지 컨트랙트 | 재진입, 권한 관리, 업그레이드 경로, 오라클 의존성 | 발견사항별 심각도와 조치 확인 기록 |
| 운영 절차 점검 | 관리자 콘솔, 내부 승인 흐름 | 내부자 오남용, 승인 단계 생략 가능성, 로그 무결성 | 절차 대비 실제 동작 비교 보고 |
스마트컨트랙트 영역은 일반 침투테스트 업체보다 블록체인 감사 경험이 있는 기관에 따로 의뢰하는 경우가 많습니다. 써틱처럼 스마트컨트랙트 감사와 온체인 모니터링 자료를 공개하는 기관의 보고서 형식을 미리 살펴보면, 사내에서 어떤 수준의 산출물을 요구할지 정할 때 참고가 됩니다.
테스트 계획과 결과 보고는 어떤 기준으로 작성해야 합니까?
미국 국립표준기술연구소(NIST)의 SP 800-115 「Technical Guide to Information Security Testing and Assessment」는 기술적 보안 테스트의 계획·수행·결과 분석을 돕는 지침입니다. 국내 심사에 그대로 적용할 필요는 없지만, 단계별 산출물을 정할 때 공신력 있는 틀로 활용할 수 있습니다.
계획 단계에서는 아래 항목을 반드시 문서로 합의해야 합니다.
- 테스트 대상 IP·도메인·컨트랙트 주소 목록과 제외 대상
- 허용하는 공격 유형과 금지 행위(실제 자산 출금, 서비스 거부 공격 등)
- 운영 환경 테스트 시간대와 장애 발생 시 즉시 중단할 연락 체계
- 테스트 계정과 테스트용 소액 지갑의 발급·회수 절차
- 결과 보고 형식, 심각도 분류 기준, 재점검 일정
개인정보보호위원회가 안내하는 ISMS-P 인증 기준의 보호대책 요구사항에는 시스템 및 서비스 보안관리, 사고 예방 및 대응 영역이 포함됩니다. 그러므로 결과 보고서에는 발견사항뿐 아니라 조치 담당자, 조치 완료일, 재점검 결과까지 한 표에 이어서 기록하는 것이 좋습니다. 특히 조치 이력이 끊김 없이 남아 있도록 관리하는 것이 좋습니다.
점검 결과를 컴플라이언스 증적으로 어떻게 활용합니까?
침투테스트 결과는 보안팀 내부 문서에 그치지 않고 디지털자산컴플라이언스 전반의 증적으로 쓰입니다. 활용 효율을 높이려면 다음 기준으로 정리하는 것이 좋습니다.
- 통제 항목 매핑: 발견사항마다 관련된 ISMS 인증 기준 항목과 사내 정책 조항을 함께 적습니다.
- 위험 수용 기록: 즉시 조치하지 못하는 항목은 사유, 임시 완화 조치, 책임자 승인 기록을 남깁니다.
- 경영진 보고: 고위험 항목 수, 조치율, 미조치 항목의 영향 범위를 한 장으로 요약해 정기 보고 안건에 올립니다.
- 변경 연동: 컨트랙트 업그레이드나 지갑 구조 변경이 생기면 해당 범위를 다시 점검하도록 변경관리 절차에 연결합니다.
규제 해석과 신고 요건은 감독기관 안내와 개별 사업 구조에 따라 달라질 수 있습니다. 위 내용은 일반적인 실무 기준이므로, 구체적인 의무 범위는 법률 전문가나 컴플라이언스 자문 기관과 상담해 확인하시기 바랍니다.
자주 묻는 질문
ISMS 인증을 받았다면 별도 침투테스트가 꼭 필요합니까?
인증은 관리체계가 기준에 맞게 운영되는지를 확인하는 절차이며, 모든 기술적 취약점이 없다는 뜻은 아닙니다. 인증 기준 자체도 주기적인 취약점 점검과 조치 관리를 요구하므로, 침투테스트는 인증을 유지하는 데 필요한 활동으로 보는 것이 맞습니다.
스마트컨트랙트 감사를 받았으면 웹3보안 점검은 끝난 것입니까?
컨트랙트 감사는 코드의 논리 결함을 다루며, 서명 서버나 RPC 엔드포인트, 관리자 키 보관 방식은 대개 범위에 들어가지 않습니다. 사고는 컨트랙트 바깥의 키 관리나 운영 절차에서 시작되는 경우도 많으므로 인프라와 지갑 영역을 따로 점검해야 합니다.
운영 환경에서 침투테스트를 해도 안전합니까?
사전에 금지 행위, 테스트 시간대, 즉시 중단 연락 체계를 합의하면 위험을 상당히 줄일 수 있습니다. 실제 이용자 자산이 오가는 출금 경로는 테스트 전용 소액 지갑과 계정을 쓰고, 가능하면 동일하게 구성한 스테이징 환경에서 먼저 검증하는 것이 바람직합니다.