Kako da zaštitite mikroservise unutar svoje aplikacije

Kao što verovatno već znate, mikroservisna arhitektura deli aplikacije na nekoliko nezavisnih servisa koji među sobom komuniciraju preko definisanih interfejsa. To je popularan pristup za postavljanje, prvenstveno cloud-native aplikacija, jer vam on omogućava da skalirate svaki deo aplikacije posebno, bez uticaja na ostale komponente.

Tradicionalne monolitne aplikacije su često teške za održavanje, jer njihove logičke komponente rade kao jedna komponenta, sa samo jednim servisom koji toj aplikaciji daje njenu funkcionalnost.

Kao primer možemo uzeti recimo e-commerce aplikaciju: kod ovog tipa servisa monolitna aplikacija može u jednom servisu nuditi i autentifikaciju i plaćanje. Međutim, razdvajanje tih komponenti u dva mikroservisa omogućava mnogo efikasnije upravljanje i održavanje svakom celinom posebno. Ovo je i logično, jer ćete uvek imati više ulogovanih korisnika, nego korinsika koji će na kraju i izvršiti plaćanje. Takvom podelom možete po potrebi lako skalirati servis za autentifikaciju, bez izmene na strani servisa za plaćanje.

Međutim, iako podela aplikacije na mikroservise donosi povećanu fleksibilnost, sa druge strane donosi i povećan rizik po bezbednost aplikacije. Drugim rečima, više mikro-komponenti znači ujedno i više posla oko njihove zaštite.

Ipak, to ne treba da vas uplaši. Primenom najboljih praksi i proaktivnim pristupom, zaštita vaših mikroservisa ne mora da bude obavezno težak zadatak.

Zato ćemo u ovom tekstu objasniti kako da najbolje zaštitite mikroservise u svojim aplikacijama.

Važnost zaštite mikroservisa

Kako smo već pomenuli u uvodu, mikroservisi su samostalne aplikacije koje zajedno formiraju funkcionalnosti koje su dostupne klijentu. Bez primene mikroservisa sistemi su uglavnom implementirani kao monolitna komponenta koja je zadužena za svaku funkcionalnost unutar tog sistema/aplikacije.

Sa mikroservisnom arhitekturom, imate na raspolaganju više komponenti od kojih je svaka zadužena za određeni deo funkcionalnosti, a koje pritom međusobno komuniciraju putem zajedničkog interfejsa.

Više ulaznih tačaka

Iz prethodno navedenog logično se nameće zaključak da model mikroservisa kreira i više mogućih ulaznih tačaka u vaš sistem. To ujedno znači i veći rizik od zloupotrebe nekih potencijalnih ranjivosti sistema. Što je više takvih tačaka, to je veći potencijalni rizik kojem je vaša aplikacija izložena. Iz tog razloga je kod mikroservisne arhitekture akcenat upravo na zaštiti pojedinačnih mikroservisa i veza među njima.

Veliki broj servisa

Poseban izazov u zaštiti mikroservisa je veličina koju određeni sistemi mogu dostići. Na primeru e-commerce platforme koju smo malopre pomenuli, većina e-commerce sistema će imati i dodatne servise pored web API-a, servisa za autentifikaciju i platforme za plaćanje.

U tom slučaju, biće potrebno da uvedete što više zasebnih servisa, kako biste iskoristili sve benefite mikroservisne arhitekture.

Takođe, nije neobično da se današnji sistemi sastoje od stotina zasebnih komponenti koje su implementirane kao zasebni mikroservisi. Sa toliko zasebnih delova, povećavaju se i šanse za greške, pa je zato izuzetno važno da svaki od tih mikroservisa bude i adekvatno zaštićen.

Kada je reč o zaštiti mikroservisa, postoje četiri osnovne oblasti na koje treba obratiti pažnju:

Kontrolisani pristup mikroservisima: Ovaj pristup podrazumeva da mikroservisi treba da budu izolovani od spoljnih mreža, osim ako nisu posebno namenjeni za pristup krajnjih korisnika. Čak i ako vaš API, web sajt i CDN treba da budu otvoreni, javni korisnici ne bi trebalo direktno da pristupaju vašoj usluzi plaćanja ili hostu baze podataka.

Kontrola pristupa između mikroservisa: Kontrolisanje pristupa između mikroservisa jednako je važno, jer to smanjuje oblast širenja u slučaju da je jedan servis ugrožen. Servisi koji se ne pozivaju međusobno bi trebalo da budu i fizički izolovani. U tom slučaju, ako napadač dobije pristup vašem sloju za autentifikaciju, neće moći neovlašćeno da kontaktira vaš sistem za plaćanje.

Provera sadržaja kontejnera mikroservisa: Sav trud koji uložite u ojačavanje mikroservisne arhitekture biće uzaludan ako radni zadaci unutar vaših kontejnera imaju neke ranjivosti. Redovan monitoring liste paketa, korišćenje automatizovanih alata za skeniranje zavisnosti i pridržavanje najboljih praksi za bezbednost kontejnera pomoći će u smanjenju rizika od kompromitovanja kontejnera.

Okruženje za implementaciju: Bezbednost vaših mikroservisa zavisi od vaših standarda bezbednosti i od toga koliko je sigurno vaše okruženje za implementaciju. Zadaci koji spadaju u one od vitalnog značaja za funkcionisanje vaše aplikacije, trebalo bi da se implementiraju samo na pouzdanim cloud lokacijama koje pritom ispunjavaju sve vaše bezbednosne standarde. Neće biti na odmet ni zaštita vaših naloga pomoću višefaktorske autentifikacije, postavljanje kontrole pristupa na osnovu definisanih rola, kao i redovno rotiranje ključeva i sertifikata.

Važno je da imate u vidu da ne postoji jedinstveni način za zaštitu vaših mikroservisa ili vaših aplikacija. Ipak fokus na pristupe koje ćemo predstaviti u nastavku teksta olakšaće otkrivanje potencijalnih ranjivosti u ranom stadijumu.

Kontrola pristupa mikroservisima (sever-jug)

Kontrola pristupa mikroservisima, poznata i kao kontrola pristupa na nivou mikroservisne arhitekture „sever-jug“ (engl. north-south), odnosi se na strategije i mehanizme za upravljanje pristupom mikroservisima sa spoljnih tačaka kao što su klijenti, korisnički interfejsi ili drugi mikroservisi. Ovaj tip kontrole pristupa fokusira se na komunikaciju između spoljnih klijenata i mikroservisa.

Evo nekoliko ključnih elemenata i pristupa vezanih za kontrolu pristupa mikroservisima „sever-jug“:

• Autentifikacija: Proces provere identiteta korisnika ili servisa koji pristupa mikroservisu. Ovo se može postići putem različitih mehanizama, uključujući lozinke, JWT (JSON Web Tokens), OAuth i drugi.
• Autorizacija: Definisanje pravila i politika koje određuju koji korisnici ili servisi imaju dozvolu da pristupe određenim resursima ili izvrše određene akcije unutar mikroservisa. Autorizacija se može izvršiti na osnovu uloga, privilegija ili drugih kriterijuma.
• Kontrola pristupa na nivou mreže: Implementacija sigurnosnih mehanizama na nivou mreže kako bi se ograničio pristup mikroservisima sa spoljnih mreža. Ovo može uključivati firewall, VPN (Virtual Private Network) i druge tehnologije.
• API gateway: Korišćenje centralizovanog API gateway-a koji služi kao ulazna tačka za sve zahteve klijenata ka mikroservisima. API gateway može implementirati autentifikaciju, autorizaciju, validaciju i druge funkcionalnosti za kontrolu pristupa.
• Token-based security: Korišćenje tokena za autentifikaciju i autorizaciju pristupa mikroservisima. Ovi tokeni mogu biti generisani putem servisa za autentifikaciju kao što su OAuth ili JWT, i mogu sadržati informacije o korisniku, roli ili privilegijama.
• Pravilno upravljanje identitetima: Efikasno upravljanje identitetima korisnika i servisa u mikroservisnoj arhitekturi, uključujući pravilno skladištenje, enkripciju i rotaciju kredencijala.

Kontrola internih komunikacija između mikroservisa (istok-zapad)

Kontrola internih komunikacija između mikroservisa „istok-zapad“ (engl. east-west) odnosi se na strategije i mehanizme za upravljanje pristupom unutar mikroservisne arhitekture, tj. komunikaciju između samih mikroservisa unutar sistema.

Evo detaljnog pregleda kako se kontrola pristupa može implementirati u ovom kontekstu:

• Mikroservisni mesh: Korišćenje mikroservisnog mesh-a kao centralizovanog mehanizma za upravljanje komunikacijom između mikroservisa. Ovaj pristup omogućava centralizovanu kontrolu i transparentnu enkripciju komunikacije između svih mikroservisa u arhitekturi.
• Sigurnost na novou transportnog sloja: Implementacija sigurnosnih mehanizama na nivou transportnog sloja sa ciljem da se obezbedi sigurna komunikacija između mikroservisa. Ovo može uključivati korišćenje TLS (Transport Layer Security) enkripcije za zaštitu podataka tokom prenosa.
• Politike sigurnosti za mikroservise: Definisanje politika sigurnosti na nivou mikroservisa koje određuju koje mikroservise može pozivati svaki mikroservis, kao i koji tipovi zahteva su dozvoljeni. Ove politike se mogu implementirati kroz alate za upravljanje konfiguracijom ili centralizovane sisteme upravljanja pristupom.
• Identitet i autentifikacija: Korišćenje identiteta i autentifikacije na nivou mikroservisa kako bi se osiguralo da samo ovlašćeni mikroservisi mogu da komuniciraju jedni s drugima. Ovo može uključivati razmenu sigurnosnih tokena ili korišćenje mehanizama poput mTLS (mutual TLS) autentifikacije.
• Autorizacija na nivou resursa: Definisanje pravila autorizacije na nivou resursa unutar mikroservisa kako bi se osiguralo da samo određeni mikroservisi imaju pristup određenim funkcionalnostima ili podacima. Ovo se može postići kroz kontrolu pristupa na osnovu rola ili privilegija.
• Monitoring i detekcija potencijalnih pretnji: Implementacija sistema za monitoring i detekciju potencijalnih pretnji kako bi se otkrile neovlašćene aktivnosti ili pokušaji napada na internu komunikaciju između mikroservisa. Ovo može uključivati korišćenje alata za praćenje saobraćaja, detekciju anomalija i reagovanje na incidente.

Provera mikroservisa pre implementacije

Kao što znamo, lanac je jak samo toliko koliko i najslabija karika u lancu. Ranjivost u paketu koji koristi jedan od vaših servisa mogla bi biti iskorišćena da napadaču omogući pristup i ostalim servisima.Detaljna provera vaših kontejnera pre nego što ih implementirate u vaše okruženje, može pomoći u ublažavanju ovih rizika.

Automatizovane tehnike testiranja bezbednosti poput DAST, SAST i IAST mogu biti iskorišćeni za otkrivanje mogućih nedostataka u vašem kodu. Takođe, skeneri ranjivosti mogu pomoći u identifikaciji zastarelih paketa u vašim kontejnerskim image-ima.

Ipak, važnije od svega navedenog je usvajanje odgovarajućeg bezbednosnog standarda na nivou kompanije. On može doprineti tome da i developeri, operateri i menadžeri projekta moraju prvenstveno dati prioritet bezbednosti, sa ciljem da se preduprede sve potencijalne slabosti sistema. U skladu s ovim pristupom, trebalo bi da obezbedite da vaši mikroservisi budu pravilno zaštićeni još u fazi razvoja aplikacije.

Na kraju, treba imati u vidu da nisu sve ranjivosti koje detektujete nužno primenljive na kontekst u kojem se implementiraju vaši servisi, ali rešavanjem što većeg broja problema u fazi pre implementacije, odnosno ažuriranjem pogođenih paketa i odabirom bezbednijih alternativa, bez sumnje smanjujete rizik da potencijalno maliciozan kod na kraju dospe na produkciju.

Ojačajte svoje cloud okruženje

Ojačavanje okruženja u kojem se nalazi vaša aplikacija je poslednji element bezbednosti mikroservisa. Osnovne mere bezbednosti u cloud-u (npr. ograničavanje korisničkih privilegija i redovno rotiranje pristupnih tokena) spadaju svakako među najvažnije, ali postoje i specifične, najbolje prakse za distribuirane sisteme poput Kubernetes-a.

Postavljanje Kubernetes RBAC-a

Kubernetes RBAC (Role-Based Access Control) je mehanizam koji administratorima omogućava da precizno upravljaju pristupom resursima unutar Kubernetes klastera. Ovaj sistem omogućava definisanje pravila i dozvola na nivou korisnika ili grupa korisnika, što omogućava bolju kontrolu nad pravima pristupa u sistemu.

Preporuka je da se ovaj mehanizam koristi za konfigurisanje pristupa za svakog korisnika u vašem klasteru. Ograničavanje naloga na minimalne privilegije koje zahtevaju njihove role, može poboljšati bezbednosne parametre. Osim smanjenja rizika u slučaju gubitka ili krađe pristupnih podataka, ovo ograničenje pruža i zaštitu u slučaju da se tokeni servisnog naloga kompromituju usled napada na third-party sisteme kojima su u međuvremenu distribuirani.

Enkripcija

Standardna Kubernetes distribucija ne enkriptuje podatke u stanju mirovanja. Umesto toga, osetljive lozinke, API ključevi i sertifikati koje čuvate unutar objekata se čuvaju u plaintext-u unutar instanci etcd klastera. To potencijalno može omogućiti lako iznošenje podataka od strane napadača.

Možete postaviti enkripciju za ove podatke konfigurišući Kubernetes API server da koristi jednog od dostupnih provajdera enkripcije. To se oslanja na EncryptionConfiguration objekat koji definiše standard enkripcije i tajni ključ koji treba koristiti.

Kada realno nema potrebe da koristite mikroservise?

Iako smo u ovom tekstu predstavili sve prednosti korišćenja mikroservisa, dobro je znati da mikroservisi nisu idealno rešenje za svaku situaciju. Važno je pažljivo razmotriti zahteve aplikacije i sposobnosti developerskog tima, pre donošenja odluke da li koristiti mikroservisnu arhitekturu. Iako mikroservisi mogu ponuditi značajne prednosti u određenim okolnostima, to nije rešenje koje je primenjivo na svaki model i možda nije pogodno za svaku aplikaciju.

Evo nekoliko scenarija u kojima mikroservisi možda nisu prikladni:

• Jednostavne aplikacije: Mikroservisna arhitektura može biti previše složena za jednostavne aplikacije koje ne zahtevaju visok nivo skalabilnosti ili modularnosti. U takvim slučajevima, monolitna arhitektura može biti dovoljna.
• Tesno povezane komponente: Ako su komponente aplikacije tesno povezane i zavise jedna od druge, može biti teško razdvojiti ih u mikroservise bez primene većih promena u dizajnu aplikacije.
• Ograničeni resursi: Implementacija mikroservisne arhitekture zahteva dodatne resurse, uključujući infrastrukturu, razvojne i operativne resurse. Ako su resursi ograničeni, možda nije ni izvodljivo implementirati i upravljati mikroservisima.
• Aplikacije sa niskom stopom saobraćaja: Ako aplikacija ne prima veliki obim saobraćaja, prednosti mikroservisa, poput skalabilnosti i otpornosti na greške, možda neće biti potrebne za vašu aplikaciju.
• Organizaciona ograničenja: Implementacija mikroservisne arhitekture zahteva značajne organizacione promene, uključujući promene u procesima razvoja, testiranja, implementacije i operacija. Ako organizacija nije spremna da napravi ove promene, možda primeni mikroservisa nije najbolje rešenje.

Zaključak

Kao što ste videli, mikroservisna arhitektura pruža brojne prednosti u razvoju i održavanju aplikacija, omogućavajući veću skalabilnost i modularnost. Međutim, sa sobom nosi i određene izazove, posebno u pogledu bezbednosti. Zato, pre nego što se odlučite za korišćenje mikroservisne arhitekture, važno je da pažljivo razmotrite specifične zahteve aplikacije i sposobnosti vašeg tima, kako bi ste osigurali da je ova arhitektura adekvatno rešenje za vaš sledeći projekat.