Saksinformasjon kryptert.
Serveren i Docker.
Pilot 1.8 legger til kryptert saksnavn og beskrivelse, en streng Linux-minneprofil og Docker-oppsett. En egen sentral servermodus er implementert. Ansatte bruker nettleseren, deler dokumenter i tildelte saker og får enten leser- eller redaktørtilgang. Det er et konkret steg mot bedriftsdrift; den komplette kundeleveransen er fortsatt ikke godkjent.
Dette følger med.
| Område | Hva som finnes | Hva som gjenstår |
|---|---|---|
| Sentral server | Egen Linux-servermodus, opptil 16 samtidige forespørsler og separate databaseforbindelser. | Lasttest med faktisk modell/OCR, driftsoppfølging og høytilgjengelighet. |
| Delte saker | Eksplisitt tilgangsliste. Leser kan undersøke; redaktør kan lagre og slette. Andre saker avvises. | Administrasjonsgrensesnitt og integrasjon med bedriftens tilgangsforvaltning. |
| Innlogging | Gateway-grense med kontrollert identitet, separat hemmelighet og eksakt HTTPS Origin. OIDC/proxy-maler følger med. | Faktisk Entra eller lokal IdP, påkrevd MFA og testet HTTPS-kjede. BankID er ikke integrert. |
| Lagring | Krypterte saksnavn, beskrivelser, titler, dokumenttekst og hendelsestekst. Nøkkelbasert pseudonymisering av bruker-/saks-ID-er i serverdatabasen. | Nøkkelforvaltning/rotasjon, serverbackup/restore og uavhengig sikkerhetstest. |
| Installasjon | Ansatte trenger ingen Python-installasjon i servermodus. Dockerfile, Compose, konfigurasjonsgenerering og oppstartsskript er inkludert. Python ligger i appimaget. | Ferdig bygget, signert og testet serverimage. Docker kan ikke kjøres i dette utviklingsmiljøet. Windows/Mac-appene er fortsatt ikke ferdige. |
85 automatiserte tester består.
De nye testene bruker faktisk lokal HTTP og undersøker delte saker, rollegrenser, identitetskrav, feil origin, ciphertext-manipulering og 20 parallelle lagringer. Kryptert saksinformasjon, hendelsestekst og pseudonymiserte identifikatorer er kontrollert mot databasefilen. Backend avviser også tvetydige HTTP-felt og JSON med dupliserte nøkler. Minneprofilens feilavvisning er testet, og faktisk dump-sperre er kontrollert i en isolert Linux-prosess.
Identitetsheaderne simuleres i disse testene. Dette beviser ikke at Entra/MFA, Nginx, OAuth2 Proxy eller kundens nettverk er riktig konfigurert. De komponentene er ikke kjørt og verifisert her. Nettdemoen på denne nettsiden er fortsatt separat fra dokumentserveren.
Slik håndteres dataene.
Klartekst finnes i server, nettleser og modellmotor mens dokumenter behandles. Den kan ikke gjøres uleselig for prosessen som skal analysere den. Docker-profilen sperrer minnedumper, krever minnelås og nekter oppstart ved aktiv swap eller feilet minnelås. Nettleserarbeidsrommet ryddes ved inaktivitet. Sikret klientutstyr, krypterte disker/swap og OS-isolasjon må inngå i leveransen.
Entra krever ekstern kontakt for innlogging. Full frakoblet drift krever en lokal identitetstjeneste med MFA, lokal DNS og TLS. Vardnex sender ikke dokumentinnhold til identitetstjenesten gjennom denne integrasjonen.
Serverdatabasens tidspunkt, antall og struktur er fortsatt synlige. Pseudonymisering er ikke det samme som kryptering av hele databasen. Nøkkelforvaltning og uavhengig gjennomgang er nødvendige deler av et konkret kundeoppsett.
Dette må bli ferdig først.
Et lokalt testoppsett for modellvalg følger nå med: seks norske kontraktoppgaver med referansesvar, kildeutdrag og responstider. Qwen3-8B/32B, Mistral Small 3.2 24B og Llama 3.3 70B skal sammenlignes. Ingen av kandidatene er ferdig vurdert. Gyldige kilde-ID-er gir ingen automatisk godkjenning av juridisk kvalitet.
Faktisk lokal modellkjøring, reell SSO/MFA/TLS-integrasjon, plattformtesting på Windows og Mac, signerte installasjonspakker, faglig kvalitet, serverbackup og uavhengig sikkerhetsgjennomgang må gjennomføres. Pakken skal fortsatt bare testes med syntetiske data.
Til utviklingspakken