En nettside laget med AI kan være trygg å bruke, men verktøyet som skrev koden er ingen sikkerhetsgaranti. Det avgjørende er hvilke data løsningen behandler, hvem som får tilgang til dem, og hvordan utvikling og drift følges opp. En pen demonstrasjon viser bare en liten del av dette.
Du trenger ikke være utvikler for å stille gode spørsmål. Be om konkrete forklaringer og demonstrasjoner knyttet til din løsning. En enkel presentasjonsside, en nettbutikk og en kundeportal har forskjellige behov og bør vurderes deretter.
Skill mellom AI som bygger og AI som behandler kundedata
ChatGPT, Claude eller et annet AI-verktøy kan brukes til å utvikle kode uten å være en del av den ferdige løsningen. Da handler en viktig del av vurderingen om hva som deles under utviklingen: krav, kildekode, skjermbilder og eksempeldata. Kundelister, passord og fortrolige opplysninger bør ikke ukritisk legges inn i en samtale.
Hvis selve nettstedet har en AI-chat, oppsummerer kundesamtaler eller analyserer opplastede dokumenter, oppstår en annen datastrøm. Da må dere kartlegge hva som sendes hvor, hvem som har tilgang, og hvordan opplysninger lagres og slettes. Kontotype, innstillinger og avtaler må vurderes konkret. Det holder ikke å anta at alle AI-tjenester behandler data likt.
Et praktisk utgangspunkt er å bruke fiktive eksempeldata i utviklingen og bare dele opplysninger som trengs for oppgaven. Hvis løsningen krever personopplysninger eller fortrolig materiale, må rammene avklares før disse opplysningene brukes.
Innlogging må følges av riktig tilgang
At en bruker må logge inn, sier ikke alene hvilke opplysninger brukeren kan hente. En kunde skal bare få tilgang til informasjonen vedkommende har rett til å se. Å skjule en knapp i nettleseren beskytter ikke data hvis de fortsatt kan hentes direkte fra systemet.
Tilgang må kontrolleres der dataene håndteres. OWASP anbefaler kontroll av rettigheter på hver forespørsel og at tilgang avslås som utgangspunkt. Se veiledningen om tilgangsstyring.
Et tenkt eksempel: Dere skal lansere en portal der kundene ser tilbudene sine. Be leverandøren teste med to separate testkunder og en ansattrolle. Kunde A skal ikke kunne lese kunde Bs tilbud, heller ikke ved å endre en adresse eller gjenbruke en lenke. Når en ansatt mister tilgangen, skal den også slutte å virke i praksis. Bruk fiktive tilbud i demonstrasjonen.
Passord og hemmelige nøkler skal holdes utenfor den offentlige koden
Noen integrasjoner bruker hemmelige nøkler til å sende e-post, hente data eller utføre betalinger. Slike nøkler må håndteres som tilgang til tjenesten. De skal ikke ligge i kode som sendes til besøkendes nettleser eller i et offentlig kodearkiv.
Be om å få forklart hvor hemmelighetene lagres, hvem som kan bruke dem og hvordan de byttes hvis de blir eksponert. Noen tjenester har også offentlige identifikatorer som er ment for nettleseren; leverandøren må kunne skille disse fra hemmelige nøkler. OWASPs veiledning om hemmeligheter beskriver prinsipper for tilgang og håndtering gjennom hele levetiden.
En sikkerhetsskanning er ett kontrollpunkt
Automatiske verktøy kan finne kjente sårbarheter, mistenkelige mønstre og feil i oppsettet. De kjenner ikke nødvendigvis bedriftens regler: hvem som skal få rabatt, når en ordre skal regnes som betalt, eller hvilke opplysninger en samarbeidspartner skal få se.
Lovable beskriver egne sikkerhetskontroller, men understreker at de ikke erstatter en grundig gjennomgang. Ansvaret må tilpasses bruksområdet. Se Lovables sikkerhetsdokumentasjon. Det samme praktiske spørsmålet bør stilles uansett verktøy: Hvilke feil er det faktisk testet for i denne løsningen?
Be om tester av handlinger som avbrytes eller gjentas. Hva skjer hvis en bestilling sendes to ganger, en betaling blir avvist eller forbindelsen til regnskapet stopper? For løsninger med følsomme data eller stor konsekvens ved feil bør en særskilt sikkerhetsgjennomgang inngå i vurderingen.
Nettbutikkens regler må kontrolleres på serveren
I en skreddersydd nettbutikk må serveren kontrollere pris, rabatt og gyldige produktvalg. Kundens nettleser kan vise beregningen, men skal ikke bestemme hva som faktisk belastes. Ordren må ta vare på prisen og produktvalgene som ble avtalt, selv om produktet endres senere.
Test hva som skjer når to kunder bestiller siste vare samtidig, og når samme betalingsmelding mottas flere ganger. En gjentatt melding skal ikke opprette en ekstra ordre eller dobbelt levering. Ansatte trenger sporbar status og en måte å håndtere avvik på. Se OWASPs veiledning om sikkerhet i forretningslogikk.
Statisk nettside betyr fortsatt ansvar for drift
En statisk Astro-side kan servere ferdige sider uten at et publiseringssystem må bygge dem for hvert besøk. Det kan redusere deler av angrepsflaten. Den samlede risikoen avhenger likevel av resten av oppsettet: skjemaer, filer, tredjepartsskript, server, kontoer og verktøyene som publiserer siden.
På vår egen nettside har vi beholdt enkelte WordPress-funksjoner bak Astro-frontenden. De trenger fortsatt oppdateringer og oppfølging. Et teknologibytte fritar oss ikke fra å vedlikeholde delene som fortsatt er i bruk.
Avtal hva som skjer når noe går galt
En sikkerhetskopi er mest verdifull når noen vet at den kan gjenopprettes. Avklar hva som kopieres: kode, database, opplastede filer og nødvendige innstillinger. Versjonshistorikk for kildekoden erstatter ikke sikkerhetskopi av kundedata eller bestillinger.
PostgreSQL er en database, mens Supabase tilbyr en plattform rundt blant annet PostgreSQL, innlogging og fillagring. En administrert tjeneste overtar deler av driften, men dere må fortsatt ha riktige tilgangsregler og en plan for gjenoppretting. Supabase opplyser for eksempel at databasebackup ikke inkluderer selve filene i Storage. Bilder og dokumenter må derfor omfattes av en egen plan. Se Supabases backupdokumentasjon.
Avtalen bør også si hvem som mottar feilvarsler, hvem som kan sette tilbake en tidligere versjon, og hvor lenge virksomheten tåler å være uten løsningen. Be om en gjenoppretting i et testmiljø. Da blir forskjellen mellom en lagret kopi og en fungerende beredskap tydelig.
Be om disse svarene før lansering
- Hvilke data samles inn, og hvilke tjenester mottar dem?
- Hvem kan lese, endre og slette opplysningene?
- Hvilke kritiske handlinger og feiltilfeller er testet?
- Hvordan håndteres oppdateringer, sikkerhetskopier og gjenoppretting?
- Hvem har ansvar etter lansering, og hvordan får dere hjelp?
Bruk svarene i valg av leverandør og driftsavtale. For bakgrunnen for vår arbeidsmåte, les hvorfor vi bygger mer med Astro og AI. Skal dere velge en helt ny løsning, gir gjennomgangen av kundereisen et godt oppdragsgrunnlag.
