高等教育機関における Cloud IAM と Cloud Billing でのおすすめの方法

大学、短期大学、専門学校、その他の高等教育機関の多くは、他の業種の企業と比較して独自の IT ニーズを持っています。このガイドでは、教育機関に Google Cloud Platform（GCP）環境を設定する際のおすすめの方法を紹介し、解決すべきいくつかの重要な問題について概説します。

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

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

G Suite for Education の設定

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

リソースの管理

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

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

組織とフォルダ

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

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

一般的な GCP 組織の構造は次のようになります。

一般的な GCP 組織の構造

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

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

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

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

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

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

一元化された組織ノード

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

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

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

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

個別の組織構造

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

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

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

フォルダの使い方

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

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

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

プロジェクトとリソース

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

各 GCP プロジェクトには次が含まれます。

ユーザーが提供するプロジェクト名
ユーザーが提供する、または GCP から提供されるプロジェクト ID
GCP から提供されるプロジェクト番号

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

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

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

割り当て

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

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

信頼の境界

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

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

Cloud IAM ポリシー

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

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

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

最小権限の原則に従って、頻繁に使用されないアカウントに特権管理者の役割を割り当てます。たとえば、日常的なアクティビティに jo.watanabe@school.edu を使用しているものの、G Suite 管理コンソールまたは GCP Console に対して変更を行う際には jo.watanabe.admin@school.edu を使用することが考えられます。

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

GCP では 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 接続を使用して、GCP に固有の RFC 1918 IP 空間に接続したり、オンプレミスネットワークの RFC 1918 IP 空間を拡張したりできます。

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

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

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

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

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

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

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

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

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

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

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

単一の請求先アカウント

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

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

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

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

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

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

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

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

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

請求先アカウントの変更

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

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

予算の作成

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

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

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

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

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

Cloud 請求先アカウントで使用されているすべてのサービスの詳細レポートが必要な場合は、GCP 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

次のステップ

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