Det offentlige køber blandede sky-bolcher for milliardbeløb

Statens og Kommunernes Indkøbsservice har det helt store checkhæfte fremme, når der skal købes ASP og cloud-tjenester for op til 1,2 milliarder. Men det er ikke så nemt at finde ud af, hvad der konkret er på tegnebrættet.

Den første juli har Statens og Kommunernes Indkøbs Service (SKI) offentliggjort et udbud på mellem 800 millioner og 1,2 milliard.

»Udbuddet dækker løsninger i bred forstand, og vil stort set dække alle typer af offentlige fagsystemer ? herunder økonomi- og personalesystemer. SKI lægger op til et bredt udbud med mere end 50 leverandører for at fremme konkurrencen blandt de mange interesserede,« skriver SKI i sit månedlige nyhedsbrev.

»Det at gennemføre de lovpligtige udbud er en stor og kompleks opgave, som mange kommuner for tiden ikke har ressourcerne til. Sigtet med det kommende ASP/Cloud-udbud er primært at være kommunerne behjælpelige med at gennemføre udbud på deres mange it-systemer og sikre dem gennemsigtige priser og leveringsvilkår. Samtidig er der også lagt vægt på, at de nye løsninger kan integreres med eksisterende platforme«, udtaler direktør Søren Jakobsen til SKI's nyhedsbrev.

Det er ikke så nemt at komme tættere på, hvad der konkret vil blive udmøntet på baggrund af udbuddet.

Ifølge SKI skal rammeaftalen understøtte SKI's kunders behov for ASP (Application Service Provider) og Cloud baserede it-services, herunder drift, vedligehold og udvikling - som begge er computer-services og funktionalitet, der understøtter forretningsprocesser.

Version2 har henvendt sig til SKI for at få uddybet rammeaftalen. SKI's kommunikationsrådgiver Charlotte Balle har svaret i en e-mail.

**Hvilke ASP-opgaver og forretningsprocesser tænkes der på konkret?

»ASP løsninger er ofte løsninger, som har en høj grad af kundetilpasning og supplerende ydelser, ASP løsninger er tillige ofte løsninger, som har en dybere forretningslogik end Cloud.«

Hvilke cloud-tjenester og forretningsprocesser er der tænkt på konkret?

»SKI benytter i sit udbud en modificeret model af de to offentlige referencemodeller FORM og STORM. Gældende for både ASP og Cloud udbuddene, er, at leverandøren skal indplacere sin løsning og services efter disse to modeller. Det giver således mulighed for at leverandøren kan byde ind med en meget bred vifte af services,« siger Søren Bo Christiansen, SKI.

Hvilke sikkerhedsmæssige overvejelser er der bag udbuddet, specielt i forbindelse med cloud-services?

»De sikkerhedsmæssige udfordringer baseres på almen best practice. Det betyder, at den gældende nationale og EU lovgivning skal overholdes, og hele sikkerheden i øvrigt aftales mellem kunde og leverandør. Alle leverancer baseres på SKI leveringsaftaler og/eller standardbetingelser. Disse betingelser angiver bl.a. leverandørens forpligtigelser og kundens mulighed for indsigelser, audit og opsigelse, bl.a. i relation til sikkerhed,« siger Søren Bo Christiansen, SKI, som i øjeblikket er på ferie.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (12)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Anonym

"De sikkerhedsmæssige udfordringer er baseres på almen best practice. Det betyder, at den gældende nationale og EU lovgivning skal overholdes, og hele sikkerheden i øvrigt aftales mellem kunde og leverandør. Alle leverancer baseres på SKI leveringsaftaler og/eller standardbetingelser. Disse betingelser angiver bl.a. leverandørens forpligtigelser og kundens mulighed for indsigelser, audit og opsigelse, bl.a. i relation til sikkerhed,« siger Søren Bo Christiansen, SKI, som i øjeblikket er på ferie.

Bureaukratisk for "Der er ingen sikkerhed, men det ignorerer vi bare"

  • 0
  • 0
#2 Joe Sørensen

Så vidt jeg ved, så er der ikke nogen lovlig måde at sælge en cloud baseret løsning til det offentlige.

For at en løsning må indeholde personlige oplysninger, for det offentlige skal leverandør til en hver tid vide hvor alle kopiere af dataene ligger fysisk og være i stand til at slette dem fuldstændig hvis det pludselig bliver nødvendigt. Samtidig skal man også kende alle kabler, som de data har bevæget sig gennem i ukrypteret tilstand. Alt dette er pludselig meget svær at løse, hvis man ikke har adgang til den fysiske server, og dennes fysiske harddisk.

I øvrigt må disse data ikke bevæge sig uden for Danmarks grænser, da dette kan betyder at udenlandske myndigheder kan forhindre sig i at destruerer disse data.

Grunden til at disse data skal kunne destrueres er selvfølgelig at man gerne vil vide hvem der har/har haft/vil kunne få adgang til at læse de data, og kan du ikke destruerer dem, så kan du heller ikke være sikker på at der pludselig er nogen der kan finde dem i en "secund hand" backup enhed.

  • 0
  • 0
#4 Anonym

Nu er det jo ikke al offentlig IT der behandler personfølsomme oplysninger...

Selvfølgelig er der offentlige systemer som ikke behandler persondata - pointen er netop at det kun er systemer som ikke behandler persondata, der kan lægges i cloud.

Dvs. vi taler ikke kun om personfølsomme (sundhedsdata, bankdata etc.), men om alle persondata.

Hvis systemer behandler data om personer, så må man sikre sig at systemerne ikke kan vide HVEM data omhandler.

  • 0
  • 0
#5 Joe Sørensen

Min pointe med mit tidligere indlæg var netop at jeg er træt af at personfølsomme data ikke må komme ud i et cloud. Alle data vores servere behandler er personfølsomme. Jeg kunne spare en del tid ved at have disse data i et cloud, hvor der er webservices der kan bestille nye servere som leveres med det samme, og hvor der kan bestilles storage plads, hvor backup af data er garanteret.

Selvfølgelig kan jeg få det samme af vores hosting partner, men det tager lang tid at bestille yderligere plads, når der er brug for det. Data skal jo kopieres til andre diske og der skal måske kontrollere i serverne, som betyder nedetid.

Vi kan selvfølgelig selv opbygge vores eget lille cloud, købe blade server eller bruge virtualisering til at opnå de fordele som cloud vil give os. Nogen gange misunder jeg bare dem, som kan løse en opgave med klik og træt i et webinterface i stedet for at holde møder om kontraktlige forhold hver gang en disk løber tør.

  • 0
  • 0
#6 Anonym

Det er ikke så svært - redesign systemet så personhenførbarheden ikke ligger i cloud. Sætter du farten op og koncentrerer risiko, så må du modvirke det på anden vis.

Faktum er at det skal man alligevel med alle servere. Der er bare megen legacy at rydde op i.

  • 0
  • 0
#7 Anonym

[Advarsel - langt indlæg for at få sammenstillet diskussionen]

Joe

Pointen er at jeg er enig i at der er værdier at hente.

(Det kan diskuteres hvor store værdierne er. F.eks. VTUs beregninger er det rene cherry picking simpelt erkendt ved at de gælder usikret email som absolut ikke må eller kan lægges i cloud. De indregner hverken sikkerhed, markedsforvridninger eller legacy, dvs. det er markedsføring af cloud snarere end samfundsmæssig business cases)

Der er kritiske grunde til at holde fast i principperne. Misbrug af nøgler og persondata (opsamling og brug uden for kontekst til enten kriminalitet eller mod den pågældende kommercielt eller planøkonomisk) er det kritiske problem for hele digitaliseringsprocessen.

Faktum er at hvis lovgivningen ikke indeholdt beskyttelse, så ville vi have nødtvingende grunde til at etablere sådanne krav meget hurtigt.

Om lovgivningen beskytter eller om lovgivningen og navnlig administrationen reelt bør strammes er så et andet spørgsmål.

Princippet siger ikke nej til cloud, men at cloud i sin natur er alt, alt for usikkert til at man kan lægge risikoen og kontrollen i cloud.

Du bør altså behandle ethvert cloud-system som om det allerede er hacket og serveren ikke kan beskyttes mod internes adgang til data og applikationer - og så designe dine applikationer og strukturer så de kan tåle det.

Det betyder ikke at risikoen kan blive nul, men at du skal designe efter, at du - og navnlig de eksterne parter som skal bruge systemet - kan overleve brud.

En kritisk erkendelse - som du måske ikke er opmærksom på. INGEN server behøver at behandle persondata for at levere værdi - serveren behøver ikke at kunne vide HVEM, data vedrører, for at kunne behandle data låst til den konkrete logiske kontekst.

Udgangspunktet og den kritiske forudsætning er at de sårbare entiteter (legale personer og fysiske devices) altid erstattes af formålsspecifikke identifiers og tilsvarende nøgler til nødvendig validering.

Hverken serveren for et bibliotek eller en elektronisk patientjournal behøver at kunne vide hvem som har lånt en bog eller hvem givne sygdomsmæssige eller legemelige karakteristika vedrører.

Viden om HVEM bør forbeholdes de legale personer som faktisk er nødt til at have denne viden enten grundet processens naturlige aspekter eller for at forebygge personens misbrug (e.g. hvis personen nægter at overholde en indgået aftale).

Ingen server gavner sine brugere af at behandle persondata - det skaber blot risici og ubalancer, som kunne undgås og løses langt bedre ved at flytte de relatede opgaver tættere til brugerne/borgerne.

Nettet er en fantastisk opfindelse - men det hele hænger på om det er et både åbent (dvs. ikke dikterende, men semantisk interoperabel og inklusivt) og sikkert (dvs. kontekstuelt isoleret men nødvendigt validerende) net. Cloud sætter de kritiske principper på spidsen ved at løfte konsekvenserne størrelsesordener.

Hvis man ikke var næsten hysteriske over flysikkerhed ville mange flere fly dratte ned.

Cloud og i stigende grad alle servere vil "dratte ned" og må antages allerede at have f.eks. spyware, men til gengæld kan vi designe så vi kan overleve styrtet via f.eks. logisk isolering, redundans og recovery, så hverken en intern eller ekstern angriber kan få noget ud af et angreb, mens forstyrelsen af nyttefunktionen minimeres.

Og her må du desværre huske på at den værste form for kriminalitet er den som foregår ved fuld dagslys. Det kan i praksis altid reduceres til en form for magtmisbrug som kun gavner særinteresser uden en reelt fri markedsdannelse til at sikre at interessenterne kan vælge magtmisbruget fra og bedre alternativer til.

Det dækker både den offentlige sektors planøkonomiske ressourcespilde, monopoler/karteller i den private sektor herunder specielt i infrastrukturen og direkte kriminalitet i form af spyware, malware og afledte handlinger såsom identitetstyveri, anden tyveri, manipulation eller blot som dække for andre handlinger.

Listen er forsøgt prioriteret efter skadeseffekt. F.eks. er den store angriber med ukrypterede SMS ikke den kinsesiske hacker, men planøkonomisk ineffektivisering i den offentlige sektor, kommerciel adfærdsprofillering via infrastrukturen, gatekeepernes lockin - mens den mulige gevinst for den eksterne kriminelle afhænger af indholdet og vil i de fleste tilfælde være meget lille.

Du skriver

Min pointe med mit tidligere indlæg var netop at jeg er træt af at personfølsomme data ikke må komme ud i et cloud. Alle data vores servere behandler er personfølsomme. Jeg kunne spare en del tid

"JEG kunne" (den umiddelbart synlige førsteordenseffekt) - men regningen betales af andre. Både den direkte og navnlig de afledte som er langt, langt større.

Ingen af disse servere bør i fremtiden håndtere pesondata, men funktionerne skal stadig serviceres. Private clouds er at tisse i bukserne - det hjælper (lidt) på det kortsigtede, men skader ved at akkumulere legacyproblemerne.

Dit problem er at det ikke et problem som systemadministrator kan løse alene - redesign af applikationer og infrastruktur er nødvendigt.

Det er en af årsagerne, hvorfor NemId og hele nem-konstruktionen er så tåbeligt fejldesignet - det er desideret anti-cloud og forældet legacy inden det er implementeret. Istedet for at gøre dit arbejde nemmere, så gør man det umuligt.

Du kan ikke løse økonomiske og sikkerhedsmæssige problemer via SLA. Forget it. Cloud fails, live with it.

Eksempel:

Det er fint at ligge stemmeoptællingen i et folketingsvalg i cloud fordi processen netop (af applikationskrav som er uafhængig af cloud) er designet til at være logisk isoleret og det fysiske transaktionsspor/bevis sikrer recovery når cloud-systemet fejler. Du kan simpelthen dumpe processen og begynde forfra her med din (fysiske) backup. Redesignet drejer sig i så tilfælde om at få digitaliseret den fysiske stemmeseddel EFTER den er skabt - fordi man ikke kan digitalisere selve afstemningen.

I princippet kan (konkurrence og innovation) og bør (mindske homogenitet og dermed reducere sårbarhed overfor skalerede angreb) forskellige afstemningssteder arbejde med forskellige metoder, men stemmeoptællingen skal stadig arbejde med så høj verificerbarhed (applikationenskrav) at der er alternative metoder til uforudsigelige stikprøvecheck. I eksemplet valg skal uforudsigelige stikprøvecheck altid ske i en vis procentdel af optællingsstederne.

Oversat - dine førsteordenseffekter her er availability (andre er stærkt afhængige af resultatet) og performance (hurtig optælling) og direkte pris (den variable kapacitetsdel).

Men forudsætningen herfor er design med total revocation (dvs. at fejl er næsten konsekvensløse) og recovery (dvs. at systemet kan bootstrapes hurtigt nok i forhold til applikationskrav uanset om dette kræver varm synkroniseret backup eller mere komplekse funktioner a la de fysiske transaktionsspor).

Valg kan godt leve med at et enkelt valgsted hvor der uanset grund er opstået tvivl (f.eks. store skift eller andre indikationer) lige skal dobbeltchecke i en langsommere process og dobbeltchecket må gerne koste fordi det er både sjældent og kritisk for valgets troværdighed.

Om det kan betale sig at lægge stemmeoptælling i cloud skal jeg ikke kunne sige - det vil markedet afgøre. Pointen er at kravene skal matche risikoen og risikoen ved cloud er nærmest uendelig - so live with it, dvs. gør hvad det kræver eller lad være med at bruge cloud.

  • 0
  • 0
#8 Joe Sørensen

Det er ikke så svært - redesign systemet ...

Jeg elsker den slags sætninger taget ud af sammenhæng :-)

Det ændre så ikke på at du har ret. Hvis man har systemer, som har udviklet i kontinuerlig over mange år, så bør man en gang i mellem tage fat i designet af systemet og se om der er nogen grundlæggende der bør ændres. Også selvom dette er meget dyrt at ændre i, men det bliver kun dyrere at ændre senere. Og hvis man er så heldig at have et SOA baseret design af sit system, så vil det heller ikke være umulig at adskille personfølsomme data fra anonyme data. I vores vil dette dog ikke være let. Vores brugere har det nemlig med at gemme personfølsomme opløsninger steder i vores system, hvor dette ikke er beregnet hertil. Dette gør al vores data personfølsom.

Jeg forstod dog ikke din pointe med at sammenligne clouds med at pisse i bukserne.

Du har ret i at risikoen ved clouds i dag er ret stor. Jeg mener dog ikke, at der er umuligt at bygge et cloud hvor risikoen er lille nok til at det bliver lovlig at bruge den til at opbevare og behandle personfølsomme data. Disse data skal jo opbevares og behandles uanset hvor dette gøres. I dag er det hos en hostingudbyder på servere der er leased til formålet. Grunden til at dette er lovligt, er at hosting udbyderens ansatte har skrevet under på at de ikke kommet til at se disse data, selvom de faktisk har mulighed for at logge på vores databaser med root adgang. Det skal de kunne, fordi der er dem der sørger for backupen. Og det er stadig lovlig fordi vi ved hvor denne backup befinder sig, eller i hvertfald hvor vores hosting udbyder siger at den befinder sig.

I virkeligheden kan de faktisk lyve for os. Vi har ikke nogen klar bevis på at vores servere rent faktisk står, hvor de siger at de står. Og den eneste grund til at vi ved at de tager backup, er fordi vi nogengange beder dem genskabe fra den.

Jeg er mere tryk ved at serverne står hos et hosting firma, sammenlignet med at have dem på vores kontor. Vi er for lille en organisation til at have ansatte med særlig kendskab til hosting. Det kræver fx. at virksomheden investerer i hosting lokale og det tror jeg ikke virksomheden nogenside bliver villig til. ( Fx har jeg endnu ikke overbevist direktøren om at døren til server lokalet på kontoret skal kunne låses... Har forsøgt ).

Det jeg godt kan lide ved de cloud løsninger jeg kender, er at alle de aftaler der skal forhandles allerede er forhandlet på plads, og deres services er lige til at gå til. Lidt ligesom ved telmore. Hvis jeg vil have udenlandstelefoni, så sætter er jeg et kryds i et felt på deres hjemmeside. Og så er det aktiveret.

I dag skal jeg gennem vores indkøbsafdeling for at få dem til at forhandle priser med hosting, hvis leasing aftalen skal udvides med noget der kan købes hos BOB.dk for en plovmand. Jeg har oplevet at opgraderinger af hardware har taget lang tid, fordi forhandlinger er gået i hårknude, og pludselig så er hardwaren en gidsel. Den opgradering bliver jo mere og mere nødvendig, jo længere der forhandles.

Vi skal selvfølgelig heller ikke gøre det der cloud bedre end det er. I virkeligheden er det ikke sikkert at det vil løse mit problem. Jeg bliver jo ikke fuldmægtig af den grund, og ledelsen vil gerne vide hvad det koster før der investeres. Og prisen kommer an på forbrug. Og så bliver det pludselig teknisk.

Men jeg kan stadig ikke forstå at der ikke er nogen der har set et marked i could for personhenførbare data. Som kan garanterer at data ikke bliver tilgængelig for de forkerte applikationer og kan garantere at dansk lovgivning for det data overholdes. Men samtidig kan leverer nogle af de fordele som andre could løsninger også har.

  • 0
  • 0
#9 Anonym

Joe

Cloud indebærer et meget væsentligt skifte i vores system forståelse - et skifte som nok har været modent længe, men som nu er blevet kritisk.

Der er flere niveauer i dette. Borgerens læge kan sagtens vide at et bestemt datasegment vedrører borger x uden at systemet (servere / applikationerne) ved det. Tilsvarende kan borgernes egen læge vide hvem datasegmentat tilhører uden at en anden læge kan vide det.

Endelig kan der være en form for betinget identificerbarhed (som f.eks. kun en dommer, men ingen andre, kan åbne) hvis nu man kræver at f.eks. en anonym sæddoner skal have deponeret denne viden af hensyn til barnets mulighed for senere at få kontakt.

Anonymitet / ikke-anonymitet er i denne forbindelse en alt for unuanceret tilgang.

Vi har i dag teknologier til at verficere og validere fakta om en borger (f.eks. borgeren er tilkendt invalidepension eller over 18 år) uden det nødvendigvis betyder at vi ved hvem borgeren er indenfor denne gruppe. Etc.

Dit problem er at du sidder med den praktiske opgave og får ingen hjælp - leverandørerne kan nok love at beskytte data i cloud, men har selv ikke teoretisk nogen måde at leve op til disse løfter.

  • 0
  • 0
#10 Joe Sørensen

Dit problem er at du sidder med den praktiske opgave og får ingen hjælp - leverandørerne kan nok love at beskytte data i cloud, men har selv ikke teoretisk nogen måde at leve op til disse løfter.

Ja, den situation kender jeg. En leverandør lover og lover, men alligevel så er det os der skal opdage fejlene, overbevise leverandøren om fejlen eksistere, udbedre fejlene, installere hvad der skal installeres af software på eventuel ny hardware eller hvad der nu skal til.

Det er naturligvis os der ved hvem der skal have adgang til de data, som vi opbevare. Og der er også vores system der udlevere data til læge, pårørende, andre behandlere og kommunen. Det, at vide hvem der skal have adgang til informationen, er en ret væsenlig del af vores system, og dette skal naturligvis ikke outsources. Vi er i stand til at opbevare den hardware der opbevare softwaren, og det er det.

Uanset om vores system kører hostet, eller på cloud skal slutresultatet være det samme, og vi vil selvfølgelig hellere have nede tid, end at data bliver tilgængelig på en forkert måde, til forkerte mennesker.

Vi kan ikke rigtige tænke så meget nyt mht. autentificering af data. Vi kan ikke rigtig forlange at data skal dekrypteres hos modtageren på en måde hvor serveren der sender data ikke har mulighed for at dekryptere disse. Altså hvor kun modtagerens klient har nøglerne til de data denne må se. Det kunne være cool, men som du selv tidligere har skrevet, så forlanges der en centraliseret sikkerheds- og nøgle system. Sp den sikkerheds feature bliver ikke til noget i dette årti. Teorien bag den sikkerhedsmodel, vil jeg nok heller ikke kunne forklarer til vores programmører fordi det simpelthen er for langt fra de baner som de fleste programmører tænker i. Selv når vi bruger et offentlig nøgle system, så tænker vi topstyring og ikke asymmetrisk. Selvom vi primært bruger open-source har vores programmører en baggrund i MS-teknologi, hvor AD er gud, og domæne controlleren har alle nøgler til alt.

Det er selvfølgelig synd. Men det var heller ikke det jeg ville ændre. Det var bare interfacet mellem mig og min hostingudbyder jeg vil have standardiseret i samme grad, som interfacet til et cloud system er. Men jeg vil stadig gerne kunne gemme personhenførbar data hos dem, ukrypteret. Og så kryptere det hver gang det læses for at det kan dekrypteres hos modtageren.

  • 0
  • 0
#11 Anonym

Som Einstein sagde - You cannot solve problems with the same thinking that crated them.

Der er meget lidt "naturligt" i det som du skriver ovenfor. Det er altsammen valg - og ja, udviklere og systemejere udvikler med udgangspunkt i deres egne interesser, ikke med fokus på kunder og samfund. Det gælder alle planøkonomiske systemet og er selve årsagen til at de bliver dyere og dårligere over tid.

  • 0
  • 0
#12 Anonym

Det kunne være cool, men som du selv tidligere har skrevet, så forlanges der en centraliseret sikkerheds- og nøgle system. Sp den sikkerheds feature bliver ikke til noget i dette årti.

Sagt med andre ord - systemet formår ikke at addressere systemets indbyggede problemer, men fortsætter med at gentage fejlene i stadigt større omfang.

Det er essensen af forskellen mellem et planøkonomisk og et behovsdrevet system.

Jeg er ikke helt så sortsynet - selv planøkonomiske systemer kan erkende så store fejl. Men det kræver en kritisk masse i centraladministrationen - og specielt Finansministeriets folk ligger låst engang i midten af sidste halvdel af forrige århundrede.

Gammeldags mainfram og planbureaukratisk tænkning den største kilde til det danske samfunds mange og voksende problemer.

Det er ikke så svært - sæt borgeren over systemet, først og fremmest navlig når man taler cloud, fordi ellers vil systemet forsøge at tilpasse borgeren til stive ufleksible processer og alle vil tabe (bortset fra snylterne som lever af andres ulykke).

  • 0
  • 0
Log ind eller Opret konto for at kommentere