인출 권한이 활성화된 API 키 강제 거부: 기술 심층 분석

대부분의 거래 플랫폼은 인출 권한이 활성화된 API 키를 수락합니다. 노란색 경고 배너를 표시하고, "동의합니다"를 입력하도록 요청한 후 키를 저장합니다. 우리는 그렇게 하지 않습니다. 키에 인출 권한이 있으면 온보딩 단계에서 거부하고 절대 저장하지 않습니다. 이 글은 그 이유, 방식, 그리고 대안이 실제로 무엇을 비용으로 드는지 설명합니다.

위협 모델을 한 문단으로

인출 권한이 활성화된 API 키를 보유하는 모든 시스템은 자격증명 유출 한 번으로 사용자 계정이 비워질 수 있습니다. 유출은 데이터베이스 침해일 필요가 없으며, 침해된 직원 노트북, 잘못 구성된 백업, 타사 의존성의 사이드채널, 또는 프로세스 메모리 덤프가 암호화되지 않은 로그에 저장될 수 있습니다. 이 모든 상황이 우리보다 큰 기업에서 발생했습니다. 유일한 지속적인 방어는 누군가의 자금에 대한 키를 처음부터 보유하지 않는 것입니다.

탐지 방식

사용자가 키를 붙여넣은 후 첫 번째 인증된 호출에서, 우리는 거래소별 권한 조회 호출을 수행합니다. 대부분의 주요 거래소는 다음 중 하나를 노출합니다.

• 권한 집합을 구조화된 필드로 반환하는 전용 "API 키 정보 조회" 엔드포인트, 또는
• 응답 페이로드의 일부로 키의 권한 범위가 포함된 계정 정보 엔드포인트.

우리는 인출, 내부 이체, 서브계정 이체 아웃, 또는 일반 이체 아웃을 부여하는 모든 플래그를 찾습니다. 거래소마다 같은 개념을 다르게 부릅니다. 이 중 하나라도 있으면, 우리는 메모리에서 비밀을 즉시 폐기하고, UI에 구조화된 오류를 반환하며, 키를 우리 데이터베이스에 절대 기록하지 않습니다.

경고 대신 강제 거부를 하는 이유

경고는 클릭되어 넘어갑니다. 우리는 수년간 여러 제품에서 이 데이터를 관찰했습니다. 위의 글을 한 단어도 읽지 않고 "동의합니다"를 입력하는 사용자의 기본율은 80% 이상입니다. 80%의 사용자가 무시하는 경고는 보안 제어가 아니라 책임 회피입니다.

강제 거부는 반대입니다. 마찰을 올바른 위치에 놓습니다. 사용자는 거래소로 돌아가 거래 권한만 있는 새로운 키를 만들고, 돌아와서 그것을 붙여넣습니다. 전체 과정은 사용자에게 약 2분이 소요됩니다. 최악의 시나리오인 자격증명 유출에서 공격자에게 드는 비용은 전체 계정입니다.

경고 후 저장 경로가 실제로 드는 비용

경고 후 저장 패턴은 최악의 경우가 무엇인지 물어볼 때까지 사용자 친화적으로 보입니다. 한 명의 적대적 직원, 하나의 공급망 침해, 전이적 의존성의 하나의 사이드채널, 하나의 범위 초과 로그가 있으면, 인출 권한이 활성화된 키는 정확히 그것을 건드린 가장 약한 사람과 가장 약한 코드만큼 안전합니다.

강제 거부는 이 계산을 뒤집습니다. 최악의 경우인 완전한 데이터베이스 침해에서도, 공격자는 읽기+거래 키로만 나갑니다. 거래 전용 키는 손상을 입힐 수 있습니다 — 포지션을 폭발시키고, 수수료를 변동시키고, 열린 포지션을 유동성이 낮은 쌍으로 덤프할 수 있습니다 — 하지만 인출할 수 없습니다. 자금은 거래소에 남아 있습니다. 이것이 위험 제로는 아니지만, 자동화된 거래 에이전트를 연결할 때 당신이 서명한 위험입니다.

우리가 여전히 방어할 수 없는 것

우리는 강제 거부가 완전한 보안 태세라고 가장하지 않습니다. 이것은 하나의 제어입니다. 전체 집합은 우리 보안 페이지에 문서화되어 있습니다: 사용자별 데이터 키를 사용한 KMS 봉투 암호화, API 호출 기간 동안에만 프로세스 메모리에 존재하는 복호화된 비밀, 추가 전용 해시 연쇄된 감사 로그, CI로 테스트된 교차 사용자 격리, 그리고 취약점 공개 프로그램. 강제 거부 인출 권한은 단지 그 스택의 가장 보이는 부분일 뿐입니다 — 그리고 확인하기 가장 쉬운 부분입니다. 온보딩 중에 실시간으로 우리가 인출 권한이 활성화된 키를 거부하는 것을 볼 수 있으니까요.