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.
Google Cloud CLI를 설치합니다.
설치 후 다음 명령어를 실행하여 Google Cloud CLI를 초기화합니다.
Web Risk는 통합할 수 있는 두 가지 API를 제공합니다. 이러한 API는 Lookup API와 Update API입니다. 두 API 모두 동일한 정보를 제공합니다. 즉, URL이 악성으로 확인되었는지 여부를 나타냅니다. 사용하기에 가장 쉬운 API는 Lookup API입니다. Lookup API를 사용하여 확인할 모든 URL에 대해 Web Risk를 쿼리하게 됩니다.
Update API는 더 복잡하지만 몇 가지 매력적인 속성이 있습니다. Update API를 사용하면 로컬 데이터베이스를 유지관리하게 됩니다. 이 데이터베이스는 URL이 악성인지 확인하기 위해 확인됩니다. 이 데이터베이스는 블룸 필터 역할을 합니다. 즉, 거짓 양성(URL은 악성으로 식별되지 않지만 그렇지 않은 경우)은 있을 수 있지만 거짓음성은 없어야 합니다(URL은 악성이 아닌 것으로 식별되지만 악성인 경우). 이로 인해 Web Risk 서버는 거의 접속되지 않으며 일치를 확인하고 거짓 양성의 모호성을 없애기 위해서만 접속됩니다. 대부분의 경우 Update API를 사용하여 URL을 확인할 때 Web Risk 서버에 접속하지 않아도 됩니다. 로컬 데이터베이스를 업데이트하고 URL이 유해하다고 확인할 경우에만 Web Risk 서버에 접속해야 합니다.
다시 말해 빠르고 쉽게 설정하려면 Lookup API를 사용합니다.
지연 시간이 짧은 URL 확인이 필요한 경우 Update API를 사용합니다.
적합한 클라이언트 기능 선택
Update API를 사용하기로 선택한 경우 전체 사양을 구현할 필요가 없을 수도 있습니다. 다수의 기업 사례에서 과도하게 최적화된, 널리 분산된 클라이언트(예: 웹브라우저)를 위해 설계된 일부 기능이 있습니다.
일부 기능은 쉽게 통합할 수 있도록 무시됩니다.
다음은 복잡성 순으로 나열한 웹 Web Risk 통합 솔루션입니다.
LookUp API 사용하기
기본 Update API 클라이언트
비교를 사용하는 Update API 클라이언트
RICE 압축 비교를 사용하여 Update API 클라이언트
Lookup API 사용
Lookup API를 사용하는 것이 복잡성이 가장 낮습니다. 의심스러운 URL이 있을 때마다 해당 URL로 Lookup API를 호출하여 결과를 확인합니다.
URL 표준화 및 형식 지정은 Web Risk 서버에서 처리합니다. 평균 지연 시간이 요구사항을 초과하지 않는 한 이 솔루션은 대부분의 클라이언트에서 유효해야 합니다.
기본 Update API 클라이언트
Update API를 사용하려면 쿼리 전에 로컬 데이터베이스와 표준 URL을 관리하는 것이 더 복잡해집니다.
Web Risk의 일반적인 클라이언트 통합에서 클라이언트는 데이터베이스 diff를 적용하여 최신 상태를 유지합니다. diff 애플리케이션 로직이 올바르게 구현되려면 시간이 걸릴 수 있으므로 가장 간단한 경우에는 클라이언트가 diff를 무시하고 각 사이클마다 Web Risk의 새로운 전체 데이터베이스를 요청하는 것이 좋습니다. 이 데이터베이스는 효율적으로 쿼리할 수 있도록 여전히 메모리에 저장됩니다. threatLists.computeDiff 요청에서 versionToken 필드를 비워 두면 전체 데이터베이스 재설정 요청이 수행됩니다.
대역폭 또는 데이터베이스 동기화 지연 시간이 요구사항을 충족하지 않는 한 이 솔루션은 클라이언트에 유효해야 합니다.
Update API 사용 및 비교 업데이트 요청
이 솔루션에는 diff 로직을 로컬 데이터베이스에 적용하는 복잡성이 추가되었습니다. 자세한 내용은 데이터베이스 Diff를 참조하세요. diff를 사용하면 각 사이클마다 새 데이터베이스를 요청할 때와 대역폭이 줄어들어 복잡성이 감소합니다. 전체 데이터베이스 업데이트는 수 메가바이트 정도일 수 있습니다.
대부분의 기업 고객은 이 솔루션을 사용하는 것이 좋습니다.
Update API 사용 및 RICE 인코딩 비교 업데이트 요청
이 솔루션은 가장 효율적인 클라이언트 통합입니다. RICE 인코딩은 DIFF 크기를 압축하고 업데이트 대역폭을 더 줄입니다. 이 솔루션은 대역폭이 가장 제한된 고객이 사용하도록 고안되었습니다. 이와 관련이 있을 수 있는 한 가지 예시로 Web Risk 쿼리가 전화 앱에 포함된 경우 이러한 앱의 사용자가 전화 데이터를 통해 데이터베이스를 업데이트해야 하면 사용자는 낮은 대역폭 솔루션에 만족할 것입니다.
자세한 내용은 압축을 참조하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Detect malicious URLs with Web Risk\n===================================\n\nBefore you begin\n----------------\n\n- Create a Google Cloud project. [Learn how to create a Google Cloud project](/resource-manager/docs/creating-managing-projects#creating_a_project).\n\n-\n\n\n [Verify that billing is enabled for your Google Cloud project](/billing/docs/how-to/verify-billing-enabled#confirm_billing_is_enabled_on_a_project).\n\n \u003cbr /\u003e\n\nSet up authentication and enable the Web Risk API\n-------------------------------------------------\n\nSign in to your Google Cloud account. If you're new to Google Cloud, [create an account](https://console.cloud.google.com/freetrial) to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.\n\n\n[Install](/sdk/docs/install) the Google Cloud CLI.\n\nAfter installation,\n[initialize](/sdk/docs/initializing) the Google Cloud CLI by running the following command:\n\n```bash\ngcloud init\n```\n\n\nIf you're using an external identity provider (IdP), you must first\n[sign in to the gcloud CLI with your federated identity](/iam/docs/workforce-log-in-gcloud).\n\n[Create or select a Google Cloud project](https://cloud.google.com/resource-manager/docs/creating-managing-projects).\n| **Note**: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.\n\n- Create a Google Cloud project:\n\n ```\n gcloud projects create PROJECT_ID\n ```\n\n Replace \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e with a name for the Google Cloud project you are creating.\n- Select the Google Cloud project that you created:\n\n ```\n gcloud config set project PROJECT_ID\n ```\n\n Replace \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e with your Google Cloud project name.\n\n\n[Verify that billing is enabled for your Google Cloud project](/billing/docs/how-to/verify-billing-enabled#confirm_billing_is_enabled_on_a_project).\n\n\nEnable the Web Risk API:\n\n\n```bash\ngcloud services enable webrisk.googleapis.com\n``` \n\n[Install](/sdk/docs/install) the Google Cloud CLI.\n\nAfter installation,\n[initialize](/sdk/docs/initializing) the Google Cloud CLI by running the following command:\n\n```bash\ngcloud init\n```\n\n\nIf you're using an external identity provider (IdP), you must first\n[sign in to the gcloud CLI with your federated identity](/iam/docs/workforce-log-in-gcloud).\n\n[Create or select a Google Cloud project](https://cloud.google.com/resource-manager/docs/creating-managing-projects).\n| **Note**: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.\n\n- Create a Google Cloud project:\n\n ```\n gcloud projects create PROJECT_ID\n ```\n\n Replace \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e with a name for the Google Cloud project you are creating.\n- Select the Google Cloud project that you created:\n\n ```\n gcloud config set project PROJECT_ID\n ```\n\n Replace \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e with your Google Cloud project name.\n\n\n[Verify that billing is enabled for your Google Cloud project](/billing/docs/how-to/verify-billing-enabled#confirm_billing_is_enabled_on_a_project).\n\n\nEnable the Web Risk API:\n\n\n```bash\ngcloud services enable webrisk.googleapis.com\n```\n\n\u003cbr /\u003e\n\nUsing the APIs\n--------------\n\nWhen you use the Web Risk APIs, make sure you're familiar with Web Risk's [Service Level Agreement](/web-risk/sla) and [usage limits](/web-risk/quotas).\n\nTo start using Web Risk, see these topics:\n\n- [Using the Lookup API](/web-risk/docs/lookup-api)\n- [Using the Update API](/web-risk/docs/update-api)\n\nWhich API is right for me? Lookup or Update?\n--------------------------------------------\n\nWeb Risk provides two different APIs that you may integrate with. These\nAPIs are the [Lookup API](/web-risk/docs/lookup-api) and the [Update API](/web-risk/docs/update-api). Both of\nthese APIs provide the same information. That is, whether a URL has been\nidentified as malicious. The easiest to use is the Lookup API. Using the Lookup\nAPI, you will query Web Risk for every URL you wish to check.\n\nThe Update API is more complex but has some desirable properties. Using the\nUpdate API, you will maintain a local database. This database may be checked\nto see if a URL is malicious. This database acts as a bloom filter. That is,\nthere may be false positives (a URL is identified as malicious but isn't) but\nthere should not be any false negatives (a URL is identified as not malicious,\nbut is). Because of this, the Web Risk servers are rarely contacted, and are\nonly contacted to confirm matches and disambiguate false positives. In most\ncases, when checking a URL using the Update API you won't need to contact the\nWeb Risk servers at all. You are expected to contact Web Risk servers only when\nupdating the local database and when confirming a URL is harmful.\n\nIn summary, use the Lookup API if you want to get set up quickly and easily.\nUse the Update API if you need lower latency URL checking.\n\nChoosing the Right Client Features\n----------------------------------\n\nIf you chose to use the Update API, you may not need to implement the entire\nspecification. There are some features that were designed for widely distributed\nclients (like web browsers) that are over-optimizations in many enterprise\ncases.\n\nThere are some features that may be ignored for easier integration.\n\nHere are the Web Risk integration solutions in order of complexity\n\n1. Use the LookUp API\n2. Basic Update API client\n3. Update API client using diffs\n4. Update API client using RICE compressed diffs\n\n### Using the Lookup API\n\nUsing the Lookup API has the lowest complexity. Whenever there is a potentially\nsuspicious URL, simply call the Lookup API with the URL to see a verdict.\nCanonicalization and formatting the URL is handled by the Web Risk\nserver. This solution should be valid for most clients unless average latency\nexceeds requirements.\n\n### Basic Update API client\n\nThe Update API requires the additional complexity of managing a local database\nand canonicalized URLs before queries.\n\nIn a typical client integration with Web Risk, a client will apply database\ndiffs to remain up-to-date. The diff application logic may take some time to\nimplement correctly, so in the simplest cases we recommend clients ignore diffs\nand request a full new database from Web Risk every cycle. This database will\nstill be stored in memory for efficient querying. Requesting a full database\nreset is done by leaving the `versionToken` field empty in the\n[`threatLists.computeDiff` request](/web-risk/docs/update-api#http_get_request).\nThis solution should be valid for clients unless bandwidth or database\nsynchronization latency exceeds requirements.\n\n### Use the Update API and request diff updates\n\nThis solution has the added complexity of applying the diff logic to the local\ndatabase. For more information, see\n[Database Diffs](/web-risk/docs/local-databases#full-updates). Using diffs will reduce\nbandwidth at the expense of complexity, compared to requesting a new database\neach cycle. A full database update may be on the order of a few megabytes.\nThis solution should be sufficient for most enterprise clients.\n\n### Use the Update API and request RICE encoded diff updates\n\nThis solution is the most efficient client integration possible. RICE encoding\ncompresses DIFF sizes and further reduces update bandwidth. This solution is\nintended to be used by the most bandwidth constrained customers. An example\nwhere this may be relevant is if Web Risk queries are built into a phone App.\nThe users of such an app would surely appreciate a lower bandwidth solution if\nthey needed to update the database over phone data.\nFor more information, see [Compression](/web-risk/docs/compression)."]]
