4 best practices for ensuring privacy and security of your data in Cloud Storage

Cloud storage enables organizations to reduce costs and operational burden, scale faster, and unlock other cloud computing benefits. At the same time, they must also ensure they meet privacy and security requirements to restrict access and protect sensitive information. 

Best practices for securing your data with Cloud Storage

Securing enterprise storage data requires planning ahead to protect your data from future threats and new challenges. Beyond the fundamentals, Cloud Storage offers several security features, such as uniform bucket-level access, service account HMAC keys, IAM conditions, Delegation tokens, and V4 signatures. 

We wanted to share some security best practices for using these features to help secure and protect your data at scale: 

#1: Use org policies to centralize control and define compliance boundaries
Cloud Storage, just like Google Cloud, follows a resource hierarchy. Buckets hold objects, which are associated with projects, which are then tied to organizations. You can also use folders to further separate project resources. Org policies are settings that you can configure at the org, folder, or project level to enforce service-specific behaviors. 

Here are two org policies we recommend enabling: 

• Domain-restricted sharing—This policy prevents content from being shared with people outside your organization. For example, if you tried to make the contents of a bucket available to the public internet, this policy would block that operation. 
• Uniform bucket-level access—This policy simplifies permissions and helps manage access control at scale. With this policy, all newly created buckets have uniform access control configured at the bucket level governing access for all the underlying objects. 

#2: Consider using Cloud IAM to simplify access control  
Cloud Storage offers two systems for granting permissions to your buckets and objects: Cloud IAM and Access Control Lists (ACLs). For someone to access a resource, only one of these systems needs to grant permissions. 

ACLs are object-level and grant access to individual objects. As the number of objects in a bucket increases, so does the overhead required to manage individual ACLs. It becomes difficult to assess how secure all the objects are within a single bucket. Imagine having to iterate across millions of objects to see if a single user has the correct access. 

We recommend using Cloud IAM to control access to your resources. Cloud IAM enables a Google Cloud wide, platform centric, uniform mechanism to manage access control for your Cloud Storage data. When you enable uniform bucket-level access control, object ACLs are disallowed, and Cloud IAM policies  at the bucket level are used to manage access—so permissions granted at a bucket-level automatically apply to all the objects in a bucket.

#3: If you can’t use IAM Policies, consider other alternatives to ACLs 
We recognize that sometimes our customers continue to use ACLs for different reasons, such as multi-cloud architectures or sharing an object with an individual user. However, we don’t recommend putting end users on object ACLs. 

Consider these alternatives instead: 

• Signed URLs—Signed URLs allow you to delegate time-limited access to your Cloud Storage resources. When you generate a signed URL, its query string contains authentication information tied to an account with access (e.g. a service account). For example, you could send a URL to someone allowing them to access a document, read it,  with access revoked after one week. 
• Separate buckets—Audit your buckets and look for access patterns. If you notice that a group of objects all share the same object ACL set, consider moving them into a separate bucket so you can control access at the bucket-level. 
• IAM conditions—If your app uses shared prefixes in object naming, you could also use IAM Conditions to shard access based on those prefixes.
• Delegation Tokens—You can use STS Tokens to grant time-limited access to Cloud Storage buckets and shared prefixes. 

#4 Use HMAC keys for service accounts, not user accounts 
A hash-based message authentication key (HMAC key) is a type of credential used to create signatures included in requests to Cloud Storage. In general, we suggest using HMAC keys for service accounts rather than user accounts. This helps eliminate the security and privacy implications of relying on accounts held by individual users. It also reduces the risk of service access outages as user accounts could be disabled when a user leaves a project or company.  

To further improve security, we also recommend: 

• Regularly changing your keys as part of a key rotation policy.
• Granting service accounts the minimum access to accomplish a task (i.e. the principle of least privilege). 
• Setting reasonable expiration times if you’re still using V2 signatures (or migrating to V4 signatures, which automatically enforces a maximum one-week time limit).