エンタープライズ企業のベスト プラクティス

エンタープライズ企業が Google Cloud Platform を最大限活用するための、重要な概念とベスト プラクティスについて学んでみましょう。このガイドでは、エンタープライズ組織に関係する、機能以外のトピックが採り上げられています。

このガイドは、次のセクションで構成されています。

プロジェクトとアクセス

プロジェクトは、Google Cloud Platform の組織向けコンポーネントの核となるものです。プロジェクトでは抽象グループ化を行い、リソースを特定の部門または機能チームに関連付けすることができます。すべての Cloud Platform リソースは、プロジェクトに属しています。プロジェクトは、Google Cloud Platform ConsoleResource Manager API を使って管理することができます。Cloud IAM API には、Resource Manager API を通じてプロジェクト権限を管理するための、さまざまな方法が含まれています。

プロジェクトを使い、リソースへのアクセスを制御

組織で使用されている Cloud Platform リソース間の相互接続が明示的に許可されている場合を除き、プロジェクトは分離境界を設けます。ユーザーとグループには、プロジェクトごとに、viewereditorowner といった異なった役割を付与することができます。役割を与えるには、Cloud Platform Console 内の [IAM と管理] ページ または Cloud IAM API を使用します。現在、この API では、カスタムの役割を作成し、その役割に権限を割り当てることはできません。

さらに、特定のプロジェクトにアクセスできる人物を決める権限を委任することができます。owner の権限を与えられたユーザーは、ユーザー、グループ、サービス アカウントにアクセス権限を付与することも、それを取り消すこともできます。

どの Google アカウントにも、プロジェクトへのアクセス権限を付与することができます

プロジェクトへのアクセス権限は、Gmail アカウントなどの、あらゆる Google アカウントに付与することができます。プロジェクトへのアクセス権限を持っているグループに所属していることでも、Google アカウントにアクセス権限を与えることができます。請負業者などの外部の関係者にも迅速にアクセス権限を付与できるようになるため、この機能が役立つことがあります。しかし、セキュリティ ポリシーによって、組織がこのような柔軟性を求めない場合もあるかもしれません。このリスクは、Cloud IAM API で管理できます。API を使えば、モニタリング機能の活用によってポリシーに違反する割り当てをチェックし、警告を発したり、そのような割り当てを自動的に取り消したりすることができます。

プロジェクトは Universally Unique Identifier(UUID)で識別されます

それぞれのプロジェクトはユニバーサルに一意のプロジェクト ID を持っています。この識別子は、小文字の文字、数字、ダッシュ、プロジェクト番号で構成された、短い文字列になっています。プロジェクトを作成するとき、プロジェクト ID を指定することができます。Google がプロジェクト番号を自動的に割り当てます。プロジェクトの作成後は、プロジェクト ID とプロジェクト番号の変更はできません。

管理をしやすくするために、プロジェクト ID の計画にはある程度の時間をかけることをおすすめします。一般的なプロジェクト ID の命名には、次のようなパターンがあります。

[company tag]-[group tag]-[system name]-[environment (dev, test, uat, stage, prod)]

このパターンに従うと、たとえば、人事部の給与体系を開発する環境は、acmeco-hr-comp-dev となります。

人が読める形式のプロジェクト名にしてもかまいません。この名前は、グローバルに一意である必要はなく、編集が可能です。プロジェクト ID は、6 文字から 30 文字の長さにすることができますが、プロジェクト名の長さは 4 文字から 30 文字となります。

プロジェクトにより、正確な費用計算が可能になります

プロジェクトにより、Google が、エクスポート可能な CSV や JSON などのバージョンの支払い書類を整理します。プロジェクトが、請求書のグループ分けの最上位の単位になります。SKU でのグループ分けでさらなる内訳も提供されますが、プロジェクトでグループ分けされることで、コンピュートとネットワーキングのリソースの費用全体がきわめて把握しやすくなります。

エクスポート可能な支払い書類の内容の説明は、課金データのエクスポートをご覧ください。

クロスプロジェクト アクセスは可能ですが明示的に許可されていなければなりません

ユーザーやグループと同じように、サービス アカウントにも複数のプロジェクトへのアクセス権限を付与することができます。このクロスプロジェクト アクセスにより、あるプロジェクトのプロセスが、他のプロジェクト内のリソースに直接アクセスできるようになります。

プロジェクト A のサービス アカウントがプロジェクト B のリソースにアクセスするとき、費用はそのリソースを所有しているプロジェクト、つまりプロジェクト B のものとなります。

このルールの例外となるのは、Google BigQuery でクエリを実行するときです。ユーザーまたはサービス アカウントがプロジェクト B 内から、プロジェクト A に保存されている BigQuery データのクエリを実行すると、クエリの費用は、クエリの送信元のプロジェクト、つまりプロジェクトB に課金されます。ただし、データのストレージ費用は、引き続きプロジェクト A が負担します。このアプローチにより、他のグループがどのように BigQuery を利用しているかが簡単にわかるようになり、データ分析に使用できます。

それぞれのプロジェクトは、特定の請求先アカウントに属します

請求先アカウントは、組織全体のリソースで、請求管理者だけが編集することができます。請求管理者は、Cloud Platform Console の課金ページを使って管理されます。それぞれのプロジェクトは、ただ 1 つの請求先アカウントに関連付けられます。プロジェクトを請求先アカウントに関連付けできるのは、プロジェクト オーナーであり、課金管理者であるユーザーに限られます。サポート料金と請求書は、単一の請求先アカウントに関連付けられます。

プロジェクトは、地理やゾーンのようなものにもとづいているわけではありません

プロジェクトは、リソースを論理的にグループ分けしたものであり、特定の地理的地域に対応するものではありません。同様に、プロジェクトに利用可能なゾーンがあるわけではありません。プロジェクト内のリソースは、複数の地理的地域と複数のゾーンで存在できます。

たとえば、プロジェクト A はそれぞれに複数のゾーンがある米国中央部、ヨーロッパ、アジアにあるリソースを含んでいて、プロジェクト B はこれも複数のゾーンがあるヨーロッパのリソースしか含んでいないこともあります。

プロジェクトを作成するときには、地理的地域またはゾーンを設定する必要はありません。このルールの唯一の例外は、Google App Engine です。App Engine のアプリは必ず、地理的なロケーションをもっています。App Engine のロケーションは、新しいプロジェクトを作成するときに、デフォルトのロケーションから変更することができます。プロジェクトの作成後には、特定の地理的ロケーションに固定されるリソースがありますので、ご注意ください。この概念については、後のセクションでより詳しく説明されています。

認証と ID

法人向けログイン認証情報の使用

ドメインと Cloud Platform を関連付けすることができます。その場合、登録レコードを追加するか、ご自身のサイトのホームページの HTML にスニペットを追加するかのいずれかの方法で、ドメインを所有していることを確認しなければなりません。ドメインを Cloud Platform ライセンスに関連付けすることにより、Cloud Platform プロジェクトにドメインのユーザーを追加することができます。また、ベンダーの ID 管理コネクタ、Cloud Platform で動作する Google Admin SDK または Google Apps Directory Sync(GADS) を使うことで、ユーザーを自動的にプロビジョニングすることができます。プロビジョニングされたユーザーは、シングル サインオン(SSO)、OAuth、2 要素確認といった、豊富な認証機能を利用することができます。

既存の Google Apps ドメインに Cloud Platform の機能を追加することもできます。この場合、単一のコンソールを通じて、すべてのユーザーと設定の管理が可能となります。すべての新規ユーザーに Google Apps のライセンスを自動的に割り当てることができ、これがデフォルトの設定となっています。Apps のライセンスを必要としないデベロッパーがいる場合には、手動または組織ごとのライセンス割り当てを代わりに選択することもできます。最初にライセンスを割り当てたあとに組織に加わった新規ユーザーには、ライセンスが自動的に割り当てられませんので、ご注意ください。その場合、管理者が手動で組織にライセンスを再割り当てしなければなりません。

ドメイン確認の前に重複したアカウントを解決

ドメインを使用するときには、ユーザー名の重複という状況に遭遇するかもしれません。たとえば、メールアドレスを使ってドメインから Google アカウントを作成し、Google サービスでそのアカウントを使用する人がいるかもしれません。さらに、その人がワークドメインのメールアドレスを使って Blogger のアカウントを設定することがあるかもしれません。もし、その後に Google Apps のドメインが設定され、そのような人のワークドメインのメールアドレスが Cloud Platform のアカウントとして追加されると、重複が生まれます。前から存在していたアカウントは権限を失いませんが、ユーザー名は、複雑なプレースホルダ ドメインに名前が変更されます。既存の権限は、手動で取り消し、新しいユーザー アカウントに移されなければなりません。

このような種類の重複を避けるには、ドメインのメンバーに加える前に、既存のアカウントの名前を変更するように、ユーザーに依頼してください。アカウントの重複という問題を回避および解決する方法についての、さらに詳しいガイダンスは、Google Apps 管理者用ヘルプをご覧ください。

ドメイン管理ルールの定義

ドメインに関連付けされているプロジェクトは、既存の一連の役割に、ドメイン管理者という、新しい役割を加えます。ドメイン管理者の役割はドメイン自体に適用され、次のような事前定義された役割のうちの 1 つを使用するか、あるいはカスタムの役割を作成し、その管理範囲を定義します。

  • ユーザー: ユーザーのサブセットである組織、あるいはグローバルな組織
  • 権限: グループ管理、セキュリティ管理など

これらの役割は、Admin Console または役割 API を通じて管理することができます。ドメイン管理者の役割についての詳しい情報は、管理者の役割についてをご覧ください。

SAML 交換で SSO を実装

Cloud Platform は、SAML 2.0 ベースの SSO をサポートしており、Cloud Platform Console、SSH、OAuth の認証プロンプトに対する、シームレスな SSO を可能にします。gcloudgsutilbq といったCloud Platform のコマンドライン インターフェースも、ウェブブラウザでのセッションベースの認証をサポートしているため、残り部分の Cloud Platform と同じように SAML 2.0 ベースの SSO が可能です。

ユーザーが、SSO プロバイダに対する承認を事前に受けていないまま直接的に、あるいは他のアプリケーションにアクセスする方法で、これらのツールにアクセスすると、そのユーザーにはユーザー名の入力が求められますが、パスワードの入力は求められません。このステップにより、Google 認証インフラストラクチャが、ユーザーが認証を求めているドメインを判断できるようになります。

Cloud Platform と Google Apps は、共通のディレクトリ、auth、SSO インフラストラクチャを使用します。Google SSO のドキュメントには、Google Apps の説明がありますが、この説明は、Cloud Platform にもそのまま適用させることができます。次のドキュメントが、とりわけ役立つでしょう。

他のサービスの ID プロバイダとして Google を使用する際の留意点

アプリケーションを Google の OpenID Connect で認証し、市販のアプリケーションを認証するための SAML 2.0 の ID プロバイダとして Google を使うことにより、100% クラウドベースの認証ソリューションに移行することができます。

Google とサードパーティは、ユーザー認証に OpenID Connect を実装するための参考となる、詳細な情報を数多く揃えた、ライブラリを用意しています。Microsoft Active Directory のようなサードパーティのディレクトリとは異なり、Google は、SAML 2.0 のID プロバイダとして活用させることができます。Google for Work は、15 の人気 SaaS プロバイダを含む、多くのプロバイダをサポートしています。Google for Work の推奨 ID パートナーには、PingOkta が含まれています。カスタム SAML アプリの統合を新たに追加することもできます。

Google を ID プロバイダとして使うことにより、2 要素認証と FIDO U2F セキュリティ キー デバイスなどの Google の豊富な認証インフラストラクチャを活用することができます。

Google のディレクトリをユーザーに提供

大手のアクセス管理ベンダーは、ID プロバイダのディレクトリでユーザーが作成されたときの、Cloud Platform ユーザーの自動プロビジョニングをサポートしていますが、Cloud Platform は現在、SAML ベースのユーザー プロビジョニングをサポートしていません。

SSO の世界では、ディレクトリという語は、通常、ライトウェイト ディレクトリ アクセス プロトコル(LDAP)を意味します。ここでは、この語は、LDAP ベースではない、Google のディレクトリを意味しますが、機能に違いはなく、認証と承認のための、ユーザーとグループのディレクトリが提供されます。

Cloud Platform のユーザー プロビジョニングには、次のいずれかによってアクセスすることができます。

ユーザー プロビジョニングの自動化

大手の ID 管理ベンダーは、Google Apps 用のコネクタを提供しています。これらのコネクタは通常、Google Admin SDK Directory API を使って、Google Apps のユーザーとその関係者にグループと組織をプロビジョニングします。Cloud Platform と Google Apps では、共通のディレクトリ インフラストラクチャが使われているため、これらのコネクタは Cloud Platform にも適用させることができます。

Google では、代理でユーザーとグループを自動的にプロビジョニングするオンプレミス型コネクタである GADS も提供しています。GADS のドキュメントには Google Apps について書かれていますが、Cloud Platform にもそのまま適用させることができます。GADS により、ユーザー、グループ、非社員の連絡先を自動的に追加、修正、削除できるようになり、LDAP クエリを使って Cloud Platform のドメインにあるデータを LDAP ディレクトリ サーバーに同期させることができます。LDAP ディレクトリ サーバー内のデータが、改変されたり、漏洩することは決してありません。

GADS は、ネットワークの内側の管理マシン上で作動します。GADS は、標準的な LDAP またはセキュア LDAP とセキュア ソケット レイヤー(SSL)の組み合わせを通じて、ネットワーク内側の LDAP サーバーに接続されます。この接続は、指定のポートでできますが、デフォルトは標準的な LDAP ポートとなっています。GADS は、ポート 443 において、HTTPS でインターネットを通じて Google Apps ドメインに接続されます。この接続は、ネットワーク内のプロキシホストを通じても可能です。

ユーザーとグループをプロビジョニングする、独自ソリューションの構築をご希望の場合には、Google Admin SDK を使用することができます。Admin SDK は、グループと組織によって、Cloud Platform のユーザーとその関係者を管理します。Admin SDK は、HTTPS REST とともに、Python、Java、.NET、その他のクライアント ライブラリをサポートしています。

テストまたは他の目的でユーザーを手動でプロビジョニングするために、Cloud Platform の管理者は、Admin Console を通じて、または CSV ファイルのインポートによって、ユーザーおよびその関係者をグループと組織でプロビジョニングすることができます。

ユーザーのグループへの役割の割り当て

グループを使えば、大規模な組織でも、プロジェクト承認を簡単に管理することができます。ユーザーにプロジェクトの役割を割り当てるのと同じように、グループにも役割を割り当て、前に説明した方法でグループのメンバーを管理することができます。

役割ベースアクセス制御(RBAC)に慣れている人であれば、Google グループは RBAC における役割のようなものであり、Cloud Platform のプロジェクト役割は RBCA における権限のようなものであると考えてもいいでしょう。

サービス アカウントによるサーバー間インタラクションの承認

ユーザーと同じように、サービス アカウントにも、同じような手法で、特定のリソースに対する承認を付与することができます。そのような例としては、Google Cloud Storage のバケットの読み取りおよび書き取りを行う能力や、BigQuery 内の特定のデータセットにアクセスする権限のアプリケーションへの付与があります。サービス アカウントは、パスワードではなく、秘密鍵で認証されるので、自動化されたプロセスを実行するのに役立ちます。

アプリケーションの承認を OAuth2 に委任

Cloud Platform API の OAuth 2.0 サポートとその範囲により、サポートされている方法に対するきめ細かな承認が可能になります。Cloud Platform は、three-legged OAuth とも呼ばれる、サービス アカウントとユーザー アカウントの両方の OAuth をサポートしています。

OAuth 2.0 は通常、ウェブ アプリケーションの承認に使われます。OAuth 2.0 には、デスクトップ アプリケーションをサポートするインストール済みアプリケーション モードもあります。

Cloud Platform は、アプリケーション デフォルト信用情報をサポートしています。この信用情報は、誰もが同じデータへのアクセス権限を持っているときなどの、API へのユーザー非依存のアクセスに適しています。

コマンドライン端末から操作する場合には、gcloud の承認によって、ユーザー アカウントまたはサービス アカウントになりかわって API にアクセスでき、gsutil によっても、これらの信用情報を使うことができます。

ネットワーキングとセキュリティ

プロジェクトを使い、リソースを完全に分離

Google では、ソフトウェア定義ネットワーキングを採用しています。これによって、あらゆるパケットをセキュリティ チェックの対象にすることができ、結果的に Cloud Platform の完全分離が可能になります。Google のデータセンターでの、ソフトウェア定義ネットワーキングについての詳しい情報は、Cloud Platform ブログでご覧いただけます。

セキュリティについての詳しい情報は、Google Cloud Platform Security ページでご覧いただけます。

プロジェクト内でのネットワーク使用による、VM インスタンス グループの分離

それぞれのプロジェクトは、最大 5 つの、分離されたネットワークに対応することができます。それぞれのネットワークは、グローバル IP アドレス空間を構成しています。つまり、複数の地理的地域で、Google Compute Engine 仮想マシン(VM)のインスタンスのようなリソースを作成することができ、そのリソースは、同じ仮想ネットワーク上にあるため、同じ IP アドレス空間を共有するようになります。フラットなネットワーク アドレス空間であっても、ゾーンから離れるときには通常の下り料金がかかりますので、ご注意ください。詳しい情報は、ネットワークの料金体系をご覧ください。

割り当て増加をリクエストすれば、それぞれのプロジェクトで最大 15 の分離ネットワークをサポートすることができます。

ネットワーク内部向け DNS の利用

それぞれのネットワークは、VM インスタンスがお互いを名前によって迅速に、簡単に見つけることができるようにする、ローカルのドメインネーム サーバー(DNS)をサポートしています。グローバルなアドレス空間と同様に、このローカルな DNS は、サービスを利用している VM インスタンスの地理的ゾーンに関係なく、ネットワーク全体を対象として作動します。

仮想ファイアウォールとルートで、すべてのネットワーク アクセスを制御

Cloud Platform は、仮想アプライアンスの柔軟性を大幅に高める、ソフトウェア定義ネットワークを採用しています。これによって、ファイアウォール ルールの作成が可能となり、公共ネットワークと同一ネットワーク上の他のインスタンスの両方から、インスタンスとともに、ロードバランサに向かうトラフィックを制御することができます。ファイアウォール ルールは、指定のインスタンスタグに適用させることができます。たとえば、同じタグでマークされたさまざまなインスタンスに動的に適用されるファイアウォール ルールを作れば、クラスタの自動スケーリングがより簡単にできるようになります。

ルートも同様に柔軟性があります。ネットワークへのルートを定義すれば、同じネットワーク上ならびにリソース外にある、他のインスタンスに、VM インスタンスがトラフィックを送信する方法が定義されます。ルートは指定されたインスタンス タグにも適用できますので、インスタンスの送受信に動的に適用されるルールを設定することができます。

iptables とルートを使い、下りトラフィックの制限とフィルタリングを実施

Cloud Platform のファイアウォール ルールは、VM インスタンスへの上りトラフィックを制御でき、ネットワーク ルートは、VM から IP アドレス範囲への下りトラフィックを制御することができます。これら制御の例としては、NAT ゲートウェイを経由して企業の IP 範囲に向かうすべての外部トラフィックまたは VPN ゲートウェイを経由して企業の IP 範囲に向かうすべてのトラフィックのルーティング、あるいは存在していない IP へのルーティングによる IP 範囲へのアクセスの拒否などがあります。ポート 80 を通るすべてのトラフィックのフィルタリングといったような、VM インスタンスから指定のポートまでの下りトラフィックを制御する必要がある場合には、そのインスタンス上で iptables または別のホストベースのフィルタリング メカニズムを設定します。

VM インスタンスは内部 IP を持ち、さらに公開 IP アドレスを持つことができます

あらゆる VM インスタンスには、それが作成されたネットワーク アドレス空間に適合した内部アドレスが割り当てられます。このアドレスは、同じネットワーク上のインスタンス間のトラフィックに使用することができます。オプションとしては、VM に外部の公開 IP アドレスを追加できます。この外部アドレスは、エフェメラルlなアドレスか、有料の静的アドレスのいずれかになります。VM のインスタンスが動作していないとき、ならびに IP が VM のどのインスタンスとも関連付けされていないときは、保留されていた静的な IP アドレスの料金が請求されますので、ご注意ください。

標準の割り当てでは、少数の外部 IP アドレス、つまり地域当たり 23 のエフェメラル アドレスと 7 つの静的アドレスの利用が可能です。割り当てが増えると、外部のエフェメラル IP アドレスを地域あたり 500 にまで増やすことができます。割り当てよりも多くの外部 IP アドレスが必要な場合には、Cloud サポートへの連絡または担当のテクニカル アカウント マネージャーへの連絡を通じて、必要な数をご相談ください。

VM のインスタンスが Cloud Platform のサービスと繋がるには、公開 IP アドレスが必要です

Cloud Platform API や他のサービスなどのインターネット リソースと繋がるには、それぞれの VM インスタンスが外部 IP アドレスを持つ必要があります。こうすることを不安に思われる場合は、ファイアウォール ルールによって、これらの VM インスタンスに送信されるトラフィックを制限することを推奨いたします。

VM インスタンスが本当に内部的なものであることがセキュリティ ポリシーの要件となっている場合、ネットワーク上で NAT プロキシを手動で設定し、さらにそのためのルートも設定する必要があります。そうすることで、内部のインスタンスとインターネットとの接続が可能となります。SSH を使って、完全な内部 VM インスタンスに直接接続することは不可能である、ということには、必ず注意してください。このような内部マシンに接続するには、外部 IP アドレスを持ち、それを通じてトンネルの作成が可能な要塞インスタンスを設定しなければなりません。詳しい情報は、要塞ホストをご覧ください。

地域とゾーンに特定のリソースを置き、レイテンシの削減と災害復旧を可能にします

地域は地理的な地域のことであり、もっと具体的には、データセンター キャンパスの場所を言います。地域内には、基本となるインフラストラクチャのアベイラビリティ ゾーンである、複数のゾーンがあります。Cloud Platform の特定のリソースがグローバルであっても、他のリソースが、特定の地域、またば事情によっては特定のゾーンに固定されている場合もあります。VM インスタンス、永続ディスク、Cloud Storage のバケット、App Engine のアプリケーション、Cloud Bigtable、Cloud Dataproc、BigQuery のデータセット、Cloud VPN、その他一部のリソースは、その地理的地域内で作成することができます。

地域とゾーンを活用し、地理を考慮しながら、サービスの適切な冗長性の確保あるいはレイテンシの最小化を目指しましょう。

Cloud VPN を使って、リモート ネットワークにセキュアに接続

Google Cloud VPN はフレキシブルなツールで、Cloud Platform とオンプレミス ネットワークの間、プロジェクトが異なる 2 つのネットワークの間、あるいは同じプロジェクトの 2 つのネットワークの間など、リモート ネットワークとのセキュアな接続を可能にします。Cloud VPN トンネルは、固定の月額料金に標準の下り料金が加算されて課金されます。同じプロジェクトの 2 つのネットワークを接続させるのは、標準の下り料金がかかりますので、ご注意ください。

ルート上でインスタンス タグを使えば、VPN にトラフィックを送信する VM インスタンスを動的に制御することができます。

ウェブサイトの一般的な脆弱性をスキャン

Google Cloud Security Scanner で、ウェブサイトの一般的な脆弱性を検出しましょう。このツールは、App Engine のアプリケーションをスキャンし、クロスサイト スクリプティングや混合コンテンツといった問題を検出します。

あらゆる動的脆弱性スキャナと同じように、クリーン スキャンによって、サイトがセキュアであると保証されるわけではありません。手動でのセキュリティ レビューも行わなければなりません。

Cloud Router により、Cloud VPN にルートを動的に追加することができます

Cloud VPN はフレキシブルではありますが、トンネルでの IP アドレス範囲の静的な追加および削除が必要です。 Google Cloud Router は、ボーダー ゲートウェイ プロトコル(BGP)を利用することで、この制限を緩和し、トンネルを動的に更新します。

ネットワークをサブネットワークに分割することができます

Compute Engine 上のサブネットワークにより、VM インスタンス間でルーティングを行う機能を維持しながら、VM インスタンスが作成されたアドレス空間を制御することができます。サブネットワークは、非公開の IP 範囲になることができますので、一般の親ネットワークに属する必要はありません。ネットワーク グループ内のサブネットワークは、相互に接続することができます。

ファイアウォール ルールと経路を使えば、サブネットワーク同士をさらに分離させることができるようになります。

ロギング、モニタリング、監査

脅威を認識し、リスクを軽減するには、アカウントとシステム リソースへのアクセスとそれらの利用状況をモニターします。Cloud Platform には、ソリューション全体の重要な一部となる、モニタリングおよび通知用のツールがとても豊富にあります。

ログの集まる場所として Cloud Logging を使用

Google Cloud Logging は、ログを集めるための、汎用の場所を提供します。VM インスタンス、App Engine、マネージド サービスからのログは、この中央集中的なログエリアに自動的に表示されます。他の任意のログも、Cloud Logging に送ることができます。この機能を使えば、システムおよびアプリケーションのすべてのログを 1 か所に集めることができ、分析とモニタリングが簡単になります。

システム リソースへのアクセスをモニター

システム リソースがどのようにアクセスされているのかを見るには、次の項目をモニターします。

  • インスタンスとディスクの作成と削除、ファイアウォール ルールの変更、RegionOperations API を使った、負荷分散と自動スケーリングの設定などの、Compute Engine リソースの修正

  • アクティビティ ログを使った instance/get の呼び出しなどの、Compute Engine 情報のリクエスト

  • Compute Engine のアプリケーション ログ、Google Cloud Logging エージェントを使った認証の試み

  • ソースと IP アドレスのような、プライベート ネットワーク ログを使った、VPN のゲート間トラフィック

  • BigQuery のクエリとテーブル、データセット、BigQuery API を使った表示操作

  • Cloud Storage アクセスログを使った、Cloud Storage オブジェクトのアクセス

  • App Engine のデプロイ、バージョン アップ、cron、インデックス、キュー、または App Engine Admin ログを使った、その他の設定変更

  • Cloud SQL の operations.list メソッドを使った、Cloud SQL の操作

  • Deployment Manager API を使った、Google Cloud Deployment Manager の操作

アカウント アクセスのモニター

Reports API管理コンソールのログイン監査ログを使った、ドメイン アカウントに対するアクセスの試みをすべてモニターします。

管理アクションのモニター

IAM API を使って、プロジェクトの役割に対する変更をモニターします。Admin console audit log を使って、domain admin console 内で行われた、すべての操作をモニターします。

分析と長期の保存のために、ログを BigQuery にエクスポート

BigQuery は、膨大な量のデータを迅速に分析するための、優れたツールです。BigQuery は、分析用のデータを保存する、非常に費用効果の高い方法でもあります。Cloud Logging を設定することで、ログを BigQuery に直接エクスポートできます。BigQuery は、ログの傾向を識別するための詳細分析を可能にする、パワフルなツールとなります。

ログの不要な変更を予防

ログは、発端となるプロジェクトの Cloud Storage に保存されます。デフォルトでは、バケットの階層的な権限モデルに基づき、プロジェクトのオーナーとエディタが、プロジェクトとオブジェクトのすべての Cloud Storage バケットの所有権限を持ちます。

ログが不注意または悪意によって変更されるリスクを最小化するために、次の原則を適用させます。

最小限の権限

ジョブを行うのに必要な、最低限の権限を付与します。プロジェクトとログバケットに対する owner の役割の使用を制限します。owner の役割の目的は、メンバー、承認などを管理することにあります。

この場合も、editor の役割を持つチームメンバーは、アプリケーションのデプロイで、リソースを変更または設定することができます。

専用のサービス アカウントで Cloud Storage API を使うカスタム アプリケーションを通じて、より多くの人々にバケットとオブジェクトへのマネージド アクセスを提供し、その後にアプリケーション内で監査を強化することもできるでしょう。

否認防止

Cloud Storage は、ディスクに書き込まれる前に、すべてのデータを自動的に暗号化します。ログバケットでオブジェクトのバージョニングを実装すれば、否認防止という、追加の保証を得ることができます。オブジェクトがバケット内で上書きまたは削除されれば、そのオブジェクトを識別する世代プロパティにより、オブジェクトのコピーが自動的に保存されます。残念ながら、この機能では、プロジェクト オーナーがアーカイブされたオブジェクトを削除したりバージョニングを無効にしたりすることを防止できません。

職掌分散

職掌分散という、追加の保証を得ることができます。たとえば、ログの検査と終了を行うのに 2 人の人間が必要であるとします。その場合、頻繁な cron ジョブの一部として gsutil cp を使うことで、あるいはコピーされるデータの容量が 10TB のログデータより大きい場合に、Cloud Storage Transfer Service を使うことで、ログバケットを別のオーナーのプロジェクトにコピーできます。このアプローチでは、プロジェクト オーナーがコピーの前にオリジナルのバケットを削除したりオリジナルのロギングを無効にしたりすることを防止できません。

このアプローチは、ローカルマシンにコピーすることなく、クラウドベースのコピーができますので、迅速で、効率的です。コピーに対する運用料金はかかりますが、地域内でのコピーのためのネットワークの上りまたは下りの料金は無料となっています。

オブジェクトの Durable Reduced Availability Storage へのコピー、発端となるバケット オブジェクト上でのオブジェクトのライフサイクル管理の実行、およびオブジェクトがたとえば週ごとにバックアップ プロジェクトに複製されていることを確認したあとで、そのオブジェクトを削除することによって、ログ複製のストレージ費用を削減することができます。

Cloud Monitoring を使って、リソースをモニターし、アラートを生成

Google Cloud Monitoring を使えば、VM インスタンス、App Engine、Cloud Pub/Sub などのさまざまなリソースをモニターすることができます。このようなモニタリング機能の多くは自動的に提供され、必要なのはアラートのしきい値の設定だけです。

Cloud Platform は、特定ログエントリを検出し、それらアイテムについてのカスタム メトリクスを構築する機能も提供します。

Cloud Platform を使い、ロギングとモニタリングのすべてのニーズを集約

Cloud Monitoring により、Cloud Platform の外側にある VM からモニタリング指標を送ることができます。インストールされたエージェントを使えば、オンプレミスのリソースと他のクラウドのリソースなど、単一のダッシュボードにある、すべてのリソースにレポートとアラートを生成することができます。

アクティビティ ページを使って、組織のプロジェクトでのアクティビティを閲覧

Cloud Platform Console 内のアクティビティ ページは、すべてのプロジェクトで、組織全体にアクティビティのストリームを提供します。ストリームは、1 つまたは複数のプロジェクト、アクティビティのタイプ、データ範囲によってフィルタリングすることができますので、変更または調整に迅速に焦点を定めることが可能となります。サービスのコアセットは、現在のアクティビティ ストリームをサポートしており、将来的にさらに多くのストリームが追加されます。

サポートとトレーニング

稼働中のアプリケーションには、Gold 以上のサポートをおすすめします

サポート パッケージは、組織全体を対象としています。さまざまなサポート パッケージを利用できますが、稼働中のプロジェクトのクリティカルな問題にタイムリーに対応するためには、Gold と Platinum のパッケージを強くおすすめします。

コミュニティは優れたサポート情報源

Google の社員は、ユーザーのコミュニティを積極的にサポートし、奨励しています。Cloud Platform についての詳細な情報を得られる、一般的なコミュニティの場所を記したリストは、Google Cloud Platform コミュニティに参加でご覧いただけます。

入門者向けと上級者向けのトレーニングにより、よくある落とし穴を回避

Google では、入門者向けの詳しい概要紹介から、特定のテクノロジーに関する詳細で、深遠なセッションまでを網羅した、Cloud Platform 用の認定トレーニングを提供しています。Google Cloud Platform ウェブサイトのクラスを探すをご利用ください。

少なくとも組織の重要な人物には、Cloud Platform 認定を受けさせることを推奨いたします。CPO200: Google Cloud Platform for Systems Operations Professionals コースは、Compute Engine アプリケーションのデプロイと管理を行う人々には、とりわけ役立ちます。

優れたプロダクトを内部に集約

Cloud Platform には、創造的かつ予期せぬ方法で組み合わせることのできる、多様なプロダクト、サービス、API があります。Google は、このようなプロダクトへの投資を続けており、新しい機能が次々と導入されています。組織の情報、経験、パターンを wiki、Google サイト、または内部のサイトといった内部の知識ベースにキャプチャすることで、価値を生み出すことができます。

新しいユーザーにアドバイスでき、組織のベストプラクティスにもとづいて特定の Cloud Platform プロダクトを使用できるように手助けできる、プロダクト エキスパートのリストを wiki に加えましょう。

内部にサポート用クリアリングハウスを構築

組織の代表としてサポート チケットを提出する権限が与えられる人数には、限りがあります。そのため、内部にサポート用クリアリングハウスまたはトリアージ デスクを設立することを推奨します。このアプローチにより、チケットの重複や連絡ミスを避けることができ、Google Cloud Support との連絡状況を最大限にわかりやすく保つことができます。

Google パートナーの活用

組織の専門知識と能力を外部からの協力で補完する必要も、ときにはあるでしょう。Google では、このような架け橋となりえる、充実したパートナー エコシステムを導入しています。パートナーについての詳しい情報は、Google Cloud Platform パートナーをご覧ください。

Cloud Platform 関係の最新ニュースと発表を入手

Google Cloud Platform ブログをフォローして、最新のニュース、発表、カスタマー ストーリーに常に触れられるようにしましょう。

課金と費用の特長

毎月の料金は、プロジェクトごと、それからリソースタイプごとに分類されます

毎月の請求書は、請求管理者にメールで送られます。請求書自体には、たくさんの詳細情報が含まれています。請求書では、リソースの利用が最初はプロジェクトごとに分類され、それからリソースタイプごとに分類されています。プロジェクトのネーミングを慎重に行えば、どのチームまたは製品がリソースを消費しているかが、とても簡単にわかるようになります。この情報を使えば、組織内の部門への入金取り消しを簡単に行えるようになります。

請求書のエクスポートを毎日行い、機械が読み取り可能なバージョンに請求書を変換

請求書エクスポート機能を使えば、請求書の詳細な行項目に匹敵するものを毎日、発行できるようになります。このファイルは、JSON または CSV のいずれかのフォーマットで、Cloud Storage バケットに発行することができます。この生データにより、Cloud Platform の利用と費用に関するレポートを毎日、生成することができます。請求書のエクスポートは、Cloud Platform Console の請求先アカウント管理エリアで行えます。

プロジェクト ラベルを使い、請求書エクスポートのプロジェクトをより細かく分類

Cloud Platform Console の[プロジェクト] ページでは、キーバリュー ペアとして、カスタムラベルをプロジェクトに追加することができます。これらのラベルは、請求書エクスポート ファイル内で表示されます。このラベルを適用すれば、プロジェクトをさらに細かく分類することができます。

クレジットは、特定のプロジェクトではなく、課金アカウントに適用されます

払い戻しあるいはプロモーションなどの理由でクレジットを受け取る場合、そのクレジットは、特定のプロジェクトではなく、課金アカウントに適用されます。つまり、正確な費用計算が若干複雑になる場合があるため、すべてのプロジェクトは、クレジットが消費されるまで、クレジットのプールから分離されます。ただし、クレジットは通常、それほど頻繁に適用されませんので、費用計算に大きな影響を与えることはあまりないでしょう。

プロジェクト支出に上限を設けることができます

Compute Engine の費用は、割り当てシステムによって管理されています。それぞれのプロジェクトには、そのプロジェクトが消費できるリソースの最大量を示す、特定の割り当てが設けられています。この割り当てを調整するには、割り当て変更リクエスト フォームに記入します。

自動スケーリング リソースである App Engine の場合は、サポート チケットを開けば、日々の最大予算を指定する機能を有効にすることができます。予算のしきい値を越えた場合、アプリケーションが完全に動作を停止しますので、この機能の使い方にはご注意ください。上限は概算であり、完全に正確な消費費用の計算は、オフライン ジョブで行われる必要があります。

毎月の支出しきい値のアラートを設定

課金アカウントごとに、毎月のしきい値を設定することができます。これは、課金アカウントでの支出を制限するものではありませんので、ご注意ください。これは、モニタリングのメカニズムに過ぎません。アカウントが、この毎月のしきい値の 50%、90%、100% に達すると、課金管理者に通知が送られます。課金プロセス完了後の実際の課金額は、さらに高くなる場合があります。Cloud Platform Console 内の課金アカウントについては、[アラート] ページでこの設定を変更することができます。

BigQuery 費用のモニターと分析

BigQuery の Jobs:list メソッドを使って、過去 6 か月間のクエリごとの課金バイト数を知れば、課金の前に BigQuery 費用の試算を得ることができます。BigQuery の Jobs:list メソッドを使って、クエリとその発行者を見れば、個々のクエリの費用をドリルダウンすることができます。

リスク マネジメント

プロジェクトを使って、リソースの所有権を指定

Cloud Platform のプロジェクトを使って、組織内の Cloud Platform リソースの所有権を指定することができます。複数のプロジェクトとそれに含まれるリソースを所有できるのは、特定の部門に限られるということにご注意ください。プロジェクト ラベルを使えば、組織の所有権またはトラックしたい他のディメンションを表示することができます。たとえば、owner:marketing または cost-center:cc-123 などのラベルをプロジェクトに追加することができます。このラベルは、Cloud Platform Console とエクスポートされた請求書のなかで見えるように設定でき、API 呼び出しのフィルターとして使用することができます。

新しいプロジェクトを作成できるのは、課金管理者だけです

課金管理者は、管理する課金アカウントに関連付けされる、新しい課金可能なプロジェクトを作成できる、唯一の人物です。リソース支出に責任を負う人物を課金責任者にすることで、リソースの利用と費用に対する責任が生まれるようになります。

プロジェクト オーナーを使って、所有されているリソースへのアクセスを制御する責任を委任

それぞれのプロジェクトの各オーナーは、個人でなければならず、グループがオーナーになることは許されません。これらのオーナーは、プロジェクトにアクセスできる人物とそのアクセスのタイプ、つまり役割を決めることができます。プロジェクト オーナーを使って、組織内のリソースに対する責任を委任しましょう。

リソースラベルを使って、プロジェクト内またはプロジェクト間でオーナーをよりはっきりと識別

VM インスタンスなどの一部のリソースは、ネームバリュー ラベルを加えることができます。このようなラベルを使えば、owner:johndoe のような、リソース所有権をより細かく分類することができます。

権限が最小限になるように、適切な許可をユーザーに付与

Cloud Platform には、権限が最小限になるように許可を微調整するための、いくつものメカニズムがあります。デベロッパーには、プロジェクト レベルで最小限必要な権限、つまり viewereditor または owner といった役割を付与します。このような許可は、Compute Engine や Cloud Storage といったリソースに継承されます。owner 許可の目的は、メンバー、承認などを管理することにあります。

デベロッパーにプロジェクト レベルのアクセスが本当に必要なのか、あるいは特定の Cloud Platform リソースへのアクセス権限を付与するだけで十分なのかを、検討しましょう。たとえば、インスタンスに SSH キーを追加することで、プロジェクトへのアクセスまたはプロジェクト内のすべてのインスタンスへのアクセス権限を付与することなく、デベロッパーに個々の仮想マシン インスタンスへのアクセス権限を付与することができます。

MACL レポートでポリシーの準拠状況をモニター

セキュリティ レポートを使って、特権管理者といったドメインでの役割をモニターします。あるいは、Roles API を使って、中央集中的なレポーティング ソリューションで役割をモニターし、コンプライアンス違反があれば、アラートの生成または許可の取り消しが自動的に行われるようにします。

Cloud Platform Console を使って、プロジェクトの利用状況をモニターし、ポリシー外の業務割り当てがないかチェックしましょう。あるいは、中央集中的なレポーティング ソリューションの代わりに Cloud IAM API を使い、アラートの生成またはアクセス権限の取り消しが自動的に行われるようにします。

Cloud Storage Bucket Access Controls API を使って、プロジェクトの利用状況をモニターしてポリシー外の業務割り当てがないかをチェックし、アラートの生成またはアクセス権限の取り消しが自動的に行われるようにします。監査ログの場合、これがとりわけ重要となります。

ポリシー付与システムでポリシーを徹底

Cloud Platform でのロギング、モニタリング、監査により、脅威を認識し、リスクを緩和することができます。また、サードパーティのポリシー付与システムとの統合、あるいは自社システムの構築により、ポリシーを定義、管理、徹底することができます。そうすることにより、プロジェクトの所有権に関係する役割をポリシー管理の役割と分離させることができます。この種のスキームを正確に実装するには、プロジェクト オーナーのアカウントと権限、とりわけ Cloud Storage での権限のような、継承された権限についての、優れた、先進的なプラニングが必要になります。さらに、API が必要なポリシー管理操作をサポートするかどうかの検討も必要となるでしょう。

災害復旧計画

サービスが中断される事態はいつでも発生する可能性があります。ネットワークに障害が発生したり、最新のアプリケーションが重大なバグを引き起こしたり、まれに、自然災害への対処が必要になる場合があります。

状況が改善しない場合に備えて、堅牢で、目的がはっきり定められ、十分にテストされた災害復旧計画を用意しておくことが重要です。Cloud Platform には、助長性、拡張性、コンプライアンス、セキュリティといった、災害復旧計画の実施に必要な手段が数多くそろっています。

災害復旧クックブックには、いくつものシナリオが書かれており、Cloud Platform の活用方法がわかるようになっています。

利用規約とコンプライアンス証明書についての理解

以下が重要なリンクとなります。

次のステップ

Google Cloud Platform のその他の機能をお試しください。チュートリアルをご覧ください。

外出先でもリソースをモニタリング

Google Cloud Console アプリを入手して、プロジェクトの管理にお役立てください。

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