Sådan sikrer du din software mod sikkerhedstrusler
Hvorfor softwaresikkerhed ikke er noget, man ordner én gang
Mange virksomheder behandler sikkerhed som et tjekpunkt: man installerer en firewall, sætter et SSL-certifikat op og regner sig for færdig. Den tilgang holder ikke. Software er under konstant forandring, og det samme gælder truslerne imod den. Nye sårbarheder opdages løbende, og angribere udnytter dem hurtigt, ofte inden udviklere overhovedet er klar over, at problemet eksisterer.
Sikkerhed er i stedet en løbende praksis, der skal bygges ind i hele udviklingsprocessen fra start til slut. Det gælder uanset om du driver en simpel hjemmeside, en mobilapp eller et komplekst backend-system med mange integrationer.
De mest almindelige sikkerhedstrusler mod software
Før man kan forsvare sig, skal man forstå, hvad man forsvarer sig imod. Her er de angrebstyper, der oftest rammer software i praksis:
Injektionsangreb
SQL-injektion og lignende angreb sker, når brugerinput ikke valideres korrekt, og en angriber kan sende ondsindet kode direkte ind i databaseforespørgsler eller systemkald. Konsekvensen kan være, at data lækkes, ændres eller slettes fuldstændigt. Det er en af de ældste og stadig mest udbredte angrebsformer.
Brudt adgangskontrol
Når en bruger kan tilgå ressourcer eller funktioner, vedkommende ikke burde have adgang til, taler man om brudt adgangskontrol. Det sker fx, når man blot ændrer et tal i en URL og pludselig ser en anden brugers data, eller når administratorfunktioner ikke er korrekt beskyttet bag rollebaserede tilladelser.
Usikker konfiguration
Standardindstillinger i servere, databaser og frameworks er sjældent sikre ud af boksen. Åbne porte, for brede databaserettigheder, fejlmeddelelser der afslører teknisk information og ubrugte funktioner der stadig er aktive, er klassiske eksempler på konfigurationsfejl, der skaber unødvendige angrebsflader.
Svag autentifikation og sessionshåndtering
Korte eller forudsigelige adgangskoder, manglende to-faktor-autentifikation og sessioner der ikke udløber korrekt, giver angribere mulighed for at overtage konti. Det er et område, der undervurderes overraskende ofte, selv i systemer der ellers er velbyggede.
Tredjepartskomponenter med kendte sårbarheder
Næsten al moderne software bruger åben kildekode-biblioteker og eksterne pakker. Hvis disse ikke holdes opdaterede, kan kendte sikkerhedshuller i dem udnyttes direkte. Det gælder både frontend-pakker, backend-afhængigheder og containerimages.
Sikkerhed starter i koden
Den mest effektive måde at undgå sikkerhedsproblemer på er at bygge dem ud fra begyndelsen, ikke at lappe dem bagefter. Det kaldes "security by design" og indebærer, at man tænker sikkerhed ind i kravspecifikationen, arkitekturen og den daglige kodepraksis.
Input-validering og output-kodning
Al data, der kommer udefra, skal betragtes som potentielt ondsindet. Det betyder, at alt brugerinput skal valideres på serversiden, ikke blot i browseren. Output skal kodes korrekt, så eventuel ondsindet kode ikke udføres. Parametriserede forespørgsler frem for dynamisk sammensatte SQL-strenge er et minimum.
Princippet om mindste privilegium
Enhver del af systemet, hvad enten det er en bruger, en tjeneste eller en proces, skal kun have adgang til præcis det, den har brug for og intet mere. En backend-tjeneste, der kun læser fra én tabel, behøver ikke skriveadgang til hele databasen. Det begrænser skaden markant, hvis en del af systemet kompromitteres.
Sikker håndtering af hemmeligheder
API-nøgler, adgangskoder til databaser og krypteringsnøgler hører aldrig hjemme i kildekoden. De bør opbevares i dedikerede hemmelighedshåndteringsværktøjer eller miljøvariabler, og adgangen til dem bør logges og begrænses. En nøgle, der er lækket til et versionskontrolsystem, skal betragtes som kompromitteret og skiftes øjeblikkeligt.
Hvis du er nysgerrig på, hvordan backend-arkitektur spiller ind på sikkerhed, giver denne gennemgang af API'er i backend-udvikling et godt overblik over, hvor sårbarhederne typisk opstår i kommunikationen mellem systemerne.
Kryptering og sikker datatransmission
Al kommunikation mellem klient og server bør foregå over HTTPS med gyldige certifikater. Det er i dag et absolut minimum og ikke en ekstra funktion. Derudover bør følsomme data krypteres i hvile, det vil sige i databasen, ikke blot under transport.
Adgangskoder må aldrig gemmes i klartekst. De skal hashes med en moderne og saltbaseret algoritme som bcrypt eller Argon2. Hvis din software stadig bruger MD5 eller SHA-1 til adgangskoder, er det et kritisk problem, der skal rettes.
Adgangskontrol og autentifikation
Implementér rollebaseret adgangskontrol, så brugere kun ser og kan gøre det, de har rettighed til. Hvert endpoint i dit API skal kontrollere, om den indkommende anmodning er autentificeret og autoriseret, ikke blot om brugeren er logget ind.
To-faktor-autentifikation bør være tilgængeligt for alle brugere og obligatorisk for administratorer. Sessioner skal have en fornuftig levetid og udløbe ved inaktivitet. Efter logout skal sessionstokens ugyldiggøres på serversiden, ikke blot slettes i browseren.
Afhængigheder og løbende opdateringer
Hold alle pakker og biblioteker opdaterede. Brug automatiserede værktøjer til at scanne dine afhængigheder for kendte sårbarheder, og integrer dem i din byggeproces, så du får besked med det samme, en sårbarhed opdages. Det gælder også infrastruktur som servere, containere og operativsystemer.
Har du en eksisterende platform, der trænger til et sikkerhedsmæssigt eftersyn, kan det være relevant at se nærmere på hvordan man optimerer en eksisterende softwareplatform uden at starte forfra.
Test og overvågning
Sikkerhedstest som del af udviklingsprocessen
Statisk kodeanalyse, automatiserede sårbarhedsscanninger og penetrationstest bør indgå som faste elementer i udviklingsforløbet. En penetrationstest, hvor en ekstern part forsøger at bryde ind i systemet på kontrolleret vis, giver et realistisk billede af, hvilke huller der faktisk kan udnyttes.
Logning og overvågning
Et system, der ikke logges, er et system, man ikke kan forsvare. Sørg for at logge fejl, adgangsforsøg, API-kald og usædvanlige mønstre. Opsæt alarmering, der giver besked ved unormal aktivitet, fx mange fejlede loginforsøg på kort tid eller uventede dataeksportmønstre. Logs skal opbevares sikkert og ikke være tilgængelige for den kompromitterede applikation selv.
Cloudbaserede systemer kræver særlig opmærksomhed
Hvis din software kører i skyen, er det vigtigt at forstå den delte ansvarsmodel: cloududbyderen sikrer infrastrukturen, men du er ansvarlig for, hvad du bygger og konfigurerer ovenpå. Fejlkonfigurerede opbevaringscontainere med offentlig adgang og for brede IAM-rettigheder er klassiske fejl i cloudmiljøer. Du kan læse mere om overvejelserne bag cloudopsætninger i guiden til cloud-løsninger i backend-udvikling.
Hvad sker der, hvis det går galt?
Selv med gode sikkerhedsforanstaltninger kan der opstå hændelser. Derfor bør alle virksomheder have en hændelsesresponsplan, der beskriver, hvad man gør, hvem der kontaktes, og hvordan man kommunikerer udadtil. En plan, der aldrig er testet, er sjældent effektiv i praksis. Kør simuleringer og gennemgå planen jævnligt.
Dataminimering er også en del af risikostyringen: jo mindre følsomt data du opsamler og gemmer, jo mindre skade sker der ved et brud. Gem kun det, du faktisk har brug for, og slet det, når formålet er opfyldt.
Sikkerhed er et fælles ansvar
Softwaresikkerhed er ikke udelukkende et teknisk anliggende. Medarbejdere skal kende grundlæggende sikkerhedspraksis, fx at undlade at dele loginoplysninger, genkende phishing-forsøg og vide, hvem de skal kontakte ved mistanke om et brud. Det tekniske fundament er afgørende, men menneskelige fejl er stadig en af de hyppigste årsager til sikkerhedshændelser.
Sikkerhed skal heller ikke stoppe ved det, man selv bygger. Leverandører og tredjepartsintegrationer bør vurderes ud fra deres sikkerhedspraksis, og kontraktmæssige forpligtelser bør afspejle de krav, du stiller til dine egne systemer.
Kom godt i gang
Det kan virke overvældende at sætte sig ind i alle aspekter af softwaresikkerhed på én gang. Et godt udgangspunkt er at kortlægge, hvilke data din software håndterer, hvem der har adgang til hvad, og hvilke dele af systemet der vender ud mod internettet. Derfra kan man prioritere de tiltag, der giver størst effekt i netop din kontekst.
Arbejder du med et softwareprojekt og er usikker på, om sikkerheden er i orden, kan det være værd at tage en snak med et udviklingsmiljø, der har erfaring med sikker softwareudvikling. Sahari er et softwarestudie i Aarhus, der arbejder med netop den type projekter, og du er velkommen til at række ud, hvis du vil høre nærmere.