Bitcoin Core RPC credential을 가진 client는 지갑 자금 지출, private data 조회, node 설정과 파일 경로를 다루는 강한 권한을 얻을 수 있습니다. 공식 문서는 RPC가 encryption을 제공하지 않고 public Internet에 노출하도록 hardened되지 않았다고 경고합니다. 기본 loopback binding과 cookie authentication을 유지하고 remote access가 필요하면 VPN·SSH tunnel 같은 보호된 private 경로, OS user·container 격리, 최소 command whitelist를 겹쳐야 합니다.
RPC는 읽기 API 이상의 제어면입니다
JSON-RPC는 getblock 같은 조회뿐 아니라 wallet load, transaction creation·signing·broadcast와 node control method를 제공합니다. Valid credential이 있으면 bitcoind process가 접근 가능한 filesystem resource까지 영향을 줄 수 있습니다. 단순 dashboard용 read API로 가정하면 compromise 범위를 과소평가합니다.
Bitcoin Core 공식 문서는 RPC client가 funds, consensus verification view, private data에 영향을 줄 수 있다고 설명합니다. Shared VPS나 신뢰하지 않는 program이 같은 OS user·network에 있으면 local-only RPC여도 cookie file이나 port를 악용할 수 있습니다. Process 권한과 host 소유권이 첫 보안 경계입니다.
Bitcoin Core RPC 비밀번호는 조회용 API 키가 아니라, 노드와 지갑을 크게 제어할 수 있는 관리자 자격증명에 가깝습니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- RPC는 읽기 API 이상의 제어면입니다
JSON-RPC는 getblock 같은 조회뿐 아니라 wallet load, transaction creation·signing·broadcast와 node control method를 제공합니다.
- rpcbind와 rpcallowip는 서로 다른 역할입니다
rpcbind는 server가 어느 local interface에 listen할지 정하고 rpcallowip는 어떤 source address의 연결을 허용할지 정합니다.
- Cookie와 rpcauth의 용도를 구분합니다
기본 cookie auth는 node start마다 unique credential을 만들어 data directory 의 권한 제한 파일에 저장하며 같은 host의 client에 권장됩니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
rpcbind와 rpcallowip는 서로 다른 역할입니다
rpcbind는 server가 어느 local interface에 listen할지 정하고 rpcallowip는 어떤 source address의 연결을 허용할지 정합니다. rpcallowip만 추가했는데 외부 interface에 bind되지 않거나, 0.0.0.0 bind와 넓은 CIDR을 함께 써 공개되는 실수가 있습니다. 실제 socket listen address와 firewall rule을 확인합니다.
Docker의 단순 port publish는 host 모든 interfaces에 노출할 수 있습니다. 공식 문서는 예시로 127.0.0.1:8332:8332처럼 host loopback에 제한하라고 안내합니다. NAT·cloud security group·IPv6가 IPv4 firewall과 다른 경로를 만들 수 있어 외부 scanner와 local ss/netstat 증거를 함께 봅니다.
| 계층 | 권장 통제 | 실패 예 |
|---|---|---|
| Listen | loopback·private interface | 0.0.0.0 공개 |
| Network | firewall·VPN·SSH | 평문 public Internet |
| Authentication | cookie·rpcauth | 약한 고정 password |
| Authorization | 최소 RPC whitelist | 모든 method 허용 |
| Isolation | 전용 OS user·container | 공유 host credential 탈취 |
Cookie와 rpcauth의 용도를 구분합니다
기본 cookie auth는 node start마다 unique credential을 만들어 data directory의 권한 제한 파일에 저장하며 같은 host의 client에 권장됩니다. Static application user가 필요하면 share/rpcauth script로 salted HMAC credential 설정을 생성합니다. Raw password나 cookie를 source repository·chat·monitoring label에 넣지 않습니다.
rpcuser·rpcpassword 직접 설정은 마지막 fallback이며 강하고 고유한 secret과 안전한 transport가 필요합니다. RPC HTTP authentication은 traffic encryption이 아니므로 network path에서 credential과 요청이 노출될 수 있습니다. TLS termination을 임의 proxy로 붙이는 것보다 공식 경고대로 secure private tunnel과 endpoint 제한을 우선합니다.
- 현재 listen interfaces와 port owner를 확인합니다.
- rpcbind·rpcallowip·firewall 범위를 대조합니다.
- Cookie 또는 rpcauth secret 저장 권한을 점검합니다.
- Wallet별 endpoint와 method whitelist를 제한합니다.
- 외부에서 public exposure가 없는지 재검사합니다.
Wallet endpoint와 command 제한에도 경계가 있습니다
여러 wallets가 load됐으면 /wallet/<walletname>/ endpoint를 명시해야 wallet RPC 대상이 모호하지 않습니다. URL encoding과 wallet name validation을 구현하고 user input을 path처럼 그대로 결합하지 않습니다. Read-only service는 wallet이 없는 별도 node나 proxy facade로 필요한 method만 제공하는 구성이 더 명확할 수 있습니다.
-rpcwhitelist는 user별 method를 줄이지만 공식 문서는 이를 robust security boundary로만 의존하지 말라고 경고합니다. 일부 method 조합과 filesystem permission이 예상보다 넓은 효과를 낼 수 있습니다. System-level isolation, separate users와 funds 없는 node 분리를 적용합니다.
버전 변경과 로그 노출을 운영에 포함합니다
RPC interface는 Bitcoin Core major version에 따라 암묵적으로 versioned되고 deprecated RPC는 grace period 뒤 바뀔 수 있습니다. Client는 getnetworkinfo version을 기록하고 upgrade release notes와 schema tests를 거칩니다. HTTP 200만으로 JSON-RPC success를 판단하지 않고 version에 따른 result·error 형식을 parse합니다.
Request log에 passphrase, raw transaction metadata, wallet names와 addresses가 남을 수 있습니다. Authorization header와 body를 기본 redact하고 audit에는 caller identity, method, outcome만 최소 보존합니다. Incident 때 credential rotate, wallet unlock state, broadcast transactions와 filesystem access를 순서대로 조사합니다.
자주 묻는 질문
rpcallowip를 설정하면 Internet 공개도 안전한가요?
아닙니다. RPC는 encryption이 없고 public traffic에 hardened되지 않았으므로 VPN·SSH 등 보호된 private path가 필요합니다.
Cookie file은 비밀번호보다 약한가요?
같은 host client에는 공식 권장 방식이며 파일 권한과 OS user 격리가 중요합니다.
rpcwhitelist만 쓰면 tenant 격리가 되나요?
공식 문서는 robust security boundary로 의존하지 말고 system-level isolation을 사용하라고 권고합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
