---
type: tutorial
title: Dein erstes geteiltes Team erstellen
summary: Stell ein geteiltes Team auf und lade drei Teammitglieder ein, jedes mit genau den Berechtigungen, die seine Rolle braucht, indem du BananaSeed beim Aufbau eines Teams folgst.
---

Am Ende dieses Tutorials hast du ein geteiltes Team erstellt und drei Personen hineingeladen, jede mit einem bewusst anderen Satz Berechtigungen: einen Operations-Lead, der das Team führt, einen Entwickler, der ein Produkt konfiguriert, und eine Managerin, die nur die Zahlen liest. Wir folgen **BananaSeed**, einem Unternehmen, dessen Gründerin ein Team aufbaut.

Du brauchst einen bezahlten Tarif, der geteilte Teams enthält (Troop oder Apex). Auf Solo oder Alpha hast du nur dein **persönliches** Team, das dir allein gehört. Sieh dir [Abrechnung](/docs/account-management/billing) für Tarife an, [was ein Team ist](/docs/troops/overview) für das Konzept und [Berechtigungen und Geltungsbereich](/docs/troops/permissions) für das Modell, auf das die Rollen unten zurückgreifen.

## Das Setup

BananaSeeds Gründerin Ana ist ihrem persönlichen Team entwachsen. Sie hat zwei Produkte, jedes mit eigenem Site-Key, und drei Personen mitzubringen:

| Person | Rolle | Soll können |
|---|---|---|
| **Dana** | DevOps | Das Team führen: Mitglieder und Access Tokens verwalten. |
| **Raj** | Entwickler | Den Site-Key eines Produkts anpassen, sonst nichts. |
| **Mia** | Managerin | Die Zahlen über das Team hinweg ansehen. Nichts ändern. |

Jede bildet eine der vier [Berechtigungen](/docs/troops/permissions) ab: Dana braucht **Verwalten**, Raj braucht **Bearbeiten** auf einem Key, Mia braucht **Lesen**.

## 1. Das Team und seine Keys erstellen

Erstell aus der Team-Liste des Dashboards ein Team namens `BananaSeed`. Es startet mit nur dir, der Inhaberin, die jede Berechtigung hält. Erstell die zwei Site-Keys darin, `shop.bananaseed.com` und `blog.bananaseed.com`, damit es etwas gibt, worauf du Personen einschränken kannst. (Sieh dir [Site-Keys](/docs/site-keys/overview) an.)

## 2. Dana einladen, die DevOps-Lead (Verwalten)

Lade Dana auf der **Mitglieder**-Seite des Teams per E-Mail ein. Die Einladung ist die E-Mail-Adresse selbst; meldet sich Dana mit dieser Adresse an, ist ihre Mitgliedschaft live.

Gewähr ihr nur **Verwalten**. Diese eine Berechtigung ist die Team-Administration: sie kann Mitglieder und [Access Tokens](/docs/troops/tokens) hinzufügen, entfernen und ändern und das Team umbenennen oder löschen. Weil Verwalten teamweit ist, spielt ihr Geltungsbereich keine Rolle, also lass ihn auf allen Site-Keys. Sie braucht weder Lesen, Erstellen noch Bearbeiten für ihre Arbeit; Verwalten ist die Berechtigung, die das Team führt.

Jetzt kann Dana den Rest des Onboardings Ana abnehmen: sie kann einen CI-Token ausgeben, die nächste Einstellung hinzufügen und Berechtigungen anpassen, alles, ohne durch einen Geltungsbereich ausgesperrt werden zu können.

## 3. Raj einladen, den Entwickler auf einem Produkt (Bearbeiten, eingeschränkt)

Lade Raj auf dieselbe Weise ein. Er besitzt den Shop, nicht den Blog, also:

- Gewähr **Bearbeiten** (und **Lesen**, damit er sieht, was er bearbeitet). Bearbeiten lässt ihn den Key konfigurieren: seine Einstellungen, Secret-Rotation, gehostete Verifizierung und die [Spiel- und White-Label-Anpassung](/docs/game-customization/overview) des Keys.
- Setz seinen **Geltungsbereich** auf **bestimmte Site-Keys** und wähl nur `shop.bananaseed.com`.

Lass **Verwalten** aus. Raj soll sein Produkt konfigurieren, nicht das Team führen. Mit Bearbeiten auf einen Key eingeschränkt bekommt er genau das: er kann die Aufgabe und den Skin des Shops justieren, und er kann den Blog, die Mitgliederliste oder die Tokens nicht anfassen.

Das ist die alltägliche Least-Privilege-Gewährung: eine Berechtigung (Bearbeiten), begrenzt durch einen Geltungsbereich (ein Key).

## 4. Mia einladen, die Managerin, die nur liest (Lesen)

Lade Mia ein und gewähr nur **Lesen**, auf allen Site-Keys. Lesen lässt sie jeden Key im Team öffnen und seine [Statistik](/docs/troops/statistics), Konfiguration und Audit-Logs ansehen und nichts davon ändern. Sie bekommt das teamweite Bild, das sie fürs Reporting braucht, ohne die Fähigkeit, versehentlich eine Einstellung zu bearbeiten oder ein Secret zu rotieren.

## 5. Jede Gewährung bestätigen

Lass jede Person sich anmelden und prüfen, dass das Team sich wie beabsichtigt verhält:

- **Dana** sieht die Mitglieder- und Token-Steuerungen und kann sie ändern, aber die eigene Konfiguration eines Site-Keys zu bearbeiten ist nicht ihre Gewährung.
- **Raj** kann `shop.bananaseed.com` öffnen und konfigurieren, sieht `blog.bananaseed.com` nicht und hat keine Mitglieder-Steuerungen.
- **Mia** kann jeden Key öffnen und seine Statistik lesen, aber jede Bearbeiten-Steuerung fehlt.

Das ist der ganze Sinn des Modells: drei Personen, drei Jobs, drei verschiedene Reichweiten, keine davon hält mehr, als sie braucht. Auf Apex wird alles, was jede von ihnen tut, unter ihrer eigenen Identität im [Team-Audit-Log](/docs/audit-logs/troop-log) aufgezeichnet.

## Wohin als Nächstes

- Füg eine CI- oder Service-Anmeldedatei statt einer Person mit einem [Troop Access Token](/docs/troops/tokens) hinzu, das dieselben Berechtigungen und denselben Geltungsbereich trägt.
- Setz [Overrides](/docs/troops/overrides) einmal auf dem Team, sodass beide Keys die Marke erben.
- Beobachte die Nutzung über beide Produkte auf der [Statistik](/docs/troops/statistics) des Teams.

## Siehe auch

- [Berechtigungen und Geltungsbereich](/docs/troops/permissions): die vier Berechtigungen in voller Länge.
- [Sitze](/docs/troops/seats): wie jedes Mitglied und jeder Token den Sitzpool deines Tarifs verbraucht.
- [Was ein Team ist](/docs/troops/overview): das Konzept und was ein Team besitzt.