Å sikre en serverløs applikasjon kan føles overveldende. Man får fort en ekkel følelse av å ha glemt noe, spesielt når det er så mange mikrotjenester som kjører samtidig.
Dessverre kan jeg ikke si at du bare kan slappe av, men jeg kan peke ut noen typiske feil mange gjør.
Bruk dem gjerne som en sjekkliste, så kan du senke skuldrene et par hakk etterpå.
#1: Du tror at WAF tar hånd om alle sikkerhetsbehov
Tradisjonelt befinner brannmurer for nettbaserte apper (WAF) seg ved inngangen til nettverket, der den beskytter web- og applikasjonstjenester i skyen.
En WAF inspiserer web trafikk (HTTP/S), men er veldig statisk, som gjør oppdatering og vedlikehold krevende. Med andre ord kan nye trusler kan lettere få innpass.
Hva er egentlig serverless?
I tillegg benyttes det stadig oftere API-er for kommunikasjon mellom webapplikasjoner og funksjoner, samt mellom interne funksjoner i skynettverket ditt. Dermed kan det oppstå mange ubeskyttede eventer utløst av funksjoner i det interne skynettverket.
En WAF vil for eksempel ikke hjelpe hvis funksjonene dine blir utløst fra forskjellige eventkilder, slik som:
- Skylagrings-eventer (for eksempel AWS S3, Google Cloud Storage, Azure Blob lagring)
- Stream data processing (for eksempel AWS Kinesis)
- Endringer i databaser (for eksempel AWS DynamoDB, Azure CosmosDB)
- Kodemodifiseringer (for eksempel AWS CodeCommit)
- Varslinger (for eksempel SMS, e-post, IoT)
Du bør selvsagt ikke skrote WAF som førstelinjen i forsvaret ditt, men å anta at WAF tar seg av alt er en kritisk feil. Gjør du det, etterlater du mange gapende sikkerhetshull.
«Du må sette deg ned med utviklerne som skrev funksjonene og gå gjennom hva hver funksjon gjør.»
#2: Du dropper å tilpasse tillatelser
En vanlig sikkerhetsfeil i serverløse apper er å angi en policy som er bredere og gir flere tillatelser enn det som er nødvendig.
Hvis du ikke minimerer individuelle roller og tillatelser, gjør du angrepsflaten din større enn nødvendig.
Du må sette deg ned med utviklerne som skrev funksjonene og gå gjennom hva hver funksjon gjør. Først når dere har kartlagt hva de ulike funksjonene faktisk må gjøre, kan du opprette en unik rolle for hver funksjon og lage en passende tillatelses-policy.
Mener Javascript-utvikling har blitt «dependency-rodeo»
#3: Du tenker at din kode er all koden din
Skybaserte apper har ofte mange bibliotek og moduler, som igjen inneholder flere moduler. Derfor er det ikke uvanlig at en enkelt, serverløs funksjon inneholder titusenvis av kodelinjer fra ulike eksterne kilder - selv om utviklerne dine bare har skrevet rundt 100 linjer med kode.
I dag er mer enn 70 prosent koden som benyttes i ulike apper basert på åpne kilder.
Angripere prøver derfor å “forgifte brønnen” ved å bake ondsinnet kode inn i vanlige prosjekter, for eksempel på GitHub. Deretter venter de tålmodig mens den nye versjonen av koden tar seg inn i skyappene dine, der den kan få fotfeste i lang tid.
Det er ikke rart at de fleste sikkerhetskontroller for applikasjoner integrerer verktøy som Source Code Analysis (SCA) tidlig i utviklingsfasen. En forskningsrapport fra 2017 viste at 96 prosent av de mest brukte applikasjonene i en bedrift har åpen kildekode, og mer enn 60 prosent hadde sårbarheter som en følge av dette. Flere av disse sårbarhetene var over fire år gamle.
«Nå er jo de fleste utviklere mer skeptisk til phishing-kampanjer enn folk flest, men de er ikke immune.»
#4: Du tror du har kontroll på alle funksjonene dine
Svakheter i kode kan forbedres gjennom møysommelig integrasjon av applikasjonssikkerhet i CI/CD-pipelinen. Men kan du egentlig være sikker på at alle funksjonene dine gikk gjennom denne prosessen?
En grunn til at sikring av serverløse apper er vanskelig er at ondsinnede funksjoner kan lure seg inn på mange ulike måter.
De kan for eksempel skrives inn av en uærlig ansatt. Det er også mulig at utviklerne og deres maskiner blir angrepet, istedenfor selve appene.
Nå er jo de fleste utviklere mer skeptisk til phishing-kampanjer enn folk flest, men de er ikke immune. Og med tilgang til en utviklers arbeidsstasjon får en angriper mulighet til å opprette ondsinnede funksjoner gjennom legitime kanaler. Slike funksjoner kan snike seg inn og føre til stor ødeleggelse før de oppdages.
- Den viktigste sikkerhetsjobben er det utviklerne som gjør!
#5: Du ser på feil angrepsindikatorer
Synlighet blir vanskeligere i en serverløs verden. Mengden informasjon og ressurser øker betydelig, slik at det blir mer krevende å trekke ut innsikt fra all dataen.
Bare et par hundre funksjoner kan generere milliarder av eventer i loggen din, hver eneste dag. Da blir det vanskelig å filtrere ut de virkelig viktige og relevante signalene fra all den irrelevante støyen.
Og etter hvert som antallet funksjoner fortsetter å øke fra hundre til tusener, blir det bare mer uoverkommelig å kontrollere at alt oppfører seg slik du har tenkt.
Selv om du kjenner angrepsmønstrene for serverløse apper, klarer du ikke skalere opp den menneskelige scanningen til å overvåke all informasjonen. Her trenger du kunstig intelligens (KI) og maskinlæring.
Vi har sett hvordan KI kan bidra gjennom alt fra taleassistanse til selvdrevne biler, og denne teknologien utgjør også en stor forskjell når det gjelder å forbedre sikkerheten i skytjenester.
#6: Du gir funksjoner all verdens kjøretid
Å sette timeouts på funksjoner i serverløse apper er på ingen måte rett frem. Den maksimale varigheten til en funksjon kan være ganske spesifikk for nettopp den funksjonen.
«Med en kortere timeout må de angripe oftere, noe som gjør angrepet mer synlig.»
Mange utviklere setter timouten til det maksimalt tillatte. Og hvorfor ikke? ¯\_(ツ)_/¯ Vi betaler jo ikke for den tiden, så hvorfor ikke?
Jo, på grunn av sikkerhet.
Funksjoner burde ha begrenset kjøretid. Du må derfor vurderte den oppsatte timeouten versus funksjonens faktiske timeout. Hvis en angriper lykkes med å sette inn skadelige kode, får vedkommende mer tid til å gjøre mer skade jo lengre timeout du har.
Med en kortere timeout må de angripe oftere, noe som gjør angrepet mer synlig. Derfor må du ikke bare minimere hva en funksjon kan gjøre, men også hvor lenge den kan kjøre.
Jeg håper dette kan gi deg et bedre overblikk over hva du må passe på neste gang du skal sikre en serverløs applikasjon.
Lær deg SameSite:
- Brukes altfor lite!
Stian forteller deg hvorfor og hvordan du bruker SameSite på cookies-ene dine. 🍪