Ofte stillede spørgsmål om to-faktor-autentificering og analyser

De fleste sikkerhedsbrud i analyseplatforme sker ikke, fordi selve dataene var værdifulde nok til at stjæle, men fordi en administratorkonto med adgang til dashboards manglede et andet lag beskyttelse. En besøgstælling er ikke fortrolig i sig selv, men den konto, der kan eksportere rapporter, ændre integrationer eller tilgå API-nøgler til dine kassesystemer, er et reelt mål. Derfor er spørgsmålet om to-faktor-autentificering på analyseplatforme sjældent et spørgsmål om selve tallene — det handler om, hvem der kommer ind, og hvad de kan gøre bagefter.

Hvad betyder to-faktor-autentificering egentlig i en analysekontekst?

To-faktor-autentificering (2FA) kræver, at brugeren beviser sin identitet med to uafhængige faktorer: noget de ved (adgangskode) og noget de har (en engangskode fra en app, en hardware-token eller en push-notifikation). I en analyseplatform gælder det typisk for tre indgange: web-dashboardet, administrationsportalen og API-adgangen. Mange organisationer sikrer dashboardet, men glemmer API-lagret, hvor automatiserede integrationer ofte kører på statiske nøgler uden andet lag. Det er den svaghed, en revisor vil finde.

Erstatter 2FA min eksisterende SSO-løsning?

Nej — de arbejder sammen. Hvis din organisation allerede bruger en identitetsudbyder som Azure AD, Okta eller Google Workspace, bør analyseplatformen tilslutte sig via SSO (SAML eller OIDC), så 2FA håndteres centralt af jeres eksisterende politik. Fordelen er, at I ikke administrerer et separat sæt legitimationsoplysninger, og at deaktivering af en medarbejder ét sted lukker al adgang. Praktisk observation fra implementeringer: den største kilde til frustration er ikke selve SSO-opsætningen, men gruppemapping. Hvis platformen ikke kan læse jeres AD-grupper korrekt, ender alle enten som administratorer eller som brugere uden adgang — og oprydningen tager længere tid end selve integrationen.

Bemærk til procurement: Bed leverandøren dokumentere præcist hvilke SSO-protokoller der understøttes, før kontrakten underskrives. Antag ikke at "understøtter SSO" betyder SCIM-provisionering eller automatisk deprovisionering.

Hvordan hænger 2FA sammen med GDPR og databeskyttelse?

GDPR kræver "passende tekniske foranstaltninger" til at beskytte adgang til systemer, der behandler data. 2FA er en af de mest konkrete foranstaltninger, en compliance-officer kan pege på i en databehandleraftale. Men den reelle databeskyttelse begynder tidligere — ved hvilke data platformen overhovedet indsamler. Vemcos personoptælling er designet, så der ikke sker personidentifikation: der tælles i aggregerede tal, personalet kan ekskluderes, og der lagres ikke identificerbare oplysninger om den enkelte besøgende. Det ændrer risikoprofilen fundamentalt. Når systemet ikke gemmer persondata om kunderne, handler 2FA primært om at beskytte forretningsindsigter og systemintegritet — ikke om at forhindre lækage af følsomme personoplysninger.

Det gør ikke 2FA mindre vigtig. Aggregerede besøgstal, konverteringsrater og bemandingsdata er konkurrencefølsomme, og en kompromitteret administratorkonto kan manipulere de tal, jeres bemanding og lejeforhandlinger bygger på.

Hosted eller privat cloud — påvirker det 2FA-kravene?

Ja, men mest på ansvarsfordelingen. I en hosted (multi-tenant) opsætning administrerer leverandøren autentificeringsinfrastrukturen, og I konfigurerer politikken. I en privat cloud har I flere muligheder for at håndhæve egne krav — for eksempel at binde adgang til bestemte IP-intervaller eller integrere med interne identitetssystemer bag jeres firewall. Vemco tilbyder begge modeller og kan integreres med jeres eksisterende IT-systemer, hvilket betyder, at 2FA-politikken kan følge jeres etablerede standard i stedet for at introducere endnu et separat regelsæt. For enterprise-buyers er spørgsmålet ikke "har I 2FA", men "hvem ejer nøglerne, og hvor ligger de".

Hvilke autentificeringsmetoder bør vi kræve?

Ikke alle andenfaktorer er lige stærke. Prioriteringen bør se således ud:

• Hardware-tokens (FIDO2/WebAuthn): Stærkeste beskyttelse mod phishing. Anbefales til administratorkonti.
• Authenticator-apps (TOTP): God balance mellem sikkerhed og brugervenlighed for den brede medarbejdergruppe.
• Push-notifikationer: Bekvemme, men sårbare over for "MFA fatigue"-angreb, hvor brugeren godkender ved en fejl.
• SMS-koder: Bedre end ingenting, men sårbare over for SIM-swapping. Undgå til privilegerede konti.

Hvordan logger vi adgangsforsøg til revision?

En revisor vil bede om en tydelig audit-log: hvem loggede ind, hvornår, fra hvilken IP, og hvilke handlinger blev udført. Bed om at kunne eksportere disse logs til jeres eget SIEM-system, så de ikke kun findes i leverandørens portal. Uden det bliver hændelsesundersøgelser afhængige af support-tickets, og det er hverken hurtigt eller dokumenterbart. Sørg også for at få klarhed over opbevaringsperioden for logs — kort opbevaring kan gøre det umuligt at efterforske et brud, der først opdages måneder senere.

Hvad med selve nøjagtigheden af de data, vi beskytter?

Sikkerhed uden datakvalitet giver beskyttede, men ubrugelige tal. Det er værd at forstå, hvad man faktisk sikrer. Vemcos personoptælling har en kontraktlig minimumsnøjagtighed på 96 %, og under normale forhold ligger den typisk på 98–99 %, når lysforhold, butiksindretning og besøgsadfærd tillader det. Det er den slags præcision, der gør besøgsdata pålidelige nok til at træffe beslutninger om bemanding og lejevilkår — og præcis derfor er de værd at beskytte med ordentlig adgangskontrol.

Hvad bør vi spørge leverandøren om, inden vi køber?

• Understøttes SSO via SAML eller OIDC, og er automatisk deprovisionering inkluderet?
• Kan 2FA gøres obligatorisk på organisationsniveau — ikke kun valgfrit per bruger?
• Er API-adgangen også beskyttet, og hvordan roteres nøgler?
• Hvor ligger data, og hvad er opbevaringsperioden for både data og audit-logs?