디파이 보안 가이드북: AI 시대에서 해커 공격을 효과적으로 방어하는 방법?

원문 제목: DeFi 해킹으로 돈을 잃지 않는 방법
원문 저자: sysls, openforage
원문 번역: AididiaoJP, Foresight News

서론

다수의 DeFi 프로토콜 해킹 사건을 이해한 후, 나는 "국가적 행위 주체"에 대해 두려움을 느꼈다. 그들은 기술적으로 뛰어나며 자원이 풍부하며, 극도로 장기적인 게임을 진행하고 있다. 이러한 슈퍼 악당들은 당신의 프로토콜과 인프라의 모든 측면을 살펴 취약점을 찾는 데 집중하며, 일반 프로토콜 팀의 주의는 여섯~일곱 가지 서로 다른 비즈니스 방향으로 흩어져 있다.

나는 자체를 보안 전문가라고 주장하지는 않지만, 나는 고위험 환경에서 팀을 이끄는 데 (군대 및 대규모 자금의 금융 분야를 포함한) 풍부한 경험을 가지고 있으며, 위기 대응 계획을 고려하고 계획하는 데 능숙하다.

나는 진심으로 믿습니다. 오직 편집증 있는 사람들만이 살아남을 수 있습니다. 어느 팀도 처음부터 "나는 보안에 대해 방심하고 엉성한 태도를 취하겠다"고 생각하지 않을 것입니다. 그러나 해킹은 여전히 발생합니다. 우리는 더 잘해야 합니다.

AI는 이번에 정말 다릅니다

(데이터 출처: https://defillama.com/hacks)

해킹은 드물지는 않지만, 빈도가 확연히 증가하고 있습니다. 2026년 1분기는 기록된 바에 따르면 DeFi 해킹 사건이 가장 많았던 분기이며, 2분기가 시작되었음에도 불구하고 이미 지난 분기 기록을 경신할 전망이 있습니다.

내 핵심 전제는 다음과 같습니다: AI는 취약점을 찾는 비용을 크게 낮추었으며, 공격 범위를 크게 확대시켰습니다. 인간은 100가지 프로토콜 구성을 실수 구성을 찾는 데 몇 주의 시간이 걸리지만, 최신 기본 모델은 몇 시간 만에 완료할 수 있습니다.

이것은 우리가 해킹에 대한 사고 방식과 대응을 완전히 변화시켜야 한다는 것을 의미합니다. AI가 강력해지기 전의 보안 조치에 익숙한 기존 프로토콜은 점점 "순식간에" 위험에 노출됩니다.

표면적 및 계층적 사고 활용

(데이터 출처: https://defillama.com/hacks)

해커 공격 표면적은 실제로 세 가지로 요약될 수 있습니다: 프로토콜 팀, 스마트 계약 및 인프라, 사용자 신뢰 경계 (DSN, 소셜 미디어 등).

이러한 표면이 확인되면 방어층을 쌓으십시오:

· 예방: 엄격하게 시행되면 악용 가능성을 최대한으로 낮출 수 있는 프로세스.

· 완화: 예방이 실패한 경우 피해 정도를 제한합니다.

· 중지: 아무도 거대한 압력 아래에서 최상의 결정을 내릴 수 없습니다. 공격이 확인되면 즉시 총 차단을 시작하십시오. 동결은 추가 손실을 막을 수 있으며 사고 후 생각할 시간을 확보합니다...

· 회수: 독성이나 침투된 구성 요소의 제어를 잃었을 경우 그것을 버리고 대체하십시오.

· 회복: 잃어버린 것을 되찾으십시오. 자금을 동결하고 거래를 취소하며 조사를 돕는 기관 파트너와의 협력을 계획해 두세요.

원칙

이러한 원칙은 각 방어층의 구체적인 조치를 지시합니다.

선도적 AI 대규모 활용

선도적 모델 AI 대규모 활용하여 코드베이스 및 구성을 스캔하고 취약점을 찾으며 광범위한 표면에서 레드팀 테스트를 수행하십시오: 전단에 취약점을 찾아 백엔드에 닿을 수 있는지 확인하십시오. 공격자들은 이를 시도할 것입니다. 방어적 스캔으로 발견할 수 있는 것은 그들의 공격적 스캔이 이미 발견했습니다.

pashov, nemesis 등의 기술 및 Cantina (Apex), Zellic (V12) 등의 AI 플랫폼을 사용하여 완전한 감사를 제출하기 전에 코드베이스를 신속하게 스캔하십시오.

시간과 마찰은 좋은 방어입니다

피해를 줄 수 있는 모든 조작에 여러 단계 프로세스 및 시간 잠금을 추가하십시오. 비정상을 발견할 때 개입하고 동결할 시간이 충분해야 합니다.

과거에는 시간 잠금 및 멀티 스텝 설정에 반대한 이유는 프로토콜 팀에 마찰을 일으킬 것이라는 것이었습니다. 이제는 이에 대해 너무 걱정할 필요가 없습니다: AI가 배경에서 이러한 마찰을 쉽게 처리할 수 있습니다.

불변성

스마트 계약은 방어적으로 구축하기 위해 변경할 수 없는 "사실"을 기록할 수 있습니다: 이러한 사실이 깨지면 전체 프로토콜 로직이 붕괴됩니다.

보통 불변성은 소수의 사실만 가지고 있습니다. 이를 코드 수준으로 조심스럽게 끌어올려야 합니다; 각 함수에서 다수의 불변을 강제 적용하면 관리가 어려워집니다.

권력 균형

많은 해킹 공격은 침투된 지갑에서 발생합니다. 이러한 구성이 필요합니다: 다중 서명이 침투당하더라도 신속하게 피해를 억제하고 프로토콜을 거버넌스 결정이 가능한 상태로 되돌릴 수 있어야 합니다.

이는 거버넌스(모든 것을 결정함)와 구제(거버넌스 안정성을 복구할 수 있지만 거버넌스를 대체하거나 전복할 수 없음) 사이에서 균형을 유지해야 합니다.

항상 문제가 발생합니다

처음부터 다음을 가정하세요: 얼마나 똑똑하더라도 해킹당할 것입니다. 당신의 스마트 계약이나 의존성 항목이 실패할 수 있습니다. 사회 공학 공격을 받을 수 있고, 새 업데이트가 예상치 못한 취약점을 도입할 수 있습니다.

한 번 이러한 점을 고려하면 피해 제한 속도 제한과 프로토콜 차단기는 여러분의 가장 좋은 친구가 될 것입니다. 피해를 5-10%로 제한한 다음 잠그고 대응 계획을 계획하세요. 아무도 총알이 비바람에서 최상의 결정을 내릴 수 없습니다.

최고의 계획 시간은 지금입니다

해킹당하기 전에 대응 계획을 고려하세요. 프로세스를 최대한 코딩하고 팀과 함께 연습하면 충격이 발생했을 때 혼란스럽지 않을 것입니다. AI 시대에서는 많은 정보를 가능한 빨리 제시할 수 있는 능력과 알고리즘, 요약 및 장문형식으로 핵심 그룹과 공유하는 기술을 가져야 합니다.

완벽할 필요는 없지만 살아남아야 합니다. 어떤 시스템도 첫 날부터 날이 선 절대적인 것은 아닙니다. 여러 차례의 반복을 통해 교훈을 얻고 취약하지 않게 변실합니다.

해킹된 증거가 없다고하여 해킹당하지 않을 것이라고는 할 수 없습니다. 최대 안락 지점이 자주 최대 위험 지점입니다.

예방 조치

스마트 계약 설계

변하지 않는 사항을 한 번 확인하고 실행중에 확인합시다. 강제로 적용할 가치 있는 사항이 무엇인지 신중히 고려하세요.

이것이 FREI-PI(기능 요구 사항, 효과, 상호 작용, 프로토콜 불변) 패턴입니다: 가치를 담당하는 각 함수의 끝에는 함수가 유지할 것으로 약속한 왕관 불변을 재검증합니다. 많은 CEI(Checks-Effects-Interactions)에 의한 합병 공격(플래시 대여 샌드위치, 오라클 보조 청산 grief, 교능 능력 자금 소진)이 함수 종료 시 불변검사에 포착될 수 있습니다.

좋은 테스트

상태 기반 퍼징(Stateful fuzzing)은 프로토콜의 완전한 공개 표면에 대해 무작위 호출 시퀀스를 생성하고 각 단계에서 불변성을 단언합니다. 대다수의 프로덕션 환경 취약점은 다중 트랜잭션에 해당하며, 상태 기반 퍼징은 이러한 경로를 공격자보다 먼저 발견하는 거의 유일한 신뢰할 수 있는 방법입니다.

불변성 테스트를 사용하여 속성이 퍼저가 생성할 수 있는 모든 호출 시퀀스에서 유지되는지 확인합니다. 형식 검증과 결합하여, 이는 모든 도달 가능한 상태에서 속성이 유지되는 것을 증명할 수 있습니다. 당신의 핵심 불변성은 꼭 이러한 처리를 받아야 합니다.

오라클과 의존성

복잡성은 안전의 적입니다. 각 외부 의존성은 공격 표면을 확장합니다. 원시를 설계 중이라면 신뢰와 신뢰할 대상의 선택을 사용자에게 맡기세요. 의존성을 제거할 수 없다면, 다양성을 촉진하여 어떤 단일 실패 지점도 귀하의 프로토콜을 붕괴시킬 수 없도록 합니다.

오라클 및 의존성이 실패할 수 있는 방식에 대한 감사 범위를 확장하고, 그러한 실패의 잠재적인 재앙적 영향에 대해 속도 제한을 부과하세요.

최근 KelpDAO 취약점은 그 예시 중 하나입니다: 그들은 LayerZero의 기본값인 requiredDVNCount=1 구성을 상속했는데, 이 구성은 그들의 감사 범위 밖에 있었습니다. 최종적으로 공격을 받은 것은 감사 범위를 벗어난 오프체인 인프라였습니다.

공격 표면

DeFi에서 대부분의 공격 표면은 이미 나열되어 있습니다. 각 범주를 확인하고 귀하의 프로토콜에 해당하는지, 그런 다음 해당 공격 벡터에 대한 통제를 구현합니다. 레드팀 역량을 강화하여 AI 에이전트가 귀하의 프로토콜에서 취약점을 진단하도록 수동 조치가 필요합니다. 현재 이것은 필수 요구사항입니다.

내재된 구조적 구원 능력

투표 기반 거버넌스에서 권한은 초기에 팀 멀티싸인에 집중되어 있으며, 시간이 걸려 확산됩니다. 심지어 토큰 배포가 넓게 이루어진 경우에도, 위임은 종종 소수의 지갑에 권한을 집중시킵니다 (때로는 n=1일 때도 있음). 이러한 지갑이 위험에 노출되면 게임이 종료됩니다.

'가디언 지갑'을 배포하고 엄격하고 제한적인 권한을 부여하세요: 이러한 지갑은 프로토콜을 일시 중지할 수 있으며, 극단적인 상황에서 손상된 위임을 사전 정의된 대체 지갑으로 전환할 수 있습니다. 가디언은 절대로 거버넌스 제안을 실행할 수 없습니다.

이렇게 하면 항상 가버넌스의 안전한 회복력을 가지게 되며, 가버넌스를 전복시키지 않고도 거버넌스를 가져올 수 있습니다. 가디언 중 4/7 이상을 잃는 최악의 시나리오 확률은 매우 낮으며(소유자 다양성을 고려할 때), 거버넌스가 성숙하고 분산되면 이 층을 점진적으로 폐기할 수 있습니다.

지갑 및 키 토폴로지

다중 서명 지갑은 기본 요구 사항이며, 최소한 4/7이어야 합니다. 7개 키 모두를 단일 인물이 통제해서는 안 됩니다. 서명자를 자주 교체하며, 교체는 조용히 이뤄져야 합니다.

키는 절대 일상적으로 사용하는 장치와 상호 작용해서는 안 됩니다. 서명 장치를 사용하여 인터넷을 둘러보거나 이메일을 주고받거나 Slack을 열면, 해당 서명자가 이미 침해당한 것으로 간주해야 합니다.

여러 다중 서명을 보유하되, 각각 다른 목적을 가져야 합니다. 적어도 하나의 완전한 다중 서명이 침해될 것으로 상정하고 거기서부터 계획을 세워야 합니다. 어떠한 단일 인물도 프로토콜을 침해할 수 있을 만큼의 통제력을 가져서는 안 되며, 극도의 상황에서도(납치, 고문 등) 마찬가지로 해당해야 합니다.

바운티 고려

리소스가 있을 경우, 프로토콜 TVL 대비 높은 금액의 버그 바운티를 설정하는 것은 매우 가치 있는 일입니다. 상대적으로 작은 프로토콜이라도, 버그 바운티는 가능한 한 관대히(예: 최소 7-8 자리 수) 설정해야 합니다.

국가 행위체의 공격을 당하고 있다면, 그들은 협상하지 않을 수 있지만 여전히 "화이트햇 보안 센터" 계획에 참여하여 화이트햇이 자금을 보호하기 위해 행동하고 일정 비율의 버그 금액을 수수료로 받을 수 있습니다(사실상 이것은 예금자가 지불하는 바운티입니다).

좋은 감사인을 찾아라

이전에 썼듯이 대규모 언어 모델이 똑똑해짐에 따라 감사인을 고용하는 이점은 줄어들게 될 것이라고 보여지지만, 내 의견이 변했습니다.

먼저, 좋은 감사인은 曲線(곡선) 앞에 있습니다. 새로운 것을 시도하고 있다면, 귀하의 코드와 해당 버그는 훈련 데이터에 없을 수 있으며, 단순히 토큰 수량을 늘리는 것은 새로운 버그를 효과적으로 발견하는 데 도움이 안 된 것으로 입증되지 않았습니다. 당신은 고유한 버그의 첫 샘플 지점이 되기를 원하지 않습니다.

둘째, 과소평가된 이점은 다음과 같습니다: 감사인을 고용하는 것은 그들의 명성을 담보로 하는 것입니다. 그들이 서명하고 승인하면서 당신이 공격을 받으면, 그들은 돕기 위해 강한 인센티브를 받을 것입니다. 보안 관련 직업을 가진 사람들과 관계를 형성하는 것은 거대한 이점입니다.

운영 보안 실행

운영 보안을 성공 지표로 삼으십시오. 피싱 시나리오를 연습하고, (신뢰할 수 있는) 레드팀을 고용하여 팀에 사회 공학 공격을 시도하도록 합니다. 필요할 때 전체 다중 서명을 대체할 수 있는 예비 하드웨어 지갑 및 장치를 준비하십시오. D-day 때 이러한 물건을 급하게 구매하는 것을 피하고 싶지 않을 것입니다.

대응 조치

귀하의 퇴출 경로는 손실 한도입니다

프로토콜에서 가치를 이탈하는 경로의 최대한도는 해당 경로가 취약점에 악용될 때의 최대 이론적 손실입니다. 간단히 말해, 블록 당 한도가 없는 코인 생성 함수는 어떤 무제한 코인 생성 취약점에 대해 공백 수표를 열어둔 것입니다. 주기간당 한도가 없는 인출 함수는 어떤 자산 잔액 손상에 대해 공백 수표를 열어둔 것입니다.

나의 이탈 경로의 명백한 값에 대해 신중하게 고민하세요. 이 숫자는 최대 피해 용인과 사용자의 가장 극단적인 UX 요구 사이의 균형을 찾아야 합니다. 문제가 발생했을 때, 여러분을 완전히 파괴로부터 보호해 줄 것입니다.

화이트리스트(및 블랙리스트)

대부분의 프로토콜은 호출, 거래 또는 수신할 수 있는 목록, 그리고 사용자가 절대 수행해서는 안 되는 목록을 갖고 있습니다. 명시화되지 않은 경우에도 이러한 것들은 신뢰 경계이며 공식화되어야 합니다.

이를 공식화하면 2단계 세터를 설정하여 의미 있는 마찰을 유발할 수 있습니다. 공격자는 먼저 화이트리스트에 추가해야 하며(/또는 블랙리스트에서 제거해야 함) 그런 후에야만 작업할 수 있습니다. 두 가지를 동시에 소유함으로써, 공격자는 새로운 벡터를 비밀리에 도입할 때 두 프로세스를 동시에 해킹해야 하므로, 시장이 허용되어야(통합/상장)하고 그 작업이 금지되어서는 안 됩니다(안전 검토).

징발

알고리즘 모니터링

모니터링이 없다면, 킬 스위치는 아무런 가치가 없습니다. 체인 외 감시자는 불변식을 계속 모니터링하고 문제가 발생할 때 알고리즘적으로 경보를 업그레이드해야 합니다. 최종 경로는 가디언 다중 서명한 인간의 손에 도달해야 하며, 그들에게 몇 분 내에 판단할 수 있는 충분한 맥락을 제공해야 합니다.

재조정을 위한 중지

만약 타격을 입었다면, 당신은 먼저 출혈을 멈추어야 하며, 카운트다운 상황에서 결정을 내리지 말아야 합니다. 프로토콜에게, 이것은 킬 스위치입니다(또한 UI에 표시되어야 합니다): 한 번의 거래로 모든 가치 이동 경로를 일시 중단할 수 있는 버튼입니다. "모든 것을 일시 중단"할 수 있는 보조 스크립트를 준비하여 모든 일시 중단 구성 요소를 열거하고 원자적으로 중단할 수 있어야 합니다.

일시 중단을 해제할 수 있는 것은 거버넌스뿐이므로, 킬 스위치는 거버넌스 계약 자체를 일시 중단할 수 없어야 합니다. 만약 가디언 계층이 거버넌스 계약을 일시 중단할 수 있다면, 해킹된 가디언 계층은 영원히 회복 프로세스를 막을 수 있습니다.

전쟁 방지실을 시작하세요

동결, 출혈 멈춤, 그런 다음 신뢰하는 모든 사람(소규모 그룹, 사전 협약)을 커뮤니케이션 채널로 끌어당기세요. 정보 유출을 방지하기 위해 가능한 한 작게 유지하고, 공격자, 공개 또는 악의적인 이익 추구자에게 정보가 누출되지 않도록 합니다.

팀에 필요한 역할에 대해 롤 플레이하십시오: 결정을 내리는 사람; 방어 스크립트를 능숙하게 실행하고 일시 중단 작업자; 취약점을 재구성하고 근본 원인을 찾는 사람; 주요 이해관계자와 소통하는 사람; 관찰, 이벤트 및 결정 타임라인을 기록하는 사람.

모든 사람이 자신의 역할을 알고 훈련을 받았을 때, 당신은 절차에 따라 대응할 수 있고 최악의 순간에 당황하지 않을 것입니다.

체인 리액션 고려

가능한 공격자가 상당히 숙련되어 있다고 가정해 봅시다. 첫 번째 취약점은 미끼일 수도 있고, 후속 공격을 위해 뿌린 씨앗일 수도 있습니다. 공격은 당신이 완전히 잘못된 일을 하도록 유도함으로써 실제 취약점을 트리거할 수도 있습니다.

일시 중단은 철저한 연구를 거치고 완전히 제어 가능하며 자체적으로 악용될 수 없어야 합니다. 일시 중단은 전체 프로토콜 동결이어야 합니다: 어떤 구성 요소의 중단을 유도당하면 안 되며, 그 대신 다른 중단을 여는 일이 없어야 합니다. 원인과 공격 벡터를 찾으면 주변 노출 면 및 체인 리액션을 탐색하고 한꺼번에 모두 수정해야 합니다.

미리 약속된 후임자 교체

후임자를 미리 알면 교체가 안전합니다. 저는 미리 약속된 후임자 레지스트리라는 아이디어를 좋아합니다: 이는 공격자가 건강한 수호자/거버넌스 지갑을 해킹된 것과 교체하기 어렵게 만듭니다. 이는 "화이트리스트/블랙리스트" 개념에서 비롯된 것입니다.

중요한 역할마다 후임자 주소를 등록하세요. 비상 계층이 실행할 수 있는 유일한 교체 원시는 "역할 X를 후임자로 교체"입니다. 이는 평화 시기에 후임자를 평가할 수 있게 하며, 천천히 조사하고 패치 요청자와 대면할 수 있게 합니다.

업그레이드 전 신중한 테스트

원인과 영향 범위를 확인하면 업그레이드를 배포해야 합니다. 이는 당신이 구현하려는 가장 위험한 코드일 수 있습니다: 압박 속에서 작성되었으며, 이미 충분히 이해되어 있는 프로토콜 및 취약점을 찾은 공격자를 대상으로 합니다.

충분한 테스트가 이루어지지 않은 상태에서 출시를 연기하세요. 감사할 시간이 없다면 화이트해커 관계에 의존하거나, 배포 전에 48시간 경쟁을 설정하여 신선한 적대적 검토를 받으세요.

회복

빠른 조치

도난당한 자금은 반감기가 있습니다; 취약점이 이용될 때 자금은 빠르게 세탁 파이프라인에 들어갈 것입니다. Chainalysis와 같은 온체인 분석 서비스 제공 업체를 실시간으로 준비하여 공격자의 주소 집단을 식별하고, 그들이 체인을 건너뛸 때 거래소에 통보하여 표시하고 추적하세요.

준비된 상태로 중앙 거래소의 준수 부서, 크로스체인 브릿지 관리자, 보호 소유자 관리자 및 특정 크로스체인 메시지 또는 입금을 동결할 수 있는 권한을 갖춘 기타 제3자 목록을 만들어 시간을 단축하세요.

협상

네, 이것은 아프겠지만 여전히 공격자와 대화를 시도해야 합니다. 생활에서 많은 일들은 협상을 통해 해결될 수 있습니다. 일정 기간 내에 고화질 버그 바운티를 제공하고, 마감일 이전에 자금 전액 환불 시 법적 조치를 취하지 않겠다는 것을 공개적으로 밝힙니다.

만약 국가 주체에 직면하고 있다면 운이 좋지 않을 수 있지만, 당신이 마주한 것이 비굴한 공격자일 수 있습니다. 그들은 단지 당신을 이용할 방법을 찾았을 뿐이며, 낮은 비용으로 벗어나려고 합니다.

이를 하기 전에 반드시 변호사를 참석시켜야 합니다.

결론

해커 공격은 멈추지 않을 것이며, AI가 더 똑똑해지면 공격 또한 더 많아질 것입니다. 방어측이 더 예리해지는 것만으로는 충분하지 않습니다. 우리는 공격자가 사용하는 동일한 도구를 사용해야 하며, 우리의 프로토콜에 대한 레드팀 테스트를 수행하고, 지속적으로 모니터링하며, 피해를 입히기 위한 강력한 제한을 설정해야 합니다. 그래야만 최악의 경우에도 생존할 수 있습니다.

원문 링크

BlockBeats 공식 커뮤니티에 참여하세요:

Telegram 구독 그룹：https://t.me/theblockbeats

Telegram 토론 그룹：https://t.me/BlockBeats_App

Twitter 공식 계정：https://twitter.com/BlockBeatsAsia