IAM-Rollen für abrechnungsbezogene Jobfunktionen

In diesem Abschnitt erfahren Sie, wie Sie IAM-Berechtigungen (Identity and Access Management) für eine Reihe von Abrechnungsszenarien konfigurieren. Sie finden Anleitungen dazu, welche IAM-Rollen den abrechnungsbezogenen funktionalen Rollen in Ihrem Unternehmen für die Szenarien zugewiesen werden. Diese Beispiele richten sich hauptsächlich an Abrechnungsadministratoren und Mitarbeiter, die Abrechnungsaufgaben für eine Organisation verwalten.

In diesem Dokument werden die Abrechnungsrollen und -berechtigungen nicht ausführlich beschrieben. Eine ausführliche Beschreibung der Rollen und Berechtigungen für die Billing API finden Sie auf der Seite zur Zugriffssteuerung für die Billing API.

Abrechnungsberechtigungen in einem kleinen Unternehmen konfigurieren

In diesem Szenario wird in einem kleinen Start-up versucht, Google-Rechnungskonten zu konfigurieren und zu verwenden. Es gibt einige technische Mitarbeiter, die Anwendungen entwickeln und pflegen, aber keiner von ihnen ist für die Abrechnung zuständig. Das Unternehmen hat einen Büroleiter, der die Zahlungen den Rechnungen zuordnet. Aus Compliance-Gründen darf er aber keinen Zugriff auf Google Cloud-Ressourcen in den Projekten haben. Der CEO verwaltet auch die Kreditkartendaten.

In der folgenden Tabelle werden die IAM-Abrechnungsrollen erläutert, die der Administrator der Organisation (in diesem Szenario der CEO) anderen Personen in dem Unternehmen zuweisen kann, und es wird erklärt, auf welcher Ressourcenebene die Rollen gewährt werden.

Rolle:	Organisationsadministrator	Über die Rolle des Organisationsadministrators kann der CEO dem Büroleiter Berechtigungen zuweisen.
Ressource:	Organisation
Hauptkonto:	CEO

Rolle:	Rechnungskontoadministrator	Mit der Rolle des Abrechnungskonto-Administrators können der Büroleiter und der CEO Zahlungen und Rechnungen verwalten, ohne dass ihnen Berechtigungen zum Anzeigen der Projektinhalte erteilt werden.
Ressource:	Organisation
Hauptkonten:	Büroleiter, CEO

Die Zulassungsrichtlinie, die der Organisationsressource für dieses Szenario zugeordnet wird, sieht in etwa so aus:

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

Zur Verwaltung von Hauptkonten wird die Verwendung von Gruppen empfohlen. Im gezeigten Beispiel würden Sie für die zweite Bindung den CEO und den Office-Manager zu finance-admins-group hinzufügen. Wenn Sie ändern möchten, wer zur Ausführung der Funktion in der Lage ist, müssen Sie lediglich die Gruppenmitgliedschaft anpassen, ohne die Zulassungsrichtlinie zu aktualisieren. Deshalb werden die zwei Nutzerkonten nicht einzeln in den Rollenbindungen angezeigt.

Finanzteams verwalten Budgets

In diesem Szenario möchte eine große Organisation, dass das Finanzteam in jeder Abteilung Budgets festlegen und die Teamausgaben in der Abteilung ansehen kann, aber keinen Zugriff auf die Google Cloud-Ressourcen hat. Es ist in Ordnung, wenn die Entwickler die Ausgaben für ihre eigenen Projekte sehen können, ein allgemeiner Überblick über die Ausgaben soll ihnen jedoch nicht gewährt werden.

Den Finanzadministratoren der einzelnen Sparten und den Entwicklern sollen die Rollen in der folgenden Tabelle gewährt werden:

Rolle:	Rechnungskontoadministrator	Mit dieser Rolle wird den Finanzadministratoren der einzelnen Sparten die Berechtigung gewährt, Budgets festzulegen und die Ausgaben für die Rechnungskonten in den jeweiligen Sparten anzuzeigen, jedoch nicht die Berechtigung, Projektinhalte aufzurufen.
Ressource:	Rechnungskonto
Hauptkonten:	Finanzadministratoren der einzelnen Sparten

Rolle:	Rechnungskontobetrachter	Mit der Rolle des Rechnungskonto-Betrachters können die Entwickler die Ausgaben für ein Rechnungskonto aufrufen.
Ressource:	Rechnungskonto
Hauptkonten:	Entwickler des Projekts

Verwenden Sie in diesem Szenario die Abrechnungskonsole, um den Finanzadministratoren des Rechnungskontos die Rolle des Rechnungskontoadministrators zu erteilen. Erteilen Sie außerdem den Entwicklern des Rechnungskontos die Rolle "Rechnungskontobetrachter".

Wenn Sie fertig sind, sieht die Zulassungsrichtlinie für das Rechnungskonto ungefähr so aus:

{
  "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
}

Self-Service-Portal für Kunden, Entwickler können Abrechnung nicht anpassen

In diesem Szenario stellt das zentrale IT-Team eines Kunden Google Cloud-Ressourcen für seine Entwickler als Teil des Self-Service-Portals zur Verfügung. Entwickler fordern über das Portal Zugriff auf Google Cloud-Projekte und andere genehmigte Clouddienste an. Die Kostenstelle des Entwicklers bezahlt die verbrauchten Cloud-Ressourcen an das zentrale IT-Team.

Das zentrale IT-Team muss zu Folgendem in der Lage sein:

Projekte mit Rechnungskonten verknüpfen
Abrechnung für Projekte deaktivieren
Kreditkarteninformationen anzeigen

Es benötigt keine Berechtigungen zum Anzeigen der Projektinhalte.

Entwickler sollen Abrechnungen mit Projekten verknüpfen, Kreditkarteninformationen einsehen sowie die tatsächlichen Kosten der verbrauchten Google Cloud-Ressourcen sehen, aber nicht die Abrechnung deaktivieren können.

Rolle:	Rechnungskontoadministrator	Die Rolle des Abrechnungsadministrators gewährt der IT-Abteilung die Berechtigung, Projekte mit Rechnungskonten zu verknüpfen, die Abrechnung für Projekte zu deaktivieren und Kreditkarteninformationen für die Konten anzuzeigen, die sie an ihre Kunden weiterverkaufen. Sie verfügen nicht über die Berechtigung, die Inhalte der Projekte anzuzeigen.
Ressource:	Rechnungskonto
Hauptkonto:	IT-Abteilung

Rolle:	Rechnungskontonutzer	Die Rolle des Abrechnungskonto-Nutzers gibt dem Dienstkonto die Berechtigungen zum Aktivieren der Abrechnung (Verknüpfen von Projekten mit dem Abrechnungskonto der Organisation für alle Projekte in der Organisation). Dadurch kann das Dienstkonto APIs aktivieren, für die die Abrechnung aktiviert werden muss.
Ressource:	Organisation
Hauptkonto:	Dienstkonto, das für die automatische Projekterstellung verwendet wird

Rolle:	Rechnungskontobetrachter	Mit der Rolle "Rechnungskontobetrachter" können die Entwickler die Ausgaben für ein Rechnungskonto aufrufen.
Ressource:	Rechnungskonto
Hauptkonten:	Entwickler des Projekts

Für dieses Szenario benötigen Sie zwei separate Vorgänge, um die entsprechenden Zulassungsrichtlinien zuzuweisen, da die Zuordnung auf unterschiedlichen Hierarchieebenen erfolgt.

Verwenden Sie die Abrechnungskonsole, um der IT-Abteilung des Rechnungskontos die Rolle des Rechnungskontoadministrators zu gewähren. Gewähren Sie den Entwicklern für das Rechnungskonto außerdem die Rolle "Rechnungskontobetrachter".

Anschließend müssen Sie eine Zulassungsrichtlinie auf Oganisationsebene anhängen. Mit dieser Zulassungsrichtlinie wird dem Dienstkonto die Rolle „Rechnungskontonutzer“ zugewiesen. Er sieht etwa so aus:

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

Entwickler erstellen abgerechnete Projekte

Ein großer Digital Native möchte allen seinen Entwicklern die Möglichkeit geben, abgerechnete Projekte für die Konten mit monatlicher Abrechnung der Organisation zu erstellen, ohne die Rechte eines Abrechnungsadministrators zu gewähren.

Für ein Projekt muss die Abrechnung aktiviert sein, um sicherzustellen, dass Nicht-Standard-APIs aktiviert werden können. Deshalb müssen Entwickler ein Projekt bei der Erstellung einem Rechnungskonto zuweisen, um die APIs zu aktivieren.

Rolle:	Rechnungskontonutzer	Mit der Rolle "Rechnungskontonutzer" können Entwickler das Rechnungskonto an neue Projekte innerhalb der Organisation anhängen.
Ressource:	Organisation
Hauptkonten:	Entwickler

Die Zulassungsrichtlinie für dieses Szenario muss auf Organisationsebene zugeordnet werden und sieht in etwa so aus:

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

Kostenaggregation

In diesem Szenario möchte ein Unternehmen berechnen und nachverfolgen können, wie viel ein Team, eine Abteilung, ein Service oder Projekt das Unternehmen kostet. Es soll beispielsweise nachverfolgt werden, wie viel eine Testbereitstellung monatlich kostet.

Dies kann mit den folgenden Methoden nachverfolgt werden:

Ressourcen in Projekten organisieren. Die Kosten werden pro Projekt angezeigt. Der Abrechnungsexport enthält Projekt-IDs.
Projekte durch Labels mit zusätzlichen Gruppierungsinformationen kennzeichnen. Beispiel: environment=test Die Labels sind im Abrechnungsexport enthalten, damit Sie eine "Slice and Dice"-Auswertung vornehmen können. Für die Labels in einem Projekt gelten jedoch dieselben Berechtigungen wie für die anderen Metadaten im Projekt, sodass ein Projektbesitzer die Labels ändern kann. Sie können Ihre Mitarbeiter darüber aufklären, welche Informationen nicht geändert werden dürfen, und diese (über Audit-Logs) überwachen, oder ihnen keine umfassenden Berechtigungen gewähren, sodass sie Projektmetadaten nicht ändern können.

Sie können in das JSON- und CSV-Format exportieren, Google empfiehlt jedoch den direkten Export in BigQuery. Dies kann im Abschnitt zum Abrechnungsexport der Abrechnungskonsole einfach konfiguriert werden.

Wenn jede Kostenstelle eine separate Rechnung oder bei einigen Arbeitslasten in einer separaten Währung bezahlen muss, wird ein separates Rechnungskonto für jede Kostenstelle benötigt. Bei dieser Methode muss jedoch für jedes Rechnungskonto eine Affiliate-Vereinbarung abgeschlossen werden.