Grundlegende Konzepte

Geheimnis als Eintrag in Passwork

Passwork hat keine dedizierte „Geheimnis"-Entität — jeder Passworteintrag kann als Geheimnis fungieren. Das bietet Ihnen Flexibilität: Dieselbe Oberfläche funktioniert sowohl für Endbenutzer-Passwörter als auch für Infrastrukturgeheimnisse.

Wo ein Geheimnis innerhalb eines Eintrags gespeichert wird

Feldtyp	Was gespeichert wird	Beispiel
Login	Benutzername-Anmeldedaten	svc_backend
Passwort	Geheimnisse, Passwörter, Schlüssel	xK9#mP2$vL7!nQ
Benutzerdefinierte Felder	Benannte Geheimnisse, Token, Schlüssel	AWS_SECRET_KEY, OAUTH_CLIENT_SECRET, REDIS_AUTH
Beschreibung	Konfigurationsausschnitte, JSON, YAML	Verbindungszeichenfolgen, JSON-Konfigurationen

Empfehlung

Verwenden Sie für die Automatisierung benutzerdefinierte Felder mit aussagekräftigen Namen (MYSQL_ROOT_PASS, STRIPE_SECRET). Dies macht den Abruf per CLI/SDK unkompliziert und hält Einträge selbstdokumentierend.

Geheimnisse klassifizieren

Um Geheimnisse effektiv zu organisieren und zu finden, verwenden Sie:

• Tags — logische Gruppierungen: production, staging, development, db, cloud, k8s.
• Titel — beschreibt den Zweck des Geheimnisses
• Ordnerhierarchie — gruppiert zusammengehörige Geheimnisse

Geheimnisse strukturieren

Eine durchdachte Ordnerstruktur ist für die Automatisierung unerlässlich. Wenn Geheimnisse einem vorhersagbaren Muster folgen, können CLI- und SDK-Tools sie ohne manuelle Einrichtung finden und sammeln.

Organisationsansatz

Erstellen Sie einen dedizierten Tresor oder Stammordner für Infrastrukturgeheimnisse. Organisieren Sie darin nach Umgebung und Kategorie:

infrastructure/
├── production/
│   ├── databases/
│   │   ├── mysql-primary
│   │   └── memcached-sessions
│   ├── cloud/
│   │   └── aws-credentials
│   └── k8s/
│       └── cluster-admin
├── staging/
│   ├── databases/
│   └── cloud/
└── development/
    └── local/

Wie dies die Automatisierung vereinfacht

Alle Produktionsgeheimnisse abrufen:

passwork-cli exec --folder-id <infrastructure/production ID>

Nur Produktions-DB-Geheimnisse abrufen:

passwork-cli exec --folder-id <infrastructure/production/databases ID>

Einträge benennen

Wählen Sie aussagekräftige Namen, die den Zweck vermitteln:

• Gut: mysql-primary, memcached-sessions, twilio-auth-token
• Vermeiden: secret1, temp-pass, asdf123

Aussagekräftige Benennung hilft Ihnen:

• Geheimnisse schnell in der Benutzeroberfläche oder über die CLI-Suche zu finden;
• den Zweck eines Eintrags auf einen Blick zu verstehen;
• Verwechslungen bei Rotation und Audits zu vermeiden.

Zugriffskontrolle

Passwork bietet granulare Berechtigungen auf Tresor- und Ordnerebene:

• Plattform-Team → Vollzugriff auf infrastructure/production und infrastructure/staging.
• Entwickler → Zugriff beschränkt auf infrastructure/development.
• CI/CD-Dienst (Dienstkonto) → Nur-Lese-Zugriff auf infrastructure/production für Bereitstellungen.

Berechtigungen werden in der Ordnerhierarchie vererbt, können aber auf jeder Ebene angepasst werden.

Wie die API-Authentifizierung funktioniert

Jede Passwork-Integration arbeitet im Namen eines bestimmten Benutzers. Für den API-Zugriff ist ein Token-Paar erforderlich:

• Access Token — autorisiert API-Anfragen; hat eine begrenzte Lebensdauer.
• Refresh Token — erhält ein neues Access Token, ohne Anmeldedaten erneut eingeben zu müssen.

Token sind an einen Benutzer gebunden, und alle API-Operationen werden mit den Berechtigungen dieses Benutzers ausgeführt. Das bedeutet:

• Die Integration sieht nur Tresore und Ordner, auf die der Benutzer Zugriff hat.
• Schreiboperationen erfordern entsprechende Benutzerrechte.
• Alle Aktionen erscheinen im Audit-Protokoll unter dem Namen dieses Benutzers.

Dienstkonten für Integrationen

Für die Automatisierung (CI/CD, Rotationsskripte, interne Dienste) empfehlen wir dedizierte Dienstkonten anstelle persönlicher Mitarbeiterkonten.

Vorteile:

• Zugriffsisolierung — Dienstkonten greifen nur auf die benötigten Ordner zu.
• Klarer Audit-Trail — Protokolle zeigen klar automatisierungsausgelöste Aktionen.
• Personalunabhängigkeit — Personalwechsel stören CI/CD nicht.
• Flexible Sicherheitseinstellungen — separate Richtlinien für Dienstkonten konfigurieren.

Empfehlung

Gruppieren Sie Dienstkonten unter einer dedizierten Rolle (z. B. Service Accounts oder CI/CD Integration). Konfigurieren Sie für diese Rolle:

• API-Token-Lebensdauer — kürzere Token für CI/CD-Jobs, längere für Dauerdienste.
• Passwortrichtlinien — Anforderungen lockern, wenn die Authentifizierung nur über Token erfolgt.

Beispiel-Layout für Dienstkonten:

Konto	Zweck	Zugriff
deploy-prod-svc	Produktionsbereitstellung	Nur-Lese auf infrastructure/production
deploy-staging-svc	Staging-Bereitstellung	Nur-Lese auf infrastructure/staging
cred-rotator	Geheimnis-Rotation	Lesen-Schreiben auf infrastructure/production, infrastructure/staging
health-checker	Integritätsprüfung	Nur-Lese auf alle Geheimnisse

Sicherheitshinweise

Das Modell „Integration = Benutzer" bietet mehrere Sicherheitsvorteile:

1. Minimale Rechte — jede Integration erhält nur den Zugriff, den sie benötigt. Bereitstellungs-CI/CD kann keine Geheimnisse rotieren, und der Rotationsbot kann keine Dev-Umgebungsdaten einsehen.

2. Transparentes Audit — jede Operation wird mit Benutzer, Zeitstempel und Aktionstyp protokolliert. Bei Vorfällen können Sie genau nachverfolgen, welche Integration wann auf ein Geheimnis zugegriffen hat.

3. Schnelle Reaktion — bei Kompromittierung einer Integration können Sie Token für dieses spezifische Dienstkonto widerrufen, ohne andere zu beeinflussen.

4. Klare Verantwortung — DevOps verwaltet Infrastruktur-Dienstkonten, während Entwicklungsteams ihre eigenen verwalten.

Wichtig

Alle Geheimnis-Operationen (Lesen, Ändern, Löschen) werden im Audit-Protokoll von Passwork aufgezeichnet, einschließlich:

• Wer die Operation durchgeführt hat (Benutzername oder Dienstkonto)
• Wann (Zeitstempel)
• Was getan wurde (Operationstyp, Eintrags-ID)