Na dnešnom trhu, kde odvetvia používajú rôzne softvérové architektúry a aplikácie, je takmer nemožné cítiť, že vaše dáta sú úplne zabezpečené. Pri vytváraní aplikácií pomocou , bezpečnostné problémy sa stávajú čoraz významnejšími, pretože jednotlivé služby komunikujú medzi sebou a klientom. Takže v tomto článku o zabezpečení mikroslužieb budem v nasledujúcom poradí diskutovať o rôznych spôsoboch, ktoré môžete implementovať na zabezpečenie svojich mikroslužieb.
- Čo sú mikroslužby?
- Problémy, ktorým čelia mikroslužby
- Najlepšie postupy na zabezpečenie mikroslužieb
Čo sú mikroslužby?
Mikroslužby, aka mikroslužobná architektúra , je architektonický štýl, ktorý štruktúruje aplikáciu ako súbor malých autonómnych služieb, modelovaných okolo a obchodná doména. Mikroslužby teda môžete chápať ako malé individuálne služby, ktoré navzájom komunikujú okolo jedinej obchodnej logiky. Ak sa chcete dozvedieť viac podrobne o mikroslužbách, môžete
Teraz, keď spoločnosti často prechádzajú z monolitickej architektúry na mikroslužby, vidia veľa výhod, ako je škálovateľnosť, flexibilita a krátke vývojové cykly. Táto architektúra však zároveň prináša aj niekoľko zložitých problémov.
Ďalej v tomto článku o zabezpečení mikroslužieb teda poďme pochopiť problémy, ktorým čelí architektúra mikroslužieb.
Problémy, ktorým čelia mikroslužby
Problémy, ktorým čelia mikroslužby, sú nasledujúce:
Problém 1:
Zvážte scenár, keď sa používateľ musí prihlásiť, aby získal prístup k prostriedku. Teraz v architektúre mikroslužieb musia byť prihlasovacie údaje používateľa uložené takým spôsobom, že od používateľa nebude vyžadované overenie vždy, keď sa pokúsi získať prístup k prostriedku. Teraz to vytvára problém, pretože údaje o používateľovi nemusia byť zabezpečené a môže k nim získať prístup 3rdvečierok.
Problém 2:
Keď klient pošle žiadosť, potom je potrebné overiť podrobnosti o klientovi a skontrolovať tiež jeho oprávnenie. Takže keď používate mikroslužby, môže sa stať, že pre každú službu musíte klienta autentifikovať a autorizovať. Teraz môžu vývojári použiť rovnaký kód pre každú službu. Nemyslíte si však, že spoliehanie sa na konkrétny kód znižuje flexibilitu mikroslužieb? No to určite áno. Toto je teda jeden z hlavných problémov, ktorým táto architektúra často čelí.
Problém 3:
Ďalším veľmi výrazným problémom je bezpečnosť každej jednotlivej mikroslužby. V tejto architektúre spolu okrem 3 komunikujú všetky mikroslužby navzájomrdpárty aplikácie. Takže keď sa klient prihlási z 3rdvečierková aplikácia, musíte sa ubezpečiť, že klient nezíska prístup k údajom mikroslužieb spôsobom, ktorý by ich mohol zneužiť.
počkajte a upozornite v Jave
Dobre, vyššie uvedené problémy nie sú jedinými problémami nachádzajúcimi sa v architektúre mikroslužieb. Povedal by som, že by ste mohli čeliť mnohým ďalším problémom súvisiacim s bezpečnosťou založenou na aplikácii a architektúre, ktorú máte. K tejto poznámke sa posuňme vpred v tomto článku o zabezpečení mikroslužieb a poznajme najlepší spôsob, ako znížiť výzvy.
Najlepšie postupy pre zabezpečenie mikroslužieb
Najlepšie postupy na zlepšenie zabezpečenia v mikroslužbách sú:
Mechanizmus ochrany v hĺbke
Pretože je známe, že mikroslužby prijímajú akýkoľvek mechanizmus na granulárnej úrovni, môžete použiť mechanizmus obrany v hĺbke a zvýšiť tak úroveň služieb. Laicky povedané, mechanizmus obrany v hĺbke je v podstate technika, prostredníctvom ktorej môžete na ochranu citlivých služieb aplikovať vrstvy bezpečnostných protiopatrení. Ako vývojár teda musíte identifikovať služby s najcitlivejšími informáciami a na ich ochranu potom použiť niekoľko bezpečnostných vrstiev. Týmto spôsobom sa môžete ubezpečiť, že akýkoľvek potenciálny útočník nedokáže prelomiť zabezpečenie naraz, a musí ísť dopredu a pokúsiť sa prelomiť obranný mechanizmus všetkých vrstiev.
čo sú kuchár a bábka
Pretože v architektúre mikroslužieb môžete implementovať rôzne vrstvy zabezpečenia na rôznych službách, útočník, ktorý úspešne využíva konkrétnu službu, nemusí byť schopný prelomiť obranný mechanizmus ostatných služieb.
Tokeny a brána API
Keď otvoríte aplikáciu, často sa zobrazí dialógové okno s textom „Prijmite licenčnú zmluvu a povolenie pre súbory cookie“. Čo znamená táto správa? Akonáhle to prijmete, vaše prihlasovacie údaje sa uložia a vytvorí sa relácia. Teraz, keď nabudúce prejdete na tú istú stránku, stránka sa načíta z pamäte cache a nie zo samotných serverov. Predtým, ako sa tento koncept dostal do obrazu, sa relácie ukladali centrálne na strane servera. To však bola jedna z najväčších prekážok v horizontálnom škálovaní, aplikácia.
Žetóny
Riešením tohto problému je teda použitie tokenov na zaznamenanie prihlasovacích údajov používateľa. Tieto tokeny sa používajú na ľahkú identifikáciu používateľa a sú uložené vo forme súborov cookie. Teraz, kedykoľvek klient požaduje webovú stránku, je požiadavka preposlaná na server a potom server určí, či má používateľ prístup k požadovanému prostriedku alebo nie.
Teraz sú hlavným problémom tokeny, kde sú uložené informácie o používateľovi. Dáta tokenov teda musia byť šifrované, aby sa zabránilo zneužitiu od 3rdstranícke zdroje. Jason Web Format alebo najbežnejšie známy ako JWT je otvorený štandard, ktorý definuje formát tokenu, poskytuje knižnice pre rôzne jazyky a tiež tieto tokeny šifruje.
Brány API
Brány API sa pridávajú ako ďalší prvok k zabezpečeným službám prostredníctvom autentifikácie pomocou tokenov. The Gateway slúži ako vstupný bod pre všetky požiadavky klienta a efektívne pred klientom skrýva mikroslužby. Klient teda nemá priamy prístup k mikroslužbám, a teda nemôže žiadnym spôsobom využívať žiadnu zo služieb.
Distribuované sledovanie a správa relácií
Distribuované sledovanie
Pri používaní mikroslužieb musíte všetky tieto služby nepretržite monitorovať. Ak však musíte súčasne monitorovať obrovské množstvo služieb, stane sa z toho problém. Ak sa chcete vyhnúť takýmto výzvam, môžete použiť metódu známu ako Distribuované sledovanie. Distribuované sledovanie je metóda na presné určenie zlyhaní a identifikáciu príčin. Nielen to, ale môžete tiež určiť miesto, kde sa zlyhanie deje. Je teda veľmi ľahké vypátrať, ktorá mikroslužba čelí bezpečnostnému problému.
Riadenie relácie
Správa relácií je dôležitý parameter, ktorý musíte brať do úvahy pri zabezpečovaní mikroslužieb. Teraz sa relácia vytvorí vždy, keď používateľ príde k aplikácii. Údaje o relácii teda môžete spracovať nasledujúcimi spôsobmi:
- Údaje o relácii jedného používateľa môžete uložiť na konkrétny server. Tento typ systému však úplne závisí od vyváženia záťaže medzi službami a spĺňa iba horizontálne mierky.
- Kompletné údaje relácie je možné uložiť v jednej inštancii. Potom je možné dáta synchronizovať cez sieť. Jediným problémom je, že pri tejto metóde sa sieťové zdroje vyčerpajú.
- Môžete sa ubezpečiť, že údaje používateľa je možné získať zo zdieľaného úložiska relácií, aby sa zaistilo, že všetky služby budú môcť načítať rovnaké údaje relácie. Pretože sa však údaje získavajú zo zdieľaného úložiska, musíte sa ubezpečiť, že máte nejaký bezpečnostný mechanizmus, aby ste k údajom mohli pristupovať bezpečným spôsobom.
Prvá relácia a vzájomné SSL
Myšlienka prvého zasadnutia je veľmi jednoduchá. Používatelia sa musia do aplikácie prihlásiť raz a potom majú prístup ku všetkým službám v aplikácii. Každý používateľ však musí na začiatku komunikovať s autentifikačnou službou. To určite môže mať za následok veľkú premávku medzi všetkými službami a pre vývojárov by mohlo byť nepríjemné zisťovať zlyhania v takomto scenári.
Pokiaľ ide o vzájomné SSL, aplikácie často čelia prenosu od používateľov, 3rdstrany a tiež mikroslužby navzájom komunikujúce. Ale keďže k týmto službám má prístup 3rdstrán, vždy existuje riziko útokov. Teraz je riešením takýchto scenárov vzájomné SSL alebo vzájomné overovanie medzi mikroslužbami. Vďaka tomu budú dáta prenášané medzi službami šifrované. Jediným problémom tejto metódy je, že keď sa zvýši počet mikroslužieb, potom pretože každá služba bude mať svoj vlastný certifikát TLS, bude pre vývojárov veľmi ťažké aktualizovať certifikáty.
3rdstranícky prístup k aplikácii
Každý z nás má prístup k aplikáciám, ktoré sú 3rdpárty aplikácie. 3rdpárty aplikácie používajú na prístup k požadovaným prostriedkom token API vygenerovaný používateľom v aplikácii. Aplikácie tretích strán majú teda prístup k údajom konkrétnych používateľov, a nie k prihlasovacím údajom iných používateľov. Týkalo sa to jedného používateľa. Čo však v prípade, keď aplikácie potrebujú prístup k údajom od viacerých používateľov? Ako si myslíte, že je vyhovené takejto žiadosti?
Používanie protokolu OAuth
Riešením je použitie OAuth. Keď používate OAuth, aplikácia vyzve používateľa na autorizáciu 3rdstranícke aplikácie, aby použili požadované informácie a vygenerovali pre ne token. Spravidla sa autorizačný kód používa na vyžiadanie tokenu, aby sa zabezpečilo, že adresa URL spätného volania používateľa nebude ukradnutá.
reťazec k dátumu previesť v
Takže keď klient zmieni prístupový token, komunikuje s autorizačným serverom a tento server autorizuje klienta, aby zabránil iným vo falšovaní identity klienta. Takže keď používate Microservices s OAuth, služby fungujú ako klient v architektúre OAuth, aby sa zjednodušili problémy so zabezpečením.
Nuž, priatelia, nepovedal by som, že toto sú jediné spôsoby, ako môžete zabezpečiť svoje služby. Mikroslužby môžete zabezpečiť mnohými spôsobmi na základe architektúry aplikácie. Takže ak ste niekto, kto sa usiluje vybudovať aplikáciu založenú na mikroslužbách, nezabudnite, že bezpečnosť služieb je jedným z dôležitých faktorov, pri ktorých musíte byť opatrní. V tejto súvislosti sa dostávame k ukončeniu tohto článku o zabezpečení mikroslužieb. Dúfam, že ste tento článok našli informačný.
Ak sa chcete naučiť mikroslužby a budovať svoje vlastné aplikácie, pozrite si naše ktorá prináša živé školenie vedené inštruktorom a skúsenosti s projektmi v reálnom živote. Toto školenie vám pomôže pochopiť Microservices do hĺbky a pomôže vám dosiahnuť osvojenie si predmetu.
Máte na nás otázku? Uveďte to v sekcii komentárov stránky ” Zabezpečenie mikroslužieb “A ozvem sa ti.