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.
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".
Agil utvikling og mikrotjenester går ofte hånd i hånd. CALMS er et fint program for å bygge et godt DevSecOps-program.
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.
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.
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.
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.
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.
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.
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:
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å:
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: