Geminus 2FA Teknisk overblik

Teknisk overblik

Som forklaret i den generelle beskrivelse har Geminus 2FA både en frontend til selvbetjening og en backend til at validere LDAP(S)/TOTP -login fra tilknyttede services. Frontenden kører en Django/Python-applikation og er den eneste server der er eksponeret for slutbrugeren og det net som den tilgås fra.

Geminus 2FA kan opsummeres til fire hovedkomponenter:

1. Databasen, som indeholder mapping mellem brugernavne og TOTP hemmeligheder mm. Databaseserveren er PostgreSQL
2. TOTP Frontend, en Django/Python-applikation som præsenterer en hjemmeside hvor brugere kan onboarde sig og/eller nulstille hemmeligheden i deres TOTP apps
3. Administrationsserveren, en Django/Python-applikation som udstiller en række API-adgange via REST/HTTP til administration af løsningen
4. Et antal RADIUS-servere som kører FreeRADIUS, og hver en lokal PostgreSQL server med en realtidsreplikeret kopi af hoveddatabasen

Onboarding

Ved onboarding af en ny bruger skal denne besøge Python/Django-applikationens webside, der kører på frontend-serveren. Denne server kan vi betegne som onboarding-01. På siden der forvaltes af onboarding-01 har brugeren mulighed for at logge ind med f.eks. LDAP(S) for at generere et nyt link, eller autentifikere sig med et klient-certifikat. Hvis brugeren logger ind med LDAP(S) tilsendes et unikt link til brugerens mail. Det unikke link præsenterer en webside med en QR-kode, som brugeren kan scanne med sin mobilapp/kodegenerator. Hvis Geminus 2FA er sat til at benytte klient-certifikater som autentifikationsmodel vil brugeren allerede være præsenteret for en QR-kode ved første besøg. Når QR-koden er scannet skal brugeren indtaste det nyligst genererede TOTP, for at verificere, at den korrekte hemmelighed er delt mellem klient (f.eks. mobilapp) og Geminus 2FA. Såfremt koden er korrekt, vil onboarding-01 sørge for, at den primære database-server, som vi kan kalde database-01, tilføjer den nye bruger og respektive hemmelighed i PostgreSQL-databasen.

Administration

Udover den brugervendte webserver på onboarding-01, er der en anden webserver. Denne er på administrationsserveren, som vi kan vi kalde for for administration-01. Serveren administration-01 udstiller et REST/HTTP API, der giver mulighed for at administratorer og driftsansvarlige kan administrere Geminus 2FA-løsningen. Her kan f.eks. slettes brugere, oprettes nye brugere til provisionering af præprogrammerede kodevisere, migreres databaser eller lave udtræk over allerede provisionerede brugere.

Autentifikation

Til sidst bruger Geminus 2FA minimum en RADIUS-node, som kører FreeRADIUS. I eksemplet nedenfor bruger vi to, som vi kalder radius-01 og radius-02. Begge disse noder er sekundære databaser og har read-only replikering i realtid af database-01. Det er disse servere der autentificeres mod når en bruger logger ind gennem en service der benytter Geminus 2FA-løsningen som authorization-endpoint. RADIUS-noderne foretager loginvalidering med LDAP mod AD og de to RADIUS-noder har til formål at give redundans i tilfælde af, at den ene går ned. Read-only replikering følger princippet om least privilege og har desuden til formål at undgå, at fejl på RADIUS-noderne resulterer i tab af hele databasen. På alle database-servere (RADIUS-noder samt primære database) kan der foretages en daglig backup til en fil i SQL-format, og både RADIUS-noderne og TOTP Frontend foretager SIEM-logging af alle relevante events (login, reset/provisionering, brugertilgang til onboarding-01).

En tegning over systemet er vist i figuren nedenfor:

Figur 1 - Geminus 2FA's komponenter og hvordan de kommunikerer

Sikkerhed

Alle PostgreSQL-forbindelser i løsningen er TLS-krypterede. Der anvendes klient- og server-certifikater til autentikering, som udstedes af en lokal CA på administration-01. Alle servere i løsningen administreres i øvrigt via Ansible fra administration-01. Den interne webserver på administration-01 udstiller et begrænset API, og der kræves en unik HTTP-header-baseret nøgle for hver af de forskellige adgange. API’er kan slås til/fra enkeltvis og disse tilgås over TLS-krypteret HTTP-trafik.

Som nævnt bygger Geminus 2FA på internetstandarden RFC 6238. RFC 6238 er en internationalt anerkendt og bredt anvendt standard for multifaktor-autentifikation. RFC 6238 er baseret på kryptografisk hashing med en delt hemmelighed, der er kendt af brugerens klient (mobilapp/kode-viser) og serveren.

Frontend-serveren onboarding-01 har udelukkende rettigheder til, at overskrive brugerens hemmelighed i databasen og kan altså intet udlæse derfra. Dette er et bevidst design, med det formål at begrænse skadeomfang i tilfælde af, at onboarding-01 kompromitteres. Denne er nemlig den ene brugereksponerede server. På onboarding-01, hvor de delte hemmeligheder genereres og provisioneres via en QR-kode, gemmes hemmeligheden kun i hukommelsen og ikke på disken. Efter lagring på database-01 slettes den fra onboarding-01's hukommelse.

Administration foregår med krypterede SSH-forbindelser. Disse autentikeres med klient- og server-certifikater til og selve konfiguration af løsningen foretages ved ændringer en Ansible ”inventory”-fil på administration-01. I inventory-filen indstilles f.eks. hvilke AD-servere der skal foretages LDAP(S)-validering mod. Det er også her API'erne kan slås til/fra og nøglerne dertil bestemmes. Her indstilles også de delte adgangsnøgler til brug mellem RADIUS-klienter/servere.

Er du nysgerrig på hvordan Geminus 2FA kan bruges i jeres virksomhed? Kontakt os for en uforpligtende snak om mulighederne med Geminus 2FA.

Læs også den generelle beskrivelse af Geminus 2FA.