Signed URL 만료 계산기
유효기간·시계 오차를 고려한 signed URL 만료 시각을 계산합니다.
CloudFront, S3, Cloudflare 같은 CDN과 오브젝트 스토리지는 임시 접근을 위해 만료 시각이 포함된 signed URL(서명 URL) 또는 presigned URL을 발급합니다. 이 계산기는 시작 시각과 유효기간을 입력하면 정확한 만료 시각을 UTC ISO 8601, 로컬 시각, Unix epoch(초)로 한 번에 환산해 보여줍니다.
서버와 클라이언트의 시계가 어긋나면 아직 유효해야 할 URL이 만료로 거부되거나 반대로 너무 오래 살아 있을 수 있습니다. 그래서 시계 오차(clock skew) 허용값을 함께 입력하면 “실질적으로 안전하게 보장되는 만료 시각”까지 계산해 줍니다. 모든 계산은 브라우저 안에서만 이뤄지며 어떤 값도 외부로 전송되지 않습니다.
signed URL 만료는 어떻게 계산되나
만료 시각은 단순합니다. 만료 = 시작 시각 + 유효기간. 대부분의 서명 방식은 만료를 절대 시각(Unix epoch 초)으로 URL에 박아 넣습니다. 예를 들어 CloudFront는 정책 문서의 DateLessThan 값, S3 presigned URL은 발급 시각 기준 X-Amz-Expires(초)로 만료를 표현합니다.
- 시작 시각: 보통 URL을 서명하는 “지금”. 미래 시각으로 미리 발급할 수도 있습니다.
- 유효기간: 초·분·시·일 단위로 입력. S3 presigned URL은 최대 7일(604800초)로 제한됩니다.
- 만료 시각: 이후로는 게이트웨이가
403으로 거부합니다.
시계 오차(clock skew)를 반드시 고려하라
서명을 검증하는 쪽과 URL을 만든 쪽의 시계가 완벽히 같을 수는 없습니다. 검증 서버 시계가 조금 빠르면, 발급한 입장에서는 아직 유효해도 검증 측에서는 이미 만료로 보일 수 있습니다. 그래서 “실질 만료”는 다음과 같이 보수적으로 봐야 합니다.
- 실질 만료 = 만료 − 시계오차 허용값. 이 시각 전에 요청이 도착하도록 설계하세요.
- NTP로 시간을 동기화해도 수 초의 드리프트는 흔합니다. 1~5초 정도의 여유를 두는 것이 안전합니다.
- 반대로 시작 시각을 미래로 잡는 서명(NotBefore)이라면, 검증 측 시계가 느릴 때 “아직 시작 안 됨”으로 거부될 수 있으니 같은 논리로 여유를 둡니다.
운영 팁
- 만료는 가능한 짧게. 유출돼도 위험 창이 작아집니다.
- 긴 다운로드/업로드는 전체 전송 시간보다 유효기간이 충분히 길어야 합니다(연결 시작 시점에 만료가 검증되는지, 전송 중에도 검증되는지는 서비스마다 다름).
- 로그·DB에는 항상 UTC epoch로 저장하고, 사람에게 보여줄 때만 로컬 시각으로 변환하세요. 저장된 epoch 값을 사람이 읽기 좋은 시각으로 바꿀 때는 로그 타임스탬프 변환기가 편리합니다.
CDN 캐시의 신선도(TTL)와 백그라운드 갱신 정책까지 함께 설계하려면 stale-while-revalidate 설계기를 참고하세요.