Småbedriften trenger ikke enda et IT-system

Et nytt IT-system er ikke automatisk en forbedring. Hvis løsningen ikke kan kobles til virksomhetens sentrale brukerstyring, får de ansatte enda et brukernavn, enda et passord og kanskje enda en tofaktorløsning. Da må gevinsten være stor nok til å forsvare alt det nye arbeidet.

Utgangspunktet for denne artikkelen er en enkel observasjon fra praktisk IT-arbeid: Når et nytt system krever en separat konto og ikke lar seg integrere med den etablerte identitetsløsningen, kan innføringen skape mer administrasjon enn nytte. Det bør utløse et spørsmål som ofte stilles for sent: Trenger vi virkelig dette systemet?

Nytt system betyr også nytt ansvar

Leverandørens presentasjon handler gjerne om funksjonene. Den viser hva løsningen kan gjøre, hvor raskt den kan tas i bruk og hvilke oppgaver den skal forenkle. Det som sjeldnere får like mye plass, er alt virksomheten må forvalte etter kjøpet.

Noen må opprette og avslutte brukere. Tilganger må gjennomgås. Tofaktor må gjenopprettes når en telefon byttes. En kontaktperson må følge med på endringer, varsler og sikkerhetsoppdateringer. Data må eksporteres dersom avtalen avsluttes. Et nytt system er derfor ikke bare en ny funksjon. Det er et nytt forvaltningsansvar.

For en liten bedrift er dette særlig merkbart. De samme få personene skal ofte være ledelse, innkjøper, personvernansvarlig og uformell systemadministrator. En løsning som sparer noen minutter i én arbeidsprosess, kan samtidig legge en varig oppgave i fanget på noen andre.

Innloggingen avslører mer enn brukeropplevelsen

Separat innlogging er ikke bare et irritasjonsmoment. Den sier også noe om hvordan løsningen passer inn i resten av virksomhetens IT-miljø.

Nasjonal sikkerhetsmyndighet anbefaler at virksomheter har kontroll på identiteter, kontoer og tilganger gjennom hele livsløpet. NSM anbefaler også et sentralisert og automatiserbart verktøy for å styre flest mulig kontoer og rettigheter. Det gjør spørsmålet om integrasjon til mer enn en bekvemmelighet: Det handler om hvorvidt virksomheten faktisk kan holde oversikt.

NIST beskriver føderert innlogging, ofte omtalt som single sign-on, som en måte å bruke tjenester uten at hver tjeneste må utstede en egen autentiseringsmekanisme til brukeren. Det kan gi sentral kontoadministrasjon, men betyr ikke at enhver integrasjon automatisk er sikker. Løsningen må fortsatt konfigureres, avgrenses og følges opp.

Min vurdering er likevel klar: En leverandør som selger til bedrifter bør kunne forklare hvordan brukere opprettes, endres og deaktiveres, og om løsningen støtter en vanlig standard for føderert innlogging. Hvis svaret er «vi har vår egen brukerdatabase», har kunden fått en ny administrativ øy.

Tofaktor løser ikke systemspredning

Tofaktorautentisering er et viktig sikkerhetstiltak. NSM anbefaler flerfaktorautentisering som et minimum for kontoer med tilgang til kritiske data eller systemer og for brukere med driftsoppgaver. Problemet er derfor ikke at et system krever tofaktor.

Problemet oppstår når hver nye løsning har sin egen konto, sin egen gjenopprettingsprosess og sin egen metode for tofaktor. Da blir sikkerhetstiltaket en del av en større forvaltningsbelastning. Det kan bli uklart hvem som eier kontoen, hvem som kan gjenopprette tilgangen og om brukere faktisk blir fjernet når noen slutter.

Dette er samme grunn til at bedriften bør eie sin egen IT-dokumentasjon. Oversikt må være en egenskap ved systemet, ikke kun noe én bestemt medarbeider husker.

Vurder integrasjonen før funksjonslisten

NSM anbefaler å stille sikkerhetskrav allerede ved anskaffelsen. En løsning som ikke integrerer godt med eksisterende sikkerhetsarkitektur kan øke sårbarheten og redusere sikkerhetsnivået. Dette er en nyttig korreksjon til innkjøpsprosesser som begynner og slutter med funksjoner og månedspris.

Før en liten bedrift kjøper enda en skytjeneste, bør leverandøren kunne svare konkret på disse spørsmålene:

• Kan løsningen bruke virksomhetens eksisterende identitetsleverandør og single sign-on?
• Kan brukere og grupper opprettes og deaktiveres sentralt eller automatisk?
• Hvem får administratorrettigheter, og kan handlinger spores til en navngitt bruker?
• Hvordan eksporteres virksomhetens data dersom avtalen avsluttes?
• Hva må gjøres manuelt når en ansatt begynner, bytter rolle eller slutter?
• Hvem følger opp sikkerhetsvarsler, oppdateringer og endringer i tjenesten?

Det er ikke sikkert at alle små løsninger må støtte avansert automatisk brukerprovisjonering. Kravene må stå i forhold til dataene, risikoen og antallet brukere. Men manglende integrasjon er en kostnad, og den må regnes med før kjøpet.

Regn på belastningen, ikke bare lisensen

Den reelle prisen på et system er større enn beløpet på fakturaen. Den omfatter også opplæring, administrasjon, støtte, dokumentasjon, integrasjoner, sikkerhetsarbeid og tiden det tar å håndtere avvik.

En enkel vurdering kan gjøres uten et stort prosjekt. Skriv ned hvilken konkret oppgave systemet skal forbedre. Anslå hvor ofte oppgaven utføres og hvem som sparer tid. Skriv deretter ned de nye oppgavene løsningen skaper. Hvis nytten fortsatt er tydelig, har systemet et forsvarlig utgangspunkt. Hvis gevinsten bare kan beskrives med ord som «digitalisering» eller «bedre flyt», er beslutningsgrunnlaget for svakt.

Vurder også hva som allerede finnes. Mange virksomheter betaler for funksjoner i dagens plattform som aldri er tatt i bruk. Det kan være enklere å rydde i arbeidsprosessen eller aktivere en eksisterende funksjon enn å innføre en ny tjeneste.

Et system bør også ha en avslutningsplan

Programvare blir ofte kjøpt inn som om den skal vare evig. I praksis skifter behov, leverandører og priser. Før innføring bør bedriften derfor vite hvordan løsningen kan avvikles.

Kan data hentes ut i et anvendelig format? Kan alle brukere deaktiveres sentralt? Finnes det integrasjoner som må kobles fra? Hvem dokumenterer dette? En enkel avslutningsplan gjør det lettere å si nei til en løsning som vil bli vanskelig å forlate.

Trenger vi virkelig dette?

Det spørsmålet er ikke teknologifiendtlig. Det er et nødvendig styringsspørsmål.

Et godt system skal løse et viktig problem bedre enn alternativene. Det skal passe inn i virksomhetens identitets- og sikkerhetsarbeid, eller ha en gevinst som tydelig forsvarer ekstraarbeidet. Hvis resultatet først og fremst er enda en konto, enda en app og enda en rutine som noen må huske, er det ofte bedre å la være.

Småbedriften trenger ikke flest mulig systemer. Den trenger færrest mulig systemer som til sammen dekker de faktiske behovene.

Kilder

• NSM: Ivareta sikkerhet i anskaffelses- og utviklingsprosesser
• NSM: Grunnprinsipper for IKT-sikkerhet, versjon 2.1
• NIST SP 800-63C: Federation and Assertions