使用「Bucket IP 篩選」，根據要求的來源 IP 位址限制 Bucket 的存取權。儲存空間 IP 篩選功能可防止未經授權的網路存取儲存空間及其資料，進一步提升安全性。
您可以設定允許的 IP 位址範圍清單，包括公開 IP 位址、公開 IP 位址範圍，以及虛擬私有雲中的 IP 位址。系統會封鎖來自不在清單中的 IP 位址的所有要求。
因此只有獲得授權的使用者才能存取值區。
[[["容易理解","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-09-03 (世界標準時間)。"],[],[],null,["# Overview of access control\n\nYou control who has access to your Cloud Storage buckets and objects\nand what level of access they have.\n\nChoose between uniform and fine-grained access\n----------------------------------------------\n\nWhen you create a bucket, you should decide whether you want to apply\npermissions using *uniform* or *fine-grained* access.\n\n- **Uniform (recommended)** : [Uniform bucket-level access](/storage/docs/uniform-bucket-level-access) allows you to use\n [Identity and Access Management (IAM)](/storage/docs/access-control/iam) alone to manage permissions. IAM\n applies permissions to all the objects contained inside the bucket or groups of\n objects with common name prefixes. IAM also allows you to use\n features that are not available when working with ACLs, such as\n [managed folders](/storage/docs/managed-folders), [IAM Conditions](/iam/docs/conditions-overview),\n [domain restricted sharing](/resource-manager/docs/organization-policy/restricting-domains), and [workforce identity federation](/iam/docs/workforce-identity-federation).\n\n- **Fine-grained** : The fine-grained option enables you to use\n IAM and [Access Control Lists (ACLs)](/storage/docs/access-control/lists) together to manage\n permissions. ACLs are a legacy access control system for Cloud Storage\n designed for interoperability with Amazon S3. ACLs also allow you to specify\n access on a per-object basis.\n\n Because fine-grained access requires you to coordinate between two different\n access control systems, there is an increased chance of unintentional data\n exposure, and auditing who has access to resources is more complicated.\n Particularly if you have objects that contain sensitive data, such as\n personally identifiable information, we recommend storing that data in a\n bucket with uniform bucket-level access enabled.\n\n| **Note:** Once you enable uniform bucket-level access, you have 90 days to switch back to fine-grained access before uniform bucket-level access becomes permanent.\n\nUsing IAM permissions with ACLs\n-------------------------------\n\nCloud Storage offers two systems for granting users access your buckets\nand objects: IAM and Access Control Lists (ACLs). These systems\nact in parallel - in order for a user to access a Cloud Storage\nresource, only one of the systems needs to grant that user permission. For\nexample, if your bucket's IAM policy only allows a few users to\nread object data in the bucket, but one of the objects in the bucket has an ACL\nthat makes it publicly readable, then that specific object is exposed to the\npublic.\n| **Caution:** In general, IAM cannot detect permissions granted by ACLs, and ACLs cannot detect permissions granted by IAM.\n\nIn most cases, IAM is the recommended method for controlling\naccess to your resources. IAM controls permissioning throughout\nGoogle Cloud and allows you to grant permissions at the bucket and project\nlevels. You should use IAM for any permissions that apply to\nmultiple objects in a bucket to reduce the risks of unintended exposure. To use\nIAM exclusively, enable uniform bucket-level access to disallow ACLs for\nall Cloud Storage resources.\n\nACLs control permissioning only for Cloud Storage resources and have limited\npermission options, but allow you to grant permissions per individual objects.\nYou most likely want to use ACLs for the following use cases:\n\n- Customize access to individual objects within a bucket.\n- Migrate data from Amazon S3.\n\nAdditional access control options\n---------------------------------\n\nIn addition to IAM and ACLs, the following tools are available to help you\ncontrol access to your resources:\n\n### Signed URLs (query string authentication)\n\nUse [signed URLs](/storage/docs/access-control/signed-urls) to give time-limited read or write access to an object\nthrough a URL you generate. Anyone with whom you share the URL can access the\nobject for the duration of time you specify, regardless of whether or not they\nhave a user account.\n\nYou can use signed URLs in addition to IAM and ACLs. For example,\nyou can use IAM to grant access to a bucket for only a few\npeople, then create a signed URL that allows others to access a specific\nresource within the bucket.\n\nLearn how to create signed URLs:\n\n- [with the Google Cloud CLI or client libraries](/storage/docs/access-control/signing-urls-with-helpers).\n- [with your own program](/storage/docs/access-control/signing-urls-manually).\n\n### Signed Policy Documents\n\nUse [signed policy documents](/storage/docs/authentication/signatures#policy-document) to specify what can be uploaded to a bucket. Policy\ndocuments allow greater control over size, content type, and other upload\ncharacteristics than signed URLs, and can be used by website owners to allow\nvisitors to upload files to Cloud Storage.\n\nYou can use signed policy documents in addition to IAM and ACLs.\nFor example, you can use IAM to allow people in your organization\nto upload any object, then create a signed policy document that allows website\nvisitors to upload only objects that meet specific criteria.\n\n### Firebase Security Rules\n\nUse [Firebase Security Rules](https://firebase.google.com/docs/storage/security) to provide granular, attribute-based access control\nto mobile and web apps using the [Firebase SDKs for Cloud Storage](https://firebase.google.com/docs/storage). For example,\nyou can specify who can upload or download objects, how large an object can be,\nor when an object can be downloaded.\n\n### Public access prevention\n\nUse [public access prevention](/storage/docs/public-access-prevention) to restrict public access to your buckets and\nobjects. When you enable public access prevention, users who gain access\nthrough [`allUsers` and `allAuthenticatedUsers`](/iam/docs/principals-overview#principal-types) are disallowed access to\ndata.\n\n### Credential Access Boundaries\n\nUse [Credential Access Boundaries](/iam/docs/downscoping-short-lived-credentials) to downscope the permissions that are\navailable to an OAuth 2.0 access token. First, you define a Credential Access\nBoundary that specifies which buckets the token can access, as well as an upper\nbound on the permissions that are available on that bucket. You can then\n[create an OAuth 2.0 access token](https://developers.google.com/identity/protocols/OAuth2) and exchange it for a new access token\nthat respects the Credential Access Boundary.\n\n### Bucket IP Filtering\n\nUse [Bucket IP filtering](/storage/docs/ip-filtering-overview) to restrict access on your bucket based on the source IP address of the request. Bucket IP filtering adds a layer of security by preventing unauthorized networks from accessing your bucket and its data.\nYou can configure a list of permitted IP address ranges, including public IP addresses,\nranges of public IP addresses and IP addresses within your Virtual Private Cloud.\nAny requests originating from an IP address that's not on your list are blocked.\nAs a result, only authorized users can access your bucket.\n\nWhat's next\n-----------\n\n- Learn how to [use IAM permissions](/storage/docs/access-control/using-iam-permissions).\n- [Refer to IAM permissions and roles specific to Cloud Storage](/storage/docs/access-control/iam-reference)\n- View examples of [sharing and collaboration](/storage/docs/collaboration) scenarios that involve setting bucket and object ACLs.\n- Learn how to [make your data accessible to everyone on the public internet](/storage/docs/access-control/making-data-public).\n- Learn more about when to use a [signed url](/storage/docs/access-control/signed-urls#should-you-use)."]]
