원본 출처: Beosin

2025년 8월 1일, 홍콩의 스테이블코인 발행자에 대한 규제 제도가 공식 발효되었습니다. 홍콩금융 관리국(HKMA)의 "허가받은 스테이블코인 발행자 감독 지침"과 " 자금세탁 및 테러 자금 조달 방지 지침 (허가받은 스테이블코인 발행자에 적용)"도 동시에 발효되어 스테이블코인 발행자에 대한 세부적인 규제 지침을 제공하고자 합니다.

"허가받은 스테이블코인 발행자 감독 지침" 문서는 홍콩의 스테이블코인 규제 체계에 대한 상세한 기술 사양을 제공하며, 스테이블코인 가치 안정성(전액 준비금), 상환 능력(적시 상환), 위험 분리(준비금 자산의 독립성), 그리고 소비자 보호와 같은 규제 목표를 달성하는 것을 목표로 합니다 . 다음은 Beosin 보안팀이 "허가받은 스테이블코인 발행자 감독 지침"의 블록체인 기술 사양을 해석하고 감사하여 허가받은 기관이 지침에 명시된 블록체인 기술 요건을 충족할 수 있도록 지원하는 내용입니다.

1. 블록체인 기술 사양 해석

자금세탁 및 테러자금조달 방지 지침 제2.1조, 제3.3조 및 제5.4조에 따라 허가자는 사업의 특성, 규모 및 복잡성에 따라 위험 기반 접근 방식을 채택하여 자금세탁 및 테러자금조달 방지 정책, 절차 및 통제 조치를 수립하고 이행해야 하며, 발행 및 환매 시 효과적인 거래 모니터링 시스템을 구현하여 의심스러운 거래를 식별하고 보고하고, 관련 자금세탁 및 테러자금조달 위험을 효과적으로 관리하고 완화해야 합니다.

1. 분산원장

규제 지침은 특정 분산원장(예: 이더리움)을 스테이블코인 발행 네트워크로 명시하지 않습니다. 그러나 제6.5.5조는 라이선스 보유자가 분산원장의 보안 및 신뢰성(예: 일반적인 공격에 대한 방어 능력, 코드 결함, 악용 위험 등)에 대한 상세한 평가를 수행할 것을 명시적으로 권고합니다.

라이선스 취득자는 스테이블코인이 발행되는 분산원장을 엄격하게 평가해야 하며, 안정성과 시장성이 입증된 퍼블릭 블록체인 기반 분산원장을 우선적으로 고려해야 합니다. 또한, 라이선스 취득자는 분산원장에 복구 불가능한 오류가 발생할 경우 스테이블코인 상환을 용이하게 하기 위한 추가 조치를 시행하여 스테이블코인 생태계의 보안성과 안정성을 확보해야 합니다.

2. 토큰 관리

2.1 기술 문서

라이센스 취득자가 발행하려는 각 스테이블코인에 대해 라이센스 취득자는 다음을 명확하게 기록해야 합니다.

• 사용되는 토큰 표준
• 특정 스테이블코인이 발행된 분산원장
• 업그레이드 가능성(있는 경우), 상태 변수, 함수, 함수 수정자, 라이브러리, 인터페이스 등을 포함하여 스테이블코인과 관련된 모든 스마트 계약 (토큰 계약, 프록시 계약, 다중 서명 계약 등)의 아키텍처입니다.

2.2 권한 제어

"감독 지침" 제6.5.3조에서는 라이선스 취득자가 발행하는 각 스테이블코인의 전체 수명 주기 관리와 관련된 모든 작업을 명확하게 정의해야 한다고 권고하고 있습니다. 여기에는 배포, 구성, 주조, 파기, 업그레이드, 중단, 복원, 블랙리스트 등록, 블랙리스트에서 제거, 동결, 동결 해제, 허용 목록에 추가, 운영 중인 모든 지갑 사용 등이 포함됩니다 .

스테이블코인 수명 주기의 각 작업에 대해 라이선스 보유자는 적절한 수준의 권한 부여 및 트리거 조건을 구현해야 합니다. 고위험 작업(예: 계약 배포/업그레이드, 대규모 채굴, 계정 동결)은 다중 서명 계약(예: 5개 서명 중 3개 서명)을 통해 실행되어야 합니다.

추가적인 위험 관리 조치:

• 거래 속도 제한 설정
• 허용된 주소에서만 코인을 주조할 수 있습니다.
• 특정 작업에 대한 시간 잠금 설정
• 특정 작업에 대한 사전 서명 거래, 거래 방송 전 오프체인 시뮬레이션 검증 수행, 서명 거래 확인

2.3 기술 감사

연간 및 이벤트 기반 감사: 규제 지침 제6.5.5조는 라이선스 소지자가 발행된 스테이블코인과 관련된 스마트 계약에 대한 감사를 최소 연 1회 제3자 전문 회사(예: Beosin)에 위탁할 것을 권장합니다. 또한, 특정 스테이블코인의 스마트 계약이 처음 배포, 재배포 또는 업그레이드될 때마다 즉시 감사를 실시해야 합니다. 이러한 접근 방식은 내부 감사의 허점을 해소하고, 스마트 계약이 설계된 대로 올바르게 실행되고 의도된 기능을 충족하는지 확인하며, 계약에 취약점이나 보안 결함이 없음을 높은 수준으로 보장하는 것을 목표로 합니다.

2.4 스테이블코인 모니터링 시스템

감독 지침 제6.5.6조 및 제6.8.3조에서는 라이선스 취득자가 기반 기술의 가용성, 용량, 성능 및 예상되는 업데이트나 변경 사항을 지속적으로 모니터링하고, 이상 현상(스마트 계약 취약성, 하드 포크 및 소프트 포크와 같은 분산원장 관련 이벤트, 심각한 네트워크 혼잡, 중단, 공격 및 복구 불가능한 오류, 개인 키의 무단 사용 등)을 보고하는 조치를 시행할 것을 권고합니다.

3. 키 보안

키 관리(개인 키 및 니모닉 포함)는 규제 지침에서 가장 상세하고 중요한 영역 중 하나입니다. 라이선스 보유자는 키 생성, 배포, 저장, 사용, 백업, 복구 및 파기를 포함하되 이에 국한되지 않는 키 수명 주기 전체를 포괄하는 포괄적인 관리 조치 및 운영 절차를 수립해야 합니다. 특히, 계약 배포 및 업그레이드, 권한 및 역할 관리, 대규모 채굴 및 파기와 같은 스테이블코인 스마트 계약과 관련된 중요 작업의 경우, 키 보안을 보장하고 무단 접근 및 잠재적 위험을 방지하기 위해 더 높은 보안 표준을 채택해야 합니다.

다음은 주요 수명 주기의 권장 구현입니다.

• 키 생성: 중요 키의 경우, 생성 과정은 완전히 오프라인 환경에서 수행되어야 하며 더 높은 수준의 보안을 적용해야 합니다. 실제로 시드 키 및/또는 개인 키 생성은 무단 접근이나 공개를 방지하기 위해 엄격한 물리적 보안 관리 체계가 구축된 물리적으로 격리된 환경에서 수행되어야 합니다.
• 키 저장: 적절한 인증 메커니즘을 갖춘 하드웨어 보안 모듈(HSM) 키는 다음과 같은 안전한 저장 매체에 저장해야 합니다. 이 저장 위치는 엄격한 접근 통제 및 모니터링 시스템이 구축된 홍콩 내 또는 홍콩 금융관리국(HKMA)에서 승인한 다른 안전한 장소여야 합니다. 시드 및/또는 개인 키를 관리하는 데 사용되는 다른 하드웨어 또는 소프트웨어 장치도 동일하게 안전한 환경에서 적절하게 보호해야 합니다. 다중 서명 체계에 사용되는 여러 니모닉 및/또는 개인 키는 집중 위험을 줄이기 위해 별도의 안전한 환경에 저장해야 합니다.
• 키 배포: 라이선스 보유자는 니모닉 및/또는 개인 키의 무결성과 기밀성을 보장하기 위해 안전하고 신뢰할 수 있는 방식으로 배포해야 합니다. 구체적인 조치로는 무결성 검증 메커니즘 적용, 물리적 보안 조치(수동 배포 시나리오), 그리고 배포 과정 중 유출이나 변조를 방지하기 위한 검증된 암호화 알고리즘을 전송 및 저장에 사용하는 것이 있습니다 .
• 키 사용: 라이선스 사용자는 최소 권한 원칙을 준수하고 키 접근을 엄격하게 제한해야 합니다. 키는 키 유출 또는 오용 위험을 줄이기 위해 신뢰할 수 있거나 물리적으로 격리된 안전한 환경에서만 사용해야 합니다.
• 키 교체 및 파기: 라이선스 소지자는 키 유출과 관련된 보안 위험을 완화하기 위해 정기적으로 키를 교체하는 것을 고려해야 합니다 . 또한, 사용하지 않거나 만료된 키를 완전히 파기하여 무단 복구 또는 오용을 방지하는 키 파기 절차를 개발하고 구현해야 합니다.
• 키 백업: 라이선스 소지자는 시드 키 및/또는 개인 키를 홍콩 내 여러 안전한 장소(또는 HKMA가 승인한 다른 장소)에 백업해야 합니다 . 백업의 위치와 내용은 제3자에게 엄격히 기밀로 유지되어야 합니다. 라이선스 소지자는 단일 물리적 장소에 있는 백업에만 의존하여 시드 키 및/또는 개인 키를 복구할 수 없도록 해야 합니다. 백업은 신뢰할 수 있는 매체에 저장해야 하며, 무단 접근을 방지하는 데 필요한 보안 조치와 백업의 무결성과 보안을 보장하는 변조 방지 기능을 갖추어야 합니다.

스테이블코인 보안 감사 프로그램

Beosin은 스테이블코인의 스마트 계약 보안 및 운영 관리 요구 사항에 대응하여 라이선스 취득자에게 블록체인 기술에 대한 자세한 감사 및 기술 지원을 제공하는 다음과 같은 감사 솔루션을 출시했습니다. 이를 통해 라이선스 취득자가 HKMA의 관련 규제 요구 사항 및 운영 표준을 계속 충족할 수 있도록 보장하는 것을 목표로 합니다.

1. 스마트 계약 감사

1.1 감사 범위:

계약 보안 감사는 다음 사항을 포함합니다.

• 스테이블코인 핵심 계약 기능(주식 발행, 파기, 전송, 동결, 중단 등)
• 권한 및 역할 관리 시스템의 설계 및 구현
• 업그레이드 메커니즘(UUPS/투명 프록시)
• 비상 메커니즘 관련 기능(일시 정지, 동결, 블랙리스트, 화이트리스트 등)
• 이벤트 기록 및 체인상 동작 추적
• 인터페이스 표준 호환성(ERC 20, 허가, 메타데이터 등)

1.2 감사 내용:

(1) 주조 및 파괴

• mint() 함수는 권한이 있는 역할에 의해서만 호출될 수 있는지 여부.
• burn()은 잔액과 총 공급량을 올바르게 줄입니다.
• 우회 경로나 논리적 취약점(예: 에스컬레이션을 통한 권한 검사 우회)이 있습니까?
• 오프체인 입금 확인(PoR 서명이나 관리자 확인 등)을 지원할지 여부.

(2) 전송 논리

• transfer()와 transferFrom()이 ERC 20 표준을 준수하는지 여부.
• 동결된 주소나 블랙리스트에 있는 주소에서 송금을 시작하는 것을 방지할지 여부.
• 일시 정지 상태에서 토큰이 이동하는 것을 효과적으로 방지할 수 있는지 여부.

(3) 현탁 및 동결

• pause() / unpause() 및 freeze() / unfreeze()가 특정 역할에 제한되는지 여부.
• 일시 정지 상태에서는 토큰 전송, 주조, 파기 등의 작업이 완전히 정지될 수 있는지 여부.
• 주소 동결 기능이 이체와 주조에 효과적인지 여부.

1.2.2 권한 구조 및 역할 관리

(1) 역할 정의(전체가 아님)

• 관리자: 가장 높은 권한으로 모든 역할과 업그레이드 작업을 관리합니다.
• MINTER: 토큰을 주조할 수 있는 권리.
• 일시 중지 권한: 계약을 일시 중지하고 재개할 수 있는 권한입니다.
• FREEZER: 주소를 동결하고 동결 해제할 권리가 있습니다.
• 업그레이드자: 계약 업그레이드를 시작할 권리가 있습니다.

(2) 권한 설정 확인

• 배포 또는 초기화 중에 모든 역할이 올바르게 할당되었습니까?
• 단일 통제 상실 지점을 피하기 위해 높은 권한 역할은 다중 서명 지갑으로 제어됩니까?
• 취소 및 긴급 교체(예: 시간 잠금 관리)를 지원할지 여부.

(3) 다중서명 및 시간 잠금 제어

• 주조 및 업그레이드와 같은 매우 민감한 작업에 다중 서명 + 타임록 프로세스가 필요합니까?
• 시간 잠금 지연 시간이 48시간 이상이면 허가자와 규제 기관이 관찰하고 대응하기가 더 쉬워집니다.
• 계약에서 보안 업그레이드 프록시 모드(예: UUPS)를 사용하는지 여부.
• initialize() 함수에 초기화 수정자가 추가되었는지 여부.
• 2차 초기화의 위험이 있나요?
• _authorizeUpgrade() 특정 역할에 의해서만 호출을 허용할지 여부입니다.
• 업그레이드 전후의 저장 구조가 일관성을 유지하는지 확인하여 변수 덮어쓰기를 방지합니다.

1.2.4 이벤트 로깅 및 작업 추적

모든 주요 작업이 명시적 이벤트를 발생시키는지 여부.

추천 이벤트는 다음과 같습니다.

• Mint(주소, 단위 256 금액, 주소)
• Burn(주소, 단위 256 금액, 주소)
• 일시 정지(주소 지정) / 일시 정지 해제(주소 지정)
• 동결(주소 대상, 주소 지정) / 동결 해제(주소 대상, 주소 지정)
• 업그레이드(주소 newImpl, 주소)
• 각 이벤트 제안에는 연산자, 대상 주소, 타임스탬프, 세부 매개변수가 포함됩니다.
• 로그 정보는 감사 추적 및 규제 검토를 용이하게 해줍니다.

1.2.5 표준 인터페이스 호환성

• ERC 20 표준 인터페이스가 완전히 구현되었는지 여부(이름, 기호, 소수점, 잔액 등).
• EIP-2612(허가, 가스 허가 없음)가 지원되는지 여부.
• ERC 20 메타데이터가 지갑 식별 및 표시에 지원되는지 여부.
• 모든 표준 인터페이스가 사양에 따라 값을 반환하고 비정상적인 입력을 처리하는지 여부.

2. 운영 및 유지 관리 거버넌스 및 보안 전략 업그레이드

2.1 감사 범위

장기적인 운영 및 유지 관리 과정에서 스테이블코인 계약 시스템의 거버넌스 구조 설계, 권한 관리 로직, 계약 업그레이드 프로세스의 보안, 그리고 핵심 운영 제어 메커니즘에 중점을 둡니다. 이를 통해 프로젝트가 지속 가능한 운영 및 유지 관리 역량을 갖추고 권한 남용 및 버전 하이재킹과 같은 위험에 대처할 수 있는 메커니즘을 갖추도록 보장합니다.

2.2 감사 내용

• 계약 업그레이드 계획: 안전한 업그레이드 모드(예: UUPS 또는 투명 프록시)를 사용하는지 평가하고, 업그레이드 기능에 권한 제어 및 액세스 제한이 있는지 확인하고, 논리 계약과 프록시 계약의 스토리지 레이아웃이 스토리지 충돌 위험을 피하기 위해 일관성이 있는지 확인합니다.
• 업그레이드 권한 경계 및 권한 부여 메커니즘: 업그레이드 작업이 특정 역할(예: UPGRADER)로 제한되는지, _authorizeUpgrade()와 같은 메커니즘이 권한 부여 보호에 사용되는지, 그리고 이러한 권한이 다른 논리에 의해 우회되지 않는지 확인합니다.
• 높은 권한의 작업 제어 메커니즘: 캐스팅, 업그레이드, 동결 등의 작업이 독립적인 역할에 의해 관리되어 여러 책임으로 인한 권한 남용의 위험을 방지하는 등, 시스템에 권한 분립 및 최소 권한 원칙이 있는지 확인합니다.
• 다중 서명 지갑 및 타임락 구성: 주요 권한(ADMIN 및 UPGRADER 등)이 다중 서명 지갑에 의해 제어되는지, 그리고 주요 작업에 대한 지연 창이 타임락 계약을 통해 늘어나 거버넌스 관찰 기간과 위험 버퍼가 도입되는지 확인합니다.
• 역할 시스템 및 권한 수명 주기 관리: 장기 운영 및 유지 관리 역할과 임시 역할(운영 계정, 업그레이드 관리자 등)이 명확하게 구분되어 있는지 평가하고, 역할이 장기간 제어 불능 상태가 되는 것을 방지하기 위한 권한 이전, 취소 및 복구 메커니즘이 있는지 확인합니다.
• 비상 제어 메커니즘: 잠재적인 공격, 외부 보안 사고 또는 내부 운영 오류로 인해 발생하는 시스템적 위험을 방지하기 위해 계약 일시 중지, 역할 동결, 권한 철회와 같은 비상 조치가 지원되는지 분석합니다.
• 업그레이드 동작 기록 및 감사 로그: 업그레이드 및 운영 및 유지 관리 관련 이벤트에 온체인 로그(예: 업그레이드, GrantRole, 일시 중지 등)가 있는지 확인하여 이벤트 이후 추적성을 보장하고 감사 및 규정 준수 조사를 용이하게 합니다.
• 온체인 거버넌스의 적응성 및 확장성: 향후 온체인 거버넌스 모듈을 도입할 계획이라면, 현재의 권한 구조가 거버넌스 계약 인수 작업을 지원하는지, 그리고 거버넌스 결과에 따라 업그레이드, 철회, 동결 및 기타 작업을 실행할 수 있는지 평가하는 것이 좋습니다.

3. 로그 분석 및 위험 모니터링

3.1 감사 범위

Beosin은 운영 중 스테이블코인 계약의 온체인 동작 로그와 그로 인해 발생하는 위험에 초점을 맞춰, 라이센스 소지자가 포괄적인 운영 추적성, 시각적 위험 제어 및 규정 준수 대응 역량을 갖출 수 있도록 로그 수집, 동작 모델링, 위험 식별, 규정 준수 보고 및 실시간 모니터링 시스템 서비스를 제공합니다.

• 온체인 로그 수집 및 분석

계약(Mint, Burn, Transfer, Freeze, RoleGranted 등)에 의해 발생하는 온체인 이벤트를 기반으로 스테이블코인의 전체 수명 주기에 대한 운영 기록이 작성되고, 다양한 계약 버전과 다양한 배포 환경에 대한 로그 호환성 분석이 지원됩니다.

• 자동화된 행동 분석

로그와 온체인 상태 스냅샷을 결합한 행동 모델링을 사용하여 비정상적인 운영 경로, 비정상적인 거래 빈도 및 기타 의심스럽거나 위험도가 높은 행동을 자동으로 식별합니다.

• 위험 수준 식별 및 보고서 생성

시간, 주소, 거래 해시, 작업 유형, 권한 경로 및 기타 정보를 포함하는 표준화된 행동 감사 보고서를 출력하여 프로젝트 당사자가 보관하고 HKMA가 검토할 수 있도록 합니다. 운영 위험 수준은 프로젝트 내부 참조를 위해 보고서에 동시에 표시됩니다.

• 모니터링 시스템 통합 및 알람 메커니즘

Beosin은 대규모 채굴, 비정상적 파기, 권한 변경, 블랙리스트 거래 트리거 등 다양한 지표의 실시간 모니터링을 지원하는 전담 온체인 모니터링 시스템을 제공합니다. 사전 설정된 위험 임계값이 발생하면 시스템은 즉시 알람을 발령하여 프로젝트가 적시에 대응할 수 있도록 지원합니다.