Detectar URLs maliciosos com o Web Risk

Antes de começar

Configurar a autenticação e ativar a API Web Risk

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
  2. Install the Google Cloud CLI.

  3. To initialize the gcloud CLI, run the following command: 

    gcloud init

  4. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  5. Make sure that billing is enabled for your Google Cloud project.

  6. Enable the Web Risk API: 

    gcloud services enable webrisk.googleapis.com
  7. Install the Google Cloud CLI.

  8. To initialize the gcloud CLI, run the following command: 

    gcloud init

  9. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  10. Make sure that billing is enabled for your Google Cloud project.

  11. Enable the Web Risk API: 

    gcloud services enable webrisk.googleapis.com

Como usar as APIs

Ao usar as APIs Web Risk, familiarize-se com o Contrato de nível de serviço e os limites de uso do Web Risk.

Para começar a usar a Web Risc, consulte estes tópicos:

Qual API é ideal para mim? Lookup ou Update?

A Web Risk fornece duas APIs diferentes que podem ser integradas. Essas APIs são a API Lookup e a API Update. Ambas as APIs fornecem as mesmas informações. Ou seja, se um URL foi identificado como malicioso. A mais fácil de usar é a API Lookup. Usando a API Lookup, você consultará a Web Risk para cada URL que você quer verificar.

A API Update é mais complexa, mas tem algumas propriedades desejáveis. Usando a API Update, você manterá um banco de dados local. Esse banco de dados pode ser verificado para ver se um URL é malicioso. Esse banco de dados atua como um filtro de floração. Ou seja, pode haver falsos positivos (um URL é identificado como malicioso, mas não deve ser), mas não deve haver nenhum falso negativo (um URL é identificado como não malicioso, mas é). Por isso, os servidores da Web Risk raramente são contatados e só são contatados para confirmar correspondências e para desambiguar falsos positivos. Na maioria dos casos, ao verificar um URL usando a API Update, você não precisa entrar em contato com os servidores da Web Risk. Espera-se que você entre em contato com os servidores da Web Risk somente ao atualizar o banco de dados local e ao confirmar um URL.

Em resumo, use a API Lookup se quiser configurar de maneira rápida e fácil. Use a API Update se precisar de uma verificação de URL de latência mais baixa.

Como escolher os recursos certos para o cliente

Se você optou por usar a API Update, talvez não seja necessário implementar toda a especificação. Há alguns recursos projetados para clientes amplamente distribuídos (como navegadores da Web) que são otimizações em excesso em muitos casos corporativos.

Alguns recursos podem ser ignorados para facilitar a integração.

Estas são as soluções de integração da Web Risk em ordem de complexidade

  1. Usar a API LookUp
  2. Cliente da API Update básica
  3. Cliente da API Update usando diferenças
  4. Ciente da API Update usando diferenças com compactação RICE

Como usar a API Lookup

O uso da API Lookup tem a menor complexidade. Sempre que houver um URL potencialmente suspeito, basta chamar a API Lookup com o URL para ver um veredito. A canonicidade e a formatação do URL são tratadas pelo servidor da Web Risk. Essa solução deve ser válida para a maioria dos clientes, a menos que a latência média exceda os requisitos.

Cliente da API Update básica

A API Update exige a complexidade adicional do gerenciamento de um banco de dados local e de URLs canônicos antes das consultas.

Em uma integração de cliente típica com a Web Risk, um cliente aplicará diferenças de banco de dados para permanecer atualizado. A lógica do aplicativo de diferenças pode levar algum tempo para ser implementada corretamente. Portanto, nos casos mais simples, recomendamos que os clientes ignorem as diferenças e solicitem um novo banco de dados completo da Web Risk a cada ciclo. Esse banco de dados ainda será armazenado na memória para consultas eficientes. A solicitação de uma redefinição completa do banco de dados é feita deixando o campo versionToken vazio na solicitação threatLists.computeDiff. Essa solução deve ser válida para clientes, a menos que a latência de sincronização do banco de dados ou da largura de banda exceda os requisitos.

Usar a API Update e solicitar atualizações diferentes

Essa solução tem a complexidade adicional de aplicar a lógica de diferenças ao banco de dados local. Para mais informações, consulte Diferenças de banco de dados. O uso de diferenças reduzirá a largura de banda à custa da complexidade, em comparação com a solicitação de um novo banco de dados a cada ciclo. Uma atualização completa do banco de dados pode estar na ordem de alguns megabytes. Essa solução deve ser suficiente para a maioria dos clientes empresariais.

Usar a API Update e solicitar atualizações de diferenças codificadas em RICE

Essa solução é a integração de cliente mais eficiente possível. A codificação RICE compacta tamanhos DIFF e reduz ainda mais a largura de banda de atualização. Esta solução deve ser usada pelos clientes com maior largura de banda. Um exemplo em que isso pode ser relevante é se as consultas da Web Risk estiverem incorporadas em um aplicativo para telefone. Os usuários desse aplicativo com certeza gostariam de uma solução de largura de banda menor se precisassem atualizar o banco de dados por dados de telefone. Para mais informações, consulte Compactação.