Condividi tramite

Modelli di progettazione dell'architettura che supportano la sicurezza

Quando si progettano architetture dei carichi di lavoro, è consigliabile usare modelli di settore che affrontano le problematiche comuni. I modelli consentono di ottenere compromessi intenzionali all'interno dei carichi di lavoro e di ottimizzare il risultato desiderato. Possono anche contribuire a mitigare i rischi che derivano da problemi specifici, che possono influire sull'affidabilità, sulle prestazioni, sui costi e sulle operazioni. Tali rischi potrebbero essere indicativi della mancanza di garanzie di sicurezza, se non è stata lasciata automatica possono rappresentare rischi significativi per l'azienda. Questi modelli sono supportati dall'esperienza reale, sono progettati per la scalabilità cloud e i modelli operativi e sono intrinsecamente indipendenti dai fornitori. L'uso di modelli noti come modo per standardizzare la progettazione del carico di lavoro è un componente dell'eccellenza operativa.

Molti modelli di progettazione supportano direttamente uno o più pilastri dell'architettura. I modelli di progettazione che supportano il pilastro Sicurezza assegnano priorità ai concetti come la segmentazione e l'isolamento, l'autorizzazione avanzata, la sicurezza uniforme delle applicazioni e i protocolli moderni.

La tabella seguente riepiloga i modelli di progettazione dell'architettura che supportano gli obiettivi di sicurezza.

Modello Riassunto
Ambasciatore Incapsula e gestisce le comunicazioni di rete eseguendo l'offload di attività trasversali correlate alla comunicazione di rete. I servizi helper risultanti avviano la comunicazione per conto del client. Questo punto di aggregazione offre l'opportunità di aumentare la sicurezza nelle comunicazioni di rete.
Back-end per front-end Individualizza il livello di servizio di un carico di lavoro creando servizi separati esclusivi di un'interfaccia front-end specifica. A causa di questa separazione, la sicurezza e l'autorizzazione nel livello di servizio che supportano un client possono essere personalizzate in base alle funzionalità fornite dal client, riducendo potenzialmente la superficie di attacco di un'API e lo spostamento laterale tra diversi back-end che potrebbero esporre funzionalità diverse.
Paratia Introduce la segmentazione intenzionale e completa tra i componenti per isolare il raggio di esplosione di malfunzionamenti. È anche possibile usare questa strategia per contenere eventi imprevisti di sicurezza per la testa compromessa.
Verifica attestazioni Separa i dati dal flusso di messaggistica, fornendo un modo per recuperare separatamente i dati correlati a un messaggio. Questo modello supporta la conservazione dei dati sensibili dai corpi dei messaggi, mantenendo invece la gestione in un archivio dati protetto. Questa configurazione consente di stabilire un'autorizzazione più restrittiva per supportare l'accesso ai dati sensibili dai servizi che si prevede di usare i dati, ma rimuovere la visibilità dai servizi ausiliari come le soluzioni di monitoraggio delle code.
Identità federata Delega l'attendibilità a un provider di identità esterno al carico di lavoro per la gestione degli utenti e l'autenticazione per l'applicazione. Esternalizzando la gestione e l'autenticazione degli utenti, è possibile ottenere funzionalità avanzate per il rilevamento e la prevenzione delle minacce basate sull'identità senza dover implementare queste funzionalità nel carico di lavoro. I provider di identità esterni usano protocolli di autenticazione interoperatori moderni.
Portiere Esegue l'offload dell'elaborazione delle richieste specificamente per l'imposizione del controllo di sicurezza e di accesso prima e dopo l'inoltro della richiesta a un nodo back-end. L'aggiunta di un gateway nel flusso di richiesta consente di centralizzare funzionalità di sicurezza come web application firewall, protezione DDoS, rilevamento bot, manipolazione delle richieste, avvio dell'autenticazione e controlli di autorizzazione.
Aggregazione gateway Semplifica le interazioni client con il carico di lavoro aggregando le chiamate a più servizi back-end in una singola richiesta. Questa topologia spesso riduce il numero di punti di tocco di cui dispone un client con un sistema, riducendo così l'area di attacco pubblica e i punti di autenticazione. I back-end aggregati possono rimanere completamente isolati dalla rete dai client.
Offload del gateway Trasferisce l'elaborazione delle richieste a un dispositivo gateway prima e dopo l'inoltro della richiesta a un nodo back-end. L'aggiunta di un gateway nel flusso di richiesta consente di centralizzare le funzionalità di sicurezza, ad esempio web application firewall e connessioni TLS con i client. Qualsiasi funzionalità offloaded fornita dalla piattaforma offre già una maggiore sicurezza.
Server di pubblicazione/Sottoscrittore Separa i componenti in un'architettura sostituendo la comunicazione diretta da client a servizio con la comunicazione tramite un broker di messaggi intermedio o un bus di eventi. Questa sostituzione introduce un importante limite di segmentazione di sicurezza che consente ai sottoscrittori della coda di essere isolati dalla rete dal server di pubblicazione.
Quarantena Assicura che gli asset esterni soddisfino un livello di qualità concordato dal team prima di essere autorizzati a utilizzarli nel carico di lavoro. Questo controllo funge da prima convalida della sicurezza degli artefatti esterni. La convalida su un artefatto viene eseguita in un ambiente segmentato prima che venga usata all'interno del ciclo di vita di sviluppo sicuro (SDL).
Sidecar Estende la funzionalità di un'applicazione incapsulando attività non primarie o trasversali in un processo complementare esistente insieme all'applicazione principale. Incapsulando queste attività e distribuendole out-of-process, è possibile ridurre la superficie di attacco dei processi sensibili solo al codice necessario per eseguire l'attività. È anche possibile usare sidecar per aggiungere controlli di sicurezza trasversali a un componente dell'applicazione non progettato in modo nativo con tale funzionalità.
Limitazione Impone limiti alla velocità effettiva o alla velocità effettiva delle richieste in ingresso a una risorsa o a un componente. È possibile progettare i limiti per evitare l'esaurimento delle risorse che potrebbe causare abusi automatici del sistema.
Passeggiatore Concede l'accesso limitato alla sicurezza a una risorsa senza usare una risorsa intermedia per delegare l'accesso. Questo modello consente a un client di accedere direttamente a una risorsa senza bisogno di credenziali permanenti o di lunga durata. Tutte le richieste di accesso iniziano con una transazione controllabile. L'accesso concesso è quindi limitato sia nell'ambito che nella durata. Questo modello semplifica anche la revoca dell'accesso concesso.

Passaggi successivi

Esaminare i modelli di progettazione dell'architettura che supportano gli altri pilastri di Azure Well-Architected Framework:

  • Last updated on