オープンソースコミュニティへの貢献を続けるIndeed は、この度Apache ソフトウェア財団 (ASF) のスポンサーに就任しました。2018年の初めには、クラウド・ネイティブ・コンピューティング・ファウンデーション (CNCF) に加入し、 Python ソフトウェア財団のスポンサーに就任したことをお知らせしましたが、これはIndeedのオープンソースへの取り組みの第一歩に過ぎません。

ASF の議長である Phil Steitz 氏からは｢Indeed をゴールドスポンサーとして迎えることができて、わくわくしています。彼らのオープンソースへの支援に本当に感謝しています。というコメントをいただきました。Steitz 氏はさらに、「この支援によって、何千人というボランティアに機会を与え、何億人ものユーザーに素晴らしいソフトウェアを提供することが可能になるので、プロジェクトはさらに発展を遂げるでしょう。」と続けました。

Apache ソフトウェア財団は、幅広いオープンソースソフトウェアのホームです。Apache Mesos や Apache Commons などの Indeed の組織を多くの分野で支えている多種多様なソフトウェアがあります。また、Apache ソフトェア財団はインターネットを動かす重要なソフトウェアに中立したホームを提供しています。このような理由から、同財団のスポンサーとなるのは自然な決断でしたが、業界の他社企業と共にスポンサーリストに名を連ねることができ、光栄です。財政面だけでなく、技術的なコントリビュータとしても長期的に貢献していきたいと考えています。

今後もさらにオープンソースコミュニティに積極的に参加しながら、Indeed ではその他の提携や・スポンサーシップや、同様の組織への参加を、継続して検討していきます。

---

Indeed におけるオープンソースプロジェクトへの最新情報は、オープンソースのサイトからご覧いただけます。Indeed でのオープンソース関連の求人に興味をお持ちの場合は、採用ページをご覧ください。

独立したチームは、Indeed の開発において不可欠なものです。急成長をし続ける組織として、チーム間での依存性の数を減らすように努力しており、チームのデプロイのインフラを各チームに管理させています。こうすることで、開発の速度、品質、そして、アーキテクチャの大規模化などを得ることができます。

Apache Mesos は、運営上のボトルネックを削減し、そして各チームが各プロダクトへの裁量をさらに持つための手助けをしてくれます。

運営上のボトルネック

初期の Indeed は、人の手でアプリケーションのプロビジョニングと設定を行っていました。新しいアプリケーションができる度に、オペレーションチームにリクエストを送信し、この新しいアプリケーションが実行できるだけの容量があるサーバーを探して貰っていました。何も見つからなかった場合には、オペレーションチームは新しい仮想マシンを投入したり、追加サーバーを発注したりしていました。新規アプリケーションのプロビジョニングには、最長で 2 か月ほどかかっていました。

その後に続くデプロイはより短時間で済む、オペレーションチームから独立した作業でしたが、初めのプロビジョニングの行程が問題でした。このことから、開発者はアプリケーションデザインを代償にして開発速度を最適化するようになりました。時間のかかる新しいアプリケーション作成に着手するよりも、サービスをつなぎ合わせていく方が簡単だったので、アプリケーションは膨れ上がりモノリシックになっていきました。しかし、これでは大規模化できなかったため、何かを変える必要がありました。

Mesos の導入

3年ほど前に、Indeed は Mesos を利用し始めました。これにより、各チームには、担当アプリケーションの設定、デプロイ、そして監視する裁量が与えられました。現在は、アプリケーションが CPU、メモリ、ディスクをさらに必要とする場合には、担当チームがそれらを追加します。こうしたプロセスの利点は以下のようなことが挙げられます。

管理者が不要になる。これにより、開発速度があがり、スケーラブルなアーキテクチャとしての傾向が強化されました。

担当チームがアプリケーションのパファーマンスプロファイルを把握できる。各チームは、CPU、メモリ、ディクスの数などを指定する必要があるので、予想されるパフォーマンス、トラブルシューティング、そして改善できる部分について、熟知するようになりました。

信頼性が強化された。 サーバーが落ちた際に、アプリケーションは別の場所で再起動するので、エンジニアが個々のインスタンスを管理しなくて済むようになりました。

Indeed における Mesos のエコシステム

Mesos 単体では、確実にアプリケーションを実行できるわけではありません。私たちの Mesos のエコシステムは、多くのオープンソースプロジェクトと、チームがシームレスに開発出来るように作られた自社アプリケーションが統合されています。

デーモンのための Marathon

Indeed では、デーモンを実行するために Marathon を使用しています。ただし、ほとんどの開発者はこの事に気づいていません。Indeed は 10 か所のデータセンターで稼働していますが、 Marathon はそのうちの 1 か所でのみ実行されているため、全データセンター間のデプロイを調整する Marvin と呼ばれるシステムを作りました。開発者は独立して自身のリソース要件、実行するアプリケーションのバージョン、インスタンスの数、そして実行するデータセンターを指定します。そして、定義された設定と Marathon の設定を比較してくれるエージェントが各データセンター内で実行されます。もしそれらが一致しなければ、エージェントは直接 Marathon と連携し、インスタンスの大規模化・縮小化や、新しいデプロイを開始します。

バッチと単発ジョブ用の内製ツール

また、私たちは大量のバッチや、 ｢単発｣ のジョブを実行します。Marathon はこうしたユースケースには適していないため、Orc と言う Marathon と同様の Mesos のフレームワークを開発しました。これは、以前はオペレーションチームがタスクの担当をしていたような、上記のようなジョブを設定し予約するものです。このツールを開発したことで、最後にアクセスしたホストをできるだけ使うようにするなどの複数の最適化が出来るようになりました。これは Indeed の Resilient Artifact Distribution （RAD。障害発生時に回復機能を持つアーティファクトの分散）システムともうまく連携し、必要なデータの近くでジョブが実行されます。開発者はまた必要なタイミイングでジョブが実行されるように予約設定をすることが可能です。

Orcはバッチと単発ジョブの設定と実行予約を行うツールである。

ロードバランシングには HAProxy

Marathon が、異なるサーバー上や異なるポート上の新しいインスタンスを常に提示するので、これらインスタンスへのアクセスを簡単に行える方法が必要でした。その有名なパフォーマンスの特性から、 HAProxy をリバースプロキシとして使用しています。デーモンがどこで実行されているか検知し、一致する HAProxy の設定を生成する小さなアプリケーションを作りました。設定が変更されると、Runtime API を使用して、HAProxy の動的な更新を試みます。これが不可能な場合、パケットやリクエストが全く失われずに済むシームレスリロードのメカニズムを使用して、 HAProxy を再起動します。

設定には Vault

最後に、Indeed ではアプケーションを設定するのに堅牢な方法を必要としています。Indeed のほとんどのアプリケーションがシンプルでフラットなプロパティファイルで設定されています。Mesos 導入以前では、各データセンターにプロパティファイルを配布するために Puppet を使用していました。しかし、これは各チーム内で完結できない作業であり、タイムラグが数多く発生していました。速度を上げ、各チームが安全にそして担当アプリケーションを自分で設定するのを簡単にするために、機密情報を管理する HashiCorp 社のプロダクト、Vault に関連したシステムをデザインしました。アプリケーション実行の前に、プロパティを取得するための有効期限の短いトークンを生成します。Marvin のデーモンがこれを実行できるように小さな Marathon のプラグインを作り、また、Orc がバッチのジョブを処理できるように手を加えました。

結果: 独立したチームとスケール可能なアプリケーション

これらの変更はデプロイにかかる時間を 14% 削減しました。さらには、プロビジョニングに要する時間を数ヶ月から数分にまで削減し、開発チームが担当アプリケーションに、より責任を持てるようになりました。

設定とデプロイのチケットが急激に減少し、設定のチケットの解決までの平均時間が 15~6 日から 3~4 日にまで減少しました。結果として、オペレーションチームは、サイト信頼性のエンジニアリング技術を作成するためにリソースの割り当て直すなど、さらに急を要する案件などにフォーカスできるようになりました。

現在、私たちは Mesos 上での Docker のコンテナ型になったデプロイの実現にむけて取り組んでいます。開発者はいずれ、Docker イメージを自身で作動させ、脆弱性のスキャンを自動で行い、そして簡単にコンテナ型になったアプリケーションを自社のクラウド上でデプロイできるようになります。こうした進歩を目前に、Indeed では、エンジニアリングチームが独立してスケール可能なアプリケーションを開発できるように、引き続き新しい機能を Mesos 上で有効にしていきたいと思います。

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 で ElastAlert や Watcher の設定を推奨しています。これらは、これまでに見たことのないアプリが認証されていたり、一つのアプリが短期間で認証される数が急激に増加していたりする場合に、検知します。

問題が起きる前にユーザーに危険について警告するので、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）