서명된 URL과 토큰 인증: CDN 콘텐츠 무단 접근 막기

서명된 URL은 무엇을 막나요?

서명된 URL은 만료 시각과 서명을 주소에 붙여, 링크가 유출돼도 시간이 지나면 접근을 막는 방식입니다. CDN에 올린 파일은 대개 https://cdn.example.com/video.mp4 같은 주소로 제공되죠. 문제는 이 주소가 조건 없이 열려 있는 영구 링크라는 점입니다. 한 번 노출되면 누구나, 언제까지나 내려받을 수 있고, 다른 사이트가 내 대역폭으로 콘텐츠를 가져다 쓰는 핫링크도 막기 어렵습니다.

서명된 URL은 이 주소에 두 가지를 더합니다. 하나는 만료 시각, 다른 하나는 그 주소가 정당하게 발급됐음을 증명하는 서명이에요. 만료가 지나거나 서명이 맞지 않으면 엣지가 파일을 내주지 않습니다. 링크가 새더라도 그 값은 정해진 시간 동안만, 정해진 자원에만 유효하니 피해 범위가 크게 좁아지죠

서명은 어떻게 만들어지나요?

서버가 경로와 만료 시각을 비밀 키로 해시해 서명을 만들고, 엣지가 같은 계산으로 검증합니다. 이때 쓰는 방식이 보통 HMAC이에요. 발급 서버가 보호할 자원의 경로, 만료 시각, 필요하면 허용 IP 같은 값을 모아, 자신과 엣지만 아는 비밀 키로 해시를 계산하죠. 그 결과가 서명이고, URL 뒤에 쿼리 파라미터로 붙습니다.

요청이 들어오면 엣지가 같은 값과 같은 키로 서명을 다시 계산해 비교합니다. 주소를 한 글자라도 손대면 서명이 어긋나 거부되고, 만료 시각이 지났으면 역시 거부돼요. 여기서 핵심은 비밀 키가 클라이언트에 절대 노출되지 않고 서버와 엣지 사이에만 존재한다는 점입니다. 서명과 검증의 원리가 더 궁금하다면 웹훅 서명 검증 글에서 HMAC을 다룬 대목이 도움이 됩니다.

토큰은 어디에 담아 전달하나요?

쿼리스트링, 쿠키, 헤더 세 방식이 있고, 콘텐츠 유형과 클라이언트 환경에 따라 고릅니다. 서명(토큰)을 어디에 실어 보내는지도 설계 포인트인데, 각각 장단이 뚜렷하죠.

정리하면 직접 링크에는 쿼리스트링, 스트리밍에는 쿠키, API에는 헤더가 무난한 출발점입니다. 특히 수백 개의 조각을 잇따라 받는 HLS 같은 스트리밍에서 조각마다 서명을 붙이는 대신 쿠키 하나로 처리하면 훨씬 깔끔해요.

실무에서 무엇을 정해야 하나요?

실무에서는 만료 시간, 키 로테이션, 검증 위치, 제한 범위 네 가지를 서비스 특성에 맞게 정합니다. 하나씩 보죠. 첫째, 만료 시간이에요. 다운로드 링크는 짧게, 스트리밍 세션은 시청 길이에 맞춰 잡습니다. 짧을수록 유출 시 위험은 줄지만 재발급 부담이 늘어나니 서비스 성격으로 저울질하죠. 둘째, 키 로테이션입니다. 비밀 키는 주기적으로 바꾸되, 이전 키도 잠시 함께 인정해 발급 중이던 링크가 끊기지 않게 합니다. 키 관리 자체가 사고로 이어지지 않게 하는 방법은 시크릿 관리 글에서 짚었습니다.

셋째, 검증 위치입니다. 서명 검증을 엣지에서 처리하면 오리진까지 요청이 가지 않아 부하와 지연이 줄어요. 넷째, 제한 범위죠. 서명에 허용 IP나 경로를 함께 묶으면 링크가 새도 다른 환경에서는 쓰기 어렵습니다. 참고로 예전부터 쓰던 Referer 기반 핫링크 차단은 헤더를 위조하면 뚫리므로, 확실한 보호가 필요하면 서명된 URL이 정공법입니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)