Snap が堅牢なゼロトラスト フレームワークを構築するために BeyondCorp Enterprise を選んだ理由

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

Snapchat の開発元である Snap Inc. は「カメラが人々の生活やコミュニケーションの方法を改善する最大の機会を提供する」を信条とするテクノロジー企業です。クラウド生まれの Snap は、Google Cloud を使用して最新のソーシャル メディア フレームワークを提供しています。

2023 年に入って行われた Google Cloud と Snap の発表には、Snap が AI、ML、セキュリティ サービスをはじめとするより多くのワークロードに Google Cloud を選択することなど、関係拡大に関する内容が盛り込まれています。これらのクラウド ワークロードを保護するための重要な側面の一つがゼロトラスト アクセス フレームワークであり、Snap のクラウドへの取り組みにおいて不可欠な要素となっています。

Snap のコーポレート セキュリティ エンジニアリング責任者である Nick Reva 氏は次のように述べています。「Beyond Corp Enterprise（BCE）は、当社のコーポレート セキュリティ プログラムの中心部分を担っています。Snap はクラウド生まれの企業として、ほぼ VPN を使用せずに Snap の社内サービスに「どこからでも安全に」アクセスできるようにプログラムを設計しました。Google とのパートナーシップにより、BCE を社内サービスに拡張して統合することで、企業のインベントリのデバイス メンバーシップと全体的な健全性に基づいてアクセスを決定するメカニズムが提供されます。これは、Google Cloud の信頼とセキュリティに支えられた、BCE が提供する比類のない機能です。」

「コンテキスト」の課題

Snap は、Google Cloud の BeyondCorp Enterprise（BCE）を使用して、ウェブ アプリケーションを保護するという課題に対処することにしました。同社のセキュリティ エンジニアリング チームは、以前に内製開発で HTTP リバース プロキシを設計し、すべてのアプリケーションに認可を適用していました。より堅牢かつ安全なゼロトラスト ベースのシステムを構築するために、さまざまなユーザー グループやさまざまな種類のデバイスに合わせて設定できる、デバイスのコンテキスト情報に基づいたきめ細かなアクセス制御ポリシーが必要でした。しかし、Snap には、デバイスの属性を収集し、認可に活用するメカニズムが欠けていたのです。

BCE は、世界中のどこからでもアプリケーションやリソースに安全にアクセスできるようにします。Google のグローバル ネットワーク インフラストラクチャを活用することで、企業はネットワーク インフラストラクチャのスケーリングと管理についての懸念を最小限に抑えながら、世界中からアクセスできるようアプリケーションをデプロイできます。

これには、デバイス属性の収集、コンテキストアウェア アクセス ポリシーの定義、最新のゼロトラスト ネットワーク アクセス制御を可能にするグローバルにデプロイされたポリシー適用エンジンで構成される、堅牢なデバイス証明書のフレームワークが含まれます。BCE のコア コンポーネントの一つに、Identity-Aware Proxy（IAP）と呼ばれるアクセス プロキシがあります。

IAP は、ユーザーベースおよびプログラムによるリソースへのアクセスをサポートし、管理者が JSON Web Token（JWT）でカスタムクレームを使用できるようにします。管理者はこの機能を活用して追加情報を限定公開アプリケーションに転送し、ゼロトラスト インフラストラクチャのセキュリティとカスタマイズを強化できます。

Google と Snap の共同作業

Snap の内製開発の HTTP プロキシ設計は、複数のカスタム認証方法をサポートしているため、そこから Google IAP に全面的に移行するのは困難でした。たとえば、同社のカスタム認証方法の一つである Lightweight Client Auth（LCA）は、現在も Google IAP と統合されていない内製開発ソリューションです。また、Snap は他のサードパーティ認証ツールも IAP に組み込まないことを選びました。

Google Cloud は、Snap のプロダクション チームおよびコーポレート セキュリティ エンジニアリング チームと協力し、ゼロトラスト基準と Snap の要件を満たすアーキテクチャを設計しました。IAP を内製開発の HTTP プロキシの前に配置するという単純なアプローチでしたが、実装は複雑でした。IAP は、すべてのユーザーがバックエンド サービスにアクセスできるように設定されていました。IAP を通過したユーザーは、Snap の内製開発の HTTP プロキシで認証されなければなりません。BCE はデバイスの属性を取得し、IAP はこの情報をすべてのリクエストに付加して、内製開発の HTTP プロキシに送信されるリクエストを強化します。

ゼロトラストの実現に向けたコンテキスト リッチなシステム

IAP が内製開発の HTTP プロキシにリクエストを転送することで、Snap は BCE の基本機能を使用して、社内の既存の適用エンジンを活用できるようになりました。新しいアーキテクチャでは、IAP がリクエストをデバイスとその収集した属性に関連付け、それらを特定のポリシーに関連付けることができます。このリクエストはその後、ポリシーの評価と認可のために、内製開発の HTTP プロキシにプロキシされます。IAP がカスタム認証を含むすべてのリクエストを透過的に内製開発の HTTP プロキシに渡し、そこでポリシー適用が行われるため、Snap のバックエンド サービスに必要な、重要なカスタム認証が維持されます。   

Snap は、複数の内製開発のデバイス インベントリ システムを使用しており、その一部は社内専用であるため、すでに BCE と統合されている BeyondCorp Alliance のメンバーが提供するプロダクトには含まれません。BCE のデバイス インベントリを最新の状態に保つためには、BCE の API を使用した統合メカニズムが使われます。内製開発のカスタムビルドのサービスにより、BCE のデバイス インベントリと社内の Snap インベントリとの同期が維持され、必要に応じてデバイスの追加や削除が行われます。

Google Cloud のサポートにより、Snap は Snap の社内サービスへのアクセスを制限することができ、社内サービスには会社所有のデバイスからしかアクセスできなくなりました。Snap は、新しいデバイス インベントリにある数万ものデバイス オブジェクトにアクセス ポリシーを適用できるほか、数千の企業エンドポイントからデータを収集し、可視化できます。また、同社はデータ損失防止（DLP）、マルウェアやフィッシングの防止など、BCE の追加機能の使用を拡大し、活用することを計画しています。

BeyondCorp Enterprise とゼロトラスト アクセスの詳細については、ドキュメントをご確認ください。Identity-Aware Proxy の活用方法の詳細については、技術ドキュメントをご覧ください。