Condividi tramite

Gestione di Microsoft: operazioni del ciclo di vita della chiave del tenant

  • Articolo

Nota

Si sta cercando Microsoft Purview Information Protection, in precedenza Microsoft Information Protection (MIP)?

Il componente aggiuntivo Azure Information Protection viene ritirato e sostituito con le etichette integrate nelle app e nei servizi di Microsoft 365. Altre informazioni sullo stato di supporto di altri componenti di Azure Information Protection.

Il client Microsoft Purview Information Protection (senza il componente aggiuntivo) è disponibile a livello generale.

Se Microsoft gestisce la chiave del tenant per Azure Information Protection (impostazione predefinita), usare le sezioni seguenti per altre informazioni sulle operazioni del ciclo di vita rilevanti per questa topologia.

Revocare la chiave del tenant

Quando si annulla la sottoscrizione per Azure Information Protection, Azure Information Protection smette di usare la chiave del tenant e non è necessaria alcuna azione da parte dell'utente.

Reimpostare la chiave del tenant

La reimpostazione della chiave è nota anche come rollover della chiave. Quando si esegue questa operazione, Azure Information Protection smette di usare la chiave del tenant esistente per proteggere documenti e messaggi di posta elettronica e inizia a usare una chiave diversa. I criteri e i modelli vengono immediatamente riassegnati, ma questa modifica è graduale per i client e i servizi esistenti che usano Azure Information Protection. Quindi, per qualche tempo, alcuni nuovi contenuti continuano a essere protetti con la chiave del tenant precedente.

Per reimpostare la chiave, è necessario configurare l'oggetto chiave del tenant e specificare la chiave alternativa da usare. La chiave usata in precedenza viene quindi contrassegnata automaticamente come archiviata per Azure Information Protection. Questa configurazione garantisce che il contenuto protetto tramite questa chiave rimanga accessibile.

Esempi di quando potrebbe essere necessario reimpostare la chiave per Azure Information Protection:

  • È stata eseguita la migrazione da Active Directory Rights Management Services (AD RMS) con una chiave di crittografia in modalità 1. Al termine della migrazione, si vuole passare all'uso di una chiave che usa la modalità di crittografia 2.

  • La società si è suddivisa in due o più aziende. Quando si reimposta la chiave del tenant, la nuova azienda non avrà accesso a nuovi contenuti pubblicati dai dipendenti. Possono accedere al contenuto precedente se hanno una copia della chiave del tenant precedente.

  • Si vuole passare da una topologia di gestione delle chiavi a un'altra.

  • Si ritiene che la copia master della chiave del tenant sia compromessa.

Per reimpostare la chiave, è possibile selezionare una chiave gestita da Microsoft diversa per diventare la chiave del tenant, ma non è possibile creare una nuova chiave gestita da Microsoft. Per creare una nuova chiave, è necessario modificare la topologia della chiave in modo che sia gestita dal cliente (BYOK).

Si dispone di più chiavi gestite da Microsoft se è stata eseguita la migrazione da Active Directory Rights Management Services (AD RMS) e si è scelta la topologia della chiave gestita da Microsoft per Azure Information Protection. In questo scenario sono disponibili almeno due chiavi gestite da Microsoft per il tenant. Una chiave, o più, è la chiave o le chiavi importate da AD RMS. Si avrà anche la chiave predefinita creata automaticamente per il tenant di Azure Information Protection.

Per selezionare una chiave diversa come chiave del tenant attiva per Azure Information Protection, usare il cmdlet Set-AipServiceKeyProperties del modulo AIPService. Per identificare la chiave da usare, usare il cmdlet Get-AipServiceKeys . È possibile identificare la chiave predefinita creata automaticamente per il tenant di Azure Information Protection eseguendo il comando seguente:

(Get-AipServiceKeys) | Sort-Object CreationTime | Select-Object -First 1

Per modificare la topologia della chiave in modo che sia gestita dal cliente (BYOK), vedere Pianificazione e implementazione della chiave del tenant di Azure Information Protection.

Eseguire il backup e il ripristino della chiave del tenant

Microsoft è responsabile del backup della chiave del tenant e non è necessaria alcuna azione da parte dell'utente.

Esportare la chiave del tenant

È possibile esportare la configurazione di Azure Information Protection e la chiave del tenant seguendo le istruzioni descritte nei tre passaggi seguenti:

Passaggio 1: Avviare l'esportazione

  • Contattare supporto tecnico Microsoft per aprire un caso di supporto di Azure Information Protection con una richiesta di esportazione di una chiave di Azure Information Protection. È necessario dimostrare di essere un amministratore globale per il tenant e comprendere che questo processo richiede diversi giorni per confermare. Si applicano gli addebiti per il supporto standard; l'esportazione della chiave del tenant non è un servizio di supporto gratuito.

Passaggio 2: Attendere la verifica

  • Microsoft verifica che la richiesta di rilasciare la chiave del tenant di Azure Information Protection sia legittima. Questo processo può richiedere fino a tre settimane.

Passaggio 3: Ricevere le istruzioni chiave da CSS

  • Microsoft Customer Support Services (CSS) invia la configurazione di Azure Information Protection e la chiave del tenant crittografata in un file protetto da password. Questo file ha un'estensione di file con estensione tpd . A tale scopo, CSS invia prima di tutto (come persona che ha avviato l'esportazione) uno strumento tramite posta elettronica. È necessario eseguire lo strumento da un prompt dei comandi come indicato di seguito:

    AadrmTpd.exe -createkey

    In questo modo viene generata una coppia di chiavi RSA e le metà pubbliche e private vengono salvate come file nella cartella corrente. Ad esempio: PublicKey-FA29D0FE-5049-4C8E-931B-96C6152B0441.txt e PrivateKey-FA29D0FE-5049-4C8E-931B-96C6152B0441.txt.

    Rispondere al messaggio di posta elettronica da CSS, allegando il file con un nome che inizia con PublicKey. CSS invia quindi un file TPD come file .xml crittografato con la chiave RSA. Copiare questo file nella stessa cartella in cui è stato eseguito lo strumento AadrmTpd originariamente ed eseguire di nuovo lo strumento, usando il file che inizia con PrivateKey e il file da CSS. Ad esempio:

    AadrmTpd.exe -key PrivateKey-FA29D0FE-5049-4C8E-931B-96C6152B0441.txt -target TPD-77172C7B-8E21-48B7-9854-7A4CEAC474D0.xml

    L'output di questo comando deve essere costituito da due file: uno contiene la password di testo normale per il TPD protetto da password e l'altro è il TPD protetto da password stesso. I file hanno un nuovo GUID, ad esempio:

    • Password-5E4C2018-8C8C-4548-8705-E3218AA1544E.txt

    • ExportedTPD-5E4C2018-8C8C-4548-8705-E3218AA1544E.xml

      Eseguire il backup di questi file e archiviarli in modo sicuro per garantire che sia possibile continuare a decrittografare il contenuto protetto con questa chiave del tenant. Inoltre, se si esegue la migrazione ad AD RMS, è possibile importare questo file TPD (il file che inizia con ExportedTDP) nel server AD RMS.

Passaggio 4: In corso: Proteggere la chiave del tenant

Dopo aver ricevuto la chiave del tenant, mantenerla ben protetta, perché se qualcuno ottiene l'accesso, può decrittografare tutti i documenti protetti usando tale chiave.

Se il motivo dell'esportazione della chiave del tenant è dovuto al fatto che non si vuole più usare Azure Information Protection, come procedura consigliata, disattivare ora il servizio Azure Rights Management dal tenant di Azure Information Protection. Non ritardare questa operazione dopo aver ricevuto la chiave del tenant perché questa precauzione consente di ridurre al minimo le conseguenze se la chiave del tenant è accessibile da qualcuno che non dovrebbe averlo. Per istruzioni, vedere Rimozione delle autorizzazioni e disattivazione di Azure Rights Management.

Rispondere a una violazione

Nessun sistema di sicurezza, indipendentemente dalla forza, è completo senza un processo di risposta alle violazioni. La chiave del tenant potrebbe essere compromessa o rubata. Anche quando è protetta correttamente, le vulnerabilità potrebbero essere trovate nella tecnologia chiave di generazione corrente o nelle lunghezze e negli algoritmi chiave correnti.

Microsoft ha un team dedicato per rispondere agli eventi imprevisti di sicurezza nei propri prodotti e servizi. Non appena è presente un report credibile di un evento imprevisto, questo team si impegna per analizzare l'ambito, la causa radice e le mitigazioni. Se questo evento imprevisto influisce sugli asset, Microsoft informerà gli amministratori globali per il tenant tramite posta elettronica.

In caso di violazione, l'azione migliore che l'utente o Microsoft può intraprendere dipende dall'ambito della violazione; Microsoft collaborerà con l'utente tramite questo processo. La tabella seguente illustra alcune situazioni tipiche e la risposta probabile, anche se la risposta esatta dipende da tutte le informazioni rivelate durante l'indagine.

Descrizione dell'evento imprevisto Risposta probabile
La chiave del tenant viene persa. Reimpostare la chiave del tenant. Vedere la sezione Reimpostare la chiave del tenant in questo articolo.
Un utente malintenzionato o un malware ha ottenuto diritti per l'uso della chiave del tenant, ma la chiave stessa non è stata persa. La reimpostazione della chiave del tenant non è utile in questo caso e richiede l'analisi della causa radice. Se un processo o un bug software è responsabile dell'accesso dell'utente non autorizzato, tale situazione deve essere risolta.
La vulnerabilità individuata nell'algoritmo RSA o nella lunghezza della chiave o negli attacchi di forza bruta diventa fattibile a livello di calcolo. Microsoft deve aggiornare Azure Information Protection per supportare nuovi algoritmi e lunghezze di chiave più lunghe resilienti e indicare a tutti i clienti di reimpostare la chiave del tenant.