請求関連ジョブ機能の IAM ロール

このトピックでは、一連のサンプル請求シナリオで Identity and Access Management（IAM）の権限を構成する方法について説明します。企業の課金関連機能のロールに対して付与する IAM のロールについて、シナリオ形式で説明していきます。以下に示す例は、組織の課金タスクを管理する課金管理者や従業員を主な対象者としています。

ここでは、課金のロールと権限については詳しく説明していません。Billing API の役割と権限の詳細については、Billing API のアクセス制御のページをご覧ください。

小規模企業による課金権限の構成

このシナリオでは、小規模企業が Google の請求先アカウントを構成して使い始めようとしています。この企業では、数人のエンジニアがアプリケーションの開発とメンテナンスを担っていますが、課金管理の担当者はいません。請求書と支払いの照合を担当するオフィスマネージャーはいますが、コンプライアンス上の理由から、このオフィスマネージャーがプロジェクトの Google Cloud リソースにアクセスすることは許可されていません。CEO がクレジットカードを所有し管理しています。

以下の表は、組織管理者（このシナリオでは CEO）が社内の他の従業員に付与できる課金 IAM のロールと、付与するロールのリソースレベルを示しています。

ロール:	組織管理者	組織管理者の役割により、CEO はオフィスマネージャーに各種の権限を割り当てることができます。
リソース:	組織
プリンシパル:	CEO

ロール:	請求先アカウント管理者	請求先アカウント管理者の役割により、オフィスマネージャーと CEO はプロジェクト内容の表示権限がなくても支払いと請求を管理できるようになります。
リソース:	組織
プリンシパル:	オフィスマネージャー、CEO

このシナリオで組織リソースに関連付けられている許可ポリシーは、次のようになります。

{
  "bindings": [
    {
      "role": "roles/resourcemanager.organizationAdmin",
      "members": [
        "user:ceo@example.com"
      ]
    },
    {
      "role": "roles/billing.admin",
      "members": [
        "group:finance-admins-group@example.com"
      ]
    }
  ]
}

おすすめの方法は、グループを使用してプリンシパルを管理することです。上の例の 2 番目のバインディングでは、CEO とオフィスマネージャーを finance-admins-group に追加します。機能を実行できるユーザーを変更する必要がある場合は、グループメンバーシップを調整するだけでよく、許可ポリシーを更新する必要はありません。そのため、2 つの個別のユーザーアカウントはロールバインディングに含まれません。

財務チームによる予算の管理

このシナリオでは、ある大企業が、各部門の財務チームが予算を設定して部門内のチームの支出を表示できるようにしたいと考えています。ただし、財務チームが Google Cloud リソースにアクセスすることはできません。デベロッパーは担当プロジェクトに関する費用は表示できますが、組織全体の費用を表示することは許可されません。

以下の表に示す役割を各部門の財務マネージャーとデベロッパーに付与します。

ロール:	請求先アカウント管理者	この役割により、各部門の財務マネージャーは予算を設定し、部門内の請求先アカウントの支出を表示できるようになりますが、プロジェクトの内容を表示することはできません。
リソース:	請求先アカウント
プリンシパル:	各部門の財務マネージャー

ロール:	請求先アカウント閲覧者	請求先アカウント閲覧者のロールにより、デベロッパーは請求先アカウントの費用を表示できるようになります。
リソース:	請求先アカウント
プリンシパル:	プロジェクトのデベロッパー

このシナリオでは、課金コンソールを使用して、請求先アカウントの財務マネージャーに請求先アカウント管理者ロールを付与します。さらに、請求先アカウントのデベロッパーに請求先アカウント閲覧者のロールを付与します。

完了すると、請求先アカウントの許可ポリシーは次のようになります。

{
  "bindings": [
    {
      "role": "roles/billing.admin",
      "members": [
        "group:finance-admins-group@example.com"
      ]
    },
    {
      "role": "roles/billing.viewer",
      "members": [
        "group:developers@example.com"
      ]
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

デベロッパーが課金を調整できない、お客様のセルフサービスポータル

このシナリオでは、お客様の主幹 IT チームが、セルフサービスポータルの一部として Google Cloud リソースをデベロッパーに提供します。デベロッパーはポータルを介して、Google Cloud プロジェクトやその他の承認済みクラウドサービスへのアクセスをリクエストします。デベロッパーのコストセンターは、消費したクラウドリソース分の料金を主幹 IT チームに支払います。

主幹 IT チームは次のことを行う必要があります。

プロジェクトと請求先アカウントを関連付ける
プロジェクトの課金を無効にする
クレジットカード情報を表示する

主幹 IT チームがプロジェクトの内容を表示する権限を持つことはできません。

デベロッパーは、消費した Google Cloud リソースの実際の費用を表示することはできますが、課金の無効化、課金とプロジェクトの関連付け、クレジットカード情報の表示は行えません。

ロール:	請求先アカウント管理者	請求先アカウント管理者の役割は、プロジェクトと請求先アカウントを関連付ける権限、プロジェクトの課金を無効にする権限、顧客に再販するアカウントのクレジットカード情報を表示する権限を IT 部門に付与します。ただし、プロジェクトの内容を表示する権限は付与しません。
リソース:	請求先アカウント
プリンシパル:	IT 部門

ロール:	請求先アカウントユーザー	請求先アカウントユーザーの役割は、課金を有効にする（組織のすべてのプロジェクトについて、組織の請求先アカウントとプロジェクトを関連付ける）権限をサービスアカウントに付与し、それにより課金の有効化を必要とする API を有効にすることをサービスアカウントに許可します。
リソース:	組織
プリンシパル:	プロジェクト作成の自動化に使用されるサービスアカウント

ロール:	請求先アカウント閲覧者	請求先アカウント閲覧者のロールにより、デベロッパーは請求先アカウントの費用を表示できるようになります。
リソース:	請求先アカウント
プリンシパル:	プロジェクトのデベロッパー

このシナリオでは、許可ポリシーを階層内の異なるレベルに関連付けるため、2 つのオペレーションを別々に実行して適切な許可ポリシーを割り当てる必要があります。

課金コンソールを使用して、請求先アカウントの IT 部門に請求先アカウント管理者ロールを付与します。さらに、請求先アカウントのデベロッパーに請求先アカウント閲覧者のロールを付与します。

次に、組織レベルで許可ポリシーを接続する必要があります。この許可ポリシーは、サービスアカウントに請求先アカウントユーザーのロールを付与します。次のようになります。

{
  "bindings": [
    {
      "role": "roles/billing.user",
      "members": [
        "serviceAccount:my-project-creator@shared-resources-proj.iam.gserviceaccount.com"
      ]
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

デベロッパーによる課金プロジェクトの作成

ある大規模なデジタルネイティブ企業は、請求先アカウント管理者の権限がなくても、すべてのデベロッパーが組織の請求書発行アカウントで課金プロジェクトを作成できるようにしたいと考えています。

デフォルトを超える API を有効化できるようにプロジェクトの課金を有効にする必要があります。したがって、デベロッパーがプロジェクトを作成する場合、プロジェクトを請求先アカウントに関連付けて API を有効化する必要があります。

ロール:	請求先アカウントユーザー	請求先アカウントユーザーのロールを使用すると、デベロッパーは組織内の新しいプロジェクトに請求先アカウントを関連付けることができます。
リソース:	組織
プリンシパル:	デベロッパー

このシナリオの許可ポリシーは組織レベルで関連付ける必要があり、次のようになります。

{
  "bindings": [
    {
      "role": "roles/billing.user",
      "members": [
        "group:developers@example.com"
      ]
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

コストの集計

このシナリオでは、ある会社が、各チーム、部門、サービス、プロジェクトに要しているコストを計算して記録したいと考えています。たとえば、毎月のテスト導入に要するコストを追跡して記録します。

これは次のようにして追跡できます。

プロジェクトごとにリソースをまとめる。コストはプロジェクトごとに表示され、課金エクスポートにはプロジェクト ID が含まれます。
追加のグループ情報を表すラベルを使用してプロジェクトにアノテーションを付ける。たとえば、environment=testのようなラベルを課金エクスポートに含めると、よりきめ細かい分類ができます。ただし、プロジェクトのラベルについてはプロジェクトの他のメタデータと同じ方法で権限が付与されるため、プロジェクトオーナーはラベルを変更することが可能です。したがって、変更してはならないものについて従業員を指導したうえで（監査ログを利用して）監視を行ったり、細分化された権限のみを従業員に付与してプロジェクトのメタデータを変更できないようにするなどの対策が必要です。

データは JSON や CSV にもエクスポートできますが、BigQuery に直接エクスポートすることをおすすめします。この方法では、課金コンソールの課金エクスポートのセクションから簡単に構成できるためです。

各コストセンターが別々の請求書で支払う必要がある場合や、一部のワークロードについて別の通貨で支払う必要がある場合は、コストセンターごとに個別の請求先アカウントが必要です。ただし、この方法では請求先アカウントごとにアフィリエイト契約への同意が必要になります。