Indurisce contro l'escalation dei privilegi in Microservices

Question

Indurisce contro l'escalation dei privilegi in Microservices

#1 da (0 voti)

0

Considerare il seguente scenario.

Il sistema ha un insieme di titolari di aziende (ovvero utenti del sistema)
Ogni proprietario di attività commerciale è associato a un gruppo di clienti
Gli imprenditori accedono al sistema per gestire i propri clienti.

I proprietari delle attività selezioneranno prima un singolo cliente e da lì in avanti la sua sessione sarà associata a quel cliente selezionato .

Ho un set di microservizi, ognuno richiede un Customer-ID per l'elaborazione. cioè.

Microservizio A espone GET /resource-a/{customer-id}
Microservice B espone POST /resource-b/{customer-id}
ecc.

Il Customer-Id è considerato un'informazione sensibile, quindi è in forma crittografata.

Tuttavia è ancora vulnerabile a escalation di privilegi . Ad esempio, un imprenditore può condividere per errore l'ID cliente crittografato tramite segnalibri, ecc. in modo che il proprietario di un'attività commerciale possa accedere ai dettagli dei clienti che non sono associati a lui. (non esattamente privilege-escalation?)

Voglio evitare l'autorizzazione lato server dell'ID cliente rispetto al titolare dell'attività perché è noto che è un'operazione lenta e il 90% delle API dovrà ripetere questa procedura di autorizzazione
Tutti i microservizi sono privi di stato, quindi non è possibile crittografare Customer-Id con l'ID di sessione come chiave (poiché nessun microservizio / sessione di stato)
Inoltre, non penso che sia una buona idea fare questa autorizzazione al gateway poiché non è destinato a svolgere tale logica di business.

Come posso evitare l'escalation dei privilegi in questa situazione?

encryption session-management privilege-escalation

posta Fahim Farook 21.10.2018 - 10:50

fonte

1 risposta

Leggi altre domande sui tag encryption session-management privilege-escalation

Come funziona l'autenticazione con chiave pubblica ssh? Qual è la differenza tra casi di abuso e abuso in sicurezza?

score 0 · Answer 1

Considerando che non vuoi farlo sul lato server, vedo solo altre due possibilità:

Vai con security through obscurity , e non esporre mai Customer-Id sul fronte utente (qualsiasi azione che lo faccia apparire nella barra degli indirizzi, nell'interfaccia utente, nella cronologia del browser, ecc.). Questo non correggerà il tuo problema e non ti proteggerà da un attaccante dedicato. Anche se potrebbe funzionare in un certo grado.
Utilizza token autonomi stateless (ad esempio JWT) per generare la sessione utente. E salva tutti i customer-id's associati a quell'utente sul token stesso. Quindi, quando si verifica il token di sessione lato server, si otterrà anche l'autorizzazione allo stesso tempo. Questo non costerebbe affatto delle prestazioni. Tuttavia, potrebbe funzionare come soluzione solo se non si ha molto a customer-ids legato a un utente (ovviamente non si desidera l'intero DB nel token).

Sono consapevole che questa potrebbe non essere la risposta completa, e piuttosto aggiungerei questo come commento ma non ero in grado di farlo a causa della mia reputazione. Pertanto, vorrei chiedere di astenermi dal dare punti negativi.