Four ways to secure your Google Cloud Storage data

Cloud storage enables organisations 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. 

Security is a common concern for companies as they move their data to the cloud. Google Cloud Storage offers simple, reliable and cost-effective storage and retrieval of any amount of data at any time with built-in security capabilities such as encryption in transit and at rest and a range of encryption key management options including Google-managed, customer-supplied, customer-managed and hardware security modules. Google has one of the largest private networks in the world, minimizing exposure of your data to the public internet when you use Cloud Storage. 

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. 

Here are some security best practices for using these features to help secure and protect your data at scale. 

1. Use org policies to centralise 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 organisations. 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 behaviours. 

Here are two org policies that’s recommended to be enabled: 

• Domain-restricted sharing—This policy prevents content from being shared with people outside your organisation. 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. 

It’s recommended to use 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 

ACLs are used for different reasons such as multi-cloud architectures or sharing an object with an individual user. However, Google doesn’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 share 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, Google suggests 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, Google also recommends: 

• 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). 

To learn more about Cloud Storage and more ways to keep your data safe and compliant, check out Google’s access control documentation.