Last updated: May 22, 2026
This document identifies potential attack vectors and mitigation strategies for
data confidentiality, integrity, and availability for Cloud Storage. The
scope of this report is limited to your perspective, focusing on risks
that you can manage within your Cloud Storage environment.
These threat models are a probabilistic assessment based on currently known attack vectors, architectural assumptions, and the system's specified scope at the time of publication. These models are not exhaustive and are intended to serve as a baseline for Google Cloud customers' security and risk assessments and to guide risk reduction decisions.
The following threats were identified for this service:
Threat details
The following sections provide information about each threat, their
manifestations, and their recommended mitigations.
Information disclosure using insecure access configuration
Sensitive data stored in Cloud Storage objects can be exposed to unauthorized parties when access controls are misconfigured. Misconfiguring access controls is one of the most common and impactful cloud security issues.
| STRIDE category |
Information Disclosure |
| MITRE ATT&CK tactic |
Collection |
| Manifestations |
Public bucket exposure: A Cloud Storage bucket is made public by granting roles like Storage Object Viewer to allUsers or allAuthenticatedUsers accounts in its IAM allow policy. If public access prevention isn't enforced, these roles expose all objects to the internet. Signed URL leakage: A signed URL, which acts as a temporary bearer token, is inadvertently leaked through client-side code, logs, or insecure transmission. Any external user or application that obtains the URL can access the specified Cloud Storage object with the permissions (for example, read or write) until the URL signature expires. Overly broad IAM permissions: Identities, such as a user account or service account, are granted broad permissions (for example, storage.objects.get or storage.objects.list) across many buckets when the identities only require access to a small subset of data. Compromised identity credentials: An attacker obtains the credentials for a user account or a service account key, letting them authenticate to the Cloud Storage JSON API and access all the data that the compromised identity is authorized to see. Load balancer misconfiguration: A Cloud Load Balancing instance that's configured with a Cloud Storage bucket as a backend can be misconfigured to publicly expose objects, even if the bucket itself is not public. This misconfiguration creates an alternative, potentially less secure, access path to the data, bypassing direct Cloud Storage IAM controls. Improper CDN caching: When a Cloud Storage bucket is used as a backend for Cloud Load Balancing and Cloud CDN, a misconfiguration can cause sensitive data to be cached at Google's public edge locations. If the backend service doesn't emit the correct Cache-Control headers (for example, private or no-store), the CDN might serve the cached content to unauthorized users, bypassing bucket IAM checks.
|
| Mitigations |
Enforce public access prevention on individual storage buckets or at a project, folder, or organization level with the storage.publicAccessPrevention organization policy constraint. Use uniform bucket-level access to simplify permissions and avoid legacy ACLs. Configure customer-managed encryption keys (CMEKs) to protect data with encryption-at-rest. Keep signed URL expiry times as short as possible. Regularly audit for and remove compromised or unused service account keys. Implement VPC Service Controls to create a service perimeter and prevent data exfiltration even if credentials are stolen. Ensure that Cloud Armor policies are applied to load balancers that serve Cloud Storage content to restrict access.
|
Elevation of privilege using IAM misconfigurations
An attacker with specific, seemingly innocuous IAM permissions can escalate their privileges to gain broader access, including administrative control over Cloud Storage buckets and the data they contain. This threat circumvents the intended security posture and breaks the principle of least privilege.
| STRIDE category |
Elevation of Privilege |
| MITRE ATT&CK tactic |
Privilege Escalation |
| Manifestations |
Direct policy modification: An identity, such as a user or service account, that is granted the storage.buckets.setIamPolicy permission on a Cloud Storage bucket can directly modify its allow policy. This configuration lets the attacker grant themselves highly privileged roles, such as Storage Admin, leading to complete control over the bucket's configuration and data. Service account impersonation: An identity with a role such as roles/iam.serviceAccountUser that contains the iam.serviceAccounts.actAs permission on a service account can attach the service account to other resources, such as a Compute Engine instance, to run code with the identity of the attached service account. Alternatively, an identity with a role such as roles/iam.serviceAccountTokenCreator that has permissions including iam.serviceAccounts.getAccessToken can generate access tokens for that service account. If the target service account has elevated permissions on Cloud Storage resources, the attacker effectively inherits those privileges. Signed URL generation: An identity with the iam.serviceAccounts.signBlob permission on a service account can generate V4 signed URLs. These URLs let the attacker create temporary, bearer-token access to objects that the service account can read or write, potentially bypassing more restrictive network controls or the attacker's own lack of direct Cloud Storage permissions.
|
| Mitigations |
Follow the principle of least privilege. Avoid adding permissions like storage.buckets.setIamPolicy, iam.serviceAccounts.actAs, or iam.serviceAccounts.signBlob to roles unless absolutely necessary. Use IAM conditions to restrict permissions to specific resources or timeframes. Regularly audit allow policies using tools like Cloud Asset Inventory to detect and remove excessive permissions. Ensure that applications that handle signed URLs don't log them or expose them in a way that can be scraped by third parties. For example, if using Cloud CDN to cache signed URLs, set appropriate Cache-Control headers to avoid publicly caching sensitive objects that should be private and authenticated through a signed URL.
|
Data tampering or destruction using excessive permissions
An attacker with sufficient permissions can alter, corrupt, or permanently delete data and configurations within the Cloud Storage system, leading to a loss of data integrity and availability.
| STRIDE category |
Tampering |
| MITRE ATT&CK tactic |
Impact |
| Manifestations |
Direct object manipulation: An identity with storage.objects.create or storage.objects.delete permissions can overwrite or destroy individual Cloud Storage objects. Lifecycle policy weaponization: An attacker with the storage.buckets.update permission can modify a bucket's Object Lifecycle Management configuration to create a rule that deletes all objects immediately or after a short period, leading to mass data destruction. Bucket deletion: A highly privileged attacker with the storage.buckets.delete permission can delete an entire Cloud Storage bucket, instantly destroying all objects, configurations, and policies associated with it. Notification hijacking: An attacker with the storage.buckets.update permission can maliciously alter or delete a Pub/Sub notification configuration. This attack can blind downstream systems that rely on these events or redirect notifications to an attacker-controlled topic.
|
| Mitigations |
If you require immutable storage or a minimum retention period, configure bucket lock for the entire bucket, or object lock for individual objects. Configure object versioning and a soft delete policy to plan for recovery against accidental or malicious rewrites on buckets that contain critical data. Implement a specified soft delete period that gives you sufficient time to detect and recover the objects before permanent deletion. Enable Data Access audit logs on buckets that contain critical data to help monitor irregular access patterns.
|
Data exfiltration using misconfigured Storage Transfer Service jobs
An attacker with storagetransfer.transferjobs.create or storagetransfer.transferjobs.update permissions can create or modify a Storage Transfer Service job to copy data from a sensitive Cloud Storage bucket to an attacker-controlled bucket in another project. This attack vector can be used to exfiltrate large volumes of data silently and continuously, bypassing typical data access monitoring that might be focused on direct API calls like storage.objects.get.
| STRIDE category |
Information Disclosure |
| MITRE ATT&CK tactic |
Exfiltration |
| Manifestations |
Malicious transfer job creation: An attacker with storagetransfer.transferjobs.create or storagetransfer.transferjobs.update permissions creates or modifies a Storage Transfer Service job to copy data from a sensitive Cloud Storage bucket to an attacker-controlled bucket in another project.
|
| Mitigations |
Strictly limit IAM permissions for storagetransfer.transferjobs.create and storagetransfer.transferjobs.update. Only assign these permissions to roles that are used by trusted administrative accounts. Implement a VPC Service Controls perimeter to restrict communication between services inside the perimeter and services outside the perimeter. Use IAM conditions on roles that grant transfer job permissions to restrict the source and destination buckets to known, authorized locations. Regularly monitor Cloud Audit Logs for the creation and modification of Storage Transfer Service jobs. Configure alerts for any jobs that specify an untrusted or external destination.
|
Loss of data access using dependency mismanagement
Attacks or mismanagement of critical service dependencies can deny legitimate access to data in Cloud Storage, rendering data inaccessible even without directly compromising the storage system itself.
| STRIDE category |
Tampering |
| MITRE ATT&CK tactic |
Impact |
| Manifestations |
CMEK unavailability: If a Cloud Storage bucket is configured to use a CMEK, disabling or deleting the backing Cloud KMS key makes all objects that are encrypted with that key cryptographically inaccessible. The Cloud Storage service agent can't perform decryption, which results in a total denial of service for that data. Malicious bucket lock: An attacker with storage.buckets.update permissions can apply a bucket lock with an excessively long retention period. This lock prevents the legitimate deletion of data, which can lead to significant and unnecessary cost accumulation, a form of financial denial of service.
|
| Mitigations |
Implement strict IAM allow policies and separation of duties for Cloud KMS administration. Ensure that identities with permission to manage Cloud Storage buckets don't also have permission to manage the Cloud KMS keys that the buckets use. Use Cloud KMS key deletion prevention mechanisms. For bucket lock, tightly control the storage.buckets.update permission and use monitoring to alert on unexpected configuration changes.
|
Activity obfuscation through insufficient observability
An attacker can perform malicious actions against Cloud Storage resources without being detected if auditing and monitoring aren't properly configured. Insufficient observability lets an attacker hide their tracks and prevents effective incident response and forensics.
| STRIDE category |
Repudiation |
| MITRE ATT&CK tactic |
Defense Evasion |
| Manifestations |
Data Access logs disabled: While Admin Activity logs are always on, Data Access logs, which record object reads and writes, are disabled by default. If not explicitly enabled, an attacker can exfiltrate or tamper with all data in a bucket, without generating Cloud Audit Logs for those actions, making the breach difficult to detect or investigate. Log sink manipulation: An attacker who gains sufficient permissions can disable or reconfigure the log sinks that route Cloud Audit Logs, effectively stopping the flow of security-relevant data to monitoring systems. Metric monitoring negligence: An attacker performs low-and-slow activities, such as gradually exfiltrating small amounts of data over a long period. These actions might not trigger high-severity alerts in Cloud Audit Logs but would create anomalous patterns in Cloud Monitoring metrics (for example, sustained egress traffic). Failure to monitor these metrics provides another way for an attacker to remain undetected.
|
| Mitigations |
Enable Data Access audit logs for all buckets that contain sensitive or critical data. Ensure that logs are routed to a secure, centralized logging project with tightly controlled permissions to prevent tampering with the log sinks. Configure log-based alerts in Cloud Monitoring or a SIEM to actively detect suspicious activities, such as anomalous access patterns or IAM allow policy changes. Create alerts based on key Cloud Monitoring metrics to detect deviations from baseline behavior. Use built-in Storage Intelligence dashboards and insights data from Data Security Posture Management to provide continuous, object-level risk exposure monitoring and security posture assessments.
|
Supply chain poisoning using compromised artifacts stored in Cloud Storage
If an attacker gains write access, such as storage.objects.create or storage.objects.delete, to a Cloud Storage bucket that's used for storing software artifacts (for example, binaries, container images, or build scripts), they can replace legitimate artifacts with malicious versions. Downstream CI/CD pipelines, developers, or end-users who trust the artifacts from this bucket will inadvertently run the compromised code, leading to a widespread supply chain attack.
| STRIDE category |
Tampering |
| MITRE ATT&CK tactic |
Initial Access |
| Manifestations |
Binary replacement: An attacker overwrites a release binary or library with a trojanized version. When this artifact is pulled into a build or deployed, the attacker's code runs within the target environment. Container image poisoning: An attacker with access to a bucket that's used as a backend for a container registry (for example, Artifact Registry) can potentially tamper with image layers, injecting vulnerabilities or backdoors. Build script modification: An attacker modifies build scripts (for example, cloudbuild.yaml or Makefile), stored in Cloud Storage to alter the build process itself. An attacker might modify build scripts to exfiltrate secrets or embed a backdoor during compilation. AI model poisoning: An attacker might swap a valid model checkpoint in Cloud Storage with a malicious checkpoint that runs code when loaded by a production system. Or an attacker might modify data in a Cloud Storage bucket that's used for model training to insert backdoors or malicious behavior into the trained model.
|
| Mitigations |
Use a dedicated artifact management service like Artifact Registry which provides vulnerability scanning and better access control. Avoid using standard Cloud Storage buckets for storing critical software artifacts. Implement digital signing for all build artifacts. Configure CI/CD pipelines to verify the signature of an artifact before deploying it, ensuring its integrity and provenance. Configure object versioning on a bucket to retain objects that were overwritten with malicious data.
|
Cost-based denial of service using Cloud Storage object flooding or egress abuse
An attacker with object creation permissions on a publicly writable or poorly secured bucket can upload a massive number of small objects, leading to significant financial costs from Class A operations and storage fees. Alternatively, an attacker with read access to a bucket with 'Requester Pays' disabled can repeatedly download large objects, generating excessive network egress charges and potentially impacting service availability for legitimate users due to billing limits.
| STRIDE category |
Denial of Service |
| MITRE ATT&CK tactic |
Impact |
| Manifestations |
Object flooding: An attacker uses a script to rapidly create millions of small objects in a bucket, driving up operational costs and potentially impacting applications that list or process bucket contents. Egress abuse: For a bucket hosting large public datasets, an attacker repeatedly downloads files, causing a financial drain through egress bandwidth costs. This abuse can lead to the project hitting billing quotas, effectively causing a denial of service.
|
| Mitigations |
Configure Cloud Billing alerts to notify administrators when costs exceed a predefined budget threshold, letting you detect anomalous spending early. For publicly accessible buckets, enable Requester Pays. This feature shifts the cost of data access and egress to the user downloading the data, mitigating egress-based cost attacks against the bucket owner. Use Storage Insights to monitor object-level activity. Storage Insights provides the visibility that's needed for cost forecasting and identifying high-traffic objects that might be targets for egress abuse.
|
Data integrity manipulation using Cloud Storage object versioning abuse
While object versioning is a key defense, an attacker with sufficient permissions, such as storage.objects.delete or storage.objects.create, can manipulate the object history to compromise data integrity. They can delete the current version of an object, causing an older, potentially incorrect or vulnerable version to become the 'live' version. This can be used to revert security patches, reintroduce bugs, or restore outdated information without being immediately obvious, as the object still exists.
| STRIDE category |
Tampering |
| MITRE ATT&CK tactic |
Impact |
| Manifestations |
Security patch reversal: An attacker deletes the latest version of an application binary or configuration file that contains a security patch, causing the system to revert to the previous, vulnerable version. Data corruption by reversion: In a system that relies on Cloud Storage for storing state or configuration, an attacker reverts a critical configuration object to an older state, causing service misconfigurations or data processing errors. AI model integrity manipulation: An attacker might overwrite or revert an AI model checkpoint stored in a Cloud Storage bucket.
|
| Mitigations |
Develop applications that rely on specific versions of objects to retrieve the object by its unique generation number, not just its name. This ensures the correct version is always fetched. Use a bucket lock with a defined retention policy for data that requires immutable storage. Configure a soft delete policy as an additional layer of defense against malicious deletion. Object versioning does not provide protection against bucket deletions.
|
Data exfiltration using Dataflow pipelines triggered by Cloud Storage
If a Dataflow pipeline is configured to automatically trigger on object creation in a Cloud Storage bucket, an attacker who can write to that bucket can potentially exfiltrate data. If the Dataflow job's service account has permissions to access other sensitive data and write to external locations (for example, another Cloud Storage bucket or BigQuery), the attacker can craft an input file that causes the pipeline to read sensitive data and write it to an attacker-controlled location.
| STRIDE category |
Information Disclosure |
| MITRE ATT&CK tactic |
Exfiltration |
| Manifestations |
Cross-project exfiltration: An attacker uploads a file to a trigger bucket. The Dataflow pipeline, running with a privileged service account, reads sensitive data from a different project and writes the output to a public Cloud Storage bucket specified by the attacker's input file.
|
| Mitigations |
Enclose the Dataflow pipeline and its Cloud Storage dependencies within a VPC Service Controls perimeter to prevent the pipeline from sending data to unauthorized external destinations. Apply the principle of least privilege to the Dataflow worker service account. It should only have the specific permissions needed to read from the source and write to the intended destination. Enable Data Access audit logs for DATA_WRITE events to help audit suspicious activity from the Dataflow pipeline. Enable uniform bucket-level access on your Cloud Storage bucket to ensure consistent IAM-based access control.
|
Integrity compromise using IaC state manipulation in Cloud Storage
When using Cloud Storage buckets to store infrastructure as code (IaC) state files (for example, the terraform.tfstate file in Terraform), an attacker with write access to the state bucket can tamper with the state file. By modifying the state, an attacker can inject malicious resources, change critical security configurations, or cause resource destruction on the next IaC run. This tampering bypasses code review processes, as the attack targets the state, not the code itself.
| STRIDE category |
Tampering |
| MITRE ATT&CK tactic |
Impact |
| Manifestations |
Security control disablement: An attacker alters the state file to show an inaccurate state for a firewall rule or IAM allow policy. The next Terraform apply might not correctly apply the intended secure configuration.
|
| Mitigations |
Enable object versioning on the Cloud Storage bucket that stores the state file. Object versioning lets you recover the state file in case of accidental or malicious modification. Implement strict IAM controls on the state file bucket. Ensure that only the CI/CD service account has write access, and developers have read-only access at most.
|
Privilege escalation for startup or bootstrap scripts stored in Cloud Storage
If a Compute Engine instance or GKE node pulls its startup or bootstrap scripts from a Cloud Storage bucket, an attacker with write access to that bucket can modify these scripts. Because these scripts often run with high privileges (for example, as root on the VM or with the node's service account), the attacker can inject commands to create backdoor users, exfiltrate metadata and access tokens, or install malicious software. These actions let an attacker escalate privileges from Cloud Storage object write permissions to full control over compute resources.
| STRIDE category |
Elevation of Privilege |
| MITRE ATT&CK tactic |
Privilege Escalation |
| Manifestations |
Metadata exfiltration: The attacker adds commands like curl -H 'Metadata-Flavor: Google' http://metadata.google.internal/... to the startup script to steal service account tokens or other secrets. Reverse shell: The attacker injects a command to initiate a reverse shell from the compute instance to an attacker-controlled server, granting them interactive access.
|
| Mitigations |
Store startup scripts in a dedicated, tightly controlled Cloud Storage bucket. Apply least-privilege IAM allow policies so that only authorized administrators or CI/CD pipelines can modify the scripts. Consider a data classification strategy where you configure resource tags on buckets used for startup scripts, and use IAM tag-based conditional access to further restrict access. Instead of pulling scripts from Cloud Storage, include them in custom machine images. This strategy creates an immutable artifact that is less susceptible to runtime modification.
|
Supply chain backdoor using Cloud Storage hosted ML training data
An attacker with write access to a Cloud Storage bucket that contains training data for a machine learning model can poison the dataset. By injecting carefully crafted malicious data, the attacker can create a backdoor in the trained model. This backdoor can cause the model to misclassify specific inputs in a way that benefits the attacker while behaving normally on general data to evade detection. For example, the model might approve fraudulent transactions or bypass security checks.
| STRIDE category |
Tampering |
| MITRE ATT&CK tactic |
Impact |
| Manifestations |
Targeted misclassification: An attacker inserts poisoned data that causes a trained fraud detection model to always classify transactions from an attacker-controlled account as legitimate. Model evasion: An attacker poisons a malware detection model's training data with examples of their malware labeled as benign, causing the final model to ignore their specific tools.
|
| Mitigations |
Implement strong access controls on Cloud Storage buckets that contain training data. Apply the principle of least privilege for granting write access to these buckets, and regularly audit with tools like Policy Analyzer. Consider a data classification strategy where you configure resource tags on buckets used for ML training data, and add IAM tag-based conditions to further restrict access. Audit for unauthorized modifications to the objects used for training data. Configure object versioning, maintain checksums, and configure Data Access audit logs for the DATA_WRITE event to help audit anomalies for object creation events that are related to the training data. Regularly audit and validate ML models for unexpected behavior. Employ adversarial testing techniques to probe for hidden backdoors or vulnerabilities introduced during training. Configure a VPC Service Controls perimeter to restrict access to sensitive resources, such as training data and other services involved in model creation, from outside of the trusted perimeter.
|
Denial of service using fan-out workflows triggered by object creation in Cloud Storage
If a workflow (for example, Cloud Run functions, or Workflows) is configured to trigger object creation in a Cloud Storage bucket and perform a resource-intensive task, an attacker with storage.objects.create permission can initiate a denial of service attack. By uploading a large number of files in a short period (known as a fan-out trigger), the attacker can cause the downstream service to scale rapidly, consuming excessive resources, hitting concurrency or scaling limits, and incurring significant costs, ultimately leading to service unavailability for legitimate users.
| STRIDE category |
Denial of Service |
| MITRE ATT&CK tactic |
Impact |
| Manifestations |
Resource exhaustion: An attacker uploads 10,000 small files, triggering 10,000 parallel Cloud Run functions invocations that exhaust the project's CPU quota, memory, or downstream API rate limits. Cost-based DoS: The fan-out triggers a massive number of executions in a paid service, leading to a huge bill and potential account suspension, effectively denying service.
|
| Mitigations |
Implement strong access controls on Cloud Storage buckets that trigger workflows. Apply the principle of least privilege for granting write access to these buckets, and regularly audit with tools like Policy Analyzer. Set concurrency limits on event-driven Cloud Run functions to control the maximum number of parallel executions, preventing resource exhaustion. Implement a debouncing mechanism, which then invokes the main processing logic. An example debouncing mechanism is to add a task to a Cloud Tasks queue with rate limits. This mechanism helps manage sudden surges in request volume by spreading them over time. Configure a VPC Service Controls perimeter to restrict access to sensitive resources, such as writing to a bucket that triggers a workflow, from outside of the trusted perimeter.
|
Unauthorized data movement using Cloud Storage-backed backup pipelines
Backup and Disaster Recovery (DR) tools often use Cloud Storage as a staging area or final destination for backups. If an attacker compromises the configuration of this tooling, they can redirect backups to an attacker-controlled Cloud Storage bucket. The backup service account often has broad read permissions across many data sources (for example, databases or VMs), letting the attacker exfiltrate large volumes of sensitive data by manipulating the backup job's destination parameter.
| STRIDE category |
Information Disclosure |
| MITRE ATT&CK tactic |
Exfiltration |
| Manifestations |
Backup job redirection: An attacker with permissions to edit a backup job configuration changes the target Cloud Storage bucket path to gs://attacker-public-bucket/. Cross-project backup: The attacker configures a new backup job within a compromised project to read data from a sensitive source and back it up to a bucket in a different, attacker-controlled Google Cloud project.
|
| Mitigations |
Ensure the backup tool's service accounts have narrowly scoped permissions. Set up backup tools so that they can only write to specific, designated backup buckets and not read from arbitrary locations. Use VPC Service Controls to prevent backup services from accessing sensitive data sources and writing to Cloud Storage buckets outside of a secure perimeter.
|
Policy bypass using legacy Cloud Storage ACL usage in hybrid environments
Cloud Storage supports two mutually exclusive access control systems: IAM and legacy ACLs. When uniform bucket-level access is disabled, both systems are evaluated. An attacker can exploit this configuration by adding a legacy ACL (for example, granting a personal Google account or a public group access) to an object, even if the bucket-level allow policy appears restrictive. This attack creates a shadow access path that is often missed by IAM-centric security scanners, letting the attacker bypass intended security policies.
| STRIDE category |
Elevation of Privilege |
| MITRE ATT&CK tactic |
Defense Evasion |
| Manifestations |
Object-level public access: An attacker with the storage.objects.update permission adds a public-read ACL to a sensitive object, making it accessible to anyone on the internet, bypassing a restrictive bucket allow policy. Cross-account access: An attacker assigns their external account the OWNER permission on a critical configuration object using an ACL, letting them modify the object undetected by IAM audits.
|
| Mitigations |
Enable uniform bucket-level access on all Cloud Storage buckets. Uniform bucket-level access disables all ACLs and ensures that IAM is the sole and consistent method for managing access, simplifying audits and preventing this bypass. Use the organization policy constraint constraints/storage.uniformBucketLevelAccess to enforce uniform bucket-level access across all new buckets in a project, folder, or organization.
|
Data destruction using compromised CI/CD pipelines targeting Cloud Storage
CI/CD pipelines are often granted highly privileged service accounts to manage infrastructure and deploy artifacts. If an attacker compromises the CI/CD system, they can use the pipeline's service account to perform destructive actions on Cloud Storage. An example compromise is an attacker injecting malicious code into a build script or gaining access to the orchestrator. This compromise can involve deleting buckets or overwriting critical objects.
| STRIDE category |
Tampering |
| MITRE ATT&CK tactic |
Impact |
| Manifestations |
Malicious build step: An attacker adds a step to a CI/CD pipeline that wipes all data. For example, the attacker adds a step in cloudbuild.yaml that runs a command like gcloud storage rm -r gs://critical-bucket/. Privilege inheritance: The attacker uses the compromised pipeline's service account, which has broad permissions, to grant the attacker's own account administrative access to Cloud Storage buckets for later use.
|
| Mitigations |
Apply the principle of least privilege to CI/CD service accounts. For example, don't assign a build pipeline permissions to delete production buckets. Use separate identities for different pipeline stages, such as build, test, or deploy. Protect critical Cloud Storage buckets from deletion by enabling bucket lock or object lock, or by ensuring the CI/CD service account doesn't have the storage.buckets.delete permission.
|
Unauthorized bucket deletion using over-privileged break-glass accounts
Break-glass or emergency access accounts are highly privileged identities used only in emergencies. If these accounts aren't properly secured and governed (for example, credentials are leaked or access is not time-bound), an attacker who compromises a break-glass account can perform highly destructive actions. A primary risk is the deletion of entire Cloud Storage buckets, which can lead to catastrophic, irreversible data loss, as bucket deletion is a permanent action.
| STRIDE category |
Elevation of Privilege |
| MITRE ATT&CK tactic |
Privilege Escalation |
| Manifestations |
Catastrophic data loss: An attacker compromises a poorly managed break-glass account and runs a script to delete all Cloud Storage buckets in a project. Extortion: An attacker gains access and threatens to delete critical buckets unless a ransom is paid.
|
| Mitigations |
Implement just-in-time (JIT) access for break-glass procedures instead of using accounts with standing privileges. Grant permissions on-demand for a limited time and for a specific purpose. Apply a bucket lock to buckets that contain critical objects, or an object lock to individual objects. Locks prevent the deletion of the bucket and its objects, even by users with owner permissions, for a specified retention period.
|
Silent data exfiltration using compromised logging sinks writing to Cloud Storage
Cloud Logging can be configured to export logs to a Cloud Storage bucket. If an attacker gains permissions to modify a logging sink, they can reconfigure it to export sensitive logs to an attacker-controlled Cloud Storage bucket in another project. Exporting sensitive logs lets an attacker silently and continuously exfiltrate sensitive data that's captured in logs.
| STRIDE category |
Information Disclosure |
| MITRE ATT&CK tactic |
Exfiltration |
| Manifestations |
Log sink redirection: An attacker modifies an existing log sink's destination property to point to their own Cloud Storage bucket. Malicious filter creation: An attacker creates a sink with a filter that specifically targets logs that contain sensitive information (for example, PII or tokens) and exports them.
|
| Mitigations |
Monitor Cloud Audit Logs for CreateSink and UpdateSink API calls. Configure alerts to notify security teams of any new or modified log sinks to ensure they are authorized. Configure a VPC Service Controls perimeter to mitigate data exfiltration.
|
Ransomware enablement using centralized CMEK revocation
When Cloud Storage buckets are encrypted with CMEK, the availability of the data is tied to the availability of the key. An attacker who gains sufficient permissions on Cloud KMS can destroy or disable the key that's used for a critical Cloud Storage bucket. This action renders all data in the bucket cryptographically inaccessible, effectively a form of data destruction or ransomware, as the data remains but cannot be decrypted.
| STRIDE category |
Tampering |
| MITRE ATT&CK tactic |
Impact |
| Manifestations |
Key destruction: An attacker with the cloudkms.cryptoKeyVersions.destroy permission permanently destroys a key version, making data recovery impossible. Key disablement: An attacker with the cloudkms.cryptoKeyVersions.disable permission disables a key, making the Cloud Storage data unreadable until the key is re-enabled. This action can cause a prolonged outage.
|
| Mitigations |
Enforce a minimum duration for the scheduled for destruction state before Cloud KMS keys can be destroyed. By default, this period is 30 days, but you can configure a period from 1 to 120 days at the time when a key is first created. You can't modify this period after a key is deleted. Consider enforcing the constraints/cloudkms.minimumDestroyScheduledDuration organization policy constraint to enforce that keys cannot be created with a scheduled for destruction period less than your expected minimum. Strictly limit access to Cloud KMS administrative roles. Separate the duties of key usage from key administration to prevent a single compromised account from both using and destroying keys. Periodically rotate Cloud KMS keys, choosing a rotation period based on the sensitivity or compliance requirements of your workload.
|
Data exfiltration using snapshot or backup exports to Cloud Storage
Many Google Cloud services (for example, Compute Engine or Cloud SQL) allow creating snapshots or exporting backups to Cloud Storage. An attacker with permissions to perform these export operations can create a snapshot of a resource that contains sensitive data and save the snapshot to a Cloud Storage bucket with lax permissions, such as a public bucket or a bucket shared with an external account. This action bypasses the primary resource's stricter access controls (for example, database credentials) as the data is now accessible using Cloud Storage IAM.
| STRIDE category |
Information Disclosure |
| MITRE ATT&CK tactic |
Exfiltration |
| Manifestations |
Disk snapshot to public bucket: An internal developer with compute.snapshots.create and storage.objectAdmin permissions creates a snapshot of a VM disk that contains secrets and exports it to a public Cloud Storage bucket. Database export: An attacker with cloudsql.instances.export permission exports a production database to a Cloud Storage bucket in an attacker-controlled project.
|
| Mitigations |
Ensure that projects that are designated for backups and snapshots have IAM and VPC Service Controls policies that are at least as strict as the source projects to maintain a consistent security posture. Consider a data classification strategy where you configure resource tags on buckets used for backups, and add IAM tag-based access conditions to further restrict access.
|
