Kernkonzepte

Geheimnis als Datensatz in Passwork

Passwork verfügt über keine dedizierte „geheime“ Entität – jeder Passwortdatensatz kann als Geheimnis fungieren. Dies gibt Ihnen Flexibilität: Die gleiche Schnittstelle funktioniert sowohl für Endbenutzerkennwörter als auch für Infrastrukturgeheimnisse.

Wo ein Geheimnis in einem Datensatz gespeichert werden soll

Feldtyp	Was ist aufzubewahren	Beispiel
Anmelden	Anmeldeinformationen für den Benutzernamen	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

:::Tipp Empfehlung Verwenden Sie zur Automatisierung benutzerdefinierte Felder mit beschreibenden Namen (MYSQL_ROOT_PASS, STRIPE_SECRET). Dadurch wird der CLI/SDK-Abruf unkompliziert und die Aufzeichnungen bleiben selbstdokumentierend. :::

Geheimnisse klassifizieren

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

• Tags – logische Gruppierungen: production, staging, development, db, cloud, k8s.
• Titel – beschreibt den Zweck des Geheimnisses
• Ordnerhierarchie – gruppiert verwandte Geheimnisse

Strukturierungsgeheimnisse

Eine gut gestaltete Ordnerstruktur ist für die Automatisierung unerlässlich. Wenn Geheimnisse einem vorhersehbaren 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. Innen nach Umgebung und Kategorie ordnen:

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>

Benennen von Datensätzen

Wählen Sie klare Namen, die einen Zweck vermitteln:

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

Eine beschreibende Benennung hilft Ihnen:

• Finden Sie Geheimnisse schnell in der Benutzeroberfläche oder über die CLI-Suche;
• den Zweck eines Datensatzes auf einen Blick verstehen;
• Vermeiden Sie Verwirrung bei Rotationen und Audits.

Zugangskontrolle

Passwork bietet detaillierte Berechtigungen sowohl auf Tresor- als auch auf Ordnerebene:

• Plattformteam → Vollzugriff auf infrastructure/production und infrastructure/staging.
• Entwickler → Zugriff beschränkt auf infrastructure/development.
• CI/CD-Dienst (Dienstkonto) → schreibgeschützter Zugriff auf infrastructure/production für Bereitstellungen.

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

So funktioniert die API-Authentifizierung

Passwork API Aufrufe werden als registriertes Konto ausgeführt: entweder als Person (interaktiver Benutzer) oder als Dienstkonto – ein dedizierter Kontotyp für Skripte, CI/CD und andere Automatisierung. In beiden Fällen verwenden Sie ein Token-Paar:

• Zugriffstoken – autorisiert API-Anfragen; begrenzte Lebensdauer.
• Aktualisierungstoken – erhält ein neues Zugriffstoken, ohne ein völlig neues Paar auszugeben (wobei eine erneute Eingabe der Anmeldeinformationen gilt).

Die Erneuerung des Token-Paares über HTTP (vollständige Rotation oder nur Zugriff/nur Aktualisierung) wird in API Token-Rotation behandelt. Für das gewählte Konto werden Token ausgegeben; Jeder API-Aufruf wird mit den Berechtigungen dieses Kontos ausgeführt und im Überwachungsprotokoll unter dieser Identität aufgezeichnet. Das heisst:

• Die Integration sieht nur Tresore und Ordner, auf die das Konto zugreifen kann.
• Schreibvorgänge sind nur zulässig, wenn dieses Konto über Rechte verfügt.
• Das Audit-Protokoll zeigt, welches Konto die Aktion ausgeführt hat (einschließlich Dienstkonten).

Dienstkonten für Integrationen

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

Vorteile:

• Zugriffsisolation – Dienstkonten greifen nur auf die Ordner zu, die sie benötigen.
• Klarer Audit-Trail – Protokolle zeigen deutlich die durch die Automatisierung ausgelösten Aktionen.
• Personelle Unabhängigkeit – Personalwechsel beeinträchtigen CI/CD nicht.
• Flexible Sicherheitseinstellungen – Konfigurieren Sie separate Richtlinien für Dienstkonten.

:::Tipp 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 Tokens für CI/CD-Jobs, längere für Always-on-Dienste.
• Passwortrichtlinien – lockern Sie die Anforderungen, wenn die Authentifizierung nur auf Token erfolgt. :::

Beispiellayout für ein Dienstkonto:

Konto	Zweck	Zugriff
deploy-prod-svc	Produktionsbereitstellung	schreibgeschützt für infrastructure/production
deploy-staging-svc	Staging-Bereitstellung	schreibgeschützt für infrastructure/staging
cred-rotator	Geheime Rotation	Lese-/Schreibzugriff auf infrastructure/production, infrastructure/staging
health-checker	Integritätsprüfung	schreibgeschützt für alle Geheimnisse

Sicherheitsüberlegungen

Das Modell „Integration = Benutzer“ bietet mehrere Sicherheitsvorteile:

1. Geringeste Berechtigung – jede Integration erhält nur den Zugriff, den sie benötigt. Bereitstellungs-CI/CD können keine Geheimnisse rotieren und der Rotations-Bot kann keine Entwicklungsumgebungsdaten anzeigen.

2. Transparente Prüfung – jeder Vorgang wird mit Benutzer, Zeitstempel und Aktionstyp protokolliert. Bei Vorfällen können Sie genau nachvollziehen, welche Integration wann auf ein Geheimnis zugegriffen hat.

3. Schnelle Reaktion – Wenn eine Integration gefährdet ist, widerrufen Sie Token für dieses bestimmte Dienstkonto, ohne dass dies Auswirkungen auf andere hat.

4. Klare Verantwortung – DevOps verwaltet Infrastrukturdienstkonten, während Entwicklungsteams sich um ihre eigenen kümmern.

:::warnung Wichtig Alle geheimen Vorgänge (Lesen, Ändern, Löschen) werden im Prüfprotokoll von Passwork aufgezeichnet, einschließlich:

• Wer hat den Vorgang ausgeführt (Benutzername oder Dienstkonto)
• Wann (Zeitstempel)
• Was wurde getan (Vorgangstyp, Datensatz-ID) :::