なぜGoogleCloud Computeなのか？
ほとんどの企業がデータセンターを利用しているのは、コストの予測可能性、ハードウェアの確実性、コントロールが可能なためです。しかし、データセンターでリソースを運用・維持するには、以下のような多くのオーバーヘッドも必要となります：
キャパシティ：必要に応じて拡張できる十分なリソースとそのリソースの効率的な使用。
セキュリティ：資産を保護するための物理的なセキュリティに加えて、ネットワークやOSレベルのセキュリティ。
ネットワークインフラ：配線、スイッチ、ルーター、ファイアウォール、ロードバランサーなどのコンポーネント。
サポート：インストールやメンテナンス、問題解決のために必要なスキルを持ったスタッフ。
帯域幅：ピーク時の負荷に適した帯域幅。
設備：機器や電源などの物理的なインフラ。
クラウドプラットフォームのようなフル機能のクラウドプラットフォームは、物理的、物流的、人材的な問題を解決し、ビジネスコストの削減に貢献します。クラウドプラットフォームはGoogleのインフラ上に構築されているため、従来のデータセンターではコスト的に困難であった以下のようなメリットもあります。
グローバルネットワーク
内蔵されたマルチリージョナル・リダンダンシー
世界各地にある複数のデータセンターのリージョンとゾーンは、強力な冗長性と可用性を確保するのに役立ちます。これは、国際的な複数の地理的ゾーンの拡張/開発が必要な場合に特に重要です。
迅速で信頼性の高いスケーリング
Cloud Platformは、トラフィックが急増した場合でも、Googleの自社製品と同様にスケーリングできるように設計されています。Google App Engine、Google Compute Engineのオートスケーラー、Google Cloud Datastoreなどのマネージドサービスは、必要に応じてアプリケーションの容量を拡大・縮小できる自動スケーリング機能を備えています。
容量と帯域幅
従来のデータセンターでは、リソースの必要性を計画し、必要に応じて拡張できるだけのリソースを前もって取得し、そのリソースの制限内で容量やワークロードの配分を慎重に管理する必要があります。事前にプロビジョニングされたリソースの性質上、どんなに慎重にキャパシティを管理しても、最適な利用率にならない場合があります：
図1：事前に用意されたリソースの時間経過による利用状況
さらに、このようにリソースを事前に提供するということは、リソースの上限が決まっているということでもあります。もし、それ以上の拡張が必要になった場合には、お手上げです。
Cloud Platformは、これらの使用率の問題やスケーラビリティのしきい値の多くを解決するのに役立ちます。必要に応じてVMインスタンスをスケールアップ、スケールダウンすることができます。使用した分だけを秒単位で支払うため、常に必要ではない、あるいはトラフィックのピーク時にのみ必要となる過剰な容量を支払う必要がなく、コストを最適化することができます。
セキュリティ
The Google のセキュリティモデルは、 Gmail や Google Apps などの Google アプリケーションでお客様の安全を確保することに注力してきた 18 年以上の経験に基づいて構築されたエンドツーエンドのプロセスです。さらに、Googleのサイト信頼性エンジニアリングチームは、プラットフォームシステムの運用を監督し、高可用性を確保し、プラットフォームリソースの乱用を防止しています。
ネットワークインフラ
従来のデータセンターでは、ラックに収められたサーバーやストレージ、何層にもわたるスイッチ、ロードバランサー、ルーター、ファイアウォールなど、複雑なネットワーク設定を管理しています。また、ソフトウェアや詳細な機器構成の設定、維持、監視を行う必要があります。さらに、ネットワークのセキュリティや可用性にも気を配らなければならず、ネットワークのニーズの高まりに応じて機器の追加やアップグレードを行わなければなりません。
一方、クラウドプラットフォームは SDN（Software-Defined Networking） モデルを採用しており、クラウドプラットフォームのサービスAPIやユーザーインターフェースを通じて、ネットワークの設定をすべて行うことができます。データセンターのネットワークハードウェアを購入・管理する必要はありません。GoogleのSDNスタックであるAndromedaの詳細については、 Enter the Andromeda zone .
設備とサポート
クラウドプラットフォームを利用すれば、データセンターに物理的なハードウェアを設置したり維持したりする必要はありませんし、そのための熟練した技術者を確保する必要もありません。Googleがハードウェア層と技術者の両方を担当するので、お客様はアプリケーションの実行に集中することができます。
コンプライアンス
Google は、独立した第三者機関による定期的な監査を受け、クラウドプラットフォームがセキュリティ、プライバシー、およびコンプライアンスの管理と一致していることを確認しています。クラウドプラットフォームは、ISO 27001、ISO 27017、ISO 27018、SOC 2、SOC 3、PCI DSS などの基準に基づいた定期的な監査を受けています。
セキュリティ面でのメリットに注目
世界経済は毎年、データの漏洩、盗難、破壊によって何十億ドルもの損失を被っています。このような理由から、クラウド業界とGCPの主要な関係者は、以下のような信頼性の高い基準への準拠を目指しています：
FIPS 140-2
ISO/IEC 27001
PCI DSS
ISO 27017
ISO 27018, SOC 2, SOC 3
保存中および転送中のすべてのデータの暗号化
Google Cloud Computingは、レベル1のFIPSに準拠するために、この数年間で何百万ドルもの投資を行ってきました、 こちらをご参照下さい や こちらをご参照下さい.
ちなみに、FIPSとは Federal Information Processing Standardの略で、アメリカの行政機関が秘密やインフラを守るために定めた、世界で最も厳しい基準のことです。
以下は、GCPで実装されていて「オンプレミスのインストール」のローカルネットワークレベルでは実装されていない可能性が高いものです：
| Technology | Google Cloud Compute | Standard DIY corporate implementation |
| ローカルSSDストレージ製品は、NIST承認の暗号で自動的に暗号化される。 | Applied on all storage | RARELY implemented |
| NIST認定の暗号化アルゴリズムを用いて、社内外のデータ拠点間のトラフィックを自動的に暗号化する。 | Applied on all data transfers | RARELY implemented |
| クライアントがインフラに接続する際には、クライアントのTLSクライアントは、FIPSに準拠した安全なアルゴリズムの使用を要求するように設定されている必要がある。TLSクライアントとインフラ所有者のTLSサービスが、FIPSと互換性のない暗号化方式に合意した場合、検証されていない暗号化実装が使用される。 | Applied on all connections | VERY RARELY implemented |
| 本番環境で構築・運用するアプリケーションには、独自の暗号実装が含まれている場合があり、そのアプリケーションが処理するデータをFIPS Validatedの暗号モジュールで保護するためには、そのような実装を自分で統合する必要がある。 | Ready to Use | VERY RARELY implemented |
グーグル・クラウド環境と静止時の暗号化
CIO level
| Technology | Google Cloud Compute | Standard local implementation |
| Googleは、Google Cloud Platform製品の中で保存されているお客様のデータを保護するために、複数のレイヤーの暗号化を使用する。 | Applied as a Standard | RARELY implemented |
| Google Cloud Platform は、1 つまたは複数の暗号化メカニズムを使用して、お客様が何もしなくても、静止状態で保存されているお客様のコンテンツを暗号化する。ただし、いくつかの例外があり、この文書で詳細説明。 | Applied as a Standard | RARELY implemented |
| 保存するデータはチャンクに分割され、各チャンクは固有のデータ暗号化キーで暗号化される。これらのデータ暗号化キーは、データとともに保存され、Googleの中央キーマネージメントサービス内で独占的に保存・使用されるキー暗号化キーで暗号化される。（「ラップ」）。Google の Key Management Service は、冗長化されており、世界中に分散している。 | Achieved as a Standard | VERY RARELY implemented |
| Google Cloud Platformに保存されたデータは、AES256またはAES128を用いてストレージレベルで暗号化される。 | Achieved as a Standard | VERY RARELY implemented |
| Googleは、ほぼすべてのGoogle Cloud Platform製品で一貫して暗号化を実装するために、共通の暗号化ライブラリTinkを使用。この共通ライブラリには広くアクセスできるため、少数の暗号技術者チームだけが、この厳重に管理・審査されたコードを適切に実装し、維持する必要がある。 | Achieved as a Standard | VERY RARELY implemented |
暗号化のレイヤー
Googleでは、データを保護するために複数の暗号化レイヤーを使用しています。複数の暗号化レイヤーを使用することで、データ保護の冗長性を高め、アプリケーションの要件に応じて最適なアプローチを選択することができます。
各チャンクはGoogleのストレージシステムに分散され、バックアップや災害復旧のために暗号化された状態で複製されます。顧客データにアクセスしようとする悪意のある人物は、(1)目的のデータに対応するすべてのストレージチャンクと、(2)チャンクに対応する暗号化キーを知り、それにアクセスできる必要があります。
Googleは、Advanced Encryption Standard（AES）アルゴリズムを使用して、保存中のデータを暗号化しています。AESが広く使用されているのは、（1）AES256とAES128の両方が、米国標準技術研究所（NIST）によって長期保存用に推奨されていること（2019年3月現在）、（2）AESが顧客のコンプライアンス要件の一部として含まれていることが多いこと、などが挙げられます。
Google Cloud Storageに保存されたデータは、ほとんどの場合、ガロア/カウンタモード（GCM）のAESを使用してストレージレベルで暗号化されます。これは、Googleが管理しているBoringSSLライブラリで実装されています。このライブラリは、OpenSSLの多くの欠陥が明らかになった後、内部使用のためにOpenSSLからフォークされたものです。一部のケースでは、AESはCBC（Cipher Block Chaining）モードで使用され、認証にはHMAC（Hashed Message Authentication Code）が使用されます。また、一部の複製されたファイルでは、AESはCTR（Counter）モードでHMACが使用されます。他の Google Cloud Platform 製品では、AES はさまざまなモードで使用されています。
| Technology | Google Cloud Compute | Standard local implementation |
| ネイティブなマルチレイヤーの暗号化 | Applied as a Standard | VERY RARELY achieved |
| CTRモードによるネイティブAES暗号化 | Applied as a Standard | VERY RARELY achieved |
| ネイティブGCM | Applied as a Standard | VERY RARELY achieved |
ストレージデバイス層での暗号化
前述のストレージシステムレベルの暗号化に加えて、ほとんどの場合、データはストレージデバイスレベルでも暗号化されます。少なくともハードディスク（HDD）ではAES128、新しいソリッドステートドライブ（SSD）ではAES256が使用され、別のデバイスレベルの鍵（ストレージレベルでのデータの暗号化に使用される鍵とは異なる）が使用されます。古いデバイスが交換されると、デバイスレベルの暗号化にはAES256のみが使用されます。バックアップの暗号化
Googleのバックアップシステムでは、バックアッププロセスの間、データは暗号化されたままです。これにより、平文のデータが不必要に公開されることはありません。さらに、バックアップシステムは、Googleのキーマネージメントサービス（KMS）に保存されているキーに、バックアップ時にファイルごとにランダムに生成されるシードを加えた独自のデータ暗号化キー（DEK）で、各バックアップファイルを個別に暗号化します。また、バックアップ中のメタデータには別のDEKが使用され、このDEKもGoogleのKMSに保存されます。
| Technology | Google Cloud Compute | Standard local implementation |
| オンザフライでのバックアップフローの暗号化 | Achieved as a Standard | VERY RARELY implemented |
| ストレージ バックアップの暗号化 | Achieved as a Standard | VERY RARELY implemented |
GCPによる鍵管理
チャンク内のデータを暗号化するために使用される鍵は、データ暗号化鍵（DEK）と呼ばれます。Googleでは大量の鍵が使用されており、低遅延と高可用性が求められているため、これらの鍵は暗号化するデータの近くに保管されています。DEKは、鍵暗号化キー（KEK）で暗号化されている（またはKEKで「ラップ」されている）。KEKは、Google Cloud Platformの各サービスに1つ以上存在する。これらのKEKは、鍵を保管するために特別に構築されたGoogleのKMS（Key Management Service）というリポジトリに集中的に保管されます。KEKの数をDEKよりも少なくし、中央の鍵管理サービスを利用することで、Googleスケールでのデータの保存と暗号化が管理しやすくなり、データへのアクセスを中央から追跡・管理することができます。
Google Cloud Platformの顧客ごとに、非共有のリソースはデータチャンクに分割され、他の顧客に使用する鍵とは別の鍵で暗号化されます。これらのDEKは、同じ顧客が所有する同じデータの他の部分を保護する鍵とも異なります。
DEKは、ストレージシステムがGoogleの共通暗号ライブラリを使って生成します。DEKはKMSに送られ、ストレージシステムのKEKとラップされ、ラップされたDEKはストレージシステムに戻され、データチャンクと一緒に保管されます。ストレージシステムが暗号化されたデータを取り出す必要がある場合、ストレージシステムはラップされたDEKを取り出し、KMSに渡します。KMSは、そのサービスがKEKの使用を許可されているかどうかを検証し、許可されている場合は、ラップを解除して平文のDEKをサービスに返します。その後、サービスは DEK を使用してデータ・チャンクを平文に復号し、その整合性を検証します。
データチャンクを暗号化するためのKEKのほとんどはKMS内で生成され、残りはストレージサービス内で生成されます。一貫性を保つために、すべてのKEKは、Googleが構築した乱数生成器（RNG）を用いて、Googleの共通暗号ライブラリを使って生成されます。このRNGは、NIST 800-90Ar1 CTR-DRBGに基づいており、AES256のKEKを生成します。このRNGは、LinuxカーネルのRNGからシードされ、さらに複数の独立したエントロピー源からシードされます。これには、データセンター環境からのエントロピーイベント（ディスクシークやインターパケットの到着時間の詳細な測定値など）や、 インテルのRDRAND命令 （Ivy Bridge以降のCPUで利用可能）が含まれます。
Google Cloud Platformに保存されているデータは、前述のようにAES256またはAES128を使用したDEKで暗号化され、Google Compute Engineのパーシステントディスクに暗号化された新しいデータはAES256で暗号化されます。DEKは、Google Cloud Platformのサービスに応じて、AES256またはAES128を使用したKEKでラップされます。現在、クラウドサービスのすべてのKEKをAES256にアップグレードする作業を行っています。
GoogleのKMSはKEKを管理するもので、この目的のためだけに作られています。セキュリティを考慮して設計されています。KEKはGoogleのKMSからエクスポートできないように設計されており、これらの鍵を使ったすべての暗号化と復号化はKMS内で行う必要があります。これにより、漏洩や誤用を防ぐことができ、また、鍵が使用されたときにKMSが監査証跡を発することができます。
| Technology | Google Cloud Compute | Standard local implementation |
| KMSとの連携 | Applied as a Standard | VERY RARELY implemented |
| AES256 KEK | Applied as a Standard | VERY RARELY achieved |
ネットワークとコミュニケーション
プレミアム層の特典
ある場所から別の場所まで、ネットワークを完全に所有することは、ほとんどの企業にとって不可能なことです。しかし、Google Cloud Computeは、エンドツーエンドの完全な所有権とコントロールを実現することができます。
| Technology | Google Cloud Compute | Standard DIY corporate implementation |
| 完全なエンド・ツー・エンドのネットワーク・オーナーシップ | Achieved as a Standard | VERY RARELY implemented |
| 世界各地に100以上のPoPを設置し、広範なカバレッジとネットワークの冗長性/回復力を提供 | Achieved as a Standard | VERY RARELY implemented |
運用の安定性／静寂性／SLA
SLAレベルの高い水準
Google Cloud Computeは、すべてのサービスで 99%以上のSLAを検証できる数少ないクラウドプロバイダーです。.
| 対象サービス | 月間稼働率 |
| 複数ゾーンのインスタンス | >= 99.99% |
| シングルインスタンス | >= 99.5% |
| ロードバランシング | >= 99.99% |
Google がサービス レベル目標（SLO）を達成しなかった場合で、お客様が本 SLA に基づく義務を果たした場合、お客様は以下に説明する金銭的クレジットを受け取ることができます。本 SLA は、Google が SLO を満たさなかった場合のお客様の唯一かつ排他的な救済手段を規定しています。本 SLA で使用されているが、本 SLA で定義されていない大文字の用語は、本契約で定められた意味を持ちます。本契約が Google クラウド パートナーまたはリセラー プログラムに基づく Google クラウド プラットフォームの再販または供給を許可している場合、本 SLA におけるお客様とは、パートナーまたはリセラー（該当する場合）を意味し、ファイナンシャル クレジットは、本契約に基づくパートナーまたはリセラーの注文に影響を与える場合にのみ適用されます。
| Technology | Google Cloud Compute | Standard local implementation |
| シングルインスタンス/サーバーの実装 99.5% SLA (年間354,5日の稼働率) | Achieved as a Standard | RARELY achieved |
| 複数のインスタンス（冗長化された負荷分散）／サーバーの実装 99.5%のSLA（年間364,96日の稼働率を意味する） | Achieved as a Standard | VERY RARELY achieved |
| ライフタイムSLA | Achieved as a Standard | VERY RARELY achieved |
ハイ・アベイラビリティー規格
100%の可用性という目標を達成するためには、お客様のインフラが以下の基準を満たすことが必要です：
| Technology | Google Cloud Compute | Standard local implementation |
| 自己管理型のハードウェア容量 | Achieved as a Standard | RARELY achieved |
| オートスケーラビリティ | Achieved as a Standard | VERY RARELY achieved |
| リソース提供の自動化 | Achieved as a Standard | VERY RARELY achieved |
| 複数の冗長性（ストレージ） | Achieved as a Standard | VERY RARELY achieved |
| 複数の冗長性（コンピューティングインスタンス／サーバー） | Achieved as a Standard | VERY RARELY achieved |
| 複数の冗長性（電源） | Achieved as a Standard | VERY RARELY achieved |
| 複数の冗長性（電源） | Achieved as a Standard | VERY RARELY achieved |
| 複数の冗長性（ストレージ） | Achieved as a Standard | VERY RARELY achieved |
| ロードバランシング技術 | Achieved as a Standard | VERY RARELY achieved |
| パッシブストレージ（データ／ファイル）へのリアルタイムデータレプリケーション | Achieved as a Standard | VERY RARELY achieved |
| ダイナミックストレージ（データベース）上でのリアルタイムデータレプリケーション | Achieved as a Standard | VERY RARELY achieved |
Port Cities- お客様のビジネスに最適なホスティングソリューションの選択をお手伝いします
Port Citiesは、Google Cloud Platformをはじめとする世界最高のクラウドサービスプロバイダーと提携し、お客様のERPにいつでもどこからでもアクセスできるようにしています。また、当社のホスティングソリューションは、セキュリティ、容量、運用の安定性など、お客様のERPシステムの最も厳しい基準を満たしています。いずれにしても、 私たちのサーバーチームは、 お客様のビジネスに最適なサーバー・ホスティング・ソリューションをご相談させていただきます。
.
