Mythic 하드닝.

일주일 동안 우리는 Mythic 구축을 멈추고 대신 깨뜨리는 데 집중했다 —— 라이브 서버에 대한 블랙박스, 블랙박스로 부족한 곳은 화이트박스로. 12건의 발견이 나왔다. 전부 수정했고, 회귀 테스트로 고정했으며, 완료라고 부르기 전에 원본 재현으로 다시 검증했다. 이 글은 같은 패스에서 랜딩한 두 개의 M1 로드맵 항목 —— 키 로테이션과 Redis 스토어 —— 도 기록한다.

다운타임 없는 키 로테이션

이번 주까지 Mythic은 모든 결정 토큰을 단일 Ed25519 키로 서명했다; 로테이션은 재시작을 의미했고 살아있는 모든 토큰을 무효화했다. 서버는 이제 정확히 하나의 활성 서명자를 가진 키 링을 유지한다 (ADR-0006). 로테이션은 시간 기반이며 프로세스 내에서 동작한다 (MYTHIC_KEY_MAX_AGE, 기본 720h); 은퇴한 키는 MYTHIC_KEY_RETENTION(기본 24h) 동안 JWKS에 남는다 — 그 키가 서명한 토큰이 유효할 수 있는 시간보다 의도적으로 길어, 전송 중인 토큰이 로테이션 도중에 깨지지 않는다:

키스토어는 원자적으로 쓰이는 JSON 파일이다; 레거시 32바이트 시드 파일도 로드되며 첫 저장 시 마이그레이션된다. 오리진은 계속 로컬에서 토큰을 검증하고 kid 클레임으로 키를 선택한다 —— 조정 호출이 필요 없다.

단일 노드를 넘어 살아남는 스토어

인메모리 스토어는 mythicd를 단일 노드에 묶어두었다 (ADR-0009). MYTHIC_STORE=redis는 Redis 백엔드를 선택한다: 일회용 챌린지는 GETDEL(원자적 가져오기-삭제), 프레셔 카운터는 하나의 Lua 스크립트로 가지치기하는 sorted set. 두 백엔드 모두 슬라이딩 윈도우 카운터를 구현해 고정 윈도우의 경계 버스트를 막는다. Store 인터페이스는 이제 에러를 반환한다: 닿지 않는 Redis는 시작을 거부하고, 런타임 장애는 /v1에서 503 store_unavailable로 표출되는 동안 /healthz는 로드밸런서를 향해 열려 있다. 공유 컨트랙트 스위트가 두 백엔드(memory와 miniredis)에 대해 돌아서 시맨틱이 어긋날 수 없게 한다.

문서로 남길 caveat 하나: 공유되는 것은 스토어지 서명 키가 아니다. 노드 A의 토큰은 노드 B의 JWKS로 검증되지 않는다. 멀티노드 토큰 검증에는 공유 키스토어(KMS/HSM)가 필요하다 —— M5이며, 이번 변경으로 해결되지 않았다.

12건의 발견, 그룹별 정리

각 행: 공격이 보여준 것, 그리고 바뀐 것. 모든 수정에는 회귀 테스트가 있고, 모든 수정은 원본 재현으로 다시 검증했다.

점수 클램프 수정은 보여줄 가치가 있다. 신뢰 경계에 있기 때문이다 —— 토큰 안에 서명되어 들어가는 값:

// The score is a 0-100 contract (token claim `risk`,
          // dashboards, tuning docs). Hostile tuning must clamp
          // here, not leak 500 into tokens (red-team H3).
          if score > 100 {
              score = 100
          }
          if score < 0 {
              score = 0
          }

검증 —— 그리고 아직 열린 문제

모든 발견에는 재현이 있고, 모든 수정에는 회귀 테스트가 있다 (go test ./... -race, plus SDK 타입체크와 테스트). 그리고 모든 수정은 원본 재현으로 다시 검증했다. 아직 열린 것은 우리 머릿속이 아니라 위협 모델에 문서화되어 있다: 검증을 지연시키는 인내심 많은 솔버 (M2, 행동 신호), 새 신원을 쓰는 분산 공격 (이후 M1 네트워크 지문으로 부분 해결 —— 003 참조), 노드별 키스토어 (M5, 공유 KMS/HSM).

— XEY LABS