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

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

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

プロジェクトとアクセス

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

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

組織で使用されている Cloud Platform リソース間の相互接続が明示的に許可されている場合を除き、プロジェクトは分離境界を設けます。ユーザーとグループには、プロジェクトごとに、viewereditorowner といった異なった役割を付与することができます。役割を割り当てるには、GCP 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 を利用しているかが簡単にわかるようになり、データ分析に使用できます。

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

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

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

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

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

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

認証と ID

このセクションでは、Google Cloud Platform で認証と ID を作成および管理するためのベスト プラクティスを紹介します。

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

Google Cloud Platform では、認証とアクセス管理に Google アカウントが使用されます。Google では、Cloud Platform リソースの可視性、監査、およびアクセスの制御を高めるために、完全に管理された企業用 Google アカウントを使用することを推奨しています。

Cloud Identity では、無料の管理対象 Google アカウントが提供されており、Cloud Platform などの Google サービスで使用できます。各ユーザーに Cloud Identity アカウントを使用することで、Google Admin コンソールからドメイン全体にわたって、すべてのユーザーを管理できます。

G Suite 管理者は、G Suite 管理コンソールからすべてのユーザーと設定を管理できます。デフォルトで、すべての新規ユーザーは G Suite ライセンスに割り当てられます。G Suite ライセンスが不要な開発者のサブセットがある場合、代わりに、Cloud Identity アカウントを追加できます。

詳細については、Cloud Identity の利用を開始するをご覧ください。

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

G Suite のグローバル ディレクトリには、認証と承認に使用される、ユーザーとグループの構造化されたデータストアが用意されています。このグローバル ディレクトリは、Cloud Platform と G Suite の両方のリソースで使用することができ、さまざまな方法でプロビジョニングできます。プロビジョニングされたユーザーは、シングル サインオン(SSO)、OAuth、2 要素認証など、豊富な認証機能を利用することができます。

以下のいずれかのツールまたはサービスを使用して、ユーザーを自動的にプロビジョニングできます。

GCDS は、Cloud Platform と G Suite の両方で、ユーザーとグループを自動的にプロビジョニングできるコネクタです。GCDS を使用して、ユーザー、グループ、従業員以外の連絡先の追加、変更、および削除を自動化できます。LDAP クエリを使用して、LDAP ディレクトリ サーバーから Cloud Platform ドメインにデータを同期できます。この同期は一方向です。LDAP ディレクトリ サーバー内のデータが変更されることはありません。

GCDS は、制御しているマシン上のネットワーク内で実行されます。これは、標準 LDAP またはセキュア LDAP と、セキュア ソケット レイヤー(SSL)を介して、ネットワークの内部で LDAP サーバーに接続されます。この接続は指定したポートで行われますが、デフォルトでは標準 LDAP ポートに設定されています。GCDS は、ポート 443 で HTTPS によるインターネット経由で、G Suite ドメインに接続されます。この接続は、ネットワーク内のプロキシホスト経由で行うこともできます。

独自のソリューションを作成してユーザーとグループをプロビジョニングする場合、Google Admin SDK を使用できます。Admin SDK には、Cloud Platform ユーザーを管理したり、それらのユーザーとグループや組織との関連付けを管理したりするための方法が備わっています。SDK では HTTPS REST エンドポイントがサポートされており、Python、Java、.NET、およびその他のクライアント ライブラリも用意されています。

これらのネイティブ ツールやサービスに加え、多数の大手 ID 管理ベンダーは G Suite グローバル ディレクトリ用のコネクタを提供しています。通常、これらのコネクタは Google Admin SDK の Directory API を使用して、G Suite ユーザーと、それらのユーザーとグループおよび組織の関連付けをプロビジョニングします。Cloud Platform と G Suite では共通のディレクトリ インフラストラクチャが共有されているため、これらのコネクタは Cloud Platform と G Suite の両方で使用できます。

テストやその他の目的でユーザーを手動でプロビジョニングするために、Cloud Platform 管理者は G Suite Admin Console を使用して、ユーザーと、ユーザーのグループおよび組織との関連付けを手動でプロビジョニングできます。

G Suite グローバル ディレクトリの詳細については、グローバル ディレクトリを管理するをご覧ください。

ユーザー プロビジョニング中のアカウント競合の解決

ドメインのメンバーが YouTube や Blogger などの Google サービスにサインアップするなどのために、会社のメールアドレスを使用して個人的な Google アカウントを作成した場合、メンバーを G Suite や Cloud Platform に追加すると、そのようなアカウントによって競合が生じます。既存のアカウントに対する権限を手動で取り消し、新しいユーザー アカウントに移す必要があります。

アカウントの競合問題を回避および解決する方法については、アカウントの競合を解決するをご覧ください。

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

プロジェクトがドメインに関連付けられると、特権管理者という新しい役割が作成されます。特権管理者の役割は、ドメイン自体に適用されます。事前定義されているいずれかの役割を使用するか、カスタム役割を作成し、その管理範囲を定義します。

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

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

SAML 交換で SSO を実装

Cloud Platform では SAML 2.0 ベースの SSO がサポートされているため、Cloud Platform Console、ウェブベースおよびコマンドライン ベースの SSH、および OAuth 認証プロンプトに対してシームレスな SSO を使用できます。gcloudgsutil、および bq など、Cloud Platform のコマンドライン インターフェース ツールでも、ブラウザベースの認証に SAML 2.0 ベースの SSO が使用されます。

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

Google SSO のセットアップの詳細については、G Suite アカウントに対するシングル サインオンのセットアップをご覧ください。Cloud Platform と G Suite は共通のディレクトリ、auth、および SSO インフラストラクチャを共有しているため、このガイドは両方の製品に適用されます。

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

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

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

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

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

Google グループを使用して、大規模な組織全体でプロジェクトの承認を管理できます。役割ベースのアクセス制御(RBAC)に習熟していれば、Google グループは RBAC 役割のようなものであり、Cloud Platform のプロジェクト役割は RBAC における権限のようなものであると考えてもいいでしょう。ユーザーにプロジェクトの役割を割り当てるのと同様の方法で、グループに役割を割り当て、前に説明した方法でグループのメンバーを管理することができます。

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

ユーザーと同じように、サービス アカウントにも、同じような手法で、特定のリソースに対する承認を付与することができます。たとえば、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 では、これらの認証情報も使用できます。

データ送信前のインスタンス ID の確認

インスタンスによって、インスタンスの詳細と Google の RS256 署名が含まれた JSON ウェブトークン(JWT)が生成される場合があります。アプリケーションは Google の公開 Oauth2 証明書に対して署名を照合し、接続を確立したときに使用したインスタンスの ID を確認します。

署名付きインスタンス トークンのリクエストおよび確認方法の詳細については、インスタンスの ID の確認をご覧ください。

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

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

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 ゲートウェイを経由するすべての外部トラフィックのルーティング、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、その他一部のリソースは、その地理的地域内で作成することができます。

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

Use 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 を使って、プロジェクトの役割に対する変更をモニターします。管理コンソールの監査ログを使って、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 を使うことで、ログバケットを別のオーナーのプロジェクトにコピーできます。このアプローチでは、プロジェクト オーナーがコピーの前にオリジナルのバケットを削除したりオリジナルのロギングを無効にしたりすることを防止できません。

このアプローチは、ローカルマシンにコピーすることなく、クラウドベースのコピーができますので、迅速で、効率的です。コピーに対するオペレーション料金はかかりますが、リージョン内のコピーに対するネットワークの上りまたは下りの料金はかかりません

オブジェクトを Nearline Storage にコピーし、元のバケット オブジェクトでオブジェクトのライフサイクル管理を実行して、バックアップ プロジェクトにオブジェクトが複製されていることを確認した後でそれらのオブジェクトを削除することにより、ログ複製によるストレージ費用を削減できます。

Stackdriver Monitoring を使用したリソースのモニタリングとアラートの生成

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

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

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

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

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

GCP 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 の利用と費用に関するレポートを毎日、生成することができます。請求書のエクスポートは、GCP Console の請求先アカウントの管理エリアで行えます。

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

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

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

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

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

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

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

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

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

BigQuery 費用のモニターと分析

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

リスク マネジメント

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

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

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

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

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

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

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

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

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

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

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

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

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

GCP Console を使用して、プロジェクトの利用状況をモニタリングし、ポリシーに含まれていない割り当てがないか確認します。または、一元管理されたレポーティング ソリューションで、代わりに Cloud IAM API を使用し、アラートの生成やアクセスの取り消しが自動的に行われるようにします。

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

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

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

災害復旧計画

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

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

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

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

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

次のステップ

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

このページは役立ちましたか?評価をお願いいたします。

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