presigned URL은 현재 로그인 상태를 계속 확인하는 세션이 아니라, 특정 요청 조건을 가진 bearer capability를 일정 시간 위임하는 방식으로 이해해야 합니다. 따라서 발급 시점의 앱 인가와 URL 사용 시점의 저장소 검사를 분리하고, 공개된 URL을 회수해야 하는 요구는 만료 시간만으로 해결된다고 가정하지 않습니다.
링크 보유자 권한과 발급 주체 인가의 구분
예를 들어 A가 발급한 다운로드 URL을 B에게 복사해도, 일반적인 presigned URL은 URL을 제시한 사람이 서명된 요청의 대상·메서드·만료 등 조건을 만족하는지 저장소가 확인하는 bearer 권한입니다. 저장소가 요청마다 앱 세션을 조회해 ‘지금도 A인가’를 판정하는 구조가 아니므로, URL을 가진 사람을 발급 사용자 A와 동일한 주체로 취급하지 않습니다.
따라서 요구가 “A가 잠시 다운로드할 수 있게 한다”인지 “A의 현재 세션으로만 읽게 하고 계정 정지 즉시 차단한다”인지 먼저 나눕니다. 두 번째 요구라면 앱 프록시에서 현재 인가를 검사하거나 더 강하게 주체에 결합된 전달 구조가 필요할 수 있습니다.
발급 시점의 대상·행동·기한 결정
| 제한 | 예 | 확인할 제품 계약 |
|---|---|---|
| 대상 | 특정 객체 키·버전 | 같은 키 덮어쓰기 시 내용 변화 |
| 행동 | GET 또는 제한된 업로드 | 서명된 메서드·헤더 조건 |
| 시간 | 짧은 만료 | 원본 자격 만료·회수의 영향 |
| 업로드 범위 | 크기·내용 형식 조건 | URL·정책 유형별 지원 차이 |
| 공개 | 앱 인가 뒤 발급 | CDN·캐시와 실제 제공 경로 |
객체 키를 사용자가 요청했다고 그대로 서명하지 않습니다. 현재 주체가 그 파일에 그 행동을 할 수 있는지 서버에서 확인하고 허용 대상을 내부 매핑으로 선택합니다. 여러 사용자의 업로드에 같은 키를 주면 덮어쓰기·검사 경쟁이 생기므로 서버 생성 ID·불변 버전을 사용합니다.
그림을 글로 읽기
- 앱의 현재 파일 인가
- 대상·행동·기한 서명
- URL을 보유한 주체
- 저장소의 서명·정책 검사
- 앱의 현재 파일 인가 → 대상·행동·기한 서명: 허용 범위 선택
- 대상·행동·기한 서명 → URL을 보유한 주체: 제한된 권한 전달
- URL을 보유한 주체 → 저장소의 서명·정책 검사: URL로 요청
만료와 이미 전달된 바이트의 회수 불가
만료 직전에 시작한 다운로드가 만료 시각에 즉시 끊기는지, 새 요청만 거절되는지는 제품 계약에 따릅니다. 짧은 만료는 새 요청의 창을 줄이지만 다운로드된 사본을 지우지 못합니다. 서명에 사용한 자격의 회수·객체 정책 변경이 기존 URL을 막는 방식도 제품별로 확인합니다. URL 하나만 개별적으로 즉시 취소할 수 있다고 가정하지 않습니다.
CDN이 앞에 있으면 URL의 query 서명을 캐시 키·원본 인증에 어떻게 사용하는지와 cache hit에서 인증을 계속 검사하는지가 중요합니다. 원본 URL 만료와 CDN 객체 TTL은 같은 값이 아닙니다. 제한 자료를 인증 없는 캐시 경로로 재공개하지 않도록 별도 캐시 권한을 검토합니다.
URL 비밀값 취급과 노출 경로
쿼리 문자열이 access log·분석·브라우저 기록·채팅·Referer에 남을 수 있습니다. 원문 URL을 진단 로그에 넣지 않고 객체 ID·발급 ID·만료·정책만 기록합니다. 필요한 referrer 정책과 외부 자산 제한을 적용하고, 발급 응답을 공유 캐시에 저장하지 않습니다.
업로드 URL은 파일 접수 권한이지 공개 승인 권한이 아닙니다. quarantine에 저장하고 실제 형식·자원 사용·내용을 검사한 뒤 검사한 객체 버전만 공개합니다. Content-Type을 서명했더라도 그 헤더가 파일의 실제 바이트가 안전하다는 증거는 아닙니다.
공유·재사용·만료별 동작 시험
테스트용 객체로 A가 받은 URL을 B 환경에서 사용했을 때 정책상 예상한 bearer 동작이 나오는지 확인합니다. 이 결과가 제품 요구와 맞지 않으면 URL 길이를 늘리는 대신 인증 구조를 바꿉니다. 메서드·키·버전 변경, 만료 뒤 새 요청, 진행 중 전송, 원본 자격 회수와 CDN cache hit를 각각 검사합니다.
특정 저장소의 크기 조건·회수·전송 중 만료 동작은 공식 문서와 실행 결과로 확인해야 합니다. 이 노트는 일반적인 위임 구조 설명이며 실제 객체 저장소에서 실행한 실험 보고서는 아닙니다.
실패 진단에서는 먼저 서명된 메서드·객체 키·버전·만료 시각이 요청과 일치하는지 확인하고, 그 다음 URL을 가진 다른 주체도 의도한 bearer 동작을 할 수 있는지 확인합니다. 업로드가 성공해도 quarantine 밖으로 공개되지 않아야 하며, CDN cache hit에서 원본의 현재 앱 인가가 다시 검사된다고 가정하지 않습니다. 즉시 회수가 필수라면 프록시 검사를 선택하거나 저장소 정책·키 폐기 계약을 별도로 검증해야 합니다.