Google インフラストラクチャのセキュリティ設計の概要

このコンテンツの最終更新日は 2023 年 6 月で、作成時点の状況を表しています。お客様の保護の継続的な改善のために、Google のセキュリティ ポリシーとシステムは変更される場合があります。

はじめに

このドキュメントでは、Google の技術インフラストラクチャのセキュリティ設計の概要について説明します。このドキュメントは、セキュリティ管理者、セキュリティ アーキテクト、監査者を対象としています。

このドキュメントの内容は次のとおりです。

  • Google のグローバル技術インフラストラクチャは、Google の情報処理ライフサイクル全域でセキュリティを確保するように設計されています。このインフラストラクチャにより、次のことが可能になります。
    • サービスの安全なデプロイ
    • エンドユーザーのプライバシー保護によるデータの安全な保管
    • サービス間の安全な通信
    • インターネット経由でのユーザーとの安全でプライベートな通信
    • Google エンジニアによる安全な運用
  • このインフラストラクチャを使用して、インターネット サービス（Google 検索、Gmail、Google フォトなどの一般ユーザー向けサービス、Google Workspace や Google Cloud などの企業向けサービス）を構築する方法。
  • Google のインフラストラクチャと運用を保護するための投資。セキュリティとプライバシーを専門とする数多くのエンジニアが Google 全域に配置されています。業界の権威と認められているエンジニアも多数存在します。
  • セキュリティ要件を満たすために Google 内部に実装したイノベーションから生まれたセキュリティ プロダクトとサービス。たとえば、BeyondCorp は、ゼロトラスト セキュリティ モデルの内部実装から直接生まれたプロダクトです。

  • プログレッシブ レイヤでインフラストラクチャのセキュリティをどのように設計するか。これらのレイヤには次のものがあります。

以降のセクションでは、セキュリティ レイヤについて説明します。

下位インフラストラクチャの保護

このセクションでは、Google のデータセンターの物理施設、データセンターのハードウェア、ハードウェア上で稼働するソフトウェア スタックを保護する方法について説明します。

物理施設のセキュリティ

Google では、複数の物理層セキュリティを組み込んだ独自のデータセンターを設計し、構築しています。これらのデータセンターへのアクセスは厳重に管理されています。複数の物理セキュリティ レイヤを使用して、データセンターのフロアを保護しています。Google では、生体認証、金属検知、カメラ、車両障害物、レーザーによる侵入検知システムなどを導入しています。詳細については、データセンターのセキュリティをご覧ください。

また、一部のサーバーはサードパーティのデータセンターにホストされています。これらのデータセンターでは、データセンター オペレーターが提供するセキュリティ レイヤに加えて、Google が管理する物理的なセキュリティ対策が講じられています。たとえば、データセンターのオペレーターが提供するセキュリティ レイヤとは別に、生体認証識別システム、カメラ、金属探知機を設置しています。

ハードウェアの設計と供給元

Google データセンターは、ローカル ネットワークに接続された何千台ものサーバーで構成されています。Google では、サーバーボードやネットワーク機器の設計も行っています。Google は、提携するコンポーネント ベンダーを入念に調査し、コンポーネントを慎重に選択しています。Google では、コンポーネントによって提供されるセキュリティ特性をベンダーと協力して監査および検証しています。また、サーバー、デバイス、周辺機器にデプロイするハードウェア セキュリティ チップ（Titan と呼ばれる）などのカスタムチップも設計しています。これらのチップは、正規の Google デバイスをハードウェア レベルで識別して認証し、ハードウェアのルート オブ トラストとして機能します。

ブートスタックとマシン ID のセキュリティ

Google サーバーはさまざまな技術を使用して、適切なソフトウェア スタックを起動しています。Google では、ベースボード管理コントローラ（BMC）、BIOS、ブートローダー、カーネル、ベース オペレーティング システム イメージなどの下位コンポーネントに暗号署名を使用しています。これらの署名は、ブートまたは更新サイクルごとに検証できます。Google サーバーの最初の整合性チェックでは、ハードウェアのルート オブ トラストが使用されます。これらのコンポーネントは Google が管理、構築し、整合性証明書で強化しています。Google では、新しい世代のハードウェアごとにセキュリティを継続的に改善しています。たとえば、サーバー設計の世代に応じて、ブートチェーンのルート オブ トラストは次のいずれかになります。

  • Titan ハードウェア チップ
  • ロック可能なファームウェア チップ
  • 独自のセキュリティ コードを実行するマイクロコントローラ

データセンター内の各サーバーには独自の ID が設定されています。この ID は、ハードウェアのルート オブ トラストと、マシンが起動するソフトウェアに関連付けることができます。この ID は、マシン上の下位管理サービスとの間でやり取りされる API 呼び出しの認証に使用されます。この ID は、相互サーバー認証と転送暗号化にも使用されます。Google では、インフラストラクチャ内のリモート プロシージャ コール（RPC）通信を保護するために、Application Layer Transport Security（ALTS）システムを開発しました。これらのマシン ID は、セキュリティ インシデントに対応するために一元的に取り消すことができます。また、証明書と鍵は定期的にローテーションされ、古いものは取り消されます。

Google では、次のことを行うために自動システムを開発しました。

  • サーバーで常にソフトウェア スタックの最新バージョン（セキュリティ パッチを含む）が実行されることを保証する。
  • ハードウェアまたはソフトウェアの問題を検出して診断する。
  • 確認済みの起動証明書と暗黙的な証明書を使用してマシンと周辺機器の整合性を維持する。
  • 目的のソフトウェアとファームウェアを実行しているマシンのみが、本番環境ネットワーク上で通信できる認証情報にアクセスできることを保証する。
  • 不要になったマシンをサービスから削除するか、再割り当てする。

サービスのデプロイのセキュリティ

Google サービスは、デベロッパーが Google のインフラストラクチャ上で作成して実行するアプリケーション バイナリです。Google サービスの例としては、Gmail サーバー、Spanner データベース、Cloud Storage サーバー、YouTube 動画トランスコーダ、カスタム アプリケーションを実行する Compute Engine VM などがあります。必要な規模のワークロードを処理するために、何千ものマシンが同じサービスのバイナリを実行している場合があります。Borg というクラスタ オーケストレーション サービスがインフラストラクチャ上で直接実行されるサービスを制御します。

インフラストラクチャは、インフラストラクチャで実行されているサービス間の信頼を前提としません。この信頼モデルは、ゼロトラスト セキュリティ モデルと呼ばれます。ゼロトラスト セキュリティ モデルのデフォルトでは、ネットワーク内外にかかわらず、デバイスやユーザーは信頼されません。

インフラストラクチャはマルチテナントとして設計されているため、ユーザー（消費者、企業、Google 独自のデータ）のデータは共有インフラストラクチャ全体に分散されます。このインフラストラクチャは、数万台の同種のマシンで構成されています。インフラストラクチャは、顧客データを単一マシンまたはマシンのセットに分離することはありません。ただし、Google Cloud を使用して Compute Engine の単一テナントノードに VM をプロビジョニングする場合など、特定の状況を除きます。

Google Cloud と Google Workspace は、データ所在地に関する規制要件に対応しています。データ所在地と Google Cloud の詳細については、データ所在地と主権の要件を実装するをご覧ください。データ所在地と Google Workspace の詳細については、データ リージョン: データの地理的な保管場所を選択するをご覧ください。

サービス ID、整合性、分離

サービス間の通信を可能にするため、アプリケーションは暗号認証と認可を使用します。認証と認可により、管理者とサービスが認識できる抽象化レベルと粒度で強力なアクセス制御が提供されます。

サービスは、主要なセキュリティ メカニズムとして、内部ネットワークのセグメンテーションやファイアウォールに依存していません。IP スプーフィングを防ぐため、ネットワーク内のさまざまなポイントで上り（内向き）と下り（外向き）のフィルタリングを行っています。このアプローチは、ネットワークのパフォーマンスと可用性の最大化にも役立ちます。Google Cloud の場合、VPC Service Controls や Cloud Interconnect などのセキュリティ メカニズムを追加できます。

インフラストラクチャ上で動作する各サービスには、サービス アカウント ID が関連付けられます。サービスには、RPC を作成または受信するときに、他のサービスに対する ID の証明に使用できる暗号認証情報が付与されます。これらの ID はセキュリティ ポリシーで使用されます。セキュリティ ポリシーは、クライアントが意図したサーバーと通信していることと、特定のクライアントがアクセスできるメソッドとデータをサーバーが制限することを保証します。

Google では、同じマシン上で動作している他のサービスからサービスを保護するために、さまざまな分離手法とサンドボックス化手法を使用しています。これらの手法には、Linux ユーザーの分離、言語ベース（Sandboxed API など）とカーネルベースのサンドボックス、コンテナ用アプリケーション カーネル（gVisor）、ハードウェア仮想化などがあります。一般に、よりリスクの高いワークロードには、より多くの分離レイヤを使用します。リスクの高いワークロードには、追加の処理が必要なユーザー指定項目が含まれます。たとえば、リスクの高いワークロードとしては、ユーザー提供データに対する複雑なファイル コンバータの実行や、App Engine や Compute Engine などのプロダクトに対するユーザー指定コードの実行などがあります。

セキュリティを強化するため、クラスタ オーケストレーション サービスや一部の鍵管理サービスなどの機密性の高いサービスは専用のマシンでのみ動作します。

Google Cloud では、ワークロードに対してより強力な暗号分離を提供し、使用中のデータを保護するために、Compute Engine VM と Google Kubernetes Engine（GKE）ノードに対して Confidential Computing サービスをサポートしています。

サービス間アクセスの管理

サービスの所有者は、インフラストラクチャが提供するアクセス管理機能を使用して、通信可能な他のサービスを正確に指定できます。たとえば、あるサービスで、着信 RPC を他のサービスの許可リストのみに制限できます。このサービスはサービス ID の許可リストで構成でき、インフラストラクチャは自動的にこのアクセス制限を適用します。適用には、監査ロギング、理由、一方的なアクセス制限（エンジニア リクエストなど）が含まれます。

サービスにアクセスする必要がある Google エンジニアにも個別の ID が発行されます。サービスは、ID に基づいてアクセスを許可または拒否するように構成できます。これらの ID（マシン、サービス、社員）はすべて、インフラストラクチャが維持するグローバルな名前空間内にあります。

これらの ID を管理するため、インフラストラクチャには承認チェーン、ロギング、通知を含むワークフロー システムが用意されています。たとえば、セキュリティ ポリシーによってマルチパーティの承認を適用できます。このシステムには 2 人ルールが採用されており、単独で行動するエンジニアは、権限を持つ他のエンジニアの承認がなければ、機密性の高い操作を行うことができません。このシステムを使用すれば、安全なアクセス管理プロセスをインフラストラクチャ上で動作する何千ものサービスに拡張できます。

また、このインフラストラクチャは、ユーザー、グループ、メンバーシップを管理するための正規サービスを提供するために、必要に応じて、カスタムできめ細かいアクセス制御を実装できます。

Google Workspace でのエンドユーザー データのアクセス管理で説明されているように、エンドユーザー ID は個別に管理されます。

サービス間通信の暗号化

このインフラストラクチャは、ネットワーク上の RPC データの機密性と整合性を提供します。すべての Google Cloud 仮想ネットワーク トラフィックは暗号化されます。インフラストラクチャ サービス間の通信はすべて認証され、ほとんどのサービス間通信は暗号化されます。これにより、セキュリティをさらに強化して、ネットワークが盗聴されたり、ネットワーク機器が侵害されたりしても通信を保護できます。サービス間通信の暗号化要件に対する例外が認められるのは、低レイテンシの要件があるトラフィックで、かつ Google のデータセンターの複数の物理的セキュリティ レイヤ内に単一のネットワーク ファブリックが残されない場合のみです。

インフラストラクチャは、データセンター間のネットワークを経由するインフラストラクチャ RPC トラフィックにエンドツーエンドの暗号化を、（ハードウェア オフロードを使用して）自動的かつ効率的に提供します。

Google Workspace でのエンドユーザー データのアクセス管理

標準的な Google Workspace サービスは、エンドユーザーのために何かをするように作られています。たとえば、エンドユーザーは、Gmail 上に自分のメールを保存しておくことができます。Gmail などのアプリケーションとエンドユーザーとのやり取りは、インフラストラクチャ内の他のサービスにも及ぶ可能性があります。たとえば、Gmail はエンドユーザーのアドレス帳にアクセスするために People API を呼び出す場合があります。

サービス間通信の暗号化では、別のサービス（Gmail など）からの RPC リクエストを保護するようにサービス（Google コンタクトなど）を設計する方法について説明します。ただし、Gmail は任意のユーザーの連絡先をいつでもリクエストできるため、このレベルのアクセス制御には引き続き広範な権限が使用されています。

Gmail がエンドユーザーに代わって Google コンタクトに RPC リクエストを行うと、インフラストラクチャによって Gmail は RPC リクエストにエンドユーザー権限チケットを提示できます。このチケットは、Gmail が特定のエンドユーザーの代わりに RPC リクエストを作成していることを証明するものです。これより、Google コンタクトがチケットで指定されたエンドユーザーのデータのみを返すように安全保護対策を実装できます。

インフラストラクチャには、これらのエンドユーザー コンテキスト チケットを発行する中央のユーザー ID サービスがあります。ID サービスがエンドユーザーのログインを確認し、Cookie や OAuth トークンなどのユーザー認証情報をユーザーのデバイスに発行します。デバイスからインフラストラクチャへの後続のリクエストでは、そのエンドユーザー認証情報を提示する必要があります。

サービスはエンドユーザー認証情報を受け取ると、検証のためにその認証情報を ID サービスに渡します。エンドユーザー認証情報が検証されると、ID サービスは有効期間が短いエンドユーザー コンテキスト チケットを返します。このチケットは、ユーザーのリクエストに関連する RPC に使用できます。この例では、エンドユーザー コンテキスト チケットを取得するサービスは Gmail であり、チケットは Google コンタクトに渡されます。それ以降は、どのようなカスケード呼び出しに対しても、呼び出し側のサービスは、RPC の一部としてエンドユーザー コンテキスト チケットを呼び出し側に送信できます。

次の図は、サービス A とサービス B の通信を示しています。このインフラストラクチャは、サービス ID、自動相互認証、暗号化されたサービス間通信、サービス オーナーによって定義されたアクセス ポリシーの適用を可能にします。各サービスには、サービス オーナーが作成するサービス構成があります。暗号化されたサービス間通信の場合、自動相互認証は呼び出し元と呼び出し先の ID を使用します。通信は、アクセスルールの構成で許可されている場合にのみ可能です。

サービス A とサービス B の通信を示す図。

Google Cloud でのアクセス管理については、IAM の概要をご覧ください。

Google Cloud でのエンドユーザー データのアクセス管理

Google Workspace でのエンドユーザー データのアクセス管理と同様に、インフラストラクチャはサービス アカウントを認証するための中央のユーザー ID サービスを提供し、サービス アカウントが認証された後に、エンドユーザー コンテキスト チケットを発行します。通常、Google Cloud サービス間のアクセス管理は、エンドユーザー コンテキスト チケットではなく、サービス エージェントを使用して行います。

Google Cloud では、Identity and Access Management（IAM）と Identity-Aware Proxy などのコンテキストアウェア プロダクトを使用して、Google Cloud 組織内のリソースへのアクセスを管理します。Google Cloud サービスへのすべてのリクエストでは、IAM を通じて権限が確認されます。

アクセス管理プロセスは次のとおりです。

  1. Google Front End サービス、またはお客様の VM の Cloud Front End サービスを通じて、リクエストが到着します。
  2. リクエストが中央のユーザー ID サービスに転送されます。中央のユーザー ID サービスで認証チェックが行われ、エンドユーザー コンテキスト チケットが発行されます。
  3. また、リクエストは次の項目をチェックするためにもルーティングされます。
  4. これらのチェックすべてに合格すると、Google Cloud バックエンド サービスが呼び出されます。

Google Cloud でのアクセス管理については、IAM の概要をご覧ください。

データ ストレージのセキュリティ

このセクションでは、インフラストラクチャに保存されているデータのセキュリティを実装する方法について説明します。

保存時の暗号化

Google のインフラストラクチャは、さまざまなストレージ サービスと分散ファイル システム（Spanner や Colossus など）と中央の鍵管理サービスを提供します。Google 上のアプリケーションは、ストレージ インフラストラクチャを使用して物理ストレージにアクセスします。保存されているデータを保護するために、複数の暗号化レイヤが使用されています。デフォルトでは、ユーザーデータが物理ストレージに書き込まれる前に、ストレージ インフラストラクチャはすべてのユーザーデータを暗号化します。

インフラストラクチャは、アプリケーションまたはストレージ インフラストラクチャ レイヤで暗号化を実行します。暗号化により、インフラストラクチャは、ストレージの下位レベルでの潜在的な脅威（悪意のあるディスク ファームウェアなど）からインフラストラクチャ自体を分離できます。該当する場合、Google ではハードドライブと SSD 内のハードウェア暗号化サポートを有効にし、すべてのドライブをそのライフサイクルを通して細かく追跡しています。廃棄予定の暗号化されたストレージ デバイスは、物理的に管理対象外になる前に、2 回の独立した検証を含む多段階プロセスを使用してクリーニングされます。このクリーニング プロセスに合格していないデバイスは、オンプレミスで物理的に破壊（細断）されます。

インフラストラクチャの暗号化に加えて、Google Cloud と Google Workspace には鍵管理サービスが用意されています。Google Cloud の場合、Cloud KMS は、お客様が暗号鍵を管理できるようにするクラウド サービスです。Google Workspace の場合は、クライアントサイド暗号化を使用できます。詳しくは、Google Workspace でのクライアントサイド暗号化とコラボレーション強化をご覧ください。

データの削除

通常、データの削除は実際にデータを削除するのではなく、特定のデータを削除対象としてマークすることから始まります。このアプローチにより、ユーザーが開始したのか、バグが原因なのか、または内部プロセスエラーが原因なのかに関係なく、意図しない削除から回復することが可能になります。削除予定としてマークされたデータは、サービス固有のポリシーに従って削除されます。

エンドユーザーがアカウントを削除すると、インフラストラクチャはアカウントが削除されたことをエンドユーザー データを処理するサービスに通知します。その後、削除されたエンドユーザー アカウントに関連付けられたデータを削除するようにスケジューリングできます。この機能により、エンドユーザーは自分のデータを制御できます。

詳細については、Google Cloud 上のデータの削除をご覧ください。

インターネット通信のセキュリティ

このセクションでは、インターネットと Google インフラストラクチャ上で実行されるサービスの間の通信を保護する方法について説明します。

ハードウェアの設計と供給元で説明したように、インフラストラクチャは、LAN と WAN で相互接続された多数の物理マシンで構成されています。サービス間通信のセキュリティは、ネットワークのセキュリティに依存しません。ただし、インフラストラクチャはインターネットからプライベート IP アドレス空間に分離されています。サービス拒否攻撃（DoS）に対する防御などの追加の保護を実装できるように、マシンのサブセットを直接外部のインターネット トラフィックに公開しています。

Google Front End サービス

サービスをインターネット上で利用可能にする必要がある場合、それを Google Front End（GFE）と呼ばれるインフラストラクチャ サービスに登録する必要があります。GFE は、すべての TLS 接続が正しい証明書を使用し、完全な前方秘匿性のサポートなどのベスト プラクティスに沿って終端されることを保証します。GFE は、DoS 攻撃に対する保護も適用します。その後、GFE は Google Workspace でのエンドユーザー データのアクセス管理で説明されている RPC セキュリティ プロトコルを使用して、サービスのリクエストを転送します。

実際には、外部に公開する内部サービスでは、GFE がスマートなリバース プロキシ フロントエンドとして使用されます。GFE は、パブリック DNS 名、DoS 保護、TLS 終端のパブリック IP アドレス ホスティングを提供します。GFE は、他のサービスと同様のインフラストラクチャ上で動作し、着信リクエストの量に合わせてスケーリングできます。

Google Cloud のユーザーの VM は GFE に登録されません。代わりに、Cloud Front End に登録されます。Cloud Front End は、Compute Engine ネットワーキング スタックを使用する GFE の特別な構成です。Cloud Front End では、お客様の VM がパブリック IP アドレスまたはプライベート IP アドレスを使用して Google サービスに直接アクセスできます（プライベート IP アドレスは、限定公開の Google アクセスが有効な場合にのみ使用できます）。

DoS 対策

インフラストラクチャの規模が大きいため、多数の DoS 攻撃を吸収できます。サービスに対する DoS の影響のリスクを軽減するため、Google では多層型の DoS 防御を提供しています。

光ファイバー バックボーンが Google のデータセンターのいずれかに外部接続を提供すると、接続はハードウェアとソフトウェアのロードバランサの複数のレイヤを通過します。これらのロードバランサは、インフラストラクチャ上で動作している中央の DoS サービスへの受信トラフィックに関する情報を報告します。中央の DoS サービスが DoS 攻撃を検出すると、攻撃に関連付けられたトラフィックを破棄または抑制するようにロードバランサを構成できます。

GFE インスタンスは、中央の DoS サービスに受信したリクエストに関する情報も報告します。この情報には、ロードバランサがアクセスできないアプリケーション レイヤの情報も含まれます。その後で、中央の DoS サービスが、攻撃トラフィックを破棄または抑制するように GFE インスタンスを構成できます。

ユーザー認証

DoS 防御の後、安全な通信を実現するため、中央の ID サービスによって次の防御レイヤが追加されます。エンドユーザーは、Google ログインページでこのサービスを操作します。このサービスではユーザー名とパスワードを求められます。また、リスク要因に基づいて追加情報をユーザーに求めることもできます。リスク要因の例としては、ユーザーが同じデバイスからログインしたかどうか、同様の場所からログインしたことがあるかどうか、などがあります。ユーザーの認証後は、ID サービスが、以降の呼び出しに使用可能な Cookie や OAuth トークンなどの認証情報を発行します。

ユーザーがログインするときに、OTP などの第 2 要素や、Titan セキュリティ キーなどのフィッシング耐性のあるセキュリティ キーを使用できます。Titan セキュリティ キーは、FIDO Universal 2nd Factor（U2F）をサポートする物理トークンです。Google は FIDO Alliance で U2F のオープン規格の策定を支援しました。ほとんどのウェブ プラットフォームとブラウザで、このオープン認証標準が採用されています。

オペレーション セキュリティ

このセクションでは、Google がインフラストラクチャ ソフトウェアを開発して、社員のマシンと認証情報を保護し、内部と外部の両方の脅威からインフラストラクチャを防御する方法について説明します。

安全なソフトウェアの開発

Google では、前述のソース管理の保護と二者レビュー プロセスに加えて、デベロッパーが特定のクラスのセキュリティ バグを発生させないようにライブラリを使用しています。たとえば、ウェブアプリの XSS 脆弱性を排除するのに役に立つライブラリとフレームワークが用意されています。また、ファザーなどの自動ツール、静的解析ツール、ウェブ セキュリティ スキャナを使用して、セキュリティ バグを自動的に検出します。

最終チェックとして、リスクの低い機能に対する迅速な選別から、最もリスクの高い機能に対する綿密な設計・実装レビューまで、手作業によるセキュリティ レビューを実施しています。これらのレビューを行うチームには、ウェブ セキュリティ、暗号、オペレーティング システム セキュリティの専門家が含まれています。このレビューは、新しいセキュリティ ライブラリ機能の開発や、今後のプロダクトに使用できる新しいファザーの開発につながる可能性があります。

さらに、インフラストラクチャやアプリケーションのバグを発見して報告した人に報奨金を出す脆弱性報奨金プログラムも実施しています。Google が提供している特典など、このプログラムの詳細については、Bug Hunters の主要な統計情報をご覧ください。

また、Google が使用するオープンソース ソフトウェアに対するゼロデイ エクスプロイトなどのセキュリティ問題の発見にも取り組んでいます。Google では、Spectre と Meltdown など、ゼロデイ脆弱性の研究に取り組む Google の研究者チーム Project Zero を運営しています。また、Google は Linux KVM ハイパーバイザの CVE とセキュリティ バグの修正の最大の提出者でもあります。

ソースコードの保護

Google のソースコードは、整合性とガバナンスを備えたリポジトリに格納されています。このリポジトリでは、サービスの最新バージョンと古いバージョンの両方を監査できます。インフラストラクチャでは、サービスのバイナリをレビュー、チェックイン、テストした後に特定のソースコードからビルドする必要があります。Binary Authorization for Borg（BAB）は、サービスがデプロイされたときに実行される内部適用チェックです。BAB では次の処理が行われます。

  • Google にデプロイされた本番環境のソフトウェアと構成が（特にそのコードがユーザーデータにアクセスできる場合に）確認され、承認されていることを確認します。
  • コードと構成のデプロイが特定の最小基準を満たしていることを確認します。
  • インサイダーや攻撃者がソースコードに悪意のある変更を加えないよう制限して、サービスからそのソースまでの監査証跡も提供します。

社員のデバイスと認証情報の保護

Google では、社員のデバイスと認証情報を侵害から保護するために安全対策を実装しています。社員を高度なフィッシング詐欺から保護するため、OTP の 2 要素認証に代わり、U2F 互換のセキュリティ キーの使用を必須にしました。

Google では、社員がインフラストラクチャの運用に使用するクライアント デバイスをモニタリングしています。これらのデバイスのオペレーティング システム イメージがセキュリティ パッチを含む最新版であることを保証し、社員がデバイスにインストールできるアプリケーションを管理しています。また、ユーザーがインストールしたアプリケーション、ダウンロード、ブラウザの拡張機能、ウェブブラウザのコンテンツをスキャンして、デバイスが企業デバイスに適しているかどうかを判断しています。

社内 LAN に接続されていることは、アクセス権を付与するための主要な仕組みではありません。代わりに、リソースへの社員のアクセスを保護するためにゼロトラスト セキュリティを使用しています。アプリケーション レベルでのアクセス管理により、社員が管理対象デバイスを使用して、予期されるネットワークと地理的な場所から接続している場合にのみ、内部アプリケーションを社員に公開できます。クライアント デバイスは、個々のマシンに対して発行される証明書と、その構成（最新のソフトウェアなど）に関するアサーションに基づいて信頼されます。詳細については、BeyondCorp をご覧ください。

インサイダー リスクの低減

インサイダー リスクとは、Google のネットワーク、システム、データへのアクセス権を現在持っているか過去に持っていた従業員、元従業員、請負業者、その他のビジネス パートナーが、そのアクセスを悪用して Google の情報システム、または情報システムの機密性、完全性、可用性を侵害する可能性のことです。

インサイダー リスクを軽減するため、Google ではインフラストラクチャへの管理者権限が付与された従業員のアクティビティを制限し、積極的にモニタリングしています。Google では、同じタスクを安全で管理された方法で自動的に実行する処理を行うことで、特定のタスクに対する特権アクセスの必要性を排除する努力を続けています。Google は、機密データを公開せずにデバッグできる制限付き API を公開しています。また、人間のオペレータが行う特定の機密性の高いアクションには、二者の承認が必要です。

エンドユーザー情報への Google 社員のアクセスは、下位インフラストラクチャ フックを介して記録されます。Google のセキュリティ チームがアクセス パターンを監視し、異常なイベントを調査しています。詳細については、Google Cloud の特権アクセス管理（PDF）をご覧ください。

Google は、インサイダー リスクからサプライ チェーンを保護するために Binary Authorization for Borg を使用しています。また、BeyondProd への投資は、Google インフラストラクチャのユーザーデータの保護と Google サービスに対する信頼の確立に役立っています。

Google Cloud では、アクセスの透明性を使用してデータへのアクセスをモニタリングできます。アクセスの透明性のログを使用することにより、Google の担当者によるお客様データへのアクセスは、サービス停止の修復やサポート リクエストへの対応など、ビジネス上の正当な理由がある場合に限られていることを確認できます。また、Access Approval により、Cloud カスタマーケアやエンジニアリングがお客様のデータにアクセスする必要がある場合に明示的な承認が求められるようになります。この承認は、アクセス承認の整合性を確保するために暗号的に検証されます。

脅威のモニタリング

Google の Threat Analysis Group は脅威アクターと、その戦術と技術の進化をモニタリングします。このグループの目的は、Google プロダクトの安全性とセキュリティを改善し、オンライン コミュニティのメリットを得るためにこの情報を共有することです。

Google Cloud の場合は、Google Cloud Threat Intelligence for Google Security Operations と VirusTotal により、さまざまな種類のマルウェアをモニタリングし、対処できます。Google Cloud Threat Intelligence for Google Security Operations は、Google Security Operations で使用する脅威インテリジェンスを開発する脅威研究者のチームです。VirusTotal は、企業内でのマルウェアの動作を詳細に把握できるマルウェア データベースと可視化ソリューションです。

脅威モニタリング活動の詳細については、Threat Horizons レポートをご覧ください。

侵入検知

Google では、高度なデータ処理パイプラインを使用して、個々のデバイスでのホストベースの信号、インフラストラクチャ内のさまざまなモニタリング ポイントからのネットワーク ベースの信号、インフラストラクチャ サービスからの信号を統合しています。これらのパイプライン上に構築されたルールとマシン インテリジェンスにより、セキュリティ エンジニアは潜在的なインシデントの警告を確認できます。Google の調査およびインシデント対応チームは、これらの潜在的なインシデントを年中無休で選別、調査、対応しています。Google では、検出メカニズムと対応メカニズムの有効性を評価して改善するための Red Team 訓練を実施しています。

次のステップ