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

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

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

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

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

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

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

このシナリオで組織リソースに接続されている Cloud 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 リソースにアクセスすることはできません。デベロッパーは担当プロジェクトに関する費用は表示できますが、組織全体の費用を表示することは許可されません。

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

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

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

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

課金コンソールを使用して、請求先アカウントに関する請求先アカウント管理者役割をユーザーに付与します。請求先アカウントが設定されているアカウントから、その請求先アカウントに関する請求先アカウント管理者役割を財務マネージャーに付与します。

プロジェクトへの接続を必要とする Cloud IAM ポリシーは、次のようになります。

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

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

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

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

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

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

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

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

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

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

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

課金コンソールを使用して、請求先アカウントに関する請求先アカウント管理者役割をユーザーに付与します。請求先アカウントが設定されているアカウントから、その請求先アカウントに関する請求先アカウント管理者役割を財務マネージャーに付与します。

次に、別々の階層レベルに接続するための 2 つの別個の Cloud IAM ポリシーが必要です。

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

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

2 番目の Cloud IAM ポリシーは、プロジェクト レベルで接続する必要があります。デベロッパーにプロジェクトの閲覧者の役割を付与します。

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

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

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

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

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

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

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

コストの集計

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

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

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

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

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

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

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

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