Securitate la microservicii Cum să vă securizați infrastructura de microservicii?



Acest articol despre securitatea Microservices va discuta unele dintre cele mai bune practici pentru securizarea microservicii într-un mod detaliat.

Pe piața actuală, unde industriile folosesc diverse arhitecturi și aplicații software, este aproape imposibil să simțiți că datele dvs. sunt complet sigure. Deci, în timp ce construiți aplicații folosind , problemele de securitate devin mai semnificative, deoarece serviciile individuale comunică între ele și cu clientul. Deci, în acest articol despre securitatea microserviciilor, voi discuta diferitele moduri în care puteți implementa pentru a vă securiza microserviciile în următoarea secvență.

Ce sunt microserviciile?

Microservicii, alias arhitectura microservice , este un stil arhitectural care structurează o aplicație ca o colecție de mici servicii autonome, modelate în jurul a domeniul afacerii. Deci, puteți înțelege microserviciile ca mici servicii individuale care comunică între ele în jurul unei singure logici de afaceri. Dacă doriți să aflați mai multe despre microservicii în profunzime, atunci puteți



Ce sunt Microserviciile - Securitatea Microserviciilor - Edureka

găsiți cel mai mare element în matricea java

Acum, adesea, atunci când companiile trec de la o arhitectură monolitică la microservicii, văd multe beneficii precum scalabilitatea, flexibilitatea și ciclurile scurte de dezvoltare. Dar, în același timp, această arhitectură introduce și câteva probleme complexe.



Deci, în acest articol despre securitatea microserviciilor, să înțelegem problemele cu care se confruntă o arhitectură de microservicii.

Probleme cu care se confruntă microserviciile

Problemele cu care se confruntă microserviciile sunt următoarele:

Problema 1:

Luați în considerare un scenariu în care un utilizator trebuie să se conecteze pentru a accesa o resursă. Acum, în arhitectura microserviciilor, detaliile de conectare ale utilizatorului trebuie să fie salvate în așa fel încât, utilizatorului să nu i se solicite verificarea de fiecare dată când încearcă să acceseze o resursă. Acum, acest lucru creează o problemă, deoarece detaliile utilizatorului ar putea să nu fie sigure și, de asemenea, ar putea fi accesate de către 3rdparte.



Problema 2:

Când un client trimite o cerere, atunci trebuie verificate detaliile clientului și trebuie verificate și permisiunile date clientului. Deci, atunci când utilizați microservicii, se poate întâmpla ca, pentru fiecare serviciu, să fiți autentificat și autorizat clientul. Acum, pentru a face acest lucru, dezvoltatorii ar putea folosi același cod pentru fiecare serviciu. Dar, nu credeți că a vă baza pe un cod specific reduce flexibilitatea microserviciilor? Ei bine, cu siguranță. Deci, aceasta este una dintre problemele majore cu care se confruntă adesea în această arhitectură.

Problema 3:

Următoarea problemă foarte importantă este securitatea fiecărui microserviciu individual. În această arhitectură, toate microserviciile comunică între ele simultan în plus față de cele 3rdaplicații de petrecere. Deci, atunci când un client se conectează dintr-un 3rdcerere de petrecere, trebuie să vă asigurați că clientul nu obține acces la datele microserviciilor, într-un mod în care ar putea să le exploateze.

Bine, problemele menționate mai sus nu sunt singurele probleme găsite într-o arhitectură de microservice. Aș spune că ai putea să te confrunți cu multe alte probleme legate de securitate pe baza aplicației și a arhitecturii pe care o ai. În această notă, să mergem mai departe cu acest articol despre securitatea microserviciilor și să cunoaștem cea mai bună modalitate de a reduce provocările.

Cele mai bune practici pentru securitatea microserviciilor

Cele mai bune practici pentru îmbunătățirea securității în microservicii sunt următoarele:

Apărarea în mecanismul de adâncime

Deoarece se știe că microserviciile adoptă orice mecanism la nivel granular, puteți aplica mecanismul Apărare în adâncime pentru a face serviciile mai sigure. În termeni laici, mecanismul Apărare în adâncime este practic o tehnică prin care puteți aplica straturi de contramăsuri de securitate pentru a proteja serviciile sensibile. Deci, ca dezvoltator, trebuie doar să identificați serviciile cu cele mai sensibile informații și apoi să aplicați o serie de straturi de securitate pentru a le proteja. În acest fel, vă puteți asigura că orice potențial atacator nu poate sparge securitatea dintr-o singură mișcare și trebuie să meargă înainte și să încerce să spargă mecanismul de apărare al tuturor straturilor.

De asemenea, întrucât într-o arhitectură de microservicii, puteți implementa diferite straturi de securitate pe diferite servicii, un atacator, care are succes în exploatarea unui anumit serviciu, ar putea să nu poată sparge mecanismul de apărare al celorlalte servicii.

Jetoane și API Gateway

Adesea, când deschideți o aplicație, apare o casetă de dialog care spune „Acceptați acordul de licență și permisiunea pentru cookie-uri”. Ce înseamnă acest mesaj? Ei bine, odată ce îl acceptați, acreditările dvs. de utilizator vor fi stocate și va fi creată o sesiune. Acum, data viitoare când accesați aceeași pagină, pagina va fi încărcată din memoria cache, mai degrabă decât din serverele în sine. Înainte ca acest concept să intre în imagine, sesiunile erau stocate central pe partea serverului. Dar aceasta a fost una dintre cele mai mari bariere în scalarea orizontală, aplicația.

Jetoane

Deci, soluția la această problemă este utilizarea jetoanelor, pentru a înregistra acreditările utilizatorului. Aceste jetoane sunt utilizate pentru a identifica cu ușurință utilizatorul și sunt stocate sub formă de cookie-uri. Acum, de fiecare dată când un client solicită o pagină web, cererea este redirecționată către server și apoi, serverul determină dacă utilizatorul are sau nu acces la resursa solicitată.

Acum, principala problemă sunt jetoanele în care sunt stocate informațiile utilizatorului. Deci, datele jetoanelor trebuie criptate pentru a evita orice exploatare de la 3rdresurse de partid. Jason Web Format sau cel mai frecvent cunoscut sub numele de JWT este un standard deschis care definește formatul de jetoane, oferă biblioteci pentru diferite limbi și criptează acele jetoane.

Gateway-uri API

Gateway-urile API se adaugă ca element suplimentar pentru securizarea serviciilor prin autentificare prin token. Gateway acționează un punct de intrare pentru toate cererile clientului și ascunde eficient microserviciile de la client. Deci, clientul nu are acces direct la microservicii și, astfel, niciun client nu poate exploata niciunul dintre servicii.

Gestionarea distribuită a urmăririi și sesiunii

Urmărire distribuită

În timp ce utilizați microservicii, trebuie să monitorizați continuu toate aceste servicii. Dar, atunci când trebuie să monitorizați simultan o cantitate enormă de servicii, atunci aceasta devine o problemă. Pentru a evita astfel de provocări, puteți utiliza o metodă cunoscută sub numele de urmărire distribuită. Urmărirea distribuită este o metodă de identificare a eșecurilor și identificarea motivului din spatele acesteia. Nu numai acest lucru, dar puteți identifica și locul în care se întâmplă eșecul. Deci, este foarte ușor de depistat, care microserviciu se confruntă cu o problemă de securitate.

aruncă o dublă la un int

Managementul sesiunii

Gestionarea sesiunii este un parametru important pe care trebuie să îl luați în considerare în timp ce asigurați microserviciile. Acum, se creează o sesiune de fiecare dată când un utilizator accesează o aplicație. Deci, puteți gestiona datele sesiunii în următoarele moduri:

  1. Puteți stoca datele de sesiune ale unui singur utilizator pe un anumit server. Dar acest tip de sistem depinde complet de echilibrarea sarcinii între servicii și îndeplinește doar scalarea orizontală.
  2. Datele complete ale sesiunii pot fi stocate într-o singură instanță. Apoi, datele pot fi sincronizate prin rețea. Singura problemă este că, în această metodă, resursele de rețea se epuizează.
  3. Vă puteți asigura că datele utilizatorului pot fi obținute din stocarea de sesiune partajată, pentru a vă asigura că toate serviciile pot citi aceleași date de sesiune. Dar, deoarece datele sunt preluate din stocarea partajată, trebuie să vă asigurați că aveți un mecanism de securitate, pentru a accesa datele într-un mod sigur.

Prima sesiune și SSL reciproc

Ideea primei sesiuni este foarte simplă. Utilizatorii trebuie să se conecteze la aplicație o singură dată, iar apoi pot accesa toate serviciile din aplicație. Dar, fiecare utilizator trebuie să comunice inițial cu un serviciu de autentificare. Ei bine, acest lucru poate duce cu siguranță la mult trafic între toate serviciile și ar putea fi dificil pentru dezvoltatori să descopere eșecurile într-un astfel de scenariu.

Venind la SSL reciproc, aplicațiile se confruntă adesea cu traficul utilizatorilor, 3rdpetreceri și, de asemenea, microservicii care comunică între ele. Dar, deoarece aceste servicii sunt accesate de către 3rdpărți, există întotdeauna riscul atacurilor. Acum, soluția la astfel de scenarii este SSL reciprocă sau autentificarea reciprocă între microservicii. Cu aceasta, datele transferate între servicii vor fi criptate. Singura problemă cu această metodă este că, atunci când numărul de microservicii crește, atunci deoarece fiecare serviciu va avea propriul certificat TLS, va fi foarte greu pentru dezvoltatori să actualizeze certificatele.

3rdacces la aplicația de petrecere

Toți accesăm aplicații care sunt 3rdaplicații de petrecere. Cele 3rdaplicațiile de partid utilizează un simbol API generat de utilizator în aplicație pentru a accesa resursele necesare. Deci, aplicațiile terță parte pot accesa datele anumitor utilizatori și nu acreditările altor utilizatori. Ei bine, acest lucru se referea la un singur utilizator. Dar dacă aplicațiile trebuie să acceseze date de la mai mulți utilizatori? Cum credeți că este acceptată o astfel de cerere?

Utilizarea OAuth

Soluția este să utilizați OAuth. Când utilizați OAuth, aplicația îi solicită utilizatorului să autorizeze cele 3rdaplicații de petrecere, pentru a utiliza informațiile solicitate și pentru a genera un simbol pentru aceasta. În general, un cod de autorizare este utilizat pentru a solicita jetonul pentru a vă asigura că adresa URL a apelului de apel al utilizatorului nu este furată.

Deci, în timp ce menționează jetonul de acces, clientul comunică cu serverul de autorizare, iar acest server îl autorizează pe client să împiedice alții să falsifice identitatea clientului. Deci, atunci când utilizați Microservices cu OAuth, serviciile acționează ca un client în arhitectura OAuth, pentru a simplifica problemele de securitate.

Ei bine, oameni buni, nu aș spune că acestea sunt singurele modalități prin care vă puteți asigura serviciile. Puteți securiza microserviciile în mai multe moduri, pe baza arhitecturii aplicației. Deci, dacă sunteți cineva care aspiră să construiască o aplicație bazată pe microservicii, nu uitați că securitatea serviciilor este un factor important la care trebuie să fiți precaut. În această notă, ajungem la sfârșitul acestui articol despre securitatea microserviciilor. Sper că ați găsit acest articol informativ.

Dacă doriți să învățați Microservicii și să vă creați propriile aplicații, consultați care vine cu instruire live condusă de instructor și experiență în viața reală a proiectului. Această instruire vă va ajuta să înțelegeți în profunzime Microserviciile și să vă ajute să obțineți stăpânirea asupra subiectului.

Ai o întrebare pentru noi? Vă rugăm să o menționați în secțiunea de comentarii din ” Securitate Microservice ”Și mă voi întoarce la tine.

mutabil și imuabil în java