이 시리즈의 첫 두 편에서는 크립토 기관이 왜 블록체인 침투 테스트를 필요로 하는지(1편)와 이 분야가 무엇인지(2편)를 다루었습니다. 이번 글에서는 기관 차원의 인게이지먼트를 어떻게 준비하고 안전하게 진행하는지, 즉 인게이지먼트 규칙(RoE), 프로덕션 안전 안전장치, 그리고 발견 사항을 수정으로 이어지게 하는 개선 및 재테스트—아래에 나타난 인게이지먼트 라이프사이클로 넘어갑니다.

Web3는 특정한 방식으로 프로덕션 테스트의 위험도를 높입니다: 온체인 작업은 일반적으로 되돌릴 수 없고, 테스트 활동이 종종 온체인에서 공개적으로 노출되며, 대상 시스템은 실제 자금을 이동시킬 수 있습니다. 따라서 아래의 안전장치들은 일반적인 인게이지먼트보다 환경 선택, 가치 제한, 키 관리, 그리고 대조 확인(reconciliation)에 더 큰 비중을 둡니다.
Blockchain Penetration Testing
컨트랙트, 노드, API, 클라우드를 아우르는 침투 경로를 찾아냅니다
운영 권한으로서의 RoE
미국 국립표준기술연구소(NIST)에 따르면 RoE는 보안 테스트를 위한 가이드라인과 제약 조건을 설정합니다 [1]. 기관 차원의 인게이지먼트에서 RoE는 테스트를 하겠다는 결정을 승인된 위임으로 전환합니다: 명확한 목표, 명확한 범위, 그리고 행동할 수 있는 지정된 권한입니다.
이 위임이 중요한 이유는 테스트 팀이 계약서나 자산 목록으로부터 권한을 안전하게 추론할 수 없기 때문입니다. 평가할 위험, 관련 시스템, 그리고 그 시스템에 대한 책임자에 대한 공유된 결정이 없다면, 팀은 잘못된 경로를 테스트하거나, 중요한 종속성을 제외하거나, 중대한 발견 사항을 검증할 권한이 없을 수 있습니다.
시작점은 테스트가 지원하고자 하는 비즈니스 결정입니다. 목표는 출시 전 공개 노출과 관련될 수 있습니다. 고객 및 애플리케이션 프로그래밍 인터페이스(API) 인가에 초점을 맞출 수도 있고, 권한이 있는 클라우드 및 운영 시스템의 접근 가능성에 초점을 맞출 수도 있습니다. 또한 서명 또는 인출 워크플로를 테스트하거나 서드파티 통합을 평가할 수도 있습니다. 이 목표는 중요한 시스템, 줄여야 할 위험, 그리고 경영진이 결정을 내리기 위해 필요한 결과를 식별합니다.
목표는 운영 모델을 따르는 범위로 전환되어야 합니다. 크립토 기관에서는 일반적으로 고객 대상 웹, 모바일, 애플리케이션 프로그래밍 인터페이스(API) 서비스; 클라우드 계정 및 신원 및 접근 관리(IAM); 지속적 통합 및 지속적 배포(CI/CD) 시스템 및 시크릿; 운영 콘솔; 지갑 및 승인 워크플로; 서명 시스템; 원장 및 인출 서비스; 그리고 이들을 연결하는 벤더가 포함됩니다. 이 구성 요소들은 고객과 내부 팀이 자금 관련 작업을 시작, 승인, 서명, 실행, 그리고 대조 확인하는 방식을 함께 관리합니다. 기관과 테스트 팀은 관련 관점, 즉 외부 공격자, 일반 사용자, 파트너, 낮은 권한을 가진 직원, 또는 이미 침해된 것으로 가정된 신원에 대해서도 합의해야 합니다.
범위에 포함된 각 시스템, 계정, 인터페이스, 활동에는 지정된 소유자와 명확한 승인 경로가 있어야 합니다. 이는 커스터디 제공업체, 지갑 인터페이스, 원격 프로시저 호출(RPC) 제공업체, 서비스형 소프트웨어(SaaS) 플랫폼, 신원 제공업체, 코드 호스트, 그리고 관리형 서비스를 포함한 서드파티 종속성에도 동일하게 적용됩니다. 제공업체가 소유한 환경을 테스트하려면 해당 제공업체의 서면 허가가 필요합니다. 기관의 승인만으로는 제공업체 시스템에 대한 활동이 승인되지 않을 수 있습니다.
목표, 범위, 승인 경로가 함께 작용하여 팀이 평가할 수 있는 대상을 확립합니다. 다음 단계는 팀이 그 평가를 수행할 수 있는 방식을 기록하는 것입니다.
운영 경계
운영 경계는 위임이 합의된 후 실행을 규율하는 서면 제약 조건입니다. 이는 범위에 포함된 것과 허용되는 활동을 구분합니다: 프로덕션 인출 서비스는 승인 경로 검증을 위해 범위에 포함될 수 있지만, 실제 고객 인출, 개인 키 추출, 지속성 변경, 부하를 발생시키는 공격은 여전히 금지됩니다.
이 구분은 불확실성이 운영 위험으로 변하는 것을 막습니다. 프로덕션 인게이지먼트 동안, 기관과 테스트 팀은 어떤 기법이 허용되는지, 활동을 언제 중단해야 하는지, 누가 그 결정을 내릴 수 있는지, 그리고 증거를 어떻게 다루어야 하는지를 사전에 알아야 합니다. 그렇지 않으면 승인된 테스트조차 피할 수 있었던 서비스나 고객 영향을 일으킬 수 있습니다.
RoE는 테스트가 시작되기 전에 이러한 결정을 기록해야 합니다. 또한 이 문서는 인게이지먼트 도중 근본적인 질문을 다시 열지 않고도 양측이 행동할 수 있을 만큼 정확해야 합니다.
아래 표는 위에서 확립한 테스트 위임을 실용적인 RoE 기록으로 전환합니다. 이는 테스트 전에 확정해야 할 결정들을 그룹화합니다: 무엇을 평가하는지, 누가 승인되었는지, 어떤 활동과 제한이 적용되는지, 당사자들이 어떻게 조율하는지, 그리고 증거를 어떻게 다루는지입니다. 이는 그대로 복사할 일반적인 체크리스트가 아닙니다. 기록된 값은 기관의 운영 모델, 테스트 관점, 프로덕션 위험을 반영해야 합니다.
| RoE 항목 | 테스트 전에 기록할 결정 |
|---|---|
| 목표 및 범위 | 비즈니스 결정, 범위에 포함된 시스템 및 인터페이스, 소유자, 그리고 테스트할 공격자 관점. |
| 승인 | 서면 권한, 테스트 신원, 승인된 접근 경로, 서드파티 환경에 대한 제공업체 승인. |
| 테스트 방법 및 완료 조건 | 허용된 기법과 팀이 중단해야 하는 시점, 예를 들어 증명된 접근, 권한 상승, 또는 통제된 워크플로 시뮬레이션. |
| 운영 제한 | 테스트 시간대, 요청 속도 및 동시성 제한, 계정 작업 제한, 데이터 접근 경계, 변경 동결 기간, 그리고 승인된 시나리오가 트랜잭션을 사용하는 경우 허용된 네트워크, 테스트 주소, 트랜잭션 유형, 최대 테스트 가치, 가스 예산. |
| 금지된 활동 | 서비스 거부 테스트, 소셜 엔지니어링, 실제 고객 자산 이동, 개인 키 반출, 지속성, 승인되지 않은 프로덕션 변경 등이 예시입니다. |
| 민감한 워크플로 | 지정된 지갑 및 계정, 허용 목록에 등록된 대상지, 최대 테스트 가치, 승인 참여자, 예상되는 정책 동작, 대조 확인 단계, 그리고 검증이 도달할 수 있는 트랜잭션 통제 체인의 최대 지점. |
| 커뮤니케이션 및 일시 중지 | 일상적인 통지 모델, 보호된 안전 채널, 에스컬레이션 담당자, 중대한 발견 사항 기준, 테스트를 일시 중지하거나 재개할 지정된 권한, 그리고 승인된 공개 트랜잭션 브로드캐스트에 대해 예상되는 관측 가능성 및 알림 처리. |
| 증거 처리 | 필요한 최소한의 증거, 데이터 최소화 및 편집, 암호화, 승인된 수신자, 보존 기간, 파기 확인, 그리고 승인된 테스트 트랜잭션에 대한 내부 승인 및 원장 증거와 연결된 트랜잭션 해시 및 네트워크 메타데이터. |
실행 경계가 합의되면, 기관은 테스트에서 마주하게 될 배포된 시스템과 운영 조건을 준비할 수 있습니다.
운영 환경 및 실제 서비스 보호
운영 환경은 배포된 시스템과 그 주변의 비즈니스 활동입니다: 신뢰 경계, 자금 흐름, 서비스 종속성, 운영 워크플로, 그리고 각 구성 요소에 대한 책임자입니다. 이는 테스트 발견 사항이 실제 의미를 갖게 되는 맥락입니다.
이 맥락이 중요한 이유는 동일한 기술적 약점이 매우 다른 결과를 초래할 수 있기 때문입니다. API 문제, 클라우드 권한, 또는 승인 워크플로 약점은 고객 데이터, 내부 운영, 서명 권한, 잔액 변경, 또는 인출에 영향을 미칠 수 있습니다. 실제 운영 중인 거래소, 결제 회사, 커스터디언, 또는 지갑 제공업체의 경우, 테스트는 거래, 결제, 입금, 인출, 정산, 지원 운영과도 공존해야 합니다.
현재 상황에 대한 파악에는 자산 및 서비스 인벤토리, 아키텍처 및 통합 지점, 클라우드 및 신원 모델, 운영 워크플로, 서드파티 종속성이 포함되어야 합니다. 계획 수립 시에는 관련 비즈니스 기간, 예정된 릴리스, 변경 동결, 고volume 기간, 핫월렛 활동, 그리고 기타 운영 이벤트도 식별해야 합니다. 테스트 중 관찰되는 서비스 상태 신호에는 트랜잭션 및 API 볼륨, 응답 시간, 오류율, 대기열 깊이, 서명 서비스 상태, 지갑 서비스 가용성이 포함되어야 합니다. 운영 환경에는 트랜잭션을 시작하고 통제하는 데 사용되는 프로덕션 서비스, 신원, 운영 워크플로, 외부 종속성이 포함됩니다. RoE는 승인된 테스트 환경, 테스트 신원, 서명 또는 인출 워크플로 내에서 허용된 단계, 그리고 통제된 검증 시나리오에 적용되는 안전장치를 기록합니다. 이러한 파라미터는 정상적인 고객 및 운영 활동을 보호하면서 평가가 기관의 통제에 집중되도록 유지합니다.
유럽연합의 디지털 운영 복원력 법(DORA)은 고규제 산업의 유용한 참고 사례를 제공합니다. 위협 주도 침투 테스트 대상으로 선정된 금융 기관의 경우, 제26조는 테스트가 중요하거나 필수적인 기능을 다루어야 하며 관련 아웃소싱된 정보통신기술(ICT) 서비스를 포함하여 이를 지원하는 프로덕션 시스템에서 수행되어야 한다고 요구합니다 [2]. 이는 프로덕션 테스트에 대한 일반적인 승인이 아닙니다. 각 기관은 여전히 자체적인 권한, 안전장치, 그리고 적용 가능한 법적 및 계약상 승인이 필요합니다.
이 프로덕션 기준선을 통해 기관은 자금이나 고객 접근에 직접 영향을 미칠 수 있는 워크플로에 더 구체적인 안전장치를 적용할 수 있습니다.
민감한 워크플로의 경계
민감한 워크플로는 정상 운영이 자금, 고객 접근, 또는 기록의 무결성에 직접 영향을 미칠 수 있는 시스템과 작업입니다. 여기에는 서명 및 인출 워크플로, 권한이 있는 프로덕션 접근, 고객 데이터 처리, 원장 작업이 포함됩니다.
이러한 워크플로는 더 엄격한 경계가 필요한데, 그렇지 않으면 현실적인 테스트가 통제를 검증하는 것에서 고객이나 재무적 결과를 변경하는 것으로 넘어갈 수 있기 때문입니다. 위험은 단순히 기술적 중단만이 아닙니다: 승인되지 않은 자금 이동, 잘못된 잔액, 민감한 데이터 노출, 또는 테스트 활동과 실제 사고 간의 혼동이 포함될 수 있습니다. 통제 실패가 자금에 영향을 미칠 수 있는 경우, 되돌리는 것이 어렵거나 불가능할 수 있으므로, 이러한 경계는 테스트가 의도하지 않았거나 승인되지 않은 자금 이동을 발생시키지 않도록 유지해야 합니다.
서명 및 인출 워크플로는 기관이 요청을 인증하고, 정책을 적용하고, 승인을 경로화하고, 결과를 대조 확인하는 방식을 검증하는 통제된 시나리오가 필요합니다. RoE는 지정된 테스트 계정, 승인된 참여자, 예상되는 정책 동작, 시나리오의 상한선, 그리고 워크플로를 검증하는 데 필요한 증거를 식별합니다. 그런 다음 허용되는 최대 워크플로 단계, 즉 요청 생성, 정책 결정, 승인 표시, 서명 요청, 실행 결정, 또는 대조 확인을 기록합니다. 테스트 신원은 합의된 접근 프로세스를 통해 프로비저닝, 사용, 그리고 폐기됩니다. 동일한 원칙이 권한이 있는 접근, 고객 데이터, 원장 작업에도 적용됩니다: 접근 모델, 예상되는 시스템 동작, 증거 경계는 테스트 시작 전에 합의됩니다. 고객 데이터는 필요한 경우에만 접근되며, 증거에서 최소화 및 편집되고, 승인된 증거 저장소 내에 보관됩니다.
이러한 통제는 민감한 경로를 일반적인 애플리케이션 기능처럼 취급하지 않고 프로덕션에서 테스트할 수 있게 합니다. 또한 운영팀과 테스트 팀에게 실시간 활동을 조율하기 위한 공통 기반을 제공합니다.
테스트 및 조율
테스트 및 조율은 인게이지먼트를 위한 실시간 운영 모델입니다. 테스트가 진행되는 동안 서비스 소유자, 보안 운영 팀, 사고 대응 기능, 그리고 테스트 리더를 연결합니다.
이 모델이 필요한 이유는 예상된 테스트 활동과 실제 보안 사고가 유사하게 보일 수 있기 때문입니다. 모니터링, 알림, 또는 일시 중지 결정이 명확하지 않으면 테스트가 사고 대응을 지연시키거나 프로덕션 조치가 필요한지에 대한 불확실성을 만들 수 있습니다.
커뮤니케이션 모델은 누가 전체 테스트 계획을 알고 있는지, 누가 시간에 민감한 통지를 받는지, 그리고 누가 활동을 일시 중지하거나 재개할 수 있는지를 식별합니다. 이는 목표에 따라 달라집니다: 일부 테스트는 민감한 시스템 주변에서 긴밀한 보안 운영 센터(SOC) 조율이 필요하지만, 제한된 공개 테스트는 모니터링이 활동을 감지하고 에스컬레이션이 올바른 사람에게 도달하는지를 평가합니다. 통제된 시나리오가 트랜잭션 관련 워크플로를 실행하는 경우, 계획에는 커스터디, 지갑, 트랜잭션 스크리닝, 모니터링 제공업체로부터의 관련 알림 및 예상 경고도 포함됩니다. 별도의 안전 담당자와 지정된 일시 중지 권한은 항상 연락 가능해야 합니다. 서비스 소유자와 테스트 팀은 오류 예산 이탈, 95번째 백분위(p95) 응답 시간 또는 대기열 깊이의 예기치 않은 증가, 의심스러운 계정 또는 지갑 활동, 중대한 대조 확인 불일치, 또는 계획되지 않은 보안 경고와 같은 측정 가능한 중단 기준에 합의합니다.
이러한 준비는 운영 복원력도 강화합니다. 홍콩 증권 및 선물 위원회(SFC)는 가상자산 거래 플랫폼 운영자가 24/7 모니터링과 문서화된 에스컬레이션 절차를 유지하고, 관련 서드파티와 함께 긴급 및 비즈니스 연속성 훈련을 실시할 것을 기대합니다 [3]. 이러한 규제 참조는 예시일 뿐이며 법적 조언이 아닙니다. 적용 가능성은 관할권마다 다르며 법률 자문을 통해 확인해야 합니다.

이 다이어그램은 테스트가 진행되는 동안 적용되는 통제 루프를 보여줍니다. 핵심은 RoE 경계가 승인에서 끝나지 않는다는 것입니다: 모니터링과 안전 채널은 이러한 경계를 재개, 일시 중지, 억제, 또는 검증된 발견 사항을 개선으로 넘기는 결정으로 전환합니다. 이는 앞서 정의한 범위나 프로덕션 준비가 아니라 실시간 조율에 속하는 결정이기 때문에 여기에 등장합니다.
동일한 모델이 중대한 발견 사항도 규율합니다: 승인되지 않은 자금 이동으로의 증명된 경로, 서명 권한 또는 프로덕션 통제 플레인의 침해, 매우 민감한 고객 데이터의 노출, 또는 중요한 서비스에 대한 중대한 위험입니다. 대응 경로는 에스컬레이션 기준, 발견 사항을 분류하는 사람, 관련 활동을 일시 중지할 권한, 그리고 억제, 개선, 검증을 위한 프로세스를 식별해야 합니다. 침투 테스트 팀은 문제를 증명하고 보고합니다. 기관은 프로덕션 결정, 고객 커뮤니케이션, 개선에 대한 권한을 유지합니다. 중대한 발견 사항 통지는 먼저 보호된 안전 채널을 사용해야 하며, 불필요한 익스플로잇 세부사항을 노출하지 않는 합의된 서면 기록이 뒤따라야 합니다.
발견 사항이 억제되고 배정되면, 인게이지먼트의 가치는 기관이 그 결과를 검증된 통제 개선으로 전환할 수 있는지에 따라 결정됩니다.
개선, 재테스트, 그리고 정상 복귀
개선 및 재테스트는 증명된 약점을 검증된 개선으로 전환하는 종료 프로세스입니다. 정상 복귀는 같은 프로세스의 일부입니다: 테스트 접근, 통제된 시나리오, 그리고 수집된 증거는 새로운 장기적 위험이 되어서는 안 됩니다.
이 마지막 단계는 인게이지먼트가 위험을 줄이는지 아니면 단순히 보고서만 생성하는지를 결정합니다. 소유자, 개선 경로, 검증 조건이 없는 발견 사항은 동일한 공격 경로가 프로덕션에 남아있는 동안 계속 미해결 상태로 남을 수 있습니다.
테스트가 시작되기 전에, 발견 사항이 엔지니어링, 클라우드, 지갑 운영, 또는 비즈니스 통제 워크플로에 어떻게 유입되는지, 누가 개선을 책임지는지, 그리고 어떤 발견 사항이 재테스트를 필요로 하는지를 식별하십시오. 종료 시점에는 임시 테스트 신원, 권한, 통제된 시나리오가 원래의 구성으로 복귀하며, 서비스 소유자는 관련 상태 지표가 예상 범위 내에 있는지 확인합니다. 최종 기록은 각 발견 사항을 그 증거, 영향, 소유자, 개선 계획, 재테스트 조건과 연결합니다. 통제된 트랜잭션 관련 시나리오의 경우, 워크플로 참조, 테스트 신원, 타임스탬프, 승인 기록, 그리고 결과 원장 항목도 연결됩니다. 시나리오를 위해 생성된 모든 임시 접근, 승인, 또는 테스트 구성은 폐기됩니다. 증거는 합의된 기간 동안만 보관되며, 그 이후 안전하게 파기되거나 반환됩니다.
그 결과는 취약점 목록이 아니라 기관의 다음 운영 결정을 지원할 수 있는, 테스트되고 개선되고 재테스트된 통제 집합입니다.
결론
블록체인 침투 테스트를 준비하는 것은 기관 차원의 과제입니다. 기관은 목표, 운영 맥락, 권한, 서비스 제약, 대응 모델을 정의하고, 테스트 팀은 그 준비된 환경에 적대적 검증을 적용합니다.
이러한 요소들이 갖춰지면, 침투 테스트 인게이지먼트는 단순한 기술적 훈련을 넘어서게 됩니다. 이는 기관의 배포된 시스템, 사람, 프로세스가 공격 상황에서 어떻게 견뎌내는지를 이해하는 통제된 방법이 됩니다.
BlockSec은 기관이 이 프로세스를 준비하고 실행하는 것을 돕습니다: 범위 정의, 운영 환경 매핑, RoE 및 프로덕션 안전장치 확립, 그리고 발견 사항을 개선되고 재테스트된 통제로 전환하는 것입니다. 다음 테스트를 위한 인게이지먼트 규칙과 프로덕션 안전 통제를 계획하려면 스코핑 대화를 요청하십시오. 자세한 정보는 요청 시 제공됩니다.
시리즈를 계속 읽어보세요:
곧 발행될 이 시리즈의 다른 편들:
- 5편: 인가 및 서명 보안: 웹, dApp, 모바일
- 6편: 클라우드 및 CI/CD 보안: 자동화된 운영 공격 표면
- 7편: 트레저리 통제 플레인 보안: 서명 및 인출 승인
- 8편: 거래소 원장 보안: 도난 경로 및 데이터 플레인 로직
Blockchain Penetration Testing 필러 페이지는 인게이지먼트 차원의 개요를 제공합니다.
Web3를 위한 최고의 보안 감사자
출시 전에 설계, 코드, 비즈니스 로직을 검증하세요
참고 문헌
처음 등장한 순서대로 번호가 매겨짐.
- National Institute of Standards and Technology, Rules of Engagement (ROE), CSRC Glossary.
- European Union, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA), Article 26.
- Hong Kong Securities and Futures Commission, Circular to Licensed Virtual Asset Trading Platform Operators on Custody of Virtual Assets (15 August 2025).



