Google Cloud での転送データの暗号化

これは Google が暗号化によってどのようにデータを保護しているかに関する 3 番目のホワイトペーパーです。このほか、Google Cloud Platform での保存データの暗号化と、G Suite の暗号化も公開しています。これらのドキュメントをあわせてお読みいただくと、Google による暗号化の利用についての理解に役立ちます。このホワイトペーパーでは、Google Cloud Platform や G Suite を含む Google Cloud での転送データの暗号化について詳しく説明します。

Google ではすべての Google サービスで、顧客データを高度に保護するとともに、セキュリティ保護の方式についても可能な限り透明性を確保するよう努めています。

このドキュメントの内容は 2017 年 12 月時点のものです。このホワイトペーパーは作成時点の状況を表しています。お客様の保護の継続的改善のため、Google Cloud のセキュリティ ポリシーおよびシステムは適宜変更される場合があります。

再生ボタン

Google Cloud による転送データの暗号化

CIO レベルの概要

  • Google では転送データの信頼性、整合性、プライバシーを確保するために、さまざまなセキュリティ対策を採用しています。
  • すべての転送データは、Google が管理している物理的境界または Google のために管理されている物理的境界の外へ出るときに、1 つ以上のネットワーク レイヤで暗号化され認証されます。このような物理的境界の内部で転送されるデータは、認証されますが、必ずしも暗号化されるとは限りません。
  • 確立される接続に応じて、転送データにはデフォルトの保護が適用されます。たとえば、ユーザーと Google Front End(GFE)間の通信は TLS を使用して保護されます。
  • WAN 経由でのデータの暗号化について追加要件がある Google Cloud のお客様は、データがユーザーからアプリケーション、または仮想マシンから仮想マシンへと移動する際に、追加の保護を実装できます。こうした保護には、IPsec トンネル、Gmail S/MIME、マネージド SSL 証明書、Istio などがあります。
  • Google は業界と積極的に協力して、誰もがどこからでも転送データの暗号化を利用できるように努めています。Google には Certificate Transparency(証明書の透明性)、Chrome API、セキュアな SMTP など、転送データの暗号化の利用とインターネット上でのデータ セキュリティを促進する複数のオープンソース プロジェクトがあります。
  • Google は今後も引き続き、転送データの暗号化における業界リーダーの地位を維持していく予定です。この目的のため、Google は暗号化技術の開発と改善に向けてリソースを投入しています。この分野における Google の努力は、Key Transparency やポスト量子暗号の分野における革新にも表れています。

はじめに

多くの場合、セキュリティはパブリック クラウド プロバイダを選ぶ際の重要な決定要因となります。Google では、セキュリティを最も重要な項目と見なしています。Google はデータ保護のためのたゆまぬ努力を続けており、それはインターネット上を流れるデータでも、Google のインフラストラクチャ内を移動するデータでも、Google のサーバーに保存されているデータでも同様です。

Google のセキュリティ戦略の中心にあるのは、保存データと転送データ両方の認証、整合性、暗号化です。このドキュメントでは、Google Cloud での転送データの暗号化に関するアプローチを説明します。

保存中のデータについては、Google Cloud Platform での保存データの暗号化をご覧ください。Google のセキュリティ全体の概要については、Google インフラストラクチャのセキュリティ設計の概要をご覧ください。

対象: このドキュメントは、Google Cloud を使用しているまたはその使用を検討している、CISO およびセキュリティ運用チームを対象としています。

前提条件: 読者はこの概要の知識に加えて、暗号化および暗号プリミティブについても基本的な理解を有していることを前提とします。

認証、整合性、暗号化

Google では転送データの信頼性、整合性、プライバシーを確保するために、さまざまなセキュリティ対策を採用しています。

  • 認証: データソース(人間またはプロセス)と宛先を検証します。
  • 整合性: ユーザーが送信したデータが変更されることなく宛先に到着することを確認します。
  • 暗号化: 転送中のデータは判読不能にして機密性を維持します。暗号化とは、読み取り可能なデータ(プレーンテキスト)を読み取り不能(暗号テキスト)にするプロセスであり、その目的はプレーンテキストへのアクセスをデータの所有者が許可したユーザーのみに限定することです。暗号化プロセスに使用されるアルゴリズムは公開されていますが、暗号テキストを解読するために必要な鍵は未公開になっています。転送データの暗号化では多くの場合、楕円曲線ベースの Diffie-Hellman 鍵のような非対称鍵交換を使用して、データ暗号化に利用する共有対称鍵を確立します。暗号化の詳細については、最新の暗号の概要をご覧ください。

暗号化は以下の 3 種類の状態にあるデータの保護に使用できます。

  • 保存データの暗号化: 保存中のデータを暗号化することで、システム侵害やデータ漏洩からデータを保護します。保存データの暗号化には、Advanced Encryption Standard(AES)がよく利用されます。
  • 転送データの暗号化: データがユーザーのサイトとクラウド プロバイダの間、または 2 つのサービスの間を移動する際に、通信が傍受された場合、そのデータを保護します。この保護は、送信前にデータを暗号化し、各エンドポイントを認証し、到着時にデータを解読して検証することで実現されます。たとえば、転送時のセキュリティを確保するための転送データの暗号化には Transport Layer Security(TLS)が、メール メッセージのセキュリティ確保には Secure/Multipurpose Internet Mail Extensions(S/MIME)がよく使用されます。
  • 使用中データの暗号化: サーバーによるコンピューティングの実行に使用されているデータを保護します(例: 準同型暗号化など)。

暗号化は広範なセキュリティ戦略の一部です。転送データを暗号化すると、次のような理由で、接続が確立され認証された後に潜在的な攻撃者からデータを保護できます。

  • 一般に第三者によって提供されている、ネットワークの下位レイヤを信頼する必要がなくなる
  • 攻撃される可能性のある範囲が縮小する
  • 通信が傍受された場合に、攻撃者によるデータへのアクセスが防止される

適切な認証、整合性、暗号化を利用すると、悪意ある環境においても、ユーザー、端末、プロセスの間を移動するデータを保護できます。以降のセクションでは、転送データの暗号化に対する Google のアプローチと、それがどこで適用されているかを説明します。

Google のネットワーク インフラストラクチャ

Google のネットワークの物理的境界

データが Google が管理しているまたは Google のために管理されている物理的境界の外に送信された場合、Google では転送中のデータにさまざまな保護を適用しています。物理的境界は Google が管理しているまたは Google のために管理されている物理スペースの障壁であり、そこでは Google が厳格なセキュリティ対策を講じることができます。この場所への物理的なアクセスは制限され、厳重に監視されています。ハードウェアにアクセスできるのは、Google のごく一部の社員のみです。こうした物理的境界の内部で転送中のデータは、通常は認証されますが、デフォルトで暗号化はされない場合があります。ユーザーは脅威モデルに基づいて、追加で適用するセキュリティ対策を選択できます。

インターネットの世界的な規模のため、Google の WAN 内のファイバー リンクや、Google が管理しているまたは Google のために管理されている物理的境界の外で、この同じ物理的セキュリティ制御を施行することはできません。このため Google では、物理的な信頼境界の外では自動的に追加の保護を実施しています。こうした保護には転送データの暗号化も含まれます。

トラフィックのルーティング方法

前のセクションでは、Google のネットワークの物理的境界と、その境界の外に送信されるデータに対してどのようにさまざまな保護が適用されるかについて説明しました。Google における転送データの暗号化の仕組みを完全に理解するには、トラフィックがインターネット内をどのようにルーティングされるかも知っておく必要があります。このセクションでは、リクエストがエンドユーザーから適切な Google Cloud サービスまたは顧客アプリケーションにどのように伝達されるか、およびサービス間でトラフィックがどのようにルーティングされるかを説明します。

Google Cloud サービスは、Google がお客様に提供するモジュール式クラウド サービスです。これにはコンピューティング、データ ストレージ、データ分析、機械学習などのサービスがあります。たとえば、Google Cloud Storage と Gmail はどちらも Google Cloud サービスです。顧客アプリケーションは Google Cloud でホストされるアプリケーションで、Google のお客様であるユーザーが、Google Cloud サービスを利用して構築およびデプロイできます。Google Cloud でホストされている顧客アプリケーションやパートナー ソリューションは、Google Cloud サービスとはみなされません1。たとえば、ユーザーが Google App Engine、Google Kubernetes Engine、または Google Compute Engine の VM を使用して構築したアプリケーションは、顧客アプリケーションになります。

図 1 は、以下に説明する 5 種類のルーティング リクエストを示したものです。この図はさまざまなネットワーク コンポーネントと、それぞれの接続に適用されるセキュリティとのインタラクションを示しています。

エンドユーザー(インターネット)から Google Cloud サービスへの通信

Google Cloud サービスは、Google Front End(GFE)という全世界に分散したシステムを利用して、世界中からのリクエストを受信します。GFE は着信する HTTP(S)、TCP、TLS プロキシのトラフィックを終了し、DDoS 攻撃対策を提供し、Google Cloud サービス自体へのトラフィックをルーティングおよび負荷分散します。GFE の拠点は全世界にあり、ルートはユニキャストまたはエニーキャスト経由でアドバタイズされています。

GFE は Google Cloud サービスへのトラフィックをプロキシします。GFE はユーザーのリクエストを、Google のネットワーク バックボーンを介して Google Cloud サービスにルーティングします。この接続は、Google が管理しているまたは Google のために管理されている物理的境界を離れるときに、GFE から Google Cloud サービスのフロントエンドまたは顧客アプリケーションに対して認証され暗号化されます。図 1 にこのインタラクションを示します(接続 A)。

エンドユーザー(インターネット)から Google Cloud でホストされている顧客アプリケーションへの通信

インターネットからのトラフィックを、ユーザーが Google Cloud でホストしている顧客アプリケーションにルーティングする方法はいくつかあります。トラフィックのルーティング方法は、以下に説明するように、構成によって異なります。図 1 にこのインタラクションを示します(接続 B)。

  • Google Cloud HTTP(S) または TCP/SSL プロキシ Load Balancer の外部ロードバランサを使用する場合: Google Compute Engine VM でホストされている顧客アプリケーションは、Google Cloud Load Balancer(GCLB)サービスを使用して HTTP(S)、TLS、TCP の接続を終了し、そのトラフィックを VM にプロキシ、ルーティング、分散できます。こうしたロードバランサ サービスは、GFE が Google Cloud サービスのトラフィックを終了しルーティングするのと同様に、GFE によって実装されます。接続は GCLB が GFE 間のトラフィックをルーティングするときに認証され、トラフィックが Google が管理しているまたは Google のために管理されている物理的境界を離れるときに暗号化されます。GCLB が GFE と顧客の VM をホストする物理マシンとの間でトラフィックをルーティングする場合、このトラフィックは Google が管理しているまたは Google のために管理されている物理的境界を離れるときに認証され暗号化されます。HTTPS ロードバランサの場合、エンドユーザーと GFE 間の接続は、顧客がロードバランサに提供した証明書を使用して TLS または QUIC で暗号化され認証されます。HTTP ロードバランサの場合、エンドユーザーと GFE 間の接続は暗号化も認証もされません。SSL ロードバランサの場合、エンドユーザーと GFE 間の接続は、顧客が提供した証明書を使用して同様に TLS で暗号化されます。TCP ロードバランサの場合、エンドユーザーと GFE の間で暗号化は行われません。ただし顧客のアプリケーションは、エンドユーザーと VM の間で独自の暗号化を行う場合があります。
  • 外部 IP またはネットワーク ロードバランサ IP を利用した VM への直接接続を使用する場合: VM の外部 IP 経由、またはネットワーク負荷分散 IP 経由で接続する場合、その接続は GFE を経由しません。この接続はデフォルトでは暗号化されず、セキュリティはユーザーの裁量で実装されます。
  • Cloud VPN を使用する場合: 顧客施設のホストから VPN 経由で Google Cloud VM に接続する場合、その接続はオンプレミス ホストで発着信するほか、オンプレミス VPN、Google VPN、Google Cloud VM に着信し、GFE を経由しません。接続はオンプレミス VPN から Google VPN まで、IPsec を使用して保護されます。Google VPN から Google Cloud VM への接続は、その通信が Google が管理しているまたは Google のために管理されている物理的境界を離れるときに認証され暗号化されます。
  • Cloud Dedicated Interconnect を使用する場合: Dedicated Interconnect を使用して接続する場合、接続はオンプレミス ホストで直接発着信され、GFE を経由しません。この接続はデフォルトでは暗号化されず、セキュリティはユーザーの裁量で実装されます。Transport Layer Security(TLS)レイヤ 7 暗号化プロトコルを使用して、専用インターコネクトを介したアプリケーショントラフィックを暗号化できます。

仮想マシンから仮想マシンへの通信

Google のネットワーク バックボーンで、RFC1918 のプライベート IP アドレスを使用して行われる仮想マシン(VM)同士の間でのルーティングでは、Google が管理しているまたは Google のために管理されている物理的境界の外にトラフィックをルーティングしなければならない場合があります。VM 間ルーティングの例には次のようなものがあります。

  • Compute Engine の仮想マシン同士が相互にリクエストを送信する場合
  • 顧客の VM が Cloud SQL のような Google 管理 VM に接続する場合

VM から VM への接続は物理的境界を離れる場合に暗号化され、物理的境界内で認証されます。パブリック IP アドレスを使用した VM から VM へのトラフィックは、デフォルトでは暗号化されず、セキュリティはユーザーの裁量で実装されます。図 1 にこのインタラクションを示します(接続 C)。

仮想マシンから Google Cloud サービスへの通信

VM がリクエストを Google Cloud サービスにルーティングする場合、リクエストは GFE にルーティングされます(Google Cloud サービスが前述のように Google 管理 VM で実行されている場合を除く)。GFE はリクエストを受信すると、そのリクエストをインターネットからのリクエストと同様にルーティングします。VM から Google Cloud サービスへのトラフィックの場合は、Google の非公開パスを経由して、GFE と同じパブリック IP にルーティングされます。プライベート Google アクセスでは、パブリック IP のない VM が、Google App Engine でホストされている一部の Google Cloud サービスや顧客アプリケーションにアクセスできます(VM が Google Compute Engine または Google Kubernetes Engine でホストされている顧客アプリケーションに接続する場合、そのトラフィックはインターネットからのリクエストが外部パス経由でルーティングされるのと同じ方法でルーティングされます)。図 1 にこのインタラクションを示します(接続 D)。このようなルーティング リクエストの例としては、Compute Engine VM から Google Cloud Storage に対して、または Machine Learning API に対して行われるものがあります。Google Cloud サービスはデフォルトで、TLS によるこうした接続の保護をサポートしています2。この保護は VM から GFE まで実施されます。接続は GFE からサービスまで認証され、接続が物理的境界を離れる場合には暗号化が行われます。

Google Cloud サービスから Google Cloud サービスへの通信

ある本番環境サービスから別の本番環境サービスへのルーティングは、Google のネットワーク バックボーン上で行われ、場合によっては Google が管理しているまたは Google のために管理されている物理的境界の外にトラフィックをルーティングしなければならないことがあります。図 1 にこのインタラクションを示します(接続 E)。この種のトラフィックの一例は、Google Cloud Functions をトリガーする Google Cloud Storage イベントです。本番環境サービス間の接続は、物理的境界を離れる場合は暗号化され、認証は物理的境界内で行われます。

図 1: Google のネットワークにおけるデフォルトおよびオプションの保護

デフォルトでの転送データの暗号化

Google では転送中のデータに対し、デフォルトとユーザー構成の両方によるさまざまな暗号化方式を使用しています。使用される暗号化のタイプは、OSI レイヤ、サービスのタイプ、およびインフラストラクチャの物理コンポーネントによって異なります。下の図 2 と図 3 は、Google Cloud でレイヤ 3、4、7 のために用意されているオプションとデフォルトの保護を示しています。

図 2: Google Cloud 全体のレイヤ 3 および 4 におけるデフォルトとオプションの保護

図 3: Google Cloud 全体のレイヤ 7 におけるデフォルトとオプションの保護3

このセクションの残りの部分では、Google で転送中のデータを保護するために使用されるデフォルトの保護について説明します。

ユーザーから Google Front End への通信の暗号化

今日、多くのシステムは HTTPS プロトコルを使用してインターネット上での通信を行っています。HTTPS は TLS 接続全体にプロトコルを指示することでセキュリティを実現し、リクエストとレスポンスの信頼性、整合性、プライバシーを確保しています。HTTPS リクエストを受け入れるには、受信者が公開鍵 / 秘密鍵のペアと、サーバー認証用の認証局(CA)からの X.509 証明書を持っていなければなりません。この鍵ペアと証明書は、受信者がリクエスト対象のドメイン名を所有していることを証明するもので、アプリケーション レイヤ(レイヤ 7)でユーザーのリクエストを保護するのに役立ちます。以下のサブセクションでは、TLS、BoringSSL、Google の認証局といった、ユーザーから GFE への暗号化の要素について説明します。顧客のパスがすべて GFE を経由するわけではないことに注意してください。GFE は特に、ユーザーから Google Cloud サービスへのトラフィック、およびユーザーから Google Cloud 上でホストされている顧客アプリケーション(Google Cloud Load Balancing を使用)へのトラフィックに使用されます。

Transport Layer Security(TLS)

ユーザーが Google Cloud サービスにリクエストを送信すると、Google では HTTPS プロトコルとウェブ(パブリック)認証局からの証明書を使用して認証、整合性、暗号化を実現することで、転送中のデータが保護されます。ユーザーが GFE に送信したデータは、Transport Layer Security(TLS)または QUIC を利用して転送中に暗号化されます。GFE はクライアントが何をサポートできるかに応じて、特定の暗号化プロトコルをクライアントとネゴシエートします。GFE は可能な限り、より近代的な暗号化プロトコルをネゴシエートします。

GFE の拡張された TLS 暗号化は、エンドユーザーの Google との通信に適用されるだけでなく、TLS による Google との API 通信(Google Cloud を含む)も容易にします。さらに Google の TLS 暗号化は、Gmail で外部メールサーバーとメールを交換するためにも使用されています(詳細は Gmail での TLS 要件をご覧ください)。

Google は TLS の採用とその導入強化の両方において業界をリードしています。このため Google では、TLS のセキュリティ機能の多くをデフォルトで有効化しています。たとえば 2011 年以降は、TLS 実装で前方秘匿性を使用しています。前方秘匿性により、接続を保護する鍵は永続化されなくなるため、1 つのメッセージを傍受して読み取った攻撃者が以前のメッセージを読み取ることはできません。

BoringSSL

BoringSSL は Google が維持管理する TLS プロトコルのオープンソース実装であり、OpenSSL から分岐したもので、OpenSSL とほぼインターフェース互換性があります。Google は OpenSSL から BoringSSL を分岐することで、内部使用のためおよび Chromium と Android オープンソース プロジェクトのサポートを強化するために、OpenSSL を簡略化しました。BoringSSL のコアである BoringCrypto は、FIPS 140-2 レベル 1 の認定を受けています。

GFE の TLS は BoringSSL によって実装されています。表 1 は、GFE でクライアントとの通信の際にサポートされる暗号化プロトコルを示しています。

プロトコル 認証 鍵交換 暗号化 ハッシュ関数
TLS 1.34 RSA 2048 Curve25519 AES-128-GCM SHA384
TLS 1.2 ECDSA P-256 P-256(NIST secp256r1) AES-256-GCM SHA256
TLS 1.1     AES-128-CBC SHA18
TLS 1.05     AES-256-CBC MD59
QUIC6     ChaCha20-Poly1305  
      3DES7  

表 1: Google Front End で Google Cloud Services 用に実装され、BoringSSL 暗号ライブラリで実装される暗号化

Google の認証局

TLS の一環として、サーバーは接続リクエストを受信したときに、ユーザーに対して自身の ID を証明する必要があります。この ID 確認は TLS プロトコルで行われ、サーバーが要求された ID を含む証明書を提示することで成功します。証明書にはサーバーの DNS ホスト名と公開鍵の両方が含まれます。提示された証明書は、接続をリクエストしたユーザーが信頼する発行元の認証局(CA)によって署名されます10。この結果、サーバーへの接続をリクエストしたユーザーは、ルート CA を信頼するだけで済みます。サーバーが普遍的なアクセスを許可するには、ルート CA が世界中のクライアント端末に知られている必要があります。現在、ほとんどのブラウザや他の TLS クライアント実装には、それぞれ独自の「ルートストア」で信頼できるものと構成された独自のルート CA セットがあります。

Google ではこれまで、独自の発行元 CA を運用し、それを使用して Google ドメインの証明書に署名していました。ただし、独自のルート CA は運用していませんでした。現在 Google の CA 証明書は、Symantec(「GeoTrust」)や以前 GlobalSign が運営していたルート(「GS Root R2」と「GS Root R4」)を含む、普遍的に分散した複数のルート CA によって相互署名されています。

Google は 2017 年 6 月、今後は Google 所有のルート CA を使用していくことを発表しました。長期的には、普遍的に分散したルート CA を運用し、そこで Google ドメインおよびお客様の証明書を発行することを計画しています。

ルート鍵の移行と鍵のローテーション

新しいルート CA に移行する際は、すべてのブラウザと端末にその証明書の信頼を埋め込む必要があり、これには長い時間がかかるため、ルート CA の鍵は頻繁には変更されません。そのため、現在 Google では独自のルート CA を運用しているものの、移行期間中は今後も引き続き複数の第三者のルート CA に依存して、独自の CA に移行するまでの間、レガシー端末の認証を行う予定です。

新しいルート CA を作成するには、キーセレモニーを行う必要があります。Google では、このセレモニーには 6 名の許可された担当者のうち最低 3 名が物理的に集まり、金庫に保管されたハードウェア キーを使用することを義務づけています。このメンバーは電磁干渉から保護された専用の部屋に集まり、エアギャップ式のハードウェア セキュリティ モジュール(HSM)を使用して、一連の鍵と証明書を生成します。この専用の部屋は Google データセンター内の安全な場所にあります。プロセスを計画どおりに進めるため、物理的なセキュリティ対策、カメラ、他の人による観察などという追加的な管理も行われます。セレモニーが成功した場合、生成された証明書は発行者名、公開鍵、署名を除いて、サンプル証明書と同一になります。結果として得られたルート CA 証明書は、ブラウザおよび端末のルート プログラムに送信され組み込まれます。このプロセスは、鍵が 10 年以上その信頼性を維持できるよう、関連する秘密鍵のプライバシーとセキュリティが十分に理解されるように設計されています。

前述のように、CA は秘密鍵を使用して証明書に署名し、次にその証明書が、ユーザー セッションの一部として TLS handshake を開始するときに ID を確認します。サーバー証明書は中間 CA で署名されます。中間 CA の作成方法は、ルート CA の作成と同様です。中間 CA の証明書は TLS セッションの一部として配布されるため、新しい中間 CA に移行するほうが容易です。この配布方法により、CA オペレータはルート CA 鍵のマテリアルをオフライン状態に保つこともできます。

TLS セッションのセキュリティは、サーバーのキーがどれだけ安全に保護されているかによって異なります。キー侵害のリスクをさらに軽減するため、Google の TLS 証明書の有効期間は約 3 か月に制限されており、証明書は約 2 週間ごとにローテーションされます。

以前サーバーに接続していたクライアントは、秘密のチケットキー11 を使用して、短縮された TLS handshake で以前のセッションを再開できるため、このチケットは攻撃者にとって非常に貴重となります。Google ではチケットキーを少なくとも 1 日に 1 回ローテーションし、3 日ごとにすべてのプロパティでキーを期限切れにしています。セッション キーチケットのローテーションの詳細については、TLS 暗号ショートカットのセキュリティ損害の測定を参照してください。

Google Front End からアプリケーションのフロントエンドへの通信

ユーザーは場合によっては、トラフィックのルーティング方法で説明したように、望ましいサービスおよびそれに関連するアプリケーション フロントエンドとは異なる物理的境界内の GFE に接続することがあります。これが発生した場合、ユーザーのリクエストおよび他のレイヤ 7 プロトコル(HTTP など)は、TLS によって保護されるか、Application Layer Transport Security(ALTS)を使用して保護された RPC にカプセル化されます(サービス間の認証、整合性、暗号化を参照)。これらの RPC は認証され、暗号化されます。

Google Cloud サービスの場合、RPC はデフォルトで ALTS を使用して保護されます。Google Cloud でホストされている顧客アプリケーションの場合は、トラフィックが Google Front End 経由でルーティングされると(Google Cloud Load Balancer を使用している場合など)、VM へのトラフィックは次のセクションで説明する Google Cloud の仮想ネットワーク暗号化を使用して保護されます。

Google Cloud の仮想ネットワーク暗号化と認証

Google Cloud の仮想ネットワーク インフラストラクチャは、トラフィックが Google の物理的境界の外に出るときの暗号化を可能にします。暗号化はネットワーク レイヤで実行され、同じ Virtual Private Cloud(VPC)内またはピアリングされた VPC ネットワーク上でのプライベート IP トラフィックに適用されます。

Google では、Google が管理しているまたは Google のために管理されていない物理的境界を横切るネットワークはいずれも、ネットワーク上のトラフィックをスヌーピング、注入、変更できるアクティブな敵対者によって損なわれる可能性があると想定しています。Google が制御していない物理的境界外にデータが移動するときは、暗号化を使用して通信の完全性とプライバシーを確保しています。

Google では Galois Counter Mode(GCM)の Advanced Encryption Standard(AES)を 128 ビット鍵(AES-128-GCM)とともに使用して、ネットワーク レイヤの暗号化を実装しています。通信するホストのペアはそれぞれ、ALTS によって保護されたコントロール チャネルを介してセッションキーを確立し、認証され暗号化された通信を行います。セッションキーはこうしたホスト間のすべての VM 間通信を暗号化するために使用され、定期的にローテーションされます。

ネットワーク レイヤ(レイヤ 3)では、Google Cloud の仮想ネットワークが VM 間のすべてのトラフィックを認証します。この認証はセキュリティ トークンを介して行われ、侵害されたホストがネットワーク上のパケットを偽装するのを防止します。

認証の際、セキュリティ トークンは送信者と受信者に関する認証情報を含むトンネル ヘッダーにカプセル化されます。送信側のコントロール プレーン12 がトークンを設定し、受信側のホストがトークンを検証します。セキュリティ トークンはすべてのフローについて事前に生成されており、トークンキー(送信者の情報を含む)とホストのシークレットで構成されます。Google が管理しているまたは Google のために管理されている物理的境界のすべての送信元 / 受信者ペアについて、それぞれ 1 つのシークレットが存在します。図 4 は、トークンキー、ホスト シークレット、およびセキュリティ トークンの作成方法を示しています。

図 4: セキュリティ トークン

物理的境界のシークレットは 128 ビットの擬似乱数であり、ホスト シークレットはそこから HMAC-SHA1 を導出することで得られます。物理的境界のシークレットは、一対の物理的境界のネットワーク コントロール プレーン間のハンドシェイクによってネゴシエートされ、数時間ごとに再ネゴシエートされます。個々の VM 間認証に使用されるセキュリティ トークンは、これらの情報および他の入力情報から得られる HMAC であり、特定の送信側と受信側のペアについてネゴシエートされます。

サービス間の認証、整合性、暗号化

Google のインフラストラクチャ内のアプリケーション レイヤ(レイヤ 7)では、Google の Application Layer Transport Security(ALTS)を使用して、GFE からサービスへ、およびサービスからサービスへの Google RPC コールの認証、整合性、暗号化を実現しています。

ALTS ではサービス アカウントを使用して認証が行われます。Google のインフラストラクチャで動作する各サービスは、暗号認証情報の関連付けられたサービス アカウント ID として実行されています。他のサービスから RPC を作成または受信する場合、サービスはその認証情報を使用して認証を行います。ALTS はこうした認証情報を、内部認証局を使用して検証します。

Google が管理しているまたは Google のために管理されている物理的境界内では、ALTS が「認証と整合性」モードで RPC の認証と整合性を確認します。これらの物理的境界外の WAN を経由するトラフィックについては、ALTS はインフラストラクチャ RPC トラフィックの暗号化を、「認証、整合性、プライバシー」モードで自動的に実施します。現在、Google Cloud サービスを含む Google サービスへのすべてのトラフィックには、この同じ保護が適用されています。

ALTS はまた、Google Front End からアプリケーション フロントエンドに移動するトラフィックのため、HTTP などの他のレイヤ 7 プロトコルをインフラストラクチャ RPC メカニズムでカプセル化する際にも使用されています。この保護によってアプリケーション レイヤが隔離され、ネットワーク パスのセキュリティに依存する必要がなくなります。

サービスは Google が管理しているまたは Google のために管理されている物理的境界内であっても、「認証、整合性、プライバシー」モードでのみ ALTS 通信の送受信を行うように構成できます。その一例が、Google のインフラストラクチャに保存されているデータを保護するための暗号鍵を保管し管理する Google の内部鍵管理サービスです。

ALTS プロトコル

ALTS には相互 TLS に似た安全なハンドシェイク プロトコルがあります。ALTS を使用して通信しようとする 2 つのサービスは、機密情報を送信する前に、このハンドシェイク プロトコルを使用して通信パラメータを認証およびネゴシエートします。このプロトコルは以下の 2 つのステップによるプロセスになります。

  • ステップ 1: handshake クライアントが Curve25519 を使用して、サーバーとの楕円曲線 Diffie Hellman(ECDH)handshake を開始します。クライアントとサーバーはそれぞれ、証明書の一部として認定済みの ECDH 公開パラメータを有しており、それが Diffie Hellman 鍵交換の際に使用されます。handshake の結果、クライアントとサーバーで利用可能な共通のトラフィック鍵が生成されます。証明書のピア ID はアプリケーション レイヤに表示され、承認の決定に使用されます。
  • ステップ 2: 暗号化の記録 ステップ 1 で得られた共通トラフィック鍵を使用して、クライアントからサーバーにデータが安全に送信されます。ALTS の暗号化は、BoringSSL とその他の暗号化ライブラリを使用して実装されます。暗号化は AES-128-GCM が最も一般的ですが、整合性は AES-GCM の GMAC によって実現されます。

下の図 5 は、ALTS handshake の詳細を示したものです。新しい実装ではプロセス ヘルパーが handshake を行いますが、場合によってはアプリケーションによって直接行われる場合もあります。

図 5: ALTS ハンドシェイク

サービス間の認証、整合性、暗号化セクションの冒頭で説明したように、ALTS はサービス アカウントを使用して認証を行っており、Google インフラストラクチャ上で実行される各サービスは、関連する暗号認証情報を持つサービス ID として実行されています。ALTS ハンドシェイクの際、プロセス ヘルパーは各クライアント / サーバーのペアが通信で使用する秘密鍵とそれに対応する証明書にアクセスします。秘密鍵とそれに対応する証明書(署名付きのプロトコル バッファ)は、サービスのサービス アカウント ID に対してプロビジョニングされています。

ALTS 証明書 ALTS 証明書にはいくつかの種類があります。

  • マシン証明書: 特定のマシンのコアサービスに ID を提供します。これは約 6 時間ごとにローテーションされます。
  • ユーザー証明書: コードを開発する Google エンジニアのエンドユーザー ID を提供します。これは約 20 時間ごとにローテーションされます。
  • Borg ジョブ証明書: Google のインフラストラクチャ内で実行されているジョブに ID を提供します。これは約 48 時間ごとにローテーションされます。

ルート認証書署名鍵は、Google の内部認証局(CA)に保管されています。これは Google の外部 CA とは無関係の独立した認証局です。

ALTS での暗号化

ALTS の暗号化は使用するマシンに応じて、さまざまなアルゴリズムを利用して実装できます。たとえば、大半のサービスでは AES-128-GCM13 が使用されています。ALTS 暗号化の詳細については、表 2 を参照してください。

マシン 使用されるメッセージ暗号化法  
最も一般的 AES-128-GCM  
Sandy Bridge 以前 AES-128-VCM GMAC の代わりに VMAC が使用されており、こうした古いマシンでは若干効率性が向上します。

表 2: ALTS での暗号化

ほとんどの Google サービスでは、ALTS か、ALTS を使用する RPC カプセル化が使用されます。ALTS が使用されない場合は、その他の保護が適用されます。次に例を示します。

  • 一部の低レベルのマシン管理およびブートストラップ サービスでは、SSH を使用します。
  • 一部の低レベルのインフラストラクチャ ロギング サービスでは TLS または Datagram TLS(DTLS)を使用します14
  • 非 TCP トランスポートを使用する一部のサービスは、Google が管理しているまたは Google のために管理されている物理的境界の内部にある場合、他の暗号化プロトコルまたはネットワーク レベルの保護を使用します。

VM と Google Cloud Platform サービスの間の通信では、ALTS ではなく TLS を使用して、Google Front End との通信が行われます。こうした通信については、仮想マシンから Google Front End への通信の暗号化で説明します。

仮想マシンから Google Front End への通信の暗号化

VM から GFE へのトラフィックは外部 IP を使用して Google サービスにアクセスしますが、プライベート Google アクセス機能を構成すると、Google 専用の IP アドレスをリクエストに使用できます。

外部ユーザーから Google へのリクエストと同様、VM から GFE への通信についても、デフォルトで TLS トラフィックがサポートされています。接続は他の外部接続と同じ方法で行われます。TLS の詳細については、Transport Layer Security(TLS)をご覧ください。

転送データの暗号化に関するユーザー構成可能なオプション

転送データの暗号化では、Google が転送データに対して適用しているデフォルトの保護について説明しました。このセクションでは、こうしたデフォルトの保護に関してユーザーが行える構成について説明します。

オンプレミスのデータセンターから Google Cloud への通信

GCLB 外部ロードバランサを利用した TLS

お客様のクラウド サービスが Google HTTPS または SSL プロキシの外部ロードバランサを使用している場合、GFE はお客様がプロビジョニングし管理している SSL 証明書を使用して、サービスのユーザーからの TLS 接続を終了します。証明書のカスタマイズの詳細については、Google の SSL 証明書のドキュメントをご覧ください。

Google Cloud VPN を利用した IPsec トンネル

Google Cloud のお客様は、Google Cloud VPN を使用して、オンプレミス ネットワークを IPsec VPN 接続(レイヤ 3)を介して自身の Google Cloud Platform Virtual Private Cloud(VPC)ネットワークに安全に接続できます。2 つのネットワーク間のトラフィックは一方の VPN ゲートウェイで暗号化され、もう一方の VPN ゲートウェイで復号化されます。これにより、インターネット上でデータが保護されます。また、複数の VPN ゲートウェイを介して、複数の負荷分散されたトンネルを設定できます。Google Cloud VPN では、以下の方法でデータが保護されます。

  • VM から Cloud VPN へのパケットは、Google のネットワーク内に残ります。こうしたパケットは、Google が管理しているまたは Google のために管理されている物理的境界の外に出る場合、Google Cloud の仮想ネットワークによって暗号化されます。
  • Cloud VPN からオンプレミス VPN へのパケットは、IPsec トンネルを使用して暗号化され認証されます。
  • ユーザーのオンプレミス VPN からオンプレミス ホストへのパケットは、ユーザーが設定したネットワーク上の任意のコントロールによって保護されます。

VPN を設定するには、ホスティング サービスの VPC ネットワーク上に Cloud VPN ゲートウェイとトンネルを作成して、ネットワーク間のトラフィックを許可します。またオプションで、2 つの VPC 間に VPN を設定することもできます。

VPN トンネルに Internet Key Exchange15(IKE)バージョンを指定すると、ネットワークをさらにカスタマイズできます。IKE は IKEv1 と IKEv2 の 2 つのバージョンから選択可能で、それぞれが異なる暗号をサポートしています。IKEv1 を指定すると、Google では AES-128-CBC を使用してパケットが暗号化され、SHA-1 HMAC16 を介して整合性が確保されます。IKEv2 の場合は、さまざまな暗号が利用可能でありサポートされています。いずれの場合も、Google Cloud VPN ではピアデバイスがサポートしている最も安全な共通プロトコルがネゴシエートされます。VPN の設定に関する詳細は、Google のドキュメント VPN ルーティング オプションの選択をご覧ください。

IPsec トンネルの代替手段としては、Google Cloud Dedicated Interconnect があります。Dedicated Interconnect は、ユーザーのオンプレミス ネットワークと Google のネットワークの間に直接的な物理接続と RFC1918 通信を提供します。この接続を介して転送されるデータはデフォルトでは暗号化されないため、TLS を利用するなどしてアプリケーション レイヤで保護する必要があります。Google Cloud VPN と Google Cloud Interconnect は同じアタッチメント ポイントを使用するため、Dedicated Interconnect で IPSec VPN 暗号化を利用できますが、これを行うにはサードパーティのソリューションを使用する必要があります。MACsec(レイヤ 2 保護)は現在サポートされていません。

ユーザーから Google Front End への通信

マネージド SSL 証明書: 無料の自動証明書

Google Cloud でアプリケーションを構築する場合は、使用する SSL 証明書を構成することで、GFE の TLS サポートを活用できます。たとえば、アプリケーションで TLS セッションを終了させることができます。この終了は、GCLB 外部ロードバランサを使用した TLS で説明されている TLS 終了とは異なります。

Google ではまた、Firebase HostingGoogle App Engine の両方のカスタム ドメインで、無料の自動 SSL 証明書も提供しています。この証明書は Google がホストするプロパティにのみ使用できます。Google App Engine のカスタム ドメインを使用すると、独自の SSL 証明書を提供し、HTTPS Strict Transport Protocol(HSTS)ヘッダーを使用することもできます。

ドメインが Google のインフラストラクチャをポイントすると、Google からそのドメインの証明書がリクエストされて取得され、安全な通信が可能になります。Google では TLS サーバーの秘密鍵(2048 ビット RSA または secp256r1 ECC のいずれか)を管理し、お客様に代わって証明書を更新しています。

Gmail での TLS 要件

Transport Layer Security のセクションで説明したように、Gmail ではデフォルトで TLS が使用されます。Gmail では、メールの最後のホップが TLS セッション上で行われたかどうかが記録され表示されます17。Gmail ユーザーが別の Gmail ユーザーとメールを交換した場合、それらのメールは TLS によって保護されるか、場合によってはアプリケーション内で直接送信されます。こうした場合、Gmail アプリケーションで使用される RPC は、サービス間の認証、整合性、暗号化で説明したように ALTS で保護されます。Gmail では、他のメール プロバイダからの受信メールには TLS が適用されません。Gmail 管理者は構成により、すべての受信メールと送信メールについて安全な TLS 接続を要求できます。

Gmail S/MIME

Secure/Multipurpose Internet Mail Extensions(S/MIME)は、認証、整合性、暗号化を提供するメールのセキュリティ標準規格です。S/MIME 標準の実装においては、メールを送信するユーザーに関連付けられる証明書は公開 CA でホストすることが義務付けられています。

管理者は Gmail の構成により、送信メールの S/MIME を有効にし、コンテンツと添付ファイルのコンプライアンスに関するポリシーを設定し、受信メールと送信メールのルーティング ルールを作成できます。構成が完了したら、Gmail API を使用してユーザーの公開証明書を Gmail にアップロードする必要があります。Gmail 以外のユーザーの場合は、最初の S/MIME 署名付きメッセージを交換して S/MIME をデフォルトに設定する必要があります。

サービス間および VM 間の通信の暗号化

Istio は、サービスの検出と接続を簡略化するため、Google、IBM、Lyft などが開発したオープンソースのサービス メッシュです。Istio 認証ではサービス間の転送データが自動的に暗号化され、関連する鍵と証明書が管理されます。Istio は Google Kubernetes Engine および Google Compute Engine で使用できます。

ワークロードの相互認証と暗号化を実装する場合は、istio auth を使用できます。具体的には、Kubernetes のワークロードの場合、Istio auth を使用するとクラスタレベルの CA で証明書を生成および配布でき、それらがポッド間の相互 Transport Layer Security(mTLS)に使用されます。

Google によるインターネット上の転送データの暗号化支援

デフォルトでの転送データの暗号化および転送データの暗号化に関するユーザー構成可能なオプションでは、Google Cloud で転送中の顧客データに対して適用されるデフォルトの保護およびカスタマイズ可能な保護について説明しました。Google ではまた、複数のオープンソース プロジェクトやその他の取り組みにより、転送データの暗号化の利用およびインターネット全体でのデータ セキュリティを奨励しています。

Certificate Transparency

ユーザーから Google Front End への通信の暗号化で説明したように、HTTPS を提供するには、まずサイトが信頼できるウェブ(パブリック)認証局(CA)による証明書を申請する必要があります。認証局は申請者がドメイン所有者の承認を受けているかどうかを検証するとともに、証明書に含まれるその他の情報がすべて正確であることを確認する責任があります。その後、この証明書がブラウザに提示され、ユーザーがアクセスしているサイトが認証されます。HTTPS が適切に認証されるようにするため、CA は必ずドメイン所有者が承認した証明書だけを発行することが重要です。

Certificate Transparency(CT、証明書の透明性)は、CA が未承認の証明書や不正な証明書を発行した場合に、サイト運営者とドメイン所有者がそれを検出できるようにするため、Google が 2013 年 3 月に開始した取り組みです。その仕組みとしては、ドメイン所有者、CA、および一般ユーザーが確認した信頼される証明書や、CA の場合は自身が発行した証明書を、公開の検証可能な追記専用の改ざん防止ログに記録できるようになっています。このログに記録された証明書は誰でも閲覧が可能で、情報が正確かつ承認済みであることを確認できます。

Certificate Transparency の最初のバージョンは、IETF の実験的 RFC である RFC 6962 で規定されました。Certificate Transparency の開発中、Google では証明書を記録できるオープンソースのログサーバーや、Certificate Transparency ログを作成するためのツールなど、さまざまなツールをオープンソース化しました。さらに Google Chrome では、Extended Validation(EV)証明書や、過去に証明書を不適切に発行したことがある CA から発行された証明書など、一部の証明書を一般公開することを義務付けています。2018 年以降、Chrome では新しいパブリック証明書はすべて開示が義務付けられます。

サイト運営者は Certificate Transparency を使用すると、自身のウェブサイトに対して不正な証明書が発行されたかどうかを検出できます。これを簡単に行うための無料ツールは、Google の Certificate Transparency ReportCertificate SearchFacebook のツールなど、数多く存在します。Certificate Transparency を使用していない場合でも、現在は多数のブラウザが、証明書の透明性を定期的に検査して、ユーザーがウェブサイトにアクセスする際に信頼している CA が業界の要件とベスト プラクティスを遵守していることを確認し、不正な証明書が発行されるリスクを低減しています。

HTTPS の利用の促進

ユーザーから Google Front End への通信の暗号化で説明したように、Google ではサイトやサービスで、最新の HTTPS をデフォルトで提供するよう努めています。Google の目標は、すべてのプロダクトおよびサービスで 100% の暗号化を達成することです。このため Google では、Google Cloud を含むすべてのプロパティの目標達成状況を追跡した HTTPS 透明性レポートを毎年発行しています。Google では引き続き、一部のプロダクトで暗号化のサポートを困難にしている技術的障壁に取り組んでおり、これには HTTPS Strict Transport Protocol(HSTS)18 をサポートしていないブラウザや他のクライアント向けのソリューションなどがあります。google.com のホームページなど一部の Google サイトでは、ユーザーが HTTPS 経由でのみサーバーに接続できるよう、HSTS を使用しています。

Google はインターネット全般で HTTPS への移行が進んでいることを理解しており、この動きを促進するため以下のような取り組みを行っています。

2016 年には、インターネット上の Google 以外の上位 100 サイトに関する「インターネットでの HTTPS 利用」の統計情報の公開を開始しました。Google ではこの情報を使用して、意識の向上を図るとともに、インターネットをすべてのユーザーにとってより安全な場所にすることを目指しています。2017 年 10 月、Chrome は Let's Encrypt に対する資金援助を正式に更新し、プラチナ スポンサーとなりました。

セキュアな SMTP の利用促進: Gmail の指標

ほとんどのメールは、デフォルトで暗号化を使用せずにメールを送信する SMTP(Simple Mail Transfer Protocol)を利用して交換されています。メールを暗号化するには、メール プロバイダが TLS などのセキュリティ管理を実装する必要があります。

ユーザーから Google Front End への通信の暗号化で説明したように、Gmail ではデフォルトで TLS が使用されます。また Gmail での TLS 要件では、Gmail 管理者が送受信メールに対して TLS 保護の利用を義務付けられることを説明しました。Google では HTTPS の透明性に関する取り組みと同様、Gmail でも受信メールへの TLS 利用に関するデータを提供しています。このデータは Safer Email Transparency Report に掲載されています。

Google は IETF や他の業界の主要企業と協力しながら、SMTP STS の開発を主導しています。SMTP STS は HTTPS の HSTS に似ており、暗号化されたチャネルでのみ SMTP の使用を強制します。

Chrome API

2015 年 2 月、Chrome ではいくつかの強力な新機能が、安全な送信元でのみ使用可能になるという発表がありました19。こうした新機能には、個人情報の処理や、ユーザー端末上のセンサーへのアクセスなどがあります。安全でない送信元に対しては、Chrome 50 の位置情報を手始めに、こうした機能のサポートを終了し始めています。

転送データの暗号化の継続的な革新

Chrome セキュリティのユーザー エクスペリエンス

Google Chrome は、ユーザーがサイトへの接続の安全性を素早く理解できるよう、UI を活用してセキュリティ情報を表示する業界リーダーとなっています。ユーザーはこの情報により、データをいつどのように共有するかについて、情報に基づいた決定を下すことができます。Chrome は広範なユーザー調査を実施しており、その結果はピアレビュー済みの記事で公開されています。

さらにユーザーを保護するため、Chrome は 2017 年末までにすべての HTTP 接続を「安全でない」とマークすることを発表しましたChrome 56 以降は、HTTP ページにパスワードまたはクレジット カードのフィールドを含むフォームがある場合、デフォルトで警告が表示されるようになります。Chrome 62 では、ユーザーが HTTP ページにデータを入力したとき、およびシークレット モードでアクセスしたすべての HTTP ページで、警告が表示されるようになります。最終的に Chrome では、HTTP 経由で配信されるすべてのページに警告が表示されるようになる予定です。

Chrome で特定の構成がユーザーに対してどのように表示されるかを確認するには、BadSSL ツールを使用してください

鍵の透明性

メッセージの暗号化が広く採用されることを阻む大きな要因の 1 つは、公開鍵交換の難しさにあります。つまり、通信の相手となる新しいユーザーの公開鍵を確実に見つけるにはどうすればよいかということです。この問題を解決するため、Google では 2017 年 1 月、Key Transparency を発表しました。これは公開鍵を配布するための一般的で安全かつ監査可能な手段を提供する、オープンなフレームワークです。このフレームワークにより、ユーザーは手動で鍵検証を行う必要がなくなります。Key Transparency は主に E2E や OpenPGP のメール暗号化など、通信におけるユーザーの公開鍵の配布を目的としています。Key Transparency の設計は鍵の復旧と配布に関する新しいアプローチであり、Certificate TransparencyCONIKS から得られた知見に基づいています。

Key Transparency の開発はオープンソースであり、大規模な Merkle ツリーを使用して実装されています。Key Transparency Verification では、アカウント所有者が自身のアカウントに関連付けられている鍵と、アカウントが有効で安定している期間を確認できます。Google による Key Transparency の取り組みの長期的目標は、誰でも Key Transparency サーバーを実行し、任意の数のアプリケーションに簡単に統合できるようにすることです。

ポスト量子暗号

Google は今後も引き続き、転送データの暗号化における業界リーダーの地位を維持していく予定です。この目的のため、Google はポスト量子暗号の分野での取り組みを開始しました。このタイプの暗号により、巧妙な量子攻撃に弱い既存の基礎暗号を、より堅牢とされるポスト量子暗号に置き換えられるようになります。2016 年 7 月、Google では Chrome のデベロッパー版で New Hope ポスト量子暗号アルゴリズムを使用して、このようなアルゴリズムの導入の可能性に関するテストを実施したことを発表しました。この他にも、Google の研究者は他の実用的なポスト量子鍵交換プロトコルに関する論文を発表しています。

付録

インフラストラクチャ セキュリティ設計の概要などの Google Cloud のセキュリティと公開 SOC 3 監査レポートなどの Google Cloud のコンプライアンスの詳細をご覧ください。

脚注

1 パートナー ソリューションには、Cloud Launcher で提供されるソリューションと、Cloud Dataprep のようなパートナーとの共同開発によるプロダクトが含まれます。
2 この暗号化は無効化することもできます(例: Google Cloud Storage バケットへの HTTP アクセスの場合など)。
3 レイヤ 7 で保護されていない VM - サービス間の通信も、レイヤ 3 とレイヤ 4 では保護されます。
4 TLS 1.3 はまだ完成していません。ドラフト版は Gmail など特定の Google ドメインでのみ、テスト用に実装されています。
5 Google では、TLS 1.0 を引き続き使用しているブラウザに対しては、このプロトコル バージョンをサポートしています。クレジット カード情報を処理する Google サイトでは、Payment Card Industry(PCI)コンプライアンスで TLS 1.0 の使用中止が義務付けられている 2018 年 7 月までに、TLS 1.0 のサポートを終了する予定です。
6 QUIC の詳細については、[https://www.chromium.org/quic](https://www.chromium.org/quic)をご覧ください。
7、8、9 一部のレガシー オペレーティング システムとの後方互換性のため、Google は 3DES、SHA1、MD5 をサポートしています。
10 チェーン証明書の場合、CA は推移的に信頼されます。
11 これはセッション チケット(「RFC 5077(https://tools.ietf.org/html/rfc5077)」)またはセッション ID(「RFC 5246(https://tools.ietf.org/html/rfc5246)」)になります。
12 コントロール プレーンはネットワークの一部で、シグナリング トラフィックを伝送し、ルーティングを担当します。
13 以前は他のプロトコルが使用されていましたが、現在は使用が中止されました。こうした古いプロトコルを使用しているのはジョブの 1% 未満です。
14 Datagram TLS(DTLS)は傍受や改ざんを防止した通信を可能にすることで、データグラム ベースのアプリケーションのセキュリティを実現します。
15 Internet Key Exchange(IKE)は、IPsec プロトコル スイート内でセキュリティ アソシエーションを設定するために使用されるプロトコルです。
16 HMAC-SHA-1 は、Google の研究者が発見した SHAttered 衝突のような「SHA-1 衝突(https://shattered.io/)」によって破壊されません。
17 G Suite Enterprise の場合、これは UI には表示されません。ドメイン管理者は「メールログ検索(https://support.google.com/a/answer/2604578)」を使用して、ドメインのデータを調べることができます。
18 HTTPS Strict Transport Protocol は、ウェブサイトが自身へのアクセスをセキュアな接続を介してのみ可能であると宣言したり、ユーザーがユーザー エージェントに対し、セキュアな接続を介してのみ特定のサイトと通信するように指示したりすることを可能にするメカニズムです。
19 安全な送信元とは、特定のスキーム、ホスト、ポートの「パターン(https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features)」に一致する接続のことです。
このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...