Razlike

Slijede razlike između dviju inačica stranice.

--- racfor_wiki:forenzika_mikroservisa_baziranih_na_spremnicima [2020/12/24 16:02]
tbaric [Forenzika spremnika]
+++ racfor_wiki:forenzika_mikroservisa_baziranih_na_spremnicima [2024/12/05 12:24] (trenutno)
@@ Redak 30: / Redak 30: @@
 {{ :racfor_wiki:scaling-microservices.png?600 |}}
-  * Decentralizirani podaci. Svaka usluga može koristiti posebnu bazu podataka. Ako se uzme primjer sa slike iznad, za korisničke usluge, podaci se mogu spremati u bazi s jednostavnom ključ-vrijednost formatom, usluge plaćanja mogu koristiti klasičnu relacijsku bazu poput MySQL baze, a usluge dostave neku drugu NoSQL bazu.
+  * Decentralizirani podaci. Svaka usluga može koristiti posebnu bazu podataka. Ako se uzme primjer sa slike iznad, za korisničke usluge, podaci se mogu spremati u bazi s jednostavnim ključ-vrijednost formatom, usluge plaćanja mogu koristiti klasičnu relacijsku bazu poput MySQL baze, a usluge dostave neku drugu NoSQL bazu.
-  * **Izolirani ispadi.** Greška u jednom mikroservisu ne ruši cijeli sustav. Kada se aplikacija koja se sastoji od slabo spojenih komponenata i mikrouservisa javi grešku, manja je vjerojatnost da će to utjecati na druge usluge jer se nalaze u vlastitim spremnicima i međusobno ne ovise u potpunosti. Monolitna aplikacija može srušiti cijeli proces aplikacije ako pogreška nije ispravno riješena.
+  * **Izolirani ispadi.** Greška u jednom mikroservisu ne ruši cijeli sustav. Kada se aplikacija koja se sastoji od slabo povezanih usluga javi grešku, manja je vjerojatnost da će to utjecati na druge usluge jer se nalaze u vlastitim spremnicima i međusobno nisu ovisne. Monolitna aplikacija može srušiti cijeli proces aplikacije ako pogreška nije ispravno riješena.
 ===== Sigurnost mikroservisa =====
-Iako upotreba mikroservisa rješava veliki dio problema monolitne arhitekture, njihova upotreba donosi vlastiti niz problema. Jedan bitan nedostatak je povećanje kompleksnosti arhitekture aplikacije. Mikroservisima treba veća koordinacija. Također će biti više mrežnih poziva u slučajevima kada treba komunicirati s drugim uslugama, što nije prisutno u monolitnim aplikacijama. Nije tako jednostavno kao postavljanje jedne instance aplikacije. Ostale stvari koje treba razmotriti su: kako postupati s komunikacijom između mikroservisa, riješiti greške kako bi se izbjeglo ometanje rada drugih mikroservisa i dodati više testnih slučajeva u svaku komponentu.
+Iako upotreba mikroservisa rješava veliki dio problema monolitne arhitekture, njihova upotreba donosi vlastiti niz problema. Ispostavlja se da nije tako jednostavno složiti funkcionalnu aplikaciju pomoću mikroservisa kao postavljanje jedne instance aplikacije. Jedan bitan nedostatak aplikacije u obliku mikroservisa je povećanje kompleksnosti arhitekture aplikacije. Mikroservisima treba veća koordinacija. Također, očekuje se više mrežnih poziva pri komunikaciji među uslugama, što nije prisutno u monolitnim aplikacijama. Ostali problemi koje treba razmotriti su: kako upravljati komunikacijom između mikroservisa, riješiti greške kako bi se izbjeglo ometanje rada drugih mikroservisa i dodati više testnih slučajeva u svaku komponentu.
-Jedno od područja gdje se očituje kompleksnost ovakve arhitekture jest sigurnost. Izgradnja bilo kojeg sigurnog sustava je izazvno. Klasični sigurnosni ciljevi su povjerljivost i cjelovitost podataka, autentifikacija entiteta i poruka, autorizacija i dostupnost sustava. Naravno, ovi apstraktni ciljevi mogu se ostvariti na mnogo različitih načina u praksi. Kako se ti ciljevi ostvaruju i do kojeg su stupnja odluke koje ovise o određenom modelu prijetnje, proračunu i stručnosti ovisne o infrastrukturi. Sigurnost mikroservisa višeslojni je problem i uvelike se oslanja na temeljne tehnologije i okruženje. Da bi se to riješilo, baš kao u sama aritektura aplikacije, sigurnost mikroservisa treba razgraditi na manje komponente. Radi lakše ilustracije složenosti problema sigurnosti bilo kojeg raspodijeljenog sustava (ovdje naglasak na mikroservisima), podijeljen je u šest kategorija ili **slojeva** uz primjere prijetnji vezane uz određeni sloj [4]:
+Jedno od područja gdje se očituje kompleksnost ovakve arhitekture jest sigurnost. Izgradnja bilo kojeg sigurnog sustava je izazovno. Klasični sigurnosni ciljevi su povjerljivost i cjelovitost podataka, autentifikacija entiteta i poruka, autorizacija i dostupnost sustava. Naravno, ovi apstraktni ciljevi mogu se ostvariti na mnogo različitih načina u praksi. Kako se ti ciljevi ostvaruju i do kojeg su stupnja odluke koje ovise o određenom modelu prijetnje, proračunu i stručnosti ovisne o infrastrukturi. Sigurnost mikroservisa višeslojni je problem i uvelike se oslanja na temeljne tehnologije i okruženje. Da bi se to riješilo, baš kao i samu aritekturu aplikacije, sigurnost mikroservisa treba razgraditi na manje komponente. Radi lakše ilustracije složenosti problema sigurnosti bilo kojeg raspodijeljenog sustava (ovdje naglasak na mikroservisima), podijeljen je u šest kategorija ili **slojeva** uz primjere prijetnji vezane uz određeni sloj [4]:
   * **Hadrware** - Skriveno pod apstraktnom perspektivom, ali i dalje problem pouzdanosti i sigurnosti. Hardverske su pogreške izuzetno opasne jer onesposobljavaju sigurnosne mehanizme drugih slojeva. Hardverski //backdoor// može se uvesti za vrijeme proizvodnje.
   * **Virtualizacija** - Napadi uključuju: bijeg iz pješčanika (//sandbox//), napade hipervizora i napade na zajedničku memoriju. Također, uporaba zlonamjernih i/ili ranjivih [[racfor_wiki:virtualizacija:docker-kontejneri|slika]] iz kojih se grade spremnici još je jedna ozbiljna sigurnosna briga.
   * **//Cloud//** - Računalna obrada u oblaku sa sobom donosi veliki broj sigurnosnih problema, uglavnom vezanih uz činjenicu da pružatelj usluga u oblaku ima neograničenu kontrolu nad svime što pokreće.
   * **Komunikacija** - Problem sigurnosti komunikacije svodi se na klasične mrežne napade. Oni uključuju: prisluškivanje (//sniffing//), lažno predstavljanje, otmica sesije, uskraćivanje usluge ([[racfor_wiki:mrezna_forenzika:dos_i_ddos_napadi|DoS]]), //Man in the middle// (MITM) napad i //Heartbleed// napad na TLS.
-  * **Usluga/Aplikacija** - Tipični i još uvijek vrlo česti sigurnosni problemi na razini aplikacije su ubrizgavanja SQL koda, neispravna provjera autentičnosti i kontrola pristupa, izloženost osjetljivih podataka, //Cross site scripting// (XSS), nesigurna deserijalizacija, pogrešna konfiguracija opće sigurnosti. OWASP svake godine objavljuje deset najkritičnijih sigurnosnih rizika web aplikacija.
+  * **Usluga/Aplikacija** - Tipični i još uvijek vrlo česti sigurnosni problemi na razini aplikacije su ubrizgavanja SQL koda, neispravna provjera autentičnosti i kontrola pristupa, izloženost osjetljivih podataka, //Cross site scripting// (XSS), nesigurna deserijalizacija, pogrešna konfiguracija opće sigurnosti. OWASP svakih par godina objavljuje deset najkritičnijih sigurnosnih rizika web aplikacija.
   * **Orkestracija** - Orkestracija podrazumijeva upravljanje, koordinaciju i automatizaciju zadataka povezanih s uslugama, uključujući raspoređivanje i grupiranje usluga. Struktura mreže mikroservisa može se kontinuirano mijenjati zbog zaustavljanja, pokretanja i premještanja usluga. Otkrivanje usluga (//Service discovery//) pruža središnju točku lociranja usluga nalik DNS-u. Napadi uključuju: ugrožavanje usluge otkrivanja, registriranje zlonamjernih čvorova u sustavu i preusmjeravanje komunikacije na njih.
 ===== Upravljanje i kontrola mikroservisa =====
-Ustanovljeno je da u okruženju mikroservisa, spremnici se konstantno gase i pokreću, što znači da imaju kratak rok trajanja i cijela struktura je vrlo dinamična. Spremnici zahtijevaju skup pomoćnih usluga, poput API poslužitelja, kao i sigurnosne mjere. Premještanje svih tih spremnika na poslužitelj i van njega, provjeravanje jesu li pravilno povezani, njihovo praćenje kako bi se nadogradnje aplikacija mogle neometano izvoditi - sve to je komplicirano. To dovodi do zaključka da je potreban alat, odnosno skup alata za upravljanje i kontrolu životnog ciklusa spremnika. U prethodnom poglavlju spomenuta je kategorija sigurnosti orkestracija. Kod spremnika, orkestracija pokriva puno više od same sigurnosti. Iako postoje brojni drugi, najrasprostranjeniji skup alata, koji je također //open-source//, za orkestraciju spremnika pod zajedničkim nazivom je **Kubernetes**. Objekti u koje Kubernetes sprema spremnike zovu se podovi. //Pod// je najmanji, osnovni raspoloživi objekt u Kubernetesu. Pod predstavlja jedan primjerak pokrenutog procesa u radnom klasteru. Podovi sadrže jedan ili više spremnika, recimo Docker spremnika. Kada Pod pokreće više spremnika, spremnicima se upravlja kao jedinstvenom entitetu i oni dijele resurse Poda, poput mrežnih i skladišnih resursa. Na primjer jedan pod nakon pokretanja prima jednu IP adresu. Prilikom pokretanja podova, Kubernetes obično pokrene više istih, redundantnih podova radi mogućnosti ispada i slično. Kubernetes pokreće radne procese postavljanjem spremnika u podove za izvođenje na čvorovima (//Nodes//). Čvor može biti virtualni ili fizički stroj, ovisno o okruženju. Svaki čvor sadrži usluge potrebne za pokretanje podova, kojima upravlja kontrolna sloj koji izlaže API i sučelja za definiranje, postavljanje i upravljanje životnim ciklusom spremnika. U nastavku je dana ilustracija strukture.
+Ustanovljeno je da u okruženju mikroservisa, spremnici se konstantno gase i pokreću, što znači da imaju kratak rok trajanja i cijela struktura je vrlo dinamična. Spremnici zahtijevaju skup pomoćnih usluga, poput API poslužitelja, kao i sigurnosne mjere. Premještanje svih tih spremnika na poslužitelj i van njega, provjeravanje jesu li pravilno povezani, njihovo praćenje kako bi se nadogradnje aplikacija mogle neometano izvoditi - sve to je komplicirano. To dovodi do zaključka da je potreban alat, odnosno skup alata za upravljanje i kontrolu životnog ciklusa spremnika. U prethodnom poglavlju spomenuta je kategorija sigurnosti orkestracija. Kod spremnika, orkestracija pokriva puno više od same sigurnosti. Iako postoje brojni drugi, najrasprostranjeniji skup alata, koji je također //open-source//, za orkestraciju spremnika pod zajedničkim nazivom je **Kubernetes**. Objekti u koje Kubernetes sprema spremnike zovu se //pod//ovi. //Pod// je najmanji, osnovni isporučivi objekt u Kubernetesu. //Pod// predstavlja jedan primjerak pokrenutog procesa u radnom klasteru. //Pod//ovi sadrže jedan ili više spremnika, npr. Docker spremnika. Kada //Pod// pokreće više spremnika, spremnicima se upravlja kao jedinstvenim entitetom i dijele se resursi //Pod//a, poput mrežnih i skladišnih resursa. Na primjer jedan //pod// nakon pokretanja poprima jednu IP adresu. Prilikom pokretanja //pod//ova, Kubernetes obično pokrene više istih, redundantnih //pod//ova radi mogućnosti ispada i slično. Kubernetes pokreće radne procese postavljanjem spremnika u //pod//ove za izvođenje na čvorovima (//Nodes//). Čvor može biti virtualni ili fizički stroj, ovisno o okruženju. Svaki čvor sadrži usluge potrebne za pokretanje podova, kojima upravlja kontrolni sloj koji izlaže API i sučelja za definiranje, postavljanje i upravljanje životnim ciklusom spremnika. U nastavku je dana ilustracija strukture.
 {{ :racfor_wiki:kubernetes_structure.png?600 |}}
-Već iz prvih par osnovnih definicija radne strukture Kuberentesa, vidljivo je koliko je ta struktura slojevita i komplicirana, pogotovo u poslovnim okruženjima gdje gdje postoje klasteri s puno čvorova koji nose puno podova. Iz tog razloga potreban je dodatan alat koji će prikupljati metričke i analitičke podatke sa svih objekata strukture u svrhu praćenja performansi, ali i kontrole sigurnosti. Za tu namjenu koristi se vrlo moćan, //open-source// alat koji se lako integrira s Kubernetesom, zvan Prometheus. Prometheus je sustav koji šalje HTTP zahtjeve, takozvano struganje (//scrape//), na temelju konfiguracije definirane u datoteci za postavljanje. Odgovor na ovaj zahtjev za struganjem pohranjuje se i parsira u memoriji zajedno s metričkim podacima za samo struganje. Podaci se pohranjuju u prilagođenu bazu podataka na Prometheus poslužitelju i može obrađivati masovni priljev podataka. Moguće je istovremeno pratiti tisuće strojeva s jednim poslužiteljem. Kubernetes klaster već ima oznake i anotacije te izvrstan mehanizam za praćenje promjena i statusa svojih elemenata. Stoga Prometheus koristi Kubernetes API za otkrivanje ciljeva za struganje.
+Već iz prvih par osnovnih definicija radne strukture Kuberentesa, vidljivo je koliko je ta struktura slojevita i komplicirana, pogotovo u poslovnim okruženjima gdje gdje postoje klasteri s puno čvorova koji nose puno podova. Iz tog razloga potreban je dodatan alat koji će prikupljati metričke i analitičke podatke sa svih objekata strukture u svrhu praćenja performansi, ali i kontrole sigurnosti. Za tu namjenu koristi se vrlo moćan, //open-source// alat koji se lako integrira s Kubernetesom, zvan Prometheus. Prometheus je sustav koji šalje HTTP zahtjeve, takozvano struganje (//scrape//), na temelju konfiguracije definirane u datoteci za postavljanje. Odgovor na ovaj zahtjev za struganjem pohranjuje se i parsira u memoriji zajedno s metričkim podacima za samo struganje. Podaci se pohranjuju u prilagođenu bazu podataka na Prometheus poslužitelju koji može obrađivati masovni priljev podataka. Moguće je istovremeno pratiti tisuće strojeva s jednim poslužiteljem. Kubernetes klaster već ima oznake i anotacije te izvrstan mehanizam za praćenje promjena i statusa svojih elemenata. Stoga Prometheus koristi Kubernetes API za otkrivanje ciljeva za struganje.
 {{ :racfor_wiki:prometheus.png?600 |}}
-Nakon što sustav prikupi podatke, možete mu pristupiti pomoću jezika upita PromQL, izvesti ga na grafička sučelja poput Grafane ili upotrijebiti za slanje upozorenja s Alertmanager-om. Grafana je alat za vizualizaciju podataka prikupljenih Prometheusom. Ona pruža grafičko sučelje sa ugrađenih mnoštvom grafova koji se mogu oblikovati prema želji, pruža konzolu za PromQL upite, i mnoštvo ostalih stvari. Neophodan je alat u analizi i praćenju stanja svih Kubernetes objekata. Primjer sučelja na kojem su prikazani razni grafovi performansi prikupljeni s Prometheus servera je dan na slici u nastavku.
+Nakon što sustav prikupi podatke, moguće im je pristupiti pomoću jezika za upite PromQL, izvesti ih na grafička sučelja poput Grafane ili upotrijebiti za slanje upozorenja s Alertmanager-om. Grafana je alat za vizualizaciju podataka prikupljenih Prometheusom. Ona pruža grafičko sučelje sa ugrađenih mnoštvom grafova koji se mogu oblikovati prema želji, pruža konzolu za PromQL upite, i mnoštvo ostalih stvari. Neophodan je alat u analizi i praćenju stanja svih Kubernetes objekata. Primjer sučelja na kojem su prikazani razni grafovi performansi prikupljeni s Prometheus servera je dan na slici u nastavku [6].
 {{ :racfor_wiki:grafana.png?600 |}}
 ===== Forenzika spremnika =====
-Spremnici čine digitalnu forenziku nevjerojatno složenom jer su raspoređeni i upravljani na različitim domaćinima ovisno o upotrebi i potrebi. Za razliku od okruženja virtualnih strojeva, spremnici koji se izvode na domaćinu dijele osnovnu jezgru operativnog sustava, što znači da nema nikakve hardverske izolacije. Ali postoje neka nova ograničenja, poput izolacije mrežnog pokrivanja, čak i unutar istog domaćina. Dobra vijest je da je IT industrija već ranije vidjela ovakvu vrstu složenosti. Kada su prvi put predstavljeni virtualni strojevi, uobičajena je praksa bila kopirati sadržaj memorije i diska izravno s fizičkog poslužitelja. Višestruki virtualni strojevi možda su premješteni na ili s računala domaćina koji je prvi put napadnut ili se kopija možda izvodi na nekom računalu bez OS-a (//bare metal//). Unatoč činjenici da se virtualni strojevi mogu migrirati između različitih podatkovnih centara, smatraju se dovoljno samostalnima da omoguće evidencijsko očuvanje [7]. Slično prijelazu s fizičkih poslužitelja na virtualne strojeve, postoje različite nijanse složenosti, s pripadajućim prednostima i nedostacima kod spremnika. Trenutno nije dostupna neka opće prihvaćena funkcija snimke spremnika; snimke moraju biti ujedinjene kao skup različitih komponenata.
+Spremnici čine digitalnu forenziku nevjerojatno složenom jer su raspoređeni i upravljani na različitim domaćinima ovisno o potrebi. Za razliku od okruženja virtualnih strojeva, spremnici koji se izvode na domaćinu dijele osnovnu jezgru operacijskog sustava, što znači da nema nikakve hardverske izolacije. Ali postoje neka nova ograničenja, poput izolacije mrežnog pokrivanja, čak i unutar istog domaćina. Dobra vijest je da je IT industrija već ranije vidjela ovakvu vrstu složenosti. Kada su prvi put predstavljeni virtualni strojevi, uobičajena je praksa bila kopirati sadržaj memorije i diska izravno s fizičkog poslužitelja. Višestruki virtualni strojevi možda su premješteni na ili s računala domaćina koji je prvi put napadnut ili se kopija možda izvodi na nekom računalu bez OS-a (//bare metal//). Unatoč činjenici da se virtualni strojevi mogu migrirati između različitih podatkovnih centara, smatraju se dovoljno samostalnima da omoguće evidencijsko očuvanje [7]. Slično prijelazu s fizičkih poslužitelja na virtualne strojeve, postoje različite nijanse složenosti, s pripadajućim prednostima i nedostacima kod spremnika. Trenutno nije dostupna neka opće prihvaćena funkcija snimke spremnika; snimke moraju biti ujedinjene kao skup različitih komponenata.
-Vodeći formati spremnika koriste datotečni sustav oblika //copy-on-write//. To je velika prednost forenzičke nabave. Sve zadane datoteke sustava i aplikacija postoje unutar slike spremnika. Sve promjene od pokretanja spremnika pohranjuju se u zaseban direktorij od izvorne slike. Nadalje, bilježi se i svako brisanje izvornih datoteka sa slike. U primjeru Dockera, razlike između slojeva slike može se vidjeti unutar pokrenutog spremnika na putanji "/var/lib/docker". Trenutni spremnik, bilo da je pokrenut ili isključen, u Dockeru se može pohraniti u novu sliku, ne izmjenjujući spremnik ni u kakvom smislu. Kao i u fizičkim strojevima, pohranjivanje spremnika u novu sliku sprema samo trenutno stanje datotečnog sustava, a ne stanje trenutnih procesa. Ako se spremnik nastavi iz nove slike, on će pokrenuti nove procese i nije zajamčeno da će izvršiti bilo kakvo sumnjivo ponašanje.
+Vodeći formati spremnika koriste datotečni sustav oblika //copy-on-write//. To je velika prednost forenzičke nabave. Sve zadane datoteke sustava i aplikacija postoje unutar slike spremnika. Sve promjene od pokretanja spremnika pohranjuju se u zaseban direktorij od izvorne slike. Nadalje, bilježi se i svako brisanje izvornih datoteka sa slike. U primjeru Dockera, razlike između slojeva slike može se vidjeti unutar pokrenutog spremnika na putanji "/var/lib/docker". Trenutni spremnik, bilo da je pokrenut ili zaustavljen, u Dockeru se može pohraniti u novu sliku, ne izmjenjujući spremnik ni u kakvom smislu. Kao i u fizičkim strojevima, pohranjivanje spremnika u novu sliku sprema samo trenutno stanje datotečnog sustava, a ne stanje trenutnih procesa. Ako se spremnik nastavi iz nove slike, on će pokrenuti nove procese i nije zajamčeno da će izvršiti bilo kakvo sumnjivo ponašanje.
 Za trenutno stanje radne memorije, spremnici također imaju rješenje. Procesi koji se izvode u spremniku upravljaju memorijom jednako kao i bilo koji drugi proces. Prema zadanim postavkama, procesi unutar spremnika ne smiju komunicirati niti ometati memoriju kojom upravlja bilo koji proces izvan spremnika. To znači da ako se za svaki proces u spremniku snimi sva memorija, snimljena je sva dodijeljena memorija za taj spremnik.
-Bitno je napomenuti da spremnici imaju mogućnost mapiranja direktorija s datotečnog sustava domaćina na onaj u spremniku. Tu nastaju potencijalni sigurnosni problemi jer napadač ima ulaz u datotečni sustav domaćina. Takve se opasnosti uklanjaju ograničenjem pristupa tom direktoriju ili kako to zna biti slučaj kod arhitekture mikroservisa, zabrana mapiranja direktorija u potpunosti. Zlonamjeran softver možda nije svjestan kratkog životnog vijeka spremnika i upisuje neke zanimljive podatke na dodijeljeni prostor spremnika na disku. Međutim, najosjetljiviji podaci vjerojatno se pohranjuju putem //volumea//, koji se obično postavlja na trajnu //online// pohranu. Tu je kraj izolacije spremnika. Dodijeljeni //volumei// oslanjaju se na //back-end// za pohranu. Prema zadanim postavkama to je izvorni datotečni sustav domaćina. U arhitekturi mikroservisa uobičajeno se koristi distribuirani sustav ili datotečni sustav u oblaku. Za dohvaćanje i istraživanje ovih datotečnih sustava potrebna je izravna interakcija s datotečnim sustavom.
+Bitno je napomenuti da spremnici imaju mogućnost mapiranja direktorija s datotečnog sustava domaćina na onaj u spremniku. Tu nastaju potencijalni sigurnosni problemi jer napadač ima ulaz u datotečni sustav domaćina. Takve se opasnosti uklanjaju ograničenjem pristupa tom direktoriju ili kako to zna biti slučaj kod arhitekture mikroservisa, zabrana mapiranja direktorija u potpunosti. Zlonamjeran softver možda nije svjestan kratkog životnog vijeka spremnika i upisuje neke zanimljive podatke na dodijeljeni prostor spremnika na disku. Međutim, najosjetljiviji podaci vjerojatno se pohranjuju putem //volume//a, koji služe za pohranu trajnih podataka (//persistent data//). Ti podaci ostaju pohranjeni na disku nakon gašenja spremnika i obično se posebno moraju brisati. Tu prestaje izolacija spremnika. Dodijeljeni //volume//i oslanjaju se na //back-end// za pohranu. Prema zadanim postavkama to je izvorni datotečni sustav domaćina. U arhitekturi mikroservisa uobičajeno se koristi distribuirani sustav ili datotečni sustav u oblaku. Za dohvaćanje i istraživanje ovih datotečnih sustava potrebna je izravna interakcija s datotečnim sustavom.
-Trenutno ne postoji formalni mehanizam za pokretanje snimljenog spremnika. Jednom kada se isključe, čak i ako se izvezu i sadržaj datotečnog sustava i memorije, ne postoji mehanizam za kombiniranje tog dvoje natrag u prethodno pokrenuto stanje. Spremnici su dizajnirani tako da budu kratkotrajni i tako pokreću procese i dodjeljuju novu memoriju nakon inicijalizacije. Iz tog razloga, interakcija sa spremnikom tijekom njegovog rada je obavezna pa je moguće sačuvati spremnik i ukloniti ga iz proizvodnog okruženja. Postoji nekoliko mehanizama koje se mogu upotrijebiti da se održi spremnik koji radi, a da spremnik dalje ne utječe na klaster na značajan način. Prvo, spremnici se mogu pauzirati u bilo kojem trenutku. Izvršenje spremnika u potpunosti je obustavljeno, memorija ostaje dodijeljena, //volumei// ostaju montirani itd. Bilo koji zlonamjerni softver koji se trenutno izvršava je prekinut. Drugo, spremnici se mogu staviti u karantenu uklanjanjem mrežnog pristupa ili privilegija sistemskih poziva. Procesi kontejnera, i moguće zlonamjerni softver, nastavit će se izvršavati, ali neće moći slati, primati, čitati ili pisati bilo kakve podatke, ili čak mapati postojeću memoriju. Međutim, to uzrokuje greške u radu. Ovisno o tome kako procesi obrađuju ove greške, to može isključiti spremnik. Navedene akcije mogu se izvršiti ručno ili automatizirano pomoću nekog od sigurnosnih alata. Jednom kada je spremnik pauziran ili stavljen u karantenu (ako se želi postići čisto radno okruženje), moguće je povećati resurse klastera. Administrator može dodati novi čvor u sustav, isprazniti sve ostale spremnike s ovog čvora i po želji ga ukloniti iz orkestratora (Kubernetesa). U tom trenutku pristup mreži može biti ograničen s čvora, a spremnik se može nastaviti ili prebaciti na drugu mrežu.
+Trenutno ne postoji formalni mehanizam za pokretanje snimljenog spremnika. Jednom kada se isključe, čak i ako se izvezu i sadržaj datotečnog sustava i radne memorije, ne postoji mehanizam za kombiniranje tog dvoje kako bi se u potpunosti rekreiralo prethodno pokrenuto stanje. Spremnici su dizajnirani tako da budu kratkotrajni i tako pokreću procese i dodjeljuju novu memoriju nakon inicijalizacije. Iz tog razloga, interakcija sa spremnikom tijekom njegovog rada je obavezna pa je moguće sačuvati spremnik i ukloniti ga iz proizvodnog okruženja. Postoji nekoliko mehanizama koje se mogu upotrijebiti da se održi spremnik koji radi, a da spremnik dalje ne utječe na klaster na značajan način. Prvo, spremnici se mogu pauzirati u bilo kojem trenutku. Izvršenje spremnika u potpunosti je obustavljeno, memorija ostaje dodijeljena, //volume//i ostaju pohranjeni, itd. Bilo koji zlonamjerni softver koji se trenutno izvršava je prekinut. Drugo, spremnici se mogu staviti u karantenu uklanjanjem mrežnog pristupa ili privilegija sistemskih poziva. Procesi spremnika, i moguće zlonamjerni softver, nastavit će se izvršavati, ali neće moći slati, primati, čitati ili pisati bilo kakve podatke. Međutim, to uzrokuje greške u radu. Ovisno o tome kako procesi obrađuju ove greške, to može isključiti spremnik. Navedene akcije mogu se izvršiti ručno ili automatizirano pomoću nekog od sigurnosnih alata. Jednom kada je spremnik pauziran ili stavljen u karantenu (ako se želi postići čisto radno okruženje), moguće je povećati resurse klastera. Administrator može dodati novi čvor u sustav, isprazniti sve ostale spremnike s ovog čvora i po želji ga ukloniti iz orkestratora (Kubernetesa). U tom trenutku pristup mreži može biti ograničen s čvora, a spremnik se može nastaviti ili prebaciti na drugu mrežu.

racfor_wiki/forenzika_mikroservisa_baziranih_na_spremnicima.1608825768.txt.gz · Zadnja izmjena: 2024/12/05 12:23 (vanjsko uređivanje)