Kontosicherheit
Serversicherheit schützt die Websites. Kontosicherheit schützt die Schlüssel dazu. Jede Anmeldung bei Zinn Digital® basiert auf einem standardsbasierten Identitätssystem – Passkeys und WebAuthn, TOTP-Zwei-Faktor, Magic-Link-Anmeldung, SAML-SSO für Unternehmens- und Agenturteams –, dem granulare Rollen, organisationsbezogene API-Schlüssel und ein unveränderliches Audit-Log zugrunde liegen.
Die meisten Hosting-Konten sind ein Passwort in einer Datenbank, festgeschraubt an ein Control Panel. Unseres ist ein dediziertes Identitätssystem – Keycloak, das OIDC und SAML spricht –, das vor allem anderen steht: dem Kunden-Dashboard, der Admin-Konsole für Mitarbeiter, dieser öffentlichen Website und Wissensdatenbank sowie Ihren Support-Tickets. Melden Sie sich einmal an und Sie sind auf allen angemeldet.
Da die Identitätsebene auf offenen Standards statt auf einem proprietären Login basiert, lässt sich diese genauso austauschen wie jede andere Komponente der Plattform. Kein Teil Ihres Zugriffsmodells ist an das Produkt eines Anbieters gebunden, und die Authentifizierung Ihres Teams hängt in keiner Weise davon ab, dass wir an einem bestimmten Lieferanten festhalten. Das ist dasselbe Prinzip der Unabhängigkeit vom Anbieter (No-Lock-in), das wir auch auf CDN-Konten, DNS und Zahlungsanbieter anwenden.
Die Anmeldung ist lokalisiert, und die Weiterleitung von der Website zum Anmeldebildschirm übernimmt Ihre Sprache – sodass ein über Länder verstreutes Team nicht gezwungen ist, einen rein englischen Login zu verwenden.
Vier Methoden, alle erstklassig, alle pro Person konfigurierbar. Niemand wird gezwungen, die schwächste Option zu nutzen, nur weil sie die einzige ist, die angeboten wird.
Geben Sie Ihre E-Mail-Adresse ein, klicken Sie auf den Link und Sie sind drin. Kein Passwort, das abgephisht, wiederverwendet oder bei einem Datenleck veröffentlicht werden kann. Dies ist der Standardweg für neue Konten und für die meisten Menschen der einzige, den sie jemals brauchen.
Registriere einen Hauptschlüssel – Touch ID, Face ID, Windows Hello oder einen Hardware-Schlüssel wie einen YubiKey – und melde dich ganz ohne Passwort an. Hauptschlüssel sind an den Ursprung gebunden, sodass eine gefälschte Anmeldeseite keinen abgreifen kann. Die Plattform akzeptiert ES256- und RS256-Authentifizierungsmethoden und bevorzugt die Nutzerverifizierung.
Melden Sie sich über eine Standard-Identitätsanbieterverbindung mit Google an, sodass ein Konto alle Steuerelemente übernimmt, die Ihr Google Workspace bereits erzwingt. Weitere Anbieter werden auf dieselbe Weise verbunden – es handelt sich dabei keineswegs um eine maßgeschneiderte Integration.
Für Personen und Skripte beibehalten und an eine echte Richtlinie geknüpft: mindestens zwölf Zeichen, niemals Ihr Benutzername oder Ihre E-Mail-Adresse, keine Wiederverwendung der letzten drei, gehasht mit Argon2. E-Mail-Adressen werden verifiziert, bevor ein Konto genutzt werden kann.
Zweite Faktoren sind Teil des Identitätssystems und kein Zusatzprodukt, das Sie kaufen, oder ein Plugin, das Sie auf Ihrer eigenen Website installieren.
Wenn Ihr Unternehmen bereits einen Identitätsanbieter betreibt – Okta, Entra ID, Google Workspace oder einen anderen, der SAML unterstützt –, verbinden Sie diesen einfach, und Ihre Mitarbeiter melden sich mit ihren bestehenden Unternehmensdaten bei Zinn Digital® an. So gibt es kein zweites Passwort, das Ihr Team verwalten muss, und keine zweite Offboarding-Checkliste, die vergessen werden kann.
Das fällt vor allem auf der Ebene von Agenturen und Resellern ins Gewicht, wo die Fluktuation von Mitarbeitern ein echtes Sicherheitsrisiko darstellt. Wenn jemand das Unternehmen verlässt und Sie den Account in Ihrem Verzeichnis deaktivieren, ist damit auch der Zugriff auf das Hosting gesperrt. Der Zugriff folgt zentral dem Beschäftigungsverhältnis, anstatt dass man ihm über ein Dutzend SaaS-Tools hinweg hinterherlaufen muss.
SAML ergänzt alle anderen Methoden, anstatt sie zu ersetzen: Auftragnehmer können weiterhin ein Magic-Link-Konto mit einer eingeschränkten Rolle erhalten, während festangestellte Mitarbeiter sich über SSO anmelden. 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 durch zeilenbasierte Sicherheit (Row-Level Security) durchgesetzt, nicht nur in der Anwendung. Mandantenübergreifender Zugriff ist keine Richtlinie, deren Einhaltung wir erwarten; es ist eine Abfrage, die keine Zeilen zurückgeben kann. Vier Kundenrollen decken die realistische Aufteilung der Aufgaben ab.
Volle Kontrolle über die Organisation und ihre Unterkonten: Unterorganisationen erstellen, Mitglieder ein- und austragen, Rollen zuweisen, jede Website verwalten, Abrechnung und Rechnungsstellung übernehmen, API-Schlüssel verwalten und das Audit-Log einsehen.
Rechnungen, Abonnements, Zahlungsmethoden und der Tarifkatalog – und sonst nichts. Ihre Buchhaltung oder Finanzabteilung kann Rechnungen begleichen, ohne jemals die Berechtigung zu haben, eine Live-Website anzufassen, zu sperren oder zu löschen.
Websites und API-Zugriff ohne Abrechnungskontrolle: Websites anzeigen und bereitstellen, Dienste neu starten, Caches leeren, API-Schlüssel verwalten und Support-Tickets bearbeiten. Bewusst ohne Zugriff auf Zahlungsmethoden, Rechnungsstellung oder Tarifänderungen.
Nur Lesezugriff im gesamten Unternehmen – Websites, Abrechnung, Tarife, Tickets, Übersetzungsstatus und das Audit-Protokoll. Die richtige Rolle für Prüfer, Kunden mit Einblickbedarf oder neue Mitarbeitende in ihrer ersten Woche.
Das Dashboard ist ein Zugangsweg. Die API, das CLI, der Terraform-Provider und der MCP-Server sind andere – und für sie gilt dasselbe Zugriffsmodell, denn ein nicht eingeschränkter Schlüssel hebelt jede Rolle aus, die Sie gerade konfiguriert haben.
Ein API-Schlüssel wird für eine Organisation ausgestellt, nicht für eine Einzelperson, und besitzt eigene Berechtigungsumfänge. Betrachten Sie ihn wie gemeinsame Zugangsdaten: Benennen Sie ihn nach seinem Zweck, weisen Sie ihm die engsten noch funktionierenden Berechtigungen zu und rotieren Sie ihn, wenn die Person, die ihn erstellt hat, das Team verlässt.
Den rohen Schlüssel bekommen Sie nur einmal bei der Erstellung angezeigt. Was wir speichern, ist ein SHA-256-Hash und ein kurzes Präfix zum Nachschlagen. Wir können Ihnen einen Schlüssel kein zweites Mal anzeigen, und ein Datenbank-Kompromiss liefert einem Angreifer keine funktionierenden Zugangsdaten.
Jeder Schlüssel enthält granulare Berechtigungsbereiche, die an denselben Berechtigungskatalog wie die Rollen gekoppelt sind, protokolliert die letzte Verwendung und kann sofort widerrufen werden, sobald etwas verdächtig erscheint. Separate Sandbox-Schlüssel nutzen die API ohne echte Abrechnung oder Bereitstellung im Hintergrund.
Der MCP-Server ermöglicht es jedem MCP-fähigen Agenten, Ihr Hosting zu verwalten – und authentifiziert sich über OAuth 2.1, beschränkt auf Ihre Organisation und deren RBAC-Berechtigungen, mit pro Tool widerrufbaren Token, Bestätigungen bei destruktiven Aktionen, Ausgabenlimits und vollständiger Audit-Protokollierung. Die Verbindung eines KI-Assistenten bedeutet nicht, ihm die Schlüssel zu allem zu übergeben.
Jede privilegierte Aktion schreibt einen unveränderlichen Protokolleintrag – wer sie ausgeführt hat, was getan wurde, woran es getan wurde, die unterstützenden Belege und die Quell-IP-Adresse samt Zeitstempel. Das ist keine Annehmlichkeit zum Debuggen, sondern die Beweiskette.
Nein — und das würden wir auch bevorzugen. Die Anmeldung per Magic-Link-E-Mail 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, erfordern mindestens zwölf Zeichen, keine Wiederverwendung der letzten drei und werden mit Argon2 gehasht.
TOTP-Zwei-Faktor-Authentifizierung ist direkt in die Identitätsebene integriert und kann per Richtlinie im gesamten Unternehmen durchgesetzt werden, anstatt dass es jedem Mitglied selbst überlassen bleibt, sich dafür zu entscheiden. Hauptschlüssel (Passkeys) sind die stärkere Option, sofern die Geräte Ihres Teams diese unterstützen, da sie das Passwort überflüssig machen, auf das ein Angreifer es abgesehen hätte.
Ja. Die Rolle des Abrechnungsmanagers umfasst Rechnungsdaten, Abonnements, Zahlungsmethoden und den Tarifkatalog und sonst nichts – keinerlei Berechtigung zum Anzeigen, Bereitstellen, Neustarten, Sperren oder Löschen einer Website. Umgekehrt gilt dasselbe: Die Entwickler-Rolle verwaltet Websites und API-Zugriffe völlig ohne Abrechnungskontrolle. Rollen werden pro Organisation zugewiesen, sodass eine Rolle in einer Organisation keinen Zugriff auf eine separate, unverbundene Organisation gewährt – eine Rolle in einer übergeordneten Organisation gilt jedoch auch für die darunter verschachtelten Organisationen.
Widerrufen Sie ihn im Dashboard, hört er sofort auf zu funktionieren. Das Schadensfenster ist auf das beschränkt, wozu dieser Schlüssel ohnehin in der Lage war, weshalb Schlüssel über granulare Berechtigungen verfügen und einen Zeitstempel der letzten Verwendung aufzeichnen – eingeschränkte Berechtigungen und eine sichtbare Nutzungshistorie machen aus einem Leak einen eingegrenzten Vorfall anstelle einer vollständigen Kontoüberkompromittierung. Beachten Sie, że Schlüssel an die Organisation statt an Einzelpersonen ausgestellt werden; behandeln Sie sie daher wie gemeinsam genutzte Zugangsdaten und rotieren Sie sie, wenn Mitarbeiter das Unternehmen verlassen. Auf unserer Seite wird nur ein Hash des Schlüssels gespeichert, sodass ein Leak aus unserer Datenbank keine funktionierenden Zugangsdaten preisgibt.
Ja. Jede privilegierte Aktion wird in ein manipulationssicheres Audit-Log geschrieben, das den Akteur, die Aktion, das Ziel, unterstützende Beweise, die Quell-IP und einen Zeitstempel enthält. Eigentümer- und Nur-Lese-Rollen können dies direkt einsehen. Mitarbeiteraktionen in Ihrem Konto werden im selben Protokoll erfasst, und sensible oder destruktive Mitarbeiteraktionen können zuvor eine Schritt-für-Schritt-Authentifizierung oder die Genehmigung durch zwei Personen erfordern.
Ja — SAML-SSO wird für Enterprise- und Agenturkonten unterstützt, sodass sich Ihre Mitarbeiter mit bestehenden Unternehmensanmeldedaten authentifizieren und das Offboarding in Ihrem Verzeichnis auch hier ihren Zugriff entfernt. Sie können Ansätze kombinieren: SSO für festangestellte Mitarbeiter, bereichsbezogene Magic-Link-Konten für Auftragnehmer, alles innerhalb desselben Berechtigungsmodells.
Nein — Passwörter werden absichtlich nicht migriert. Ihr Konto wird ohne Passwort importiert, und bei der ersten Anmeldung nutzen Sie entweder einen Magic-Link oder legen unter der aktuellen Richtlinie ein neues Passwort fest. Die Übernahme alter Passwort-Hashes würde alte Schwachstellen in ein neues System übertragen, daher tun wir das nicht.
Die Footprint-Free Testphase dauert 14 Tage, erfordert keine Kreditkarte und gilt für bis zu fünf Websites. Sie erhalten während der Testphase die vollständige Identitätsebene – Passkeys, Zwei-Faktor-Authentifizierung, Rollen, API-Schlüssel und das Audit-Log sind nicht hinter einem kostenpflichtigen Tarif verborgen.
Registrieren Sie einen Passkey, laden Sie Ihr Team in die passenden Rollen ein und erstellen Sie einen eingeschränkten API-Schlüssel – das alles in einer 14-tägigen Testversion ohne Kreditkarte und ohne Angabe von Zahlungsdaten.
Kostenlos starten