가상자산 보안은 거래소 계정, 이메일, MFA, 통신사 번호, 지갑 시드, 토큰 승인을 연결해 관리하는 일이다. 복구 수단을 한 휴대폰에 몰지 않고 수탁·비수탁·DeFi별 통제권에 맞춰 방어와 사고 대응을 나눠야 한다.
계정·이메일·지갑을 한 연결망으로 본다
가상자산 보안은 강한 비밀번호 하나가 아니라 계정 MFA, 이메일·통신사, 시드·기기, 출금 주소, 토큰 승인과 복구 절차를 계층별로 점검하는 운영 습관이다
가상자산 보안은 거래소 비밀번호만의 문제가 아니다. 이메일, MFA 기기, 통신사 번호, 지갑 시드, 출금 주소록, 토큰 승인이 서로 연결된다. 공격자는 가장 약한 복구 경로를 통해 강한 비밀번호를 우회할 수 있다.
강한 비밀번호 하나보다 서로 독립된 인증·복구·서명 계층이 단일 실패점을 줄인다.
JOBCOIN 해설
수탁 계정과 비수탁 지갑의 방어 계층
수탁 계정은 비밀번호 재사용 방지, 피싱 저항 MFA, 출금 화이트리스트와 로그인 알림이 핵심이다. 비수탁 지갑은 시드의 오프라인 백업, 서명 기기, 승인 범위와 공식 도메인 확인이 중요하다. 이메일이 탈취되면 거래소 복구도 우회될 수 있어 계정 연결망을 함께 보호한다.
수탁 계정은 고유 비밀번호, 피싱 방지 MFA, 출금 주소 허용 목록과 로그인 알림이 핵심이다. 비수탁 지갑은 시드 오프라인 보관, 거래 내용 확인, 기기 무결성이 핵심이다. 두 구조를 쓰면 두 방어를 모두 운영해야 한다.
수탁·비수탁·디파이 권한 비교
수탁에서는 사업자가 키와 출금을 통제하고 사용자는 계정 인증을 지킨다. 비수탁에서는 사용자가 키와 복구를 맡는다. DeFi에서는 여기에 계약 승인과 프런트엔드 검증이 더해진다. 같은 체크리스트를 그대로 복사할 수 없다.
| 구분 | 작동 방식 | 확인 포인트 |
|---|---|---|
| 수탁 계정 | 로그인·복구·출금 정책 보호 | 피싱 저항 MFA·이메일·화이트리스트 |
| 비수탁 지갑 | 키·시드·서명 권한 보호 | 오프라인 백업·기기 화면 확인 |
| 디파이 권한 | 계약별 토큰 사용 권한 관리 | spender·한도·revoke·도메인 |
휴대폰 한 대에 복구 수단이 몰린 경우
휴대폰 분실 시 거래소 로그인, 인증앱, 이메일, SIM 재발급이 한 기기에 몰려 있으면 두 번째 요소가 실질적으로 분리되지 않는다. 하드웨어 지갑이 있어도 시드 사진을 클라우드에 올렸다면 콜드 보관의 이점이 크게 줄어든다.
한 휴대폰에 이메일, SMS, 인증 앱, 거래소 앱, 시드 사진이 모두 있으면 분실 한 번이 여러 방어층을 동시에 무너뜨린다. 복구 코드와 주요 승인 수단을 별도 매체와 장소로 나누고 잠금 화면 알림도 최소화한다.
SMS와 클라우드 백업의 단일 실패점
SMS 2단계 인증은 아무것도 없는 것보다 낫지만 SIM 탈취와 피싱에 취약하다. 백업 코드를 같은 메일함에 저장하거나 시드와 기기 PIN을 함께 보관하면 단일 사고가 모든 복구 수단을 노출한다. 보안 점검 중 시드를 웹사이트에 입력하면 안 된다.
SMS는 SIM 탈취와 번호 재발급 위험이 있고, 클라우드 사진·메모의 시드 백업은 계정 탈취 때 노출될 수 있다. 가능한 계정은 하드웨어 보안키나 피싱 방지 인증을 쓰고 시드는 온라인 동기화에서 제외한다.
보안 설정을 점검하는 순서
먼저 이메일과 거래소의 활성 세션·복구 수단을 확인하고 MFA를 갱신한다. 다음으로 출금 주소록과 API 키, 지갑 승인 목록, 브라우저 확장을 점검한다. 마지막으로 복구 절차를 자산 없는 환경에서 시험하고 기록 날짜를 남긴다.
- 계정마다 고유 비밀번호와 피싱 저항 MFA를 설정한다
- 이메일·통신사 계정의 복구 수단도 점검한다
- 시드·백업코드·하드웨어 기기를 분리 보관한다
- 출금 주소·토큰 승인·활성 세션을 정기 검토한다
- 사고 시 동결·revoke·자산 격리·신고 순서를 문서화한다
사고 대응과 2차 복구 사기 차단
완벽한 보안은 없으며 위협 모델에 맞춰 비용과 복잡성을 조절한다. 큰 금액과 일상 사용을 분리하고, 새 절차는 소액·빈 지갑으로 시험한다. 사고 후 '복구 전문가'가 선입금이나 시드를 요구하면 2차 사기일 가능성이 크다. 온체인 전송은 되돌리기 어려우므로 예방과 증거 보존이 중요하다.
사고가 의심되면 정상 기기에서 세션을 종료하고 사업자 출금 잠금을 요청하며 TXID와 시간을 보존한다. 검색 결과의 복구 업체나 개인 메시지는 시드·선입금을 요구할 수 있다. 공식 지원 채널을 직접 찾아 2차 사기를 차단한다.
API 키를 쓰는 경우 읽기·거래·출금 권한을 분리하고 필요 없는 출금 권한은 끈다. IP 허용 목록과 만료를 설정해도 키가 소스코드·클라우드 로그에 남지 않았는지 확인한다. 사용하지 않는 키는 비활성화하고 최근 호출 기록을 계정 로그인 기록과 함께 검토한다.
사고 대응 계획에는 순서가 필요하다. 이메일이 탈취됐다면 거래소 비밀번호만 바꾸기 전에 이메일 세션과 복구 주소를 되찾고, 시드가 노출됐다면 승인 취소보다 안전한 새 키로의 이동을 우선 검토한다. 증거를 보존하면서도 공개 커뮤니티에 주소·개인정보를 과도하게 올리지 않는다.
자주 묻는 질문
SMS 인증만으로 충분한가요?
더 강한 보안키나 패스키 등 피싱 저항 방식이 가능하면 우선한다.
시드 사진을 암호화해 클라우드에 두면 되나요?
온라인 계정·기기·암호 노출이 겹칠 수 있어 오프라인 분리 백업을 우선 검토한다.
해킹당하면 고객센터가 코인을 돌려주나요?
수탁 계정은 조사·동결 가능성이 있지만 보장되지 않고, 비수탁 온체인 전송은 되돌리기 매우 어렵다.
