Microservizi e sicurezza -Parte 1

L’architettura dei microservizi è ovunque, anche in tutto il mondo. Con la crescente richiesta di implementare nuove funzionalità, i microservizi sono emersi come un modo fattibile per strutturare grandi applicazioni. Ci sono già molti contenuti disponibili sui microservizi. Se hai ancora difficoltà a comprendere i vantaggi dei microservizi, proviamo a capirlo attraverso l’esempio seguente:

Immagina di avere il compito di costruire una città. Questa è la tua applicazione principale. Per rendere la tua città un luogo ideale in cui vivere, ti consigliamo di includere le seguenti strutture (i diversi servizi per la tua applicazione principale):

  • Includi case ben costruite con connessioni idriche ed elettriche affidabili (forse anche Wi-Fi, chissà)
  • Costruire infrastrutture per rendere i pendolari e il trasporto facili e accessibili.
  • Costruire sistemi sanitari ed educativi

Sembra una città fantastica, vero? Ora, immagina di voler aggiungere un’altra scuola o ricostruire parte di una strada. Questo non significa che dovresti abbattere l’intera città, cambiare la strada e quindi riaccendere le luci. Devi creare un sistema disaccoppiato , in modo da poter modificare esattamente dove vuoi senza influire sull’intera città. È possibile creare dipartimenti per singoli servizi e loro possono occuparsene. Questo è il tipo di flessibilità che si trova nel software se lo sviluppo segue un’architettura di microservizi.

Come abbiamo visto nell’esempio sopra, l’esecuzione e la manutenzione di più servizi è fondamentale per la missione più ampia: un’applicazione di alta qualità.

Ma – non abbiamo finito con l’esempio della città.

Non possiamo dimenticare la sicurezza.

Le persone dovrebbero sentirsi al sicuro nella loro città e dovrebbe esserci un accordo adeguato per gestire qualsiasi tipo di attacco alla città. Questo post riguarda l’implementazione della sicurezza nell’intera architettura dei microservizi.

Prima di immergermi nei microservizi, dovrei notare che Martin Fowler fa un ottimo lavoro nel discutere i dettagli tecnici di questa architettura sul suo sito (verificalo sicuramente).

Sicurezza

Come tutti sappiamo, la sicurezza è molto importante ovunque. Potresti essere ben consapevole della perdita di dati di Facebook, in cui i dati personali degli utenti sono stati compromessi. Negli ultimi anni ci sono state molte altre violazioni di dati critici e hack. Prendendo molto sul serio queste problematiche, l’Unione Europea (UE) ha introdotto il Regolamento generale sulla protezione dei dati (GDPR), che è entrato in vigore il 25 maggio 2018.

Al fine di garantire la sicurezza nella tua applicazione, devi sapere chi è un utente e cosa è autorizzato a fare. I sistemi di gestione delle identità (IMS) sono lì per verificare e autorizzare chiunque sui tuoi server, dispositivi e nella tua API. L’identità è sempre al centro della sicurezza delle API, della sicurezza aziendale e della sicurezza mobile. Questo è uno dei tanti indicatori che spingono pensatori come David Birch a sostenere che “l’identità è il nuovo denaro”.

Perché la sicurezza è più importante nei microservizi?

In un’architettura di microservizi, stai sfruttando molto di più le funzionalità del tuo sistema direttamente esposte alla rete. Ciò lo rende più vicino ai potenziali aggressori, o “aumenta la superficie di attacco”, come direbbe un professionista della sicurezza, quindi la sicurezza diventa molto importante.

Regola della CIA sulla sicurezza del software:

Riservatezza: nessuno può accedere a ciò che ti appartiene.

Integrità: nessuno può modificare alcuna informazione senza il tuo consenso.

Disponibilità: puoi accedere ai dati quando ne hai bisogno.

I dettagli sono disponibili qui .

OAuth 2.0:

OAuth 2.0 è uno standard aperto per la delega di accesso.

Viene comunemente utilizzato quando gli utenti di Internet concedono a siti Web o applicazioni l’accesso alle proprie informazioni su altri siti Web o applicazioni, senza fornire la propria password a tale sito Web o applicazione.

Cosa significa delegazione di accesso?

L’accesso delegato richiede sostanzialmente a un’entità di eseguire alcuni lavori o attività per tuo conto. Potresti aver sperimentato personalmente l’accesso delegato nel mondo digitale di oggi, dove potresti aver concesso l’accesso ai tuoi account Gmail, Facebook o Twitter a un’altra applicazione.

I tipi di concessione OAuth 2.0 più comuni sono elencati di seguito :

  • codice di autorizzazione
  • Implicito
  • Parola d’ordine
  • Credenziali del cliente
  • Codice dispositivo
  • Aggiorna token

OpenID:

Secondo il sito Web ufficiale di OpenID, OpenID è ” un modo semplice e gratuito per utilizzare un’unica identità digitale su Internet”.

Concettualmente, un OpenID è un protocollo di autenticazione decentralizzato che può essere utilizzato per verificare la tua identità sul Web. È possibile fornire un URL personalizzato come OpenID, registrato con un fornitore di servizi OpenID come credenziale valida per l’autenticazione (ad esempio al login).

OpenID Connect, una specifica standard di OpenID Foundation, è simile a OAuth; fornisce un token aggiuntivo che fornisce informazioni sull’utente. Il token può essere utilizzato all’interno di un JWT (ovvero JSON Web Token) ottenendo la firma dal server di autorizzazione per stabilire una connessione sicura tra il server e il client.

Un token Web JSON (JWT) è un oggetto JSON utilizzato come modalità di scambio di informazioni tra due entità (parti), che è sicuro e ha un formato fisso definito in RFC 7519 .

Il formato per JWT è header.payload.signature

Intestazione

L’intestazione normalmente ha due parti: il tipo di token e l’algoritmo di hashing

Per esempio:

  { 
“Alg”: “SHA256”,
“Typ”: “JWT”
}

Qui,

Il tasto “typ” indica che l’oggetto è di tipo JWT,

Il tasto “alg” rappresenta quale algoritmo di hashing viene utilizzato, come HMAC SHA256 o RSA, per creare il componente della firma JWT.

Quindi, questo JSON costituisce la prima parte del JWT codificando in Base64Url.

Carico utile

Il payload è la seconda parte del token, che contiene tutti i possibili reclami.

I reclami sono dichiarazioni su un’entità (in genere, l’utente) e metadati aggiuntivi.

Puoi controllare di più sui reclami qui.

Un esempio di formato di payload:

  { 
“Sub”: “1234321789”,
“Nome”: “ Salvatore Incandela ”,
"Admin": falso
}

Il payload è quindi codificato Base64Url per formare la seconda parte del token Web JSON.

Firma

Per generare la firma in JWT, dobbiamo prendere la combinazione codificata di intestazione e payload più un segreto, l’algoritmo specificato nell’intestazione e firmarlo.

Ad esempio, la firma sarà simile a questa se si desidera utilizzare l’algoritmo HMAC SHA256:

  HMACSHA256 ( 
base64UrlEncode (header) + “.” +
base64UrlEncode (payload), segreto)

La firma assicura che il messaggio non sia stato modificato lungo il percorso e, nel caso in cui i token fossero firmati con una chiave privata, può anche verificare l’identità del mittente del JWT.

Lo scopo reale dell’utilizzo di JWT è dimostrare che i dati inviati sono stati creati da una fonte autentica. Il suo scopo non è quello di nascondere o oscurare i dati. I dati all’interno di un JWT sono codificati e firmati, non crittografati.

La propagazione dell’identità è una delle maggiori sfide in un’architettura a microservizi. Dopo l’autenticazione, l’identità verificata dell’utente deve passare al successivo microservizio a valle in modo affidabile, in modo che la sicurezza tra i microservizi non si interrompa. Questo è impegnativo senza JWT.

L’uso di JWT è per trasportare informazioni sull’utente.

Puoi pensare ai token al portatore come ai contanti. Se trovi una banconota da un dollaro per terra e la presenti in un negozio, il commerciante la accetterà felicemente. Guarda l’emittente del conto e si fida di tale autorità. Alla commessa non importa dove l’hai trovata. I token al portatore sono gli stessi.

In questo blog, abbiamo visto l’importanza di alcune delle popolari implementazioni di sicurezza digitale come Oauth 2.0, OpenID e JWT. JWT svolge un ruolo importante nel trattare l’aspetto della sicurezza all’interno dei microservizi.

Poiché la propagazione dell’identità è un aspetto importante della sicurezza dei microservizi.

A volte diventa difficile implementare la sicurezza da soli. È qui che IDAM open-source svolge un ruolo molto importante nello sviluppo di applicazioni eliminando l’onere della sicurezza (digitando le dita?).

Nel prossimo blog vedremo la protezione dei microservizi usando il keycloak in dettaglio, che è uno di questi IDAM open source di Redhat.

Grazie!!

NB: L’uso delle immagini sopra è conforme agli standard di fair use. Ulteriori informazioni su sono disponibili qui .