Autorizzazioni e sicurezza in Azure Chaos Studio

Azure Chaos Studio consente di migliorare la resilienza del servizio inserendo sistematicamente errori nelle risorse di Azure. L'inserimento di errori è un modo efficace per migliorare la resilienza del servizio, ma può anche essere pericoloso. La causa di errori nell'applicazione può avere un impatto maggiore rispetto a quanto originariamente previsto e aprire opportunità per gli attori malintenzionati di infiltrarsi nelle applicazioni.

Chaos Studio dispone di un modello di autorizzazione affidabile che impedisce l'esecuzione involontaria di errori o da un attore non valido. Questo articolo illustra come proteggere le risorse destinate all'inserimento di errori usando Chaos Studio.

Come è possibile limitare la possibilità di inserire errori con Chaos Studio?

Chaos Studio offre tre livelli di sicurezza che consentono di controllare come e quando l'inserimento degli errori può verificarsi su una risorsa:

• In primo luogo, un esperimento chaos è una risorsa di Azure distribuita in un'area, un gruppo di risorse e una sottoscrizione. Gli utenti devono disporre delle autorizzazioni appropriate di Azure Resource Manager per creare, aggiornare, avviare, annullare, eliminare o visualizzare un esperimento.

  Ogni autorizzazione è un'operazione di Resource Manager che può essere assegnata in modo granulare a un'identità o assegnata come parte di un ruolo con autorizzazioni con caratteri jolly. Ad esempio, il ruolo Collaboratore in Azure dispone dell'autorizzazione */write nell'ambito assegnato, che include l'autorizzazioneMicrosoft.Chaos/experiments/write.

  Quando si tenta di controllare la possibilità di inserire errori in una risorsa, l'operazione più importante da limitare è Microsoft.Chaos/experiments/start/action. Questa operazione avvia un esperimento chaos che inserisce errori.

• In secondo luogo, un esperimento chaos ha un'identità gestita assegnata dal sistema o un'identità gestita assegnata dall'utente che esegue errori in una risorsa. Se si sceglie di usare un'identità gestita assegnata dal sistema per l'esperimento, l'identità viene creata al momento della creazione dell'esperimento nel tenant di Microsoft Entra. Gli identificatori gestiti assegnati dall'utente possono essere usati in un numero qualsiasi di esperimenti.

  In un esperimento chaos è possibile scegliere di abilitare l'assegnazione di ruolo personalizzata nella selezione dell'identità gestita assegnata dal sistema o assegnata dall'utente. L'abilitazione di questa funzionalità consente a Chaos Studio di creare e assegnare un ruolo personalizzato contenente tutte le funzionalità di azione dell'esperimento necessarie all'identità dell'esperimento (che non esistono già nella selezione dell'identità). Se un esperimento chaos usa un'identità gestita assegnata dall'utente, tutti i ruoli personalizzati assegnati all'identità dell'esperimento da Chaos Studio verranno mantenuti dopo l'eliminazione dell'esperimento.

  Se si sceglie di concedere manualmente le autorizzazioni dell'esperimento, è necessario concedere le autorizzazioni appropriate all'identità a tutte le risorse di destinazione. Se l'identità dell'esperimento non dispone dell'autorizzazione appropriata per una risorsa, non può eseguire un errore su tale risorsa.

• In terzo luogo, è necessario eseguire l'onboarding di ogni risorsa in Chaos Studio come destinazione con le funzionalità corrispondenti abilitate. Se non esiste una destinazione o la funzionalità per l'errore eseguito, l'esperimento non riesce senza influire sulla risorsa.

Identità gestita assegnata dall'utente

Un esperimento chaos può usare un'identità gestita assegnata dall'utente per ottenere autorizzazioni sufficienti per inserire errori nelle risorse di destinazione dell'esperimento. Inoltre, le identità gestite assegnate dall'utente possono essere usate in un numero qualsiasi di esperimenti in Chaos Studio. Per usare questa funzionalità, è necessario:

• Creare prima di tutto un'identità gestita assegnata dall'utente all'interno del servizio Identità gestite. A questo punto è possibile assegnare all'identità gestita assegnata dall'utente le autorizzazioni necessarie per eseguire gli esperimenti chaos.
• In secondo luogo, quando si crea l'esperimento chaos, selezionare un'identità gestita assegnata dall'utente dalla sottoscrizione. È possibile scegliere di abilitare l'assegnazione di ruolo personalizzata in questo passaggio. L'abilitazione di questa funzionalità consentirà alla selezione dell'identità le autorizzazioni necessarie in base agli errori contenuti nell'esperimento.
• In terzo luogo, dopo aver aggiunto tutti gli errori all'esperimento chaos, verificare se la configurazione dell'identità contiene tutte le azioni necessarie per l'esecuzione corretta dell'esperimento chaos. In caso contrario, contattare l'amministratore di sistema per accedere o modificare le selezioni degli errori dell'esperimento.

Autenticazione dell'agente

Quando si eseguono errori basati su agente, è necessario installare l'agente Chaos Studio nella VM o nel set di scalabilità di VM. L'agente usa un'identità gestita assegnata dall'utente per eseguire l'autenticazione a Chaos Studio e un profilo agente per stabilire una relazione con una risorsa di VM specifica.

Quando si esegue l'onboarding di una VM o di un set di scalabilità di VM per gli errori basati su agente, creare prima di tutto una destinazione dell'agente. La destinazione dell'agente deve avere un riferimento all'identità gestita assegnata dall'utente usata per l'autenticazione. La destinazione dell'agente contiene un ID profilo agente, fornito come configurazione quando si installa l'agente. I profili agente sono univoci per ogni destinazione e le destinazioni sono univoche per ogni risorsa.

Operazioni e ruoli di Azure Resource Manager

Chaos Studio ha le operazioni seguenti:

Per assegnare queste autorizzazioni in modo granulare, è possibile creare un ruolo personalizzato.

Sicurezza della rete

Tutte le interazioni utente con Chaos Studio avvengono tramite Azure Resource Manager. Se un utente avvia un esperimento, l'esperimento potrebbe interagire con endpoint diversi da Resource Manager, a seconda dell'errore:

• Errori diretti al servizio: la maggior parte degli errori diretti dal servizio viene eseguita tramite Azure Resource Manager e non richiede endpoint di rete consentiti.
• Errori di Chaos Mesh del Servizio Azure Kubernetes diretti del servizio: errori diretti del servizio per il Servizio Azure Kubernetes che usano Chaos Mesh richiedono l'accesso al server API Kubernetes del cluster del Servizio Azure Kubernetes. Diversi metodi per aggiungere gli indirizzi IP necessari sono inclusi in Autorizzare gli indirizzi IP di Chaos Studio per un cluster del servizio Azure Kubernetes.
• Errori basati su agente: per usare errori basati su agente, l'agente deve accedere al servizio agente di Chaos Studio. Una VM o un set di scalabilità di VM deve avere accesso in uscita all'endpoint del servizio agente per consentire all'agente di connettersi correttamente. L'endpoint del servizio agente è https://acs-prod-<region>.chaosagent.trafficmanager.net. È necessario sostituire il segnaposto <region> con l'area in cui viene distribuita la VM. Un esempio è https://acs-prod-eastus.chaosagent.trafficmanager.net relativo a una VM negli Stati Uniti orientali.
• Networking privato basata su agente: l'agente di Chaos Studio supporta ora la rete privata. Vedere Networking privato per Agente Chaos.

Tag di servizio

Un tag del servizio è un gruppo di prefissi di indirizzi IP che possono essere assegnati alle regole in ingresso e in uscita per i gruppi di sicurezza di rete. Gestisce automaticamente gli aggiornamenti al gruppo di prefissi di indirizzi IP senza alcun intervento. Poiché i tag del servizio abilitano principalmente il filtro degli indirizzi IP, i tag del servizio da soli non sono sufficienti per proteggere il traffico.

È possibile usare i tag del servizio per consentire in modo esplicito il traffico in ingresso da Chaos Studio senza dover conoscere gli indirizzi IP della piattaforma. Il tag del servizio di Chaos Studio è ChaosStudio.

Una limitazione dei tag del servizio è che possono essere usate solo con le applicazioni con un indirizzo IP pubblico. Se una risorsa ha solo un indirizzo IP privato, i tag del servizio non possono instradare il traffico a esso.

Casi d'uso

Chaos Studio usa tag del servizio per diversi casi d'uso.

• Per usare gli errori basati su agente, l'agente di Chaos Studio in esecuzione all'interno delle macchine virtuali del cliente deve comunicare con il servizio back-end di Chaos Studio. Il tag del servizio consente ai clienti di elencare il traffico dalla macchina virtuale al servizio Chaos Studio.
• Per usare determinati errori che richiedono comunicazioni esterne allo spazio dei nomi management.azure.com, ad esempio gli errori di Chaos Mesh per il Servizio Azure Kubernetes, il traffico proviene dal servizio Chaos Studio alla risorsa del cliente. Il tag del servizio consente ai clienti di elencare il traffico dal servizio Chaos Studio alla risorsa di destinazione.
• I clienti possono usare altri tag del servizio come parte dell'errore Regole del gruppo di sicurezza di rete per influire sul traffico da/verso determinati servizi di Azure.

Specificando il ChaosStudiotag del servizio nelle regole di sicurezza, il traffico può essere consentito o negato per il servizio Chaos Studio senza la necessità di specificare singoli indirizzi IP.

Considerazioni sulla sicurezza

Quando si valutano e si usano tag del servizio, è importante notare che non forniscono un controllo granulare sui singoli indirizzi IP e non devono essere basati su come unico metodo per proteggere una rete. Non sono una sostituzione per le misure di sicurezza di rete appropriate.

Crittografia dei dati

Chaos Studio crittografa tutti i dati per impostazione predefinita. Chaos Studio accetta solo l'input per le proprietà di sistema, ad esempio ID oggetto identità gestito, nomi di esperimento/passaggio/ramo e parametri di errore. Un esempio è l'intervallo di porte di rete da bloccare in un errore di disconnessione di rete.

Queste proprietà non devono essere usate per archiviare dati sensibili, ad esempio informazioni di pagamento o password. Per altre informazioni su come Chaos Studio protegge i dati, vedere Protezione dei dati dei clienti di Azure.

Customer Lockbox

Lockbox offre il controllo per approvare o rifiutare la richiesta del tecnico Microsoft di accedere ai dati dell'esperimento durante una richiesta di supporto.

Lockbox può essere abilitato per le informazioni sull'esperimento chaos e l'autorizzazione per accedere ai dati viene concessa dal cliente a livello di sottoscrizione se lockbox è abilitato.

Altre informazioni su Customer Lockbox per Microsoft Azure

Passaggi successivi

Ora che si è appreso come proteggere l'esperimento chaos, si è pronti a:

• Creare ed eseguire il primo esperimento
• Creare ed eseguire il primo esperimento del servizio Azure Kubernetes