Sicurezza end-to-end per i servizi REST, eventuali standard emergenti?

Question

Sicurezza end-to-end per i servizi REST, eventuali standard emergenti?

#1 da (2 voti)
#2 da (0 voti)
#3 da (0 voti)

7

Lavoro con l'integrazione nel settore sanitario, dove la sicurezza end-to-end è importante. Ci integriamo con numerosi servizi SOAP e usiamo le funzionalità di sicurezza WS per crittografare e firmare richieste e risposte.

Le richieste e le risposte passano attraverso diversi livelli intermedi nel nostro scenario di integrazione. È quindi importante che i dati stessi siano crittografati (sicurezza dei messaggi). L'utilizzo di HTTPS (sicurezza del trasporto) protegge il messaggio solo fino alla terminazione SSL.

Ci integriamo anche con i servizi in stile REST. AFAIK, non esiste un approccio standard (come la sicurezza WS) per proteggere i payload REST.

Esistono standard emergenti per la firma e la crittografia dei payload REST?

Modifica

Il servizio Amazon S3 implementa la crittografia . Non sono sicuro che il client di upload S3 utilizzi le chiamate SOAP o REST in stile.
Questa tesi di master riguarda la sicurezza REST.

rest encryption digital-signature web-service

posta codeape 12.10.2015 - 15:14

fonte

3 risposte

Leggi altre domande sui tag rest encryption digital-signature web-service

Che cosa usare come 'stato' nel flusso di lavoro del codice di autorizzazione OAuth2 Grant Come creare esattamente un CVE? [duplicare]

score 2 · Answer 1

Credo che tu stia chiedendo la propagazione dell'identità attraverso uno stack RESTful. In altre parole, si desidera legare la richiesta all'utente originale, in modo che i sistemi a valle possano convalidare l'autorizzazione per utente. Recentemente ho svolto ricerche su questo problema.

Sul cuore, no, non esiste uno standard definito per la propagazione dell'identità per i servizi REST. REST non è uno standard, ma piuttosto un modello architettonico.

Ci sono alcune librerie che forniscono integrazione con standard esistenti come Kerberos (come JAX-RS ) o SAML tramite binding HTTP .

I vari approcci che utilizzano JSON Web Tokens (JWT) stanno diventando popolari, ma questo è più di un approccio "roll-your-own", che offre flessibilità ma al costo dei rischi di implementazione. Questo è un po 'sanguinante. L'RFC per JWT è stato approvato solo ad aprile 2015.

score 0 · Answer 2

Se la sicurezza end-to-end è un fattore critico, l'approccio migliore da adottare non è la fiducia nel mezzo. Diventa quindi irrilevante quali protocolli o API vengono utilizzati nel modo in cui possono o potrebbero non essere sicuri. IMO questo è un presupposto equo: in ogni sistema ragionevolmente complesso con più livelli intermedi, non è garantito che i canali di comunicazione siano adeguatamente protetti. Oppure non archiviano inavvertitamente i dati più a lungo del necessario e, di conseguenza, aprono una finestra in cui possono essere divulgati dati riservati.

Suggerimento:

Il server di destinazione genera una coppia di chiavi (chiavi pubbliche + private). Per esempio. RSA con 4096 bit.
Distribuisci la chiave pubblica al client. Per esempio. i client mobili potrebbero avere la chiave pubblica già presente nell'app.
Il client crittografa i dati riservati con la chiave pubblica e invia il testo cifrato. Solo il server di destinazione può decodificare il testo cifrato.

score 0 · Answer 3

JWT è principalmente per l'autenticazione, sebbene sia possibile personalizzare il token per includere ruoli e utilizzarlo per l'autorizzazione.

Per firmare e crittografare i messaggi http, è possibile dare un'occhiata a JSON Web Signature (JWS) e JSON Web Encryption (JWE). Sono entrambi RFC che fanno parte del framework JSON Object Signing and Encryption (JOSE).