a16z: Web3 프로젝트를 위한 스마트 계약 보안 가이드

출처: a16z

편집: Katie 구, 행성일보

보통 해커는 소프트웨어 개발 전체 프로세스 체인(설계에서 배포, 유지 관리까지)의 결함을 발견하고 이용하여 블록체인 프로젝트의 보안 장벽을 무너뜨립니다. 관련 경험을 미리 알 수 있다면, 보안 사고가 훨씬 줄어들 것이라고 믿습니다.

이 문서는 Web3 개발자와 보안 팀이 스마트 계약을 설계, 개발 및 유지 관리할 때 반드시 고려해야 할 보안 요소를 개요하며, 위협 모델링에서 비상 대응 준비까지의 전체 주기를 다룹니다.

안전한 소프트웨어를 개발하는 것은 다음 다섯 단계로 구성됩니다:

1. 설계: 개발자는 시스템에 필요한 기능과 작업을 설명하며, 중요한 기준 및 고정 속성을 포함합니다;

2. 개발: 개발자는 시스템 코드를 작성합니다;

3. 테스트 및 검토: 개발자는 모든 모듈을 테스트 환경에 모으고, 그들의 정확성, 규모 및 기타 요소를 평가합니다;

4. 배포: 개발자는 시스템을 생산에 투입합니다;

5. 유지 관리: 개발자는 시스템을 평가하고 수정하여 예상된 기능이 수행되도록 합니다.

아래 그림은 고려해야 할 보안 요소와 위의 단계들을 연결합니다.

소프트웨어 개발 생애 주기는 반드시 선형 경로를 따르지 않을 수 있습니다: 각 범주는 겹치거나 다른 단계로 확장될 수 있습니다. 각 버전마다 단계가 반복될 수 있습니다. 일부 보안 작업(예: 테스트 및 보안 검토)은 지속적으로 수행해야 할 수 있습니다.

위에서 설명한 소프트웨어 생애 주기 단계와 해당 보안 고려 사항은 스마트 계약의 보안을 촉진하는 기초를 제공합니다. 아래에서는 세 가지 질문을 바탕으로 더 자세히 연구합니다.

1. 설계 단계의 스마트 계약 보안 고려 사항 ------ 위협 모델링 및 보안 설계 고려

• 내용: 프로젝트 개발 생애 주기 초기에 시스템의 잠재적 위협을 명확히 식별하고 그 우선 순위를 정하는 것이 중요합니다. 스마트 계약 개발자는 개발 중 구현해야 할 모든 보안 통제를 식별하고, 테스트, 감사 및 모니터링 중 확인해야 할 위협을 정의해야 합니다. 모든 보안 가정, 공격자가 예상하는 복잡성 및 경제적 수단은 설계 단계에서 명확히 정의되고 설명되어야 합니다.

• 이유: 개발자에게 스마트 계약이나 프로토콜의 예상 용도에만 집중하는 것은 매우 매력적이지만, 이러한 단일 초점은 그들에게 "맹점"을 남길 수 있으며, 이는 공격자에게 이용당할 수 있습니다.

• 방법: 알려진 위협 모델링 관행을 따릅니다. 개발 팀에 내부 보안 전문가가 없다면, 설계 단계 초기에 보안 컨설턴트와 접촉해야 합니다. 시스템을 설계할 때 "공격자"의 마음가짐을 가지고, 개인, 기계 또는 서비스가 공격받을 수 있는 상황을 미리 가정해야 합니다.

2. 개발 단계의 보안 고려 사항 ------ 관리 고려 및 접근 제어

• 내용: 접근 제어를 구현하여 특권 계정 및 스마트 계약 호출이 관리 작업(예: 계약 업그레이드 및 특별 매개변수 설정)을 수행하는 특별 기능에 대한 능력을 제한합니다. "최소 권한 원칙"을 따릅니다 ------ 각 참여자는 필요한 최소한의 접근만을 가져야 합니다.

• 이유: 업그레이드 및 거버넌스 프로세스를 통해 프로토콜을 유지 관리함으로써, 개발자는 새로운 기능을 추가하고 보안 문제를 수정하며 변화하는 조건을 해결할 수 있습니다. 업그레이드 능력이 적절히 통제되지 않으면 심각한 보안 취약점이 될 수 있습니다.

• 방법: 커뮤니티의 변화를 투명하게 관리하기 위해 다중 서명 지갑 또는 DAO 계약을 설정합니다. 변경 사항은 철저한 검토 과정을 거쳐야 하며, 거버넌스 공격의 경우 그 정확성을 검증하고 롤백할 수 있도록 시간 잠금을 설정해야 합니다. 특권 키를 안전하게 저장하고 접근할 수 있도록 자가 보관 지갑 또는 안전한 보관 서비스에서 보장해야 합니다.

3. 재사용 가능한, 실전 테스트된 템플릿 및 통합 고려

• 내용: 가능한 한 기존의 스마트 계약 표준(예: OpenZeppelin 계약)을 활용하고, 기존 프로토콜과의 프로토콜 통합에 필요한 보안 가정을 평가합니다.

• 이유: 기존의 실전 검증된 커뮤니티 감사 표준 및 구현을 사용하는 것은 보안 위험을 줄이는 데 큰 도움이 됩니다. 프로토콜 통합의 위험을 평가하는 것은 외부 구성 요소(예: 오라클 조작)에 대한 공격을 방지하기 위한 보안 검사를 개발하는 데 도움이 됩니다.

• 방법: 보안 감사가 완료된 신뢰할 수 있는 계약 라이브러리 및 인터페이스를 도입합니다. Web3의 초점은 오픈 소스 사용, 재사용성 및 조합 가능성입니다. 코드베이스에서 계약 의존성과 그 버전을 기록하여 코드 점유를 최소화해야 합니다. 예를 들어, 모든 내용을 가져오는 대신 대형 프로젝트의 특정 하위 모듈을 가져옵니다. 위험 노출을 이해하고 공급망 공격을 모니터링합니다. 공식 인터페이스를 사용하여 외부 프로토콜을 호출하고 잠재적 통합 위험을 고려해야 합니다. 재사용된 계약의 업데이트 및 보안 공개를 모니터링합니다.

4. 테스트 및 검토 단계의 보안 고려 사항 ------ 테스트 및 문서 고려

• 내용: 명확하고 포괄적인 코드 문서를 작성하고, 빠르고 철저하며 실행하기 쉬운 테스트 스위트를 구축합니다. 허용되는 경우, 테스트 네트워크 또는 메인넷 시뮬레이션을 통해 테스트 환경을 구축하여 더 깊이 있는 실험을 진행합니다.

• 이유: 코드베이스의 예상 행동에 대한 가정을 작성하는 것은 위협 모델의 위험이 해결되도록 보장하고, 사용자와 외부 감사자가 개발 팀의 의도를 이해하는 데 도움이 됩니다. 코드에 대한 테스트 스위트를 만드는 것은 개발 가정을 입증(또는 반증)하는 데 도움이 되며, 위협 모델에 대한 더 깊은 사고를 장려합니다. 이 테스트 스위트는 극단적인 시장 시나리오에서 프로젝트 토큰 경제의 메커니즘 설계 테스트를 포함해야 하며, 단위 테스트 및 통합 테스트도 포함해야 합니다.

• 방법: Hardhat, Mythril, Slither, Truffle 등과 같은 알려진 테스트 프레임워크 및 보안 검사기를 구현하여 다양한 테스트 기술(예: 퍼징, 속성 검사, 심지어 공식 검증)을 제공합니다. NatSpec 주석을 사용하여 코드의 예상 부작용, 매개변수 및 반환 값을 지정하여 광범위하게 기록합니다. 문서 생성 도구 및 고급 설계 설명을 사용하여 실시간 문서를 생성합니다.

5. 내부 검토 및 보안 감사 고려

• 내용: 내부 및 외부 코드 검토를 통해 취약점을 발견하는 데 시간을 투자합니다.

• 이유: 기능 개발에서 보안 문제에 집중하는 것으로 전환하는 것은 개발자가 잠재적인 모호한 문제를 발견할 수 있는 시간을 제공합니다. 외부 감사는 이 점에서 특히 중요한 역할을 하며, 개발 팀이 갖추지 못한 외부 관점과 전문 지식을 제공합니다.

• 방법: 프로젝트 개발의 적절한 지점에서 특정 기능을 동결하여 내부 검토를 위한 시간을 확보한 후 외부 감사를 진행합니다. 이는 실제 배포 및 업그레이드 전에 수행되어야 합니다.

ConsenSys, Nassent, OpenZeppelin 및 Trail of Bits의 가이드를 참조하여 개발자에게 고려 사항 목록을 제공하고, 감사 준비가 된 사람들을 위한 시간 계획을 포함합니다. 배포 거래를 확인하여 감사된 코드 버전을 사용하고 적절한 매개변수를 갖추고 있는지 확인해야 합니다, 특히 소프트웨어를 업그레이드할 때.

6. 배포 및 유지 관리 단계의 보안 고려 사항 ------ 화이트 해커 커뮤니티 참여 유도

• 내용: 커뮤니티가 오픈 소스 코드베이스의 보안 개선에 참여하도록 장려하는 프로그램을 만듭니다. 한 가지 방법은 취약점 보상을 만드는 것입니다. 또 다른 방법은 커뮤니티가 프로토콜 모니터링 탐지 로봇을 개발하도록 장려하는 것입니다.

• 이유: 개발 팀은 광범위한 지식과 경험으로부터 이익을 얻을 수 있습니다(이는 오픈 소스가 암호화 분야에서 하는 역할이기도 합니다). 이러한 프로그램은 프로젝트에 대한 열정을 불러일으키는 데 도움이 되며, 본질적으로 커뮤니티와 화이트 해커를 전도자로 변모시킵니다. 해커에게 방어자가 될 수 있는 경로를 제공함으로써, 잠재적인 공격자를 보안 자산으로 전환하는 데 도움을 줄 수 있습니다.

• 방법: Code4rena, HackenProof, Immunefi 또는 Secureum과 같은 취약점 보상 플랫폼을 사용하여 숙련된 해커가 안전하게 취약점을 공개하도록 유도합니다.

주: 문서의 일부 저자는 Forta 회사에서 근무하고 있으며, 이 회사는 분산형으로 고품질 보안 모니터링 로봇을 생성하기 위한 토큰화된 인센티브 구조를 제공합니다. 개발 팀은 그들의 프로토콜 커뮤니티가 전통적인 방법과 Web3 원주율의 두 가지 방법을 활용하여 취약점 보상을 유도하고, 보안을 강화하여 참여자가 잠재적으로 이익을 얻도록 할 수 있습니다.

7. 실시간 모니터링 보안 고려 사항

• 내용: 스마트 계약 및 주요 운영 구성 요소(예: 오라클 및 크로스 체인 브리지)를 모니터링하는 시스템을 구현하고, 알려진 위협 모델에 따라 개발 팀과 커뮤니티에 의심스러운 활동을 보고합니다.

• 이유: 문제의 조기 탐지는 팀이 취약점에 신속하게 대응할 수 있게 하여, 잠재적으로 손실을 방지하거나 완화할 수 있습니다.

• 방법: 모니터링 플랫폼 또는 분산 노드에서 로봇을 실행하여 스마트 계약 이벤트를 실시간으로 모니터링합니다. 필요에 따라 개발 팀과 더 넓은 커뮤니티를 위해 데이터 대시보드 및 경고 알림을 삽입합니다.

8. 사고 및 비상 상황 대응 작업의 보안 고려 사항

• 내용: 어떤 보안 문제가 발생할 경우 즉시 대응할 수 있는 도구와 프로세스를 사용합니다.

• 이유: 최고의 배포 전 보장 조치가 있더라도, 스마트 계약 및 주요 구성 요소(예: 오라클 및 크로스 체인 브리지)에서 실시간 문제가 발생할 수 있습니다. 전담 인력, 명확한 프로세스 및 적절한 자동화 장비를 갖추어 사건을 신속하게 조사하고 가능한 한 빨리 해결할 수 있도록 합니다.

• 방법: 최악의 상황에 대비하여 사건이나 비상 상황에 대응하는 방법을 계획하고, 가능한 한 자동화된 대응 능력을 최대화합니다. 조사 및 대응 책임을 할당하고, 이들은 분산 보안 메일링 리스트, 코드 저장소의 지침 또는 스마트 계약 등록부를 통해 보안 문제에 대해 공개적으로 연락할 수 있습니다. 프로토콜의 위협 모델에 따라, 시나리오 연습 및 긴급 조치를 취하는 데 필요한 예상 대응 시간을 포함하는 일련의 프로세스를 개발하며, 긴급 사건 대응에 자동화를 통합하는 것을 고려할 수 있습니다.

보안 고려 사항은 성공적인 개발의 구성 요소여야 하며, 단순히 사후 고려 사항이나 보충이 아닙니다. 이 프레임워크는 Web3 프로토콜 및 애플리케이션을 구축하기 위한 빠른 가이드를 공유하여 전체 개발 과정에서 보안을 촉진하지만, 스마트 계약 보안을 전면적으로 논의할 수 있는 간단한 개요는 없습니다. 내부 보안 전문 지식이 부족한 팀은 자격을 갖춘 Web3 보안 전문가에게 연락하여 그들의 특정 상황에 적용할 수 있도록 안내하고 도움을 받을 수 있습니다.

보안을 간단한 문제로 생각하지 마십시오. 보안은 결코 끝나지 않는 지속적인 최선의 관행 세트입니다. 우리는 여전히 이러한 관행을 구축하는 초기 단계에 있으며, 이제 모든 개발자가 협력하여 이를 생성하고 공유할 때입니다.