請求関連のジョブ機能の IAM の役割

このトピックでは、IAM 権限を設定する方法について、課金シナリオの一連の例を示します。企業の課金関連機能の役割に対して付与する IAM 役割について、シナリオ形式で説明していきます。以下に示す例は、組織の課金タスクを管理する課金管理者や従業員を主な対象者としています。

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

スタートアップ時の課金権限の設定

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

以下の表は、組織管理者(このシナリオでは CEO)がスタートアップ時に他の従業員に付与できる課金 IAM の役割と、付与する役割のリソースレベルを示しています。

役割: 組織管理者 組織管理者の役割により、CEO はオフィス マネージャーに各種の権限を割り当てることができます。
リソース: 組織
メンバー: CEO
役割: 課金管理者 課金管理者の役割により、オフィス マネージャーと CEO は、プロジェクトの内容を表示するための権限が付与されなくても支払いと請求書を管理できるようになります。
リソース: 組織
メンバー: オフィス マネージャー、CEO

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

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

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

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

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

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

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

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

請求先アカウントへの権限の割り当て:

請求先アカウントの課金管理者の役割をユーザーに付与するには、課金コンソールで付与を行う必要があります。請求先アカウントが設定されているアカウントから、その請求先アカウントの課金管理者の権限を財務マネージャーに付与します。

プロジェクトに関連付ける必要のある IAM ポリシーは、次のようになります。

{
  "bindings": [
  {
     "role": "roles/viewer",
     "members": [
               "group:developers@example.com"
     ]
  }
  ]
}

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

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

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

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

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

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

役割: 課金管理者 課金管理者の役割は、プロジェクトと請求先アカウントを関連付ける権限、プロジェクトの課金をオフにする権限、顧客に再販するアカウントのクレジット カード情報の表示する権限を IT 部門に付与します。

ただし、プロジェクトの内容を表示する権限は付与しません。

リソース: 請求先アカウント
メンバー: IT 部門
役割: 課金ユーザー 課金ユーザーの役割は、課金を有効にする(組織のすべてのプロジェクトについて、組織の請求先アカウントとプロジェクトを関連付ける)権限をサービス アカウントに付与することにより、サービス アカウントに対して、課金を有効にする必要がある API を有効にすることを許可することです。
リソース: 組織
メンバー: プロジェクト作成の自動化に使用されるサービス アカウント
役割: 閲覧者 デベロッパーの役割により、デベロッパーは担当プロジェクトの費用を表示できるようになります。
リソース: プロジェクト
メンバー: プロジェクトのデベロッパー

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

請求先アカウントの課金管理者の役割をユーザーに付与するには、課金コンソールでそのためのオペレーションを行う必要があります。つまり請求先アカウントが設定されているアカウントから、その請求先アカウントの課金管理者の権限を財務マネージャーに付与します。

次に、階層内の別々のレベルに関連付けるための 2 つの別個の IAM ポリシーが必要です。

組織レベルで関連付ける必要がある最初の IAM ポリシーは、サービス アカウントに課金ユーザーの権限を付与するためのものです。これは次のようになります。

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

プロジェクト レベルで関連付ける必要のある 2 番目の IAM ポリシーは、デベロッパーにプロジェクトの閲覧者の権限を付与するためのものです。

{
  "bindings": [
  {
     "role": "roles/viewer",
     "members": [
       "group:developers@example.com"
     ]
  }
  ]
}

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

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

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

リソース: プロジェクト 課金作成者の役割により、デベロッパーは次のことが可能になります。
  • 新しい請求先アカウントを作成する
  • 請求先アカウントをプロジェクトに関連付ける
役割: 課金作成者
メンバー: デベロッパー

このシナリオの IAM ポリシーはプロジェクト レベルで関連付ける必要があり、次のようになります。

{
  "bindings": [
  {
     "role": "roles/billing.creator",
     "members": [
               "group:developers@example.com"
     ]
  }
  ]
}

コストの集計

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

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

  • プロジェクトごとにリソースをまとめる。コストはプロジェクトごとに表示され、プロジェクト ID が請求書エクスポートに含まれます。
  • 追加のグループ情報を表すラベルを使ってプロジェクトに注釈を付ける。たとえば、environment=test. Labels を請求書エクスポートに含めて、より詳細に分類することができます。ただし、プロジェクトのラベルはプロジェクトの他のメタデータと同じ方法で許可されるため、プロジェクトの所有者がラベルを変更することができます。このため、変更してはいけない内容について従業員を指導し、監査ログを使って監視するか、従業員には細分化した権限のみを付与してプロジェクトのメタデータを変更できないようにするといった対策が必要です。

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

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

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

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

Cloud Identity and Access Management のドキュメント