Road to Web3 (19) 스마트컨트랙트 보안 기본 2: 업그레이드 프록시 권한 운영 리스크

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다.

 

이번 편의 목표는 한 문장입니다.

• 온체인 보안의 대형 사고는 취약한 코드 한 줄보다, 업그레이드와 권한과 운영 절차의 빈틈에서 더 자주 터진다

이 글은 세 축을 다룹니다.

• 업그레이드 프록시
• 권한 설계
• 운영 리스크와 사고 대응

 

제가 처음 업그레이드 가능한 컨트랙트를 접할 때 했던 오해는 이렇습니다.

• 코드는 체인에 박히니 운영자가 바꿀 수 없다
• 업그레이드를 넣으면 그냥 편해진다
• 권한은 어드민만 안전하게 관리하면 된다

현실은 이렇습니다.

• 업그레이드 가능성을 넣는 순간, 코드 보안이 아니라 운영 보안이 주 리스크가 된다
• 어드민 키가 뚫리면, 코드가 아무리 깔끔해도 끝난다
• 업그레이드는 기능 배포이면서 동시에 자산 관리자 권한 행사다

web2로 번역하면

• 업그레이드 프록시는 DB 스키마는 그대로 두고 애플리케이션 로직만 핫스왑하는 구조와 닮아 있다
• 권한 키는 마스터 비밀번호나 루트 계정과 비슷하다
• 운영 리스크는 배포 파이프라인과 접근 통제, 변경관리의 문제다

---

 

0) 기본 용어: 프록시와 구현 컨트랙트

업그레이드 프록시는 흔히 이렇게 구성됩니다.

• proxy: 사용자 요청을 받는 주소, 상태 storage를 보관
• implementation logic: 실제 코드, 실행 로직
• admin: proxy가 가리킬 implementation을 바꾸는 주체

사용자는 proxy 주소만 보게 됩니다.
proxy는 호출을 구현 컨트랙트로 위임하고, 상태는 proxy에 쌓입니다.

---

 

1) 왜 업그레이드가 위험해지나: 신뢰 경계가 바뀐다

업그레이드를 허용하면 다음 문장이 성립합니다.

• 동일한 주소가 내일은 다른 코드가 된다

즉, 사용자가 신뢰하는 대상이

• 코드
  에서
• 운영 주체의 변경 행위

로 이동합니다.

이게 위험한 이유는 두 가지입니다.

1) 공격자는 컨트랙트 버그를 찾을 필요가 없고, 키를 훔치면 된다
2) 운영 실수 하나가 곧바로 자산 손실로 연결된다

---

 

2) 업그레이드 방식 대표 3개

2.1 Transparent proxy

사용자 호출은 implementation으로 위임하고, admin만 업그레이드 함수를 호출합니다.
admin이 일반 함수를 호출하면 충돌을 피하기 위해 막아두는 패턴이 많습니다.

2.2 UUPS

proxy는 단순하고, implementation 쪽에 업그레이드 로직이 들어갑니다.
upgrades가 구현에 의존하므로, 업그레이드 함수의 검증 로직이 더 중요해집니다.

2.3 Beacon proxy

여러 proxy가 하나의 beacon을 통해 같은 implementation을 참조합니다.
대규모 시스템에서 유용하지만, beacon이 단일 실패점이 될 수 있습니다.

중요한 공통점

• 업그레이드 권한이 존재하는 순간, 권한 탈취는 곧 코드 교체다

---

 

3) 권한 사고의 전형: 기술보다 운영이 위험한 이유

3.1 키 탈취 또는 서명자 탈락

멀티시그라도

• 서명자 피싱
• 디바이스 탈취
• 내부자 사고
• 인력 변화로 인한 키 분실

이 모두가 현실 리스크입니다.

3.2 권한 과다와 권한 혼재

자주 보이는 위험 패턴

• pause 권한과 upgrade 권한이 같은 키에 묶임
• 운영 편의로 owner를 EOA 단일 키로 둠
• 역할 분리가 없어서 사고 시 피해 범위가 과대

3.3 거버넌스 공격

토큰 거버넌스로 업그레이드를 하는 시스템은

• 투표 조작
• 대출로 토큰을 잠깐 빌려 투표
• 제안 통과 후 즉시 악성 업그레이드

같은 공격을 고려해야 합니다.

---

 

4) 운영 설계의 핵심 도구 5개

4.1 멀티시그

단일 키를 피하고, 서명 임계치를 둡니다.

• m of n 서명
• 서명자 분산
• 키 교체 절차

4.2 타임락

업그레이드를 즉시 실행하지 않고 대기 시간을 둡니다.

• 커뮤니티와 모니터링이 사전에 감지할 시간을 준다
• 사고가 나면 취소하거나 대응할 여지를 만든다

4.3 역할 분리 RBAC

업그레이드, 파라미터 변경, 일시정지, 긴급출금 같은 권한을 분리합니다.

4.4 회로 차단기 pause

완벽한 해결책이 아니라 피해 확대를 줄이는 브레이크입니다.
pause 권한은 강력하므로 오남용 가능성도 함께 관리해야 합니다.

참고.
스마트컨트랙트의 pause는 목적은 circuit breaker와 비슷하지만, 보통 자동이 아니라 관리자 트랜잭션으로 켜고 끄는 긴급 정지 스위치에 더 가깝다.

4.5 모니터링과 알람

업그레이드 가능 컨트랙트는 모니터링 없이는 운영이 어렵습니다.

• implementation 슬롯 변화 감지
• 관리자 주소 변화 감지
• 중요한 파라미터 변경 이벤트 감지
• 이상 출금과 승인의 급변 감지

---

 

5) web2 비유: 운영 리스크는 배포 권한과 같다

web2에서 이런 상황을 떠올리면 됩니다.

• 프로덕션 배포 권한을 가진 계정이 탈취되면, 코드가 안전해도 끝이다
• DB 관리자 계정이 탈취되면, 애플리케이션 검증 로직은 무력해진다
• 변경관리 절차가 없으면, 실수로도 큰 사고가 난다

체인에서는 그 결과가 더 즉각적입니다.

• 잘못된 업그레이드는 되돌리기 어렵고
• 피해는 공개적으로 관측되며
• 공격자는 자동화로 초 단위로 움직입니다

---

 

6) 제품 의사결정 프레임: 업그레이드를 어디까지 허용할까

질문은 이겁니다.

• 편의성을 위해 신뢰를 얼마나 운영 주체로 옮길 것인가

대표 선택지

1) 업그레이드 불가

• 장점: 운영 리스크 최소화
• 단점: 버그 수정과 기능 개선이 어렵다

2) 제한적 업그레이드

• 장점: 치명적 버그 대응 가능
• 단점: 설계가 복잡해진다

3) 적극적 업그레이드

• 장점: 빠른 제품 반복
• 단점: 운영 절차가 보안의 대부분을 차지한다

---

 

7) 배포 전 체크리스트

1) proxy admin을 단일 EOA로 두지 않는다
2) upgrade 권한은 멀티시그로 둔다
3) 멀티시그 서명자는 조직과 디바이스를 분산한다
4) 타임락을 기본으로 고려한다
5) 타임락 취소 절차와 커뮤니케이션 채널을 준비한다
6) 역할을 분리한다 upgrade, pause, parameter, treasury
7) pause 권한의 범위를 정의한다 무엇을 멈추고 무엇을 남길지
8) 긴급 모드에서의 출금 정책을 문서화한다
9) 구현 컨트랙트 초기화 초기화자 재호출을 방지한다
10) 업그레이드 함수가 임의 구현으로 바뀌지 않게 검증한다
11) 스토리지 레이아웃 변경을 검토한다
12) proxy와 implementation 주소를 대시보드로 노출한다
13) 업그레이드 이벤트를 온체인 로그로 남긴다
14) 접근권한 변경도 이벤트로 남긴다
15) 배포 파이프라인에 리뷰와 승인을 강제한다
16) 감사 결과를 변경관리 문서로 연결한다
17) 장애 대응 런북을 만든다
18) 모의 사고 훈련을 한다 키 분실, 키 탈취, 악성 업그레이드

---

 

8) 운영 중 체크리스트

1) 관리자 주소 변화 알람을 운영 채널로 연결한다
2) implementation 변경 감지를 24시간 켠다
3) 주요 파라미터 변경 알람을 둔다
4) 대규모 allowance 급증과 drain 패턴을 탐지한다
5) pause 실행 후 사용자 커뮤니케이션 템플릿을 둔다
6) 업그레이드 전후로 리컨실을 한다 상태와 이벤트
7) RPC 장애에도 감지 시스템이 동작하도록 다중 제공자를 둔다
8) 서명자 교체 절차를 정기적으로 점검한다
9) 타임락 대기시간 변경은 별도 승인으로 제한한다
10) 권한을 최소화하는 방향으로 정기 감사한다
11) 신규 기능은 점진 배포한다 파라미터로 노출 제한
12) 서명기기와 시드 백업 정책을 준수한다
13) 파트너 컨트랙트 업그레이드도 의존성으로 추적한다
14) 사고 후 회고를 바탕으로 권한 구조를 재설계한다

---

 

결론

• 업그레이드 프록시는 기능이 아니라 신뢰 경계를 옮기는 설계다
• 권한 키는 가장 높은 가치의 공격 목표다
• 안전한 운영은 멀티시그 타임락 역할 분리 모니터링으로 만든다