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