Zekura schermgids

Elk scherm van het portaal: wat het is, waarom het bestaat, hoe u het gebruikt, wat het resultaat moet zijn en wie wat mag. Rollen: eigenaar (E), beheerder (B), operator (O), lezer (L), auditor (A); IT-partner (MSP) en platformbeheer (P) apart. Screenshots komen uit de geautomatiseerde doorloop van 7 september 2026 (qa/crawl.mjs).

Aanmelden, registreren, tweede factor

• Wat: e-mail + wachtwoord; bij ingeschakelde 2FA daarna een TOTP-code; links naar wachtwoord vergeten en registratie.
• Waarom: één account kan lid zijn van meerdere organisaties; de aanmelding brengt u naar uw thuisorganisatie.
• Hoe: aanmelden → bij een nieuwe organisatie landt u op Aan de slag, anders op het Overzicht. Registreren vraagt alleen bedrijfsnaam, e-mailadres en wachtwoord. Na de e-mailbevestiging maakt Zekura opslag, sleutels en keten aan en landt u op Aan de slag. De herstelsleutel (vijf delen, drie nodig) is daar stap 2: de eigenaar haalt de delen op, bewaart ze en bevestigt; daarna wist Zekura ze (zie Help → Zelf beginnen).
• Resultaat: sessie van 12 uur; elke aanmelding wordt vastgelegd (laatste aanmelding zichtbaar onder Gebruikers).
• Wie: iedereen. Op een white-label-domein toont dit scherm de huisstijl van de IT-partner.

Overzicht

• Wat: de Restore Assurance Score met dekking, versheid en bewijs; onbeschermde systemen uit de inventaris; per opdracht laatste run, versheid ("op tijd / laat / te oud"), bewijskracht ("sterk / matig / zwak / geen") en laatste verificatieniveau; faalanalyse van 7 dagen; laatste runs.
• Waarom: in één blik zien of u morgen kunt herstellen, en wat het eerst aandacht vraagt.
• Hoe: rood of "zwak" aanklikken → opdracht of run; "Opdracht maken" bij een gat in de dekking. De banner Aan de slag verdwijnt zodra de eerste geverifieerde backup er is.
• Resultaat: score ≥ 80 is groen; de trend over 14 dagen staat onder de score.
• Wie: E B O L A. Alleen E/B zien "Nieuwe opdracht". Bij unit-scope ziet u alleen uw units.

Meldingen

• Wat: alles wat het platform meldde: mislukte backups en verificaties, hosts die zwijgen, RPO-overschrijdingen, anomalieën, quota, escrow: voor uw organisatie en (IT-partner) voor al uw klanten. Teller in het menu = ongelezen.
• Waarom: meldingen zijn werk; iemand moet ze oppakken en dat moet zichtbaar zijn voor collega's en auditors.
• Hoe: openen = gelezen. Waarschuwingen en kritieke meldingen bevestigt u: per stuk, geselecteerd, of "alle open in beeld" (na filteren op soort of organisatie). Een soort die u kent, dempt u 7 dagen. "Bekijk" springt naar het object (opdracht, run, host, bestemming). Persoonlijke e-mailvoorkeuren staan onder Account → Meldingen; teamkanalen onder Beheer → Kanalen.
• Resultaat: bevestigen is een ketenrecord (alerts_acknowledged, één per organisatie per handeling): de auditor ziet wie wanneer reageerde.
• Wie: lezen E B O L; bevestigen/dempen E B O. Auditors zien geen meldingen.

Hosts

• Wat: elke machine met een agent (of verifier/worker), status (gezond / laat niets horen / offline), agentversie, certificaat, inventaris (containers, volumes, databanken) en dekking.
• Waarom: een host die zwijgt, maakt geen backups; de inventaris toont wat u vergeten bent te beschermen.
• Hoe: Nieuwe host geeft een eenmalig token en het installatiecommando; binnen een minuut verschijnt de host. Op de hostpagina: unit toekennen, inventaris bekijken, opdracht maken vanuit een gat.
• Resultaat: status gezond, agent op de laatste versie (updates gaan vanzelf, met handtekeningcontrole).
• Wie: E B O (toevoegen, unit), L lezen. A ziet hosts niet in detail.

Opdrachten

• Wat: wat beschermd wordt (bestanden, PostgreSQL PITR of dump, MySQL, Docker-volumes, Gitea, Mailcow, Nextcloud, Kubernetes, Proxmox), waarheen, hoe vaak, en de stand van de laatste run.
• Waarom: de opdracht is de eenheid van bescherming én van bewijs: elke run, elke verificatie en elke restore hangt eraan.
• Hoe: Nieuwe opdracht: host, soort, wat precies (mappen, containers, databanken), unit, bestemming, beleid, planning; bij een eerste grote map eerst de omvangsschatting bekijken. Nu draaien start binnen 30 seconden. De opdrachtpagina toont runs, verificaties, RPO (bij PITR), restore-formulier en wijzigingsgeschiedenis.
• Resultaat: run "ok" gevolgd door L1-verificatie "pass" (minuten), dagelijks L2, wekelijks L3 waar van toepassing.
• Wie: aanmaken/wijzigen E B; draaien E B O; restore aanvragen E B O; lezen L A (auditor zonder paden).

Runs

• Wat: elke uitvoering met resultaat, nieuwe en logische bytes, verificaties en ketennummer; de runpagina heeft het volledige agentrapport, de steekproef en het restore-formulier.
• Waarom: dit is het ruwe bewijs; alles hier is ondertekend door de agent en door het platform.
• Hoe: filter op mislukt; open een run voor de foutmelding; herstel vanuit een run naar een map, een PVC of (PITR) naar een tijdstip.
• Resultaat: een restore verschijnt als restore_completed met bestanden, bytes, checksums en gemeten duur: de RTO die in het rapport komt.
• Wie: lezen E B O L A; restore E B O.

Bestemmingen

• Wat: per opslagplek een kaart met de ransomware-checklist (versioning, object lock in compliance-modus, agent kan niet wissen, opruimen), de sleutelsituatie (managed met shares bevestigd / sovereign), onderhoud en delete markers.
• Waarom: de bescherming van de backup zit in de bucket, niet in de software; dit scherm bewijst dat de bucket klopt.
• Hoe: Test opnieuw na een aanpassing bij de opslagpartij; Escrow-test doen eens per jaar met drie shares; Lifecycle-regel instellen alleen als de partij dat ondersteunt (anders ruimt Zekura wekelijks zelf op: dat staat er dan). Eigen S3-opslag toevoegen voor een eigen bucket, met sleutelmodel-keuze.
• Resultaat: groene rand = geschikt. Rood = niet geschikt, met de reden erbij.
• Wie: lezen E B O L A; wijzigen E B; escrow en sleutelmodel alleen E.

Wijzigingen

• Wat: verzwakkende wijzigingen (opdracht uitzetten, retentie inkorten, bestemming verwijderen) gaan in een wachttijd van 72 uur en kunnen in die tijd geannuleerd worden.
• Waarom: een aanvaller met beheerdersrechten mag niet in één keer de bescherming kunnen afbreken.
• Hoe: aanvragen → melding naar alle kanalen → na 72 uur automatisch toegepast, of annuleren.
• Wie: E B.

Bewijsketen

• Wat: elke gebeurtenis (run, verificatie, restore, wijziging, gebruiker, sleutel) als ondertekend, gekoppeld record; export als JSON; de dagelijks gepubliceerhet ankerpunt.
• Waarom: dit is wat een auditor zonder Zekura kan narekenen (zekura-verify, publieke roots-repository).
• Hoe: exporteren → zekura-verify export.json --root <ankerpunt>; zie Help → Bewijsketen narekenen.
• Wie: E B O L A (auditors zijn hiervoor gemaakt).

Rapporten

• Wat: kwartaal- of maandrapport als PDF (NL/FR/EN) met score, systemen, runs, verificaties, restores, opslagbescherming, sleutels, ketenankerpunt en normmapping (NIS2, ISO 27001, CyFun, DORA, GDPR).
• Waarom: het verkoopbare eindproduct: één document dat "wij kunnen herstellen" bewijst.
• Hoe: periode en taal kiezen → uitgeven; downloaden; "handtekening" geeft sha256, handtekening en ketennummer.
• Resultaat: report_issued in de keten; sha256sum rapport.pdf komt overeen.
• Wie: uitgeven E B A; downloaden E B O L A.

Gebruikers en rollen

• Wat: leden met rol, scope (hele organisatie of units), 2FA-status en laatste aanmelding; geërfde leden van de IT-partner; open uitnodigingen; units.
• Waarom: wie wat mag, moet expliciet en controleerbaar zijn; elke wijziging is een ketenrecord.
• Hoe: uitnodigen per e-mail (bestaand account krijgt meteen de rol); rol wijzigen in de lijst; units aanmaken en leden erop beperken. "Wat mag welke rol?" toont de matrix.
• Resultaat: minstens één eigenaar blijft altijd; niemand kent een rol hoger dan de zijne toe.
• Wie: beheren E (alles) en B (tot beheerder); lezen O L.

Capaciteit

• Wat: beschermd (logisch), fysiek na deduplicatie, verstuurd in 30 dagen, groei per dag, verloopgrafiek, quota met prognose, per bestemming, grootste opdrachten, per host.
• Waarom: kosten en verrassingen voorkomen; de quota is een zachte limiet die nooit een backup blokkeert.
• Hoe: quota instellen onder Instellingen; bij 80 % en 100 % komt een melding.
• Wie: E B O L A.

Kanalen

• Wat: waarheen het platform belt: webhook, e-mail (SMTP), Matrix; per kanaal een minimale ernst; testknop.
• Waarom: meldingen in het portaal alleen zijn niet genoeg; het team moet ze in zijn eigen kanaal krijgen. Kanalen van de IT-partner ontvangen ook de meldingen van klanten.
• Wie: E B; lezen O L.

Instellingen en Account

• Instellingen (E): naam, opslagquota, uitrolkanaal voor agent-updates, organisatie-id.
• Account (iedereen): 2FA aan- of uitzetten (QR-code), wachtwoord wijzigen, persoonlijke meldingsvoorkeuren, gedempte soorten.

IT-partner: Klanten, Huisstijl, Verbruik & facturatie

• Wat: alle klanten op risico gesorteerd; Werken in een klant (gele balk, alles in hún keten); huisstijl (naam, logo, kleuren, eigen domein, afzender); maandelijks verbruik per klant met factuurregel, CSV en verzending naar facturatie.
• Waarom: de partner verkoopt het bewijs door, onder eigen merk, en factureert per klant.
• Wie: eigenaar/beheerder van de partner-organisatie; werken-in vanaf operator.

Platformbeheer: Tenants, Gebruikers, Releases, Uitgaande mail, Status

• Wat: organisaties aanmaken (met eigen bucket, IAM-sleutels, sleutelmodel, beheerder, token), alle gebruikers en rollen zien, agent-releases publiceren en uitrolkanalen zetten, uitgaande mail lezen als er geen SMTP is, en de publieke statuspagina.
• Waarom: Zekura beheert de organisaties, niet hun backups. Platformbeheer kan niet in een klantorganisatie werken; wil een klant hulp, dan nodigt hij iemand van Zekura uit: en dat staat in zijn keten.
• Wie: eigenaar van de organisatie "Zekura Platform".