高等教育機関での IAM と Cloud Billing の使用に関するベストプラクティス

大学、短期大学、専門学校、その他の高等教育機関の多くは、他の業種の企業と比較して独自の IT ニーズを持っています。このガイドでは、教育機関の Google Cloud 環境を設定する際のベストプラクティスを紹介し、いくつかの重大な問題の概要を説明します。

ガイドを理解しやすくするために、基本的な用語の定義を以下に示します。

組織ノード: 組織ノードは、学校などの組織を表します。Google Cloud リソース階層内のルートノードです。
フォルダ: フォルダによって組織のリソースが整理されます。Identity and Access Management（IAM）ポリシーがフォルダレベルで構成されると、ポリシーはフォルダに含まれるリソースに推移的に適用されます。
プロジェクト: プロジェクトレベルでは、すべての Google Cloud サービスの有効化と使用、API の管理と請求、共同編集者の追加と削除、および権限の管理を行います。
IAM: IAM は組織とプロジェクトのポリシーを制御します。プロジェクトメンバーが仮想マシン（VM）、ログ、およびその他のリソースを管理するために必要なアクセスレベルを管理します。
ロール: ロールは権限のコレクションです。ユーザーに権限を直接割り当てることはできません。代わりに、ロールをユーザーに付与します。ロールを付与すると、ロールに含まれるすべての権限が付与されます。
リソース: コンピュータやハードディスクドライブなどの物理アセット、または仮想マシン（VM）などの仮想アセット。リソースの例には、プロジェクト、Compute Engine インスタンス、Cloud Storage バケットなどがあります。

G Suite for Education の設定

学校が Google Cloud の機能を調査するにあたって、G Suite for Education を設定することが出発点になることが一般的です。Gmail を使用しない場合でも、G Suite for Education を設定すれば、Gmail などの使用しないサービスを無効にしても、Google Cloud の ID と認証にユーザーアカウントやグループを活用できます。無料の G Suite for Education アカウントの利用資格がない商業主体の場合には、Cloud Identity がオプションとなります。

リソースの管理

Google Cloud では、組織、フォルダ、プロジェクトで構成される階層状のコンテナシステムが提供されます。これらの構造内で、他のリソース（Compute Engine 仮想マシン（VM）や Pub/Sub トピックなど）を整理できます。この階層は、複数のリソースに共通するアクセス制御や構成設定などの要素を管理するのに役立ちます。これらのリソースは、Resource Manager を使用してプログラムによって管理できます。

多くの大学を含む大規模な機関には、多くのプロジェクトが存在し、Google Cloud リソースを直接操作するユーザーが多数います。既存の IT ガバナンスとアクセス制御戦略を最大限にサポートするには、Google Cloud リソースの組織化を一元的に実施することをおすすめします。

組織とフォルダ

リソースは組織ノードをルートとして整理されます。フォルダは、組織ノードの下に最大 4 つのレベルでネストすることができます。これらのフォルダにはプロジェクトを含めることができます。プロジェクトの下に子ノードとしてその他のリソースが含まれています。各リソースの親は 1 つだけです。親リソースのアクセス制御ポリシーと構成を設定すると、子リソースは親リソースのポリシーと設定を継承します。

組織ノードによって、G Suite for Education ドメインでユーザーが作成するすべてのプロジェクトがスーパー管理者に対して表示されます。G Suite for Education の各プライマリドメインに 1 つの組織ノードがあります。セカンダリ G Suite ドメインは独自の組織ノードを持ちません。デフォルトでは、G Suite のスーパー管理者は組織のポリシー設定への取消不能なアクセス権を持っています。IT とクラウド管理が個別に管理されている組織の場合、G Suite の特権管理者は組織を管理する組織管理者を割り当てる必要があります。

典型的な Google Cloud 組織の構造は、次のようになります。

一般的な Google Cloud 組織の構造

組織ノードが作成される前にプロジェクトが作成された場合は、これらの孤立したプロジェクトを組織ノードに移行できます。

組織ノードのすべてのプロジェクトを一覧表示するには、次のコマンドを実行します。

gcloud projects list --filter "parent.type=organization parent.id=$ORG_ID"

G Suite for Education ドメインを持つ学校が Google Cloud を採用している場合、デフォルト構成では組織ノードが 1 つです。次のセクションでは、単一と複数の組織ノードのアプローチについて説明します。

一元化された組織ノードを使用する場合

一元化された組織ノードは G Suite ドメインにマッピングされ、これが IAM の信頼できる情報源となります。各フォルダには独自の一元管理者とともに独立した IAM とその他のポリシーを設定できます。

一元化された組織ノード

詳しくは、以下のリソースをご覧ください。

クロスプロジェクトネットワークや共有イメージなどのグローバルリソースを組織内のすべてのユーザーからアクセスできるフォルダにホストできます。

個別の組織ノードを使用する場合

学校内の学科を一元管理されない独立した組織として扱う場合は、次の図に示すように個別の組織を作成することを検討してください。

個別の組織構造

この構成を実装するには、school.edu と lab3.school.edu を個別のプライマリ G Suite ドメインとして設定し、個別の組織ノードを作成します。このオプションは、以下のことを決定した場合にのみ使用してください。

個別の Identity ドメインを維持する。
IAM、カスタムロール、請求、割り当て、および構成の設定が中央の school.edu 組織ノードから独立した状態を維持する。

IT ガバナンスを一元化している多くの学校で、2 つの独立した Google Cloud 環境を管理することは、さらなるオーバーヘッドの発生を意味します。また、複数の組織ノード間のポリシーが時間の経過とともに分岐する可能性があります。

フォルダの使い方

フォルダを使用すると、Google Cloud リソースの整理や、ポリシーの適用、管理権限の委任によって、学科やチームの自律性を向上させることができます。また、フォルダは、プロジェクトレベルより高度にポリシーを管理し、アクセスを制御するのに役立ちます。フォルダ内にネストされたフォルダ、プロジェクト、およびリソースは、親フォルダのポリシーを継承します。

ここでは、フォルダの使用が適切な場合のシナリオをいくつか示します。

ある教育機関に、工学、ビジネス、一般教養などの学科があり、それぞれ独自の IT グループがある。
Microsoft Active Directory などの LDAP ディレクトリに基づいて確立された構造にマッピングされている。
IT インフラストラクチャ、リサーチコンピューティング、指導と学習など、使用例ごとにプロジェクトを分離する。

プロジェクトとリソース

割り当てて使用する Google Cloud のリソースはすべて、プロジェクトに属していなければなりません。プロジェクトを、構築しようとしている構成エンティティとして考えてみましょう。プロジェクトは、設定、権限、そしてアプリケーションを記述したその他のメタデータで構成されます。1 つのプロジェクト内のリソースは、リージョンやゾーンによって異なるルールに従って、内部ネットワークを介して通信することによってスムーズに連携します。各プロジェクトで使用するリソースは、プロジェクトの境界を越えて分離したままで、外部ネットワーク接続または共有 Virtual Private Cloud（VPC）ネットワークを介してのみリンクできます。

各 Google Cloud プロジェクトには次の属性が含まれます。

ユーザーが提供するプロジェクト名
プロジェクト ID（ユーザーまたは Google Cloud が指定）
Google Cloud から提供されるプロジェクト番号

新しいプロジェクトを設定するときは、次のいずれかのシナリオに基づいてプロジェクトを作成することもできます。

ワークロードや小規模なチームを基準にしたプロジェクトの設定など、アプリケーションやプロジェクトのオーナー権限。
アプリケーションを本番環境プロジェクトおよび非本番環境プロジェクトに分割する。このように、非本番環境のテスト環境で行われた変更は本番環境に影響を与えず、デプロイスクリプトを使用して変更をプロモートまたは伝播させることができます。
ラボ間でのコンピューティングリソースとデータリソース、またはラボ内のプロジェクトの分離。この分離によって、完全な自律性とプロジェクト間のデータ分離が可能になります。これは、ラボが競合関係にあるステークホルダーと一緒に複数のプロジェクトに取り組んでいる場合に便利です。

プロジェクトは請求先アカウントに関連付ける必要があります。詳細についてはこのドキュメントの後半で説明します。新しいプロジェクトを既存の請求先アカウントに関連付けることができるのは、請求先アカウント管理者または請求先アカウントユーザーの役割を持つユーザーのみです。

割り当て

Google Cloud 内の多くのリソースが割り当てによって制限されます。たとえば、新しく関連付けられた請求先アカウントにリンクされている新しいプロジェクトには、Compute Engine 上の 8 つの仮想 CPU の割り当てがあります。デフォルトでは発行されない GPU などのリソースや新しいリソースを追加するには、割り当ての増加をリクエストします。

リソースの割り当てに加えて、組織では作成するプロジェクトの数が制限されます。プロジェクトを削除しても、プロジェクトが完全に消去されるまでの数日間はプロジェクトの割り当ての一部として残ります。

信頼境界

プロジェクトの構造を決定する際には、IT の信頼の境界を検討してください。この境界は多くの場合、既存の IT ガバナンスやセキュリティモデルに沿ったものになります。たとえば、工学、ビジネス、法律などのさまざまな学科が、相互間の信頼の境界を維持するかどうか、学校内の複数の学科で互いに信頼し合うかどうかを検討します。

必要最小限のアクセス権限に関する IT セキュリティのおすすめの方法を適用することで、単一のプロジェクト内および複数のプロジェクト間で、ユーザーアカウントとサービスアカウントに異なる役割を付与できます。ユーザーが 1 つのプロジェクトに対しては管理者レベルのアクセス権を持ち、他のプロジェクトに対しては閲覧者または読み取り専用権限しかない場合、Google Cloud の IAM ポリシーを使用してこれらのロールを明示的に定義できます。詳しくは、最小権限に関する IAM ガイダンスをご覧ください。

IAM ポリシー

大規模な組織では、セキュリティやネットワーク管理などのオペレーションチームをプロダクトチームから分離することがよくあります。この分離を実現するには、使用するリソースの管理を他チームに委ね、最小権限の原則に沿った形でリソースを使用する必要があります。この分離を構成するには、IAM とサービスアカウントを使用します。

IAM では、誰がどのレベルのリソースにアクセスできるかを定義することでアクセス制御を管理します。IAM ポリシーを作成することによって、ユーザーにロールを付与します。IAM ポリシーは、そのリソースに対して誰がどの種類のアクセス権を持つかを定義および制御する、リソースに付けられたステートメントの集合です。特定の Google Cloud リソースに対してきめ細かなアクセス権を付与するには、事前定義ロールを使用するか、カスタマイズされた IAM ロールを定義します。

特権アカウントの使用方法

最小権限の原則に従って、頻繁に使用されないアカウントに特権管理者のロールを割り当てます。たとえば、日々の活動のためには jo.watanabe@school.edu を使用し、G Suite 管理コンソールや Cloud Console に変更を加える際には jo.watanabe.admin@school.edu を使用する場合があります。

サービスアカウントの使用方法

Google Cloud では IAM サービスアカウントを使用してGoogle API 呼び出しを行い、個々のユーザー認証情報が直接関与しないようにします。このアカウントの特徴の 1 つは、ID とリソースの両方として扱われることです。

サービスアカウントが ID として機能するときは、Cloud Storage バケットなどのリソースにアクセスできるように、そのアカウントにロールを付与します。
サービスアカウントがリソースとして機能するときは、BigQuery データセットへのアクセス権を付与するのと同じ方法で、そのアカウントにアクセスする権限をユーザーに付与する必要があります。ユーザーに所有者、編集者、閲覧者、またはサービスアカウントユーザーのロールを付与できます。サービスアカウントユーザーは、サービスアカウントがアクセスするすべてのリソースにアクセスできます。

グループを使用する場合

ポリシーで個人ではなくグループを使用すると、チームメンバーが参加したり離脱したりするときに、管理者がグループのメンバーシップを調整できます。その結果、正しいポリシーの変更が自動的に行われます。この方法を実装するには、職務に基づいたグループを各プロジェクトまたはフォルダに作成します。次に、ジョブ機能に必要な複数のロールを各グループに割り当てます。

グループ管理は、G Suite の一部であるビジネス向け Google グループによって処理されます。G Suite 管理者ユーザーまたは代理管理者は、管理コンソールを使用してこのツールにアクセスできます。

ネットワークオプション

Virtual Private Cloud（VPC）を使用すると、プライベートクラウドサービスを分離できます。たとえば、VPC を使用して、すべてのプロジェクトにまたがる共通のプライベート RFC 1918 IP 空間であるネットワークを設定できます。次に、任意のプロジェクトのインスタンスをこのネットワークまたはそのサブネットワークに追加します。

また、単一のネットワークに仮想プライベートネットワーク（VPN）を接続することもできます。このネットワークは、プロジェクトのすべてまたは一部で使用できます。VPN 接続を使用すると、Google Cloud 固有の RFC 1918 IP スペースへの接続、またはオンプレミスネットワークの RFC 1918 IP スペースを拡張することが可能になります。

Google では、VPC インスタンスに接続するための次のオプションを提供しています。

相互接続		ピアリング
専用の相互接続	IPsec VPN	ダイレクトピアリング	キャリアピアリング
企業ネットワークと RFC 1918 IP 空間をクラウドに拡張するのに便利です。 Google Cloud リソースへのアクセスには VPN は必要ありません。	公共のインターネットを経由して Google に接続する場合や、少量のデータ接続に便利です。	このソリューションでは、Google に直接アクセスして、VPN やパブリックインターネット経由のアクセスよりも下り料金を最大 50% 節約できます。	ダイレクトピアリングのメリットを利用したいものの、パートナーなしではピアリング要件を満たすことができない場合に役立ちます。
リンクあたり 10 Gbps	トンネルごとに 1.5〜3 Gbps	リンクあたり 10 Gbps	パートナーのオファリングによって異なる

これらのオプションの詳細については、Cloud Interconnect ページをご覧ください。

ダイレクトピアリングを使用する場面

登録された自律システム番号（ASN）とパブリックルーティング可能な IP プレフィックスをお持ちの Google Cloud のお客様については、Google とのダイレクトピアリングを確立できます。このオプションでは、公共のインターネットと同じ相互接続モデルを使用しますが、中間にサービスプロバイダがありません。詳細については、Google とのピアリングをご覧ください。

キャリアピアリングを使用する場面

パブリック ASN をお持ちでない、またはサービスプロバイダを使用して Google に接続を希望されるお客様には、キャリアピアリングサービスをご用意しています。キャリアピアリングは、Google エッジネットワークとエンタープライズクラスの接続を希望するお客様向けに設計されています。

クラウドのお支払いとご請求

Cloud Console を使用して、Cloud 請求先アカウントを管理できます。Cloud Console から、お支払い方法や管理者の連絡先などのアカウント設定を更新できます。Cloud Console で、予算の設定、アラートのトリガー、支払い履歴の表示、課金データのエクスポートも行えます。

ほとんどのユーザーにとって、1 つの Cloud 請求先アカウントで十分です。機関全体の割引が、アカウントに関連付けられているすべてのプロジェクトに適用されます。ユーザーは毎月の請求書を決済するために Google に対して 1 回の支払いを行います。部門専用またはラボ専用のプロジェクトに対しては社内の IT チャージバックプロセスを使用して請求を受けることができます。

1 つの請求先アカウントは次のようになります。

単一の請求先アカウント

請求に関する考慮事項によって、Google Cloud のプロジェクトとフォルダの整理方法にも影響を生じる場合があります。内部コストセンターに応じて、次の図のように整理できます。

複数のフォルダに分かれている請求先アカウント

この図では、フォルダによってコストセンター、部門、または IT プロジェクトに関連付けられているすべてのプロジェクトとアセットが識別されています。
プロジェクトによってリソースが整理されます。コストはプロジェクトごとに表示され、プロジェクト ID が課金データのエクスポートに含まれます。
environment=test など、追加のグループ情報を表すラベルを使ってプロジェクトに注釈を付けます。ラベルは請求書エクスポートに含まれます。
コストセンターはプロジェクト名または ID にエンコードされます。

このモデルは、各フォルダを個別の内部コストセンターに合わせる場合にも利用できます。ただし、Google は特定の請求先アカウントに対して 1 つの請求書を送信するため、内部チャージバックが必要です。

複数の請求先アカウントは、コストセンターで個別の請求書に対して支払いを行う必要がある場合、または一部のワークロードに関して別の通貨で支払う必要がある場合のオプションです。このアプローチでは、各請求先アカウントに対する署名入り契約書が必要となる場合があります。

Cloud 請求先アカウントの管理

Cloud 請求先アカウントの役割は、請求先アカウントを管理するのに役立ちます。組織レベルで以下の請求役割を割り当てることができます。

役割	説明
請求先アカウント管理者	組織内のすべての請求先アカウントを管理します。
請求先アカウント作成者	組織内の請求先アカウントを作成します。
請求先アカウントユーザー	プロジェクトと請求先アカウントをリンクします。
プロジェクト支払い管理者	プロジェクトの請求先アカウントの割り当てと、請求の無効化を行うアクセス権を付与します。

組織ノードレベルで請求先アカウント管理者の役割を付与し、組織内のすべての請求先アカウントを表示できるようにします。請求先アカウントを作成できるユーザーと作成方法を制限するには、請求先アカウント作成者の役割を使用し、どのユーザーがこの権限を持つかを制限します。詳細については、以下の Google ヘルプセンターの記事をご覧ください。

請求先アカウントの変更

プロジェクトの Cloud 請求先アカウントを変更する場合、またはすべての請求を無効にする場合は、次の手順に沿って操作します。

Cloud Console の左側のナビゲーションメニューで、[お支払い] をクリックします。
プロジェクト名の右側にあるその他アイコンをクリックし、[請求先アカウントを変更] をクリックします。このアイコンを使用して請求を無効にすることもできます。これにより、プロジェクトが無効になります。

予算の作成

予算によってアラートが生成されますが、プロジェクトに対する請求はオフになりません。つまり、予算を超えても、引き続きプロジェクトが実行されます。プロジェクトが予算を超えて実行されている場合は、手動で請求を無効にする必要があります。または、それ以上の予算超過を防ぐために、課金額が発生しているリソースを停止することもできます。予算はリアルタイムでは更新されないため、プロジェクトが予算超過になってから 1〜2 日はそれを検出できないことがあります。

予算を作成するには、次の手順のとおりです。

Cloud Console で、[お支払い] メニューに移動して、[予算とアラート]、[予算の作成] の順にクリックします。

この例では、すでにその月のアカウントの予算を超過しています。予算によってサービスが無効になるのではなく、予算を超えたときに課金管理者に通知されます。
予算の詳細と、アラートを受け取る予算の使用状況レベルを入力します。
[プロジェクトまたは請求先アカウント] で、予算全体または個々のプロジェクトのどちらを監視するかを選択します。予算機能は、カレンダーの月単位に対して機能します。ある月の予算金額を決めることができます。

課金データのエクスポートの設定

Cloud 請求先アカウントで使用するすべてのサービスの詳細レポートが必要な場合は、Cloud Console の [お支払い] メニューで [課金データのエクスポート] を設定します。詳細を Cloud Storage または BigQuery に保存します。Cloud Storage の使用を選択した場合は、データを JSON 形式または CSV 形式で保存できます。

課金データのエクスポート

課金データを BigQuery にエクスポートすると、設定した制限を超えているプロジェクトをすばやく見つけることができます。請求対象のサービスを確認することもできます。たとえば、次のクエリでは、当月に $0.10 以上を費やしたすべてのプロジェクトが一覧表示されます。[YOUR_BIGQUERY_TABLE] をテーブル名に置き換えます。

SELECT
  project.name,
  cost
FROM
  [YOUR_BIGQUERY_TABLE]
WHERE
  cost > 0.1
ORDER BY
  cost DESC

次のステップ

各 Google Cloud サービスの詳細について学習する。
Google Cloud サービスが Amazon Web Services（AWS）や Microsoft Azure サービスにどのように対応しているかについて学習する。
最初の VM を作成する方法、コンテナイメージをデプロイする方法、TensorFlow モデルをトレーニングする方法について学習する。
Google Cloud のトレーニングの基礎についてのクラスを受講する、または認定を受ける。
Qwiklabs Google Cloud トレーニングラボのカタログを読む。
Coursera から Google Cloud の自習トレーニングコースを受講する。
Google Cloud のその他の機能を試す。チュートリアルをご覧ください。