Tänapäeva turul, kus tööstused kasutavad erinevaid tarkvaraarhitektuure ja -rakendusi, on peaaegu võimatu seda tunda, teie andmed on täiesti turvalised. Nii et samal ajal rakendusi ehitades , muutuvad turvaküsimused olulisemaks, kuna üksikud teenused suhtlevad omavahel ja kliendiga. Niisiis, selles mikroteenuste turvalisust käsitlevas artiklis käsitlen erinevaid võimalusi, mida saate oma mikroteenuste turvamiseks järgmises järjestuses rakendada.
Mis on mikroteenused?
Mikroteenused ehk aka mikroteenuse arhitektuur on arhitektuuristiil, mis struktureerib rakenduse väikeste autonoomsete teenuste kogumina, mis on kujundatud a ümber ettevõtte domeen. Nii saate mõista mikroteenuseid kui väikseid üksikteenuseid, mis suhtlevad omavahel ühe äriloogika alusel. Kui soovite mikroteenuste kohta põhjalikumalt teada saada, saate seda teha
Nüüd, kui ettevõtted lähevad monoliitselt arhitektuurilt üle mikroteenustele, näevad nad palju eeliseid, nagu mastaapsus, paindlikkus ja lühikesed arendustsüklid. Samal ajal toob see arhitektuur sisse ka mõned keerukad probleemid.
Niisiis, järgmisena selles mikroteenuste turvalisust käsitlevas artiklis, andke meile mõista probleemid, millega mikroteenuste arhitektuuris kokku puututakse.
Mikroteenuste probleemid
Mikroteenuste probleemid on järgmised:
mis on selle märksõna 6 viisi?
1. probleem:
Mõelge stsenaariumile, kus kasutaja peab ressursile juurdepääsemiseks sisse logima. Nüüd tuleb mikroteenuste arhitektuuris kasutaja sisselogimisandmed salvestada nii, et kasutajal ei palutaks kontrollimist iga kord, kui ta ressursile juurde proovib. Nüüd tekitab see probleemi, kuna kasutaja andmed ei pruugi olla turvalised ja neile pääseb juurde ka kolmrdpidu.
2. probleem:
Kui klient saadab päringu, tuleb kontrollida kliendi üksikasju ja kontrollida ka kliendile antud õigusi. Mikroteenuste kasutamisel võib juhtuda, et iga teenuse puhul peate kliendi autentima ja volitama. Nüüd võivad arendajad selleks kasutada iga teenuse jaoks sama koodi. Kuid kas te ei arva, et kindlale koodile toetumine vähendab mikroteenuste paindlikkust? Noh, kindlasti teeb. Nii et see on üks peamisi probleeme, millega selles arhitektuuris sageli kokku puututakse.
3. ülesanne:
Järgmine probleem, mis on väga silmatorkav, on iga üksiku mikroteenuse turvalisus. Selles arhitektuuris suhtlevad kõik mikroteenused üksteisega lisaks kolmele samaaegseltrdpartei rakendused. Niisiis, kui klient logib sisse 3-strdosapoole rakendus, peate veenduma, et klient ei pääse juurde mikroteenuste andmetele viisil, et ta võiks neid ära kasutada.
Hästi, ülalnimetatud probleemid pole ainsad probleemid, mida leidub mikroteenuse arhitektuuris. Ma ütleksin, et võite rakenduse ja olemasoleva arhitektuuri põhjal silmitsi seista paljude muude turvalisusega seotud probleemidega. Siinkohal jätkame selle mikroteenuste turvalisust käsitleva artikliga edasi liikumist ja teame parimat viisi probleemide vähendamiseks.
Parimad tavad mikroteenuste turvalisuse tagamiseks
Parimad tavad mikroteenuste turvalisuse parandamiseks on järgmised:
Kaitse sügavusmehhanismis
Kuna teadaolevalt kasutavad mikroteenused mis tahes mehhanismi granulaarsel tasemel, saate teenuste turvalisuse suurendamiseks rakendada kaitsesügavuse mehhanismi. Võlakokkuvõttes on kaitse sügavuses mehhanism põhimõtteliselt tehnika, mille kaudu saate tundlike teenuste kaitsmiseks rakendada turvalisuse vastumeetmeid. Seega peate arendajana lihtsalt tuvastama kõige tundlikuma teabega teenused ja seejärel nende kaitsmiseks rakendama mitmeid turvakihte. Nii saate veenduda, et ükski potentsiaalne ründaja ei saa turvalisust ühe korraga murda, vaid peab edasi minema ja proovima kõigi kihtide kaitsemehhanismi murda.
Kuna mikroteenuste arhitektuuris saate rakendada erinevatele teenustele erinevaid turvakihte, ei pruugi ründaja, kes on konkreetse teenuse ekspluateerimisel edukas, teiste teenuste kaitsemehhanismi murda.
Märgid ja API-lüüs
Sageli näete rakendust avades dialoogiboksi, mis ütleb: 'Nõustuge litsentsilepingu ja küpsiste lubamisega'. Mida see sõnum tähistab? Noh, kui olete selle aktsepteerinud, salvestatakse teie kasutaja mandaadid ja luuakse seanss. Nüüd, kui järgmine kord samale lehele liigute, laaditakse leht pigem vahemälust, mitte serveritest endist. Enne selle kontseptsiooni ilmumist salvestati seansid serveripoolselt keskselt. Kuid see oli üks horisontaalse mõõtkava suuremaid takistusi, rakendus.
Märgid
Niisiis, selle probleemi lahenduseks on märkide kasutamine, kasutajaandmete salvestamine. Neid märke kasutatakse kasutaja hõlpsaks tuvastamiseks ja need salvestatakse küpsiste kujul. Nüüd, iga kord, kui klient taotleb veebilehte, edastatakse päring serverile ja seejärel määrab server kindlaks, kas kasutajal on juurdepääs taotletud ressursile või mitte.
võite kasutada kirjutusmasina klassi, et avada fail kirjutamiseks ja sinna andmete kirjutamiseks.
Nüüd on põhiprobleemiks märgid, kuhu kasutaja teave on salvestatud. Niisiis tuleb märkide andmed krüptida, et vältida alates 3-st kasutamistrdpartei ressursid. Jasoni veebivorming või kõige sagedamini tuntud kui JWT on avatud standard, mis määratleb märgivormingu, pakub teeke erinevatele keeltele ja krüpteerib ka need märgid.
API lüüsid
API-lüüsid lisatakse täiendava elemendina teenuste turvaliseks märkide autentimise kaudu. The Gateway toimib kõigi kliendipäringute sisestuspunktina ja peidab tõhusalt kliendi eest mikroteenuseid. Seega pole kliendil otsest juurdepääsu mikroteenustele ja seega ei saa ükski klient ühtegi teenust kasutada.
Hajutatud jälgimine ja seansside haldamine
Hajutatud jälgimine
Mikroteenuste kasutamise ajal peate kõiki neid teenuseid pidevalt jälgima. Kuid kui peate samaaegselt jälgima hulgaliselt teenuseid, muutub see probleemiks. Selliste väljakutsete vältimiseks võite kasutada meetodit, mida nimetatakse hajutatud jälgimiseks. Hajutatud jälgimine on meetod rikete tuvastamiseks ja selle põhjuste väljaselgitamiseks. Mitte ainult seda, vaid saate ka tuvastada koha, kus ebaõnnestumine toimub. Niisiis on väga lihtne jälile saada, millise mikroteenuse turvalisuse probleem seisab silmitsi.
Seansside haldamine
Sessiooni haldamine on oluline parameeter, mida peate mikroteenuste turvamisel arvestama. Nüüd luuakse seanss alati, kui kasutaja rakenduse avab. Nii saate seansi andmeid käsitleda järgmistel viisidel:
- Ühe kasutaja seansiandmeid saate salvestada konkreetsesse serverisse. Kuid selline süsteem sõltub täielikult teenuste vahelise koormuse tasakaalustamisest ja vastab ainult horisontaalsele skaleerimisele.
- Seansi täielikke andmeid saab salvestada ühes eksemplaris. Seejärel saab andmeid võrgu kaudu sünkroonida. Ainus probleem on see, et selle meetodi korral saavad võrguressursid ammenduda.
- Võite veenduda, et kasutajaandmeid saab jagatud seansimälust, et kõik teenused saaksid lugeda samu seansiandmeid. Kuid kuna andmed saadakse ühismälust, peate andmetele turvalisel viisil juurdepääsemiseks veenduma, et teil on mõni turvamehhanism.
Esimene seanss ja vastastikune SSL
Esimese seansi idee on väga lihtne. Kasutajad peavad rakendusse sisse logima üks kord ja seejärel saavad nad juurdepääsu kõigile rakenduse teenustele. Kuid iga kasutaja peab algselt suhtlema autentimisteenusega. Noh, see võib kindlasti põhjustada palju liiklust kõigi teenuste vahel ja võib arendajatele olla keeruline sellise stsenaariumi korral rikete väljaselgitamiseks.
Tulles vastastikuse SSL-i juurde, näevad rakendused sageli kasutajate liiklust, 3rdpeod ja ka omavahel suhtlevad mikroteenused. Kuid kuna nendele teenustele pääseb juurde 3rdalati rünnakute oht. Nüüd on selliste stsenaariumide lahenduseks vastastikune SSL või mikroteenuste omavaheline autentimine. Sellega krüpteeritakse teenuste vahel edastatud andmed. Selle meetodi ainus probleem on see, et kui mikroteenuste arv suureneb, siis kuna igal teenusel on oma TLS-sertifikaat, on arendajatel sertifikaatide värskendamine väga keeruline.
3rdpartei rakenduste juurdepääs
Kõik meist pääsevad juurde rakendustele, mis on 3rdpartei rakendused. 3rdosapoolte rakendused kasutavad nõutavatele ressurssidele juurdepääsemiseks rakenduses kasutaja loodud API-luba. Nii saavad kolmanda osapoole rakendused juurde pääseda selle konkreetse kasutaja andmetele, mitte teiste kasutajate mandaatidele. Noh, see oli seotud ühe kasutajaga. Aga mis siis, kui rakendused peavad pääsema juurde mitme kasutaja andmetele? Mis te arvate, kuidas selline taotlus rahuldatakse?
funktsioone, mis erinevad ainult tagasituleku tüübi poolest, ei saa üle koormata
OAuthi kasutamine
Lahendus on kasutada OAuthi. OAuthi kasutamisel palub rakendus kasutajal 3 volitadardosapoolte rakendusi, et kasutada vajalikku teavet ja luua selle jaoks luba. Üldiselt kasutatakse volituse taotlemiseks autoriseerimiskoodi, et veenduda, et kasutaja tagasihelistamise URL-i ei varastata.
Nii et kui juurdepääsuluba mainitakse, suhtleb klient autoriseerimisserveriga ja see server volitab klienti takistama teisi kliendi identiteeti võltsimast. Niisiis, kui kasutate Microsofti teenuseid koos OAuthiga, toimivad teenused turbeprobleemide lihtsustamiseks kliendina OAuthi arhitektuuris.
Noh, inimesed, ma ei ütleks, et need on ainsad viisid, kuidas saate oma teenuseid turvata. Mikroteenuseid saate rakenduse arhitektuurist lähtudes mitmel viisil turvata. Seega, kui olete keegi, kes soovib luua mikroteenustele tuginevat rakendust, pidage meeles, et teenuste turvalisus on üks oluline tegur, mille suhtes peate olema ettevaatlik. Selle märkuse põhjal oleme jõudnud mikroteenuste turvalisust käsitleva artikli lõpuni. Loodan, et leidsite selle artikli informatiivseks.
Kui soovite õppida mikroteenuseid ja luua oma rakendusi, vaadake meie mis on varustatud juhendajate juhitud elava koolituse ja reaalse elu projektikogemusega. See koolitus aitab teil Microsofti teenuseid põhjalikumalt mõista ja aitab teil selle teema üle meisterlikkust saavutada.
Kas teil on meile küsimus? Palun mainige seda kommentaaride jaotises ” Mikroteenuste turvalisus ”Ja pöördun teie poole tagasi.