Delegierter Zugriff
Bringen Sie einen Entwickler an Bord, übergeben Sie die Abrechnung an Ihren Buchhalter, gewähren Sie einem Kunden einen schreibgeschützten Einblick in seine eigenen Websites oder lassen Sie unser Support-Team einen Blick auf ein Problem werfen. Jede Freigabe ist eine Rolle mit definierten Berechtigungen, beschränkt auf eine Organisation, durchgesetzt in der Datenbank und protokolliert in einem unveränderlichen Audit-Log.
Die gemeinsame Nutzung von Zugangsdaten ist der Hauptgrund für Sicherheitsprobleme beim Kontozugriff. Bei Zinn Digital® hat jede Person ihre eigene Identität, und der Zugriff ist eine Mitgliedschaft – bestehend aus einem Benutzer, einer Organisation und einer Rolle –, die Sie unabhängig voneinander vergeben, ändern oder entziehen können.
Jeder Mitarbeiter meldet sich über Keycloak, unsere Identitätsebene, persönlich an. Niemand tippt Ihr Passwort ein, niemand teilt eine Browsersitzung, und das Entfernen einer Person erfordert nur eine einzige Aktion anstelle eines Passwortwechsels und hektischem Rätselraten darüber, wer es sonst noch wusste.
Konten sind hierarchisch aufgebaut – eine Reseller-Organisation umfasst Kundenorganisationen, und Kundenorganisationen umfassen Sites. Eine Mitgliedschaft gilt für eine Organisation und alles, was darunter liegt, sodass Sie einem Agenturkunden die Kontrolle über seine eigene Organisation übergeben können, ohne jemals Ihre anderen Kunden offenzulegen.
Mandantentrennung ist kein Filter im Anwendungscode, den ein Bug umgehen könnte. Postgres Row-Level Security beschränkt jede Abfrage auf den Organisationssubbaum des Aufrufers, sodass eine Anfrage außerhalb Ihres Geltungsbereichs nichts zurückgeben kann.
Wird eine Organisation oder Website außerhalb Ihres Zuständigkeitsbereichs angefragt, antwortet die API mit einer einfachen „Nicht gefunden“-Meldung anstelle eines Berechtigungsfehlers. Ein Berechtigungsfehler würde bestätigen, dass der Datensatz existiert; „Nicht gefunden“ verrät Außenstehenden absolut gar nichts.
Berechtigungen sind granulare Schlüssel – Modul plus Aktion wie sites.restart oder billing.refund –, und Rollen fassen sie zusammen. Vier Rollen decken die Formen ab, die echte Teams benötigen, und jede davon sind initialisierte Daten, keine im Code vergrabene Logik.
Volle Kontrolle: Erstellen Sie Unterorganisationen, laden Sie Mitglieder ein und entfernen Sie sie, ändern Sie Rollen, verwalten Sie API-Schlüssel, erstellen, starten, bereinigen, sperren und löschen Sie Websites, wickeln Sie Abrechnung und Rechnungen ab, erstellen Sie Tickets und lesen Sie das Audit-Log. Die Rolle, die Sie für sich behalten.
Sie sieht die Organisation, deren Mitglieder und den Plankatalog und verwaltet Rechnungen, Zahlungsmethoden und Lastschriften. Kein Zugriff auf das Erstellen, Ändern oder Löschen einzelner Websites – genau das Profil, das ein externer Buchhalter haben sollte.
Zeigt Websites an und erstellt sie, startet Dienste neu, leert den Cache, verwaltet API-Schlüssel und bearbeitet Tickets. Bewusst ausgeschlossen: Abrechnung, Rechnungen, Zahlungsmethoden, Mitgliederverwaltung, Website-Sperrung und Website-Löschung. Ein Auftragnehmer kann entwickeln, ohne Ihnen Rechnungen stellen oder etwas zerstören zu können.
Sie sieht die Organisation, deren Mitglieder, Sites, Abrechnung, den Plantkatalog, Tickets, den Übersetzungsstatus und das Audit-Log — und kann davon absolut nichts ändern. Die richtige Berechtigung für einen Kunden, der Einblick wünscht, einen Auditor oder einen Stakeholder, der nur nachschauen muss.
Die Delegation von Zugriffen ist nur dann sicher, wenn die Konten, an die Sie delegieren, schwer zu übernehmen sind. Die Authentifizierung läuft für jede Person auf dem Konto und auf jeder Oberfläche über Keycloak.
Support-Arbeit bedeutet manchmal, einen Blick in Ihr Account zu werfen. Dieser Zugriff unterliegt demselben Berechtigungsmodell wie alles andere auch – Mitarbeitende befinden sich einfach in einer Mitarbeiterorganisation, die in Abteilungen mit streng begrenzten Zugriffsrechten unterteilt ist.
Mitarbeiter werden in Support, Abrechnung und Finanzen, Missbrauch sowie Vertrauen und Sicherheit, Vertrieb, Onboarding, Technik und Betrieb, Marketing und Management eingeteilt. Jede Rolle gewährt bestimmte Module und Aktionen, sodass ein Agent den Teil der Admin-Konsole sieht, den seine Arbeit erfordert, und nicht den Rest.
Die Support-Agent-Rolle gewährt genau das: Kunden anzeigen, Tickets einsehen und beantworten, Websites anzeigen, eine Website neu starten und deren Cache leeren. Sie beinhaltet keine Abrechnungskonfiguration, keine Rückerstattungen, keine Tarifbearbeitung und keine Flottenverwaltung. Die Korrekturmaßnahmen, die ein Agent durchführen kann, sind durch die Rolle begrenzt, nicht durch gute Absichten.
Die Berechtigung customer.impersonate ist nicht Teil der Rolle „Manager“ – sie ist ausschließlich dem Super-Admin vorbehalten. Wenn eine Sitzung in Ihrem Namen ausgeführt wird, zeigt das Dashboard ein dauerhaftes Banner für die Identitätsübernahme an, sodass zu keinem Zeitpunkt unklar ist, wer agiert.
Jede privilegierte und administrative Aktion wird an ein fortschreibungsfreies Audit-Protokoll angehängt, das den Akteur, die Aktion, das Ziel, unterstützende Metadaten, die IP-Adresse und den Zeitstempel aufzeichnet – in der Produktion nach Zeit partitioniert. Inhaber und Mitglieder mit Nur-Lese-Zugriff können das Protokoll ihrer Organisation selbst einsehen.
Sensible und destruktive Mitarbeiteraktionen können vor ihrer Ausführung eine erweiterte Authentifizierung oder die Zustimmung von zwei Personen erfordern, und neue Abteilungen und Rollen sind eine Konfiguration statt einer Codeänderung.
Skripte, CI-Pipelines, die CLI, der Terraform-Provider und KI-Agenten authentifizieren sich über dasselbe Berechtigungsmodell wie Menschen – keine geteilten menschlichen Anmeldedaten, keine langlebigen Geheimnisse, die in einen Build eingefügt werden.
Schlüssel gehören zu einer Organisation und besitzen granulare Berechtigungen, die an dieselben RBAC-Berechtigungen geknüpft sind – nur lesen, Abrechnung, Bereitstellung. Weisen Sie einer Pipeline den eingeschränkten Umfang zu, den sie benötigt, anstatt das gesamte Konto eines Mitglieds zu verwenden.
Test- und Live-Modus-Schlüssel sind getrennt, sodass eine Integration in der Entwicklung weder aus Versehen noch durch eine kopierte Umgebungsvariable auf Produktdaten zugreifen kann.
Wir speichern einen SHA-256-Hash des Geheimnisses und ein Nachschlagepräfix – niemals den rohen Schlüssel. Sie sehen einen Schlüssel nur einmal beim Erstellen. Jeder Schlüssel protokolliert, wann er zuletzt verwendet wurde, und kann einzeln widerrufen werden, ohne andere Dinge zu beeinträchtigen.
Unser MCP-Server ermöglicht es jedem MCP-fähigen Agenten, Ihr Hosting in natürlicher Sprache zu verwalten – authentifiziert mit OAuth 2.1 und beschränkt auf Ihre Organisation und Ihre RBAC-Rolle, mit pro Tool widerrufbaren Token, Bestätigungen bei destruktiven Aktionen, Ausgabenlimits und vollständiger Audit-Protokollierung.
Kontozugriff und Serverzugriff sind unterschiedliche Probleme. Anmeldedaten auf Website-Ebene werden im Dashboard verwaltet, nach dem Prinzip der geringsten Privilegien vergeben und isoliert, sodass die Shell eines Mitarbeiters immer nur die Shell einer Website ist.
Ein einzelner Betreiber verwaltet eine einzige Organisation sowie eine Inhabermitgliedschaft und fügt eine Entwicklerrolle hinzu, wenn ein Auftragnehmer für ein Projekt hinzukommt. Wenn das Projekt endet, wird die Mitgliedschaft entfernt und dessen Anmeldung funktioniert sofort nicht mehr – es bleiben keine geteilten Zugangsdaten zurück, die rotieren müssten.
Eine Agentur nutzt den Organisationsbaum. Jede Kundschaft erhält eine eigene untergeordnete Organisation, die die Websites dieses Kunden beherbergt, und die Personen des Kunden erhalten dort Mitgliedschaften – schreibgeschützt für Stakeholder, die Einblick wünschen, oder als Inhaber für Kunden, die sich selbst verwalten möchten. Ihre Mitarbeitenden besitzen Mitgliedschaften weiter oben im Baum und sehen das Portfolio; ein Kunde sieht nur seinen eigenen Zweig, und die zeilenbasierte Sicherheit (Row-Level Security) sorgt dafür, dass dies eine Tatsache und kein leeres Versprechen ist.
Ein Reseller funktioniert auf dieselbe Weise, nur eine Ebene höher: Eine Reseller-Organisation enthält Kundenorganisationen, von denen jede über eigene Mitglieder, eigene Abrechnungsansichten und eigene Websites verfügt. Dasselbe Grundprinzip treibt Unterkonten, Agenturteams und Reseller-Hierarchien an – für keinen dieser Bereiche gibt es einen separaten, eingeschränkteren Mechanismus.
Alles ist in der völlig kostenlosen 14-tägigen Testversion verfügbar. Registrieren Sie sich ganz ohne Zahlungsdaten, laden Sie einen Kollegen ein, sehen Sie sich an, worauf die einzelnen Rollen zugreifen können und was nicht, und lesen Sie Ihr eigenes Audit-Log zurück.
Heute gewährt eine Mitgliedschaft ihre Rolle in einer gesamten Organisation und allem, was darunter in der Hierarchie liegt. Um Websiten-Sets zu trennen, müssen daher Organisationen getrennt werden – diese Websites werden in eine eigene untergeordnete Organisation verschoben und die Mitgliedschaft dort zugewiesen. Dies ist ein sauberes Modell für Agenturen und Reseller, bei denen jeder Kunde ohnehin seine eigene Grenze wünscht. Eine auf einzelne Mitgliedschaften bezogene Ressourcen-Eingrenzung (das Zuweisen einer einzelnen Mitgliedschaft an benannte Websites innerhalb einer Organisation) ist eine geplante Weiterentwicklung und derzeit noch nicht verfügbar.
Die Entwickler-Rolle beinhaltet weder das Löschen noch das Suspendieren von Websites – diese Befugnisse sind der Eigentümer-Rolle vorbehalten. Sie gewährt das Anzeigen und Erstellen von Websites, den Neustart von Diensten, das Bereinigen des Caches, die Verwaltung von API-Schlüsseln und die Bearbeitung von Tickets. Auch Berechtigungen für Bereitstellungen und das Live-Schalten gehören nicht zum Entwickler-Umfang, sodass die Beförderung in die Produktion beim Kontoinhaber verbleibt. Kombinieren Sie dies mit Staging, damit Entwicklungsarbeiten von vornherein abseits der Live-Website stattfinden.
Das hängt ganz von der jeweiligen Mitarbeiterrolle ab, und jede Rolle umfasst einen eng gefassten Satz von Berechtigungsschlüsseln. Ein Support-Mitarbeiter kann beispielsweise Ihr Konto und Ihre Websites einsehen, Ihre Tickets anzeigen und beantworten, eine Website neu starten und deren Cache leeren – er kann jedoch weder Abrechnungskonfigurationen, Rückerstattungen, Tarife noch die Flotte bearbeiten. Die Anmeldung als Kunde ist eine separate Berechtigung, die ausschließlich dem Super Admin vorbehalten ist, und in diesem Fall zeigt das Dashboard ein dauerhaftes Identitätswechsel-Banner an. Jede privilegierte Aktion wird im Audit-Log mit Akteur, Aktion, Ziel, IP-Adresse und Zeitstempel aufgezeichnet, und Sie können das Log Ihrer Organisation selbst einsehen.
Entfernen Sie die Mitgliedschaft, wodurch deren Zugriff auf diese Organisation endet – sie behalten zwar ihre eigene Identität, haben aber keine Rolle und folglich keine Berechtigungen in Ihrem Konto. API-Schlüssel werden einzeln widerrufen, sodass ein Pipeline-Schlüssel getrennt werden kann, ohne andere Dinge zu beeinträchtigen. Wenn Sie SAML Single Sign-On verwenden, erfolgt die Deprovisionierung zentral über Ihren Identitätsanbieter. Anmeldeinformationen auf Site-Ebene wie SSH-Schlüssel werden im Dashboard widerrufen, und der EntfernungsVorgang selbst wird im Audit-Protokoll erfasst.
Nein — aber es lohnt sich, hierbei präzise zu sein. API-Schlüssel gehören zur Organisation, nicht zu einzelnen Mitgliedern, und sie besitzen eigene granulare Berechtigungen, die an denselben Berechtigungskatalog gekoppelt sind. Anstatt also einer Person einen Schlüssel zu geben, erstellen Sie einen Schlüssel für die jeweilige Aufgabe mit dem engsten Berechtigungsumfang, den diese Aufgabe erfordert, und widerrufen den Schlüssel, wenn die Aufgabe erledigt ist. Es wird stets nur ein Hash des Secrets gespeichert, und jeder Schlüssel protokolliert, wann er zuletzt verwendet wurde, sodass ungenutzte Schlüssel leicht zu finden und zu deaktivieren sind.
Ja. Unser MCP-Server authentifiziert Agenten über OAuth 2.1 und schränkt sie auf Ihre Organisation sowie Ihre RBAC-Rolle ein, wobei pro Tool widerrufbare Tokens verwendet werden, sodass Sie eine spezifische Berechtigung statt eines pauschalen Zugriffs gewähren. Destruktive Aktionen erfordern eine Bestätigung, Ausgabenlimits greifen, und jede Aktion landet im selben Audit-Log wie menschliche Aktivitäten.
Postgres Row-Level Security beschränkt Abfragen auf den Organisationsunterbaum des Aufrufers direkt in der Datenbank, wobei der anwendungsspezifische Filter als verteidigte Tiefe statt als einziges Bollwerk dient. Anfragen nach Datensätzen außerhalb des gültigen Bereichs liefern ein „Nicht gefunden“ statt eines Berechtigungsfehlers zurück, sodass nichts über die Existenz preisgegeben wird. Serverseitig sorgt die Isolierung pro Website durch CageFS dafür, dass Shell und Dateien jedes Mandanten auf ihre eigene Site beschränkt bleiben.
Ja. Die 14-tägige Testphase ist kartenlos – keine Zahlungsdaten, keine Verpflichtung – und umfasst Footprint-Free Hosting mit bis zu fünf Websites. Sie reicht aus, um einen Kollegen einzuladen, eine Rolle zuzuweisen und zu bestätigen, dass sich die Grenzen so verhalten, wie Sie es benötigen, bevor Sie sich festlegen.
Starte die kostenlose 14-Tage-Testversion ohne Kreditkarte, lade jemanden ein und sieh zu, wie das Berechtigungsmodell seine Arbeit tut – Rollen, die du benennen kannst, Bereiche, die du widerrufen kannst, und ein Audit-Log, das genau zeigt, wer was getan hat.
Kostenlos starten