프로덕션 모범 사례

Keychain은 서명 백엔드를 추상화하지만, 프로덕션 환경에서 서명자를 운영하는 것은 여전히 사용자의 책임입니다. 이러한 사례들은 모든 백엔드에 적용됩니다. 백엔드 선택에 대한 자세한 내용은 백엔드 선택하기를 참조하세요.

핫 서명자와 콜드 서명자 분리

소액 잔액의 운영용("핫") 서명자는 빈번한 자동화 트랜잭션에 사용하고, 별도의 고액("콜드") 서명자는 자금 이동에 사용하세요. 콜드 서명자는 MPC 수탁 또는 클라우드 HSM으로 지원하고, 서명 전에 승인 정책을 요구하도록 설정하세요. 인터페이스가 동일하기 때문에, 각 역할은 호출 지점을 변경하지 않고도 서로 다른 백엔드를 사용할 수 있습니다.

신중하게 키 교체하기

Solana에서는 서명 키가 곧 계정 주소이므로, 키를 교체하면 새로운 주소가 생성됩니다. 교체는 마이그레이션으로 계획하세요: 새 키를 프로비저닝하고, 관련 권한을 재할당하거나 새 주소로 자금을 이동한 후, 기존 키를 폐기하세요. 환경별로 별도의 키를 사용하여 devnet 키가 mainnet에서 재사용되지 않도록 하세요.

최소 권한 접근 부여

각 백엔드의 자격 증명을 서명에 필요한 최소 범위로 제한하세요. AWS KMS의 경우, 특정 키에 대한 kms:Signkms:DescribeKey 권한이 필요하며, 정적 자격 증명보다 IAM 역할을 사용하는 것이 좋습니다. 동일한 원칙을 Vault 정책 및 관리형 지갑 API 키에도 적용하세요.

가용성 계획 수립

원격 백엔드는 네트워크 서비스에 의존합니다. 서명자를 사용하기 전에 isAvailable()를 호출하고, 일시적 오류에 대해 백오프를 적용한 재시도를 수행하며, 장애 발생 시 대체 경로를 정의하세요. Keychain은 원격 백엔드에 HTTPS를 적용하고 기본 요청 타임아웃을 설정합니다.

시크릿 및 전송 보호

  • 모든 원격 백엔드는 HTTPS를 통해 통신하며, HTTPS가 아닌 엔드포인트는 거부됩니다.
  • API 키, 토큰, 자격 증명은 시크릿 매니저 또는 환경 변수를 통해 제공하세요 — 절대로 하드코딩하거나 소스 컨트롤에 커밋하지 마세요.
  • Keychain은 시크릿이 로그에 유출되지 않도록 오류 응답을 정제합니다. 자체 로깅에도 원시 자격 증명 및 키 자료가 포함되지 않도록 하세요.

서명 모니터링 및 감사

서명 성공률, 지연 시간, 실패 횟수를 추적하고 급증 시 알림을 설정하세요 — 프로덕션 준비에서 메트릭을 확인하세요. 공급자 측 감사 로그(KMS, Vault 또는 커스터디언)를 활성화하고, 애플리케이션이 제출하는 트랜잭션과 대조하여 검토하세요.

Is this page helpful?

목차

페이지 편집