Kortversjonen

• MCP er den åpne standarden en KI-assistent bruker for å nå et verktøy utenfor seg selv. Den avgjør hvordan assistenten kobler seg til, ikke hva den får se.
• Hva den får se, er hele spørsmålet. En assistent koblet til med en vid nøkkel ser alt nøkkelen ser, uansett hvem som spør.
• I Softeria svarer hver app på MCP på sin egen adresse, og assistenten logger inn som personen som bruker den: deres roller og regler gjelder, og ingenting annet kan nås.
• Skriving er ekte, og en godkjenningsdialog kan ikke skille et oppslag fra en sletting. Godkjenn endringer én om gangen, og bruk en lesekonto til arbeid som bare skal lese.

Et sted i organisasjonen deres, akkurat nå, kopierer noen rader ut av et internt verktøy og limer dem inn i en KI-assistent for å stille et spørsmål om dem. Det virker, og derfor gjør de det. Det betyr også at dataene har forlatt verktøyet, at reglene ikke lenger gjelder, og at ingen etterpå kan si hva som ble delt eller med hvem.

Det bedre svaret er ikke å forby assistenten, men å koble den til ordentlig — til appen, gjennom appens egen pålogging, slik at den ser det personen som spør kunne sett, og ikke noe mer. Det er det MCP gjør mulig, og det MCP ikke avgjør på egen hånd.

Hva MCP er

MCP, Model Context Protocol, er en åpen standard for hvordan en KI-assistent når et verktøy utenfor seg selv: hvilke operasjoner verktøyet tilbyr, hvordan assistenten kaller en av dem, og hva som kommer tilbake. Claude støtter den, og det gjør en voksende liste over andre assistenter også. Et verktøy som snakker MCP, kan kobles til hvilken som helst av dem uten at noen skriver en integrasjon for hver.

Det standarden ikke avgjør, er den delen IT bryr seg om: hvem assistenten er når den kaller verktøyet, og dermed hva den har lov til å se og endre. Det avgjøres av hvordan tilkoblingen logger inn — og det varierer enormt fra produkt til produkt.

Risikoen er nøkkelen, ikke assistenten

Den vanlige måten å gi en assistent tilgang til et system på, er en nøkkel: et API-token eller en tjenestekonto, limt inn i assistentens innstillinger én gang. Det går raskt, og det endrer i det stille hvem som spør. Hvert spørsmål kjører nå med nøkkelens tilgang, ikke tilgangen til personen som skriver — og nøkler lages nesten alltid vide, fordi en smal nøkkel stadig går i stykker.

• Praktikanten ser det nøkkelen ser. Den som bruker assistenten, arver nøkkelens rekkevidde, så regler som holder folk unna hverandres poster, slutter å gjelde.
• Loggen sier at nøkkelen gjorde det. En revisjonslogg som registrerer tjenestekontoen, kan ikke si hvilken person som ba om hva.
• Nøkkelen lever lenger enn personen. Når noen slutter, stenges kontoen deres i katalogen. Tokenet i en assistents innstillinger gjør ikke det.

Ingenting av dette er nytt. Det er det samme problemet som et delt passord, gjort verre av et verktøy som er svært flinkt til å lese alt det har lov til.

Hva dere bør spørre om før dere kobler til en

• Hvem er assistenten når den kaller? Svaret dere vil ha, er «personen som bruker den, innlogget på vanlig måte». En delt nøkkel eller en tjenestekonto er svaret å bekymre seg over.
• Gjelder de samme reglene? Roller, regler på radnivå og alt annet som begrenser en person i appen, bør begrense assistenten som handler for dem — håndhevet av systemet, ikke av assistentens gode oppførsel.
• Hva kan legitimasjonen brukes til? Et token som gis til en assistent, bør gjelde for den tilkoblingen og ingenting annet, ikke være en generell nøkkel til resten av systemet.
• Kan den skrive? Å lese er én beslutning, å endre og slette en annen. Finn ut om assistenten kan gjøre begge deler, og hvordan dere ville holdt den til lesing.
• Hva skjer når noen slutter? Å stenge kontoen deres i katalogen bør avslutte assistentens tilgang sammen med alt annet.

Slik fungerer det i Softeria: innebygd i hver app

Hver app som bygges på plattformen, svarer på MCP på sin egen adresse med /mcp på slutten — adressen dere ville åpnet appen på, på vårt domene eller deres eget. Det er ingenting å installere, rulle ut eller slå på.

• Legg til en kobling. I Claude: Settings → Connectors → Add custom connector. Andre assistenter som støtter MCP, har det samme steget.
• Lim inn adressen. For eksempel https://app.dittfirma.no/mcp.
• Logg inn. Appens egen innloggingsside åpner seg. Logg inn akkurat som du alltid gjør — samme konto, samme knapper.
• Godkjenn. Det er hele oppsettet. Be om noe i samtalen, så henter assistenten det.

Innloggingen kan åpne seg på en annen adresse

Hvis appen også ligger på deres eget domene, kan innloggingen åpne seg der selv om du limte inn en annen adresse. Det er med vilje: identitetsleverandøren godtar bare adressen som er registrert hos den.

Den logger inn som deg

Hvert kall assistenten gjør, kjører som personen som logget inn. Roller, tilgangsregler og sikkerhetsregler gjelder akkurat som i appen: ingen omvei, ingen administratormodus, ingenting som kan nås som personen ikke kunne nådd selv. En kontrollørs assistent ser kontrollørens region.

Så når en assistent sier at den ikke har lov til å se noe, er det personens tilgang som virker, ikke en ødelagt tilkobling — og løsningen ligger der tilgangen avgjøres, ikke i å koble til på nytt. Legitimasjonen assistenten ender opp med, gjelder for appens MCP-adresse og ingenting annet; den kan ikke snus og brukes som en generell nøkkel til API-et.

Hva den kan nå

Appens data, som operasjoner oppkalt etter dem: den kan lese, opprette, endre og slette poster i samlinger og visninger, lese spørringer og kalle funksjoner. Lesingen er fullverdig — filtrering, sortering, sideinndeling, valg av felter, henting av tilknyttede poster, og søk der det er slått på.

En ekte app har fort hundrevis av operasjoner, flere enn en assistent kan holde på én gang, så den får ikke listen. Den søker etter den den trenger ved navn, leser hva den tar imot og kjører den — og navnene følger datamodellen deres, så det assistenten sier den gjorde, stemmer med det dere kalte tingene.

En visning er ikke skrivebeskyttet

Visninger kan skrives til her som alle andre steder, så en assistent kan endre poster gjennom en visning akkurat som gjennom tabellen under. For en skrivebeskyttet form, bruk en spørring, eller en rolle som bare gir lesetilgang.

Hvor dere må være forsiktige

Å opprette, endre og slette gjennom en assistent er vanlige skriveoperasjoner. Funksjoner som kjører ved en endring, kjører, og en sletting kan ikke angres.

Assistenten kan ikke varsle dere om hvilken som er hvilken. Alt den gjør, når appen gjennom én og samme operasjon, så godkjenningsdialogen ser lik ut enten den skal liste ti ordrer eller slette én. Det betyr at «tillat alltid», gitt én gang under et harmløst oppslag, også godkjenner hver endring og sletting som følger. Godkjenn endringer én om gangen — og til arbeid som bare skal lese, logg inn med en konto der rollen bare gir lesetilgang.

• Svært store svar stopper ved omtrent en megabyte tekst. Over det blir assistenten bedt om å snevre inn forespørselen, i stedet for å få et avkortet svar den kanskje rapporterer som fullstendig.
• Filer kommer ikke tilbake. Assistenten får vite at en fil finnes, hvilken type og hvor stor den er; åpne den i appen. En liten fil kan sendes med en ny post.
• Hver forespørsel står for seg selv. Ingenting holdes åpent mellom dem, så arbeid som tar lang tid, hører hjemme i en funksjon, ikke i en samtale.

Det som er verdt å ta med seg

Uansett hva dere kobler en assistent til: la den logge inn som personen, etter reglene som allerede gjelder for dem, med en legitimasjon som ikke duger til noe annet. Da er en assistent bare en annen måte å bruke appen på — og spørsmålet om hva den får se, har samme svar som spørsmålet om hva personen får se, som dere allerede har besvart én gang.

Les videre

• Tilgang på radnivå forklart — Reglene en assistent arver fra personen den handler for
• Enkel pålogging — Hvorfor assistenten logger inn slik personen gjør
• Det som ligger under — MCP blant det som er bygget inn i hver app

Kortversjonen

• Enkel pålogging betyr at verktøyet ikke har noe passord. Det spør firmakatalogen hvem personen er, og stoler på svaret.
• Den egentlige gevinsten er ikke bekvemmelighet. Det er at én konto som slås av på ett sted, avslutter tilgangen overalt.
• La gruppene dere allerede vedlikeholder avgjøre hvem som når hva, så det ikke finnes en ny liste over folk som må holdes i takt med den første.
• Spør før dere kjøper: hvilken standard, om passordinnlogging kan slås av, hvor lenge en økt varer etter at kontoen er borte, og om enkel pålogging koster ekstra.

Tell de interne verktøyene i organisasjonen deres som har sitt eget innloggingsbilde: bookingsystemet, leverandørregisteret, skjemaet en avdeling bygde, rapportverktøyet noen kjøpte med kortet. Hvert av dem har sin egen liste over brukere og sine egne passord, og hver av de listene må oppdateres for hånd hver gang noen begynner, bytter rolle eller slutter.

De fleste av de listene er feil akkurat nå. Ikke grovt feil, bare litt: en innleid konsulent fra i fjor vår, en kollega som gikk over til en annen avdeling og beholdt det hun hadde. Enkel pålogging er måten å slutte å føre listene på i det hele tatt.

Hva enkel pålogging faktisk er

Med enkel pålogging ser verktøyet aldri et passord. Når noen åpner det, blir de sendt til firmaets identitetsleverandør — Microsoft Entra ID, Google, Okta eller lignende — som sjekker hvem de er på den måten firmaet har bestemt, og sender dem tilbake med en signert erklæring: dette er Kari, hun er med i disse gruppene. Verktøyet stoler på erklæringen og slipper henne inn.

To standarder gjør nesten hele denne jobben. OpenID Connect er den nyere og den de fleste moderne verktøy bruker; SAML er eldre og fortsatt vanlig i stor bedriftsprogramvare. Begge er greit. Det som betyr noe, er at det er en av dem, og ikke noe en leverandør har funnet på selv.

• Det er ikke en passordbehandler. En passordbehandler husker mange passord for deg. Enkel pålogging betyr at det bare finnes ett, og at bare katalogen deres har det.
• Det er ikke «samme passord overalt». Å synkronisere ett passord inn i ti systemer legger ti kopier av det på ti steder. Enkel pålogging legger det på ingen av dem.
• Det er ikke en personlig «Logg på med Google». En privat Gmail-konto som logger på et jobbverktøy, er fortsatt en personlig konto. Det må være firmaets katalog, ellers kan ikke firmaet slå den av.

Hva separate passord koster

Argumentet for enkel pålogging blir som regel ført som bekvemmelighet — én innlogging i stedet for tolv — og bekvemmelighet er den svakeste delen av det. Kostnadene ved separate passord ligger andre steder.

• De som slutter, beholder tilgangen. Når noen slutter, blir firmakontoen slått av. Det når ikke verktøyet med sin egen brukerliste, med mindre noen husker at verktøyet finnes og har rettigheter til å endre det.
• Sikkerhetsreglene deres stopper ved døren. Tofaktorinnlogging, blokkerte land, bare administrerte enheter — uansett hva katalogen deres håndhever, hopper et verktøy med eget passord over alt sammen.
• Passord blir gjenbrukt. Folk finner ikke på et nytt, sterkt passord til bookingsystemet for kantina. De bruker et de allerede har, som nå bare er så trygt som det minst forsiktige nettstedet de har brukt det på.
• Ingen kan si hvem som har tilgang. Når en revisor eller en kunde spør hvem som kan nå et system, er svaret spredt over et dusin adminskjermbilder, og noen av dem tilhører folk som har sluttet.

Dagen noen slutter

Det er dette øyeblikket enkel pålogging egentlig er til for. Deaktiver én konto i katalogen, og neste gang den personen prøver å åpne et tilkoblet verktøy, sier identitetsleverandøren nei. Det finnes ingen liste å gå gjennom, så det finnes ingenting på den å glemme.

Det er verdt å være presis om hullene, for det finnes noen, og det er der kontrollene bør settes inn.

• Økter som allerede er åpne. En som logget inn i morges, kan være innlogget til økten løper ut, også etter at kontoen er deaktivert. Finn ut hvor lenge det er i hvert verktøy — minutter og timer er greit, uker er det ikke.
• Innlogginger som går utenom. Mange verktøy har en passordinnlogging ved siden av enkel pålogging, for den første administratoren eller av gammel vane. En konto som opprettes der, ligger utenfor katalogen deres og overlever alt det ovenfor.
• Nøkler og tokener. Integrasjonsnøkler og personlige tilgangstokener blir ofte opprettet av en person og lever videre etter at personen har gått. De bør høre til en tjeneste, med en navngitt eier, ikke til den som tilfeldigvis satte dem opp.

Behold én vei inn som ikke er avhengig av katalogen

Å slå av passordinnlogging helt har én reell risiko: hvis identitetsleverandøren er utilgjengelig eller feilkonfigurert, kommer ingen inn for å rette noe. Svaret er én administratorkonto for nødstilfeller, forseglet, der hver bruk logges og kontrolleres — ikke en passordinnlogging som står åpen for alle.

Grupper, ikke lister

Enkel pålogging svarer på «hvem er dette». Neste spørsmål er «hva får de gjøre», og det fristende svaret er å gi hvert verktøy sin egen liste igjen: Kari er redaktør her, administrator der. Det bygger opp igjen problemet enkel pålogging nettopp fjernet.

Det bedre mønsteret er å la gruppene dere allerede vedlikeholder avgjøre. Økonomigruppen kan godkjenne fakturaer; lagergruppen kan registrere leveranser. Når Kari flytter fra økonomi til lageret, endrer noen gruppene hennes i katalogen — noe de uansett skulle gjøre — og hvert verktøy følger etter uten å bli rørt.

Grupper avgjør hvilke dører en person får åpne. De avgjør ikke hvilke poster som er deres når de først er inne: det er et eget spørsmål, som besvares ved dataene, og guiden om tilgang på radnivå tar for seg det.

Hva dere bør spørre om før et verktøy får brukere

Dette er spørsmålene som er verdt å stille om ethvert verktøy, kjøpt eller bygget, før noen får lov til å logge inn i det. Hvert av dem har et kort svar hvis leverandøren har tenkt gjennom det.

• Hvilken standard? OpenID Connect eller SAML, og virker det med identitetsleverandøren dere faktisk bruker? «Vi støtter Microsoft» er ikke et svar før dere vet hvilken del av Microsoft.
• Er det inkludert? Enkel pålogging er ofte forbeholdt den dyreste planen. Finn det ut før piloten, ikke ved fornyelsen, for det er den billige planen med separate passord folk i det stille kommer til å fortsette å bruke.
• Kan passordinnlogging slås av? Hvis den ikke kan det, er enkel pålogging et alternativ, ikke en regel, og sidedøren står åpen.
• Leses gruppene ved innlogging? Følger tilgangen gruppene i katalogen deres slik de er i dag, eller blir de kopiert én gang og aldri oppdatert?
• Hvor lenge varer en økt etter at kontoen er borte? Det ærlige tallet, og om en administrator kan avslutte en økt før tiden.
• Hvor blir innlogginger registrert? Identitetsleverandøren registrerer at noen logget inn. Verktøyet bør registrere hva de gjorde når de først var inne — og dere bør kunne lese det.

Slik fungerer det på vår plattform

Siden dere kanskje leser dette på nettstedet til et selskap som selger en plattform: det som bygges med Softeria, logger folk inn med kontoene de allerede har — Microsoft Entra ID, Google Cloud Identity eller en hvilken som helst OpenID Connect-leverandør som følger standarden, som Okta, Auth0 eller Keycloak. Vi utsteder ingen nye passord, gruppene dere allerede vedlikeholder avgjør hvem som når hva, og når noen forsvinner fra katalogen deres, opphører tilgangen.

Det som er verdt å ta med seg uansett hva dere bruker: et verktøy som fører sin egen liste over folk, er et verktøy noen kommer til å glemme den dagen det betyr noe. Gjør katalogen til den eneste listen, så blir det å avslutte en ansettelse ett steg i stedet for en jakt.

Les videre

• Hvordan logger folk inn? — Det korte svaret, i spørsmål og svar
• Tilgang på radnivå forklart — Når dere vet hvem noen er: hvilke poster som er deres
• Hva dere gjør med skygge-IT — Der de fleste separate passordene kommer fra

Kortversjonen

• Tilgang på radnivå svarer på «hvilke poster», ikke «hvilke endepunkter». Det er to ulike spørsmål, og de trenger hver sin mekanisme.
• En regel som håndheves i skjermbildene eller i koden til hvert endepunkt, holder bare så lenge hver fremtidige spørring husker den. Det er et veddemål på et teams hukommelse, på ubestemt tid.
• Er regelen erklært ved dataene, gjelder den for hver spørring — også rapporten, eksportknappen og bakgrunnsjobben noen legger til neste år.
• Test den slik en angriper ville gjort: be om en post du ikke skal ha lov til å se, ved å oppgi id-en, og se hva som kommer tilbake.

Tilgang på radnivå er svaret på et spørsmål hver applikasjon med mer enn én kunde må svare på: av alle radene i denne tabellen, hvilke har akkurat denne personen lov til å røre? Ikke «får denne personen lese fakturaer» — det er et grovere spørsmål om endepunktet — men «får denne personen lese denne fakturaen».

Skillet høres pirkete ut helt til man legger merke til at de fleste datalekkasjer ikke er innbrudd. Det er vanlige, innloggede brukere som får rader som aldri var ment for dem, fra en spørring ingen tenkte to ganger over.

To spørsmål som blir forvekslet med ett

Tilgangskontroll i en vanlig applikasjon er egentlig to beslutninger lagt oppå hverandre, og de svikter på forskjellige måter.

• Tilgang på metodenivå: får denne brukeren bruke denne operasjonen i det hele tatt? «Alle innloggede brukere kan lese samlingen bookings. Bare en administrator kan slette en booking.» Dette er et ja-eller-nei-spørsmål som avgjøres før noen data leses, og det styres som regel av en rolle i brukerens påloggingstoken.
• Tilgang på radnivå: gitt at de får lese bookinger, hvilke bookinger? «De som gjelder deres eget firma.» Dette er et filter som legges på selve dataene, og det kan bare besvares ved å se på hvordan posten henger sammen med den som spør.

Team griper til roller for å løse begge deler, fordi roller er verktøyet som allerede ligger der. Det fungerer helt til den første kunden som vil at to av sine egne brukere skal se ulike deler av sine egne data — og da finner man opp én rolle per kunde, og rollelisten har blitt en treg, dårlig indeksert kopi av datamodellen.

De tre stedene regelen havner

I praksis havner regler for enkeltposter på ett av tre steder, og de er ikke likeverdige.

• I brukergrensesnittet. Skjermbildet viser bare den innloggede brukerens poster, så ingen ser noe de ikke skal. Dette er ikke sikkerhet; det er layout. Den underliggende forespørselen kan sendes på nytt for hånd med en annen id, og alt grensesnittet skjulte, kommer tilbake.
• I koden til endepunktet. Hvert endepunkt legger til en betingelse — where company_id = current_user.company_id — før spørringen kjøres. Dette er ekte håndheving, og det virker. Men det må også gjentas i hvert endepunkt, for alltid, av alle, også av den som legger til en CSV-eksport klokka halv fem en fredag.
• Ved dataene. Regelen erklæres én gang, på relasjonen som gjør en post til «din», og databasen bruker den på hver spørring mot tabellen, uansett hvilken kode som spurte. Det finnes ikke noe endepunkt som kan glemme den, fordi filteret ikke ligger i endepunktet.

Det andre alternativet er det vanlige, og det er verdt å være presis om hvorfor det skuffer. Det er ikke feil. Det er riktig den dagen det skrives, og så forvitrer det: et endepunkt som var trygt, forblir trygt, men flaten fortsetter å vokse — en rapportspørring, et adminskjermbilde, en webhook, en planlagt jobb, en KI-assistent som spør mot de samme tabellene. Hver av dem er en ny anledning til å utelate betingelsen, og ingenting i systemet protesterer når det skjer.

Feilen er stille

En manglende autentiseringssjekk svikter med et smell: ingen kommer inn. Et manglende radfilter svikter i stillhet — endepunktet virker, returnerer data, består testene sine og gir feil kundes rader til den som spør. Som regel er det en kunde som oppdager det, og det er den dyre måten å oppdage det på.

Regelen er en vei gjennom dataene

Grunnen til at regler for enkeltposter ikke lar seg uttrykke som roller, er at «din» nesten aldri er en egenskap ved posten. Det er en vei: denne oppgaven hører til et prosjekt, som hører til et team, som du er medlem av. Eierskapet ligger to eller tre relasjoner unna, og det endrer seg når noen begynner eller slutter.

Det er den formen en god mekanisme for tilgang på radnivå tar imot. Du peker på relasjonen som bærer eierskapet, og hver spørring mot samlingen snevres inn til postene som kan nås fra den som spør. Du beskriver datamodellen i stedet for å ramse opp tilfeller, og derfor fortsetter det å virke når modellen vokser.

Det gir også noe tilnærmingen med én rolle per kunde ikke kan gi: samme person kan ha ulike rettigheter til ulike poster. Arrangør av én turnering, vanlig medlem i den neste, og påloggingstokenet endrer seg aldri — fordi rettigheten er registrert på medlemskapet, ikke på personen.

Flerleietakerarkitektur er det samme problemet i dress

Flerleietakerarkitektur — ett kjørende system som betjener mange kunder som aldri må se hverandre — høres ut som et arkitekturvalg, og blir diskutert som et: én database per kunde, eller én database med en kolonne for leietaker. Men det andre alternativet er nøyaktig problemet over, og det første velges ofte mest for å slippe å løse det.

Én database per kunde er virkelig tryggere mot akkurat denne feilen, og den koster dere overalt ellers: migreringer som må kjøres per leietaker, sikkerhetskopier som må håndteres per leietaker, rapportering på tvers av kunder som blir et prosjekt, og en oppstartskostnad per kunde som i det stille setter en nedre grense for hvor liten kunde dere har råd til å ta inn. Holder regelen på radnivå ved dataene, slutter en delt database å være det risikable valget.

Slik finner dere ut om deres faktisk holder

Uansett hvilken mekanisme dere bruker, er dette kontrollene som er verdt å gjøre før dere lover en kunde at dataene deres er isolert. Hver av dem er en halvtimes arbeid, og de fleste finner noe første gang.

• Be om en post du ikke skal ha. Logg inn som én kunde, ta id-en til en annen kundes post, og be om den direkte. Du skal ikke få noe — ikke et tomt skjermbilde, men et tomt svar.
• Prøv alle dørene, ikke bare inngangsdøren. Listeendepunktet er som regel riktig, fordi noen har testet det. Sjekk lesing av enkeltposter, søk, eksport, rapporter, opptellinger og eventuelle sanntidsabonnementer hver for seg. Opptellinger er en gjenganger: «42 treff» avslører at det finnes rader listen skjuler.
• Sjekk skrivesiden også. Lesing får oppmerksomheten; det er endringer og slettinger som endrer andres data. Prøv å endre en post som tilhører en annen leietaker, og prøv å opprette en post som peker på en.
• Sjekk hva som skjer når koblingen mangler. En post der eierrelasjonen er tom, er ingens rad. Avhengig av mekanismen betyr det at den er usynlig for alle eller synlig for alle — og bare det ene er trygt. Finn ut hvilket dere har.
• Se hva kontrollen koster. Hvis regelen håndheves ved å slå sammen tabeller på tvers av relasjoner, kan en for vid konfigurasjon gjøre én lesing om til svært mange joins. Riktig men tregt er et problem dere møter i produksjon, ikke i testing.

Abonnementer er unntaket det er verdt å kjenne til

Mekanismer for sanntidsoppdatering ligger ofte utenfor radfilteret: en klient som abonnerer på en samling, kan få beskjed om at en post er endret, også poster den ikke kunne lese. Som regel følger ingen feltverdier med — men at raden finnes, gjør det. Spør hvor sanntidslaget ligger i forhold til reglene for tilgang på radnivå, for det ligger sjelden på samme sted.

Slik fungerer det på vår plattform

For ordens skyld, siden dere kanskje leser dette på nettstedet til et selskap som selger en slik plattform: på RestAPI.com er regelen på radnivå en sikkerhetspolicy som erklæres på relasjonen som bærer eierskapet, og den gjelder for hver spørring mot den samlingen. Tilgang på metodenivå blir der den hører hjemme — roller i tokenet, sjekket før noen data leses — og de to konfigureres hver for seg fordi de er ulike spørsmål.

Det som er verdt å stjele selv om dere aldri bruker plattformen vår: regelen erklæres mot datamodellen, ikke skrives inn i hvert endepunkt. Uansett hvilken database eller hvilket rammeverk dere bruker, er det den egenskapen som avgjør om isolasjonen deres er en garanti eller en vane.

Les videre

• RestAPI.com — Datamodeller, API-er og sikkerhetspolicyer på én plattform
• Kan vi styre hvem som ser hvilke poster? — Det korte svaret, i spørsmål og svar
• Hva dere gjør med skygge-IT — Den andre måten data havner der de ikke skal være

Kortversjonen

• «Eier vi det» blander sammen opphavsrett, lesbarhet og flyttbarhet. Still dem hver for seg, ellers får dere ett svar som dekker over de to andre.
• Opphavsrett til rent maskinskapt innhold er virkelig uavklart og varierer fra land til land. Det er også sjelden det som skader dere.
• Det som avgjør hvor dere står i praksis, er kontrakten og veien ut: hva vilkårene gir dere, og om løsningen kjører uten leverandøren.
• Testen som skjærer gjennom alt sammen: kunne en annen utvikler tatt dette og kjørt det neste tirsdag, uten å be oss om noe?

Spør en leverandør om dere eier det verktøyet deres bygger, og dere får et selvsikkert ja. Det er et rimelig svar på et urimelig spørsmål, for «eie» gjør tre jobber på en gang: hvem har opphavsretten, kan dere lese og endre løsningen, og kan dere kjøre den et annet sted. En leverandør kan snakke helt sant om det første og likevel la dere sitte fast på det tredje.

De tre spørsmålene

• Juridisk eierskap. Hvem har rettighetene til resultatet, og hva sier vilkårene dere har signert om det?
• Åpenhet. Kan dere se koden, lese den, gå den gjennom og la deres egne utviklere endre den — eller ligger den bak en editor og et format som bare leverandørens programvare forstår?
• Flyttbarhet. Hvis samarbeidet tar slutt, fortsetter det dere har bygget å kjøre? På hvems infrastruktur, med hvems database, og hvor mye arbeid er flyttingen?

De skiller lag på måter som betyr noe. Dere kan ha alle rettigheter til et system dere ikke kan lese. Dere kan være i stand til å lese kode dere ikke kan kjøre noe annet sted enn der. Det er bare kombinasjonen som er verdt noe.

Den juridiske delen, ærlig talt

Opphavsrett til maskinskapt innhold er uavklart, og den er uavklart på ulike måter i ulike land. Den generelle retningen i USA har vært at opphavsretten beskytter menneskelig skaperverk, og at materiale en maskin har laget uten vesentlig skapende innsats fra et menneske, ikke kan registreres — mens verk der en person har stått for det skapende uttrykket og brukt et verktøy underveis, behandles helt vanlig. Andre jurisdiksjoner vekter dette annerledes, og stillingen er stadig i bevegelse.

Dette er ikke juridisk rådgivning

Vi lager programvare, ikke juridiske vurderinger, og jussen her er virkelig i bevegelse. Hvis eierskapet til resultatet er bærende for virksomheten deres — dere har tenkt å lisensiere det, selge selskapet eller forsvare det — bør dere få råd fra noen som har dette som yrke, i deres jurisdiksjon.

Den praktiske konsekvensen er mindre enn den høres ut. For de fleste interne systemer og de fleste produkter er det som avgjør hvor dere står, ikke om en registrering av opphavsrett ville tålt en prøving. Det er hva avtalen med leverandøren gir dere, og om løsningen kjører uten dem. Det er kontraktsmessige og tekniske spørsmål, og begge har klare svar i dag.

Hva dere bør lese i vilkårene

Uansett hvilket verktøy dere vurderer, er dette klausulene som avgjør hva dere faktisk går derfra med. De er som regel korte og sjelden gjemt — men de blir også sjelden nevnt uoppfordret.

• Hva dere får av rettigheter til resultatet. Overdrar avtalen resultatet til dere, eller gir den dere en lisens til det? En lisens kan trekkes tilbake eller gjøres betinget av at dere forblir kunde; en overdragelse kan ikke det.
• Hva som skjer når avtalen opphører. Består rettighetene deres til det som ble bygget, etter at kontrakten er slutt? Hvis svaret bare er underforstått, er det ikke et svar.
• Hva de kan gjøre med koden og dataene deres. Brukes noe av det til å trene modeller, eller til å forbedre tjenesten på en måte som innebærer at det lagres? En klar uttalelse den ene eller andre veien er greit; taushet er det ikke.
• Hva dere får med dere ut, og når. Dataeksport, databasestruktur og kildekoden til applikasjonen — i et standardformat, når dere ber om det, uten en supportsak og ventetid.
• Om noe i den bare kjører der. Proprietære komponenter, et kjøremiljø bare de drifter, eller et byggesteg dere ikke kan gjenskape. Dette er et teknisk punkt, men det hører hjemme på samme liste, for det er dette som gjør en god kontrakt til en dårlig posisjon.

Utgangstesten

Ett spørsmål avgjør det meste av dette, og dere kan stille det i et salgsmøte: hvis vi gikk neste tirsdag, hva nøyaktig ville vi tatt med oss, og hva skulle til for å kjøre det? Leverandører som har tenkt gjennom det, svarer konkret. De som ikke har det, svarer med beroligelser.

Et godt svar har fire deler, og dere bør be om å få se hver av dem i stedet for å få dem fortalt.

• Kildekoden, i en vanlig form. Et ordinært prosjekt i et utbredt rammeverk, som en utvikler som aldri har møtt leverandøren, kan åpne og forstå. Be om å få se et ekte prosjekt før dere kjøper.
• Dataene, i et format noe annet kan lese. Ikke et proprietært arkiv som bare kan importeres tilbake i det samme produktet.
• Databasestrukturen, ikke bare radene. Data uten skjemaet sitt er et stort puslespill. Ren SQL for strukturen er det dere bør be om.
• En vei til et annet sted. Hva som skal til for å drifte resultatet et annet sted — og om noe i det er en tjeneste bare den leverandøren kjører.

Det er verdt å merke seg hva denne testen ikke handler om. Den er ikke en plan for å gå. De fleste som stiller spørsmålet, blir. Den er en måte å finne ut om det å bli vil være et valg eller en konsekvens — og det er for øvrig også det sterkeste en leverandør kan tilby dere.

Hvor vi står

Våre svar, siden det ville vært rart å publisere dette og så være tilbakeholdne: applikasjonskoden er deres, og den er vanlig kode i vanlige rammeverk — React, Next.js, Vue, Flutter — som deres egne utviklere kan lese og endre. Dataene og databasestrukturen deres eksporteres i sin helhet når dere ber om det, også som SQL-skript en vanlig database kan lese. Siden med spørsmål og svar sier alt dette konkret, og Softeria Studio er produktet det gjelder.

Vi vil heller konkurrere på å være verdt å bli hos. Det er et forretningsmessig standpunkt, ikke et moralsk — men det er det som lar oss publisere denne guiden uten å redigere bort de ubehagelige delene.

Les videre

• Eier vi det som blir bygget? — Vårt svar, sagt rett ut
• Softeria Studio — Hva det bygger, og hva dere får beholde
• Tilgang på radnivå forklart — Det andre spørsmålet det er verdt å stille en leverandør tidlig

Kortversjonen

• Skygge-IT er hvordan en lang kø ser ut utenfra. Et forbud tar for seg symptomet og gjør køen lengre.
• Det farlige er sjelden verktøyet. Det er data i personlige kontoer, ingen sikkerhetskopi, tilgang som ikke fjernes når noen slutter, og én person som forstår det.
• Finn det med amnesti, ikke med revisjon. Folk skjuler verktøy for revisorer og gir dem fra seg til kolleger.
• Den varige løsningen er å gjøre den godkjente veien raskere enn omveien, for det er den eneste konkurransen den noen gang har tapt.

Hver organisasjon over en viss størrelse går på programvare ingen har godkjent: et regneark som setter opp vaktlistene, en Access-database fra 2014, et skjema noen bygde i løpet av en helg, en personlig automatiseringskonto som har en nøkkel til økonomisystemet. Dette blir gjerne beskrevet som et disiplinproblem. Det er nesten aldri et disiplinproblem.

Det er et køproblem. Noen trengte et lite system, den offisielle veien anslo måneder, og arbeidet måtte likevel gjøres dette kvartalet. Det de bygde, var et fornuftig svar på valgene de hadde foran seg.

Hvorfor det skjer

Det er verdt å være konkret, for årsakene peker mot ulike løsninger.

• Behovet er lite, og prosessen er det ikke. Et register med fem felt går gjennom samme mottak, prioritering og innkjøp som et kjernesystem, og kommer derfor aldri øverst på noen liste.
• Ingen eier det «lille». Store prosjekter har en sponsor. Et verktøy som hjelper elleve personer i én avdeling, har ingen som blir målt på om det finnes.
• Avdelingen har budsjett og et kort. Et abonnement er en utgift, ikke et prosjekt, og utgifter trenger ikke plattformteamet.
• Verktøyene ble gode. Å bygge noe som virker, er nå innen rekkevidde for en dyktig person som ikke er utvikler. Barrieren som tidligere, uten at noen hadde planlagt det, holdt utviklingen hos sentral IT, er borte.

Ingen av disse løses av en retningslinje som sier at ikke-godkjente verktøy er forbudt. De løses ved å korte ned køen — eller ved å innrømme at køen finnes og gi folk en støttet måte å bygge på i full åpenhet.

Risikoene som er reelle, i rekkefølge

Risikoregistre for skygge-IT åpner gjerne med etterlevelse og slutter med vage advarsler om sikkerhet. I praksis kommer feilene som faktisk skjer, i en ganske forutsigbar rekkefølge.

• Én person forstår det. Den vanligste feilen er ikke et innbrudd. Det er at Marit bygde det, Marit har sluttet, og ingen kan endre momssatsen.
• Det er ikke sikkerhetskopiert. En personlig disk, en bærbar PC, en gratisversjon uten lagringstid. Verktøyet fungerer helt til den dagen det ikke gjør det, og da finnes det ingen tidligere versjon å gå tilbake til.
• Tilgangen slutter ikke når ansettelsen gjør det. Firmakontoen forsvinner med sjekklisten for avslutning. Verktøyet som er bygget på en personlig pålogging, gjør ikke det — og det gjør heller ikke de delte passordene tre personer kan.
• Firmadata ligger i en personlig konto. Ikke selve verktøyet, men kundelisten i det, som ligger i noe registrert på en enkeltperson, utenfor alle avtaler organisasjonen deres har inngått.
• Ingen kan svare tilsynsmyndigheten. Når dere blir spurt om hvor personopplysninger behandles og hvem som har tilgang, er systemer dere ikke kjenner til, systemer dere ikke kan stå til ansvar for. Det er her bekymringen for etterlevelse er helt berettiget.
• Bærende, uten at noen merker det. Den ingen merker før en revisjon: et regneark som begynte som en bekvemmelighet og nå er den eneste oversikten over noe virksomheten er avhengig av.

Det som som regel ikke er risikoen

At verktøyet er amatørmessig, skader sjelden noen. Mange avdelingssystemer er stygge og helt tilstrekkelige for elleve personer. Legg innsatsen i hvor dataene ligger, hvem som kan nå dem, og hva som skjer når den som laget det, slutter — ikke i om brukergrensesnittet ville bestått en gjennomgang.

Finn det uten en heksejakt

Dere kan ikke styre det dere ikke ser, og dere kommer ikke til å se det hvis det første trekket er en gransking. Folk skjuler verktøy for revisorer og viser dem frem for kolleger. Innrammingen avgjør hvilket av dem dere får.

• Gi amnesti, og bruk ordet. Si rett ut at ingen får problemer, at målet er å beholde det som virker, og at alt som blir levert inn, blir sikkerhetskopiert og får støtte. Hold så ord, synlig, første gang noen setter det på prøve.
• Spør hva folk har laget, ikke hva de bruker. «Hva har du laget for å få gjort jobben din?» gir svar. «List opp programvaren din som ikke er godkjent» gir taushet.
• Følg utgiftene og påloggingene. Kortutskrifter og identitetsleverandørens liste over applikasjoner viser de fleste abonnementene uten at noen trenger å tilstå dem.
• Se etter de delte påloggingene. Et passord tre personer kjenner, er både et funn og en god inngang til en samtale om hva det beskytter.

Bestem hva som skjer med hvert av dem

Når dere har en liste, sorteres de fleste punktene raskt i fire hauger. Feilen er å behandle alt som om det hører hjemme i den første.

• Ta over. Det betyr noe, det virker, og det trenger en eier, sikkerhetskopi og pålogging med firmakontoen heller enn å skrives om. Det meste av listen havner her.
• Bygg på nytt. Det betyr noe, og dagens versjon kan virkelig ikke sikres — data i en personlig konto, eller logikk ingen kan følge. Bygg det ordentlig på nytt, og hold personen som laget det, involvert; de kjenner reglene programvaren uttrykker.
• Avvikle. Det løste et problem som ikke lenger finnes, eller to personer bruker det av gammel vane. Slå det av, med varsel.
• La være. Et regneark én person bruker til å organisere sitt eget arbeid, er ikke et system. Ikke alt trenger styring, og å støvsuge opp de harmløse er måten et amnesti mister troverdigheten sin på.

Gjør den godkjente veien til den raske

Alt over er opprydding. Det kommer tilbake med mindre regnestykket under endrer seg, fordi omveien bare noen gang vant på fart.

Det som endrer regnestykket, er en støttet måte å bygge små systemer på som er virkelig raskere enn den ustøttede — der pålogging med firmakontoen, drift, sikkerhetskopier og en oversikt over hvem som gjorde hva følger med når man bygger, i stedet for å komme som en gjennomgang til slutt. Når den godkjente veien er den raske veien, slutter skygge-IT å være et problem for retningslinjene og blir et lite fristende alternativ.

Det er dette Studio for Business finnes for: avdelinger får bygge verktøyet de trenger, på en plattform som allerede har enkel pålogging, administrert drift og revisjonslogg, slik at det de bygger, er synlig fra dagen det finnes i stedet for dagen det svikter. Men prinsippet gjelder uansett hva dere bruker — styring som er tregere enn alternativet, er styring folk går rundt.

Les videre

• Studio for Business — Styrt bygging med pålogging med firmakontoen og revisjonslogg
• Tilgang på radnivå forklart — Når verktøyene er kommet frem i lyset, er dette det neste spørsmålet
• Hvordan logger folk inn? — Entra, Google Cloud Identity og alt som støtter OpenID Connect