| Starije izmjene na obje strane
Starija izmjena
Novija izmjena
|
Starija izmjena
|
racfor_wiki:forenzika_mikroservisa_baziranih_na_spremnicima [2021/01/13 16:39]
tbaric [Forenzika spremnika] |
racfor_wiki:forenzika_mikroservisa_baziranih_na_spremnicima [2024/12/05 12:24] (trenutno)
|
| {{ :racfor_wiki:scaling-microservices.png?600 |}} | {{ :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 ===== | ===== Sigurnost mikroservisa ===== |
| |
| * **//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. | * **//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. | * **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. | * **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 ===== | ===== Upravljanje i kontrola mikroservisa ===== |
| {{ :racfor_wiki:kubernetes_structure.png?600 |}} | {{ :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 |}} | {{ :racfor_wiki:prometheus.png?600 |}} |
| 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. | 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. |
| |
| |
