Accountbeveiliging
Serverbeveiliging beschermt de websites. Accountbeveiliging beschermt de sleutels daarvan. Elke login bij Zinn Digital® draait op één op standaarden gebaseerd identiteitssysteem — passkeys en WebAuthn, TOTP-tweefactorauthenticatie, magic-link-aanmelding, SAML SSO voor enterprise- en agency-teams — met granulaire rollen, per-organisatie API-sleutels en een alleen-toevoegen auditlogboek erachter.
De meeste hostingaccounts zijn niet meer dan een wachtwoord in een database, vastgeschroefd aan een controlepaneel. Het onze is een toegewijd identiteitssysteem — Keycloak, dat OIDC en SAML spreekt — dat voor alles staat: het klantenpaneel, de beheerconsole voor medewerkers, deze publieke site en kennisbank, en uw supporttickets. Meld u eenmalig aan en u bent ingelogd op al deze onderdelen.
Omdat het is gebouwd op open standaarden in plaats van een eigen login, is de identiteitslaag op dezelfde manier vervangbaar als elk ander onderdeel van het platform. Geen enkel deel van je toegangsmodel zit opgesloten in het product van een leverancier, en de authenticatie van je team is op geen enkele manier afhankelijk van ons om één enkele leverancier aan te houden. Dat is hetzelfde 'geen-lock-in'-principe dat we hanteren voor CDN-accounts, DNS- en betalingsproviders.
Inloggen is gelokaliseerd en de overgang van de site naar het inlogscherm neemt je taal met zich mee, zodat een team dat verspreid is over verschillende landen niet gedwongen wordt om een Engelstalig inlogscherm te gebruiken.
Vier methoden, allemaal van topkwaliteit, allemaal per persoon configureerbaar. Niemand wordt gedwongen tot de zwakste optie omdat dit de enige is die wordt aangeboden.
Vul je e-mailadres in, klik op de link en je bent binnen. Geen wachtwoord om te vissen, te hergebruiken of te laten lekken in een datalek. Dit is de standaardmethode voor nieuwe accounts en voor de meeste mensen is dit de enige die ze ooit nodig hebben.
Registreer een passkey — Touch ID, Face ID, Windows Hello of een hardware-sleutel zoals een YubiKey — en log in zonder enig wachtwoord. Passkeys zijn gekoppeld aan de oorsprong, waardoor een nagemaakte inlogpagina er geen kan onderscheppen. Het platform accepteert ES256- en RS256-authenticators en geeft de voorkeur aan gebruikersverificatie.
Log in met Google via een standaard identiteitsproviderverbinding, zodat een account alle besturingselementen overneemt die uw Google Workspace al afdwingt. Verdere providers worden op dezelfde manier verbonden; er is niets op maat aan geïntegreerd.
Bewaard voor de mensen en scripts die het nodig hebben, en gebonden aan een echt beleid: minimaal twaalf tekens, nooit je gebruikersnaam of e-mailadres, geen hergebruik van je laatste drie, gehasht met Argon2. E-mailadressen worden geverifieerd voordat een account bruikbaar wordt.
Tweede factoren maken deel uit van het identiteitssysteem, geen extra optie die u koopt of een plug-in die u op uw eigen site installeert.
Als uw organisatie al een id-provider gebruikt — Okta, Entra ID, Google Workspace of iets anders dat SAML ondersteunt — kunt u deze koppelen en loggen uw medewerkers in bij Zinn Digital® met hun bestaande bedrijfsgegevens. Uw team hoeft geen tweede wachtwoord te beheren en er is geen tweede offboarding-checklist die kan worden vergeten.
Dat is vooral belangrijk op het niveau van bureaus en resellers, waar personeelsverloop een serieus beveiligingsincident is. Wanneer iemand vertrekt en je diegene uitschakelt in je directory, heb je daarmee ook diens toegang tot je hosting geblokkeerd. Toegang volgt het dienstverband, centraal geregeld, in plaats van dat je dit over een dozijn SaaS-tools moet najagen.
SAML staat naast al het andere in plaats de oude methoden te vervangen: contractanten kunnen nog steeds een magic-link-account krijgen binnen een beperkte rol, terwijl vast personeel binnenkomt via SSO. Eén organisatie, één permissiemodel, twee voordeuren.
Toegang is beperkt tot de organisatieboom — van reseller tot klant tot site — en wordt afgedwongen in de database zelf via row-level security, niet alleen in de applicatie. Toegang tussen verschillende tenants is geen beleid dat we mensen vragen te respecteren; het is een query die geen rijen kan retourneren. Vier klantrollen dekken de realistische taakverdeling.
Volledige controle over de organisatie en haar subaccounts: maak onderliggende organisaties aan, nodig leden uit en verwijder ze, wijs rollen toe, beheer elke site, handel facturering en facturen af, beheer API-sleutels en lees het auditlogboek.
Facturen, abonnementen, betaalmethoden en de plancatalogus — en niets anders. Uw financieel medewerker of accountant kan een factuur voldoen zonder ooit de bevoegdheid te hebben om een live website aan te raken, te schorsen of te verwijderen.
Websites en API-toegang zonder facturatiebeheer: websites bekijken en inrichten, services herstarten, caches opschonen, API-sleutels beheren en aan tickets werken. Bewust geen toegang tot betaalmethoden, facturering of abonnementswijzigingen.
Alleen-lezen binnen de hele organisatie — websites, facturering, abonnementen, tickets, vertaalstatus en het auditlogboek. De juiste rol voor een auditor, een klant die inzicht wil, of een nieuwe medewerker in hun eerste week.
Het dashboard is één toegangspoort. De API, de CLI, de Terraform-provider en de MCP-server zijn andere — en voor al deze opties geldt hetzelfde toegangsmodel, omdat een niet-afgebakende sleutel elke rol omzeilt die je zojuist hebt geconfigureerd.
Een API-sleutel wordt uitgegeven aan een organisatie, niet aan een individueel persoon, en heeft eigen scopes. Behandel deze als gedeelde inloggegevens: geef de sleutel een naam op basis van het doel, ken de meest beperkte scopes toe die nog werken, en roteer de sleutel wanneer de persoon die hem heeft aangemaakt vertrekt.
Deruwe sleutel wordt u slechts één keer getoond, bij het aanmaken. Wat we bewaren is een SHA-256-hash en een kort voorvoegsel om te zoeken. We kunnen u een sleutel niet opnieuw tonen, en een datalek geeft een aanvaller geen werkende inloggegevens.
Elke sleutel beschikt over gedetailleerde scopes die zijn gekoppeld aan dezelfde rechten-catalogus die de rollen gebruiken, registreert wanneer deze voor het laatst is gebruikt, en kan direct worden ingetrokken zodra er iets niet in de haak is. Aparte sandbox-sleutels testen de API zonder dat er echte facturering of provisioning aan te pas komt.
Met de MCP-server kan elke MCP-compatibele agent je hosting beheren — en deze verifieert via OAuth 2.1, beperkt tot je organisatie en de bijbehorende RBAC-rechten, met per tool intrekbare tokens, bevestiging bij destructieve acties, uitgavenlimieten en volledige auditlogging. Het verbinden van een AI-assistent betekent niet dat je de sleutels van alles overhandigt.
Elke bevoorrechte actie schrijft een append-only record — wie het deed, wat ze deden, waar ze het op deden, het ondersteunende bewijs en het bron-IP-adres, met een tijdstempel. Het is geen handigheidje voor debugging; het is de bewijsketen.
Nee — en we hebben liever dat u dat ook niet doet. Aanmelden via een magic link per e-mail is de standaard, en u kunt een passkey registreren (Touch ID, Face ID, Windows Hello of een hardware-sleutel) en inloggen zonder dat er ooit een wachtwoord is ingesteld. E-mail en wachtwoord blijft beschikbaar als alternatief, met een minimum van twaalf tekens, geen hergebruik van uw laatste drie, en Argon2-hashing.
TOTP-tweefactorauthenticatie is ingebouwd in de identiteitslaag en kan via beleid worden verplicht binnen een organisatie in plaats de keuze over te laten aan elk individueel lid. Passkeys zijn de sterkere optie wanneer de apparaten van je team deze ondersteunen, omdat ze het wachtwoord wegnemen waar een aanvaller op zou phishen.
Ja. De rol van Facturatiebeheerder verleent toegang tot facturen, abonnementen, betaalmethoden en de plannencatalogus, en verder niets — geen mogelijkheid om een site te bekijken, te provisioneren, te herstarten, te schorsen of te verwijderen. Het omgekeerde geldt ook: de rol van Ontwikkelaar beheert sites en API-toegang zonder enige controle over de facturatie. Rollen worden per organisatie toegewezen, dus een rol in de ene organisatie verleent geen toegang tot een afzonderlijke, ongerelateerde organisatie — hoewel een rol in een bovenliggende organisatie van toepassing is op de organisaties die daaronder zijn genest.
Trek deze in via het dashboard en hij stopt direct met werken. Het schadeveld wordt beperkt door wat die sleutel sowieso kon doen, en daarom hebben sleutels gedetailleerde scopes en wordt er een tijdstempel van het laatste gebruik vastgelegd — krappe scopes en een zichtbaar gebruiksspoor veranderen een lek in een beheersbaar incident in plaats van een volledig gecompromitteerd account. Let op: sleutels worden uitgegeven aan de organisatie en niet aan een individueel persoon, dus behandel ze als gedeelde inloggegevens en roteer ze wanneer personen vertrekken. Er wordt aan onze kant alleen een hash van de sleutel opgeslagen, dus een lek vanuit onze database levert geen werkende inloggegevens op.
Ja. Elke bevoorrechte actie wordt weggeschreven naar een alleen-toevoegen auditlogboek met de actor, de actie, het doelwit, ondersteunend bewijs, het bron-ip-adres en een tijdstempel. Eigenaren en rollen met alleen-lezen kunnen dit direct uitlezen. Acties van medewerkers op uw account worden in dezelfde reeks gelogd, en gevoelige of destructieve medewerkersacties kunnen eerst stap-voor-stap-authenticatie of goedkeuring door twee personen vereisen.
Ja — SAML SSO wordt ondersteund voor enterprise- en agency-accounts, zodat uw gebruikers inloggen met bestaande bedrijfsgegevens en het verwijderen uit uw directory hun toegang hier ook intrekt. U kunt benaderingen combineren: SSO voor vast personeel, accounts met beperkte magic links voor freelancers, allemaal binnen hetzelfde toegangsmodel.
Nee — wachtwoorden worden bewust niet gemigreerd. Je account wordt zonder wachtwoord geïmporteerd en bij de eerste aanmelding gebruik je een magic link of stel je een nieuw wachtwoord in volgens het huidige beleid. Het overzetten van oude wachtwoordhashes zou oude kwetsbaarheden meenemen naar een nieuw systeem, dus dat doen we niet.
De Footprint-Free proefperiode duurt 14 dagen, is zonder creditcard en dekt maximaal vijf sites. Je krijgt de volledige identiteitslaag tijdens de proefperiode — passkeys, tweefactorauthenticatie, rollen, API-sleutels en het auditlogboek worden niet achter een betaald abonnement gehouden.
Registreer een passkey, nodig je team uit in de juiste rollen en geef een scoped API key uit — dit alles op een kaartloze proefperiode van 14 dagen waarvoor geen creditcardgegevens vereist zijn.
Start gratis