Agil utvikling, DevOps, kanskje til og med DevSecOps – dette er emneknagger som det diskuteres rundt ofte. Hvordan kan disse tjenestene gjøres tryggere og mer hardføre?

Les videre, så får du fem gode tips til å holde mikrotjenester sikre.

1. Ikke bygg et korthus

Mikrotjenester er ofte satt i det samme nettverket som resten av mikrotjenestene, og dersom én av tjeneste har en alvorlig sårbarhet, kan det påvirke resten av tjenestene. Dette gjelder også administratortilgang til nettverket. Det er viktig at tjenestene utvikles med prinsipper som "Principle of Least Privilege" og segmentering.

Et eksempel på "Principle of Least Privilege" er at en mikrotjeneste som aksesserer database eller API, eksplisitt har fått definert hvilke tilganger den har mot datasettene; ofte kalt en hviteliste over tilganger, basert på det absolutte minimum som trengs for at tjenesten skal virke.

Eksempelvis kan dette være en egen databasebruker for tjenesten som kun har tilgang til å hente og oppdatere data for de aktuelle tabellene i databasen som applikasjonen trenger. Med andre ord, ikke nødvendigvis tilgang til å hente ut brukerdata eller kjøre kommandoer på operativsystemet.

Ha et godt system for å dokumentere tilganger, samt et test- og staging-system som tillater effektiv testing av segmentering og "Principle of Least Privilege".

2. Bygg et godt DevSecOps-miljø

Agil utvikling og mikrotjenester går ofte hånd i hånd. CALMS er et fint program for å bygge et godt DevSecOps-program.

C – Culture – Kultur

Det er viktig å bygge kultur mellom drift, sikkerhet og utvikling, på grunn av de raske kravene til rask produksjonssetting av ny funksjonalitet og reparasjon av feil. Det er dessuten viktig at skillene mellom de forskjellige disiplinene minskes gjennom utdanning, og at samarbeid mellom dem kan økes.

A – Automation – Automasjon

Utviklere må tenke automasjon i sine tjenester. Tjenester kan komme og gå, og bør starte som normalt uten for mye restriksjoner rundt miljø og konfigurasjon. Automatisk testing av sårbarheter under utvikling og testing er en effektiv måte å hindre mange av de enkle feilene som fremdeles havner i produksjonsmiljøer den dag i dag.

L – Lean – Veltrimmet

Kravene til det endelige produkt, samt utfall av prosesser som trusselmodellering, bør falle naturlig inn i utviklingsløpet. Utvikling bør fokusere på kjerneverdiene til tjenesten som skal settes i drift, og dessuten ta høyde for sikkerhet fra start til slutt i utviklingsløpet.

M – Measurement – Måling

På grunn av raske endringer i applikasjonene er det vanligvis mindre forutsigbarhet med hensyn til kvalitet og sikkerhet. Det er da essensielt å måle og overvåke hvordan applikasjonen oppfører seg, samt om det pågår hacking eller er identifisert nye sårbarheter. Det finnes mange gode overvåkningsløsninger som enkelt lar seg integrere i DevOps-miljøene og i mikrotjenester.

S – Sharing – Deling

Deling er litt tilbake igjen til kultur, men det er også snakk om å dele trusseldata. Eksempelvis dersom det oppdages nye teknikker og sårbarheter mot våre tjenester og plattformer; da er det viktig at utviklernes backlogger blir raskt fylt opp med prioriteringene for å begrense de potensielle skadene.

3. Programmer defensivt

Programmererne har uten tvil mye ansvar for sikkerheten i tjenestene vi setter ut. Drift og andre tiltak som settes inn, kan begrense og fjerne noe av risikoen, men til syvende og sist har utviklerne vanligvis det største ansvaret for å sikre at tjenestene ikke blir misbrukt. Applikasjonsstandarder som OWASP sin ASVS hjelper med å sette søkelys på gode utviklingsrutiner, samt planlegging av sikkerhetstiltak som tjenestene bør inneha.

Utviklerne må skjerpe sine innstillinger med hensyn til hvilken input og output som tjenestene aksepterer. Man skal ikke automatisk stole på innkommende og utgående data, men i stedet forsiktig og tydelig definere hvilken data som forventes.

Eksempelvis en IP-adresse som skal sendes til applikasjonen, krever tall, punktum og kanskje A-F + kolon dersom det er IP versjon 6. Applikasjonen skal på en riktig måte avbryte henvendelsen fra brukeren dersom noe annet blir definert. Det samme gjelder output av applikasjonen. Den må forsiktig defineres slik at den passer til forbrukeren av data og ikke tilfører noen risiko for dem.

4. Bruk beste praksis for infrastruktur og mellomvare

Mikrotjenester kan ofte utvikles i serverløse miljøer, for eksempel Azure Functions, Google Cloud Functions eller Amazon Lambda. Slike miljøer minsker angrepsflaten drastisk; for eksempel er det ingen server å scanne for sårbarheter, samt applikasjonens instans har en veldig kort levetid og tas opp og ned som mikrotjenesten måtte ønske. Det er bygd inn automatisk skalering og høy tilgjengelighet i de fleste serverløse miljøer, noe som gjør at vi henter store besparelser med hensyn til operasjonelle kostnader.

I miljøer hvor våre mikrotjenester tas i bruk på serverinfrastruktur, bør det tas høyde for:

• Effektive patche-rutiner for biblioteker, som for eksempel Javascript og andre programmeringsspråk. Det brukes til stadighet nye biblioteker, gjerne med hundretusenvis av linjer med kode, og som gjerne har innebygde svakheter i seg. Det er viktig å kartlegge bruken av slike avhengigheter i applikasjonene våre, slik at de raskt kan oppdateres når nye svakheter er blitt identifisert.

• Mellomvare som for eksempel API Gateways, sikkerhetsheaders og god konfigurasjon på webserver-infrastruktur.

5. Overvåkning

Det er viktig å holde systemene under kontinuerlig observasjon, spesielt med mange raske deployments, som DevOps fører med seg. Mikrotjenestene som utvikles bør, via gode bibliotek og rammeverk, inneha logging som tillater den nødvendige overvåkningen.

Logging bør tillate god oversikt over hendelser som oppstår i applikasjonen, og blant annet ha fokus på:

• Hendelser rundt autentisering og autorisasjon. Det bør tydelig fremgå hvem som tar seg tilganger i tjenesten, samt hvilke objekter det gis tilgang til. Tilganger som feiler er også nyttig å ta med i loggingen.

• Alle endringer i privilegier, f.eks. brukerstyring, må logges. En mikrotjeneste er kanskje ansvarlig for noe som kan tilføre eller fjerne tilganger for andre, og det er da viktig at nødvendige logger produseres for å tillate overvåkning av dette.

• Adgang til sensitiv eller beskyttet data må også logges. Ved undersøking av hendelser er det nyttig å kunne spore tilbake til hvilken data som er blitt aksessert for enklere å begrense skadeomfanget til en hendelse.

Ideelt sett ønsker man å se på endringer i brukermønster også. Det å sammenligne datasett time for time, eller fra dag til dag, tillater oss av og til å identifisere nye feil og avvik som oppstår.

Du er kanskje også interessert i: