Comunicazione tra microservizi - distinguendo le chiamate interne in modo sicuro

Naviga le tue risposte
5

Sto rearchitecturing e riscrivo la mia soluzione monolitica di BaaS in microservizi riguardanti la scalabilità e le regole di singola responsabilità. A causa delle dipendenze interne, i servizi vengono posizionati su diversi livelli logici. Vedi la figura sotto;

Invece di accedere direttamente al database o all'archiviazione di valori-chiave, ogni servizio in Tier 2 deve utilizzare Tier 1 Data Storage Service . L'obiettivo delle chiamate di servizio interne si trova tramite il servizio di configurazione ospitato indipendentemente dal gateway API. Il gateway API è distribuito e configurato per prodotto. Il prodotto ha un apikey e apisecret.

Scenario 1:

  • Gli utenti finali possono accedere al prodotto ospitato. (Http *: // host / autenticazione / login)

Scenario 2:

  • Business Service serve una logica personalizzata: MyClass.MyOperation () (http *: // host / business / myclass / myoperation)
  • Gli utenti finali di Business Service devono essere autenticati tramite Authentication Service per utilizzare la business logic (autenticazione basata su token)

Sull'architettura monolitica, sono stato in grado di intercettare le chiamate commerciali estese tramite intercettori configurati all'interno del task http in esecuzione corrente. Pertanto, sono stato in grado di ricevere AuthenticationToken dalla richiesta del servizio aziendale e decidere se l'utente finale è stato autenticato tramite il servizio di autenticazione interrogando direttamente l'archivio valore-chiave.

Seguendo l'architettura micoservice, prima di eseguire la logica di business Business Service dovrebbe effettuare una richiesta con il trasferimento di tutte le intestazioni di richiesta originali a Authentication Service , attende la sua risposta, quindi analizza il risultato dell'autenticazione ed esegue la logica di business desiderata compito di risposta. Responsabilità unica, abbastanza equa.

Domanda:

  • Considerando che ogni Tier 2 di servizi può essere distribuito ovunque all'interno della rete, quali sono le opzioni disponibili per distinguere in modo sicuro le richieste interne ed esterne tra gateway e microservizi?
  • Questo approccio potrebbe essere utilizzato per prevenire il ciclo di servizio interno?
posta denolk 30.03.2016 - 09:10
fonte

2 risposte

3

La cosa migliore da fare è assicurarsi che tutte le richieste tutte provengano da una fonte autenticata. Questo potrebbe significare una richiesta dell'utente, ma anche un utente "di servizio" che corrisponde a ciascun microservizio. Se un hacker ottiene l'accesso al tier2 e disponi di un'API non autenticata, possono causare il caos.

Ogni microservizio deve avere un proprio utente distinto da utilizzare per le richieste non richieste, ma generalmente ogni chiamata API deve passare lungo il token utente ricevuto dalla richiesta originale.

    
risposta data 30.03.2016 - 10:21
fonte
2

Assicurati di avere una sorta di contesto (per mancanza di una parola migliore) su tutte le chiamate interne. Questo dovrebbe contenere un token di autenticazione dal mittente di ogni richiesta e può essere semplicemente passato su ogni volta che si fanno richieste interne.

È quindi necessario eseguire l'autorizzazione, in base al token di autenticazione (idealmente verificando il token OGNI volta), come appropriato all'interno di ciascun micro-servizio.

Per le chiamate che non sono dovute a un utente esterno, assicurati che ciascuno dei tuoi servizi acquisisca un token di autenticazione appropriato, identificandolo come originatore della richiesta.

A seconda di come appare l'architettura interna, potrebbe essere appropriato per un micro-servizio ricevere una richiesta che si identifica come autore di un errore.

    
risposta data 30.03.2016 - 11:32
fonte

Leggi altre domande sui tag

Refactoring: funzione di auto-invocazione invece del metodo Extract? Come progettare una classe con più moduli