Última atualização: 22 de maio de 2026
Este documento identifica possíveis vetores de ataque e estratégias de mitigação para
confidencialidade, integridade e disponibilidade de dados no Cloud Storage. O escopo deste relatório é limitado à sua perspectiva, com foco em riscos que você pode gerenciar no seu ambiente do Cloud Storage.
Esses modelos de ameaças são uma avaliação probabilística baseada em vetores de ataque conhecidos, suposições arquitetônicas e o escopo especificado do sistema no momento da publicação. Esses modelos não são exaustivos e servem como base para as avaliações de segurança e risco dos clientes do Google Cloud e para orientar as decisões de redução de risco.
As seguintes ameaças foram identificadas para este serviço:
Detalhes da ameaça
As seções a seguir fornecem informações sobre cada ameaça, suas manifestações e as mitigações recomendadas.
Divulgação de informações usando uma configuração de acesso sem segurança
Dados sensíveis armazenados em objetos do Cloud Storage podem ser expostos a terceiros não autorizados quando os controles de acesso são configurados incorretamente. A configuração incorreta dos controles de acesso é um dos problemas de segurança na nuvem mais comuns e impactantes.
| Categoria STRIDE |
Divulgação de informações |
| Tática do MITRE ATT&CK |
Coleção |
| Manifestações |
Exposição de bucket público:um bucket do Cloud Storage é tornado público ao conceder papéis como Storage Object Viewer a contas allUsers ou allAuthenticatedUsers na política de permissão do IAM. Se a prevenção de acesso público não for aplicada, essas funções vão expor todos os objetos à Internet. Vazamento de URL assinado:um URL assinado, que funciona como um token de portador temporário, é vazado inadvertidamente por código do lado do cliente, registros ou transmissão não segura. Qualquer usuário ou aplicativo externo que obtenha o URL pode acessar o objeto especificado do Cloud Storage com as permissões (por exemplo, leitura ou gravação) até que a assinatura do URL expire. Permissões do IAM muito abrangentes:identidades, como uma conta de usuário ou de serviço, recebem permissões abrangentes (por exemplo, storage.objects.get ou storage.objects.list) em muitos buckets quando só precisam de acesso a um pequeno subconjunto de dados. Credenciais de identidade comprometidas:um invasor obtém as credenciais de uma conta de usuário ou uma chave de conta de serviço, permitindo que ele se autentique na API JSON do Cloud Storage e acesse todos os dados que a identidade comprometida tem autorização para ver. Configuração incorreta do balanceador de carga:uma instância do Cloud Load Balancing configurada com um bucket do Cloud Storage como back-end pode ser configurada incorretamente para expor objetos publicamente, mesmo que o bucket não seja público. Essa configuração incorreta cria um caminho de acesso alternativo, potencialmente menos seguro, aos dados, ignorando os controles diretos do IAM do Cloud Storage. Cache inadequado da CDN:quando um bucket do Cloud Storage é usado como back-end do Cloud Load Balancing e do Cloud CDN, uma configuração incorreta pode fazer com que dados sensíveis sejam armazenados em cache nos locais de borda públicos do Google. Se o serviço de back-end não emitir os cabeçalhos Cache-Control corretos (por exemplo, private ou no-store), a CDN poderá veicular o conteúdo armazenado em cache para usuários não autorizados, ignorando as verificações de IAM do bucket.
|
| Mitigações |
Aplique a prevenção de acesso público em buckets de armazenamento individuais ou no nível de um projeto, pasta ou organização com a restrição de política da organização storage.publicAccessPrevention. Use o acesso uniforme no nível do bucket para simplificar as permissões e evitar ACLs legadas. Configure chaves de criptografia gerenciadas pelo cliente (CMEKs) para proteger dados com criptografia em repouso. Mantenha os tempos de expiração de URL assinado o mais curtos possível. Audite e remova regularmente chaves de conta de serviço comprometidas ou não utilizadas. Implemente o VPC Service Controls para criar um perímetro de serviço e evitar a exfiltração de dados, mesmo que as credenciais sejam roubadas. Verifique se as políticas do Cloud Armor estão aplicadas aos balanceadores de carga que atendem ao conteúdo do Cloud Storage para restringir o acesso.
|
Elevação de privilégios usando configurações incorretas do IAM
Um invasor com permissões específicas e aparentemente inofensivas do IAM pode escalonar os privilégios para ter acesso mais amplo, incluindo controle administrativo sobre buckets do Cloud Storage e os dados que eles contêm. Essa ameaça burla a postura de segurança pretendida e viola o princípio de privilégio mínimo.
| Categoria STRIDE |
Elevação de privilégios |
| Tática do MITRE ATT&CK |
Escalonamento de privilégios |
| Manifestações |
Modificação direta da política:uma identidade, como um usuário ou uma conta de serviço, que recebe a permissão storage.buckets.setIamPolicy em um bucket do Cloud Storage pode modificar diretamente a política de permissão. Essa configuração permite que o invasor conceda a si mesmo papéis altamente privilegiados, como Storage Admin, levando ao controle total sobre a configuração e os dados do bucket. Identidade temporária de conta de serviço:uma identidade com um papel como roles/iam.serviceAccountUser que contém a permissão iam.serviceAccounts.actAs em uma conta de serviço pode anexar a conta a outros recursos, como uma instância do Compute Engine, para executar código com a identidade da conta de serviço anexada. Outra opção é uma identidade com um papel como roles/iam.serviceAccountTokenCreator que tenha permissões, incluindo iam.serviceAccounts.getAccessToken, para gerar tokens de acesso para essa conta de serviço. Se a conta de serviço de destino tiver permissões elevadas nos recursos do Cloud Storage, o invasor vai herdar esses privilégios. Geração de URL assinado:uma identidade com a permissão iam.serviceAccounts.signBlob em uma conta de serviço pode gerar URLs assinados V4. Esses URLs permitem que o invasor crie acesso temporário com token de portador a objetos que a conta de serviço pode ler ou gravar, possivelmente ignorando controles de rede mais restritivos ou a própria falta de permissões diretas do Cloud Storage do invasor.
|
| Mitigações |
Siga o princípio de privilégio mínimo. Evite adicionar permissões como storage.buckets.setIamPolicy, iam.serviceAccounts.actAs ou iam.serviceAccounts.signBlob a papéis, a menos que seja absolutamente necessário. Use as condições do IAM para restringir permissões a recursos ou períodos específicos. Audite regularmente as políticas de permissão usando ferramentas como o Inventário de recursos do Cloud para detectar e remover permissões excessivas. Verifique se os aplicativos que processam URLs assinados não os registram nem os expõem de uma forma que possa ser rastreada por terceiros. Por exemplo, se você estiver usando o Cloud CDN para armazenar URLs assinados em cache, defina cabeçalhos Cache-Control adequados para evitar o armazenamento público em cache de objetos sensíveis que precisam ser privados e autenticados por um URL assinado.
|
Adulteração ou destruição de dados usando permissões excessivas
Um invasor com permissões suficientes pode alterar, corromper ou excluir permanentemente dados e configurações no sistema do Cloud Storage, resultando em perda de integridade de dados e disponibilidade.
| Categoria STRIDE |
Adulteração |
| Tática do MITRE ATT&CK |
Impacto |
| Manifestações |
Manipulação direta de objetos:uma identidade com permissões storage.objects.create ou storage.objects.delete pode substituir ou destruir objetos individuais do Cloud Storage. Uso indevido de políticas de ciclo de vida:um invasor com a permissão storage.buckets.update pode modificar a configuração de gerenciamento do ciclo de vida de objetos de um bucket para criar uma regra que exclua todos os objetos imediatamente ou após um curto período, resultando na destruição em massa de dados. Exclusão de bucket:um invasor altamente privilegiado com a permissão storage.buckets.delete pode excluir um bucket inteiro do Cloud Storage, destruindo instantaneamente todos os objetos, configurações e políticas associados a ele. Sequestro de notificações:um invasor com a permissão storage.buckets.update pode alterar ou excluir maliciosamente uma configuração de notificação do Pub/Sub. Esse ataque pode prejudicar sistemas downstream que dependem desses eventos ou redirecionar notificações para um tópico controlado por um invasor.
|
| Mitigações |
Se você precisar de armazenamento imutável ou de um período de armazenamento mínimo, configure o bloqueio de bucket para o bucket inteiro ou o bloqueio de objeto para objetos individuais. Configure o controle de versões de objetos e uma política de exclusão reversível para planejar a recuperação contra substituições acidentais ou maliciosas em buckets que contêm dados críticos. Implemente um período de exclusão reversível especificado que dê tempo suficiente para detectar e recuperar os objetos antes da exclusão permanente. Ative os registros de auditoria de acesso a dados em buckets que contêm dados críticos para ajudar a monitorar padrões de acesso irregulares.
|
Exfiltração de dados usando jobs do Serviço de transferência do Cloud Storage mal configurados
Um invasor com permissões storagetransfer.transferjobs.create ou storagetransfer.transferjobs.update pode criar ou modificar um job do Serviço de transferência do Cloud Storage para copiar dados de um bucket sensível do Cloud Storage para um bucket controlado pelo invasor em outro projeto. Esse vetor de ataque pode ser usado para exfiltrar grandes volumes de dados de forma silenciosa e contínua, ignorando o monitoramento típico de acesso aos dados que pode se concentrar em chamadas diretas de API, como storage.objects.get.
| Categoria STRIDE |
Divulgação de informações |
| Tática do MITRE ATT&CK |
Exfiltração |
| Manifestações |
Criação de jobs de transferência maliciosos:um invasor com permissões storagetransfer.transferjobs.create ou storagetransfer.transferjobs.update cria ou modifica um job do Serviço de transferência do Cloud Storage para copiar dados de um bucket sensível do Cloud Storage para um bucket controlado pelo invasor em outro projeto.
|
| Mitigações |
Limite estritamente as permissões do IAM para storagetransfer.transferjobs.create e storagetransfer.transferjobs.update. Atribua essas permissões apenas a papéis usados por contas administrativas confiáveis. Implemente um perímetro do VPC Service Controls para restringir a comunicação entre serviços dentro e fora do perímetro. Use condições do IAM em papéis que concedem permissões de job de transferência para restringir os buckets de origem e destino a locais conhecidos e autorizados. Monitore regularmente os registros de auditoria do Cloud para a criação e modificação de jobs do Serviço de transferência do Cloud Storage. Configure alertas para jobs que especificam um destino externo ou não confiável.
|
Perda de acesso aos dados devido ao gerenciamento inadequado de dependências
Ataques ou má gestão de dependências de serviços críticos podem negar o acesso legítimo aos dados no Cloud Storage, tornando-os inacessíveis mesmo sem comprometer diretamente o sistema de armazenamento.
| Categoria STRIDE |
Adulteração |
| Tática do MITRE ATT&CK |
Impacto |
| Manifestações |
Indisponibilidade da CMEK:se um bucket do Cloud Storage estiver configurado para usar uma CMEK, a desativação ou exclusão da chave do Cloud KMS de apoio tornará todos os objetos criptografados com essa chave criptograficamente inacessíveis. O agente de serviço do Cloud Storage não pode realizar a descriptografia, o que resulta em uma negação total de serviço para esses dados. Bloqueio malicioso de bucket:um invasor com permissões storage.buckets.update pode aplicar um bloqueio de bucket com um período de armazenamento excessivamente longo. Esse bloqueio impede a exclusão legítima de dados, o que pode levar a um acúmulo significativo e desnecessário de custos, uma forma de negação de serviço financeira.
|
| Mitigações |
Implemente políticas de permissão estritas do IAM e segregação de funções para a administração do Cloud KMS. Verifique se as identidades com permissão para gerenciar buckets do Cloud Storage também não têm permissão para gerenciar as chaves do Cloud KMS usadas pelos buckets. Use mecanismos de prevenção de exclusão de chaves do Cloud KMS. Para o bloqueio de bucket, controle rigorosamente a permissão storage.buckets.update e use o monitoramento para alertar sobre mudanças inesperadas na configuração.
|
Ofuscação de atividade por observabilidade insuficiente
Um invasor pode realizar ações maliciosas contra recursos do Cloud Storage sem ser detectado se a auditoria e o monitoramento não estiverem configurados corretamente. A observabilidade insuficiente permite que um invasor oculte seus rastros e impede uma resposta a incidentes e uma análise forense eficazes.
| Categoria STRIDE |
Repúdio |
| Tática do MITRE ATT&CK |
Evasão de defesa |
| Manifestações |
Registros de acesso a dados desativados:os registros de atividade do administrador estão sempre ativados, mas os registros de acesso a dados, que gravam leituras e gravações de objetos, estão desativados por padrão. Se não estiverem ativados explicitamente, um invasor poderá exfiltrar ou adulterar todos os dados em um bucket sem gerar registros de auditoria do Cloud para essas ações, dificultando a detecção ou investigação da violação. Manipulação de coletores de registros:um invasor que obtiver permissões suficientes pode desativar ou reconfigurar os coletores de registros que encaminham os registros de auditoria do Cloud, interrompendo o fluxo de dados relevantes para a segurança aos sistemas de monitoramento. Negligência no monitoramento de métricas:um invasor realiza atividades lentas e discretas, como exfiltrar gradualmente pequenas quantidades de dados por um longo período. Essas ações podem não acionar alertas de alta gravidade nos registros de auditoria do Cloud, mas criam padrões anômalos nas métricas do Cloud Monitoring (por exemplo, tráfego de saída constante). Não monitorar essas métricas é outra maneira de um invasor permanecer sem ser detectado.
|
| Mitigações |
Ative os registros de auditoria de acesso a dados para todos os buckets que contêm dados sensíveis ou críticos. Verifique se os registros são encaminhados para um projeto de registro seguro e centralizado com permissões rigorosamente controladas para evitar adulterações nos coletores de registros. Configure alertas com base em registros no Cloud Monitoring ou em um SIEM para detectar atividades suspeitas, como padrões de acesso anômalos ou mudanças na política de permissão do IAM. Crie alertas com base nas principais métricas do Cloud Monitoring para detectar desvios do comportamento normal. Use os painéis e dados de insights da Storage Intelligence integrados do Gerenciamento de Postura de Segurança de Dados para fornecer monitoramento contínuo da exposição a riscos no nível do objeto e avaliações da postura de segurança.
|
Envenenamento da cadeia de suprimentos usando artefatos comprometidos armazenados no Cloud Storage
Se um invasor conseguir acesso de gravação, como storage.objects.create ou storage.objects.delete, a um bucket do Cloud Storage usado para armazenar artefatos de software (por exemplo, binários, imagens de contêiner ou scripts de build), ele poderá substituir artefatos legítimos por versões maliciosas. Pipelines de CI/CD downstream, desenvolvedores ou usuários finais que confiam nos artefatos desse bucket vão executar inadvertidamente o código comprometido, resultando em um ataque generalizado à cadeia de suprimentos.
| Categoria STRIDE |
Adulteração |
| Tática do MITRE ATT&CK |
Acesso inicial |
| Manifestações |
Substituição de binários:um invasor substitui um binário ou uma biblioteca de lançamento por uma versão trojanizada. Quando esse artefato é extraído para um build ou implantado, o código do invasor é executado no ambiente de destino. Envenenamento de imagens de contêiner:um invasor com acesso a um bucket usado como back-end para um registro de contêiner (por exemplo, o Artifact Registry) pode adulterar camadas de imagens, injetando vulnerabilidades ou backdoors. Modificação do script de build:um invasor modifica scripts de build (por exemplo, cloudbuild.yaml ou Makefile) armazenados no Cloud Storage para alterar o processo de build. Um invasor pode modificar scripts de build para exfiltrar segredos ou incorporar uma porta dos fundos durante a compilação. Envenenamento de modelo de IA:um invasor pode trocar um checkpoint de modelo válido no Cloud Storage por um checkpoint malicioso que executa código quando carregado por um sistema de produção. Ou um invasor pode modificar dados em um bucket do Cloud Storage usado para treinamento de modelo e inserir backdoors ou comportamentos maliciosos no modelo treinado.
|
| Mitigações |
Use um serviço dedicado de gerenciamento de artefatos, como o Artifact Registry, que oferece verificação de vulnerabilidades e melhor controle de acesso. Evite usar buckets padrão do Cloud Storage para armazenar artefatos de software críticos. Implemente a assinatura digital para todos os artefatos de build. Configure pipelines de CI/CD para verificar a assinatura de um artefato antes da implantação, garantindo a integridade e a origem dele. Configure o controle de versões de objetos em um bucket para reter objetos que foram substituídos por dados maliciosos.
|
Negação de serviço baseada em custos usando inundação de objetos do Cloud Storage ou abuso de saída
Um invasor com permissões de criação de objetos em um bucket gravável publicamente ou mal protegido pode fazer upload de um grande número de objetos pequenos, resultando em custos financeiros significativos de operações de classe A e taxas de armazenamento. Como alternativa, um invasor com acesso de leitura a um bucket com "O solicitante paga" desativado pode baixar repetidamente objetos grandes, gerando cobranças excessivas de saída de rede e afetando potencialmente a disponibilidade do serviço para usuários legítimos devido aos limites de faturamento.
| Categoria STRIDE |
Negação de serviço |
| Tática do MITRE ATT&CK |
Impacto |
| Manifestações |
Inundação de objetos:um invasor usa um script para criar rapidamente milhões de objetos pequenos em um bucket, aumentando os custos operacionais e afetando potencialmente os aplicativos que listam ou processam o conteúdo do bucket. Abuso de saída:em um bucket que hospeda grandes conjuntos de dados públicos, um invasor baixa arquivos repetidamente, causando um prejuízo financeiro devido aos custos de largura de banda de saída. Esse abuso pode fazer com que o projeto atinja as cotas de faturamento, causando uma negação de serviço.
|
| Mitigações |
Configure alertas do Cloud Billing para notificar os administradores quando os custos excederem um limite de orçamento predefinido, permitindo que você detecte gastos anômalos com antecedência. Para buckets acessíveis publicamente, ative os pagamentos do solicitante. Esse recurso transfere o custo de acesso aos dados e saída para o usuário que faz o download, mitigando ataques de custo baseados em saída contra o proprietário do bucket. Use o Storage Insights para monitorar a atividade no nível do objeto. O Storage Insights oferece a visibilidade necessária para a previsão de custos e a identificação de objetos de alto tráfego que podem ser alvos de abuso de saída.
|
Manipulação da integridade de dados usando abuso do controle de versões de objetos do Cloud Storage
Embora o controle de versões de objetos seja uma defesa fundamental, um invasor com permissões suficientes, como storage.objects.delete ou storage.objects.create, pode manipular o histórico de objetos para comprometer a integridade de dados. Eles podem excluir a versão atual de um objeto, fazendo com que uma versão mais antiga, potencialmente incorreta ou vulnerável, se torne a versão "ativa". Isso pode ser usado para reverter patches de segurança, reintroduzir bugs ou restaurar informações desatualizadas sem ser imediatamente óbvio, já que o objeto ainda existe.
| Categoria STRIDE |
Adulteração |
| Tática do MITRE ATT&CK |
Impacto |
| Manifestações |
Reversão de patch de segurança:um invasor exclui a versão mais recente de um arquivo binário de aplicativo ou de configuração que contém um patch de segurança, fazendo com que o sistema reverta para a versão anterior e vulnerável. Corrupção de dados por reversão:em um sistema que depende do Cloud Storage para armazenar estado ou configuração, um invasor reverte um objeto de configuração crítica para um estado mais antigo, causando erros de processamento de dados ou configurações incorretas do serviço. Manipulação da integridade do modelo de IA:um invasor pode substituir ou reverter um ponto de verificação de modelo de IA armazenado em um bucket do Cloud Storage.
|
| Mitigações |
Desenvolva aplicativos que dependam de versões específicas de objetos para recuperar o objeto pelo número de geração exclusivo, não apenas pelo nome. Isso garante que a versão correta seja sempre buscada. Use um bloqueio de bucket com uma política de retenção definida para dados que exigem armazenamento imutável. Configure uma política de exclusão reversível como uma camada extra de defesa contra exclusões maliciosas. O controle de versões de objetos não oferece proteção contra exclusões de bucket.
|
Exfiltração de dados usando pipelines do Dataflow acionados pelo Cloud Storage
Se um pipeline do Dataflow estiver configurado para ser acionado automaticamente na criação de objetos em um bucket do Cloud Storage, um invasor com permissão de gravação nesse bucket poderá exfiltrar dados. Se a conta de serviço do job do Dataflow tiver permissões para acessar outros dados sensíveis e gravar em locais externos (por exemplo, outro bucket do Cloud Storage ou BigQuery), o invasor poderá criar um arquivo de entrada que faça com que o pipeline leia dados sensíveis e os grave em um local controlado por ele.
| Categoria STRIDE |
Divulgação de informações |
| Tática do MITRE ATT&CK |
Exfiltração |
| Manifestações |
Exfiltração entre projetos:um invasor faz upload de um arquivo para um bucket de gatilho. O pipeline do Dataflow, executado com uma conta de serviço privilegiada, lê dados sensíveis de um projeto diferente e grava a saída em um bucket do Cloud Storage público especificado pelo arquivo de entrada do invasor.
|
| Mitigações |
Coloque o pipeline do Dataflow e as dependências do Cloud Storage em um perímetro do VPC Service Controls para impedir que o pipeline envie dados a destinos externos não autorizados. Aplique o princípio de privilégio mínimo à conta de serviço do worker do Dataflow. Ela só pode ter as permissões específicas necessárias para ler a origem e gravar no destino pretendido. Ative os registros de auditoria de acesso a dados para eventos DATA_WRITE e audite atividades suspeitas do pipeline do Dataflow. Ative o acesso uniforme no nível do bucket no seu bucket do Cloud Storage para garantir um controle de acesso consistente baseado no IAM.
|
Comprometimento da integridade usando manipulação de estado da IaC no Cloud Storage
Ao usar buckets do Cloud Storage para armazenar arquivos de estado de infraestrutura como código (IaC), por exemplo, o arquivo terraform.tfstate no Terraform, um invasor com acesso de gravação ao bucket de estado pode adulterar o arquivo de estado. Ao modificar o estado, um invasor pode injetar recursos maliciosos, mudar configurações de segurança críticas ou causar a destruição de recursos na próxima execução da IaC. Essa violação ignora os processos de revisão de código, já que o ataque tem como alvo o estado, não o código em si.
| Categoria STRIDE |
Adulteração |
| Tática do MITRE ATT&CK |
Impacto |
| Manifestações |
Desativação do controle de segurança:um invasor altera o arquivo de estado para mostrar um estado impreciso de uma regra de firewall ou uma política de permissão do IAM. A próxima aplicação do Terraform pode não aplicar corretamente a configuração segura pretendida.
|
| Mitigações |
Ative o controle de versões de objeto no bucket do Cloud Storage que armazena o arquivo de estado. O controle de versões de objetos permite recuperar o arquivo de estado em caso de modificação acidental ou maliciosa. Implemente controles rigorosos do IAM no bucket de arquivos de estado. Verifique se apenas a conta de serviço de CI/CD tem acesso de gravação e se os desenvolvedores têm acesso somente leitura no máximo.
|
Escalonamento de privilégios para scripts de inicialização ou bootstrap armazenados no Cloud Storage.
Se uma instância do Compute Engine ou um nó do GKE extrair os scripts de inicialização ou bootstrap de um bucket do Cloud Storage, um invasor com acesso de gravação a esse bucket poderá modificar esses scripts. Como esses scripts geralmente são executados com privilégios elevados (por exemplo, como raiz na VM ou com a conta de serviço do nó), o invasor pode injetar comandos para criar usuários de backdoor, exfiltrar metadados e tokens de acesso ou instalar software malicioso. Essas ações permitem que um invasor aumente os privilégios de permissões de gravação de objetos do Cloud Storage para controle total sobre os recursos de computação.
| Categoria STRIDE |
Elevação de privilégios |
| Tática do MITRE ATT&CK |
Escalonamento de privilégios |
| Manifestações |
Exfiltração de metadados:o invasor adiciona comandos como curl -H 'Metadata-Flavor: Google' http://metadata.google.internal/... ao script de inicialização para roubar tokens de conta de serviço ou outros secrets. Shell reverso:o invasor injeta um comando para iniciar um shell reverso da instância de computação para um servidor controlado por ele, concedendo acesso interativo.
|
| Mitigações |
Armazene scripts de inicialização em um bucket dedicado e altamente controlado do Cloud Storage. Aplique políticas de permissão do IAM com privilégio mínimo para que somente administradores autorizados ou pipelines de CI/CD possam modificar os scripts. Considere uma estratégia de classificação de dados em que você configura tags de recursos em buckets usados para scripts de inicialização e usa o acesso condicional baseado em tags do IAM para restringir ainda mais o acesso. Em vez de extrair scripts do Cloud Storage, inclua-os em imagens de máquina personalizadas. Essa estratégia cria um artefato imutável menos suscetível a modificações de tempo de execução.
|
Backdoor na cadeia de suprimentos usando dados de treinamento de ML hospedados no Cloud Storage
Um invasor com acesso de gravação a um bucket do Cloud Storage que contém dados de treinamento para um modelo de aprendizado de máquina pode contaminar o conjunto de dados. Ao injetar dados maliciosos cuidadosamente elaborados, o invasor pode criar uma porta dos fundos no modelo treinado. Essa porta dos fundos pode fazer com que o modelo classifique incorretamente entradas específicas de uma forma que beneficie o invasor, mas se comporte normalmente em dados gerais para evitar a detecção. Por exemplo, o modelo pode aprovar transações fraudulentas ou ignorar verificações de segurança.
| Categoria STRIDE |
Adulteração |
| Tática do MITRE ATT&CK |
Impacto |
| Manifestações |
Classificação incorreta direcionada:um invasor insere dados envenenados que fazem com que um modelo treinado de detecção de fraude sempre classifique como legítimas as transações de uma conta controlada por ele. Evasão de modelo:um invasor envenena os dados de treinamento de um modelo de detecção de malware com exemplos do próprio malware rotulados como benignos, fazendo com que o modelo final ignore as ferramentas específicas dele.
|
| Mitigações |
Implemente controles de acesso rigorosos em buckets do Cloud Storage que contenham dados de treinamento. Aplique o princípio de privilégio mínimo para conceder acesso de gravação a esses buckets e faça auditorias regularmente com ferramentas como a Análise de políticas. Considere uma estratégia de classificação de dados em que você configura tags de recursos em buckets usados para dados de treinamento de ML e adiciona condições baseadas em tags do IAM para restringir ainda mais o acesso. Auditoria de modificações não autorizadas nos objetos usados para dados de treinamento. Configure o controle de versões de objetos, mantenha checksums e configure registros de auditoria de acesso a dados para o evento DATA_WRITE. Isso ajuda a auditar anomalias em eventos de criação de objetos relacionados aos dados de treinamento. Faça auditorias e validações regulares dos modelos de ML para detectar comportamentos inesperados. Use técnicas de teste adversário para investigar backdoors ou vulnerabilidades ocultas introduzidas durante o treinamento. Configure um perímetro do VPC Service Controls para restringir o acesso a recursos sensíveis, como dados de treinamento e outros serviços envolvidos na criação de modelos, de fora do perímetro confiável.
|
Negação de serviço usando fluxos de trabalho de distribuição de dados acionados pela criação de objetos no Cloud Storage
Se um fluxo de trabalho (por exemplo, funções do Cloud Run ou Workflows) for configurado para acionar a criação de objetos em um bucket do Cloud Storage e realizar uma tarefa que consome muitos recursos, um invasor com permissão storage.objects.create poderá iniciar um ataque de negação de serviço. Ao fazer upload de um grande número de arquivos em um curto período (conhecido como um gatilho de distribuição de dados), o invasor pode fazer com que o serviço downstream seja escalonado rapidamente, consumindo recursos excessivos, atingindo limites de simultaneidade ou escalonamento e incorrendo em custos significativos, o que acaba levando à indisponibilidade do serviço para usuários legítimos.
| Categoria STRIDE |
Negação de serviço |
| Tática do MITRE ATT&CK |
Impacto |
| Manifestações |
Esgotamento de recursos:um invasor faz upload de 10.000 arquivos pequenos, acionando 10.000 invocações paralelas de funções do Cloud Run que esgotam a cota de CPU, a memória ou os limites de taxa da API downstream do projeto. DoS baseado em custo:a distribuição de dados aciona um grande número de execuções em um serviço pago, resultando em uma fatura enorme e possível suspensão da conta, negando efetivamente o serviço.
|
| Mitigações |
Implemente controles de acesso robustos em buckets do Cloud Storage que acionam fluxos de trabalho. Aplique o princípio de privilégio mínimo para conceder acesso de gravação a esses buckets e faça auditorias regulares com ferramentas como a Análise de políticas. Defina limites de simultaneidade em funções do Cloud Run orientadas a eventos para controlar o número máximo de execuções paralelas e evitar o esgotamento de recursos. Implemente um mecanismo de remoção de duplicação, que invoca a lógica principal de processamento. Um exemplo de mecanismo de remoção de duplicação é adicionar uma tarefa a uma fila do Cloud Tasks com limites de taxa. Esse mecanismo ajuda a gerenciar picos repentinos no volume de solicitações, distribuindo-as ao longo do tempo. Configure um perímetro do VPC Service Controls para restringir o acesso a recursos sensíveis, como a gravação em um bucket que aciona um fluxo de trabalho, de fora do perímetro confiável.
|
Movimentação não autorizada de dados usando pipelines de backup com suporte do Cloud Storage
As ferramentas de backup e recuperação de desastres (DR, na sigla em inglês) costumam usar o Cloud Storage como uma área de preparo ou destino final para backups. Se um invasor comprometer a configuração dessas ferramentas, ele poderá redirecionar os backups para um bucket do Cloud Storage controlado por ele. A conta de serviço de backup geralmente tem permissões de leitura amplas em várias fontes de dados (por exemplo, bancos de dados ou VMs), permitindo que o invasor exfiltre grandes volumes de dados sensíveis manipulando o parâmetro de destino do job de backup.
| Categoria STRIDE |
Divulgação de informações |
| Tática do MITRE ATT&CK |
Exfiltração |
| Manifestações |
Redirecionamento de jobs de backup:um invasor com permissões para editar uma configuração de job de backup muda o caminho do bucket do Cloud Storage de destino para gs://attacker-public-bucket/. Backup entre projetos:o invasor configura um novo job de backup em um projeto comprometido para ler dados de uma fonte sensível e fazer backup em um bucket em outro projeto na nuvem do Google Cloud controlado pelo invasor.
|
| Mitigações |
Verifique se as contas de serviço da ferramenta de backup têm permissões com escopo restrito. Configure as ferramentas de backup para que elas só possam gravar em buckets de backup específicos e designados, e não ler de locais arbitrários. Use o VPC Service Controls para impedir que os serviços de backup acessem fontes de dados sensíveis e gravem em buckets do Cloud Storage fora de um perímetro seguro.
|
Substituição de política usando o uso de ACLs legadas do Cloud Storage em ambientes híbridos
O Cloud Storage é compatível com dois sistemas de controle de acesso mutuamente exclusivos: IAM e ACLs legadas. Quando o acesso uniforme no nível do bucket está desativado, os dois sistemas são avaliados. Um invasor pode explorar essa configuração adicionando uma ACL legada (por exemplo, concedendo acesso a uma Conta do Google pessoal ou a um grupo público) a um objeto, mesmo que a política de permissão no nível do bucket pareça restritiva. Esse ataque cria um caminho de acesso alternativo que geralmente não é detectado por scanners de segurança centrados no IAM, permitindo que o invasor ignore as políticas de segurança pretendidas.
| Categoria STRIDE |
Elevação de privilégios |
| Tática do MITRE ATT&CK |
Evasão de defesa |
| Manifestações |
Acesso público no nível do objeto:um invasor com a permissão storage.objects.update adiciona uma ACL public-read a um objeto sensível, tornando-o acessível a qualquer pessoa na Internet e ignorando uma política de permissão restritiva do bucket. Acesso entre contas:um invasor atribui à conta externa dele a permissão OWNER em um objeto de configuração crítica usando uma ACL, permitindo que ele modifique o objeto sem ser detectado pelas auditorias do IAM.
|
| Mitigações |
Ative o acesso uniforme no nível do bucket em todos os buckets do Cloud Storage. O acesso uniforme no nível do bucket desativa todas as ACLs e garante que o IAM seja o único método consistente para gerenciar o acesso, simplificando as auditorias e evitando esse bypass. Use a restrição da política da organização constraints/storage.uniformBucketLevelAccess para aplicar o acesso uniforme no nível do bucket em todos os novos buckets de um projeto, uma pasta ou uma organização.
|
Destruição de dados usando pipelines de CI/CD comprometidos direcionados ao Cloud Storage
Os pipelines de CI/CD geralmente recebem contas de serviço altamente privilegiadas para gerenciar a infraestrutura e implantar artefatos. Se um invasor comprometer o sistema de CI/CD, ele poderá usar a conta de serviço do pipeline para realizar ações destrutivas no Cloud Storage. Um exemplo de comprometimento é um invasor injetar código malicioso em um script de build ou conseguir acesso ao orquestrador. Esse comprometimento pode envolver a exclusão de buckets ou a substituição de objetos críticos.
| Categoria STRIDE |
Adulteração |
| Tática do MITRE ATT&CK |
Impacto |
| Manifestações |
Etapa de build maliciosa:um invasor adiciona uma etapa a um pipeline de CI/CD que apaga todos os dados. Por exemplo, o invasor adiciona uma etapa em cloudbuild.yaml que executa um comando como gcloud storage rm -r gs://critical-bucket/. Herança de privilégios:o invasor usa a conta de serviço do pipeline comprometido, que tem permissões amplas, para conceder à própria conta acesso administrativo aos buckets do Cloud Storage para uso posterior.
|
| Mitigações |
Aplique o princípio de privilégio mínimo às contas de serviço de CI/CD. Por exemplo, não atribua a um pipeline de build permissões para excluir buckets de produção. Use identidades separadas para diferentes estágios do pipeline, como build, teste ou implantação. Proteja os buckets críticos do Cloud Storage contra exclusão ativando o bloqueio de bucket ou de objeto ou garantindo que a conta de serviço de CI/CD não tenha a permissão storage.buckets.delete.
|
Exclusão não autorizada de buckets usando contas de implantação forçada com privilégios excessivos
As contas de implantação forçada ou de acesso emergencial são identidades altamente privilegiadas usadas apenas em emergências. Se essas contas não forem protegidas e governadas adequadamente (por exemplo, se as credenciais forem vazadas ou o acesso não for limitado por tempo), um invasor que comprometer uma conta de emergência poderá realizar ações altamente destrutivas. Um risco principal é a exclusão de buckets inteiros do Cloud Storage, o que pode levar a uma perda de dados catastrófica e irreversível, já que a exclusão de buckets é uma ação permanente.
| Categoria STRIDE |
Elevação de privilégios |
| Tática do MITRE ATT&CK |
Escalonamento de privilégios |
| Manifestações |
Perda catastrófica de dados:um invasor compromete uma conta de emergência mal gerenciada e executa um script para excluir todos os buckets do Cloud Storage em um projeto. Extorsão:um invasor ganha acesso e ameaça excluir buckets críticos, a menos que um resgate seja pago.
|
| Mitigações |
Implemente o acesso just-in-time (JIT) para procedimentos de implantação forçada em vez de usar contas com privilégios permanentes. Conceda permissões sob demanda por um tempo limitado e para uma finalidade específica. Aplique um bloqueio de bucket a buckets que contenham objetos críticos ou um bloqueio de objeto a objetos individuais. Os bloqueios impedem a exclusão do bucket e dos objetos dele, mesmo por usuários com permissões de proprietário, por um período de armazenamento especificado.
|
Exfiltração silenciosa de dados usando coletores de registros comprometidos que gravam no Cloud Storage
O Cloud Logging pode ser configurado para exportar registros para um bucket do Cloud Storage. Se um invasor conseguir permissões para modificar um coletor de registros, ele poderá reconfigurá-lo para exportar registros sensíveis para um bucket do Cloud Storage controlado por ele em outro projeto. A exportação de registros sensíveis permite que um invasor exfiltre dados sensíveis capturados em registros de forma silenciosa e contínua.
| Categoria STRIDE |
Divulgação de informações |
| Tática do MITRE ATT&CK |
Exfiltração |
| Manifestações |
Redirecionamento de coletor de registros:um invasor modifica a propriedade de destino de um coletor de registros para apontar para o próprio bucket do Cloud Storage. Criação de filtros maliciosos:um invasor cria um coletor com um filtro que segmenta especificamente registros que contêm informações sensíveis (por exemplo, PII ou tokens) e os exporta.
|
| Mitigações |
Monitore os registros de auditoria do Cloud para chamadas de API CreateSink e UpdateSink. Configure alertas para notificar as equipes de segurança sobre novos ou modificados coletores de registros e garantir que eles estejam autorizados. Configure um perímetro do VPC Service Controls para reduzir a exfiltração de dados.
|
Habilitação de ransomware usando a revogação centralizada de CMEK
Quando os intervalos do Cloud Storage são criptografados com CMEK, a disponibilidade dos dados fica vinculada à disponibilidade da chave. Um invasor que conseguir permissões suficientes no Cloud KMS pode destruir ou desativar a chave usada em um bucket crítico do Cloud Storage. Essa ação torna todos os dados no bucket criptograficamente inacessíveis, o que é uma forma de destruição de dados ou ransomware, já que os dados permanecem, mas não podem ser descriptografados.
| Categoria STRIDE |
Adulteração |
| Tática do MITRE ATT&CK |
Impacto |
| Manifestações |
Destruição de chaves:um invasor com a permissão cloudkms.cryptoKeyVersions.destroy destrói permanentemente uma versão de chave, impossibilitando a recuperação de dados. Desativação da chave:um invasor com a permissão cloudkms.cryptoKeyVersions.disable desativa uma chave, tornando os dados do Cloud Storage ilegíveis até que ela seja reativada. Essa ação pode causar uma interrupção prolongada.
|
| Mitigações |
Imponha uma duração mínima para o estado "Programado para destruição" antes que as chaves do Cloud KMS possam ser destruídas. Por padrão, esse período é de 30 dias, mas você pode configurar um período de 1 a 120 dias quando uma chave é criada pela primeira vez. Não é possível modificar esse período depois que uma chave é excluída. Considere aplicar a restrição de política da organização constraints/cloudkms.minimumDestroyScheduledDuration para garantir que as chaves não possam ser criadas com um período programado para destruição menor que o mínimo esperado. Limite estritamente o acesso aos papéis administrativos do Cloud KMS. Separe as funções de uso de chaves da administração de chaves para evitar que uma única conta violada use e destrua chaves. Faça a rotação periódica das chaves do Cloud KMS, escolhendo um período de rotação com base nos requisitos de sensibilidade ou compliance da sua carga de trabalho.
|
Exfiltração de dados usando exportações de snapshots ou backups para o Cloud Storage
Muitos serviços do Google Cloud (por exemplo, Compute Engine ou Cloud SQL) permitem criar snapshots ou exportar backups para o Cloud Storage. Um invasor com permissões para realizar essas operações de exportação pode criar um snapshot de um recurso que contém dados sensíveis e salvar o snapshot em um bucket do Cloud Storage com permissões flexíveis, como um bucket público ou compartilhado com uma conta externa. Essa ação ignora os controles de acesso mais restritos do recurso principal (por exemplo, credenciais do banco de dados), já que os dados agora podem ser acessados usando o IAM do Cloud Storage.
| Categoria STRIDE |
Divulgação de informações |
| Tática do MITRE ATT&CK |
Exfiltração |
| Manifestações |
Snapshot de disco para bucket público:um desenvolvedor interno com permissões compute.snapshots.create e storage.objectAdmin cria um snapshot de um disco de VM que contém secrets e o exporta para um bucket público do Cloud Storage. Exportação de banco de dados:um invasor com permissão cloudsql.instances.export exporta um banco de dados de produção para um bucket do Cloud Storage em um projeto controlado por ele.
|
| Mitigações |
Verifique se os projetos designados para backups e snapshots têm políticas do IAM e do VPC Service Controls que são pelo menos tão rigorosas quanto as dos projetos de origem para manter uma postura de segurança consistente. Considere uma estratégia de classificação de dados em que você configura tags de recursos em buckets usados para backups e adiciona condições de acesso com base em tags do IAM para restringir ainda mais o acesso.
|
