Google Cloud Storage Security

Google Cloud Storage Security includes controlling access using

• Uniform Bucket or File-grained ACL access control policies
• Data encryption at rest and transit
• Retention policies and Retention Policy Locks
• Signed URLs

GCS Access Control

• Cloud Storage offers two systems for granting users permission to access the buckets and objects: IAM and Access Control Lists (ACLs)
• IAM and ACLs can be used on the same resource, Cloud Storage grants the broader permission set on the resource
• Cloud Storage access control can be performed using
  • Uniform (recommended)
    • Uniform bucket-level access allows using IAM alone to manage permissions.
    • IAM applies permissions to all the objects contained inside the bucket or groups of objects with common name prefixes.
    • IAM also allows using features that are not available when working with ACLs, such as IAM Conditions and Cloud Audit Logs.
    • Enabling uniform bucket-level access disables ACLs, but it can be reversed before 90 days
  • Fine-grained
    • Fine-grained option enables using IAM and Access Control Lists (ACLs) together to manage permissions.
    • ACLs are a legacy access control system for Cloud Storage designed for interoperability with S3.
    • Access and apply permissions can be specified at both the bucket level and per individual object.
• Objects in the bucket can be made public using ACLs AllUsers:R or IAM allUsers:objectViewer permissions

Data Encryption

• Cloud Storage always encrypts the data on the server-side, before it is written to disk, at no additional charge.
• Cloud supports the following encryption
  • Server-side encryption: encryption that occurs after Cloud Storage receives the data, but before the data is written to disk and stored.
    • Google-managed encryption keys
      • Cloud Storage always encrypts the data on the server-side, before it is written to disk
      • Cloud Storage manages server-side encryption keys using the same hardened key management systems, including strict key access controls and auditing.
      • Cloud Storage encrypts user data at rest using AES-256.
      • Data is automatically decrypted when read by an authorized user
    • Customer-supplied encryption keys
      • customers create and manage their own encryption keys.
      • customer keys can be provided via customer-side using  encryption_key=[YOUR_ENCRYPTION_KEY] .boto configuration file
    • Customer-managed encryption keys
      • customers manage their own encryption keys generated by Cloud Key Management Service (KMS)
      • Cloud Storage does not permanently store the key on Google’s servers or otherwise manage your key.
      • Customer provides the key for each GCS operation, and the key is purged from Google’s servers after the operation is complete
      • Cloud Storage stores only a cryptographic hash of the key so that future requests can be validated against the hash.
      • The key cannot be recovered from this hash, and the hash cannot be used to decrypt the data.
  • Client-side encryption: encryption that occurs before data is sent to Cloud Storage, encrypted at the client-side. This data also undergoes server-side encryption.
• Cloud Storage supports Transport Layer Security, commonly known as TLS or HTTPS for data encryption in transit

Signed URLs

• Signed URLs provide time-limited read or write access to an object through a generated URL.
• Anyone having access to the URL can access the object for the duration of time specified, regardless of whether or not they have a Google account.

Signed Policy Documents

• Signed policy documents help specify what can be uploaded to a bucket.
• Policy documents allow greater control over size, content type, and other upload characteristics than signed URLs, and can be used by website owners to allow visitors to upload files to Cloud Storage.

Retention Policies

• Retention policy on a bucket ensures that all current and future objects in the bucket cannot be deleted or replaced until they reach the defined age
• Retention policy can be applied when creating a bucket or to an existing bucket
• Retention policy retroactively applies to existing objects in the bucket as well as new objects added to the bucket.

Retention Policy Locks

• Retention policy locks will lock a retention policy on a bucket, which prevents the policy from ever being removed or the retention period from ever being reduced (although it can be increased)
• Once a retention policy is locked, the bucket cannot be deleted until every object in the bucket has met the retention period.
• Locking a retention policy is irreversible

Bucket Lock

• Bucket Lock feature provides immutable storage i.e. Write Once Read Many (WORM) on Cloud Storage
• Bucket Lock feature allows configuring a data retention policy for a bucket that governs how long objects in the bucket must be retained
• Bucket Lock feature also locks the data retention policy, permanently preventing the policy from being reduced or removed.
• Bucket Lock can help with regulatory, legal, and compliance requirements

Object Holds

• Object holds, when set on individual objects, prevents the object from being deleted or replaced, however allows metadata to be edited.
• Cloud Storage offers the following types of holds:
  • Event-based holds.
  • Temporary holds.
• When an object is stored in a bucket without a retention policy, both hold types behave exactly the same.
• When an object is stored in a bucket with a retention policy, the hold types have different effects on the object when the hold is released:
  • An event-based hold resets the object’s time in the bucket for the purposes of the retention period.
  • A temporary hold does not affect the object’s time in the bucket for the purposes of the retention period.

GCP Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. You have an object in a Cloud Storage bucket that you want to share with an external company. The object contains sensitive data. You want access to the content to be removed after four hours. The external company does not have a Google account to which you can grant specific user-based access privileges. You want to use the most secure method that requires the fewest steps. What should you do?
   1. Create a signed URL with a four-hour expiration and share the URL with the company.
   2. Set object access to “public” and use object lifecycle management to remove the object after four hours.
   3. Configure the storage bucket as a static website and furnish the object’s URL to the company. Delete the object from the storage bucket after four hours.
   4. Create a new Cloud Storage bucket specifically for the external company to access. Copy the object to that bucket. Delete the bucket after four hours have passed