키 및 토큰 회전
1) 회전이 필요한 이유
키 및 토큰은 필연적으로 "연령": 로그/백업, 내부자 위험, 라이브러리 취약점, 파트너의 누출. 회전은 "위험 수명" 을 줄이고 사고를 제어 할 수 있습니다. 목표는 다운 타임없이 예측 가능한 회전주기와 빠른 리콜 메커니즘을 구축하는 것입
2) 영역: 정확히 우리가 회전하는 것
서명/암호화 키: JWT (JWS/JWE), OAuth/OIDC, SAML, 웹 후크 (HMAC), 라이센스.
통합 비밀: API 키, 클라이언트 비밀, 기술 암호. 사용자.
TLS/mSL: 서버/클라이언트 인증서, 루트/중간 CA.
데이터 키: KMS/HSM의 KEK/CMK, DEK (엔벨로프 암호화).
계정: 액세스/새로 고침, 서비스 서비스 (mSL, HMAC), 수명이 짧은 세션.
3) 스토리지, 버전, 라벨
진실의 원천으로서의 KMS/HSM/Vault. 개인 키를 git/ENV/이미지 파일에 저장하는 것은 금지되어 있습니다.
버전: 'key _ id '/' 버전' + 레이블: 'forage = jwt-sign', 'env = prod', 'alg = ES256', 'proid _ at', 'rotates _ at'.
접근 정책: 필요한 최소 권리 원칙 (최소 권한), 의무 분리 (SoD).
감사: 누가/읽기/서명했는지; 불변의 통나무.
4) 기본 회전 패턴
4. 겹치는 창 1 개 (우아한 롤오버)
JWKS/인증서에 새 키 → 를 게시합니다.
중복 창: 오래된 키와 새로운 키로 검증, 서명-새 키로만 검증.
유예 기간이 만료되면 신뢰할 수있는 세트에서 이전 기간을 삭제하십시오.
4. 2 듀얼 런
인스턴스의 일부가 오래된 부분으로 표시되는 짧은 기간-새로운 (대형 함대).
엄격하게 동기화 된 JWKS와 'kid' 별 검증 비율을 모니터링해야합니다.
4. 3 회전 일정 vs 사용 중 회전
예약: N 일/주당 한 번 (서명 키, TLS).
사용시: 토큰 새로 고침-한 번씩 교환마다 새로운 릴리스 ("슬라이딩" 회전).
5) JWT/JWKS: 연습
5. 헤딩 및 식별자 1 개
JWS 헤더에서 'kid' 를 사용하여 확인 키를 선택하십시오.
최소 클림, 짧은 'exp', 정확한 'aud/iss/nbf'.
json
{ "alg": "ES256", "kid": "jwt-2025-10", "typ": "JWT" }5. 2 JWKS 간행물
JWKS에는 모든 활성 검증 키가 포함되어 있어야합니다 (이전 + 새 그레이스 윈도우).
클라이언트 JWKS 캐싱: 짧은 TTL (예: 5-15 분).
손상된 경우 캐시의 강제 장애인 JWKS (갑자기) 에서 손상된 키를 제거하십시오.
json
{
"keys": [
{ "kty":"EC","crv":"P-256","kid":"jwt-2025-10","use":"sig","alg":"ES256","x":"...","y":"..." },
{ "kty":"EC","crv":"P-256","kid":"jwt-2025-07","use":"sig","alg":"ES256","x":"...","y":"..." }
]
}5. 3 케이던스 및 타이밍
JWT 서명: 3-6 개월마다 (또는 고위험의 경우) 키 회전.
'exp' 액세스 토큰: 5-30 분; 새로 고침 - 7-30 일 ("사용 중 회전").
도난 위험을 줄이기 위해 PoP/DPoP와 "본딩" (§ 8 참조) 을 강제했습니다.
6) HMAC 회전 (웹 후크/서명)
활동적이고 카나리아적인 비밀을 유지하십시오. 둘 다의 서명을 수락합니다.
제목: 'X-Signature' + 'X-Timestamp'; 창 제한
발신자가 확인 된 후 이전 연결의 완전한 연결 해제.
파트너의 경우 스위치 날짜 및 종점 검사를 게시하십시오.
7) TLS/mTLS 및 트러스트 체인
공용 서버 인증서에 대한 ACME/자동 갱신 (암호화 또는 엔터프라이즈 CA).
mSL: 짧은 클라이언트 인증서 (7-30 일), 채널을 통한 자동 회전 (SPIFFE/SPIRE/mesh).
중급/루트 CA 회전 - 중복 트러스트 번들 앵커 및 긴 카나리아를 통해서만 가능합니다.
OCSP/CRL과 시계 왜곡을 주시하십시오. 로그에서-검증 실패의 이유.
8) PoP/DPoP 및 클라이언트 토큰 클라이언트 번들
DPoP (소유 증명 데모): 토큰은 클라이언트의 공개 키에 바인딩됩니다. 재생의 위험을 줄입니다.
클라이언트 키 회전 = 짧은 시간 동안 새로운 DPoP 키 토큰 릴리스.
서비스 간 서비스의 경우 mTLS가 선호됩니다 (장치/작업자는 HSM/TPM의 키를 "운반" 함).
9) 토큰 새로 고침: 사용 중 회전
일회성 새로 고침 토큰: 각 교환 → 새로운 새로 고침 + 액세스.
TTL = 수명 새로 고침 된 리콜 된 'jti '/' sid' 저장소 목록.
재사용 탐지 (재생): 즉시 세션/장치 리콜, 경고.
10) 리콜 및 블록 목록
내성이없는 JWT: 중요한 경우 (로컬/Redis, 해시 샤딩) 에 짧은 'exp' + '블랙리스트' 'jti' 를 사용하십시오.
OAuth 내성: 짧은 TTL로 중앙 집중식 상태 서버 캐시 "활성 = 거짓/진실".
API 키: 키 해시 (예: 비밀번호), 소유자/테넌트 레이블, 범위, 생성/마지막 액세스 날짜; 리콜-즉시.
11) 데이터 키: 엔벨로프 암호화
CMK/KEK (KMS/HSM) 는 DEK를 보호합니다. CMK 회전은 데이터 재공개없이 발생합니다. DEK 재 포장.
각 객체/테넌트/파티에 대한 DEK; 파생 키에 대한 KDF/HKDF.
암호화 정책: KEK = 손상되었을 때 읽을 수없는 데이터 삭제.
12) 사건 절차 (타협)
1. 동결: 손상된 키에서 토큰 발행을 비활성화하고 새 키로 발행을 전송하십시오.
2. 취소: JWKS에서 'kid' 를 제거하고 인증서 (OCSP/CRL) 를 취소하고 목록에서 API 키를 차단하십시오.
3. TTL 감소: 일시적으로 'exp' 토큰을 줄이고 PoP/DPoP 검사를 강화하십시오.
4. 강제 로그아웃: 비활성화 세션 ('sid '/' jti' 취소).
5. 법의학 및보고: 타임 라인, 적용 범위, 누가/무엇을 겪었는지; 플레이 북을 업데이트하십시오.
13) 파이프 라인 및 롤아웃
13. 1 세대 및 출판
HSM/KMS에서 키 생성; 민간 주요 수출-금지.
검증 및 테스트와 함께 JWKS/인증서의 자동 게시.
카나리아 릴리스: 클라이언트의 1-5% → 100%.
13. 2 건강 관리
메트릭: 'kid' 에 의한 검증 비율, 서명/인증서 오류, 클럭 드리프트.
경고: 서명으로 인한 401/403 스파이크, OCSP/CRL을 사용할 수 없음, 만료 인증서 (T-30/T-7/T-1).
14) 구성 및 예
14. 1 Vault/KMS 정책 예 (의사)
hcl path "transit/keys/jwt-prod" {
capabilities = ["read," "update," "list"] # signature/rotation
}
path "transit/keys/jwt-prod/rotate" {
capabilities = ["update"]
}14. 2 JWT 회전 계획 예
T0: create a new version of the key (kid = jwt-2025-10), add to JWKS
T0 + 15m: start signing with a new kid; validate with old and new
T0 + 7d: remove old kid from JWKS
T0 + 30d: delete old private key from KMS (schedule purge)14. 3 특사: 강제 JWKS 업데이트 (의사)
yaml jwt_authn:
providers:
oidc:
issuer: https://auth. example. com/
remote_jwks:
http_uri:
uri: https://auth. example. com/.well-known/jwks. json cluster: jwks_cluster timeout: 2s cache_duration: 300s # короткий TTL15) 관찰 및 감사
(PHP 3 = 3.0.6, PHP 4)
확인: 'kid', 'jti', 'sid', 'reason', 'client _ id', 'tenent', 'trace _ id' (차량 PII).
대시 보드: 'kid' 공유 카드, 만료 인증서, 리콜 빈도, 지역 별 유효하지 않은 서명.
16) 안티 패턴
리콜이없고 짧은 'exp' 가없는 수명이 긴 JWT.
검증 키의 '키드' 및 '수동' 선택 부재.
KMS가없고 etcd 수준에서 암호화없이 ENV/k8s-Secret에 비밀을 저장합니다.
비 회전 새로 고침 토큰; 탐지하지 않고 새로 고침을 재사용
"모두를위한" 단일 글로벌 API 키.
JWKS 게시 및 모니터링없이 새로운 키의 "조용한" 릴리스.
제로 겹치는 창 (즉석 교체) → 질량 401/403.
17) iGaming/Finance의 세부 사항
규제 기관 및 감사: 변경 불가능한 로테이션/리콜 로그; 시간과 배우의 확률.
파트너 PSP/KYC: 파트너/관할권 당 별도의 키; SLA/안전 위반에 대한 빠른 리콜.
다중 임대: 범위가있는 테넌트 당 API 키; 브랜드/지역 키 격리.
높은 위험: 중요한 운영을위한 PoP/DPoP, 내부 서비스 간의 짧은 'exp', mTLS.
백 오피스: SSO/OIDC, 짧은 세션, 하드웨어 토큰 (FIDO2), 유비쿼터스 회전 일정.
18) Prod 준비 점검표
- KMS/HSM/Vault의 모든 개인 키; 수출 금지.
- JWKS는 짧은 TTL로 게시 및 캐시됩니다. JWT 헤드 라인에는 '어린이' 가 있습니다.
- 겹치는 창과 자동 롤아웃이있는 회전 계획.
- 새로 고침 토큰은 일회용입니다. TTL의 취소 된 'jti' 목록.
- HMAC 비밀: 활성 + 카나리아; 둘 다에 의한 수신; T- 스위치 시간이 선언되었습니
- 리뉴얼, T-30/T-7/T-1 경고, CA 변경을위한 트러스트 번들.
- 봉투 암호화: KEK/CMK는 다운 타임없이 회전하고 객체/테넌트 당 DEK입니다.
- 서명 별 메트릭/경고, JWKS, 피드백; 대시 보드 '키드' 거래.
- 사건 플레이 북 (타협) 및 정기적 인 훈련.
- 새로운 키/CA를 사용한 카나리아 및 검증 복제본 테스트.
19) TL; DR
KMS/HSM에 키를 유지하고 'kid' 로 JWT에 서명하고 JWKS를 게시하십시오. 키와 인증서를 겹치게 회전하고 'kid' 로 유효성 검사 공유를 모니터링하십시오. 새로 고침-사용 중 회전 및 짧은 'exp'; 중요한 작업-PoP/DPoP 및 mTLS. 데이터의 경우 다운 타임없이 KEK 회전으로 엔벨로프 암호화를 사용하십시오. 구현 메트릭/알림, 사고 플레이 북 및 정기적 인 카나리아 회전.