이 페이지에서는 서명을 사용하여 특정 Cloud Storage 리소스에 시간이 제한된 액세스를 제공하는 서명된 URL에 대한 개요를 제공합니다. 유효한 계정이 있는지 여부에 관계없이 서명된 URL을 가진 사람은 누구든지 활성 URL을 사용할 수 있습니다. 서명된 URL을 만드는 방법을 알아보려면 Cloud Storage 도구를 사용한 V4 서명 프로세스 및 자체 프로그램을 사용한 V4 서명 프로세스를 참조하세요. 버킷과 객체에 대한 액세스를 제어하는 다른 방법은 액세스 제어 개요를 참조하세요.
개요
서명된 URL은 요청을 수행하는 데 필요한 제한된 권한과 시간을 제공하는 URL입니다. 서명된 URL은 쿼리 문자열에 서명을 비롯한 인증 정보가 포함되어 있어 사용자 인증 정보가 없는 사용자도 리소스에 대한 특정 작업을 수행할 수 있습니다.
서명된 URL을 생성할 때는 서명된 URL이 요청을 수행할 수 있는 충분한 권한이 있는 계정을 지정해야 합니다.
서명된 URL을 생성하는 자체 프로그램을 만드는 경우 사용자 계정을 사용할 수 있습니다(연결된 HMAC 키가 있는 경우).
서명된 URL을 생성하면 서명된 URL을 소유한 모든 사람이 이를 사용하여 지정된 기간 내에 객체 읽기와 같은 지정된 작업을 수행할 수 있습니다.
서명된 URL을 사용해야 하는 경우
일부의 경우에는 사용자가 자신의 계정이 없어도 Cloud Storage에 액세스할 수 있도록 허용하지만 애플리케이션 특정 로직을 사용하여 액세스를 제어하길 원할 수 있습니다. 이 사용 사례를 처리하는 일반적인 방법은 서명된 URL을 사용자에게 제공하여 제한된 시간 동안 해당 리소스에 대한 읽기, 쓰기, 삭제 액세스 권한을 부여하는 것입니다. 서명된 URL을 만들 때 만료 시간을 지정합니다. URL을 아는 사람은 누구나 URL 만료 시간에 도달하거나 URL 서명에 사용된 키가 순환될 때까지 리소스에 액세스할 수 있습니다.
서명된 URL의 가장 일반적인 용도는 업로드 및 다운로드입니다. 이러한 요청에서는 객체 데이터가 요청자와 Cloud Storage 간에 이동하기 때문입니다. 객체 복사, 객체 작성, 객체 삭제, 메타데이터 수정과 같은 대부분의 다른 경우에는 서명된 URL을 만들어 다른 사람에게 사용하도록 지정하는 것이 불필요한 추가 단계입니다. 대신 서명된 URL 만들기를 담당하는 항목이 Cloud Storage에 원하는 요청을 직접 수행하는 설계를 고려해야 합니다.
서명된 URL의 예시
다음은 서비스 계정 인증을 사용한 V4 서명 프로세스에 따라 생성된 서명된 URL의 예시입니다.
이 서명된 URL은 example-bucket 버킷의 cat.jpeg 객체를 읽을 수 있는 액세스 권한을 부여합니다. 이를 서명된 URL로 만드는 쿼리 매개변수는 다음과 같습니다.
X-Goog-Algorithm: URL에 서명하는 데 사용되는 알고리즘입니다.
X-Goog-Credential: 서명된 URL을 만드는 데 사용되는 사용자 인증 정보에 대한 정보입니다.
X-Goog-Date: 서명된 URL이 사용 가능해지는 날짜 및 시간을 ISO 8601 기본 형식 YYYYMMDD'T'HHMMSS'Z'로 표현한 것입니다.
X-Goog-Expires: 서명된 URL의 유효 기간으로 X-Goog-Date 값을 초로 환산한 것입니다. 이 예시에서 서명된 URL은 15분 후에 만료됩니다. 가장 긴 만료 시간 값은 604,800초(7일)입니다.
X-Goog-SignedHeaders: 서명된 URL을 사용하는 모든 요청의 일부로 포함되어야 하는 헤더입니다.
X-Goog-Signature: 이 서명된 URL을 사용한 cat.jpeg 액세스 요청을 허용하는 인증 문자열입니다.
재개 가능한 업로드로 서명된 URL 사용
일반적으로 업로드 시작 요청 후 객체 데이터를 업로드하기 위한 후속 PUT 요청은 인증 토큰 역할을 하는 세션 URI를 사용하므로 재개 가능한 업로드를 위해 서명된 URL을 생성할 필요가 없습니다. 즉, PUT 요청은 서명된 URL을 사용하지 않습니다.
초기 POST 요청에 서명된 URL을 만들고 사용하여 업로드를 시작할 수 있지만, 대부분의 경우 서버에서 대신 재개 가능한 업로드를 시작할 수 있습니다. 그런 다음 서버는 세션 URI를 클라이언트에 전송하여 업로드를 수행합니다. 이렇게 하면 서버에서 서명된 URL을 생성해야 하는 복잡성과 클라이언트가 서명된 URL을 처리하고 재개 가능한 업로드를 시작해야 하는 복잡성을 해소할 수 있습니다.
서명된 URL과 마찬가지로 세션 URI는 이를 소유한 모든 사용자가 데이터를 업로드하는 데 사용할 수 있습니다. 세션 URI를 클라이언트에 전달 시 HTTPS를 통해 전송해야 합니다.
서명된 URL 고려 사항
서명된 URL을 사용할 때는 다음 사항에 유의하세요.
서명된 URL은 XML API 엔드포인트를 통해 Cloud Storage 리소스에 액세스할 때만 사용할 수 있습니다.
사용자 인증 정보를 지정할 때 이메일 주소를 사용하여 서비스 계정을 식별하는 것이 좋습니다. 하지만 서비스 계정 ID도 사용할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-26(UTC)"],[],[],null,["# Signed URLs\n\nThis page provides an overview of signed URLs, which use [signatures](/storage/docs/authentication/signatures) to give\ntime-limited access to a specific Cloud Storage resource. Anyone in\npossession of the signed URL can use it while it's active, regardless of whether\nthey have a valid account. To learn how to create a signed URL, see\n[V4 Signing Process with Cloud Storage Tools](/storage/docs/access-control/signing-urls-with-helpers) and\n[V4 Signing Process with Your Own Program](/storage/docs/access-control/signing-urls-manually). To learn about other ways of\ncontrolling access to buckets and objects, see [Overview of Access Control](/storage/docs/access-control).\n| **Important:** Signed URLs can only be used to access resources in Cloud Storage through [XML API endpoints](/storage/docs/request-endpoints).\n\nOverview\n--------\n\nA *signed URL* is a URL that provides limited permission and time to make a\nrequest. Signed URLs contain authentication information, including a\n[signature](/storage/docs/authentication/signatures), in their query string, which allows users without credentials\nto perform specific actions on a resource.\n\n- When you generate a signed URL, you must specify an account that has\n sufficient permission to make the request that the signed URL will make.\n\n - In most cases, the account is a [service account](/iam/docs/service-accounts).\n\n - In cases where you create your own program to generate signed URLs, it's\n possible to use a user account, if it has an associated [HMAC key](/storage/docs/authentication/hmackeys).\n\nAfter you generate a signed URL, anyone who possesses it can use the signed URL\nto perform specified actions, such as reading an object, within a specified\nperiod of time.\n\n### When should you use a signed URL?\n\nIn some scenarios, you might not want to require your users to have their own\naccount in order to access Cloud Storage, but you still want to control\naccess using your application-specific logic. The typical way to address this\nuse case is to provide a signed URL to a user, which gives the user read,\nwrite, or delete access to that resource for a limited time. You specify an\nexpiration time when you create the signed URL. Anyone who knows the URL can\naccess the resource until the expiration time for the URL is reached or the key\nused to sign the URL is rotated.\n\nThe most common uses for signed URLs are uploads and downloads, because in such\nrequests, object data moves between requesters and Cloud Storage. In\nmost other cases, such as copying objects, composing objects, deleting objects,\nor editing metadata, creating a signed URL and giving it to someone to use is an\nunnecessary extra step. Instead, you should consider a design in which the\nentity responsible for creating the signed URL directly makes the desired\nrequest to Cloud Storage.\n\n### Signed URL example\n\nThe following is an example of a signed URL that was created following the V4\nsigning process with service account authentication: \n\n```\nhttps://storage.googleapis.com/example-bucket/cat.jpeg?X-Goog-Algorithm=\nGOOG4-RSA-SHA256&X-Goog-Credential=example%40example-project.iam.gserviceaccount.com\n%2F20181026%2Fus-central1%2Fstorage%2Fgoog4_request&X-Goog-Date=20181026T18\n1309Z&X-Goog-Expires=900&X-Goog-SignedHeaders=host&X-Goog-Signature=247a2aa45f16\n9edf4d187d54e7cc46e4731b1e6273242c4f4c39a1d2507a0e58706e25e3a85a7dbb891d62afa849\n6def8e260c1db863d9ace85ff0a184b894b117fe46d1225c82f2aa19efd52cf21d3e2022b3b868dc\nc1aca2741951ed5bf3bb25a34f5e9316a2841e8ff4c530b22ceaa1c5ce09c7cbb5732631510c2058\n0e61723f5594de3aea497f195456a2ff2bdd0d13bad47289d8611b6f9cfeef0c46c91a455b94e90a\n66924f722292d21e24d31dcfb38ce0c0f353ffa5a9756fc2a9f2b40bc2113206a81e324fc4fd6823\na29163fa845c8ae7eca1fcf6e5bb48b3200983c56c5ca81fffb151cca7402beddfc4a76b13344703\n2ea7abedc098d2eb14a7\n```\n\nThis signed URL provided access to read the object `cat.jpeg` in the bucket\n`example-bucket`. The query parameters that make this a signed URL are:\n\n- `X-Goog-Algorithm`: The algorithm used to sign the URL.\n\n- `X-Goog-Credential`: Information about the credentials used to create the\n signed URL.\n\n- `X-Goog-Date`: The date and time the signed URL became usable, in the\n [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) basic format `YYYYMMDD'T'HHMMSS'Z'`.\n\n- `X-Goog-Expires`: The length of time the signed URL remained valid, measured\n in seconds from the value in `X-Goog-Date`. In this example the Signed URL\n expires in 15 minutes. The longest expiration value is 604800 seconds (7\n days).\n\n- `X-Goog-SignedHeaders`: Headers that had to be included as part of any request\n that used the signed URL.\n\n- `X-Goog-Signature`: The authentication string that allowed requests using\n this signed URL to access `cat.jpeg`.\n\nUsing signed URLs with resumable uploads\n----------------------------------------\n\nGenerally, creating signed URLs for [resumable uploads](/storage/docs/resumable-uploads) is unnecessary,\nbecause after the request to [initiate the upload](/storage/docs/performing-resumable-uploads#initiate-session), subsequent `PUT`\nrequests to upload the object data use a *session URI* , which acts as an\nauthentication token. This means that `PUT` requests don't use any signed URLs.\n\nWhile you can create and use a signed URL for the initial `POST` request to\ninitiate the upload, in most cases the server can initiate the resumable upload\ninstead. The server then sends the session URI to the client to perform the\nupload. This avoids the complexity of having the server create a signed URL, as\nwell as the complexity of having the client handle the signed URL and initiate\nthe resumable upload.\n\nLike signed URLs, a session URI can be used by anyone in possession of it to\nupload data. Be sure to transmit the session URI over HTTPS when giving it to\na client.\n| **Note:** You might want to use signed URLs with resumable uploads if your server and client are in geographically distant places, because resumable uploads are [pinned to the region of the initial request](/storage/docs/resumable-uploads#upload-performance). Using a signed URL for the initial `POST` request is one way to ensure the upload is initiated from the client's location.\n\nSigned URL considerations\n-------------------------\n\nWhen working with signed URLs, keep in mind the following:\n\n- Signed URLs can only be used to access Cloud Storage resources through\n [XML API endpoints](/storage/docs/request-endpoints).\n\n- When specifying credentials, it is recommended that you identify your service\n account by using its email address; however, use of the service account\n ID is also supported.\n\nCanonical requests\n------------------\n\nSigned URLs use [canonical requests](/storage/docs/authentication/canonical-requests) as part of the information encoded in\ntheir `X-Goog-Signature` query string parameter. When you\n[make a signed URL with Cloud Storage tools](/storage/docs/access-control/signing-urls-with-helpers), the required canonical\nrequest is created and incorporated automatically. However, when you\n[make a signed URL with your own program](/storage/docs/access-control/signing-urls-manually), you need to define the canonical\nrequest yourself and use it to [create a signature](/storage/docs/authentication/creating-signatures).\n\nCredential scope\n----------------\n\nThe [credential scope](/storage/docs/authentication/signatures#credential-scope) appears in both the string-to-sign and the\n`X-Goog-Credential` query string parameter.\n\nWhat's next\n-----------\n\n- [Create a signed URL with Cloud Storage tools](/storage/docs/access-control/signing-urls-with-helpers) such as client libraries or the Google Cloud CLI.\n- [Create a signed URL with your own program](/storage/docs/access-control/signing-urls-manually).\n- Learn more about [Canonical requests](/storage/docs/authentication/canonical-requests).\n- Learn more about [Signatures](/storage/docs/authentication/signatures)."]]
