Keychain은 서명 백엔드를 추상화하지만, 프로덕션 환경에서 서명자를 운영하는 것은 여전히 사용자의 책임입니다. 이 모범 사례는 모든 백엔드에 적용됩니다. 백엔드 선택에 대해서는 백엔드 선택하기를 참조하세요.
핫 서명자와 콜드 서명자 분리
잔액이 낮은 운영용("핫") 서명자는 빈번한 자동화 트랜잭션에 사용하고, 별도의 고가치("콜드") 서명자는 자산 이동에 사용하세요. 콜드 서명자는 MPC 커스터디 또는 클라우드 HSM으로 뒷받침하고, 서명 전에 승인 정책을 요구하도록 설정하세요. 인터페이스가 동일하기 때문에 각 역할은 호출 지점을 변경하지 않고도 서로 다른 백엔드를 사용할 수 있습니다.
계획적인 키 순환
Solana에서 서명 키는 곧 계정 주소이므로, 키를 순환하면 새로운 주소가 생성됩니다. 순환은 마이그레이션으로 계획하세요: 새 키를 프로비저닝하고, 관련 권한을 재할당하거나 자금을 새 주소로 이전한 후 기존 키를 폐기하세요. 환경별로 구별된 키를 사용하여 devnet 키가 mainnet에서 재사용되지 않도록 하세요.
최소 권한 접근 부여
각 백엔드의 자격 증명은 서명에 필요한 최소한의 범위로 제한하세요. AWS KMS의 경우
특정 키에 대한 kms:Sign 및 kms:DescribeKey 권한만 부여하며, 정적 자격 증명보다
IAM 역할을 사용하는 것을 권장합니다. 동일한 원칙을 Vault 정책 및 관리형
지갑 API 키에도 적용하세요.
가용성 계획
원격 백엔드는 네트워크 서비스에 의존합니다. 서명자를 사용하기 전에 isAvailable()을
호출하고, 일시적인 오류에는 백오프 재시도를 적용하며, 장애 시 대체 경로를 정의하세요.
Keychain은 원격 백엔드에 HTTPS를 강제 적용하고 기본 요청 타임아웃을 적용합니다.
시크릿 및 전송 보호
- 모든 원격 백엔드는 HTTPS를 통해 통신하며, HTTPS가 아닌 엔드포인트는 거부됩니다.
- API 키, 토큰, 자격 증명은 시크릿 매니저 또는 환경 변수를 통해 제공하세요. 하드코딩하거나 소스 컨트롤에 커밋해서는 안 됩니다.
- Keychain은 오류 응답을 정제하여 시크릿이 로그에 노출되는 것을 방지합니다. 자체 로깅에서도 원시 자격 증명과 키 자료가 포함되지 않도록 하세요.
서명 모니터링 및 감사
서명 성공률, 지연 시간, 실패 횟수를 추적하고 급격한 변화 시 알림을 설정하세요 — 프로덕션 준비 상태의 메트릭을 참조하세요. 공급자 측 감사 로그(KMS, Vault 또는 커스터디언)를 활성화하고, 애플리케이션이 제출하는 트랜잭션과 대조하여 검증하세요.
Is this page helpful?