セキュリティの改善における OAuditToolbox の活用

Indeed が世界 No.1 の求人検索サイトであり続けているのは、ユーザーからの信頼が大きく貢献しています。ユーザー は Indeed が情報を安全に管理してることを信用しています。個人情報の悪用が常にニュースになる世の中において、私たちは、その責任を真摯に受け止め、注意を怠るわけにはいきません。だからこそ、Indeed の社員や企業のデータだけでなく、Indeed に信頼を寄せるユーザーのデータを保護するために、データを安全に管理する必要があります。

私は Indeed の情報セキュリティチームに所属しており、2017 年の初頭より、Indeed の Google GSuite 使用における問題点の改善に取り組んできました。これに対する Indeed のソリューションである OAudit Toolbox が、オープンソースのツールとして皆さんにもご利用いただけるようになりました。

問題:サードパーティアプリのリスク

Indeed が Gsuite を使用するにあたり、最もリスクの高い部分はサードパーティアプリの連携でした。

GSuite ユーザーは、自身のアカウントへのアクセスをアプリケーションに許可することができます。これは、基本的なアカウント情報から、Gmailの 閲覧・編集する権限にまで渡ります。確認画面の中に表示されている OAtuth のScope (権限) によって、Google 情報へのアクセスが管理されています。

GSuiteを利用している企業にとって、これには複数の問題点があります。

ユーザーの教育 ユーザーが気づかずにアクセスを許可してしまったり、自分の選択した動作がプライバシーやセキュリティにどのような影響があるか理解していない可能性があります。

データの共有 特定のScopeに対して、アプリを認証することでサードパーティに機密データへのアクセスを許可してしまいます。企業としては、こうした種類のアクセスに対し、適切なデータ共有の契約で明示していないかもしれません。

データの抜き取り 悪意のあるアプリケーションが OAuth のフローを使用し、フィッシングを行い、Google アカウントからデータを抜き取る可能性があります。

限られたツール 私が調査を行った時点では、Googleの提供によるアプリ制限のための選択肢は限られていました。API は、対処が後手に回りやすいブラックリスト方式だけが利用可能でした。比較的新しい機能では、接続したアプリのホワイトリスト化が可能になりましたが、これは、アプリのホワイトリストを実際に用意しておく必要がありました。

ポリシー文化 多くの企業は寛大すぎる Scope でアクセスを許可しています。Google の新しいホワイトリスト機能を使用するためには、セキュリティチームが大量のアプリのバックログの調査、承認、そしてホワイトリストの作成を行う必要があります。怪しげなメールトラッカーアプリを使わないと生産性があがらないと主張する社員からのリクエストをさばいたりもしなければいけません。

そうこうしているうちに、Indeed は実際に攻撃を受けたのですが、これにより、問題が浮き彫りにされ、ソリューションを定義することができました。

決定的な事件: 大規模のフィッシング攻撃

2017 年の 5 月には、世界中の Google Apps ユーザーに、Google ドキュメント を装った大規模のフィッシング攻撃がありました。

ユーザーは、知り合いから届いたように見える、ドキュメント共有の招待メールを受信しました。GSuite を利用している企業で働いている場合、こうしたリクエストは何の変哲もありません。ただし、この偽の Google ドキュメントは、受信者のメールと連絡先へのアクセス権限を要求するものでした。もしユーザーがアクセスを許可してしまった場合、偽 Google ドキュメントのアプリはこの被害者のアカウントを利用し、被害者になりすまして連絡先に同じフィッシングメールを送信していました。

Indeed のセキュリティチームの一員として、私は最前線に立ってこの攻撃に対応していました。数時間に渡るパニックと、OAuth トークンの無効化を行った後、私は不思議と刺激を受けていました。GSuite の利用可能なツールの隙間を埋め、このような攻撃をもっとすぐに検知し、ユーザーにサードパーティアプリ認証の危険性に関する知識を深めてもらう方法を見つけたいと考えたのです。こうして、同僚のDustin Deckerと共に、完璧なソリューションに近づけるような一連のツール開発に取り組み始めました。

Indeed のソリューション: OAudit Toolbox

OAudit Toolbox はサードパーティアプリの統合を検知し、ユーザーに危険性とそのアクセス許可する範囲を通知する一連のツールです。

OAudit Toolbox の仕組み

OAudit Toolbox は 2 つの主要なコンポーネントからなります。

  • Oaudit-collector は Google Admin API から認証イベントを Elasticsearch内にインデックス化します。
  • Oaudit-notifier は、OAuth の Scope に関する通知を送り、またホワイトリスト/ブラックリストを管理するロジックを持っています。

ブラックリスト方式は、リスト化された既知の悪質なアプリのアクセス権限の取り消しを、ほぼリアルタイムで行うことができます。このリストは、悪意のあるアプリや企業のポリシーに違反するアプリを含みます。ブラックリストとしてアプリが定義された後にだけ、認証されたアプリのアクセス権限は取り消されます。

ホワイトリスト方式は、信頼されたアプリに関する通知を停止するので、ユーザーが度重なる警告にうんざりせずに済みます。

  1. Oaudit-collector は、Google Admin SDK APIを利用し、認証トークンのイベントデータを取得します。
  2. Oaudit-collector は、Elasticsearch 内に取得したデータをインデックス化します。
  3. Oaudit-notifier は、認証されたアプリケーションがホワイトリストやブラックリストに入っているか、または未知のものであるかどうかを確認します。
    • もしアプリがホワイトリストに入っている場合、通知は送られません。これは通常セキュリティ審査を受けたアプリに使用されます。サードパーティアプリは、(該当する場合)Indeed に対して適切なデータ共有の規約の提示が必要になります。
    • もしアプリがブラックリストに入っている場合、ユーザーにその旨とアクセスが拒否されたことを通知します。これは悪意のあるアプリ (例: 2017年に起きたフィッシング攻撃) や、企業のポリシーに準拠してないアプリに対して使用されます。
    • ブラックリスト・ホワイトリストのどちらにも記載のないアプリは、信頼されていないアプリケーションを認証することに対する潜在的リスクと、望まないアクセスを拒否する方法をユーザーに通知します。

OAudit Toolbox の活用方法

OAuth Toolbox は、私が発見した GSuite の利用に伴う各問題を解決、または少なくとも軽減します。

ソリューション:ユーザーの教育

ユーザーがサードパーティアプリを認証してしまうのには、以下のように沢山の理由が考えられます。

  • マネージャーの指示があった。
  • ユーザーが確認画面の内容を理解していない。
  • ユーザーがDPA (データ処理規約。Data Protection Agreement) や、 MNDA (相互秘密保持契約書。 Mutual Non-Disclosure Agreement) などのサードパーティと情報を安全に共有する上で役立つ情報の周知を受けていない。
  • その他色々。

OAudit を有効にすると、ユーザーは、各サードパーティアプリに関連するリスクが理解しやすいように視覚化された通知を受け取ります。これには、リスクの説明がわかりやすく記載されています。各 Scope は機密情報を共有するリスクに基づいたスコアを割り当てられ、それを想起する色で表記されています。

この機能を有効にした後、アプリの使用が安全かどうかというユーザーからの質問が、著しく増えました。アプリケーションセキュリティチームへのサードパーティアプリのレビューの依頼もさらに増えました。また、エンジニア組織外のチームからの連絡も受け取りました。これまでは、技術職ではないユーザーが、サードパーティのツールの使用に不安を感じても、その理由を説明する技術・セキュリティ上の知識が不足していたのです。

ソリューション:データ共有

ユーザーは、スプレッドシートの見栄えをよくしたり、メールでのマーケティングキャンペーンを有効にしたり、Google フォームの結果を自身に送信したりするために、Google Apps にツールを追加します。

一般的なユーザーには、こうした統合は GSuite 側ではなくサードパーティ側のサーバーに存在するということは、知られていません。あるユーザーは、Google が各アプリを入念に検査していると思い込んでいます。また、別のユーザーは、一度サードパーティの機器にデータが渡ってしまうと、規約を超えた、細かい使用法や共有方法に対しては管理できないという事に気付いていません。GDPR に対応しなければならない企業にとっては、この問題はセキュリティ以上の問題となり、規制しなければならなくなります。

OAudit Toolbox の利用は、リスクの高いデータ共有の概念を周知するのに役立ちました。同時に、プライバシー規約と契約書を管理するチームと連携して、適切な同意書を必要な場合には用意し、社内の審査で却下されたアプリへのアクセスを取り消せるようになりました。ブラックリストを利用して認証されていない(けれど悪意のない)アプリへのアクセス権限の取り消しを遡って行うことも、これらのアプリの機能はデータの抜き取りには直結していなかったので、それなりに効果がありました。

ソリューション:データの抜き取りについて

安全で便利なサードパーティアプリが存在する一方で、2017 年に Google Docs をめぐり起きたフィッシング攻撃のような、便利なツールを装った悪意のあるアプリも存在します。

悪意のあるアプリのアクセスは、いつでも拒否できますが、これらのアプリはデータの抜き取りやアカウントの悪用をすぐに実行する可能性が高く、このような対処の効果はわずかなものです。また、この方法の信頼性は、トークンのログの遅れにも依存します。このタイムラグは、Google ドキュメントのフィッシング攻撃の際には、12 時間の遅れがありました。もっと最近では、トークンのアクティビティのタイムラグは 1 – 10 分ですが、Google は数時間にのぼることもあると明言しています。

OAuth Toolbox は Elasticsearch にもデータを送信するので、Indeed で ElastAlertWatcher の設定を推奨しています。これらは、これまでに見たことのないアプリが認証されていたり、一つのアプリが短期間で認証される数が急激に増加していたりする場合に、検知します。

問題が起きる前にユーザーに危険について警告するので、OAudit Toolbox は、IPS (侵入防止システム) のような事前にブロックするものというより、IDS (侵入検知システム) と呼ばれる、悪意のあるアプリに対する早期警報装置のようなものになっています。

ソリューション:利用可能なツール

OAuth Toolkit の開発が始まった頃、アプリのアクセスを拒否する機能は GSuite の中の色々な場所に点在していました。 Google Apps の管理者は Marketplace のアプリ、Drive API、そして Chromeの拡張機能をブロックすることができました。私たちがそれを実際にうまく実装するには、手荒すぎるものでした。ソリューションが不完全だったので、最小限の費用対効果では管理するのは難しかったのです。

Google でも今は Drive や Gmail、コンタクトなどの Google Apps への OAuth のアクセスを、Google 管理者セキュリティパネルでブロックできるようになりました。オプションとして、「リスクの高い」Scopeのみをブロックすることも可能ですが、どのScopeのリスクが高いかを示すドキュメンテーションはありません。信頼できるアプリの使用許可を行うホワイトリストは利用可能です。

このホワイトリストは、もしチームで以下の準備が揃えば、便利な追加機能となるでしょう。

  • 使用中の全てのアプリをブロックする。
  • ホワイトリストに入れるべきものを把握している。
  • 新しいアプリケーションを承認するためのワークフローが存在している。
  • アプリ審査のためのアプリケーションセキュリティの資料を持っている。

Googleがこれらの措置を講じているのは喜ばしいことですが、OAudit Toolkit は、もっと簡単に実装し、ワークフローをそこまで崩さないソリューションを私たちにもたらしました。

ソリューション:ポリシー文化

このツールの実装とそれに続くレビューの工程にとって一番のハードルとなったのは、技術的な部分ではなく、人と関わる部分でした。オープンな「各自好きなアプリを持ち込みOK」な文化から、より規制のある、一見するとお役所仕事のようなプロセスへと移行するのは、困難なものでした。透明性が自社の企業文化にとって重要な要素とされているので、なおさらです。

私たちは、以下のような施策が役立つことを学びました。

  • (OAudit Toolbox などの) ツールや研修、テックトーク、そして社内ブログの記事を使用して、ユーザーにサードパーティアプリが引き起こすリスクを紹介する。
  • 山のような法律用語を利用規定に追加する代わりに、ユーザーが実行しなければいけないアクションをシンプルにまとめ、イントラネットのホームページや、社内 wiki、または IT サポートのランディングページなど、簡単にアクセスできるページで閲覧可能にする。
  • 「メールの統合」や「スプレッドシートの自動化」などのカテゴリーで、よく使われる高いリスクのツールをバケット化する。こうすることで、50件の異なるアプリを調査するのではなく、認証された一つのアプリとこれらのアプリをより簡単に交換が可能。
  • 一晩では問題を解決できないということを受け入れる。もし、一部のアプリのアクセスを継続して許可したり、新しいアプリを認証したり、規制したりすることで問題を軽減することしかできないとしても、今までよりは良い状況になる。

OAudit Toolboxをご活用ください

私たちの経験が皆さんにも役立つように、OAudit Toolbox をオープンソースとして公開しました。組織の教育を向上し、次に起こりうるフィッシング攻撃に対して備えるために、このブログに記載したような手順で自社の Google Suite に統合してみてはいかがでしょうか。悪者たちを出し抜いて、せめて私たちの手の届く範囲でウェブを安全な場所にしていきたいと思います。


(この記事は英語版から翻訳されました。原文:Improving Security with OAudit Toolbox