운영체제 CSPRNG를 읽지 못할 때 fallback으로 시간을 seed로 써도 되나요?

보안 자격 발급에는 시간을 seed로 쓰는 fallback을 두지 않겠습니다. 시각·PID·컨테이너 ID는 공격자가 추정하거나 관찰할 수 있는 제한된 입력이므로 CSPRNG의 예측 불가능성을 대체하지 못합니다. 난수원 초기화나 읽기가 실패하면 token endpoint와 새 session 발급을 명시적으로 실패시키고, 서비스 readiness를 낮추는 fail-closed 경로를 선택하겠습니다.

운영 장애가 곧 취약점이 되지 않게 재시도는 유한한 backoff로 제한합니다. 예를 들어 startup에서 OS API 오류가 나면 짧은 간격으로 몇 차례 다시 초기화하되, 계속 실패하면 프로세스를 ready로 표시하지 않고 알람을 보냅니다. 이미 실행 중인 요청도 CSPRNG 호출의 오류를 성공 응답으로 바꾸지 않습니다. “일단 예측 가능한 token을 만들고 나중에 바꾼다”는 방식은 사용자가 그 token을 이미 자격으로 사용했기 때문에 회수 전까지 공격 창을 남깁니다.

실패 응답은 내부 난수 장치나 재시도 횟수를 외부에 과도하게 노출하지 않고 추적 ID를 제공합니다. 대체 경로가 정말 필요한 비보안 기능이라면 시뮬레이션 PRNG를 별도 API와 별도 데이터로 제한해야 하며, session·password reset·CSRF 같은 값에는 연결하지 않습니다. 복구 뒤에는 정상 CSPRNG 출력, 장애 중 신규 발급 차단, 기존 토큰의 정상 검증 여부를 각각 시험하겠습니다.

장애 상태를 기존 자격과 신규 자격으로 나눕니다. startup에서 CSPRNG 초기화가 실패하면 readiness를 내리고 token endpoint를 열지 않으며, 유한한 backoff 뒤 계속 실패하면 프로세스를 교체하거나 알람을 냅니다. 이미 발급된 session의 서명 검증이나 reset token의 만료 검사는 난수 생성 없이 수행할 수 있으므로 신규 발급 차단과 기존 검증 중단을 동일시하지 않습니다. 요청 중 randomBytes가 오류를 반환하면 성공 응답을 만들지 말고 트랜잭션을 커밋하지 않습니다. 시간 1700000000과 PID 42를 seed로 쓰면 공격자가 배포 시각과 프로세스 정보를 좁혀 후보를 재현할 수 있어, 장애를 숨기는 대신 사용자가 재시도할 수 있는 일반 오류를 반환합니다. 복구 후에는 정상 발급, 원자적 소비, 장애 중 fallback 부재, 로그에 seed·원문이 없는지를 각각 확인해야 합니다. 실제 OS 장애를 이 환경에서 실행한 결과가 아니라 설계 상태 추적임을 구분합니다.