Designdokument eValg 3

Detaljert og teknisk oversikt over løsningen eValg - elektronisk valg for universitet og høgskoler, versjon 3.0.

Innholdsfortegnelse

1 Innledning

eValg er et administrativt IT-system som skal gjøre det trygt og enkelt å gjennomføre valg på universitet og høgskoler. Dette styrker både integriteten, anonymiteten og ressursbruken i gjennomføring av valg, sammenlignet med papirstemmer. Merk at eValg bare håndterer en del av valgprosessen: gjennomføring av stemmeperioden og opptelling av valget.

Løsningen har et nettbasert grensesnitt for velgerne og valgadministratorene, med en tilhørende backend med API. Pålogging gjøres med Feide (tidligere kalt Dataporten), som også brukes for tilgangstyring av API.

Funksjonalitet som eValg støtter:

  • Valgstyrer kan selv opprette og redigere valg, av ulike valgtyper.
  • Velgere kan avgi sin stemmeseddel.
  • Valgstyrer kan behandle stemmer fra personer utenfor manntall.
  • Valgstyrer kan telle opp valget, og få ut valgprotokoll.
  • Alle stemmesedler blir kryptert så bare valgstyret har tilgang til anonymiserte stemmesedler.
  • Løsningen støtter ulike valgtyper, som flertallsvalg og preferansevalg.
  • Løsningen støtter mange av UH-sektoren sine valgreglement.

Se mer om eValg i BNT sin applikasjonsoversikt.

Kontaktpunkt

Primært kontaktpunkt for eValg-løsningen er evalg-kontakt@usit.uio.no. For spørsmål relatert til valgprosessen: valgsekreteriatet@admin.uio.no.

USIT, ved seksjon Integrasjoner og elektroniske identiteter (INT), er systemeier for eValg, mens Avdeling for personalstøtte (AP) er prosesseier for den overordna valgprosessen ved UiO. AP tar seg av valgtekniske spørsmål, for eksempel avklaringer rundt valgreglementet, mens USIT svarer på spørsmål knyttet til eValg, for eksempel brukerstøtte rundt pålogging.

Kontaktveileder for eValg

2 Redegjørelse

eValg er modellert etter UiO sitt valgreglement, som er basert på Universitets- og høgskolelova. Hvert universitet har sitt eget valgreglement, som også setter føringer for løsningen.

Bakgrunn

I 2006 (etter sterkt påtrykk fra studentene) besluttet Universitetsstyret at man skulle implementere elektronisk valg ved UiO. Tidligere var valgene arrangert som urnevalg for studenter, eller som postvalg for ansatte. For studentene var avkryssing i manntallet ekvivalent med å få et kryss på semesterkortet, noe som ikke sikrer mot å kunne stemme flere ganger. Ansatte ville putte stemmeseddel i en konvolutt og sende den i internposten. Løsningen med elektronisk valg økte derfor sikkerheten i valget (gitt at velgerne ikke påvirkes av frykt for elektroniske løsninger).

Opptelling av papirstemmer er noe som tar tid – spesielt når man har et komplisert opptellingsreglement, som preferansevalget vårt (single transferable vote/STV) er. Adskillige opptellingstimer er spart.

Versjon 1 ble laget i 2006 av Rune Frøysa. Robert Bauck Hamar tok over stort sett all utvikling av prosjektet, og gikk mot versjon 2, som hadde mer modularisert kode og er brukt av flere i UH-sektoren. Ny løsning, versjon 3, ble utviklet fra 2017 - 2019, og var en total omskriving, der interaksjonsdesignere har sett på hele prosessen på nytt, og gjort tjenesten enklere og mer selvbetjent.

Begrep

eValg skal generelt bruke samme begrepene som brukes i valgreglementet.

Noen egne begreper som brukes i eValg:

  • Manntall: Samlingen av personer som har stemmerett til et valg. Å være i manntallet betyr at du oppfyller kravene for å for eksempel være fast vitenskapelig ansatt på tidspunktet som valget pågår. Valgreglementet setter kravene for stemmerett. Merk at personer ikke alltid er registrert riktig i HR-systemene, og vil derfor ikke være i det registrerte manntallet i eValg, selv om de oppfyller kravene - valgstyret vurderer hvert enkelt slikt tilfelle og legger eventuelt personen inn i manntallet i eValg.
  • Oppmøtetall: Antall stemmeberettigede som har stemt i en velgergruppe, enten i absolutt tall eller som prosent av antal stemmeberettigede totalt i stemmerettsgruppa.
  • Publisering: Å publisere et valg betyr å gjøre det synlig for velgerne. Valg som opprettes i eValg er i utgangspunktet skjult. Se mer detaljer i avsnittet Valgstatuser. Alle kan opprette valg, men å publisere valg krever en egen rettigheter. Se mer under avsnittet Tilganger.
  • Registrert manntal: Listen over forhåndsgodkjente personer som har stemmerett i et valg. Listen ligger i eValg. HR gir ikke alltid helt korrekte manntall, så det er som oftest flere i manntallet enn de som er i det registrerte manntallet. Valgstyret må vurdere alle stemmer fra personer som ikke er med i det registrerte manntallet, i tilfelle de er med i manntallet, og bør bli lagt med i det registrerte manntallet.
  • Sentralt Valgsekretariat: Sekretariat underlagt Sentralt Valgstyre, og som svarer til Universitetsdirektøren. Prosesseier er med i valgsekretariatet. Se valgreglementet §3.
  • Sentralt Valgstyre: UiO sitt øverste organ for valg, som svarer til Universitetsstyret. Se valgreglementet §3 Valgstyrer for hva de er ansvarlige for.
  • Stemmerett: En person som oppfyller kravene til å få sin stemmeseddel talt med i et valg. Valgreglementet spesifiserer kravene for å ha stemmerett for de ulike stemmerettsgruppene. Personer med stemmerett legges i manntallet til valget.
  • Stemmerettsgruppe: Gruppering av personer som utfra valgreglementet telles opp hver for seg. Per i dag er dette fast vitenskapelig tilsatte (FVA), midlertidig vitenskapelig tilsatte (MVA), teknisk og administrative tilsatte (TA) og studenter. Valgreglementet setter føringer for hvordan eValg skal forholde set til stemmerettsgruppene.
  • Styrevalg: Valg av medlemmer til et styre, for eksempel universitets-, fakultets- og instituttstyret. Felles for disse valgene er at hver stemmerettsgruppe velger sine styremedlemmer.
  • Styreledervalg: Valg av leder av en enhet, for eksempel rektor/rektorat (rektor og prorektor), dekan/dekanat (dekan og prodekan) og instituttleder. Felles for disse valgene er at stemmerettsgruppene stemmer på samme kandidatene, men med ulik vekting.
  • Valgadministrator: Brukerkontoen som oppretter og administrerer et valg i eValg. Enheter kaller gjerne denne personen for valgsekretær, siden personen administrerer valget på vegne av valgstyret. Se mer detaljer under avsnittet Roller.
  • Valgansvarlig: Løst begrep for alle som er ansvarlig for et eller flere valg, uavhengig av om de har tilganger i eValg. Brukes gjerne om hvert fakultet sin overordnet ansvarlig for alle valg på fakultetet.
  • Valgarrangør: Samlebegrep for de som er ansvarlige for å gjennomføre et valg - ofte en enhet. Brukes gjerne likt som Valgansvarlig.
  • Valggruppe: En gruppering av flere valg for det samme styret, for forskjellige stemmerettsgrupper.
  • Valgsekretariat: Sekretariatet for et eller flere valgstyre. Noen enheter har et fast sekretariat som tar seg av det meste praktiske, inkludert endringer i eValg, mens valgstyret beslutter. Hos andre enheter er det noen i valgstyret som selv tar seg av det praktiske, og har da ikke et eget sekretariat.
  • Valgsekretær: Noen som tar seg av mye av det praktiske i gjennomføringen av et eller flere valg. Se Valgsekretariat, og Valgadministrator.
  • Valgstyre: De som er ansvarlig for et valg, både i gjennomføring og å beslutte at det har gått riktig for seg. Minst en person i valgstyret, eller valgsekretariatet, må være valgadministrator for valget.

Krav/føringer

I tillegg til lovverk rundt blant annet GDPR og universell utforming, må eValg også oppfylle:

  • eValg må følge valgreglementet. Ved behov for endringer i valgreglementet må det tas opp med Sentralt Valgstyre.
  • Stemmesedler kan potensielt avsløre politisk oppfatning eller fagforeningsmedlemskap, som er definert som særlige kategorier av personopplysninger (sensitive personopplysninger). Vi er derfor lovpålagt å beskytte stemmesedlene med særskilte tiltak. eValg bruker asymmetrisk kryptering av stemmesedlene, så de bare er tilgjengelige for valgstyret. Se mer detaljer under avsnittet Kryptering.

eValg er også gitt noen føringer:

  • Valgstyret for et gitt valg er ansvarlige og bestemmer over valget, ikke eValg. eValg skal hjelpe valgstyret med å gjennomføre valg riktig, ikke overstyre. Vi stoler på at valgstyret har kontroll på det de gjør, og har gode begrunnelser for endringer. Dette betyr at valgstyret må ha mulighet til å gjøre hva de vil med valget, så lenge det ikke er tekniske begrensinger og det bryter med formålet med valgreglementet. I verste fall kan valgstyret eskalere problemstillinger helt opp til Sentralt Valgstyre, som er overordnet ansvarlig for alle universitetsvalg på UiO. Se eksempler i avsnittet Endringer på valg.
  • Alle som har en brukerkonto (Feide-pålogging) skal kunne stemme i alle pågående valg, selv om de ikke er med i manntallet. Valgstyret må i etterkant vurdere om velgeren likevel burde vært med i manntallet. Dette sikrer at alle får stemt selv om det skulle være feil i manntall.
  • eValg skal være mest mulig selvbetjent, for å skalere. Dette betyr at løsningen må være enkel å bruke - eValg skal hjelpe valgadministrarorer med å gjennomføre valg.
  • Valgprosessen skal være mest mulig etterrettelig. Det må være mulig å etterprøve gjennomføringen av valg i eValg, både gjennom valgprotokoll og stemmesedler. I eValg er dette løst:
    • Alle endringer relatert til et valg blir logget, inkludert hvem som har gjort det. Historikken er tilgjengelig for valgstyret. (Per 01.08.2020 er ikke uthentingen implementert, så audit logg er tilgjengelig ved henvendelse til evalg-kontakt@usit.uio.no).
    • Valgadministrator kan laste ned de anonymiserte stemmesedlene fra valget, for å kunne telle opp for hånd.
    • eValg tilbyr nedlastbar valgprotokoll som beskriver hele opptellingsprosessen, inkludert loddtrekninger.
    • eValg er fri programvare.
  • eValg skal kunne brukes av hele UH-sektoren, med mindre tilpasninger. Det betyr at eValg blant annet støtter ulik theming.

Valgprosessen

eValg håndterer bare en del av valgprosessen - valgstyret tar seg av forberedelse og etterarbeid etter stemmeperioden. Se mer detaljer på sidene Arrangere valg.

Bilde av overordna valgprosess, fra valgstyret beslutter at valg skal gjennomføres, til valget er gjennomført og publisert. Se detaljer i beskrivelse lenger nede.
Overordna og ideell valgprosess. Mørkeblå bokser markerer hva eValg gjør.

Overordna og forenkla valgprosess:

  1. De som er ansvarlige for valget beslutter gjennomføring og setter valgstyret.
  2. Valgstyret forbereder valget. Informerer, setter tidspunkt og samler kandidater. For innsamling av kandidater anbefales det å bruke nettskjema.
  3. eValg: Noen fra valgstyret, en valgadministrator, oppretter valget i eValg, og legger inn relevante detaljer, som tidspunkt, kandidater og manntall. Manntallet skaffes fra HR/FS. Valgadministratoren kan gi resten av valgstyret tilgang til valget.
    • eValg har noen predefinerte typer valg, som er snarveier for riktig oppsett av typiske valg. Denne listen utvides etterhvert som det dukker opp behov for nye valgtyper.
  4. eValg: Valgadministratoren får generert en valgnøkkel og publiserer valget i eValg. Valgnøkkelen må lagres trygt og bare være tilgjengelig for valgstyret.
  5. eValg: eValg åpner for stemmegivning på satt tidspunkt.
  6. Valgstyret informerer manntallet om at stemmeperioden har startet. eValg gjør ikke dette.
  7. eValg: Velgere avgir sin stemme i eValg.
  8. eValg: Valgstyret sjekker valgoppslutning i eValg fortløpende, og kan behandle stemmer utenfor manntallet etterhvert som stemmene kommer inn.
  9. eValg: eValg stenger valget på satt tidspunkt.
  10. eValg: Valgstyret behandler stemmer utenfor manntallet. Dette gjøres i dialog med HR-personell som slår opp i HR og FS for å se om velger oppfyller kriteriene for stemmerett.
  11. eValg: Valgadministrator starter opptellingen ved å laste inn valgnøkkelen.
  12. eValg: eValg gir ut valgresultat og valgprotokoll. Valgstyret har også mulighet til å hente ut anonymiserte stemmesedler og historikken til valget.
  13. Valgstyret godkjenner om valget er riktig gjennomført og gyldig.
  14. Valgstyret kontakter kandidatene, før de publiserer valgresultatet. eValg gjør ikke dette.
  15. Valgstyret arkiverer valgprotokollen. eValg er ikke et arkivsystem.
  16. Klagefrist starter.
  17. Etter klagefrist kan valgstyret be om at valget slette valget fra eValg.

Forenklinger i valgprosess

Det er gjort noen forenklinger i valgprosessen, både for å gjøre prosessen enklere for valgadministratorer, og for å redusere kompleksiteten i løsningen:

  • Valg av styremedlemmer for ulike velgergrupper, i samme styre, er egentlig uavhengige valg. eValg legger opp til å behandle disse sammen, i en valggruppe. For velgerne dukker alle valgene i valggruppen opp som én oppføring, der velgeren kan velge stemmerettsgruppe.
  • I opprettingen av valg trenger valgadministrator oppgi typen valg, så setter eValg opp valget med de riktige innstillingene.
  • Navn på valg genereres basert på hvilke enhet valgadministratoren registrerer ved oppretting. Dette reduserer faren for skrivefeil.
  • Enheten som et valg registreres for brukes ikke til noe annet enn til å generere navn på valget. Det kan hende det dukker opp behov ved en framtidig integrasjon for HR-data.
  • Tilgangsrettighetene er sterkt forenklet, og distribuert, da INT ikke har registrert noen krav rundt mer granulering. Personer har enten full eller ingen tilgang til å administrere et valg, og kan selv dele ut tilgang til valget. Unntaket er rettigheten til å publisere (gjøre valget synlig for velgerne), som er begrenset til spesielt utvalgte fra fakultetene.
  • Alle som kan logge på kan opprette og administrere egne valg. Dette forenkler kursing og opplæring av valgadministratorer. Å publisere valg, så de er synlige for velgerne, krever egne rettigheter - se avsnittet Tilganger.
  • Manntallsfiler fra SAP må gjennom et makroregneark som kategoriserer personer. Å lese inn dette regnearket i eValg har blitt vurdert som for risikabelt (for eksempel at valgsekretær gjør manuelle endringer i regnearket, som kan føre til innlessing av feil data). Valgadministratorer må derfor selv eksportere personene som skal lastes inn i eValg. Dette blir et ekstra, teknisk steg for valgadministratorene. Tanken er å senere integrere med API fra FS og HR.
  • Å stemme på vegne av andre må støttes, men det skjer veldig sjelden. Dette er derfor ikke implementert i grensesnittet, men gjøres manuelt av drift/utvikling. INT har fått aksept for dette av Sentralt Valgsekretariat.

Valgstatuser

Hvilke tilstander kan valg ha i eValg:

  1. Utkast - Alle valg starter som utkast. Valget er ikke synlig, og de fleste detaljer kan endres.
  2. Klart - Valget er publisert, og vil starte ved satt tidspunkt. Enkelte detaljer i valget kan ikke endres når valget er publisert.
  3. Pågår - Valget er publisert og tidspunkt for valgstart er passert. Velgere kan stemme i valget.
  4. Stengt - Valget er publisert og har passert tidspunkt for stemmeperioden. Opptelling kan starte, så lenge stemmer utenfor manntal er behandlet.

Vanlig prosess er at valgadministrator oppretter valget, og redigerer det etterhvert som detaljer som tidspunkt og kandidater kommer på plass. Valgadministrator publiserer valget når alt er avklart og stemmeperioden nærmer seg - valget går fra Utkast til Klart, og deretter til Pågår når stemmeperioden starter. Etter stemmeperioden er valget klart for opptelling - valget får status Stengt.

Valgadministator har alltids muligheten til å avpublisere valget, som setter det tilbake til Utkast. Dette kan være nødvendig hvis valgstyret må gjøre ekstraordinære endringer på valget.

Endringer på valg

Valgstyret har ansvaret for sitt valg, og skal derfor få lov til å endre det meste som er teknisk mulig å endre. Vi går ut i fra at valgstyret vet hva de gjør, og har gode grunner for å gjøre endringene de gjør med valget.

Det er likevel noen begrensinger på hva du kan endre, spesielt for publiserte valg og valg som har vært publisert:

  • Valgstyret kan ikke legge til eller fjerne kandidater fra valg som det har blitt stemt i. Dette er av tekniske årsaker - personer vil potensielt kunne ha stemt på en kandidat som blir fjernet, og utseendet på stemmeseddel og opptellingen fungerer annerledes avhengig av om det er to eller flere kandidater. Likevel: Hvis ingen har stemt i valget kan valgadministrator avpublisere valget og endre kandidatene.
  • Valgnøkkel kan ikke byttes etter at første stemme er avgitt. Stemmesedler kan bare låses opp av den eksisterende valgnøkkelen, så å bytte valgnøkkel vil gjøre at allerede avgitte stemmesedler blir utilgjengelige. Hvis valgstyret har mistet sin valgnøkkel har vi en plan B, se mer detaljer under Kryptering.

    Presisering av noen tillatte endringer, som valgstyret må håndtere konsekvensene av:

    • Navn på valget.
    • Informasjon til velgerne, som mandatperiode, kontaktpunkt og lenker til valginformasjon.
    • Administrative roller, for eksempel hvis noen i valgstyret må byttes ut.
    • Start og slutt på stemmeperioden. Eksempler på når dette trengs:
      • Noen i manntallet har ikke blitt informert om valget, og trenger mer tid. Stemmeperioden må forlenges.
      • Det mangler kandidater, så stemmeperioden må utsettes. Startdato utsettes.
    • Navn på kandidater. Eksempelet er enkle skrivefeil i navn. Valgstyret avgjør om skrivefeil er så alvorlige at de må gjennomføre et nytt valg. Loggen til valget skal også sikre at ikke noen har for eksempel byttet navn på kandidater.
    • Legge til personer i manntall.
    • Fjerne personer fra manntall. Fjerning av personer som har stemt fra manntallet er ikke implementert i grensesnittet, og må gjøres manuelt av drift/utvikling.

    Alle endringer på valget logges, og er tilgjengelig for valgadministratorene for valget.

    Brukerroller

    Applikasjonen sine primære brukerroller, definert utfrå Scrum og «suksess for produktet»:

    • Velgar-rolla [ODT] (alle som vil/kan avgje stemme)
      • Funksjonsnedsett velgar
      • Velgar utanfor eller i feil manntal
    • Valarrangør-rolla [ODT] (alle som (med)arrangerer eit val)
      • Valadmin/valadministrator (full tilgang til eit val). Er dei som gjennomfører endringane i eValg, enten ved å være i et valgstyre eller valgsekretariat. Kalles gjerne også valgsekretær.
      • Stemmerevisor (begrensa tilgang til å vurdere om stemmesedlar er gyldige - manntal)
      • På-vegne-av-operatør (tilgang til å legge inn papirstemmer på vegne av andre)
    • Kontrollør-rolla [ODT] (alle som vil sjekke at løysing/val er etterretteleg/truverdig)
      • Intern kontrollør (med taushetsplikt)
      • Ekstern kontrollør (inkludert presse, myndigheter, men også privatpersonar)
    • Kunde-rolla (alle som har føringar for løysinga)
      • Sentralt Valstyre
      • Sentralt Valsekretariat
      • Prosesseier - Avdeling for Personalstøtte
      • Studentparlamentet
      • UH-kunde

    Se også referat fra workshop rundt eValg-roller, del 1 og workshop rundt eValg-roller, del 2.

    Tilganger

    Det er flere nivå av rettigheter i eValg:

    • Alle med Feide-pålogging kan stemme i alle pågående valg. Det er opp til valgstyret å avgjøre om stemmeseddelen skal telle med eller ikke.
    • Alle med Feide-pålogging kan opprette valg, men de vil ikke være synlige for andre enn seg selv. De blir da valgadministrator for valget, og kan gi andre tilgang til valget.
    • Publisister har tilgang til å publisere valg de er valgadministrator for. Dette gjør valget synlig for velgere. Dette styres via grupper i Cerebrum, som forvaltes av fakultetene.
    • Valgsekretariatet skal ha tilgang til å administrere alle valg. Valgsekretariatet forvalter selv hvem som har denne rettigheten. (Merk: Dette er ikke blitt implementert i første versjon av eValg3, så valgsekretariatet må enn så lenge bli gitt tilgang til valget av valgadministratorene.)

    Se dokumentet forvaltning av valadministrarorar for mer detaljer, samt brukerhåndtering i eValg.

    Mangler

    Innlasting av manntall er i dag en manuell prosess. Valgstyret får HR-personell til å hente ut lister fra HR/FS, i en excel-fil. Filen behandles gjennom et makroregneark, og eksporteres til noe som lastes inn i eValg. Risikoene med denne prosessen er at det er stor fare for å gjøre feil, i tillegg til at personopplysninger kan lett komme på avveie når filer må behandles og overføres manuelt. Det er ønskelig med en integrasjon med HR-systemer for manntallslister.

    Det har også blitt vurdert om filene som leveres fra eValg bør signeres av eValg, for å sikre etterretteligheten.

    Se også restanselisten fra eValg 3.0, for etterspurt funksjonalitet som ikke har blitt prioritert.

    Vektede stemmer er i datamodellen angitt med et tall. Det finnes andre mer kompliserte vektingsregler som ikke er mulig:

    • Institusjon X er spredd over flere steder (fusjon av to høyskoler, f.eks.)
    • De ønsker vekting ikke bare basert på kategori, men også en overordnet vekting av stedene, slik at lillebror ikke blir overkjørt.

    Det har forekommet med flikking at noen har klart å slette kandidater, og opprettet på nytt med annen kandidatid etter at noen har stemt på kandidaten. I så måte burde det ikke slettes rader fra kandidattabellene.

    3 Detaljebeskrivelse

    Se INTs miljøoversikt for navn på maskiner og tilganger.

    Høynivådesign

    Forenkla systemoversikt

    Systembeskrivelse

    Tjenesten eValg består av:

    • Frontend er et nett-grensesnitt, utviklet i React, og snakker med backend via GraphQL-API.
    • Backend er en python-tjeneste med GraphQL-API. Denne bruker flask og nginx.
    • Databasen er postgres.
    • Feide brukes for pålogging. eValg bruker Feides OpenID connect-tjeneste, som også brukes for tilgangskontroll i API.
    • INT bruker en egen management server for å få tilgang til databasen og for feilsøking.
    • Persondata fra Cerebrum brukes bare for gammel løsning, eValg2. eValg3 trenger færre personopplysninger.

    Datamodell

    De fleste tabellene i databasen har egne tabeller for tidligere versjoner av endringer i tabellen. Dette sikrer at eValg har en audit-logg for alle endringer på valg, og kunne vise det for valgadministratorer. Dette er et tiltak for å gjøre eValg mest mulig etterrettelig. Pakken SQLAlchemy-Continuum brukes for dette formålet.

    Merk: Databasen inneholder bare stemmesedler i kryptert form. Dette fordi det bare er valgstyret som skal kunne ha tilgang til dette, også ved datainnbrudd i løsningen.

    Kryptering

    eValg har krav om ekstra beskyttelse av stemmesedler. Dette har vi valgt å løse med asymmetrisk kryptering av stemmesedlene. Tidligere versjoner av eValg brukte PGP-nøkler for krypteringen, som viste seg å være for komplisert for valgadministratorer. eValg3 har derfor forenklet dette til at valgstyret må forholde seg til en enkel fil, behandle den som et passord, og laste den opp i eValg ved opptellingen.

    Krypteringen består av:

    • En offentlig nøkkel. Denne brukes av eValg for å kryptere stemmesedler straks de blir avgitt. Hvert valg (valggruppe) har sin egen nøkkel.
    • En privat nøkkel, som kan dekryptere stemmesedlene i valget. Dette er valgnøkkelen, som bare valgstyret skal ha tilgang til. Hvert valg (valggruppe) har sin egen valgnøkkel.
    • Sentralt Valgsekretariat sin mesternøkkel, som brukes i tilfeller der et valgstyre har mistet sin valgnøkkel. eValg har tilgang til den offentlige mesternøkkelen, som brukes til å lagre en kryptert kopi av hver valgnøkkel. Det er bare Sentralt Valgsekretariar som har tilgang til den private mesternøkkelen, og kan hente ut alle valgnøkler. Se rutine ved tap av valnøkkel. En slik mesternøkkel fungerer per eValg-instans, så hver enkelt institusjon får opprettet sin egen mesternøkkel. En eValg-instans kan ha ingen, en, eller mange mesternøkler i aktiv bruk.

    Stegene relatert til kryptering:

    1. Når valgadministrator skal publisere valget blir en valgnøkkel generert. Denne blir generert i valgadministratoren sin nettleser, og kan lastes ned som en fil. Nettleseren sender den offentlige nøkkelen til eValg, men ikke selve valgnøkkelen.
    2. Når en velger avgir sin stemmeseddel vil eValg kryptere stemmeseddelen før den lagres i databasen. eValg har etter dette ikke tilgang til å se hva som ble stemt.
    3. Når valget er over og valgstyret skal telle opp valget, laster de inn valgnøkkelen i eValg. eValg dekrypterer stemmesedlene, men bryter koblingen til hvem som avga stemmeseddelen. Opptellingen baserer seg deretter på anonymiserte stemmesedler.

    Valgstyret har tilgang til å laste ned anonymiserte stemmesedler, for å kunne etterprøve at opptellingen har gått riktig for seg. De har likevel ikke mulighet til å etterprøve at stemmesedlene er riktige, men må stole på at eValg har lagret velgernes stemmer korrekt.

    En ulempe med hvordan krypteringen er løst, er at eValg får tilgang til valgnøkkelen i øyeblikket det telles opp. Sikkerhetsmessig burde derfor opptellingen skjedd utenfor eValg, men dette går på bekostning av brukervennligheten. Vi har valgt et kompromiss, der dekryptering og opptelling skjer i backend og ikke lokalt hos valgstyret. I eValg2 var opptellingen i en egen java-applikasjon, utenfor løsningen, men dette ble oppfattet som for vanskelig for valgadministratorene.

    Se utviklerdokumentet Kryptering av stemmesedler for tekniske detaljer om krypteringen.

    Skille institusjoner

    For å sikre isolering av data fra ulike institusjoner, har en i eValg3 gått bort fra muligheten av å ha flere institusjoner i samme instans.

    For hver institusjon kjører vi en egen instans med egen database.

    Lavnivådesign

    Mer detaljert design informasjon finnes i dokumentasjons-repoet.

    4 Avhengigheter

    Tjenesten bruker Feide sin OpenID connect-tjeneste (tidligere kalt Dataporten) for pålogging og kommunikasjon mellom frontend og backend.

    Tjenesten kjører på www-drift sitt web-hotell.

    Pakking og bygging av nye versjoner er avhengig av USIT sitt byggesystem Jenkins og docker repository Harbor.

    Zabbix for overvåking av tjenesten. eValg genererer helsefiler som leses av Zabbix, som varsler w3d og INT ved mistanke om problemer. INT får også oppdaterte feil og tracebacks i sin lokale Sentry-instans, både for backend og frontend.

    Databasen er i postgres, som driftes av database-drift på USIT.

    Manntallslister blir hentet fra SAP og FS, i dag via manuelle prosesser.

    Organisasjonsenheter blir hentet regelmessig fra SAP-WS. Midlertidig mangel på tilgang vil bare føre til at endringer i enheter ikke kommer med.

    Lenker og referanser

    Publisert 8. mai 2019 12:13 - Sist endret 21. nov. 2024 00:29