Al mercat actual, on les indústries utilitzen diverses arquitectures i aplicacions de programari, és gairebé impossible sentir que les vostres dades són completament segures. Per tant, mentre es construeixen aplicacions mitjançant el fitxer , els problemes de seguretat esdevenen més importants, ja que els serveis individuals es comuniquen entre ells i amb el client. Per tant, en aquest article sobre la seguretat dels microserveis, parlaré de les diverses maneres que podeu implementar per protegir els microserveis en la següent seqüència.
- Què són els microserveis?
- Problemes als microserveis
- Pràctiques recomanades per protegir els microserveis
Què són els microserveis?
Microserveis, també conegut com arquitectura de microserveis , és un estil arquitectònic que estructura una aplicació com una col·lecció de petits serveis autònoms, modelats al voltant d'un domini empresarial. Per tant, podeu entendre els microserveis com petits serveis individuals que es comuniquen entre ells al voltant de la lògica empresarial única. Si voleu obtenir més informació sobre els microserveis en profunditat, podeu fer-ho
diferència entre titella i xef
Ara, sovint quan les empreses passen d’una arquitectura monolítica als microserveis, veuen molts avantatges com l’escalabilitat, la flexibilitat i els cicles de desenvolupament curts. Però, al mateix temps, aquesta arquitectura també introdueix alguns problemes complexos.
Per tant, a continuació, en aquest article sobre la seguretat dels microserveis, entenem els problemes que s’enfronten en una arquitectura de microserveis.
Problemes als microserveis
Els problemes als microserveis són els següents:
Problema 1:
Penseu en un escenari en què un usuari hagi d’iniciar sessió per accedir a un recurs. Ara, a l'arquitectura de microserveis, les dades d'inici de sessió de l'usuari s'han de desar de manera que no es demani a l'usuari la verificació cada vegada que intenta accedir a un recurs. Ara, això crea un problema, ja que és possible que les dades de l’usuari no siguin segures i que també puguin accedir a la 3rdfesta.
Problema 2:
Quan un client envia una sol·licitud, cal verificar-ne les dades i comprovar els permisos que se li donen. Per tant, quan utilitzeu microserveis, pot passar que per a tots i cadascun dels serveis hagueu d’autenticar i autoritzar el client. Ara, per fer-ho, els desenvolupadors poden utilitzar el mateix codi per a cada servei. Però, no creieu que confiar en un codi específic redueix la flexibilitat dels microserveis? Bé, definitivament ho fa. Per tant, aquest és un dels problemes principals que s’enfronten sovint en aquesta arquitectura.
Problema 3:
El següent problema, que és molt important, és la seguretat de cada microservei individual. En aquesta arquitectura, tots els microserveis es comuniquen entre si simultàniament a més dels 3rdaplicacions de festa. Per tant, quan un client inicia la sessió des d’un 3rdaplicació del partit, heu d'assegurar-vos que el client no tingui accés a les dades dels microserveis, de manera que pugui explotar-los.
Molt bé, els problemes esmentats no són els únics que es troben en una arquitectura de microserveis. Diria que podríeu afrontar molts altres problemes relacionats amb la seguretat basats en l'aplicació i l'arquitectura que teniu. En aquest sentit, avancem amb aquest article sobre la seguretat dels microserveis i coneixem la millor manera de reduir els reptes.
Pràctiques recomanades per a la seguretat dels microserveis
Les millors pràctiques per millorar la seguretat dels microserveis són les següents:
Defensa en el mecanisme de profunditat
Com que se sap que els microserveis adopten qualsevol mecanisme a nivell granular, podeu aplicar el mecanisme Defensa en profunditat per fer els serveis més segurs. En termes no normals, el mecanisme Defensa a la profunditat és bàsicament una tècnica mitjançant la qual podeu aplicar capes de contramesures de seguretat per protegir els serveis sensibles. Per tant, com a desenvolupador, només haureu d’identificar els serveis amb la informació més sensible i aplicar diverses capes de seguretat per protegir-los. D'aquesta manera, podeu assegurar-vos que qualsevol atacant potencial no pugui trencar la seguretat d'un sol cop i que hagi de seguir endavant i intentar trencar el mecanisme de defensa de totes les capes.
A més, atès que en una arquitectura de microserveis, podeu implementar diferents capes de seguretat en diferents serveis, és possible que un atacant que pugui explotar un servei concret no pugui trencar el mecanisme de defensa dels altres serveis.
Tokens i API Gateway
Sovint, quan obriu una aplicació, apareix un quadre de diàleg que diu: 'Accepteu l'acord de llicència i el permís de les galetes'. Què significa aquest missatge? Bé, un cop l’accepteu, s’emmagatzemaran les vostres credencials d’usuari i es crearà una sessió. Ara, la propera vegada que aneu a la mateixa pàgina, la pàgina es carregarà des de la memòria cau en lloc dels servidors. Abans que aparegués aquest concepte, les sessions s’emmagatzemaven al costat del servidor de forma centralitzada. Però, aquesta era una de les barreres més grans en l’escala horitzontal, l’aplicació.
Fitxes
Per tant, la solució a aquest problema és utilitzar fitxes, per registrar les credencials d’usuari. Aquestes fitxes s’utilitzen per identificar fàcilment l’usuari i s’emmagatzemen en forma de cookies. Ara, cada vegada que un client sol·licita una pàgina web, la sol·licitud es reenvia al servidor i, a continuació, el servidor determina si l'usuari té accés al recurs sol·licitat o no.
Ara, el principal problema són les fitxes on s’emmagatzema la informació de l’usuari. Per tant, cal xifrar les dades de les fitxes per evitar qualsevol explotació a partir de 3rdrecursos per a festes. El format web Jason o més conegut com a JWT és un estàndard obert que defineix el format de testimoni, proporciona biblioteques per a diversos idiomes i també xifra aquestes fitxes.
API Gateways
Les passarel·les API s’afegeixen com a element addicional per protegir els serveis mitjançant l’autenticació de token. El Gateway actua com a punt d'entrada a totes les sol·licituds del client i amaga els microserveis de manera eficient al client. Per tant, el client no té accés directe als microserveis i, per tant, d’aquesta manera, cap client no pot explotar cap dels serveis.
Gestió distribuïda de seguiment i sessió
Seguiment distribuït
Mentre utilitzeu microserveis, heu de supervisar tots aquests serveis contínuament. Però quan s’ha de controlar simultàniament una gran quantitat de serveis, això es converteix en un problema. Per evitar aquests reptes, podeu utilitzar un mètode conegut com a seguiment distribuït. El seguiment distribuït és un mètode per identificar els errors i identificar el motiu que hi ha darrere. No només això, sinó que també podeu identificar el lloc on es produeix un fracàs. Per tant, és molt fàcil localitzar quins microserveis s’enfronten a un problema de seguretat.
transformació connectada i no connectada en informàtica
Gestió de sessions
La gestió de sessions és un paràmetre important que heu de tenir en compte per assegurar els microserveis. Ara, es crea una sessió cada vegada que un usuari accedeix a una aplicació. Per tant, podeu gestionar les dades de la sessió de les maneres següents:
- Podeu emmagatzemar les dades de sessió d’un sol usuari en un servidor específic. Però aquest tipus de sistema depèn completament de l’equilibri de càrrega entre els serveis i només compleix l’escala horitzontal.
- Les dades completes de la sessió es poden emmagatzemar en una única instància. A continuació, les dades es poden sincronitzar a través de la xarxa. L'únic problema és que, en aquest mètode, els recursos de la xarxa s'esgoten.
- Podeu assegurar-vos que les dades de l'usuari es poden obtenir des de l'emmagatzematge de sessió compartit, de manera que es garanteixi que tots els serveis puguin llegir les mateixes dades de sessió. Però, atès que les dades es recuperen de l’emmagatzematge compartit, heu d’assegurar-vos que teniu algun mecanisme de seguretat per accedir a les dades d’una manera segura.
Primera sessió i SSL mutu
La idea de la primera sessió és molt senzilla. Els usuaris han d’iniciar sessió a l’aplicació una vegada i després poden accedir a tots els serveis de l’aplicació. Però, cada usuari s’ha de comunicar inicialment amb un servei d’autenticació. Bé, definitivament això pot resultar en molt trànsit entre tots els serveis i pot ser molest per als desenvolupadors esbrinar falles en aquest escenari.
En arribar a SSL mutu, les aplicacions solen afrontar el trànsit dels usuaris, 3rdfestes i també microserveis que es comuniquen entre ells. Però, atès que a aquests serveis els accedeix el 3rdparts, sempre hi ha risc d’atacs. Ara, la solució a aquests escenaris és SSL mutu o autenticació mútua entre microserveis. Amb això, les dades transferides entre els serveis es xifraran. L'únic problema amb aquest mètode és que, quan augmenta el nombre de microserveis, donat que tots els serveis tindran el seu propi certificat TLS, serà molt difícil per als desenvolupadors actualitzar els certificats.
3rdaccés a l'aplicació del partit
Tots accedim a aplicacions que són 3rdaplicacions de festa. El 3rdles aplicacions de grups utilitzen un testimoni API generat per l'usuari a l'aplicació per accedir als recursos necessaris. Per tant, les aplicacions de tercers poden accedir a les dades d’aquests usuaris en concret i no a les credencials d’altres usuaris. Bé, això corresponia a un sol usuari. Però, què passa si les aplicacions necessiten accedir a dades de diversos usuaris? Com creieu que s’accepta aquesta sol·licitud?
Ús d'OAuth
La solució és utilitzar OAuth. Quan utilitzeu OAuth, l'aplicació demana a l'usuari que autoritzi el 3rdaplicacions de partits, per utilitzar la informació necessària i generar-ne un testimoni. En general, s’utilitza un codi d’autorització per sol·licitar el testimoni per assegurar-se que no es roben l’URL de devolució de trucada de l’usuari.
Per tant, mentre esmenta el testimoni d’accés, el client es comunica amb el servidor d’autorització i aquest autoritza el client a evitar que altres falsifiquin la identitat del client. Per tant, quan utilitzeu microserveis amb OAuth, els serveis actuen com a client a l’arquitectura OAuth per simplificar els problemes de seguretat.
Bé, gent, no diria que aquestes siguin les úniques maneres de protegir els vostres serveis. Podeu protegir els microserveis de moltes maneres en funció de l'arquitectura de l'aplicació. Per tant, si sou algú que aspira a crear una aplicació basada en microserveis, recordeu que la seguretat dels serveis és un factor important que heu de tenir precaució. En aquest sentit, arribem al final d’aquest article sobre la seguretat dels microserveis. Espero que aquest article us sigui d’informació.
Si voleu aprendre microserveis i crear les vostres pròpies aplicacions, consulteu el nostre que inclou formació en viu dirigida per un instructor i experiència en projectes reals. Aquesta formació us ajudarà a comprendre en profunditat els microserveis i us ajudarà a dominar el tema.
Tens alguna pregunta? Esmenteu-lo a la secció de comentaris de ' Seguretat de microserveis ”I em posaré en contacte amb vosaltres.
per a què s’utilitza mongodb