Accountbeveiliging
Serverbeveiliging beschermt de sites. Accountbeveiliging beschermt de sleutels ertoe. Elke Zinn Digital®-login draait op één op standaarden gebaseerd identiteitssysteem — passkeys en WebAuthn, TOTP-tweeledige verificatie, aanmelden via magic link, SAML SSO voor ondernemings- en bureauteams — met gedetailleerde rollen, API-sleutels per organisatie en een append-only auditlogboek erachter.
De meeste hostingaccounts bestaan uit een wachtwoord in een database, gekoppeld aan een controlepaneel. Dat van ons is een speciaal identiteitssysteem — Keycloak, dat OIDC en SAML ondersteunt — dat vóór alles staat: het klantendashboard, de beheerconsole voor medewerkers, deze openbare site en kennisbank, en uw ondersteuningstickets. Meld u één keer aan en u bent direct bij alles aangemeld.
Omdat deze is gebouwd op open standaarden in plaats van een bedrijfseigen aanmelding, is de identiteitslaag op dezelfde manier uitwisselbaar als elk ander onderdeel van het platform. Geen enkel deel van uw toegangsmodel zit vast in het product van een leverancier, en de authenticatie van uw team is er niet van afhankelijk dat wij één leverancier aanhouden. Dat is hetzelfde no-lock-in-principe dat wij toepassen op CDN-accounts, DNS en betalingsproviders.
Aanmelden is gelokaliseerd en de overgang van de site naar het inlogscherm neemt uw taal mee — zo wordt een team verspreid over verschillende landen niet gedwongen om in te loggen in het Engels.
Vier methoden, alle van het hoogste niveau, alle configureerbaar per persoon. Niemand wordt gedwongen de zwakste optie te gebruiken omdat dit de enige is die wordt aangeboden.
Voer uw e-mailadres in, klik op de link en u bent binnen. Geen wachtwoord om te phishen, te hergebruiken of te lekken bij een datalek. Dit is de standaardroute voor nieuwe accounts, en voor de meeste mensen is het de enige die ze ooit nodig zullen hebben.
Registreer een passkey — Touch ID, Face ID, Windows Hello of een hardwaresleutel zoals een YubiKey — en meld u aan zonder enig wachtwoord. Passkeys zijn gebonden aan de oorsprong, waardoor een nagemaakte inlogpagina er geen kan onderscheppen. Het platform accepteert ES256- en RS256-authenticators en geeft de voorkeur aan gebruikersverificatie.
Meld u aan met Google via een standaard verbinding met een identiteitsprovider, zodat een account alle controles overneemt die uw Google Workspace al afdwingt. Verdere providers verbinden op dezelfde manier — niets eraan is een integratie op maat.
Bewaard voor de mensen en scripts die het nodig hebben, en gehouden aan een reëel beleid: minimaal twaalf tekens, nooit uw gebruikersnaam of e-mailadres, geen hergebruik van uw laatste drie en gehasht met Argon2. E-mailadressen worden geverifieerd voordat een account bruikbaar wordt.
Tweede factoren maken deel uit van het identiteitssysteem, niet van een add-on die u koopt of een plug-in die u op uw eigen site installeert.
Als uw organisatie al een identityprovider gebruikt — Okta, Entra ID, Google Workspace of iets anders dat SAML ondersteunt — koppelt u deze eenvoudig en loggen uw medewerkers in bij Zinn Digital® met hun bestaande bedrijfsgegevens. Er is geen tweede wachtwoord dat uw team moet beheren, en geen tweede offboarding-checklist om te vergeten.
Dat is vooral van belang op het niveau van bureaus en wederverkopers, waar personeelsverloop een reëel beveiligingsrisico vormt. Wanneer iemand vertrekt en u diegene in uw directory uitschakelt, ontzegt u diegene direct ook de toegang tot uw hosting. Toegang volgt centraal het dienstverband, in plaats van dat u dit in tientallen SaaS-tools afzonderlijk moet beheren.
SAML functioneert naast al het andere in plaats van het te vervangen: contractanten kunnen nog steeds een magic-link-account krijgen binnen een afgebakende rol, terwijl vast personeel via SSO binnenkomt. Eén organisatie, één rechtenmodel, twee voordeuren.
Toegang is beperkt tot de organisatiestructuur — van reseller tot klant tot site — en wordt via beveiliging op rijniveau afgedwongen in de database zelf, niet alleen in de applicatie. Cross-tenant-toegang is geen beleid waarvan we mensen vragen het te respecteren; het is een query die geen rijen kan retourneren. Vier klantrollen dekken de realistische taakverdeling af.
Volledige controle over de organisatie en haar subaccounts: maak onderliggende organisaties aan, nodig leden uit en verwijder ze, wijs rollen toe, beheer elke site, verzorg de facturering, beheer API-sleutels en lees het auditlogboek.
Facturen, abonnementen, betaalmethoden en de tarievenlijst — en verder niets. Uw financieel medewerker of boekhouder kan een factuur voldoen zonder ooit de mogelijkheid te hebben een live website aan te passen, op te schorten of te verwijderen.
Toegang tot sites en API zonder facturatiebeheer: bekijk en configureer sites, herstart services, wis caches, beheer API-sleutels en werktickets. Bewust geen toegang tot betaalmethoden, facturatie of planwijzigingen.
Alleen-lezen binnen de hele organisatie — websites, facturering, abonnementen, tickets, vertaalstatus en het auditlogboek. De juiste rol voor een auditor, een klant die inzicht wenst, of een nieuwe medewerker in diens eerste week.
Het dashboard is één toegangsweg. De API, de CLI, de Terraform-provider en de MCP-server zijn andere — en deze zijn onderworpen aan hetzelfde toegangsmodel, omdat een sleutel zonder bereikbeperking elke rol omzeilt die u zojuist hebt geconfigureerd.
Een API-sleutel wordt verstrekt aan een organisatie, niet aan een individuele persoon, en heeft eigen scopes. Behandel deze als gedeelde inloggegevens: geef deze een naam op basis van het doel, ken de kleinst mogelijke scopes toe die volstaan en roteer deze wanneer de persoon die deze heeft aangemaakt vertrekt.
De ruwe sleutel wordt slechts eenmaal aan u getoond, bij het aanmaken ervan. Wat wij bewaren is een SHA-256-hash en een kort voorvoegsel voor zoekacties. Wij kunnen u een sleutel niet opnieuw tonen en een database-inbreuk levert een aanvaller geen werkende inloggegevens op.
Elke sleutel heeft granulaire scopes die zijn gekoppeld aan dezelfde machtighedencatalogus die de rollen gebruiken, registreert wanneer deze voor het laatst is gebruikt en kan direct worden ingetrokken zodra er iets niet klopt. Aparte sandbox-sleutels testen de API zonder dat er daadwerkelijke facturering of provisioning achter zit.
Met de MCP-server kan elke MCP-compatibele agent uw hosting beheren — en deze verifieert via OAuth 2.1, afgestemd op uw organisatie en de bijbehorende RBAC-rechten, met per tool intrekbare tokens, bevestiging bij destructieve acties, uitgavenlimieten en volledige auditregistratie. Het koppelen van een AI-assistent betekent niet dat u deze overal toegang toe verleent.
Elke bevoorrechte actie schrijft een record dat alleen kan worden aangevuld — wie het heeft gedaan, wat diegene heeft gedaan, waarop het betrekking had, het ondersteunende bewijs en het bron-IP-adres, met een tijdstempel. Het is geen debuggemak; het is het bewijsspoor.
Nee — en we raden u aan dit niet te doen. Aanmelden via een e-mail met een magic link is de standaardoptie, en u kunt een passkey registreren (Touch ID, Face ID, Windows Hello of een hardwaresleutel) en inloggen zonder ooit een wachtwoord in te stellen. E-mailadres en wachtwoord blijven beschikbaar als alternatief, met een minimum van twaalf tekens, geen hergebruik van uw laatste drie wachtwoorden en Argon2-hashing.
TOTP-tweeledige verificatie is ingebouwd in de identiteitslaag en kan via beleid worden afgedwongen binnen een organisatie, in plaats van dat het aan elk lid wordt overgelaten om zich aan te melden. Passkeys zijn de sterkere optie waar de apparaten van uw team deze ondersteunen, omdat ze het wachtwoord elimineren waarop een aanvaller zou vissen.
Ja. De rol Factureringsbeheerder biedt toegang tot facturen, abonnementen, betaalmethoden en de tariefcatalogus, en verder niets — geen mogelijkheid om een site te bekijken, in te richten, opnieuw op te starten, op te schorten of te verwijderen. Het omgekeerde geldt ook: de rol Ontwikkelaar beheert sites en API-toegang zonder enige controle over de facturering. Rollen worden per organisatie toegewezen, dus een rol in de ene organisatie verleent geen toegang tot een afzonderlijke, niet-gerelateerde organisatie — hoewel een rol in een bovenliggende organisatie van toepassing is op de organisaties die daaronder vallen.
Trek deze in via het dashboard en deze stopt onmiddellijk met werken. De schademarge wordt beperkt door wat die sleutel in de eerste plaats kon doen. Daarom bevatten sleutels granulaire scopes en registreren ze een tijdstempel van het laatste gebruik — nauwe scopes en een zichtbaar gebruiksspoor zorgen ervoor dat een lek een beheerst incident blijft in plaats van een volledige accountinbreuk. Houd er rekening mee dat sleutels worden verstrekt aan de organisatie en niet aan een individu; behandel ze daarom als gedeelde inloggegevens en roteer ze wanneer medewerkers vertrekken. Aan onze kant wordt alleen een hash van de sleutel opgeslagen, dus een lek uit onze database levert geen werkende inloggegevens op.
Ja. Elke bevoorrechte actie wordt vastgelegd in een auditlogboek waaraan alleen gegevens kunnen worden toegevoegd, met vermelding van de uitvoerder, de actie, het doel, ondersteunend bewijs, het bron-IP-adres en een tijdstempel. Eigenaars en rollen met alleen-lezenrechten kunnen dit rechtstreeks inzien. Acties van medewerkers op uw account worden in hetzelfde logbestand geregistreerd, en voor gevoelige of destructieve acties van medewerkers kan eerst aanvullende authenticatie of goedkeuring door twee personen vereist zijn.
Ja — SAML SSO wordt ondersteund voor enterprise- en bureauaccounts, zodat uw medewerkers zich authenticeren met bestaande bedrijfsreferenties en uitdiensttreding in uw directory ook hier hun toegang verwijdert. U kunt benaderingen combineren: SSO voor vast personeel, afgebakende magic-link-accounts voor externe krachten, allemaal binnen hetzelfde machtigingsmodel.
Nee — wachtwoorden worden bewust niet gemigreerd. Uw account wordt zonder wachtwoord geïmporteerd en bij de eerste aanmelding gebruikt u een magic-link of stelt u een nieuw wachtwoord in volgens het huidige beleid. Het overzetten van oude wachtwoord-hashes zou oude kwetsbaarheden naar een nieuw systeem overbrengen, dus dat doen we niet.
De proefperiode van Footprint-Free duurt 14 dagen, vereist geen creditcard en dekt maximaal vijf sites. U krijgt tijdens de proefperiode de volledige identiteitslaag — passkeys, tweeledige verificatie, rollen, API-sleutels en het auditlogboek zijn niet afgeschermd achter een betaald abonnement.
Registreer een passkey, nodig uw team uit voor de juiste rollen en maak een API-sleutel met een specifiek bereik aan — allemaal tijdens een proefperiode van 14 dagen waarvoor geen creditcardgegevens vereist zijn.
Gratis starten