Delegierter Zugriff
Binden Sie einen Entwickler ein, übergeben Sie die Abrechnung an Ihren Buchhalter, gewähren Sie einem Kunden Nur-Lese-Zugriff auf dessen eigene Websites oder lassen Sie unser Support-Team ein Problem untersuchen. Jede Freigabe ist eine Rolle mit definierten Berechtigungen, begrenzt auf eine Organisation, in der Datenbank durchgesetzt und in ein Audit-Protokoll geschrieben, das nur erweitert werden kann.
Das Teilen von Anmeldedaten führt zu Problemen beim Kontozugriff. Bei Zinn Digital® hat jede Person ihre eigene Identität, und der Zugriff ist eine Mitgliedschaft — ein Benutzer, eine Organisation und eine Rolle —, die Sie separat erteilen, ändern oder widerrufen können.
Jede mitwirkende Person meldet sich über Keycloak, unsere Identitätsebene, mit den eigenen Anmeldedaten an. Niemand tippt Ihr Passwort ein, niemand teilt eine Browsersitzung, und das Entfernen einer Person ist ein einziger Vorgang anstelle einer Passwortänderung und der hektischen Suche danach, wer es sonst noch wusste.
Konten sind hierarchisch aufgebaut — eine Reseller-Organisation umfasst Kundenorganisationen, und Kundenorganisationen umfassen Websites. Eine Mitgliedschaft gilt für eine Organisation und alles, was ihr untergeordnet ist, sodass Sie einem Agenturkunden die Kontrolle über seine eigene Organisation übertragen können, ohne jemals Ihre anderen Kunden offenzulegen.
Die Mandantentrennung ist kein Filter im Anwendungscode, der durch einen Fehler umgangen werden könnte. Die Row-Level Security von Postgres beschränkt jede Abfrage auf den Organisations-Unterbaum des Aufrufers, sodass eine Anfrage außerhalb Ihres Bereichs nichts zurückzugeben hat.
Wenn Sie eine Organisation oder eine Website außerhalb Ihres Bereichs anfordern, antwortet die API mit einem einfachen „Nicht gefunden“ statt mit einem Berechtigungsfehler. Ein Berechtigungsfehler würde bestätigen, dass der Datensatz existiert; „Nicht gefunden“ verrät Außenstehenden überhaupt nichts.
Berechtigungen sind granulare Schlüssel — Modul plus Aktion, wie sites.restart oder billing.refund — und Rollen bündeln diese. Vier Rollen decken die Strukturen ab, die echte Teams benötigen, und jede davon besteht aus Daten, die wir bereitstellen, und nicht aus im Code vergrabener Logik.
Vollständige Kontrolle: Erstellen Sie Unterorganisationen, laden Sie Mitglieder ein und entfernen Sie diese, ändern Sie Rollen, verwalten Sie API-Schlüssel, erstellen, starten Sie neu, bereinigen, sperren und löschen Sie Websites, wickeln Sie Abrechnungen und Rechnungen ab, erstellen Sie Tickets und lesen Sie das Audit-Protokoll. Die Rolle, die Sie für sich selbst behalten.
Sieht die Organisation, ihre Mitglieder und den Tarifkatalog und verwaltet Rechnungen, Zahlungsmethoden sowie Gebühren. Kein Zugriff auf das Erstellen, Ändern oder Löschen einer einzelnen Website — genau das Profil, das eine externe Buchhaltung haben sollte.
Zeigt Websites an und erstellt diese, startet Dienste neu, leert den Cache, verwaltet API-Schlüssel und bearbeitet Tickets. Vorsätzlich ausgeschlossen: Abrechnung, Rechnungen, Zahlungsmethoden, Mitgliederverwaltung, Website-Sperrung und Website-Löschung. Ein Auftragnehmer kann Inhalte erstellen, ohne Ihnen Kosten in Rechnung stellen oder etwas zerstören zu können.
Sieht die Organisation, ihre Mitglieder, ihre Websites, ihre Abrechnung, den Tarifkatalog, Tickets, den Übersetzungsstatus und das Audit-Protokoll – und kann davon nichts ändern. Die passende Berechtigung für Kunden, die Einblick wünschen, Auditoren oder Stakeholder, die lediglich Leserechte benötigen.
Das Delegieren von Zugriffen ist nur dann sicher, wenn die Konten, an die Sie delegieren, schwer zu übernehmen sind. Die Authentifizierung erfolgt für jede Person im Konto und auf jeder Oberfläche über Keycloak.
Support-Arbeiten erfordern manchmal einen Einblick in Ihr Konto. Dieser Zugriff unterliegt demselben Berechtigungsmodell wie alles andere — Mitarbeiter befinden sich einfach in einer Mitarbeiterorganisation, die in Abteilungen mit eng definierten Berechtigungen unterteilt ist.
Mitarbeiter werden in Support, Abrechnung und Finanzen, Missbrauch sowie Vertrauen und Sicherheit, Vertrieb, Onboarding, Entwicklung und Betrieb, Marketing und Management eingeteilt. Jede Rolle gewährt Zugriff auf bestimmte Module und Aktionen, sodass Agenten nur den Teil der Administrationskonsole sehen, den ihre Tätigkeit erfordert, und nicht den Rest.
Die Support-Mitarbeiter-Rolle gewährt genau Folgendes: Kunden anzeigen, Tickets anzeigen und beantworten, Websites anzeigen, eine Website neu starten und ihren Cache leeren. Sie beinhaltet keine Abrechnungskonfiguration, keine Rückerstattungen, keine Tarifbearbeitung und keine Flottenverwaltung. Die Fehlerbehebung, die ein Mitarbeiter durchführen kann, wird durch die Rolle begrenzt, nicht durch gute Absichten.
Die Berechtigung customer.impersonate ist nicht Teil der Rolle Manager — sie ist nur Super Admin vorbehalten. Wenn eine Sitzung in Ihrem Namen läuft, zeigt das Dashboard ein dauerhaftes Identitätswechsel-Banner an, sodass zu keinem Zeitpunkt unklar ist, wer agiert.
Jede privilegierte und administrative Aktion wird an ein Audit-Protokoll angehängt, das nur erweitert werden kann und den Akteur, die Aktion, das Ziel, unterstützende Metadaten, die IP-Adresse sowie den Zeitstempel aufzeichnet — in der Produktionsumgebung nach Zeit partitioniert. Eigentümer und Nur-Lese-Mitglieder können das Protokoll ihrer Organisation selbst einsehen.
Sensible und destruktive Aktionen von Mitarbeitern können vor ihrer Ausführung eine erweiterte Authentifizierung oder die Genehmigung durch zwei Personen erfordern, und neue Abteilungen sowie Rollen sind eine Frage der Konfiguration statt einer Codeänderung.
Skripte, CI-Pipelines, das CLI, der Terraform-Provider und KI-Agenten authentifizieren sich alle über dasselbe Berechtigungsmodell wie Personen – keine gemeinsam genutzten menschlichen Anmeldedaten, keine langlebigen Secrets, die in einen Build eingefügt werden.
Schlüssel gehören zu einer Organisation und verfügen über granulare Bereiche, die an dieselben RBAC-Berechtigungen gebunden sind — schreibgeschützt, Abrechnung, Bereitstellung. Gewähren Sie einer Pipeline nur den eng gefassten Bereich, den sie benötigt, anstatt das gesamte Konto eines Mitglieds.
Schlüssel für den Testmodus und den Live-Modus sind unterschiedlich, sodass eine Integration in der Entwicklung nicht versehentlich oder durch eine kopierte Umgebungsvariable auf Produktionsdaten zugreifen kann.
Wir speichern einen SHA-256-Hash des Geheimnisses und ein Lookup-Präfix – niemals den Rohschlüssel. Sie sehen einen Schlüssel nur einmal bei der Erstellung. Jeder Schlüssel erfasst, wann er zuletzt verwendet wurde, und kann separat widerrufen werden, ohne etwas anderes zu beeinträchtigen.
Unser MCP-Server ermöglicht es jedem MCP-fähigen Agenten, Ihr Hosting in natürlicher Sprache zu verwalten – authentifiziert über OAuth 2.1, beschränkt auf Ihre Organisation und RBAC-Rolle, mit widerrufbaren Tokens pro Tool, Bestätigung bei destruktiven Aktionen, Ausgabenlimits und vollständiger Audit-Protokollierung.
Kontozugriff und Serverzugriff sind unterschiedliche Problemstellungen. Anmeldedaten auf Website-Ebene werden im Dashboard verwaltet, nach dem Prinzip der geringsten Rechtevergabe ausgestellt und so isoliert, dass die Shell eines Mitwirkenden ausschließlich auf eine Website beschränkt ist.
Ein Einzelunternehmer behält eine einzige Organisation und eine einzige Eigentümer-Mitgliedschaft bei und fügt eine Entwickler-Rolle 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 gemeinsamen Anmeldedaten zurück, die rotiert werden müssten.
Eine Agentur nutzt die Organisationsstruktur. Jeder Kunde erhält eine eigene Unterorganisation, die die Websites dieses Kunden enthält, und die Mitarbeiter des Kunden erhalten dort Mitgliedschaften – schreibgeschützt für Stakeholder, die Einblick wünschen, Eigentümerrechte für Kunden, die ihre Verwaltung selbst übernehmen möchten. Ihre Mitarbeiter verfügen über Mitgliedschaften weiter oben in der Struktur und sehen das gesamte Portfolio; ein Kunde sieht nur seinen eigenen Zweig, und Row-Level Security stellt sicher, dass dies eine Tatsache ist und kein bloßes Versprechen.
Ein Wiederverkäufer funktioniert auf die gleiche Weise, eine Ebene weiter oben: Eine Wiederverkäuferorganisation umfasst Kundenorganisationen, jede mit ihren eigenen Mitgliedern, ihrer eigenen Abrechnungsansicht und ihren eigenen Websites. Derselbe Grundbaustein steuert Unterkonten, Agenturteams und Wiederverkäuferhierarchien – es gibt für keines davon einen separaten, schwächeren Mechanismus.
In der 14-tägigen Testversion ohne Kreditkarte ist alles verfügbar. Registrieren Sie sich ohne Zahlungsdaten, laden Sie einen Kollegen ein, sehen Sie, worauf die einzelnen Rollen zugreifen können und worauf nicht, und lesen Sie Ihr eigenes Audit-Protokoll.
Derzeit gewährt eine Mitgliedschaft ihre Rolle für eine gesamte Organisation und alle ihr in der Hierarchie untergeordneten Elemente. Um Website-Gruppen zu trennen, müssen daher die Organisationen getrennt werden — platzieren Sie diese Websites in einer eigenen Unterorganisation und weisen Sie die Mitgliedschaft dort zu. Dies ist ein sauberes Modell für Agenturen und Reseller, bei denen ohnehin jeder Kunde eigene Abgrenzungen wünscht. Eine ressourcenbezogene Zuweisung pro Mitgliedschaft, die eine einzelne Mitgliedschaft auf bestimmte Websites innerhalb einer Organisation beschränkt, ist eine geplante Erweiterung und derzeit noch nicht verfügbar.
Die Rolle Developer beinhaltet weder das Löschen noch das Sperren von Websites – diese Befugnisse gehören zur Rolle Owner. Sie gewährt das Anzeigen und Erstellen von Websites, den Neustart von Diensten, das Leeren des Caches, die Verwaltung von API-Schlüsseln und die Bearbeitung von Tickets. Berechtigungen für Deployment und Push-to-Live sind ebenfalls nicht Teil der Developer-Berechtigung, sodass die Übertragung in die Produktionsumgebung beim Kontoinhaber verbleibt. Kombinieren Sie dies mit Staging, damit die Erstellungsarbeiten von vornherein außerhalb der Live-Site stattfinden.
Es hängt vollständig von der Rolle des Mitarbeiters ab, und jede Rolle besteht aus einem 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 keine Änderungen an Abrechnungskonfigurationen, Rückerstattungen, Tarifen oder der Flotte vornehmen. Die Anmeldung als Kunde ist eine separate Berechtigung, die ausschließlich dem Super Admin vorbehalten ist; tritt dieser Fall ein, zeigt das Dashboard ein dauerhaftes Banner zur Benutzerimitation an. Jede privilegierte Aktion wird mit Akteur, Aktion, Ziel, IP-Adresse und Zeitstempel im Audit-Protokoll aufgezeichnet, und Sie können das Protokoll Ihrer Organisation selbst einsehen.
Entfernen Sie die Mitgliedschaft, und der Zugriff auf diese Organisation endet – die Benutzer behalten weiterhin ihre eigene Identität, haben jedoch keine Rolle und somit keine Berechtigungen mehr in Ihrem Konto. API-Schlüssel werden einzeln widerrufen, sodass ein Pipeline-Schlüssel getrennt werden kann, ohne andere Komponenten zu beeinträchtigen. Wenn Sie SAML-Single-Sign-On verwenden, wird die Anmeldung durch das Deprovisioning bei Ihrem Identitätsanbieter zentral verwaltet. Anmeldedaten auf Website-Ebene wie SSH-Schlüssel werden im Dashboard widerrufen, und die Entfernung selbst wird im Audit-Protokoll erfasst.
Nein – es lohnt sich jedoch, die Gründe genau zu benennen. API-Schlüssel gehören der Organisation und nicht einem einzelnen Mitglied; zudem verfügen sie über eigene, feingranulare Berechtigungsbereiche, die an denselben Berechtigungskatalog gebunden sind. Anstatt also einer Person einen Schlüssel auszuhändigen, erstellen Sie einen Schlüssel für die jeweilige Aufgabe mit dem engstmöglichen Berechtigungsbereich und widerrufen diesen Schlüssel, sobald die Aufgabe abgeschlossen ist. Es wird ausschließlich ein Hash des Geheimnisses 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 mit OAuth 2.1 und beschränkt deren Gültigkeitsbereich auf Ihre Organisation sowie Ihre RBAC-Rolle, mit widerrufbaren Tokens pro Tool, sodass Sie eine spezifische Funktion statt eines pauschalen Zugriffs gewähren. Destruktive Aktionen erfordern eine Bestätigung, Ausgabenlimits finden Anwendung und jede Aktion wird im selben Audit-Protokoll wie menschliche Aktivitäten erfasst.
Postgres Row-Level Security beschränkt Abfragen direkt in der Datenbank auf den Teilbaum der Organisation des Aufrufers, wobei der Filter auf Anwendungsebene als zusätzliche Verteidigungsebene und nicht als einzige Linie dient. Anfragen für Datensätze außerhalb des Gültigkeitsbereichs geben „nicht gefunden“ statt eines Berechtigungsfehlers zurück, sodass nichts über die Existenz von Daten preisgegeben wird. Auf Serverseite sorgt die seitenbezogene Isolierung über CageFS dafür, dass Shell und Dateien jedes Mandanten auf seine 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.
Starten Sie mit der 14-tägigen Testversion ohne Kreditkarte, laden Sie jemanden ein und erleben Sie, wie das Berechtigungsmodell seine Aufgabe erfüllt — Rollen, die Sie benennen können, Bereiche, die Sie widerrufen können, und ein Audit-Protokoll, das genau anzeigt, wer was getan hat.
Kostenlos starten