Raccomandazioni per la creazione di una strategia di segmentazione

Articolo
11/15/2023

Si applica alla raccomandazione dell'elenco di controllo di sicurezza di Well-Architected Framework:

SE:04	Creare segmentazione intenzionale e perimetro nella progettazione dell'architettura e il footprint del carico di lavoro sulla piattaforma. La strategia di segmentazione deve includere reti, ruoli e responsabilità, identità del carico di lavoro e organizzazione delle risorse.

Un segmento è una sezione logica della soluzione che deve essere protetta come un'unica unità. Una strategia di segmentazione definisce il modo in cui un'unità deve essere separata da altre unità con il proprio set di requisiti e misure di sicurezza.

Questa guida descrive i consigli per la creazione di una strategia di segmentazione unificata. Usando i limiti di isolamento e i limiti di isolamento nei carichi di lavoro, è possibile progettare un approccio di sicurezza che funziona per l'utente.

Definizioni

Termine	Definizione
Containment	Tecnica per contenere il raggio di esplosione se un utente malintenzionato ottiene l'accesso a un segmento.
Accesso con privilegi minimi	Principio Zero Trust che mira a ridurre al minimo un set di autorizzazioni per completare una funzione di processo.
Perimetro	Limite di attendibilità intorno a un segmento.
Organizzazione delle risorse	Strategia per raggruppare le risorse correlate in base ai flussi all'interno di un segmento.
Ruolo	Set di autorizzazioni necessarie per completare una funzione di processo.
Segment	Unità logica isolata da altre entità e protetta da un set di misure di sicurezza.

Strategie di progettazione chiave

Il concetto di segmentazione viene comunemente usato per le reti. Tuttavia, lo stesso principio sottostante può essere usato in tutta una soluzione, inclusa la segmentazione delle risorse per scopi di gestione e il controllo di accesso.

La segmentazione consente di progettare un approccio di sicurezza che applica la difesa approfondita in base ai principi del modello di Zero Trust. Assicurarsi che un utente malintenzionato che viola un segmento di rete non possa accedere a un altro segmentando i carichi di lavoro con controlli di identità diversi. In un sistema sicuro, gli attributi di identità e rete bloccano l'accesso non autorizzato e nascondono gli asset da esporre. Ecco alcuni esempi di segmenti:

Sottoscrizioni che isolano i carichi di lavoro di un'organizzazione
Gruppi di risorse che isolano gli asset del carico di lavoro
Ambienti di distribuzione che isolano la distribuzione in base alle fasi
Team e ruoli che isolano le funzioni del processo correlate allo sviluppo e alla gestione dei carichi di lavoro
Livelli di applicazione che isolano l'utilità del carico di lavoro
Microservizi che isolano un servizio da un altro

Prendere in considerazione questi elementi chiave della segmentazione per assicurarsi di creare una strategia completa di difesa approfondita:

Il limite o il perimetro è il bordo di ingresso di un segmento in cui si applicano i controlli di sicurezza. I controlli perimetrali devono bloccare l'accesso al segmento a meno che non sia consentito in modo esplicito. L'obiettivo è impedire a un utente malintenzionato di attraversare il perimetro e di ottenere il controllo del sistema. Ad esempio, un livello applicazione potrebbe accettare un token di accesso dell'utente finale quando elabora una richiesta. Tuttavia, il livello dati potrebbe richiedere un token di accesso diverso con un'autorizzazione specifica, che solo il livello applicazione può richiedere.
Il contenimento è il bordo di uscita di un segmento che impedisce lo spostamento laterale nel sistema. L'obiettivo del contenimento è ridurre al minimo l'effetto di una violazione. Ad esempio, una rete virtuale di Azure può essere usata per configurare i gruppi di sicurezza di routing e di rete per consentire solo i modelli di traffico previsti, evitando il traffico ai segmenti di rete arbitrari.
L'isolamento è la pratica del raggruppamento di entità con garanzie simili insieme per proteggerle con un limite. L'obiettivo è semplificare la gestione e il contenimento di un attacco all'interno di un ambiente. Ad esempio, è possibile raggruppare le risorse correlate a un carico di lavoro specifico in una sottoscrizione di Azure e quindi applicare il controllo di accesso in modo che solo i team di carico di lavoro specifici possano accedere alla sottoscrizione.

È importante notare la distinzione tra perimetro e isolamento. Il perimetro fa riferimento ai punti di posizione che devono essere controllati. L'isolamento riguarda il raggruppamento. Contenere attivamente un attacco usando questi concetti.

L'isolamento non significa creare silo nell'organizzazione. Una strategia di segmentazione unificata fornisce l'allineamento tra i team tecnici e imposta linee chiare di responsabilità. Clarity riduce il rischio di errori umani e errori di automazione che possono causare vulnerabilità di sicurezza, tempi di inattività operativi o entrambi. Si supponga che venga rilevata una violazione della sicurezza in un componente di un sistema aziendale complesso. È importante che tutti comprendano chi è responsabile di tale risorsa in modo che la persona appropriata sia inclusa nel team di valutazione. L'organizzazione e gli stakeholder possono identificare rapidamente come rispondere a diversi tipi di eventi imprevisti creando e documentando una buona strategia di segmentazione.

Tradeoff: la segmentazione introduce complessità perché è presente un sovraccarico nella gestione. C'è anche un compromesso in costo. Ad esempio, viene eseguito il provisioning di più risorse quando gli ambienti di distribuzione eseguiti side-by-side vengono segmentati.

Rischio: la micro-segmentazione oltre un limite ragionevole perde il vantaggio dell'isolamento. Quando si creano troppi segmenti, diventa difficile identificare i punti di comunicazione o consentire percorsi di comunicazione validi all'interno del segmento.

Identità come perimetro

Varie identità, ad esempio persone, componenti software o dispositivi accedono ai segmenti di carico di lavoro. L'identità è un perimetro che deve essere la linea primaria di difesa per autenticare e autorizzare l'accesso tra limiti di isolamento, indipendentemente dalla posizione in cui proviene la richiesta di accesso. Usare l'identità come perimetro per:

Assegnare l'accesso in base al ruolo. Le identità devono accedere solo ai segmenti necessari per eseguire il proprio lavoro. Ridurre al minimo l'accesso anonimo comprendendo i ruoli e le responsabilità dell'identità richiesta in modo da conoscere l'entità che richiede l'accesso a un segmento e a quale scopo.

Un'identità potrebbe avere ambiti di accesso diversi in segmenti diversi. Prendere in considerazione una configurazione tipica dell'ambiente, con segmenti separati per ogni fase. Le identità associate al ruolo sviluppatore hanno accesso in lettura-scrittura all'ambiente di sviluppo. Quando la distribuzione passa alla gestione temporanea, tali autorizzazioni vengono frenate. Al momento in cui il carico di lavoro viene promosso all'ambiente di produzione, l'ambito per gli sviluppatori viene ridotto all'accesso di sola lettura.
Prendere in considerazione le identità di applicazione e gestione separatamente. Nella maggior parte delle soluzioni gli utenti hanno un livello di accesso diverso rispetto agli sviluppatori o agli operatori. In alcune applicazioni è possibile usare sistemi di identità o directory diversi per ogni tipo di identità. È consigliabile usare gli ambiti di accesso e creare ruoli separati per ogni identità.
Assegnare l'accesso con privilegi minimi. Se l'identità è consentita l'accesso, determinare il livello di accesso. Iniziare con il privilegio minimo per ogni segmento e ampliare l'ambito solo quando necessario.

Applicando il privilegio minimo, si limitano gli effetti negativi se l'identità è mai compromessa. Se l'accesso è limitato per tempo, la superficie di attacco viene ridotta ulteriormente. L'accesso limitato al tempo è particolarmente applicabile agli account critici, ad esempio amministratori o componenti software che hanno un'identità compromessa.

Compromesso: le prestazioni del carico di lavoro possono essere interessate dai perimetrali delle identità. La verifica di ogni richiesta richiede cicli di calcolo aggiuntivi e I/O di rete aggiuntivi.

Il controllo degli accessi in base al ruolo comporta anche un sovraccarico di gestione. Tenere traccia delle identità e degli ambiti di accesso possono diventare complessi nelle assegnazioni di ruolo. La soluzione alternativa consiste nell'assegnare ruoli ai gruppi di sicurezza anziché alle singole identità.

Rischio: le impostazioni di identità possono essere complesse. Le configurazioni non riuscite possono influire sull'affidabilità del carico di lavoro. Si supponga, ad esempio, che si verifichi un'assegnazione di ruolo non configurata non configurata che abbia negato l'accesso a un database. Le richieste iniziano a non riuscire, causando problemi di affidabilità che non possono altrimenti essere rilevati fino al runtime.

Per informazioni sui controlli delle identità, vedere Gestione delle identità e degli accessi.

Al contrario dei controlli di accesso alla rete, l'identità convalida il controllo di accesso in fase di accesso. È consigliabile condurre una verifica di accesso regolare e richiedere un flusso di lavoro di approvazione per ottenere privilegi per gli account di impatto critico. Ad esempio, vedere Modelli di segmentazione delle identità.

Rete come perimetro

I perimetrali delle identità sono agnostici di rete mentre i perimetrali di rete aumentano l'identità, ma non lo sostituiscono mai. I perimetrali di rete vengono stabiliti per controllare il raggio di esplosione, bloccare l'accesso imprevisto, vietato e non sicuro e offuscare le risorse del carico di lavoro.

Mentre lo stato attivo principale del perimetro dell'identità è minimo, si presuppone che vi sia una violazione quando si progetta il perimetro della rete.

Creare perimetrali definiti dal software nel footprint di rete usando i servizi e le funzionalità di Azure. Quando un carico di lavoro (o parte di un determinato carico di lavoro) viene inserito in segmenti separati, si controlla il traffico da o verso tali segmenti per proteggere i percorsi di comunicazione. Se un segmento è compromesso, è contenuto e impedisce la distribuzione in seguito attraverso il resto della rete.

Si pensi a un utente malintenzionato per ottenere un piè di pagina all'interno del carico di lavoro e stabilire controlli per ridurre al minimo l'espansione. I controlli devono rilevare, contenere e impedire agli utenti malintenzionati di ottenere l'accesso all'intero carico di lavoro. Ecco alcuni esempi di controlli di rete come perimetro:

Definire il perimetro perimetrale tra reti pubbliche e la rete in cui viene inserito il carico di lavoro. Limitare la linea di vista dalle reti pubbliche alla rete il più possibile.
Implementare zone demilitarizzate (DMZ) davanti all'applicazione con controlli appropriati tramite firewall.
Creare micro-segmentazione all'interno della rete privata raggruppando parti del carico di lavoro in segmenti separati. Stabilire percorsi di comunicazione sicuri tra di essi.
Creare limiti in base alla finalità. Ad esempio, segmentare le reti funzionali del carico di lavoro dalle reti operative.

Per modelli comuni correlati alla segmentazione di rete, vedere Modelli di segmentazione di rete.

Compromesso: i controlli di sicurezza di rete sono spesso costosi perché sono inclusi negli SKU Premium. La configurazione delle regole nei firewall comporta spesso complessità travolgente che richiedono eccezioni estese.

La connettività privata modifica la progettazione dell'architettura, spesso aggiungendo più componenti come jump box per l'accesso privato ai nodi di calcolo.

Poiché i perimetrali di rete si basano su punti di controllo o hop, sulla rete, ogni hop può essere un potenziale punto di errore. Questi punti possono avere un effetto sull'affidabilità del sistema.

Rischio: i controlli di rete sono basati su regole e c'è una significativa probabilità di errori di configurazione, che è un problema di affidabilità.

Per informazioni sui controlli di rete, vedere Rete e connettività.

Ruoli e responsabilità

La segmentazione che impedisce confusione e rischi di sicurezza viene ottenuta definendo chiaramente le linee di responsabilità all'interno di un team del carico di lavoro.

Documentare e condividere ruoli e funzioni per creare coerenza e facilitare la comunicazione. Designare gruppi o singoli ruoli responsabili delle funzioni chiave. Prendere in considerazione i ruoli predefiniti in Azure prima di creare ruoli personalizzati per gli oggetti.

Prendere in considerazione la coerenza durante l'accodamento di diversi modelli organizzativi durante l'assegnazione delle autorizzazioni per un segmento. che possono variare da un gruppo IT centralizzato a piccoli team IT e DevOps pressoché indipendenti.

Rischio: l'appartenenza ai gruppi può cambiare nel tempo quando i dipendenti si aggiungono o lasciano i team o cambiano i ruoli. La gestione dei ruoli tra segmenti può comportare un sovraccarico di gestione.

Organizzazione delle risorse

La segmentazione consente di isolare le risorse del carico di lavoro da altre parti dell'organizzazione o anche all'interno del team. I costrutti di Azure, ad esempio gruppi di gestione, sottoscrizioni, ambienti e gruppi di risorse, sono modi per organizzare le risorse che promuovono la segmentazione. Ecco alcuni esempi di isolamento a livello di risorsa:

La persistenza poliglot implica una combinazione di tecnologie di archiviazione dei dati anziché di un singolo sistema di database per supportare la segmentazione. Usare la persistenza poliglot per la separazione da vari modelli di dati, la separazione delle funzionalità, ad esempio l'archiviazione e l'analisi dei dati o per separare i modelli di accesso.
Allocare un servizio per ogni server quando si organizza il calcolo. Questo livello di isolamento riduce al minimo la complessità e può aiutare a contenere un attacco.
Azure fornisce l'isolamento predefinito per alcuni servizi, ad esempio la separazione del calcolo dall'archiviazione. Per altri esempi, vedere Isolamento nel cloud pubblico di Azure.

Compromesso: l'isolamento delle risorse potrebbe comportare un aumento del costo totale della proprietà (TCO). Per gli archivi dati, è possibile aggiungere complessità e coordinamento durante il ripristino di emergenza.

Facilitazione di Azure

Alcuni servizi di Azure sono disponibili per l'uso nell'implementazione di una strategia di segmentazione, come descritto nelle sezioni seguenti.

Identità

Il controllo degli accessi in base al ruolo di Azure supporta la segmentazione isolando l'accesso per funzione del processo. Solo alcune azioni sono consentite per determinati ruoli e ambiti. Ad esempio, le funzioni del processo che devono osservare solo il sistema possono essere assegnate autorizzazioni di lettura rispetto alle autorizzazioni di collaboratore che consentono all'identità di gestire le risorse.

Per altre informazioni, vedere Procedure consigliate per il controllo degli accessi in base al ruolo.

Rete

Reti virtuali: le reti virtuali forniscono il contenimento a livello di rete delle risorse senza aggiungere traffico tra due reti virtuali. Le reti virtuali vengono create in spazi di indirizzi privati all'interno di una sottoscrizione

Gruppi di sicurezza di rete (NSG): meccanismo di controllo degli accessi per controllare il traffico tra le risorse nelle reti virtuali e nelle reti esterne, ad esempio Internet. Implementare route definite dall'utente (UDR) per controllare l'hop successivo per il traffico. I gruppi di sicurezza di rete possono accettare la strategia di segmentazione a un livello granulare creando perimetrali per una subnet, una macchina virtuale o un gruppo di macchine virtuali. Per informazioni sulle possibili operazioni con subnet in Azure, vedere Subnet.

Gruppi di sicurezza delle applicazioni : i gruppi di sicurezza delle applicazioni consentono di raggruppare un set di macchine virtuali con un tag dell'applicazione e definire le regole di traffico che vengono quindi applicate a ognuna delle macchine virtuali sottostanti.

Firewall di Azure: un servizio nativo del cloud, che può essere distribuito nella rete virtuale o nelle distribuzioni dell'hub di Azure rete WAN virtuale. Usare Firewall di Azure per filtrare il flusso del traffico tra risorse cloud, Internet e risorse locali. Usare Firewall di Azure o Firewall di Azure Manager per creare regole o criteri che consentono o negano il traffico usando i controlli livello 3 a livello 7. Filtrare il traffico Internet usando Firewall di Azure e terze parti indirizzando il traffico tramite provider di sicurezza di terze parti per la protezione avanzata dei filtri e degli utenti. Azure supporta la distribuzione di appliance virtuali di rete, che consente di segmentare da firewall di terze parti.

Esempio

Ecco alcuni modelli comuni per segmentare un carico di lavoro in Azure. Scegliere un modello in base alle proprie esigenze.

Questo esempio si basa sull'ambiente IT (Information Technology) stabilito nella baseline di sicurezza (SE:01). Il diagramma seguente mostra la segmentazione a livello di gruppo di gestione eseguita da un'organizzazione.

Modelli di segmentazione delle identità

Modello 1: Raggruppamento basato sul titolo del processo

Un modo per organizzare i gruppi di sicurezza è per titolo di lavoro, ad esempio software engineer, amministratore del database, ingegnere di affidabilità del sito, tecnico della garanzia di qualità o analista della sicurezza. Questo approccio comporta la creazione di gruppi di sicurezza per il team del carico di lavoro in base ai propri ruoli, senza considerare il lavoro che deve essere eseguito. Concedere autorizzazioni di controllo degli accessi in base al ruolo dei gruppi di sicurezza, in piedi o just-in-time (JIT), in base alle proprie responsabilità nel carico di lavoro. Assegnare principi umani e di servizio ai gruppi di sicurezza in base all'accesso in base alle esigenze.

L'appartenenza è altamente visibile a livello di assegnazione del ruolo, rendendo più semplice visualizzare l'accesso a un ruolo . Ogni persona è in genere un membro di un solo gruppo di sicurezza, che semplifica l'onboarding e l'offboarding. Tuttavia, a meno che i titoli di lavoro si sovrapponga perfettamente alle responsabilità, il raggruppamento basato sul titolo non è ideale per l'implementazione dei privilegi minimi. È possibile combinare l'implementazione con il raggruppamento basato su funzioni.

Modello 2: Raggruppamento basato su funzioni

Il raggruppamento basato su funzioni è un metodo di organizzazione del gruppo di sicurezza che riflette il lavoro discreto che deve essere eseguito, non tenendo conto della struttura del team. Con questo modello, si concede ai gruppi di sicurezza autorizzazioni di controllo degli accessi in base al ruolo, in base alle esigenze, in base alla funzione necessaria nel carico di lavoro.

Assegnare principi umani e di servizio ai gruppi di sicurezza in base all'accesso in base alle esigenze. Se possibile, usare gruppi omogenei esistenti come membri dei gruppi basati su funzioni, ad esempio questi gruppi dal modello 1. Esempi di gruppi basati su funzioni includono:

Operatori di database di produzione
Operatori di database di preproduzione
Operatori di rotazione dei certificati di produzione
Operatori di rotazione dei certificati di preproduzione
Produzione live-site/triage
Preproduzione di tutti gli accessi

Questo approccio gestisce l'accesso più rigoroso ai privilegi minimi e fornisce gruppi di sicurezza in cui l'ambito è evidente, che semplifica il controllo delle appartenenze relative alle attività di lavoro eseguite. Spesso esiste un ruolo predefinito di Azure per corrispondere a questa funzione del processo.

Tuttavia, l'appartenenza viene astratta almeno un livello, forzando l'utente a passare al provider di identità per comprendere chi è nel gruppo quando si guarda dal punto di vista della risorsa. Inoltre, una persona deve avere più appartenenze mantenute per la copertura completa. La matrice di gruppi di sicurezza sovrapposti può essere complessa.

Il modello 2 è consigliato per rendere gli schemi di accesso incentrati, non il organigramma. I organigrammi e i ruoli dei membri a volte cambiano. L'acquisizione dell'identità e della gestione degli accessi del carico di lavoro da una prospettiva funzionale consente di astrarre l'organizzazione del team dalla gestione sicura del carico di lavoro.

Modelli di segmentazione di rete

Modello 1: Segmentazione all'interno di un carico di lavoro (limiti flessibili)

In questo modello il carico di lavoro viene inserito in una singola rete virtuale usando le subnet per contrassegnare i limiti. La segmentazione viene ottenuta usando due subnet, una per il database e una per i carichi di lavoro Web. È necessario configurare gruppi di sicurezza di rete che consentono alla subnet 1 di comunicare solo con subnet 2 e subnet 2 per comunicare solo con Internet. Questo modello fornisce il controllo livello 3.

Modello 2: Segmentazione all'interno di un carico di lavoro

Questo modello è un esempio di segmentazione a livello di piattaforma. I c omponenti del carico di lavorovengono distribuiti tra più reti senza eseguire il peering tra di essi. Tutte le comunicazioni vengono instradate tramite un intermediario che funge da punto di accesso pubblico. Il team del carico di lavoro possiede tutte le reti.

Il modello 2 offre contenimento, ma presenta la complessità aggiuntiva della gestione e del dimensionamento della rete virtuale. La comunicazione tra le due reti avviene sulla rete Internet pubblica, che può essere un rischio. Esiste anche la latenza con le connessioni pubbliche. Tuttavia, è possibile eseguire il peering delle due reti, suddividendo la segmentazione collegandole per creare un segmento più grande. Il peering deve essere eseguito quando non sono necessari altri endpoint pubblici.

Considerazioni	Modello 1	Modello 2
Connettività e routing: modalità di comunicazione di ogni segmento	Il routing di sistema fornisce la connettività predefinita ai componenti del carico di lavoro. Nessun componente esterno può comunicare con il carico di lavoro.	All'interno della rete virtuale, uguale al modello 1. Tra le reti, il traffico passa dalla rete Internet pubblica. Non esiste alcuna connettività diretta tra le reti.
Filtro del traffico a livello di rete	Il traffico tra i segmenti è consentito per impostazione predefinita. Usare gruppi di sicurezza di rete o gruppi di sicurezza di rete per filtrare il traffico.	All'interno della rete virtuale, uguale al modello 1. Tra le reti è possibile filtrare sia il traffico in ingresso che quello in uscita attraverso un firewall.
Endpoint aperti pubblici non intenzionali	Le schede di interfaccia di rete (NIC) non ottengono indirizzi IP pubblici. Le reti virtuali non sono esposte a Gestione API Internet.	Uguale al modello 1. Endpoint pubblico aperto previsto in una rete virtuale, che può essere configurato in modo errato per accettare più traffico.

Organizzazione delle risorse

Organizzare le risorse di Azure in base alla responsabilità di proprietà

Si consideri un ambiente di Azure che contiene più carichi di lavoro e componenti del servizio condiviso, ad esempio reti virtuali hub, firewall, servizi di gestione delle identità e servizi di sicurezza come Microsoft Sentinel. I componenti in tutta la proprietà devono essere raggruppati in base alle aree funzionali, ai carichi di lavoro e alla proprietà. Ad esempio, le risorse di rete condivise devono essere raggruppate in una singola sottoscrizione e gestite da un team di rete. I componenti dedicati ai singoli carichi di lavoro devono trovarsi nel proprio segmento e possono essere ulteriormente suddivisi in base ai livelli applicazione o ad altri principi dell'organizzazione.

Concedere l'accesso per gestire le risorse all'interno di singoli segmenti creando assegnazioni di ruolo controllo degli accessi in base al ruolo. Ad esempio, al team di rete cloud potrebbe essere concesso l'accesso amministrativo alla sottoscrizione che contiene le risorse, ma non alle singole sottoscrizioni del carico di lavoro.

Una buona strategia di segmentazione consente di identificare facilmente i proprietari di ogni segmento. Prendere in considerazione l'uso dei tag delle risorse di Azure per annotare gruppi di risorse o sottoscrizioni con il team proprietario.

Configurare ed esaminare il controllo di accesso

Concedere l'accesso appropriato in base alle esigenze definendo chiaramente i segmenti per le risorse.

Considerare il principio dei privilegi minimi quando si definiscono i criteri di controllo di accesso. È importante distinguere tra operazioni del piano di controllo (gestione della risorsa stessa) e operazioni del piano dati (accesso ai dati archiviati dalla risorsa). Si supponga, ad esempio, di avere un carico di lavoro che contiene un database con informazioni riservate sui dipendenti. È possibile concedere l'accesso di gestione ad alcuni utenti che devono configurare impostazioni come i backup del database o gli utenti che monitorano le prestazioni del server di database. Tuttavia, questi utenti non devono essere in grado di eseguire query sui dati sensibili archiviati nel database. Selezionare le autorizzazioni che concedono l'ambito minimo necessario per consentire agli utenti di eseguire i propri compiti. Esaminare regolarmente le assegnazioni di ruolo per ogni segmento e rimuovere l'accesso non più necessario.

Nota

Alcuni ruoli con privilegi elevati, ad esempio il ruolo proprietario nel controllo degli accessi in base al ruolo, consentono agli utenti di concedere ad altri utenti l'accesso a una risorsa. Limitare il numero di utenti o gruppi assegnati al ruolo proprietario ed esaminare regolarmente i log di controllo per assicurarsi che eseguano solo operazioni valide.

Elenco di controllo relativo alla sicurezza

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per la sicurezza

Raccomandazioni per la creazione di una strategia di segmentazione