Automatizar a verificação de malware para arquivos enviados para o Cloud Storage

Last reviewed 2023-04-19 UTC

---

Neste tutorial, você aprenderá a criar um pipeline baseado em eventos para automatizar a verificação de códigos maliciosos em arquivos.

Na maioria dos apps, a avaliação manual da grande quantidade de arquivos enviados ao Cloud Storage é muito demorada.

Para criar esse pipeline, são usados os produtos do Google Cloud, além de um antivírus de código aberto chamado ClamAV (em inglês). Para este tutorial, o ClamAV é executado em um contêiner do Docker hospedado no Cloud Run. O pipeline também grava entradas de registro no Cloud Logging e grava métricas no Cloud Monitoring.

Observação: o ClamAV é usado neste tutorial, mas é possível utilizar qualquer outro antivírus que execute verificações sob demanda nos contêineres Linux.

É possível acionar alertas baseados em registros para arquivos infectados usando as entradas de registro do Logging. No entanto, a configuração desses alertas não é abordada neste tutorial.

O termo malware usado aqui descreve diversas ameaças, como cavalos de Tróia, vírus e outros códigos maliciosos.

Neste tutorial, presumimos que você conheça a funcionalidade básica do Cloud Storage, Cloud Run, Cloud Scheduler Eventarc, Docker e Node.js.

Arquitetura

Veja no diagrama a seguir uma visão geral da arquitetura.

Há dois pipelines gerenciados por essa arquitetura:

• Pipeline de verificação de arquivos, que verifica se um arquivo enviado contém malware.
• Pipeline de atualização do espelhamento de banco de dados de malware do ClamAV, que mantém um espelho atualizado do banco de dados de malware usado pelo ClamAV.

Pipeline de verificação de arquivos

O pipeline de verificação de arquivos funciona da seguinte maneira:

1. Os usuários finais fazem upload dos próprios arquivos para o bucket não verificado do Cloud Storage.
2. O serviço Eventarc captura esse evento de upload e informa o serviço do Cloud Run sobre esse novo arquivo.
3. O serviço do Cloud Run faz o download do novo arquivo do bucket não verificado do Cloud Storage e o transmite para o verificador de malware ClamAV.
4. Dependendo do resultado da verificação de malware, o serviço realiza uma das seguintes ações:
   • Se o ClamAV declarar que o arquivo está limpo, ele será movido do bucket não verificado do Cloud Storage para o bucket limpo.
   • Se o ClamAV declarar que o arquivo contém malware, ele será movido do bucket não verificado do Cloud Storage para o bucket colocado em quarentena.
5. O serviço informa o resultado dessas ações ao Logging e ao Monitoring para permitir que os administradores realizem ações.

Pipeline de atualização do espelhamento de banco de dados ClamAV Malware

Para fazer uma verificação com eficácia, o verificador de malware ClamAV precisa manter um banco de dados atualizado de assinaturas de malware.

O ClamAV é executado usando o Cloud Run, que é sem estado. Na inicialização de uma instância do serviço, o ClamAV sempre precisa fazer o download do banco de dados de malware completo mais recente, que tem centenas de megabytes.

O banco de dados público de malware do ClamAV está hospedado em uma rede de distribuição de conteúdo (CDN) que limita a taxa desses downloads. Se várias instâncias forem iniciadas e tentarem fazer o download do banco de dados completo, a limitação de taxa poderá ser acionada. Isso faz com que o endereço IP externo usado pelo Cloud Run seja bloqueado por 24 horas. Isso impede que o serviço ClamAV seja iniciado e não faça o download das atualizações do banco de dados de malware.

Além disso, o Cloud Run usa um pool compartilhado de endereços IP externos. Como resultado, os downloads de instâncias de verificação de malware de diferentes projetos são vistos pela CDN como provenientes de um único endereço e também acionam o bloco.

Esse pipeline mantém um espelho local particular atualizado do banco de dados no Cloud Storage. Isso garante que o banco de dados público do ClamAV seja acessado apenas uma vez por atualização para fazer o download dos arquivos menores de atualizações diferenciais, e não do banco de dados completo. Isso evita limitações de taxa.

Esse pipeline funciona da seguinte maneira:

1. Um job do Cloud Scheduler está configurado para acionar a cada duas horas, o mesmo que o intervalo de verificação de atualização padrão usado pelo serviço de atualização do ClamAV. Esse job faz uma solicitação HTTP POST para o serviço do Cloud Run instruindo-o a atualizar o espelho do banco de dados do malware.
2. A instância do Cloud Run copia o espelho de banco de dados de malware do bucket do Cloud Storage para o sistema de arquivos local.
3. Em seguida, a instância executa a ferramenta ClamAV CVDUpdate, que faz o download de todas as atualizações diferenciais disponíveis e as aplica ao espelho do banco de dados.
4. Em seguida, ele copia o espelho atualizado do banco de dados de malware para o bucket do Cloud Storage.

O serviço ClamAVFreshclam em execução na instância do Cloud Run fará o download do banco de dados de malware do Cloud Storage na inicialização e também verificará e fará o download de todas as atualizações de banco de dados disponíveis de do bucket do Cloud Storage durante o tempo de execução.

Objetivos

• Criar um espelho do banco de dados de definições de malware do ClamAV em um bucket do Cloud Storage.

• Crie um serviço do Cloud Run com as seguintes funções:

  • Como verificar se há malware em um bucket do Cloud Storage usando ClamAV e mover os arquivos verificados para buckets limpos ou em quarentena com base no resultado da verificação.
  • Manter um espelho do banco de dados de definições de malware ClamAV no Cloud Storage.

• Crie um gatilho do Eventarc para acionar o serviço de verificação de malware quando um arquivo for enviado ao Cloud Storage.

• Crie um job do Cloud Scheduler para acionar o serviço de verificação de malware para atualizar o espelho do banco de dados de definições de malware no Cloud Storage.

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

• Cloud Storage
• Cloud Run
• Eventarc

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.

Antes de começar

1. Faça login na sua conta do Google Cloud. Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho de nossos produtos em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.

2. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

   Observação: se você não pretende manter os recursos criados neste procedimento, crie um projeto novo em vez de selecionar um que já existe. Depois de concluir essas etapas, é possível excluir o projeto. Para fazer isso, basta remover todos os recursos associados a ele.

   Acessar o seletor de projetos

3. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

4. Ative as APIs Artifact Registry, Cloud Run, Eventarc, Logging, Cloud Scheduler, Pub/Sub, and Cloud Build.

   Ative as APIs

5. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

   Observação: se você não pretende manter os recursos criados neste procedimento, crie um projeto novo em vez de selecionar um que já existe. Depois de concluir essas etapas, é possível excluir o projeto. Para fazer isso, basta remover todos os recursos associados a ele.

   Acessar o seletor de projetos

6. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

7. Ative as APIs Artifact Registry, Cloud Run, Eventarc, Logging, Cloud Scheduler, Pub/Sub, and Cloud Build.

   Ative as APIs

8. No Console do Google Cloud, ative o Cloud Shell.

   Ativar o Cloud Shell

   Na parte inferior do Console do Google Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a CLI do Google Cloud já instalada e com valores já definidos para o projeto atual. A inicialização da sessão pode levar alguns segundos.

Neste tutorial, todos os comandos serão executados no Cloud Shell.

Configurar o ambiente

Nesta seção, você atribui configurações aos valores usados no tutorial, como região e zona. Neste tutorial, você usa us-central1 como a região do serviço do Cloud Run e us como o local do gatilho do Eventarc e dos buckets do Cloud Storage.

1. No Cloud Shell, defina variáveis comuns do shell, incluindo região e local:

   REGION=us-central1
   LOCATION=us
   PROJECT_ID=PROJECT_ID
   SERVICE_NAME="malware-scanner"
   SERVICE_ACCOUNT="${SERVICE_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"
   

   Defina PROJECT_ID como o ID do projeto.

2. Inicialize o ambiente gcloud com o ID do projeto:

   gcloud config set project "${PROJECT_ID}"
   

3. Crie três buckets do Cloud Storage com nomes exclusivos:

   gsutil mb -l "${LOCATION}" "gs://unscanned-${PROJECT_ID}"
   gsutil mb -l "${LOCATION}" "gs://quarantined-${PROJECT_ID}"
   gsutil mb -l "${LOCATION}" "gs://clean-${PROJECT_ID}"
   

   ${PROJECT_ID} é usado para garantir que os nomes dos buckets sejam exclusivos.

   Esses três buckets armazenam os arquivos enviados em vários estágios durante o pipeline de verificação de arquivos:

   • unscanned-PROJECT_ID: armazena os arquivos antes da verificação. Seus usuários fazem upload dos arquivos para esse bucket.

   • quarantined-PROJECT_ID: armazena os arquivos que o serviço de verificação de malware verificou e contêm malware.

   • clean-PROJECT_ID: armazena os arquivos que o serviço de verificação de malware verificou e não estão infectados.

4. Crie um quarto bucket do Cloud Storage:

   gsutil mb -l "${LOCATION}" "gs://cvd-mirror-${PROJECT_ID}"
   

   ${PROJECT_ID} é usado para garantir que o nome do bucket seja exclusivo.

   Esse bucket cvd-mirror-PROJECT_ID é usado para manter um espelho local do banco de dados de definições de malware, o que impede que a limitação de taxa seja acionada pela CDN do ClamAV.

Criar uma conta de serviço para o serviço de verificação de malware e conceder permissões

Nesta seção, você cria uma conta de serviço para usar no serviço de verificação de malware e concede os papéis apropriados à conta de serviço para que ela tenha permissões para ler e gravar nos buckets do Cloud Storage. Isso garante que a conta tenha permissões mínimas e acesso apenas aos recursos necessários.

1. Crie a conta de serviço malware-scanner:

   gcloud iam service-accounts create ${SERVICE_NAME}
   

2. Conceda o papel Administrador de objetos aos buckets, permitindo que o serviço leia e exclua documentos do bucket não verificado e grave arquivos nos buckets em quarentena e limpos.

   gsutil iam ch \
       "serviceAccount:${SERVICE_ACCOUNT}:objectAdmin" \
       "gs://unscanned-${PROJECT_ID}"
   gsutil iam ch \
       "serviceAccount:${SERVICE_ACCOUNT}:objectAdmin" \
       "gs://clean-${PROJECT_ID}"
   gsutil iam ch \
       "serviceAccount:${SERVICE_ACCOUNT}:objectAdmin" \
       "gs://quarantined-${PROJECT_ID}"
   gsutil iam ch \
       "serviceAccount:${SERVICE_ACCOUNT}:objectAdmin" \
       "gs://cvd-mirror-${PROJECT_ID}"
   

3. Conceda o papel de gravador de métricas permitindo que o serviço grave métricas no Monitoring:

   gcloud projects add-iam-policy-binding \
         "${PROJECT_ID}" \
         --member="serviceAccount:${SERVICE_ACCOUNT}" \
         --role=roles/monitoring.metricWriter
   

Criar o serviço de verificação de malware no Cloud Run

Nesta seção, você implantará o serviço de verificação de malware no Cloud Run. O serviço é executado em um contêiner do Docker e contém o seguinte:

• Um Dockerfile para criar uma imagem de contêiner com o serviço, o ambiente de execução do Node.js, o SDK do GCloud e os binários do ClamAV.
• Os arquivos Node.js do serviço Cloud Run de verificação de malware.
• config.json para especificar os nomes de buckets do Cloud Storage.
• updateCvdMirror.sh para atualizar o espelho do banco de dados de definições de malware do ClamAV no Cloud Storage.
• Serviço cloud-run-proxy para fazer proxy de solicitações HTTP freshclam, que fornecem acesso autenticado às APIs Cloud Storage.
• bootstrap.sh para executar os serviços necessários na inicialização da instância.

1. No Cloud Shell, clone o repositório do GitHub que contém os arquivos de código:

   git clone https://github.com/GoogleCloudPlatform/docker-clamav-malware-scanner.git
   

2. Altere para o diretório cloudrun-malware-scanner:

   cd docker-clamav-malware-scanner/cloudrun-malware-scanner
   

3. Edite o arquivo de configuração config.json para especificar os buckets do Cloud Storage que você acabou de criar. Como são baseados no ID do projeto, é possível usar uma pesquisa e uma substituição simples:

   sed "s/-bucket-name/-${PROJECT_ID}/" config.json.tmpl > config.json
   

   Você pode ver o arquivo de configuração atualizado:

   cat config.json
   

4. Execute um preenchimento inicial do espelho do banco de dados de malware ClamAV no Cloud Storage:

   python3 -m venv pyenv
   . pyenv/bin/activate
   pip3 install crcmod cvdupdate
   ./updateCvdMirror.sh "cvd-mirror-${PROJECT_ID}"
   deactivate
   

   Isso executa uma instalação local da ferramenta CVDUpdate, usa para fazer o download do banco de dados de malware e, em seguida, faz upload dele para o bucket cvd-mirror do Cloud Storage criado anteriormente.

   É possível verificar o conteúdo do espelho:

   gsutil ls "gs://cvd-mirror-${PROJECT_ID}/cvds"
   

   O bucket precisa conter vários arquivos CVD, incluindo o banco de dados completo de malware, vários arquivos .cdiff contendo as atualizações diferenciais diárias e dois arquivos .json com informações de configuração e estado.

5. Crie e implante o serviço do Cloud Run usando a conta de serviço criada anteriormente:

   gcloud beta run deploy "${SERVICE_NAME}" \
     --source . \
     --region "${REGION}" \
     --no-allow-unauthenticated \
     --memory 4Gi \
     --cpu 1 \
     --concurrency 20 \
     --min-instances 1 \
     --max-instances 5 \
     --no-cpu-throttling \
     --cpu-boost \
     --service-account="${SERVICE_ACCOUNT}"
   

   Isso cria uma instância do Cloud Run que tem 1 vCPU e usa 4 GiB de RAM. Embora esse seja um tamanho aceitável para este tutorial, em um ambiente de produção, é recomendável escolher uma CPU e um tamanho de memória maiores para a instância e um --max-instances maior dependendo do volume de tráfego que o serviço precisa processar.

   O parâmetro --concurrency especifica o número de solicitações simultâneas que cada instância pode processar.

   O parâmetro --no-cpu-throttling permite que a instância execute operações em segundo plano, como atualizar definições de malware.

   O parâmetro --cpu-boost dobra o número de vCPUs na inicialização da instância para reduzir a latência.

   O parâmetro --min-instances 1 mantém pelo menos uma instância ativa, já que o tempo de inicialização de cada instância é relativamente alto.

   O parâmetro --max-instances 5 impede que o serviço seja escalonado verticalmente em demasia.

6. Quando solicitado, digite Y.

A criação e a implantação levam cerca de 10 minutos. Após a conclusão, uma mensagem será exibida:

Service [malware-scanner] revision [malware-scanner-NNNNN-XXX] has been deployed and is serving 100 percent of traffic.
Service URL: https://malware-scanner-XXXXXXXX-XX.a.run.app

Armazene o valor Service URL da saída do comando de implantação em uma variável de shell. Isso será usado mais tarde ao criar um job do Cloud Scheduler:

SERVICE_URL="SERVICE_URL"

O serviço do Cloud Run requer que todas as invocações sejam autenticadas e as identidades de autenticação precisam ter a permissão run.routes.invoke sobre o serviço.

Verifique o serviço em execução e a versão do ClamAV executando o seguinte comando:

curl -D - -H "Authorization: Bearer $(gcloud auth print-identity-token)"  \
     ${SERVICE_URL}

Criar um gatilho do Eventarc no Cloud Storage

Nesta seção, você adicionará permissões para permitir que o Eventarc capture eventos do Cloud Storage e um gatilho para enviar esses eventos para o serviço malware-scanner do Cloud Run.

1. Se você estiver usando um projeto criado antes de 8 de abril de 2021, configure o Pub/Sub para notificações push.

2. No Cloud Shell, conceda o papel roles/pubsub.publisher à conta de serviço do Cloud Storage:

   STORAGE_SERVICE_ACCOUNT=$(gsutil kms serviceaccount -p "${PROJECT_ID}")
   
   gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
     --member "serviceAccount:${STORAGE_SERVICE_ACCOUNT}" \
     --role "roles/pubsub.publisher"
   

3. Permita que a conta de serviço malware-scanner invoque o serviço do Cloud Run e atue como um receptor de eventos do Eventarc:

   gcloud run services add-iam-policy-binding "${SERVICE_NAME}" \
     --region="${REGION}" \
     --member "serviceAccount:${SERVICE_ACCOUNT}" \
     --role roles/run.invoker
   gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
     --member "serviceAccount:${SERVICE_ACCOUNT}" \
     --role "roles/eventarc.eventReceiver"
   

4. Crie um gatilho do Eventarc para capturar o evento do objeto finalizado no bucket do Cloud Storage não verificado e enviá-lo ao serviço do Cloud Run. O gatilho usará a conta de serviço malware-scanner para autenticação:

   BUCKET_NAME="unscanned-${PROJECT_ID}"
   gcloud eventarc triggers create "trigger-${BUCKET_NAME}-${SERVICE_NAME}" \
     --destination-run-service="${SERVICE_NAME}" \
     --destination-run-region="${REGION}" \
     --location="${LOCATION}" \
     --event-filters="type=google.cloud.storage.object.v1.finalized" \
     --event-filters="bucket=${BUCKET_NAME}" \
     --service-account="${SERVICE_ACCOUNT}"
   

   Se você receber um dos dois erros a seguir, aguarde um minuto e execute o comando novamente:

   ERROR: (gcloud.eventarc.triggers.create) INVALID_ARGUMENT: The request was invalid: Bucket "unscanned-PROJECT_ID" was not found. Please verify that the bucket exists.

   ERROR: (gcloud.eventarc.triggers.create) FAILED_PRECONDITION: Invalid resource state for "": Permission denied while using the Eventarc Service Agent. If you recently started to use Eventarc, it may take a few minutes before all necessary permissions are propagated to the Service Agent. Otherwise, verify that it has Eventarc Service Agent role.

5. Altere o prazo de confirmação da mensagem para dois minutos na assinatura do Pub/Sub usada pelo gatilho do Eventarc:

   SUBSCRIPTION_NAME=$(gcloud eventarc triggers describe \
       "trigger-${BUCKET_NAME}-${SERVICE_NAME}" \
       --location="${LOCATION}" \
       --format="get(transport.pubsub.subscription)")
   gcloud pubsub subscriptions update "${SUBSCRIPTION_NAME}" --ack-deadline=120
   

   O valor padrão de dez segundos é muito curto para arquivos grandes ou com muitas cargas.

Observação: O gatilho é criado imediatamente, mas pode levar até 10 minutos para que ele seja propagado e filtre eventos.

Criar um job do Cloud Scheduler para acionar atualizações de espelho do banco de dados ClamAV

Crie um job do Cloud Scheduler que execute uma solicitação HTTP POST no serviço do Cloud Run com um comando para atualizar o espelho do banco de dados de definições de malware. Para evitar que muitos clientes usem o mesmo horário, o ClamAV exige que você programe o job em um minuto aleatório entre 3 e 57, evitando múltiplos de 10.

while : ; do
  # set MINUTE to a random number between 3 and 57
  MINUTE="$((RANDOM%55 + 3))"
  # exit loop if MINUTE is not a multiple of 10
  [[ $((MINUTE % 10)) != 0 ]] && break
done

gcloud scheduler jobs create http \
    "${SERVICE_NAME}-mirror-update" \
    --location="${REGION}" \
    --schedule="${MINUTE} */2 * * *" \
    --oidc-service-account-email="${SERVICE_ACCOUNT}" \
    --uri="${SERVICE_URL}" \
    --http-method=post \
    --message-body='{"kind":"schedule#cvd_update"}' \
    --headers="Content-Type=application/json"

O argumento de linha de comando --schedule define quando o job será executado usando o formato de string unix-cron. O valor fornecido indica que ele precisa ser executado no minuto específico gerado aleatoriamente a cada duas horas.

Este job só atualizará o espelho do ClamAV no Cloud Storage. O daemon freshclam CLIvAV em cada instância do Cloud Run verificará o espelho a cada 30 minutos em busca de novas definições e atualizará o daemon ClamAV.

Testar o pipeline fazendo upload de arquivos

Faça upload de um arquivo sem malware e de outro infectado para testar o pipeline.

1. Crie um arquivo de texto de amostra ou use um atual não infectado para testar os processos do pipeline.

2. Copie o arquivo de dados de amostra para o bucket de arquivos não verificados:

   gsutil cp filename "gs://unscanned-${PROJECT_ID}"
   

   Substitua filename pelo nome do arquivo de texto não infectado. O serviço de verificação de malware inspeciona cada documento e o transfere para um bucket apropriado. Esse arquivo é movido para o bucket limpo.

3. Aguarde alguns segundos para o pipeline processar o arquivo e verifique o bucket limpo para ver se o arquivo processado está lá:

   gsutil ls -r "gs://clean-${PROJECT_ID}"
   

4. O arquivo foi removido do bucket não verificado:

   gsutil ls -r "gs://unscanned-${PROJECT_ID}"
   

5. No Cloud Shell, faça o upload de um arquivo chamado eicar-infected.txt com a assinatura de teste antimalware padrão da EICAR para seu bucket não verificado:

   echo -e 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' \
       | gsutil cp - "gs://unscanned-${PROJECT_ID}/eicar-infected.txt"
   

   Observação: essa string de texto tem uma assinatura que aciona verificadores de malware para fins de teste. Esse arquivo de teste não é um malware real, é apenas um teste amplamente usado e não afeta a estação de trabalho. Se você tentar criar um arquivo com essa string em um computador que tenha um verificador de malware instalado, será possível acionar um alerta.

6. Aguarde alguns segundos e verifique o bucket em quarentena para ver se o documento passou pelo pipeline. O serviço também registra uma entrada do Logging quando um arquivo infectado por malware é detectado.

   gsutil ls -r "gs://quarantined-${PROJECT_ID}"
   

7. O arquivo foi removido do bucket não verificado:

   gsutil ls -r "gs://unscanned-${PROJECT_ID}"
   

Testar o mecanismo de atualização do banco de dados de definições de malware

• No Cloud Shell, é possível acionar a verificação de atualizações forçando a execução do job do Cloud Scheduler:

  gcloud scheduler jobs run "${SERVICE_NAME}-mirror-update" --location="${REGION}"
  

  Os resultados desse comando serão exibidos apenas nos registros detalhados.

Monitorar o serviço

O serviço pode ser monitorado usando o Cloud Logging e o Cloud Monitoring.

Ver registros detalhados

1. No console do Google Cloud, acesse a página "Explorador de registros" do Cloud Logging.

   Acessar o Explorador de registros

2. Se o filtro Campos de registro não for exibido, clique no botão Campos de registro.

3. No filtro Campos de registro, clique em Revisão do Cloud Run.

4. Na seção Nome do serviço do filtro Campos de registro, clique em scanner de malware.

Os resultados da consulta de registros mostrarão os registros do serviço, incluindo várias linhas que mostram as solicitações de verificação e o status dos dois arquivos enviados, por exemplo:

Scan request for gs://unscanned-PROJECT_ID/filename, (##### bytes) scanning with clam ClamAV CLAMAV_VERSION_STRING
Scan status for gs://unscanned-PROJECT_ID/filename: CLEAN (##### bytes in #### ms)
...
Scan request for gs://unscanned-PROJECT_ID/eicar-infected.txt, (69 bytes) scanning with clam ClamAV CLAMAV_VERSION_STRING
Scan status for gs://unscanned-PROJECT_ID/eicar-infected.txt: INFECTED stream: Eicar-Signature FOUND (69 bytes in ### ms)

É possível ver que a versão do ClamAV e a revisão de assinatura do banco de dados de malware são relatadas, junto com o nome do malware do arquivo de teste infectado.

É possível usar essas mensagens de registro para configurar alertas quando um vírus for encontrado ou para quando houver falhas durante a verificação.

Os registros de atualização do espelhamento de definições de malware também aparecem e se parecem com o seguinte:

Starting CVD Mirror update
CVD Mirror update check complete. output: ...

Se o espelho tiver sido atualizado, haverá uma linha adicional:

CVD Mirror updated: DATE_TIME - INFO: Downloaded daily.cvd. Version: VERSION_INFO

Os registros de atualização do freshclam serão exibidos a cada 30 minutos e aparecerão como:

DATE_TIME -> Received signal: wake up
DATE_TIME -> ClamAV update process started at DATE_TIME
DATE_TIME -> daily.cvd database is up-to-date (version: VERSION_INFO)
DATE_TIME -> main.cvd database is up-to-date (version: VERSION_INFO)
DATE_TIME -> bytecode.cvd database is up-to-date (version: VERSION_INFO)

Se o banco de dados foi atualizado, as linhas de registro do freshclam serão exibidas como:

DATE_TIME -> daily.cld updated (version: VERSION_INFO)

Ver métricas

O serviço gera as seguintes métricas para fins de monitoramento e alerta:

• Número de arquivos limpos processados:
  custom.googleapis.com/opencensus/malware-scanning/clean_files
• Número de arquivos infectados processados:
  custom.googleapis.com/opencensus/malware-scanning/infected_files
• Tempo gasto na verificação de arquivos:
  custom.googleapis.com/opencensus/malware-scanning/scan_duration
• Número total de bytes verificados:
  custom.googleapis.com/opencensus/malware-scanning/bytes_scanned
• Número de verificações de malware com falha:
  custom.googleapis.com/opencensus/malware-scanning/scans_failed
• Número de verificações de atualização do CVD Mirror:
  custom.googleapis.com/opencensus/malware-scanning/cvd-mirror-updates

Essas métricas podem ser visualizadas no Metrics Monitoring do Cloud Monitoring.

1. No console do Google Cloud, acesse a página "Metrics Explorer" do Cloud Monitoring.

   Acessar o Metrics Explorer

2. Clique no campo Selecionar uma métrica e insira a string de filtro malware.

3. Selecione a métrica OpenCensus/malware-scanning/clean_files. O gráfico mostrará um ponto de dados que indica quando o arquivo limpo foi verificado.

As métricas podem ser usadas para monitorar o pipeline e criar alertas para quando um malware for detectado ou quando os arquivos falharem no processamento.

Para ver mais detalhes, é possível detalhar as métricas por vários rótulos:

• source_bucket
• destination_bucket
• clam_version
• cloud_run_revision

Processar vários buckets

O serviço de verificação de malware pode verificar arquivos de vários buckets de origem, enviando-os para separar buckets limpos e em quarentena.

Embora essa configuração avançada esteja fora do escopo deste tutorial, as etapas envolvidas estão resumidas da seguinte maneira:

1. Criar os vários buckets do Cloud Storage não verificados, limpos e em quarentena com nomes exclusivos.

2. Conceda os papéis apropriados à conta de serviço malware-scanner nos vários buckets.

3. Edite o arquivo de configuração config.json para especificar os nomes dos buckets de cada configuração:

   {
     "buckets": [
       {
         "unscanned": "unscanned-bucket-1-name",
         "clean": "clean-bucket-1-name",
         "quarantined": "quarantined-bucket-1-name"
       },
       {
         "unscanned": "unscanned-bucket-2-name",
         "clean": "clean-bucket-2-name",
         "quarantined": "quarantined-bucket-2-name"
       }
     ]
     "ClamCvdMirrorBucket": "cvd-mirror-bucket-name"
   }
   

4. Para cada um dos buckets não verificados, crie um gatilho do Eventarc, garantindo que haja um nome de gatilho exclusivo para cada um.

Observação: o bucket do Cloud Storage precisa estar no mesmo projeto e região que o gatilho do Eventarc.

Limpar

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

Exclua o projeto

Cuidado: excluir um projeto tem os seguintes efeitos:
• Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.
1. No Console do Google Cloud, acesse a página Gerenciar recursos.

   Acessar "Gerenciar recursos"

2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

A seguir

• Veja a documentação do Cloud Storage.
• Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.