Quando la sicurezza non è più un’opzione: parliamo del campo di battaglia invisibile nei microservizi

Immagina di aver trascorso diversi mesi a costruire un sistema di controllo di un servomotore. I servi di ogni giunto sono regolati con estrema precisione e i movimenti dei bracci robotici sono fluidi come una danza. Ma una mattina scopri che un modulo improvvisamente "si è guastato" - non un guasto meccanico, ma qualcuno è entrato attraverso una piccola porta che non hai nemmeno notato e ha cambiato silenziosamente alcuni parametri. L'intero sistema funziona ancora, ma sai, qualcosa è diverso.

Questa è probabilmente la sensazione che molte persone affrontano ogni giorno nel mondo dei microservizi.

Perché rattoppiamo sempre i buchi?

Qualcuno una volta mi ha posto una domanda: perché molti team "risolvono" sempre i problemi di sicurezza? In effetti, la risposta è abbastanza semplice: all'inizio non sai dove sia la porta.

L'architettura dei microservizi è come un complesso sistema di trasmissione meccanica. Ogni servizio è un ingranaggio indipendente, ruota indipendentemente e si ingrana tra loro. Il problema è che più ingranaggi ci sono, maggiori sono i divari. Fissi l'albero di trasmissione principale e dimentichi che anche quella piccola pompa di lubrificazione può rimanere bloccata. Quando senti un rumore anomalo, l'usura si è già verificata.

L'approccio tradizionale è quello di coprire l'intero sistema con un guscio protettivo. Ma ai microservizi non piacciono le coperture: hanno bisogno di respirare e scalare in modo flessibile. Quindi la sicurezza diventa l’arte di mettere il nastro adesivo su ogni punto di connessione. Risarcisci qui oggi, risarcisci lì domani, sempre al passo con i tempi.

Un’altra prospettiva: la sicurezza dovrebbe essere integrata nel sistema

Qualche anno fa, improvvisamente ho capito qualcosa mentre eseguivo il debug di un braccio robotico a sei assi. Il miglior meccanismo di sicurezza non è una serratura esterna, ma le "proprietà meccaniche" integrate nel progetto. Proprio come i circuiti di feedback all'interno dei servi, non vengono installati successivamente, ma fanno parte della rotazione del motore.

Anche la sicurezza dei microservizi dovrebbe essere così. Non dovrebbe essere un elemento di una lista di controllo, ma un attributo intrinseco di ogni servizio.

Ma come?

Sfatare tre miti comuni

Mito 1: “È sufficiente avere un firewall” È come installare una serratura sulla porta della tua officina lasciando le finestre aperte. La comunicazione tra i microservizi spesso avviene sulla rete interna e non è visibile al firewall. Queste chiamate da servizio a servizio sono come il trasferimento di componenti tra varie postazioni di lavoro in un'officina: anche se la porta è chiusa a chiave, i componenti continuano a circolare all'interno.

Mito 2: "Utilizziamo la tecnologia di crittografia più recente" La crittografia è importante, ma è come applicare il miglior olio antiruggine agli ingranaggi di precisione. Se la persona che applica l'olio ha dimenticato un piccolo cuscinetto o lo ha applicato in modo troppo spesso compromettendo la dissipazione del calore, il problema persiste. Errori di configurazione della crittografia, confusione nella gestione delle chiavi, certificati scaduti... questi sono i dettagli che vanno storti più spesso di loro stessi.

Mito 3: "Il nostro codice è tutto rivisto" La revisione manuale è ottima, ma è come ispezionare visivamente ogni ingranaggio per individuare eventuali segni di denti. Quando hai centinaia di servizi, aggiornati ogni settimana, manca sempre qualcosa. Per non parlare delle librerie di terze parti a cui fai affidamento: proprio come l'attrezzatura finita che acquisti, credi nella sua qualità, ma capisci davvero ogni processo di trattamento termico?

una strategia più intelligente

Successivamente ho sviluppato un'abitudine: ogni volta che progetto un nuovo modulo mi pongo due domande:

1. Se questo servizio vuole fare cose cattive, fino a che punto può arrivare?
2. Se qualcuno vuole fare qualcosa di dannoso a questo servizio, qual è il punto più semplice da cui iniziare?

Può sembrare un po’ nevrotico, ma funziona. Proprio come quando si progetta una struttura meccanica, non si considera solo come si muove, ma anche cosa fare se si blocca.

Nello specifico mi concentrerò su questi luoghi:

• L’identità non è solo una chiave. Dare ad ogni servizio una chiara identità è come dare un numero ad ogni utensile dell'officina. Ma, cosa ancora più importante, l’identità dovrebbe avere un chiaro ambito di autorità: questa chiave può serrare solo dadi di una certa dimensione, questo saldatore può essere utilizzato solo su una determinata postazione di lavoro. Le autorizzazioni dovrebbero essere dettagliate e appena sufficienti.

• Le conversazioni necessitano di supervisione. Ogni chiamata tra servizi dovrebbe essere registrata e ispezionabile. Non monitoraggio, ma come una scheda del flusso di lavoro in officina: chi ha preso quale parte, l'ha consegnata a chi e quando è stata completata. In questo modo, quando si verifica un problema in un determinato collegamento, puoi trovare rapidamente indizi.

• L'impostazione predefinita è "Nega". L'impostazione predefinita su molti sistemi è "Consenti" finché non la disabiliti esplicitamente. È come un laboratorio in cui tutti gli strumenti sono disponibili per impostazione predefinita. Un approccio migliore è fare il contrario: tutte le operazioni vengono negate per impostazione predefinita e vengono consentite solo quelle chiaramente necessarie. Sebbene la configurazione iniziale sia più problematica, a lungo termine è molto più sicura.

• Non fidarti della rete interna. L’officina non necessita di una gestione interna? Al contrario. Si dovrebbe presumere che l'interno sia pericoloso quanto l'esterno: un servizio compromesso può diventare un trampolino di lancio per attacchi ad altri servizi. Anche la comunicazione tra i servizi richiede l'autenticazione e la crittografia, anche se si trovano nella stessa sala computer.

esisterekpowerin pratica

Una volta avevamo bisogno di aggiornare il sistema di controllo automatizzato della linea di produzione di un cliente. Il sistema originario aveva un’architettura monolitica e le misure di sicurezza erano concentrate ai margini. Durante la migrazione ai microservizi, non ci siamo affrettati a scrivere un nuovo codice, ma prima abbiamo disegnato una "mappa di fiducia".

Ogni servizio è un nodo e le connessioni tra i nodi rappresentano le relazioni di comunicazione. Poi abbiamo fatto una cosa divertente: abbiamo colorato ogni linea. Il verde indica un livello di fiducia elevato, il giallo indica un livello di fiducia limitato e il rosso indica la necessità di una revisione rigorosa.

L'immagine risultante sembrava un dipinto astratto: per lo più giallo, pochissimo verde e rosso sparso qua e là. Il cliente era un po' nervoso dopo averlo visto: "Con così tante restrizioni, il sistema non funzionerà?"

Ho detto di no. È come installare limitatori e sensori di coppia su ciascuna articolazione di un braccio robotico: non interferiscono con il normale movimento e funzionano solo in caso di anomalia. Tre mesi dopo, il sistema è andato online e il team operativo e di manutenzione ha riferito che, sebbene la configurazione fosse un po’ complicata, potevano dormire molto più profondamente la notte.

Torniamo alla domanda iniziale

Quale dovrebbe essere la sicurezza? Nella progettazione meccanica, è il fattore di sicurezza dei materiali, delle strutture di supporto ridondanti e dell'analisi delle modalità di guasto. Nei microservizi, ciò che conta è la consapevolezza dell’identità di ogni pezzo di codice, i confini chiari tra i servizi e l’atteggiamento cauto predefinito.

Non è un componente aggiuntivo, ma parte della filosofia di design. Proprio come non pensi alla protezione dalla polvere dopo aver installato la guida di precisione, sai fin dall'inizio che funziona in un ambiente pulito.

Ora, quando guardi la tua architettura di microservizi, potresti voler cambiare prospettiva: le chiamate tra servizi non sono solo trasmissione di dati, ma anche trasferimento di fiducia. E ogni trasferimento dovrebbe avere un’adeguata supervisione e protezione.

Dopotutto, i buoni sistemi non sviluppano resilienza solo dopo che si presentano le vulnerabilità. Dovrebbe impedire che gli attacchi inizino prima che si manifestino le vulnerabilità. La differenza tra questo è spesso la differenza tra il funzionamento stabile quotidiano e le riparazioni di emergenza a tarda notte.

Fondata nel 2005,kpowerè dedicata a un produttore professionale di unità di movimento compatte, con sede a Dongguan, nella provincia del Guangdong, in Cina. Sfruttando le innovazioni nella tecnologia di azionamento modulare,kpowerintegra motori ad alte prestazioni, riduttori di precisione e sistemi di controllo multiprotocollo per fornire soluzioni di sistemi di azionamento intelligenti efficienti e personalizzate. Kpower ha fornito soluzioni di sistemi di azionamento professionali a oltre 500 clienti aziendali in tutto il mondo con prodotti che coprono vari campi come sistemi domestici intelligenti, elettronica automatica, robotica, agricoltura di precisione, droni e automazione industriale.