Domande frequenti e problemi relativi a Microsoft Information Protection (MIP) SDK

Questo articolo fornisce risposte alle domande frequenti e alle indicazioni per la risoluzione dei problemi noti e degli errori comuni.

Domande frequenti

Modifiche Archiviazione metadati

È stato annunciato che stiamo apportando una modifica al percorso di archiviazione dei metadati delle etichette per i file di Office (Word, Excel, PowerPoint) per supportare nuove funzionalità in Office 365, SharePoint Online e altri servizi.

Domande frequenti sui metadati

Domanda: altri formati sono interessati, ad esempio pdf?

• No, solo i file di Office, in particolare Word, Excel e PowerPoint.

Domanda: È necessaria una versione specifica di MIP SDK?

• MIP SDK 1.7 e versioni successive sono completamente compatibili.

Domanda: Esiste una versione specifica del client di Office necessaria per usare questo percorso di archiviazione?

• Tutti i client di Microsoft 365 Apps rilasciati dopo settembre 2021 supportano questa nuova posizione dei metadati. La nuova posizione di archiviazione non viene usata finché la funzionalità di creazione condivisa protetta non è abilitata dagli amministratori tenant.

Domanda: I metadati esistenti vengono archiviati come proprietà personalizzata in custom.xml essere aggiornati?

• No. La prima volta che il documento viene salvato dopo l'abilitazione del nuovo percorso di archiviazione, i metadati delle etichette vengono spostati nella nuova posizione. I metadati scritti tramite LabelingOptions.ExtendedProperties rimangono in custom.xml.

Domanda: È possibile leggere i metadati dell'etichetta senza MIP SDK?

• Sì, ma è necessario implementare il proprio codice per analizzare il file ed estrarre le informazioni.

Domanda: attualmente è facile "leggere" l'etichetta estraendo le stringhe di coppia chiave/valore dal file. I metadati possono ancora essere letti in questo modo?

• Sì, i metadati sono ancora disponibili nel file XML di Office da leggere. L'applicazione deve leggere l'impostazione di creazione condivisa dal file dei criteri per sapere che il nuovo set di funzionalità è abilitato. Definisce dove leggere/scrivere i dati dell'etichetta (custom.xml e labelinfo.xml). Esaminare MS-OFFCRYPTO: LabelInfo e proprietà personalizzate del documento | Microsoft Docs. per informazioni dettagliate sull'implementazione.

Domanda: Come viene eseguita la migrazione delle etichette alla nuova posizione?

• La logica seguente viene usata per determinare quale sezione viene letta e usata per leggere o scrivere dati etichetta.

Azione	Funzionalità non abilitata	Funzionalità abilitata
Lettura	Etichetta in custom.xml (non protetta) o Doc SummaryInfo (protetta).	Se l'etichetta esiste in labelinfo.xml, è l'etichetta effettiva. Se non è presente alcuna etichetta in labelinfo.xml, l'etichetta in custom.xml o Doc SummaryInfo è l'etichetta effettiva.
Scrittura	Tutte le nuove etichette vengono scritte in custom.xml (non protetto) o Doc SummaryInfo (protected).	Tutte le nuove etichette vengono scritte in labelinfo.xml.

Analisi dei file

Domanda: È possibile scrivere nello stesso file attualmente letto con File SDK?

MIP SDK non supporta la lettura e la scrittura simultanea dello stesso file. Tutti i file etichettati generano una copia del file di input con le azioni di etichetta applicate. L'applicazione deve sostituire l'originale con il file etichettato.

Gestione delle stringhe SDK

Domanda: In che modo l'SDK gestisce le stringhe e quale tipo di stringa deve essere usato nel codice?

L'SDK è progettato per essere usato multipiattaforma e usa UTF-8 (Formato trasformazione Unicode - 8 bit) per la gestione delle stringhe. Le indicazioni specifiche dipendono dalla piattaforma in uso:

Piattaforma	Indicazioni
Windows nativo	Per i client C++ SDK, il tipo di std::string libreria standard C++ viene usato per passare stringhe a/da funzioni API. La conversione da/verso UTF-8 viene gestita internamente dall'SDK MIP. Quando un oggetto std::string viene restituito da un'API, è necessario prevedere la codifica UTF-8 e gestirla di conseguenza se si converte la stringa. In alcuni casi, una stringa viene restituita come parte di un uint8_t vettore ,ad esempio una licenza di pubblicazione (PL), ma deve essere considerata un BLOB opaco. Per altre informazioni ed esempi, vedere: Funzione WideCharToMultiByte per assistenza nella conversione di stringhe di caratteri wide in più byte, ad esempio UTF-8. I file di esempio seguenti inclusi nel download dell'SDK: Funzioni di utilità stringa di esempio in file\samples\common\string_utils.cppper la conversione da/verso stringhe UTF-8 wide. Implementazione di wmain(int argc, wchar_t *argv[]) in file\samples\file\main.cpp, che usa le funzioni di conversione di stringhe precedenti.
.NET	Per i client .NET SDK, tutte le stringhe usano la codifica UTF-16 predefinita e non è necessaria alcuna conversione speciale. La conversione da/verso UTF-16 viene gestita internamente da MIP SDK.
Altre piattaforme	Tutte le altre piattaforme supportate da MIP SDK hanno supporto nativo per UTF-8.

Contrassegno del contenuto

Domanda: MIP SDK supporta il contrassegno del contenuto?

MIP SDK non supporta l'applicazione diretta del contrassegno del contenuto, tra cui intestazione, piè di pagina o filigrana, su qualsiasi file. Quando i metadati delle etichette vengono scritti in un file, File SDK scrive la proprietà dei metadati contentBits per indicare che la protezione è stata applicata (se configurata). Non scriverà le proprietà che indicano l'applicazione di intestazione, piè di pagina o filigrana. Quando il file viene aperto in un'applicazione che supporta il contrassegno del contenuto, la configurazione del contrassegno del contenuto deve essere valutata dall'applicazione e scritta nel file al salvataggio.

SDK di protezione e criteri in Android

Domanda: Quale libreria condivisa è consigliabile usare per l'integrazione di MIP SDK nell'applicazione Android?

I file binari android di MIP SDK includono libmip_core.so, libmip_protection_sdk.solibmip_upe_sdk.so e lipmip_unified.so. libmip_unified.so è la libreria consigliata che include le librerie condivise di base, protezione e criteri.

Conformità

Domanda: Microsoft Information Protection SDK FIPS 140-2 è conforme?

Microsoft Information Protection SDK usa attualmente crittografie approvate FIPS 140-2, ma non le librerie crittografiche convalidate FIPS 140-2. Le applicazioni che usano MIP SDK devono tenere presente che l'SDK non è considerato conforme a FIPS in questo momento. Per altre informazioni, vedere l'articolo sulla conformità FIPS 140-2.

Informazioni di riferimento su problemi ed errori

Errore: "Formato di file non supportato"

Domanda: Perché viene visualizzato l'errore seguente quando si tenta di proteggere o etichettare un file PDF?

Formato di file non supportato

Questa eccezione determina il tentativo di proteggere o etichettare un file PDF firmato digitalmente o protetto da password. Per altre informazioni sulla protezione e l'etichettatura dei file PDF, vedere Nuovo supporto per la crittografia PDF con Microsoft Information Protection .

Errore: "Impossibile analizzare i criteri di conformità acquisiti"

Domanda: Perché viene visualizzato l'errore seguente dopo il download dell'SDK MIP e il tentativo di usare l'esempio di file per elencare tutte le etichette?

Si è verificato un problema: non è stato possibile analizzare i criteri di conformità acquisiti. Failed with: [class mip::CompliancePolicyParserException] Tag not found: policy, NodeType: 15, Name: No Name Found, Value: , Ancestors: <SyncFile><Content>, correlationId:[34668a40-blll-4ef8-b2af-00005aa674z9]

Questo errore indica che non è stata eseguita la migrazione delle etichette da Azure Information Protection all'esperienza di etichettatura unificata. Seguire Come eseguire la migrazione delle etichette di Azure Information Protection alle etichette di riservatezza unificate per eseguire la migrazione delle etichette, quindi creare criteri di etichetta nel portale di sicurezza e conformità di Office 365.

Errore: "NoPolicyException: I criteri di etichetta non contengono dati"

Domanda: Perché viene visualizzato l'errore seguente quando si tenta di leggere un'etichetta o un elenco di etichette tramite MIP SDK?

NoPolicyException: i criteri di etichetta non contengono dati, CorrelationId=GUID, CorrelationId.Description=PolicyProfile, NoPolicyError.Category=SyncFile, NoPolicyError.Category=SyncFile

Questo errore indica che i criteri di etichetta non sono stati pubblicati nella Portale di conformità di Microsoft Purview. Seguire Creare e configurare le etichette di riservatezza e i relativi criteri per configurare i criteri di etichettatura.

Errore: "System.ComponentModel.Win32Exception: LoadLibrary failed"

Domanda: Perché viene visualizzato l'errore seguente quando si usa il wrapper .NET di MIP SDK?

System.ComponentModel.Win32Exception: LoadLibrary non è riuscito per: [sdk_wrapper_dotnet.dll] durante la chiamata a MIP. Initialize().

L'applicazione non ha il runtime necessario o non è stata compilata come Release. Per altre informazioni, vedi Verificare che l'app disponga del runtime necessario.

Errore: "Eccezione ProxyAuthError"

Domanda: Perché viene visualizzato l'errore seguente quando si usa MIP SDK?

"ProxyAuthenticatonError: l'autenticazione proxy non è supportata"

MIP SDK non supporta l'uso di proxy autenticati. Per correggere questo messaggio, gli amministratori proxy devono impostare gli endpoint del servizio Microsoft Purview Information Protection per ignorare il proxy. Un elenco di questi endpoint è disponibile nella pagina URL e intervalli di indirizzi IP di Office 365. MIP SDK richiede che *.protection.outlook.com (riga 9) e gli endpoint del servizio Azure Information Protection (riga 73) ignorino l'autenticazione proxy.

Errore: "Errore sconosciuto" quando si etichetta un file di immagine usando un output del flusso

Domanda: Perché viene visualizzato un "errore sconosciuto" quando si tenta di aggiungere o rimuovere un'etichetta o una protezione da un tipo di file di immagine usando un flusso per l'output?

Quando si usa un flusso per l'output, il flusso deve avere accesso in lettura e scrittura per modificare l'etichetta o la protezione per un file di immagine.

Domanda: Esistono limiti di limitazione basati sul servizio quando si usa MIP SDK?

Il servizio di protezione, usato dall'SDK di protezione o dalle operazioni di protezione in File SDK, ha un limite di 7.500 richieste per dieci secondi per un'intera organizzazione. Ovvero, se l'applicazione A genera 4.000 richieste per dieci secondi e Applicaiton B nella stessa organiziazione genera 4.000 richieste per dieci secondi, entrambe le applicazioni possono iniziare a ricevere HTTP 429 Too Many Requests risposte. Gli sviluppatori devono implementare un periodo di backoff quando vengono ricevute queste eccezioni.