Tassonomia delle etichette di riservatezza per la conformità del governo australiano con PSPF

Questo articolo fornisce indicazioni per le organizzazioni governative australiane sulle etichette di riservatezza necessarie per l'allineamento con le classificazioni di sicurezza dei dati. Il suo scopo è aiutare le organizzazioni a decidere una tassonomia delle etichette di riservatezza appropriata da distribuire nei propri ambienti Microsoft 365. I consigli in questo articolo sono stati scritti per allinearsi ai criteri PSPF (Protective Security Policy Framework) 8: Informazioni riservate e classificate.

Le organizzazioni governative australiane devono determinare una tassonomia dell'etichetta di riservatezza appropriata prima di distribuire la funzionalità. Le etichette necessarie variano tra le organizzazioni a seconda dei tipi di informazioni con cui lavorano.

Configurazione standard

I requisiti tipici delle etichette includono una combinazione di classificazioni di sicurezza, spesso combinate con un indicatore di gestione delle informazioni (IMM) e/o avvertenze. È anche probabile che le organizzazioni con una maturità di conformità elevata includano etichette per soddisfare vari requisiti di sicurezza dei dati. Ad esempio, etichette che applicano la crittografia di Azure Rights Management per garantire che solo gli utenti autorizzati possano accedere agli elementi.

L'esempio seguente illustra i contrassegni di base per l'organizzazione governativa australiana:

Le etichette sono singolari e una sola etichetta può essere applicata a un elemento o a una posizione. Qualsiasi combinazione necessaria di questi tre elementi deve essere assemblata in una singola etichetta per soddisfare i requisiti. Ad esempio, se un elemento deve essere classificato come PROTECTED e contiene anche informazioni CABINET, deve essere fornita una singola etichetta contenente questi elementi; ARMADIO PROTETTO.

Nell'esempio seguente vengono illustrate le etichette di base per le organizzazioni governative australiane. Questo elenco usa una combinazione di etichette padre (categorie) ed etichette secondarie:

• UFFICIOSO
• UFFICIALE
• OFFICIAL Sensitive (Categoria)
  • OFFICIAL Sensitive
  • OFFICIAL Sensitive Personal Privacy
  • OFFICIAL Sensitive Legal Privilege
  • OFFICIAL Sensitive Legislative Secrecy
  • OFFICIAL Sensitive NATIONAL CABINET
• PROTECTED (Categoria)
  • PROTETTO
  • PRIVACY PERSONALE PROTETTA
  • PRIVILEGIO LEGALE PROTETTO
  • PROTECTED Segreto legislativo
  • ARMADIO PROTETTO

Le organizzazioni governative con requisiti più complessi necessitano di etichette aggiuntive. Il numero massimo di etichette che un'organizzazione vuole distribuire è più rilevante per i vincoli di usabilità rispetto alle limitazioni tecniche. Esiste tuttavia un limite di 500 etichette che possono essere create per ogni organizzazione.

L'uso di etichette secondarie nell'elenco precedente ha lo scopo di migliorare l'esperienza utente, ma ha anche alcuni effetti benefici sul comportamento delle etichette. Ad esempio, la giustificazione delle modifiche delle etichette non viene attivata quando un utente cambia tra etichette secondarie. In questo modo gli utenti possono applicare IMM, avvertenze o controlli di sicurezza diversi e attivare la giustificazione solo se tentano di ridurre la classificazione di sicurezza applicata spostandosi all'esterno di una categoria di etichette.

Organizzazioni che lavorano presso OFFICIAL

Le organizzazioni governative australiane sono in grado di configurare gli ambienti Microsoft 365 per archiviare le informazioni fino a PROTECTED.

Per la documentazione del programma IRAP (Registered Assessors Program) di Microsoft Infosec, vedere il portale Microsoft Service Trust.

Molte organizzazioni governative australiane hanno intenzionalmente limitato il livello massimo di riservatezza per i dati che hanno consentito di archiviare all'interno della tenancy, riducendo a sua volta altri requisiti. Ad esempio, le autorizzazioni del personale possono essere mantenute a un livello inferiore sufficiente per i dati conservati.

Uso di più IMM

Alcune organizzazioni governative australiane usano tassonomie di classificazione che consentono l'applicazione di più di un marcatore di gestione delle informazioni (IMM) a ogni elemento. Ad esempio: 'OFFICIAL: Sensitive Legislative Secrecy Personal Privacy'. Sebbene sia possibile ottenere questo tipo di configurazione, è necessario considerare i requisiti, in particolare:

• Gli IMM derivano dallo standard AGRkMS (Australian Government Recordkeeping Metadata Standard) in cui specifica che è possibile applicare un singolo valore IMM.
• Criteri PSPF (Protective Security Policy Framework) 8 indica che gli IMM sono facoltativi.

Microsoft consiglia di mantenere le cose il più semplici possibile. Solo la distribuzione di etichette di cui l'organizzazione ha effettivamente bisogno migliorerà l'esperienza utente in quanto gli utenti hanno meno etichette da esplorare. La presenza di una tassonomia più piccola semplifica anche l'amministrazione, in quanto c'è meno configurazione da gestire, in particolare nei criteri di prevenzione della perdita dei dati e di etichettatura automatica.

Le organizzazioni che considerano l'uso di più combinazioni IMM devono considerare le possibili complicazioni seguenti:

• Complicazioni di etichettatura automatica: gli elementi con più IMM applicati sono più difficili da trovare tramite l'etichettatura automatica come espressioni per interpretare i contrassegni soggetto o le intestazioni x devono essere in grado di adattarli tramite i criteri illustrati nelle raccomandazioni di etichettatura automatica basate sul servizio.
• Lunghezza dell'oggetto: Email client spesso troncano o rendono difficile visualizzare oggetti di posta elettronica lunghi. Nelle situazioni in cui sono stati applicati più contrassegni a un singolo messaggio di posta elettronica, gli utenti potrebbero non essere a conoscenza dei contrassegni IMM o Caveat in quanto non sono visibili.
• Lunghezza dell'intestazione X: le intestazioni x X-Protective-Marking, descritte in strategie di contrassegno , vengono usate per applicare i metadati di classificazione alla posta elettronica. La quantità di metadati da applicare a un messaggio di posta elettronica dipende da diversi fattori, tra cui il client di posta elettronica usato. È probabile che le organizzazioni che applicano più IMMs ai messaggi di posta elettronica superino la lunghezza consentita dell'intestazione x, con conseguente troncare alcuni metadati di classificazione.

Se sono necessarie più etichette, assicurarsi che gli elementi siano ordinati da meno a più importanti per l'organizzazione. Ad esempio:

1. Classificazione della sicurezza
2. Avvertenza (se necessario)
3. IMM più sensibile
4. IMM meno sensibile

Organizzazioni che lavorano in PROTECTED

Microsoft 365 è valutato per essere in grado di contenere i dati fino a e incluso PROTECTED.

Per la documentazione del programma IRAP (Registered Assessors Program) di Microsoft Infosec, vedere il portale Microsoft Service Trust.

Etichette per informazioni oltre il livello PROTECTED

Le organizzazioni che contengono dati SECRET e superiori devono usare un enclave locale. L'organizzazione deve implementare la separazione di rete e un'ampia gamma di altre misure per impedire a queste informazioni di uscire dall'enclave. Se un elemento contenente un contrassegno SECRET è stato visualizzato in una posizione di Microsoft 365, l'occorrenza richiede che le organizzazioni IT Security Advisor (ITSA) eseguano la gestione delle perdite di dati. L'ASD fornisce indicazioni su come gestire le attività di correzione, vedere Guida alla gestione delle perdite di dati asd

Le organizzazioni governative devono implementare etichette per informazioni che non devono risiedere nei servizi di Microsoft 365. Tuttavia, queste etichette non vengono applicate direttamente dagli utenti, ma vengono usate per facilitare l'identificazione automatizzata degli elementi che non devono trovarsi sulla piattaforma. Ciò consente ai team di sicurezza di eseguire attività di identificazione e correzione.

Le etichette variano per questo tipo di utilizzo varia a seconda delle organizzazioni, ma devono includere:

• PROTECTED (per le organizzazioni che lavorano con i dati più alti sono OFFICIAL nel tenant)
• SEGRETO
• TOP SECRET

Come da ISM-0272, queste etichette non devono essere pubblicate per gli utenti, come se il servizio non fosse autorizzato ad ospitare tali informazioni, gli utenti non dovrebbero essere in grado di applicare le etichette agli elementi:

Le organizzazioni che richiedono la prevenzione della perdita dei dati avanzata di dati altamente sensibili nella piattaforma Microsoft 365, ad esempio tramite posta elettronica o condivisione, possono aggiungere misure di sicurezza aggiuntive con "etichette non pubblicate", tra cui:

• Criteri di etichettatura automatica per identificare gli elementi tramite x-header di posta elettronica in ingresso o contrassegni dell'oggetto (simili a quelli illustrati nell'etichettatura della posta elettronica durante il trasporto).
• Criteri di etichettatura automatica per identificare gli elementi inattivi nelle posizioni di SharePoint, OneDrive e Teams (in modo simile all'etichettatura degli elementi esistenti inattivi).
• Criteri di prevenzione della perdita dei dati per bloccare la condivisione o la distribuzione tramite posta elettronica del contenuto identificato (in modo analogo alla prevenzione della distribuzione inappropriata delle informazioni classificate per la sicurezza).
• Criteri di prevenzione della perdita dei dati per bloccare la ricezione iniziale e/o qualsiasi altra distribuzione del contenuto (come illustrato nella sezione relativa al blocco della trasmissione delle classificazioni non consentite).
• Funzionalità di creazione di report per identificare quando gli elementi altamente sensibili vengono spostati in posizioni di riservatezza inferiori(come in Avvisi dati fuori luogo).
• Defender for Cloud Apps funzionalità per impedire il caricamento di elementi identificati in servizi cloud non Microsoft (come introdotto per impedire il caricamento di elementi classificati di sicurezza in posizioni non gestite).

Etichette per organizzazioni con tassonomie di etichette diverse

Alcuni governi dello stato australiano, come il Nuovo Galles del Sud e il Queensland, usano tassonomie di classificazione che non si allineano completamente alla politica PSPF 8. Ciò può creare alcune sfide per il modo in cui le organizzazioni del governo federale interpretano la sensibilità delle informazioni che ricevono dai governi statali. Sfide simili esistono per le organizzazioni del governo federale che corrispondono ai governi stranieri, in quanto le classificazioni non sono probabilmente allineate.

I framework e gli standard di sicurezza dei dati applicati dall'organizzazione esterna con cui comunica l'organizzazione sono estremamente rilevanti per la tassonomia delle etichette. I contrassegni esterni possono essere utilizzati con i metodi seguenti:

• I contrassegni applicati dalle organizzazioni esterne possono essere convertiti in un tenant equivalente

  Ad esempio, se un elemento con un contrassegno "QLD Government SENSITIVE" applicato ad esso, viene ricevuto da un'organizzazione del governo federale, il contrassegno fornisce informazioni utili sulla riservatezza dell'elemento. Un utente può applicare un'etichetta "OFFICIAL Sensitive" all'elemento per portarlo nell'ambito delle protezioni basate su etichette del tenant. In alternativa, l'etichettatura automatica potrebbe essere configurata per eseguire automaticamente il mapping di questo contrassegno QLD all'etichetta OFFICIAL Sensitive.

• Le organizzazioni possono mantenere classificazioni esterne e protezioni appropriate per le informazioni mentre ne sono responsabili

  Anziché riclassificare gli elementi che non sono allineati con l'etichettatura di riservatezza dell'ambiente, Microsoft Purview potrebbe essere configurato con un set di "etichette non pubblicate" allineate alle classificazioni esterne. Queste etichette non devono essere selezionabili dagli utenti all'interno di client che riconoscono le etichette. Possono invece applicare l'etichettatura automatica basata sul servizio. Dopo aver etichettato gli elementi ricevuti, agli utenti non viene richiesto di applicare un'etichetta. Le etichette possono anche essere allineate con un set di DLP e altri controlli per garantire che le informazioni contenute non vengano divulgate in modo inappropriato.

La configurazione delle etichette deve essere eseguita con le organizzazioni, che interagiscono con l'obiettivo dell'allineamento nella terminologia di classificazione, in quanto ciò consente una configurazione più semplice. Se non è possibile ottenere questo risultato, l'accordo sulle equivalenze di classificazione offre il risultato migliore successivo. La situazione da evitare è che i contrassegni esterni vengano completamente ignorati, in quanto ciò potrebbe causare eventi imprevisti di sicurezza dei dati, ad esempio una perdita di dati.

1. Allineamento della classificazione (consigliato, procedura consigliata)
2. Equivalenza di classificazione (consigliata se l'opzione uno non è possibile)
3. Mancato rispetto della classificazione (sconsigliato, aumenta il rischio di perdita di dati)

La tabella seguente è un esempio di come le etichette non pubblicate vengono implementate con l'etichettatura automatica per mantenere i contrassegni applicati dalle organizzazioni esterne. L'esempio mostra un set di etichette PSPF, la cui maggior parte viene visualizzata come etichette secondarie per l'etichetta padre OFFICIAL Sensitive. Sotto questa etichetta padre, l'utente può scegliere di includere etichette allineate con i marcatori DIM (Information Management Marker) equivalenti di WALES e QLD:Underneath this parent label, the user can choose to include labels that align with WALES and QLD equivalent Information Management Markers (IMM):

I vantaggi dell'approccio precedente sono:

• Le informazioni etichettate con etichette DI PROTEZIONE HARDWARE o QLD traggono vantaggio da OFFICIAL: avviso out-of-place dei dati sensibili (ulteriormente illustrato nell'avviso out-of-place dei dati), che avvisa e facilita la prevenzione dello spostamento dei dati in posizioni in cui potrebbero essere divulgati in modo inappropriato.
• LE etichette secondarie DI TIPO CLUSTER o QLD sono incluse in OFFICIAL: Criteri di prevenzione della perdita dei dati sensibili e Defender for Cloud Apps, proteggendo dalla divulgazione inappropriata tramite l'organizzazione (come introdotto nella prevenzione della distribuzione inappropriata delle informazioni classificate per la sicurezza).
• I servizi di identificazione dati, ad esempio Esplora contenuto, possono essere usati per identificare la posizione in cui le informazioni sensibili di proprietà dello stato o generate possono risiedere nei servizi di Microsoft 365¹.

Crittografia di Azure Rights Management

Azure Rights Management viene usato per garantire che solo gli utenti autorizzati possano accedere al contenuto con un'etichetta applicata.

Per informazioni sulla configurazione della crittografia di Azure Rights Management, vedere come configurare la crittografia dei messaggi

Di seguito è riportato un esempio applicabile al governo australiano.

• È possibile usare un'etichetta secondaria contrassegnata come Solo interno per consentire agli utenti di limitare gli elementi solo agli utenti interni.
• È possibile usare un'etichetta secondaria Solo destinatari per garantire che i messaggi di posta elettronica non possano essere inoltrati a destinatari non autorizzati.
• È possibile usare un'etichetta secondaria di Project Budgerigar Only per garantire che solo il subset di utenti che hanno bisogno di sapere per Project Budgerigar e le informazioni correlate possa accedere agli elementi.

Usando queste etichette e i controlli associati insieme al set di base DI OFFICIAL: Etichette sensibili, il risultato della topologia è:

• OFFICIAL: Sensitive
  • OFFICIAL: Solo interno sensibile
  • OFFICIAL: Solo destinatari sensibili
  • OFFICIAL: Solo progetto sensibile Budgerigar
  • OFFICIAL: Sensibile (nessuna protezione)
  • OFFICIAL: Privacy personale sensibile
  • OFFICIAL: Privilegio legale riservato
  • OFFICIAL: Segreto legislativo sensibile
  • UFFICIALE: GABINETTO NAZIONALE SENSIBILE

Esistono alcune sfide ovvie con l'esempio precedente, tra cui:

• L'elenco delle etichette è molto più lungo, il che potrebbe influire sull'usabilità.
• Le etichette aggiuntive comportano un maggior numero di requisiti di configurazione nei servizi associati, ad esempio la prevenzione della perdita dei dati, aumentando la complessità.
• Il set precedente di opzioni di etichetta richiede agli utenti di prendere decisioni relative all'applicazione di una configurazione IMM, CAVEAT o di crittografia, che presenta un problema.

In tali situazioni, le protezioni fornite dalla crittografia devono essere la priorità principale. Gli IMM sono considerati facoltativi in base a PSPF, quindi devono essere considerati come priorità inferiore. Le avvertenze, ad esempio NATIONAL CABINET, sono probabilmente più importanti degli IMM e non devono essere omesse. È probabile che ciò porti a requisiti di etichetta aggiuntivi quando le organizzazioni cercano di applicare protezioni più recenti agli elementi.

L'esempio dimostra che è probabile che i requisiti delle etichette crescano nel tempo. A partire da un set di etichette di grandi dimensioni, in futuro la complessità sarà ancora maggiore. Microsoft consiglia di limitare le etichette pubblicate a un set di base richiesto dagli utenti e di omettere le combinazioni IMM e Caveat che probabilmente non saranno richieste dall'organizzazione. Limitando gli utenti a un set di core, la configurazione può aumentare senza influire sull'usabilità o sulla complessità.