Object Storage Service:Prevent file overwrites

• Gravações simultâneas e regras de impedimento de substituição: Em cenários de alta concorrência, como quando vários clientes gravam em um caminho inexistente ou uma gravação ocorre durante uma exclusão, o sistema pode não encontrar um arquivo existente para substituir. Nesses casos, a operação de gravação é permitida. No entanto, após a criação bem-sucedida do arquivo, a regra bloqueia quaisquer tentativas subsequentes de substituí-lo.

• Limitações na transição de classe de armazenamento: Quando o recurso File overwrite prohibited está ativado, não é possível usar métodos do lado do cliente, como o console do OSS, SDKs ou ossutil, para chamar a operação CopyObject e alterar a classe de armazenamento de um objeto (por exemplo, de Standard para Archive). Para alterar a classe de armazenamento de objetos protegidos, utilize regras de ciclo de vida para transições automáticas.

• Compatibilidade do recurso: O recurso File overwrite prohibited bloqueia apenas as file overwrite operations do lado do cliente. Ele não afeta funções de sistema em segundo plano, como replicação entre regiões (CRR) ou regras de ciclo de vida.

• Conflito com versionamento: O recurso File overwrite prohibited é mutuamente exclusivo com o versionamento. Se o versionamento estiver ativado ou suspenso para um bucket, quaisquer regras de impedimento de substituição serão ignoradas.

Como funciona

Quando o OSS recebe uma solicitação para substituir um arquivo, o sistema avalia a requisição em relação às regras de impedimento de substituição configuradas, seguindo a ordem de criação:

1. Correspondência de regras: O sistema verifica se o caminho do arquivo corresponde às condições de prefixo e sufixo de uma regra e se a identidade do usuário corresponde à configuração de Authorized User.

2. Decisão: O OSS bloqueia a substituição e retorna um erro FileAlreadyExists somente se todas as condições de uma regra (prefixo, sufixo e identidade do usuário) forem atendidas.

3. Comportamento padrão: Caso uma solicitação não corresponda a nenhuma regra de impedimento de substituição, a substituição será permitida.

Proteger tipos específicos de arquivos

Proteja arquivos de configuração e de log no seu ambiente de produção contra substituições acidentais por usuários específicos.

1. Na página Buckets, clique em nome do bucket desejado.

2. No painel de navegação à esquerda, escolha Data Management > File overwrite prohibited.

3. Clique em New rule added to prohibit overwrite writes e configure os seguintes parâmetros:

   • Rule ID: Insira um ID personalizado ou deixe em branco para gerar um automaticamente.

   • File name prefix: Insira o caminho do diretório a ser protegido, como production/configs/.

   • File name extension: Insira a extensão de arquivo a ser protegida, como .json.

   • Authorized User: Especifique os usuários RAM, funções RAM ou outras contas a serem restringidas.

   • Clique em OK para crie a regra.

   • Verifique a regra:

     • Com uma conta restrita, tente fazer upload de um arquivo com o mesmo nome para production/configs/app.json.

     • Confirme se o sistema retornou um erro FileAlreadyExists.

     • Valide que outros usuários conseguem fazer upload de arquivos normalmente e que uploads para caminhos fora das condições de prefixo e sufixo são concluídos com sucesso.

   Definir uma política de proteção global

   Estabeleça uma proteção abrangente para dados críticos de negócios e evite modificações acidentais por qualquer usuário.

   1. Na página Buckets, clique em nome do bucket desejado.

   2. No painel de navegação à esquerda, escolha Data Management > File overwrite prohibited.

   3. Clique em New rule added to prohibit overwrite writes e configure os seguintes parâmetros:

      • Rule ID: Insira um ID personalizado ou deixe em branco para gerar um automaticamente.

      • File name prefix: critical-data/

      • File name extension: Deixe este campo em branco para proteger todos os arquivos no caminho especificado.

      • Authorized User: * (todas as contas)

      • Clique em OK para crie a regra.

      • Verifique a proteção global:

        • Com qualquer conta, tente substituir critical-data/database.sql.

        • Confirme se o sistema retornou um erro FileAlreadyExists, o que indica que a proteção global está ativa.

        • Valide que arquivos em outros caminhos, como public-data/, ainda podem ser substituídos.

      Regras de correspondência

      • Quantidade de regras: Um único bucket pode ter no máximo 100 regras.

      • Comprimento de caracteres: O comprimento máximo para um prefixo ou sufixo é de 1.023 caracteres.

      • Correspondência de prefixo e sufixo: Há suporte apenas para correspondência exata de strings. Expressões regulares e curingas não são aceitos. O OSS trata uma entrada como logs/ como caracteres literais.

      • Correspondência de prefixo: O prefixo logs/ corresponde a logs/app.log, mas não corresponde a dev-logs/app.log.

      • Correspondência de sufixo: O sufixo .txt corresponde a readme.txt, mas não corresponde a readme.TXT (diferencia maiúsculas de minúsculas) nem a readme.txt.bak.

      • Correspondência de Authorized User: Há suporte para o caractere curinga asterisco (*). Para detalhes de configuração, consulte o elemento Principal em Common examples of a bucket policy.

      • Lógica de condições: O OSS bloqueia a substituição somente se todas as condições de uma regra (prefixo, sufixo e Authorized User) forem atendidas.

      • Rule ID: Este parâmetro é opcional. Se você deixar este campo em branco, o OSS gera automaticamente um identificador universalmente único (UUID). Caso forneça um ID, ele deve ser exclusivo dentro do bucket.

      Operações de substituição de arquivos

      Este recurso bloqueia as seguintes operações de substituição de arquivos do lado do cliente:

      • PutObject

      • PostObject

      • CopyObject

      • PutObjectSymlink

      • InitiateMultipartUpload

      • CompleteMultipartUpload

      Perguntas frequentes

      Por que o proprietário do bucket não consegue substituir arquivos?

      Esse é o comportamento esperado. Um campo Authorized User em branco aplica a regra a todos os usuários, incluindo o proprietário do bucket e a conta raiz. Para restaurar as permissões de substituição, você pode:

      • Exclua a regra no console.

      • Modifique o prefixo ou sufixo da regra para reduzir seu escopo.

      • Defina o Authorized User para contas específicas e restringir apenas esses usuários.

      Por que o prefixo logs/*.txt não funciona?

      O OSS não aceita curingas para correspondência de prefixo e sufixo. O caractere * é tratado como um caractere literal, e o sistema realiza uma correspondência exata para um arquivo chamado logs/*.txt. O método correto é:

      • Defina o prefixo como logs/

      • Defina o sufixo como .txt

      Isso corresponde a todos os arquivos no diretório logs/ que terminam com .txt.

      O que acontece com campos de prefixo e sufixo em branco?

      Quando tanto o prefixo quanto o sufixo são deixados em branco, a regra se aplica a todo o bucket. Isso significa:

      • Se o campo Authorized User também estiver em branco, todos os usuários serão impedidos de substituir qualquer arquivo no bucket.

      • Se o campo Authorized User especificar determinadas contas, apenas esses usuários terão a restrição de substituição de arquivos no bucket.

      Por que algumas operações de gravação não são bloqueadas?

      Uma regra de impedimento de substituição bloqueia apenas operações de gravação em arquivos que já existem. Durante gravações simultâneas, como quando vários clientes gravam em um caminho inexistente ou quando uma gravação é iniciada durante uma exclusão, o sistema pode não encontrar um arquivo existente para substituir. Nessas condições de corrida, a operação de gravação prossegue. Isso não significa que a regra falhou. Após a criação do arquivo, a regra bloqueará quaisquer tentativas subsequentes de substituí-lo. Além disso, a regra não pode bloquear uma operação que não esteja na lista de file overwrite operations.