Bitcoin Core RPC 자격증명(credential)을 쥔 클라이언트는 지갑 자금을 쓰고, 민감한 데이터를 조회하고, 노드 설정과 파일 경로까지 다루는 강한 권한을 얻을 수 있습니다. 공식 문서는 RPC가 암호화를 제공하지 않고 공개 인터넷에 노출되도록 단단히 만들어지지 않았다고 경고합니다. 기본값인 루프백 바인딩과 쿠키 인증을 그대로 두고, 원격 접속이 꼭 필요하면 VPN·SSH 터널 같은 보호된 사설 경로, OS 사용자·컨테이너 격리, 최소한의 명령 허용 목록을 겹겹이 둬야 합니다.
RPC는 조회용 API가 아니라 제어판입니다
JSON-RPC는 getblock 같은 조회만 하지 않습니다. 지갑 불러오기, 거래 생성·서명·전파, 노드 제어 메서드까지 제공합니다. 유효한 자격증명이 있으면 bitcoind 프로세스가 닿는 파일 시스템 자원에도 영향을 줄 수 있습니다. 대시보드용 조회 API쯤으로 여기면 침해 범위를 과소평가하게 됩니다.
Bitcoin Core 공식 문서는 RPC 클라이언트가 자금, 합의 검증 결과, 민감한 데이터에 영향을 줄 수 있다고 설명합니다. 공유 VPS이거나 믿을 수 없는 프로그램이 같은 OS 사용자·네트워크에 있다면, 로컬 전용 RPC라도 쿠키 파일이나 포트를 악용당할 수 있습니다. 프로세스 권한과 호스트 소유권이 첫 번째 보안 경계입니다.
Bitcoin Core RPC 비밀번호는 조회용 API 키가 아니라, 노드와 지갑을 크게 제어할 수 있는 관리자 자격증명에 가깝습니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- RPC는 조회용 API가 아니라 제어판입니다
JSON-RPC는 getblock 같은 조회만 하지 않습니다.
- rpcbind와 rpcallowip는 하는 일이 다릅니다
rpcbind는 서버가 어느 로컬 인터페이스에서 연결을 기다릴지 정하고, rpcallowip는 어떤 출발지 주소의 연결을 받을지 정합니다.
- 쿠키와 rpcauth는 쓰임새가 다릅니다
기본 쿠키 인증은 노드를 켤 때마다 고유한 자격증명을 만들어 데이터 디렉터리 안 권한이 제한된 파일에 저장합니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
rpcbind와 rpcallowip는 하는 일이 다릅니다
rpcbind는 서버가 어느 로컬 인터페이스에서 연결을 기다릴지 정하고, rpcallowip는 어떤 출발지 주소의 연결을 받을지 정합니다. rpcallowip만 추가했는데 외부 인터페이스에는 바인딩되지 않거나, 반대로 0.0.0.0 바인딩과 넓은 CIDR을 함께 써서 통째로 공개되는 실수가 생깁니다. 실제 소켓이 듣고 있는 주소와 방화벽 규칙을 확인합니다.
Docker에서 포트를 그냥 게시하면 호스트의 모든 인터페이스에 노출될 수 있습니다. 공식 문서는 127.0.0.1:8332:8332처럼 호스트 루프백으로 묶으라고 예를 들어 안내합니다. NAT, 클라우드 보안 그룹, IPv6가 IPv4 방화벽과 다른 길을 만들 수 있으니 외부 스캐너 결과와 로컬 ss/netstat 결과를 함께 봅니다.
| 계층 | 권장 통제 | 실패 예 |
|---|---|---|
| 연결 대기 | 루프백·사설 인터페이스 | 0.0.0.0 공개 |
| 네트워크 | 방화벽·VPN·SSH | 평문으로 공개 인터넷 노출 |
| 인증 | 쿠키·rpcauth | 약한 고정 비밀번호 |
| 권한 | 최소 RPC 허용 목록 | 모든 메서드 허용 |
| 격리 | 전용 OS 사용자·컨테이너 | 공유 호스트에서 자격증명 탈취 |
쿠키와 rpcauth는 쓰임새가 다릅니다
기본 쿠키 인증은 노드를 켤 때마다 고유한 자격증명을 만들어 데이터 디렉터리 안 권한이 제한된 파일에 저장합니다. 같은 호스트의 클라이언트라면 이 방식이 권장됩니다. 고정된 애플리케이션 사용자가 필요하면 share/rpcauth 스크립트로 솔트를 넣은 HMAC 자격증명 설정을 만듭니다. 원래 비밀번호나 쿠키를 소스 저장소, 채팅, 모니터링 라벨에 넣지 않습니다.
rpcuser·rpcpassword를 직접 설정하는 것은 마지막 대안이며, 강하고 고유한 비밀값과 안전한 전송 경로가 함께 있어야 합니다. RPC의 HTTP 인증은 통신을 암호화하지 않으므로 네트워크 경로에서 자격증명과 요청이 드러날 수 있습니다. 아무 프록시에나 TLS 종단을 붙이기보다, 공식 경고대로 안전한 사설 터널과 접속 지점 제한을 먼저 챙깁니다.
- 지금 연결을 기다리는 인터페이스와 포트 주인을 확인합니다.
- rpcbind·rpcallowip·방화벽 범위를 맞춰 봅니다.
- 쿠키나 rpcauth 비밀값이 저장된 파일 권한을 점검합니다.
- 지갑별 접속 경로와 메서드 허용 목록을 좁힙니다.
- 외부에서 공개 노출이 없는지 다시 검사합니다.
지갑 경로와 명령 제한에도 한계가 있습니다
여러 지갑을 불러왔다면 /wallet/<walletname>/ 경로를 명시해야 어느 지갑에 대한 RPC인지 모호해지지 않습니다. URL 인코딩과 지갑 이름 검증을 구현하고, 사용자 입력을 경로처럼 그대로 이어 붙이지 않습니다. 조회 전용 서비스라면 지갑이 없는 별도 노드나, 필요한 메서드만 내놓는 프록시를 앞에 두는 구성이 더 명확할 수 있습니다.
-rpcwhitelist는 사용자별로 쓸 수 있는 메서드를 줄여 줍니다. 하지만 공식 문서는 이것을 튼튼한 보안 경계로만 믿지 말라고 경고합니다. 일부 메서드 조합과 파일 시스템 권한이 예상보다 넓은 효과를 낼 수 있기 때문입니다. 시스템 수준 격리, 사용자 분리, 자금이 없는 노드 분리를 함께 적용합니다.
버전 변경과 로그 노출도 운영 항목에 넣습니다
RPC 인터페이스는 Bitcoin Core 메이저 버전에 따라 사실상 버전이 나뉘고, 폐기 예정 RPC는 유예 기간이 지나면 바뀔 수 있습니다. 클라이언트는 getnetworkinfo의 버전을 기록하고, 업그레이드 때 릴리스 노트와 응답 형식 테스트를 거칩니다. HTTP 200만 보고 JSON-RPC 성공으로 판단하지 말고, 버전에 맞는 결과·오류 형식을 파싱합니다.
요청 로그에는 지갑 암호, 원시 거래 정보, 지갑 이름과 주소가 남을 수 있습니다. 인증 헤더와 본문은 기본적으로 가리고, 감사 기록에는 호출자, 메서드, 결과만 최소한으로 남깁니다. 사고가 나면 자격증명 교체, 지갑 잠금 해제 상태, 전파된 거래, 파일 시스템 접근을 차례로 조사합니다.
자주 묻는 질문
rpcallowip를 설정하면 인터넷에 공개해도 안전한가요?
아닙니다. RPC는 암호화가 없고 공개 트래픽을 견디도록 만들어지지 않았으므로 VPN·SSH 같은 보호된 사설 경로가 필요합니다.
쿠키 파일은 비밀번호보다 약한가요?
같은 호스트의 클라이언트라면 공식 권장 방식입니다. 파일 권한과 OS 사용자 격리가 중요합니다.
rpcwhitelist만 쓰면 사용자끼리 격리되나요?
공식 문서는 이를 튼튼한 보안 경계로 믿지 말고 시스템 수준 격리를 쓰라고 권고합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
