コンテンツに移動
セキュリティ & アイデンティティ

フィッシングなどの阻止に Web Risk API を活用するためのベスト プラクティス

2021年9月8日
Google Cloud Japan Team

※この投稿は米国時間 2021 年 8 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。

ソーシャル メディア サイト、セキュリティ企業、企業メールのいずれの担当であっても、ユーザーの安全を確保するという目標に変わりはありません。ただし、ユーザーの安全に関わる上位 2 つの脅威であるフィッシングとマルウェアが存在するため、この目標の達成には困難が伴います。Google のセーフ ブラウジング チームは、10 年以上にわたり、マルウェアやフィッシングなどの脅威からウェブを防御することに専念してきました。Google は毎日数十億のリンクを調べることで、フィッシング、ソーシャル エンジニアリング、マルウェア、望ましくないソフトウェアに関連する、100 万件以上の悪意のある URL のリストを生成しています。

この数年は、セーフ ブラウジングで使用されるテクノロジーを基盤に構築され、新しい機能が加えられた企業向けツールである Web Risk API の導入に注力しています。Web Risk API によって、企業は Google のフィッシングとマルウェアに関するデータにアクセスし、URL が悪意のあるものかどうか確認できます。ここでは、ウェブベースの攻撃から企業を保護するために、すべての Web Risk API を組み合わせて使用するベスト プラクティスをお伝えします。

Web Risk API の仕組み

ユーザーは Web Risk API に URL を送信して、安全かどうかを確認できます。Web Risk が評価可能な URL は、インターネットに接続されている、会社のどのプラットフォームやデバイスからも送信できます。悪意を持った URL は、一般的に次の場所から送られてきます。

  • ユーザー作成コンテンツ: 大規模なソーシャル メディア サイトでは、攻撃者が他のユーザーに投稿やソーシャル エンジニアリングを直接行い、よく知られている悪意のあるリンクを共有させることがあります。

  • メール: 組織の内外から送信されるメールは、フィッシングとマルウェアの侵入口として最も使われることの多い媒介です。

  • ユーザー レポート: 企業には pishing@yourcompany.com のような報告用メールアドレスまたはフォームがあり、ユーザーはインフラストラクチャから送信されるフィッシング、またはブランド アイデンティティ(ロゴ、メッセージ、ログインの詳細)を使用して攻撃しようとするフィッシングを報告できます。 

  • ファイアウォールまたは CASB を経由して観測される企業ユーザーのアクティビティ。

  • 参照リンク: 攻撃者は、実際の顧客サイトからソース コンテンツ / イメージへと直接リンクすることが多く見られます。これらのリソースへのトラフィックを調べると、このタイプの初期の不正行為が見つかることがあります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/How_Web_Risk_API_Works.max-1100x1100.jpg

Web Risk API から結果を受け取ると、セキュリティ チームまたは自動システムは、コンテンツをブロックし、是正分析を行うための措置を速やかに講じて、不正使用されたユーザーが行った可能性のある行動を把握できます。ユーザーがフィッシングによって不正使用された場合、ユーザーのアカウントをリセットし、アカウントのすべてのデータが漏洩したことをユーザーに知らせます。マルウェアによる不正使用の場合、マルウェアが完全に削除されたことを確認するため、ユーザーのデバイスとソフトウェアのリセットが必要になることがよくあります。さらに、マルウェアによる不正使用以降にアクセスされたユーザー アカウントも、リスクにさらされていると考えられます。

Web Risk API の 4 つの API の仕組み

不正使用される URL にはさまざまなパターンがあるため、Web Risk は数個の異なる URL を提供し、不正行為やスパムの検出をサポートします。

  • Lookup API: URL を送信し、悪意の有無を確認します。

  • Update API: 悪意のある URL の部分的ハッシュのリストを保存します。ローカルで比較を行い、見つかった一致を Web Risk API に送信して完全なハッシュを受け取ることをおすすめします。この API は Lookup API よりも実装に手間がかかりますが、主に使用するのはローカル データベースへの呼び出しです。完全な URL を送信する必要はありません。

  • Evaluate API: URL を送信し、リスクタイプと信頼スコアの評価を受け取ります。Update API と Lookup API は不正な動作を確認した結果を返し、一方 Evaluate API は URL の評価に基づいた結果を返します。URL のクロールを必要とせず、URL のなりすましやクローキングに対して脆弱でもありません。

  • Submissions API: 企業が URL をセーフ ブラウジング拒否リストに直接送信できます。ポリシー違反リストに記載されている URL が見つかった場合、世界中の 40 億以上の(Google 以外のプラットフォームを含む)デバイスで使用されているセーフ ブラウジング拒否リストに追加されます。対象範囲が広いので、仮想フィッシング、ブランドなりすましのフィッシング、さらには企業独自のインフラストラクチャの管理外に配信される他のタイプのユーザー攻撃から、顧客を防御できます。

すべての Web Risk API を組み合わせてエンドユーザーを保護する

URL を以下のように組み合わせて使用することをおすすめします。

  1. 最初の呼び出しは Update API に対するもので、URL が悪意があると認識されているかどうか判断するために行われます。これはレスポンスが速い(ローカル ハッシュとの比較)ことから、最初の呼び出しとして最適です。

  2. Update API が、悪意があると判定しなかった場合、次の呼び出しが Evaluate API に対して行われ(サーバー呼び出し)、URL にリスクのシグナルがあるか判定します。

  3. 最後に Google に URL のクロールを依頼する、または URL が不正であると Google に知らせたい場合は、Submissions API に送信できます。この API は URL の完全なクロールを行い、不正行為が見つかった場合はセーフ ブラウジング拒否リストにその URL を加えます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/How_to_Use_All_the_Web_Risk_APIs.max-1100x1100.jpg

これらは指定された順序で呼び出すことも、同時に呼び出すこともできます。また、内部リスクモデルまたはアナリスト チームがある場合は、こうしたシグナルを入力として、独自の検出モデルに統合できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/detection_models.max-1200x1200.jpg

悪意のある URL が見つかった場合の対応は、URL が存在するチャネルによって異なります。

  • メール: ウェブプロキシ経由のアクセスをブロックして SIEM にログを記録し、漏洩したユーザーまたはデバイスをフォローアップします。

  • ユーザー レポート: URL をセーフ ブラウジングに送信し、会社管理のすべてのプラットフォームで悪意のあるリンクをブロックします。

  • ユーザー作成コンテンツ: ユーザー向けコンテンツからリンクを削除します。投稿したユーザーを調査します。注: 多くは意図せずに悪意のあるコンテンツを広めてしまうユーザーです。

  • ファイアウォールまたは CASB を経由して観測される企業ユーザーのアクティビティ: ウェブプロキシ経由のアクセスをブロックして SIEM にログを記録し、漏洩したユーザーまたはデバイスをフォローアップします。

  • 参照リンク: 攻撃者は、実際の顧客サイトからソース コンテンツ / イメージへと直接リンクすることが多く見られます。URL をセーフ ブラウジングに送信し、会社管理のすべてのプラットフォームで悪意のあるリンクをブロックします。

アカウントをフィッシングとマルウェアの侵害から防御する戦いには、終わりがありません。Web Risk API チームは、ユーザーを安全に保護するツールを提供することに専念しています。Web Risk API の使用を開始するには販売チームにご連絡ください


-プロダクト マネージャー Cy Khormaee

-Web Risk 販売チームリーダー Evan Derheim
投稿先