Na današnjem trgu, kjer industrije uporabljajo različne programske arhitekture in aplikacije, je skoraj nemogoče čutiti, da so vaši podatki popolnoma varni. Torej, med gradnjo aplikacij z uporabo , varnostna vprašanja postajajo pomembnejša, saj posamezne službe komunicirajo med seboj in stranko. V tem članku o varnosti mikro storitev bom v naslednjem zaporedju razpravljal o različnih načinih, s katerimi lahko zaščitite svoje mikro storitve.
Kaj so mikro storitve?
Microservices, aka arhitektura mikro storitve , je arhitekturni slog, ki aplikacijo strukturira kot zbirko majhnih avtonomnih storitev po vzoru a poslovna domena. Torej lahko mikro storitve razumete kot majhne posamezne storitve, ki medsebojno komunicirajo po enotni poslovni logiki. Če želite poglobljeno vedeti več o mikro storitvah, potem lahko
Zdaj, ko podjetja preidejo z monolitne arhitekture na mikro storitve, vidijo številne prednosti, kot so razširljivost, prilagodljivost in kratki razvojni cikli. Toda hkrati ta arhitektura predstavlja tudi nekaj zapletenih problemov.
V naslednjem članku o varnosti mikro storitev bomo torej razumeli težave arhitekture mikro storitev.
Težave z mikro storitvami
Težave, s katerimi se srečujejo mikro storitve, so naslednje:
razlika med preglasitvijo in preobremenitvijo
Problem 1:
Razmislite o scenariju, v katerem se mora uporabnik prijaviti za dostop do vira. Zdaj je treba v arhitekturi mikro storitev shraniti podatke za prijavo uporabnika tako, da uporabnik ni pozvan k preverjanju vsakič, ko poskuša dostopati do vira. Zdaj to povzroča težavo, saj uporabniški podatki morda niso varni in bi lahko do njih dostopali tudi s 3rdzabava.
Problem 2:
Ko stranka pošlje zahtevo, je treba preveriti podatke o njej in preveriti tudi dovoljenja, ki jih ima stranka. Ko uporabljate mikro storitve, se lahko zgodi, da morate za vsako storitev preveriti pristnost in pooblastiti odjemalca. Zdaj lahko za to razvijalci uporabljajo isto kodo za vsako storitev. Toda, ali se vam ne zdi, da zanašanje na določeno kodo zmanjša prožnost mikro storitev? No, vsekakor je. To je torej ena največjih težav, s katero se ta arhitektura pogosto srečuje.
Problem 3:
Naslednji izstopajoči problem je varnost vsake posamezne mikro storitve. V tej arhitekturi poleg mikrofona 3 med seboj sočasno komunicirajo tudi drugerdstranke. Torej, ko se stranka prijavi iz 3rdstranke, se prepričajte, da odjemalec ne dobi dostopa do podatkov mikrostoritev, tako da jih lahko izkoristi.
V redu, zgoraj omenjene težave niso edine težave, ki jih najdemo v arhitekturi mikro storitev. Rekel bi, da bi se lahko soočili s številnimi drugimi težavami, povezanimi z varnostjo, ki temeljijo na aplikaciji in arhitekturi, ki jo imate. Ob tej opombi gremo naprej s tem člankom o varnosti mikro storitev in vemo, kako najbolje rešiti izzive.
Najboljše prakse za varnost mikro storitev
Najboljše prakse za izboljšanje varnosti mikro storitev so naslednje:
Obramba v mehanizmu globine
Ker je znano, da mikroservice sprejemajo kateri koli mehanizem na zrnati ravni, lahko mehanizem Defense in Depth uporabite, da storitve naredite bolj varne. Laično gledano je mehanizem Obramba v globini v bistvu tehnika, s pomočjo katere lahko uporabite plasti varnostnih protiukrepov za zaščito občutljivih storitev. Torej morate kot razvijalec prepoznati storitve z najbolj občutljivimi informacijami in nato uporabiti številne varnostne plasti, da jih zaščitite. Na ta način se lahko prepričate, da noben potencialni napadalec ne more zlomiti zaščite naenkrat, temveč mora iti naprej in poskusiti razbiti obrambni mehanizem vseh slojev.
Ker lahko tudi v arhitekturi mikrostoritev na različnih storitvah izvajate različne ravni varnosti, napadalec, ki je uspešen pri izkoriščanju določene storitve, morda ne bo mogel razbiti obrambnega mehanizma drugih storitev.
Žetoni in prehod API
Ko odprete aplikacijo, se pogosto prikaže pogovorno okno z besedilom »Sprejmite licenčno pogodbo in dovoljenje za piškotke«. Kaj pomeni to sporočilo? No, ko jo sprejmete, bodo vaše uporabniške poverilnice shranjene in ustvarjena bo seja. Zdaj, ko boste naslednjič obiskali isto stran, se bo stran naložila iz začasnega pomnilnika in ne iz samih strežnikov. Preden se je ta koncept pojavil v sliki, so bile seje centralno shranjene na strežniški strani. Toda to je bila ena največjih ovir pri horizontalnem spreminjanju, aplikacija.
Žetoni
Rešitev te težave je torej uporaba žetonov za snemanje uporabniških poverilnic. Ti žetoni se uporabljajo za enostavno prepoznavanje uporabnika in so shranjeni v obliki piškotkov. Zdaj, ko odjemalec zahteva spletno stran, se zahteva posreduje strežniku, nato pa strežnik določi, ali ima uporabnik dostop do zahtevanega vira ali ne.
načrt spremljanja in nadzora projekta
Zdaj so glavna težava žetoni, kjer so shranjeni podatki o uporabniku. Podatke o žetonih je torej treba šifrirati, da ne pride do kakršnega koli izkoriščanja s strani 3rdviri strank. Jason Web Format ali najbolj znan kot JWT je odprt standard, ki opredeljuje format žetona, ponuja knjižnice za različne jezike in tudi šifrira te žetone.
API prehodi
API prehodi dodani kot dodaten element za zaščito storitev s preverjanjem pristnosti žetonov. The Gateway deluje kot vstopna točka za vse zahteve odjemalca in učinkovito skriva mikro storitve pred odjemalcem. Torej, stranka nima neposrednega dostopa do mikrostoritev in tako nobena stranka ne more izkoristiti nobene storitve.
Porazdeljeno sledenje in upravljanje sej
Porazdeljeno sledenje
Med uporabo mikro storitev morate vse te storitve neprekinjeno spremljati. Ko pa morate hkrati spremljati ogromno količino storitev, to postane problem. Da bi se izognili takšnim izzivom, lahko uporabite metodo, imenovano Distributed Tracing. Porazdeljeno sledenje je metoda za natančno določitev napak in prepoznavanje vzroka za to. Ne samo to, lahko tudi določite kraj, kjer se dogaja okvara. Torej je zelo enostavno izslediti, katera mikro storitev se sooča z varnostno težavo.
Upravljanje sej
Upravljanje sej je pomemben parameter, ki ga morate upoštevati pri varovanju mikro storitev. Zdaj se seja ustvari vsakič, ko uporabnik odpre aplikacijo. S podatki seje lahko torej ravnate na naslednje načine:
- Podatke seje enega uporabnika lahko shranite v določen strežnik. Toda takšen sistem je popolnoma odvisen od izravnave obremenitve med storitvami in izpolnjuje le vodoravno skaliranje.
- Popolne podatke o seji lahko shranite v enem primeru. Potem se lahko podatki sinhronizirajo po omrežju. Edina težava je v tem, da se pri tej metodi omrežni viri izčrpajo.
- Prepričate se lahko, da je mogoče uporabniške podatke pridobiti iz pomnilnika sej v skupni rabi, tako da lahko vse storitve berejo iste podatke seje. Ker pa so podatki pridobljeni iz skupne shrambe, se morate prepričati, da imate zaščitni mehanizem za varen dostop do podatkov.
Prva seja in vzajemni SSL
Ideja prve seje je zelo preprosta. Uporabniki se morajo v aplikacijo prijaviti enkrat, nato pa lahko dostopajo do vseh storitev v aplikaciji. Vendar mora vsak uporabnik najprej komunicirati s storitvijo za preverjanje pristnosti. No, to lahko zagotovo povzroči veliko prometa med vsemi storitvami in razvijalci bi lahko bili okorni, da bi ugotovili napake v takem scenariju.
Če pridejo do vzajemnega SSL, se aplikacije pogosto srečujejo s prometom uporabnikov, 3rdstranke in tudi mikrostoritve, ki komunicirajo med seboj. Ker pa do teh storitev dostopa 3rdvedno obstaja nevarnost napadov. Zdaj je rešitev za takšne scenarije vzajemna SSL ali vzajemna overitev med mikro storitvami. S tem bodo podatki, ki se prenašajo med storitvami, šifrirani. Edina težava te metode je, da bo, ko se bo število mikro storitev povečalo, in ker bo vsaka storitev imela svoj certifikat TLS, razvijalcem zelo težko posodobiti potrdila.
3.rddostop do aplikacij stranke
Vsi dostopamo do aplikacij, ki so 3rdstranke. 3rdaplikacije stranke uporabljajo žeton API, ki ga v aplikaciji ustvari uporabnik, za dostop do zahtevanih virov. Torej lahko aplikacije tretjih oseb dostopajo do podatkov določenih uporabnikov in ne do poverilnic drugih uporabnikov. No, to je veljalo za enega uporabnika. Kaj pa, če morajo aplikacije dostopati do podatkov več uporabnikov? Kako mislite, da je takšna prošnja sprejeta?
Uporaba OAuth
Rešitev je uporaba OAuth. Ko uporabljate OAuth, aplikacija od uporabnika zahteva, da dovoli 3rdstrank, da uporabi zahtevane podatke in zanje ustvari žeton. Na splošno se za odobritev žetona zahteva avtorizacijska koda, s katero se zagotovi, da uporabnikov URL za povratni klic ni ukraden.
Torej, medtem ko omenja žeton za dostop, odjemalec komunicira s strežnikom za pooblastitev, ta pa pooblasti odjemalca, da drugim prepreči ponarejanje identitete stranke. Ko torej uporabljate Microservices z OAuth, storitve delujejo kot odjemalec v arhitekturi OAuth, da poenostavijo varnostna vprašanja.
No, ljudje, ne bi rekel, da so to edini načini, s katerimi si lahko zagotovite svoje storitve. Mikro storitve lahko zaščitite na več načinov glede na arhitekturo aplikacije. Torej, če ste nekdo, ki si želi zgraditi aplikacijo, ki temelji na mikro storitvah, ne pozabite, da je varnost storitev pomemben dejavnik, pri katerem morate biti previdni. V tem zapisu smo zaključili ta članek o varnosti mikro storitev. Upam, da se vam je ta članek zdel informativen.
kako napisati tostring metodo
Če se želite naučiti mikro storitev in zgraditi lastne aplikacije, si oglejte našo ki prihaja z usposabljanjem pod vodstvom inštruktorjev v živo in izkušnjami iz resničnih projektov. Ta trening vam bo pomagal poglobljeno razumeti mikro storitve in vam pomagal doseči obvladovanje zadeve.
Imate vprašanje za nas? Prosimo, navedite to v oddelku za komentarje v Varnost mikro storitve ”In se vam oglasim.