Als Gründerin, die regelmäßig mit Kund:innen, freien Mitarbeitenden und Subagenturen arbeitet, stand ich schnell vor der Herausforderung: Wie verwalte ich Passwörter und Zugangsdaten so, dass jede Mandantschaft sicher isoliert ist und gleichzeitig die Administration nicht ausufert? Bitwarden ist mir dabei über die Jahre hinweg als verlässliches, flexibles Tool begegnet. In diesem Artikel teile ich meine Praxis für Agenturen: wie ich mehrere Mandanten in Bitwarden sichere, organisatorisch isoliere und automatisierte Rotationsrichtlinien umsetze.

Warum Bitwarden für Agenturen?

Bitwarden kombiniert ein gutes Sicherheitsniveau (end-to-end Verschlüsselung), Offenheit (Open-Source-Client und API) und administrativen Komfort (Organisationen, Collections, Policies). Für Agenturen ist das wichtig, denn wir brauchen:

  • klare Trennung zwischen Mandanten (keine Datenvermischung),
  • zugriffsbasierte Freigaben statt dezenter Passwortweitergabe,
  • Möglichkeiten zur Automatisierung von Sicherheitsprozessen (z. B. Passwortrotation),
  • Auditierbarkeit und Protokollierung von Zugriffen.

    • Ich nutze sowohl das gehostete Bitwarden Business/Enterprise als auch gelegentlich Vaultwarden (Self-Hosted) für kleinere Projekte. Beide Ansätze haben Vor- und Nachteile – dazu später mehr.

    Grundprinzip: Mandanten per Organisation und Collections isolieren

    In Bitwarden bildet die Kombination aus Organisationen, Sammlungen (Collections) und Teams das Fundament für Multimandanten-Betrieb.

  • Für jeden Mandanten lege ich eine eigene Organisation an. Das schafft die stärkste Isolation: Nutzer:innen einer Organisation sehen standardmäßig keine Vault-Einträge anderer Organisationen.
  • Innerhalb einer Organisation nutze ich Collections zum Strukturieren (z. B. "IT-Accounts", "Marketing-Tools", "Kundenzugang").
  • Mit Teams/Rollen steuere ich granular, wer welche Collections sehen oder bearbeiten darf.

    • Das Modell mit separaten Organisationen hat sich bewährt, weil es rechtlich und organisatorisch klar ist: Rechnung, SLA oder Datenschutzvereinbarungen können pro Organisation gepflegt werden. Ich vermeide die Variante „eine Organisation für alle Mandanten“ – das erhöht das Risiko von Fehlkonfigurationen.

    Zugriffs- und Rollenmodell

    Ein schlankes Rollenmodell reduziert Fehler. Mein Standard-Setup sieht so aus:

  • Mandanten-Admin: Kunde oder Hauptansprechpartner – volle Sicht in der jeweiligen Organisation.
  • Agentur-Operations: Mitarbeitende der Agentur mit Edit-Rechten in relevanten Collections.
  • Agentur-Lesezugriff: Externe oder Junior-Teammitglieder, nur View.
  • Service-Accounts: Maschinenkonten (CI/CD, Monitoring) mit begrenzten Rechten, keine Nutzer-2FA möglich, daher besondere Aufmerksamkeit.

    • Für Service-Accounts nutze ich immer zusätzliche Sicherheitsschichten: begrenzte IP-Whitelist, kurzlebige API-Tokens, und – wenn möglich – Zugriff nur über Bastion/Proxy.

    Automatisierte Rotationsrichtlinien: Warum und wie

    Passwortrotation ist eines der effektivsten Mittel gegen kompromittierte Zugangsdaten. Manuell ist das für Agenturen aber schnell nicht praktikabel. Deshalb habe ich automatisierte Rotationsabläufe implementiert:

  • Regel: Kritische Konten (Admin, SSH-Keys, API-Keys) rotieren mindestens alle 30–90 Tage.
  • Regel: Service-Accounts rotieren bei jedem Deploy oder nach einem definierten Zeitraum (z. B. 7–30 Tage).
  • Regel: Zugangsdaten von Drittanbietern rotieren nach Kompromissverdacht oder wenn Mitarbeitende das Team verlassen.

    • Automatisierung greife ich über Bitwarden CLI, API und gegebenenfalls durch Integrationen mit CI-Systemen (GitHub Actions, GitLab CI) oder Automatisierungswerkzeugen (Zapier, n8n). Ein typischer Workflow:

  • Ein Script erzeugt ein neues Passwort gemäß Policy (z. B. 24 Zeichen, Sonderzeichen, keine Ambiguities).
  • Script ruft Bitwarden CLI auf, meldet sich mit einem Service-Account an und updatet das Item in der entsprechenden Organisation/Collection.
  • Optional informiert das Script per Webhook oder Ticket-System die zuständige Person, damit manuelle Schritte (z. B. Passwort in einem Drittservice ändern) durchgeführt werden.

    • Technische Umsetzung: Beispiele und Tools

    Ich nutze häufig die Bitwarden CLI (bw) kombiniert mit einem CI-Runner. Ein vereinfachter Ablauf:

  • Authentifizierung: bw login --apikey (für Service-Accounts empfehle ich API-Keys).
  • Session generieren: bw unlock --raw $MASTER_PASSWORD → Session-Token im CI-Secret speichern.
  • Item updaten: bw edit item --password "" --session $SESSION_TOKEN

    • Für komplexere Fälle nutze ich:

  • Bitwarden API (Server-to-Server-Aufrufe) für detaillierte Operationen und Audit-Logs.
  • n8n oder GitHub Actions, um Rotation als Job zu planen oder bei bestimmten Events (z. B. nach Offboarding) auszulösen.
  • HashiCorp Vault für kurzlebige Zugangsdaten (z. B. Datenbank-Zugänge), die dann in Bitwarden referenziert werden. So hält man sensitive Secrets kurzlebig und versioniert in Vault, während Bitwarden als Inventar dient.

    • Audit, Logging und Alarmierung

    Transparenz ist essenziell. Bitwarden bietet Audit-Logs (Enterprise), die ich in mein SIEM (z. B. Splunk, ELK) einspeise. Wichtige Events, die ich überwache:

  • Neue Device-Registrierungen oder ungewöhnliche Login-Orte.
  • API-Key-Generierung und Service-Account-Nutzung.
  • Item-Änderungen an kritischen Einträgen.

    • Bei Auffälligkeiten automatisiere ich Alerts (Slack, E-Mail) und trigger sofortige Rotation für betroffene Zugangsdaten.

    Security-Hygiene und Prozesse

    Technik alleine reicht nicht. Meine Agentur hat folgende Prozesse eingeführt:

  • Onboarding/Offboarding-Checklist: Zugang in Bitwarden wird bei Onboarding zugewiesen und bei Offboarding sofort entfernt; alle freigegebenen Passwörter der Person werden rotieren.
  • Vier-Augen-Prinzip für Admin-Änderungen: kritische Änderungen benötigen Freigabe eines zweiten Admins (z. B. Ticket-Approval).
  • Regelmäßige Zugriffsreviews: Quartalsweise prüfen wir, wer Zugriff auf welche Collections hat.
  • Schulung: Mitarbeitende müssen 2FA nutzen und werden in Umgang mit Secrets geschult.

    • Self-Hosted vs. Bitwarden Cloud — meine Erfahrungen

    Self-Hosted (z. B. Vaultwarden)Bitwarden Cloud
    Mehr Kontrolle über Daten; günstigere KostenManaged Service, SLA, automatisches Security-Patching
    Eigenes Backup/Recovery und Security-Operations nötigIntegrierte Enterprise-Features, Audit-Logs, SSO-Unterstützung
    Flexiblere AnpassungenSchnellere Updates, weniger Operational Overhead

    Für Großkunden und kritische Mandate bevorzuge ich das Cloud-Enterprise-Angebot wegen Audit- und Compliance-Funktionen. Für kleine Projekte oder Testumgebungen reicht oft Vaultwarden.

    Tipps aus der Praxis

  • Vermeide gemeinsame Konten: Nutze so oft wie möglich individuelle Accounts mit Rollen und RBAC anstatt ein gemeinsames Admin-Passwort weiterzugeben.
  • Nutze eindeutige Collection-Namen und eine klare Naming-Convention (z. B. mandant-service-umgebung).
  • Dokumentiere Automatisierungen ausführlich in einem internen Runbook — sonst kann niemand nachvollziehen, warum gerade ein Passwort rotiert wurde.
  • Setze konsequent 2FA ein — für alle Agentur-Admins zwingend.
  • Teste regelmäßig deine Rotations-Workflows in einer Sandbox, bevor sie in Produktion laufen.

    • Wenn du willst, kann ich dir ein Beispiel-Repository mit Scripts für bw-cli und GitHub Actions vorbereiten oder eine Checkliste für On-/Offboarding schicken. Sag mir einfach, welche Größenordnung (Anzahl Mandanten, Anzahl Mitarbeitende) du hast — dann passe ich die Empfehlungen konkret an.