Kontosicherheit
Serversicherheit schützt die Websites. Kontosicherheit schützt die Schlüssel dazu. Jede Zinn Digital®-Anmeldung basiert auf einem einzigen standardbasierten Identitätssystem — Passkeys und WebAuthn, TOTP-Zwei-Faktor-Authentifizierung, Magic-Link-Anmeldung, SAML-SSO für Unternehmens- und Agentur-Teams — unterstützt durch granulare Rollen, organisationsbezogene API-Schlüssel und ein Append-only-Audit-Protokoll.
Die meisten Hosting-Konten bestehen aus einem Passwort in einer Datenbank, das an ein Control Panel gekoppelt ist. Unseres ist ein dediziertes Identitätssystem — Keycloak, das OIDC und SAML spricht —, das vor allem steht: dem Kunden-Dashboard, der Mitarbeiter-Administrationskonsole, dieser öffentlichen Website und Wissensdatenbank sowie Ihren Support-Tickets. Melden Sie sich einmal an, und Sie sind bei allen angemeldet.
Da sie auf offenen Standards statt auf einem proprietären Login basiert, lässt sich die Identitätsebene genauso austauschen wie jede andere Komponente der Plattform. Kein Teil Ihres Zugriffsmodells ist an das Produkt eines bestimmten Anbieters gebunden, und keine Authentifizierung Ihres Teams hängt davon ab, dass wir an einem einzigen Lieferanten festhalten. Dies ist dasselbe Prinzip der Unabhängigkeit, das wir auch auf CDN-Konten, DNS- und Zahlungsanbieter anwenden.
Die Anmeldung ist lokalisiert, und bei der Weiterleitung von der Website zum Anmeldebildschirm wird Ihre Sprache übernommen — so wird ein über mehrere Länder verteiltes Team nicht zu einer rein englischsprachigen Anmeldung gezwungen.
Vier Methoden, alle erstklassig, alle individuell pro Person konfigurierbar. Niemand wird zur schwächsten Option gezwungen, nur weil sie die einzige verfügbare ist.
Geben Sie Ihre E-Mail-Adresse ein, klicken Sie auf den Link und Sie sind angemeldet. Kein Passwort, das per Phishing erbeutet, wiederverwendet oder bei einer Datenpanne geleakt werden kann. Dies ist der Standardweg für neue Konten, und für die meisten Menschen ist es der einzige, den sie jemals brauchen werden.
Registrieren Sie einen Passkey — Touch ID, Face ID, Windows Hello oder einen Hardware-Sicherheitsschlüssel wie einen YubiKey — und melden Sie sich ganz ohne Passwort an. Passkeys sind an den Ursprung gebunden, sodass eine gefälschte Anmeldeseite sie nicht abfangen kann. Die Plattform akzeptiert ES256- und RS256-Authentifikatoren und bevorzugt die Benutzerüberprüfung.
Melden Sie sich über eine standardmäßige Identitätsanbieter-Verbindung mit Google an, sodass ein Konto alle Kontrollen übernimmt, die Ihr Google Workspace bereits erzwingt. Weitere Anbieter werden auf dieselbe Weise angebunden — es handelt sich dabei keineswegs um eine maßgeschneiderte Integration.
Für die Personen und Skripte aufbewahrt, die es benötigen, und an eine echte Richtlinie gebunden: mindestens zwölf Zeichen, niemals Ihr Benutzername oder Ihre E-Mail-Adresse, keine Wiederverwendung Ihrer letzten drei, mit Argon2 gehasht. E-Mail-Adressen werden verifiziert, bevor ein Konto nutzbar wird.
Zweite Faktoren sind Teil des Identitätssystems, kein Zusatzmodul, das Sie kaufen, oder Plugin, das Sie auf Ihrer eigenen Website installieren.
Wenn Ihr Unternehmen bereits einen Identitätsanbieter nutzt – Okta, Entra ID, Google Workspace oder ein beliebiges anderes System, das SAML unterstützt –, verbinden Sie diesen einfach, und Ihre Mitarbeiter melden sich mit ihren bestehenden Unternehmensanmeldedaten bei Zinn Digital® an. Es gibt kein zweites Passwort, das Ihr Team verwalten muss, und keine zweite Offboarding-Checkliste, die vergessen werden könnte.
Dies ist vor allem für Agenturen und Reseller von Bedeutung, bei denen die Personalfluktuation ein echtes Sicherheitsrisiko darstellt. Wenn jemand das Unternehmen verlässt und Sie die Person in Ihrem Verzeichnis deaktivieren, haben Sie damit auch deren Zugang zu Ihrem Hosting deaktiviert. Der Zugriff ist zentral an das Beschäftigungsverhältnis gekoppelt, anstatt über ein Dutzend SaaS-Tools hinweg nachverfolgt werden zu müssen.
SAML funktioniert parallel zu allem anderen, anstatt es zu ersetzen: Auftragnehmer können weiterhin ein Magic-Link-Konto innerhalb einer abgegrenzten Rolle erhalten, während feste Mitarbeiter über SSO beitreten. Eine Organisation, ein Berechtigungsmodell, zwei Eingangstüren.
Der Zugriff ist auf den Organisationsbaum beschränkt – vom Reseller über den Kunden bis zur Website – und wird direkt in der Datenbank über Sicherheit auf Zeilenebene erzwungen, nicht nur in der Anwendung. Mandantenübergreifender Zugriff ist keine Richtlinie, um deren Einhaltung wir bitten; es ist eine Abfrage, die keine Zeilen zurückgeben kann. Vier Kundenrollen decken die realistische Aufgabenteilung ab.
Vollständige Kontrolle über die Organisation und ihre Unterkonten: Erstellen Sie Unterorganisationen, laden Sie Mitglieder ein und entfernen Sie diese, weisen Sie Rollen zu, verwalten Sie jede Website, wickeln Sie Abrechnungen und Rechnungsstellungen ab, verwalten Sie API-Schlüssel und lesen Sie das Überwachungsprotokoll.
Rechnungen, Abonnements, Zahlungsmethoden und der Tarifkatalog – und sonst nichts. Ihre Finanzfachkraft oder Buchhaltung kann eine Rechnung begleichen, ohne jemals die Möglichkeit zu haben, eine Live-Website zu verändern, auszusetzen oder zu löschen.
Zugriff auf Websites und API ohne Abrechnungskontrolle: Websites anzeigen und bereitstellen, Dienste neu starten, Caches leeren, API-Schlüssel und Arbeitstickets verwalten. Zugriff auf Zahlungsmethoden, Rechnungsstellung oder Tarifänderungen ist bewusst ausgeschlossen.
Organisationsweit nur Lesezugriff — Websites, Abrechnung, Tarife, Tickets, Übersetzungsstatus und das Audit-Protokoll. Die richtige Rolle für Auditoren, Kunden mit Wunsch nach Einblick oder neue Mitarbeitende in ihrer ersten Woche.
Das Dashboard ist ein Zugangsweg. Die API, das CLI, der Terraform-Provider und der MCP-Server sind weitere — und sie unterliegen demselben Zugriffsmodell, da ein Schlüssel ohne Geltungsbereich jede soeben von Ihnen konfigurierte Rolle umgeht.
Ein API-Schlüssel wird für eine Organisation ausgestellt, nicht für eine Einzelperson, und verfügt über eigene Berechtigungsbereiche. Behandeln Sie ihn wie gemeinsame Zugangsdaten: Benennen Sie ihn nach seinem Verwendungszweck, weisen Sie ihm die engsten funktionsfähigen Berechtigungsbereiche zu und rotieren Sie ihn, wenn die Person, die ihn erstellt hat, das Unternehmen verlässt.
Der Rohschlüssel wird Ihnen nur einmal angezeigt, und zwar bei der Erstellung. Was wir speichern, ist ein SHA-256-Hash und ein kurzes Präfix für die Suche. Wir können Ihnen einen Schlüssel nicht erneut anzeigen, und eine Kompromittierung der Datenbank liefert einem Angreifer keine funktionierenden Anmeldedaten.
Jeder Schlüssel verfügt über granulare Berechtigungsbereiche, die an denselben Berechtigungskatalog gebunden sind, den auch die Rollen nutzen, protokolliert seine letzte Verwendung und kann sofort widerrufen werden, sobald er auffällig wirkt. Separate sandbox-Schlüssel testen die API, ohne dass eine echte Abrechnung oder Bereitstellung dahintersteht.
Der MCP-Server ermöglicht es jedem MCP-fähigen Agenten, Ihr Hosting zu verwalten – und er authentifiziert sich über OAuth 2.1, beschränkt auf Ihre Organisation und deren RBAC-Berechtigungen, mit pro Werkzeug widerrufbaren Token, Bestätigung bei destruktiven Aktionen, Ausgabenlimits und vollständiger Audit-Protokollierung. Das Verbinden eines KI-Assistenten bedeutet nicht, ihm die Schlüssel zu allem zu übergeben.
Jede privilegierte Aktion schreibt ein unveränderliches Protokoll (append-only) – wer sie ausgeführt hat, was getan wurde, worauf sie sich bezog, die Belege und die Quell-IP-Adresse mit einem Zeitstempel. Es dient nicht der Bequemlichkeit beim Debuggen; es ist die Beweiskette.
Nein – und wir ziehen es vor, dass Sie dies nicht tun. Die Anmeldung per E-Mail-Magic-Link ist der Standard, und Sie können einen Passkey (Touch ID, Face ID, Windows Hello oder einen Hardware-Schlüssel) registrieren und sich anmelden, ohne jemals ein Passwort festgelegt zu haben. E-Mail und Passwort bleiben als Fallback verfügbar, gebunden an ein Minimum von zwölf Zeichen, kein Wiederverwenden Ihrer letzten drei Passwörter und Argon2-Hashing.
Die TOTP-Zwei-Faktor-Authentifizierung ist in die Identitätsebene integriert und kann organisationsweit per Richtlinie durchgesetzt werden, anstatt die Aktivierung jedem einzelnen Mitglied zu überlassen. Passkeys sind die sicherere Option, sofern die Geräte Ihres Teams diese unterstützen, da sie das Passwort überflüssig machen, auf das es Angreifer beim Phishing abgesehen hätten.
Ja. Die Rolle „Rechnungsmanager“ gewährt Zugriff auf Rechnungen, Abonnements, Zahlungsmethoden und den Tarifkatalog und sonst nichts – keinerlei Möglichkeit, eine Website anzuzeigen, bereitzustellen, neu zu starten, auszusetzen oder zu löschen. Umgekehrt gilt dasselbe: Die Rolle „Entwickler“ verwaltet Websites und den API-Zugriff, verfügt jedoch über keinerlei Kontrolle über die Abrechnung. Rollen werden pro Organisation zugewiesen, sodass eine Rolle in einer Organisation keinen Zugriff auf eine separate, unabhängige Organisation gewährt – eine Rolle in einer übergeordneten Organisation gilt jedoch auch für die ihr untergeordneten Organisationen.
Widerrufen Sie ihn über das Dashboard, und er funktioniert ab sofort nicht mehr. Das Schadensausmaß ist darauf beschränkt, wozu dieser Schlüssel von vornherein berechtigt war; aus diesem Grund verfügen Schlüssel über granulare Gültigkeitsbereiche und erfassen einen Zeitstempel der letzten Nutzung — eng begrenzte Bereiche und ein sichtbarer Nutzungsverlauf machen aus einem Datenleck einen eingedämmten Vorfall statt einer vollständigen Kompromittierung des Kontos. Bitte beachten Sie, dass Schlüssel für die Organisation und nicht für eine Einzelperson ausgestellt werden; behandeln Sie sie daher als geteilte Zugangsdaten und rotieren Sie sie, wenn Mitarbeiter das Unternehmen verlassen. Auf unserer Seite wird lediglich ein Hash des Schlüssels gespeichert, sodass ein Leck aus unserer Datenbank keine funktionierenden Zugangsdaten hervorbringt.
Ja. Jede privilegierte Aktion wird mit dem Akteur, der Aktion, dem Ziel, den unterstützenden Nachweisen, der Quell-IP und einem Zeitstempel in ein Audit-Protokoll geschrieben, das ausschließlich erweitert werden kann. Rollen mit Eigentümer- und Nur-Lese-Berechtigung können dieses direkt einsehen. Mitarbeiteraktionen auf Ihrem Konto werden im selben Protokoll erfasst, und sensible oder destruktive Mitarbeiteraktionen können zuvor eine erweiterte Authentifizierung oder eine Genehmigung durch zwei Personen erfordern.
Ja – SAML SSO wird für Enterprise- und Agentur-Konten unterstützt, sodass sich Ihre Mitarbeiter mit vorhandenen Unternehmensanmeldedaten authentifizieren und ein Offboarding in Ihrem Verzeichnis auch hier deren Zugriff entzieht. Sie können Ansätze kombinieren: SSO für festangestelltes Personal, berechtigungsspezifische magic-link-Konten für Auftragnehmer, alles innerhalb desselben Berechtigungsmodells.
Nein – Passwörter werden ganz bewusst nicht migriert. Ihr Konto wird ohne Passwort importiert, und bei der ersten Anmeldung nutzen Sie entweder einen Magic-Link oder legen ein neues Passwort gemäß den aktuellen Richtlinien fest. Die Übernahme alter Passwort-Hashes würde alte Schwachstellen in ein neues System übertragen, weshalb wir darauf verzichten.
Die Footprint-Free-Testversion dauert 14 Tage, erfordert keine Kreditkarte und deckt bis zu fünf Websites ab. Sie erhalten während der Testversion die vollständige Identitätsebene — Passkeys, Zwei-Faktor-Authentifizierung, Rollen, API-Schlüssel und das Audit-Protokoll sind nicht hinter einem kostenpflichtigen Tarif gesperrt.
Registrieren Sie einen Passkey, laden Sie Ihr Team mit den passenden Rollen ein und erstellen Sie einen API-Schlüssel mit Gültigkeitsbereich – alles im Rahmen einer 14-tägigen Testversion ohne erforderliche Kreditkartendaten.
Kostenlos starten