티스토리 뷰

카테고리 없음

S3 사전 서명 URL의 만료 시간을 파일 전달 업무에 맞추는 기준

생각방 2026. 11. 4. 22:50

목차


    거래처에 S3 다운로드 링크를 보냈는데 다음 날 열리지 않는다면, 유효기간을 짧게 잡았다고만 보기는 어렵습니다. 링크에 넣은 시간보다 서명에 사용한 임시 자격 증명이 먼저 만료됐을 수도 있습니다. 반대로 문의를 줄이려고 기간을 늘리면 링크가 재전달되어 사용될 수 있는 시간도 길어집니다.

    사전 서명 url의 사용시간 제한

    설정한 유효기간과 실제 사용 가능 시간

    S3 사전 서명 URL은 특정 객체를 내려받을 권한을 일정 시간 제공하는 주소입니다. 수신자가 AWS 계정을 따로 보유할 필요는 없지만, 주소를 가진 다른 사람도 같은 조건에서 사용할 수 있습니다. 한 번 내려받았다고 자동 소멸하는 일회용 링크도 아닙니다. 공유 방식을 정할 때 이 성격부터 확인해야 합니다.

    일반적인 S3 객체 공유에서 콘솔은 최대 12시간, CLI·SDK의 SigV4 방식은 최대 7일까지 설정할 수 있습니다. 다만 임시 자격 증명으로 서명했다면 그 자격 증명의 만료가 먼저 적용됩니다. 버킷 정책 등에서 접근을 거부하는 조건도 따로 확인해야 합니다. 자세한 조건은 AWS 만료 안내에 정리되어 있습니다.

    가령 24시간 링크를 만들었어도 서명에 사용한 역할 자격 증명의 남은 수명이 2시간이라면 다음 날 사용을 기대할 수 없습니다. 이는 동작을 설명하기 위한 가정입니다. 재발급할 때는 기간 숫자뿐 아니라 발급 주체와 자격 증명의 남은 수명을 함께 봐야 합니다.

    요약: 설정 시간, 자격 증명 만료, 접근 정책을 함께 확인해야 실제 사용 가능 시간을 판단할 수 있습니다.

    새로운 접근권한 부여와 시간이 지남에 따른 접근권한 소멸

    수신자가 파일을 확인하는 시점에서 출발

    제 판단으로는 모든 전달 업무에 같은 시간을 넣는 방식보다, 수신자가 언제 열어야 하는지를 먼저 정하는 편이 낫습니다. 즉시 내려받는 화면과 다음 근무일에 확인하는 메일은 조건이 다릅니다. 다음 표는 AWS의 권장값이 아니라 업무 기준을 정하기 위한 예시입니다.

    전달 상황 기간을 정할 기준 함께 정할 절차
    로그인 화면에서 즉시 다운로드 클릭 후 시작할 짧은 여유와 재시도 시간 권한 확인 후 필요할 때 새 링크 발급
    거래처에 업무 자료 메일 발송 수신자의 근무시간과 실제 확인 예정 시각 만료 시 연락할 담당자와 재확인 방식
    민감 자료를 정해진 시각에 전달 합의한 수령 시간대에 맞춘 짧은 유효기간 수신자 확인과 재전달 제한 안내

    민감도가 높고 재전달 통제가 중요한 자료라면 기간을 늘리는 것만으로 해결하려 하지 말고, 수신자 인증을 거쳐 발급하는 경로를 우선 검토합니다.

    요약: 수신 시점과 재발급 가능성을 묶어 정하면 불필요하게 긴 유효기간을 줄일 수 있습니다.

    발급 시점과 재발급 경로를 함께 설계

    메일을 보내기 오래전에 링크를 만들면 대기 시간까지 유효기간을 소모합니다. 가정 사례로 금요일 저녁에 발급한 자료를 월요일 오전에 확인한다면, 링크 숫자만 조절하기보다 전달 방식을 다시 정할 여지가 있습니다. 본인 확인이 가능한 업무 화면에서 다운로드를 누를 때 새 URL을 발급하도록 구성하면 이 간격을 줄일 수 있습니다.

    명령으로 발급한다면 아래 예시는 1시간을 요청합니다. 버킷·객체 경로는 설명용이며, 실제 발급에는 해당 객체의 다운로드 권한이 있는 자격 증명이 필요합니다. --expires-in의 단위가 초라는 점은 CLI 공식 문서에서 확인할 수 있습니다.

    aws s3 presign s3://example-delivery-bucket/reports/sample.pdf --expires-in 3600 --region ap-northeast-2

    버킷 정책의 s3:signatureAge로 서명 나이를 제한하는 경우에는 URL에 지정한 시간과 정책의 제한이 다를 수 있습니다. 이 조건의 값은 밀리초 단위입니다. 버킷 전체에 짧은 값을 적용하기 전에는 다른 사용 경로도 시험해야 합니다. AWS는 서비스 영향 안내에서 과도하게 짧은 제한이 일부 작업을 방해할 수 있다고 설명합니다.

    운영 기록에는 대상 객체, 발급 시각, 요청 유효기간, 전달 대상, 재발급 사유를 남기는 방식을 검토할 수 있습니다. 접근 권한을 담은 전체 URL을 티켓이나 공용 로그에 그대로 복사하는 것은 피해야 합니다. 수신 안내에는 만료 시각의 시간대와 재발급 연락 경로를 함께 적는 편이 명확합니다.

    요약: 기간을 늘리기 전에 발급 시점과 만료 후 다시 받는 절차부터 점검합니다.

    새로 부여된 접근권한 및 기존 부여 권한의 사본

    자주 묻는 질문

    만료 시각이 지나면 진행 중인 다운로드도 끊기나요?

    S3는 HTTP 요청 시점에 만료 여부를 확인합니다. 만료 전에 시작한 다운로드는 계속될 수 있지만, 연결이 끊어진 뒤 만료 후 다시 요청하면 실패할 수 있습니다. 대용량 파일은 전송 시간과 재시도 여유를 구분해서 판단해야 합니다.

    새 링크를 발급하면 이전 링크도 바로 무효가 되나요?

    새 URL을 생성하는 행위만으로 이전 URL이 취소되지는 않습니다. 이전 링크의 만료와 자격 증명·접근 정책 조건을 별도로 확인해야 합니다. 긴급 차단을 위해 공용 역할이나 버킷 정책을 바꾸면 다른 업무도 영향을 받을 수 있어 적용 범위를 먼저 살펴야 합니다.

    링크가 만료되면 상대방이 받은 파일도 회수되나요?

    이미 내려받은 로컬 복사본은 링크 만료로 삭제되지 않습니다. 다운로드 가능 기간과 수신 후 파일 보유기간은 따로 관리해야 합니다. 파일 회수까지 필요한 업무라면 사전 서명 URL의 기간 설정만으로 요구를 충족한다고 판단해서는 안 됩니다.

    결론

    S3 사전 서명 URL의 만료 시간은 최대한 길게 설정할 값이 아니라 파일을 받을 업무 시간대에 맞출 값입니다. 먼저 수신자의 확인 시점을 정하고, 발급 자격 증명의 수명과 정책 제한을 대조한 뒤, 만료 후 재발급 절차를 연결하십시오. 다음 발급부터는 링크가 언제 끊기는지와 누가 다시 발급하는지를 함께 안내하는 것이 실질적인 출발점입니다.

    참고자료