Validação de dados e deteção de alterações

O Cloud Storage recomenda que valide os dados que transfere para e dos seus contentores. Esta página descreve as práticas recomendadas para realizar validações através de somas de verificação CRC32C ou MD5 e descreve o algoritmo de deteção de alterações usado pelo comando gcloud storage rsync.

Proteja contra danos nos dados através da utilização de hashes

Existem várias formas de os dados serem danificados durante o carregamento ou a transferência a partir da nuvem:

  • Erros de memória em computadores cliente ou servidor, ou routers ao longo do caminho
  • Erros de software (por exemplo, numa biblioteca que os clientes usam)
  • Alterações ao ficheiro de origem quando ocorre um carregamento durante um período prolongado

O Cloud Storage suporta dois tipos de hashes que pode usar para verificar a integridade dos seus dados: CRC32C e MD5. O CRC32C é o método de validação recomendado para realizar verificações de integridade. Os clientes que preferem o MD5 podem usar esse hash, mas os hashes MD5 não são suportados para todos os objetos.

Validação por parte do cliente

Pode fazer uma verificação de integridade dos dados transferidos através da aplicação de hash aos dados em tempo real e da comparação dos resultados com as somas de verificação fornecidas pelo servidor. No entanto, tenha em atenção que as somas de verificação fornecidas pelo servidor baseiam-se no objeto completo tal como está armazenado no Cloud Storage, o que significa que os seguintes tipos de transferências não podem ser validados através dos hashes fornecidos pelo servidor:

  • Transferências que são submetidas a transcodificação descompressiva, porque a soma de verificação fornecida pelo servidor representa o objeto no respetivo estado comprimido, enquanto os dados publicados têm a compressão removida e, consequentemente, um valor de hash diferente.

  • Uma resposta que contém apenas uma parte dos dados do objeto, que ocorre quando faz um pedido range. O Cloud Storage recomenda a utilização de pedidos de intervalo apenas para reiniciar a transferência de um objeto completo após o último desvio recebido, porque, nesse caso, pode calcular e validar a soma de verificação quando a transferência completa estiver concluída.

Nos casos em que pode validar a transferência através de somas de verificação, deve rejeitar os dados transferidos com valores de hash incorretos e usar a lógica de repetição recomendada para repetir o pedido.

Validação do lado do servidor

O Cloud Storage executa a validação do lado do servidor nos seguintes casos:

  • Quando faz um pedido de cópia ou reescrita no Cloud Storage.

  • Quando fornece o hash MD5 ou CRC32C esperado de um objeto num pedido de carregamento. O Cloud Storage só cria o objeto se o hash que fornecer corresponder ao valor calculado pelo Cloud Storage. Se não corresponder, o pedido é rejeitado com um erro BadRequestException: 400.

    • Em pedidos de API JSON aplicáveis, fornece somas de verificação como parte do recurso objects.

    • Em pedidos de API XML aplicáveis, fornece somas de verificação através do cabeçalho x-goog-hash. A API XML também aceita o cabeçalho Content-MD5 HTTP padrão (consulte a especificação).

    • Em alternativa, pode realizar a validação do lado do cliente dos seus carregamentos emitindo um pedido dos metadados do objeto carregado, comparando o valor hash do objeto carregado com o valor esperado e eliminando o objeto em caso de incompatibilidade. Este método é útil se o hash MD5 ou CRC32C do objeto não for conhecido no início do carregamento.

No caso de carregamentos compostos paralelos, os utilizadores devem realizar uma verificação de integridade para cada carregamento de componentes e, em seguida, usar pré-condições com os respetivos pedidos de composição para se protegerem contra condições de concorrência. As solicitações de composição não realizam a validação do lado do servidor, pelo que os utilizadores que pretendem uma verificação de integridade completa devem realizar a validação do lado do cliente no novo objeto composto.

Validação da CLI do Google Cloud

Para a CLI do Google Cloud, os dados copiados para ou a partir de um contentor do Cloud Storage são validados. Isto aplica-se aos comandos cp, mv e rsync. Se a soma de verificação dos dados de origem não corresponder à soma de verificação dos dados de destino, a CLI gcloud elimina a cópia inválida e imprime uma mensagem de aviso. Isto acontece muito raramente. Se for o caso, deve tentar novamente a operação.

Esta validação automática ocorre depois de o objeto em si ser finalizado, pelo que os objetos inválidos ficam visíveis durante 1 a 3 segundos antes de serem identificados e eliminados. Além disso, existe a possibilidade de a CLI gcloud ser interrompida após a conclusão do carregamento, mas antes de realizar a validação, o que deixa o objeto inválido no lugar. Pode evitar estes problemas quando carregar ficheiros únicos para o Cloud Storage usando a validação do lado do servidor, que ocorre quando usa a flag --content-md5.

Deteção de alterações para rsync

O comando gcloud storage rsync também pode usar somas de verificação MD5 ou CRC32C para determinar se existe uma diferença entre a versão de um objeto encontrado na origem e a versão encontrada no destino. O comando compara as somas de verificação nos seguintes casos:

  • A origem e o destino são ambos contentores na nuvem e o objeto tem uma soma de verificação MD5 ou CRC32C em ambos os contentores.

  • O objeto não tem uma data/hora de modificação do ficheiro (mtime) na origem nem no destino.

Nos casos em que o objeto relevante tem um valor mtime na origem e no destino, como quando a origem e o destino são sistemas de ficheiros, o comando rsync compara o tamanho e o mtime dos objetos, em vez de usar somas de verificação. Da mesma forma, se a origem for um contentor na nuvem e o destino for um sistema de ficheiros local, o comando rsync usa a hora de criação do objeto de origem como substituto de mtime e o comando não usa somas de verificação.

Se nem mtime nem as somas de verificação estiverem disponíveis, rsync só compara os tamanhos dos ficheiros quando determina se existe uma alteração entre a versão de origem de um objeto e a versão de destino. Por exemplo, nem mtime nem as somas de verificação estão disponíveis quando compara objetos compostos com objetos num fornecedor de nuvem que não suporta CRC32C, porque os objetos compostos não têm somas de verificação MD5.

O que se segue?