FAQ et problèmes liés au kit de développement logiciel (SDK) Microsoft Information Protection (MIP)

Cet article fournit des réponses aux questions fréquentes (FAQ) et des conseils de résolution des problèmes connus et des erreurs courantes.

Forums Aux Questions (FAQ)

Modifications du stockage des métadonnées

Nous avons annoncé que nous apportons une modification à l’emplacement de stockage des métadonnées d’étiquette pour les fichiers Office (Word, Excel, PowerPoint) pour prendre en charge de nouvelles fonctionnalités dans Office 365, SharePoint Online et d’autres services.

FAQ sur les métadonnées

Question : D’autres formats sont-ils affectés, tels que PDF ?

  • Non, seuls les fichiers Office, en particulier les fichiers Word, Excel et PowerPoint.

Question : Existe-t-il une version spécifique du SDK MIP requise ?

  • Le SDK MIP 1.7 et les versions ultérieures sont entièrement compatibles.

Question : Existe-t-il une version spécifique du client Bureau requis pour utiliser cet emplacement de stockage ?

  • Tous les clients Applications Microsoft 365 publiés après septembre 2021 prennent en charge ce nouvel emplacement de métadonnées. Le nouvel emplacement de stockage n’est pas utilisé tant que la fonctionnalité de co-création protégée n’est pas activée par les administrateurs clients.

Question : Les métadonnées existantes sont-elles stockées en tant que propriété personnalisée dans custom.xml être conservées à jour ?

  • Non. La première fois que le document est enregistré une fois que le nouvel emplacement de stockage est activé, les métadonnées d’étiquette sont déplacées vers le nouvel emplacement. Les métadonnées écrites via LabelingOptions.ExtendedProperties restent dans custom.xml.

Question : Est-il possible de lire les métadonnées d’étiquette sans sdk MIP ?

  • Oui, mais vous devez implémenter votre propre code pour analyser le fichier et extraire les informations.

Question : Actuellement, il est facile de « lire » l’étiquette en extrayant les chaînes de paire clé-valeur du fichier. Les métadonnées peuvent-elles toujours être lues de cette façon ?

  • Oui, les métadonnées sont toujours disponibles dans le fichier XML du fichier Office à lire. Votre application doit lire le paramètre de co-création à partir du fichier de stratégie pour savoir que le nouvel ensemble de fonctionnalités est activé. Cela définit l’emplacement où lire/écrire les données d’étiquette (custom.xml et labelinfo.xml). Consultez MS-OFFCRYPTO : LabelInfo et Propriétés personnalisées du document | Microsoft Docs. pour plus d’informations sur l’implémentation.

Question : Comment les étiquettes sont-elles migrées vers le nouvel emplacement ?

  • La logique suivante permet de déterminer quelle section est lue et utilisée pour lire ou écrire des données d’étiquette.
Action Fonctionnalité non activée Fonctionnalité activée
Lire Étiquette dans custom.xml (non protégé) ou Doc SummaryInfo (protégé). Si l’étiquette existe dans labelinfo.xml, il s’agit de l’étiquette effective.
S’il n’existe aucune étiquette dans labelinfo.xml, l’étiquette dans custom.xml ou Doc SummaryInfo est l’étiquette effective.
Écrire Toutes les nouvelles étiquettes sont écrites dans custom.xml (non protégé) ou Doc SummaryInfo (protégé). Toutes les nouvelles étiquettes sont écrites dans labelinfo.xml.

Analyse des fichiers

Question : Puis-je écrire dans le même fichier que celui que je lis actuellement avec le kit de développement logiciel (SDK) File ?

Le SDK MIP ne prend pas en charge simultanément la lecture et l’écriture dans le même fichier. Tous les fichiers étiquetés entraînent une copie du fichier d’entrée avec les actions d’étiquette appliquées. Votre application doit remplacer l’original par le fichier étiqueté.

Gestion des chaînes du SDK

Question : Comment le SDK gère-t-il les chaînes, et quel type de chaîne faut-il utiliser dans mon code ?

Le SDK est destiné à être utilisé sur plusieurs plateformes et utilise UTF-8 (Unicode Transformation Format - 8 bits) pour la gestion des chaînes. Des conseils spécifiques dépendent de la plateforme que vous utilisez :

Plateforme Guidance
Natif Windows Pour les clients SDK C++, le type de bibliothèque standard C++ std::string est utilisé pour passer des chaînes vers/depuis des fonctions d’API. La conversion vers/depuis UTF-8 est gérée en interne par le SDK MIP. Lorsqu’une API std::string est retournée, vous devez vous attendre à un encodage UTF-8 et gérer en conséquence l’éventuelle conversion de la chaîne. Dans certains cas, une chaîne est retournée dans le cadre d’un vecteur uint8_t (par exemple, une licence de publication (PL)), mais doit être traitée comme un objet blob opaque.

Pour plus d’informations et d’exemples, consultez :
  • Fonction WideCharToMultiByte pour obtenir de l’aide sur la conversion de chaînes de caractères larges en plusieurs octets, comme UTF-8.
  • Les exemples de fichiers suivants inclus dans le téléchargement du kit de développement logiciel (SDK) :
    • Exemples de fonctions utilitaires de chaîne dans file\samples\common\string_utils.cpp, pour la conversion vers/depuis des chaînes Wide UTF-8.
    • Implémentation de wmain(int argc, wchar_t *argv[]) dans file\samples\file\main.cpp, qui utilise les fonctions de conversion de chaîne précédentes.
.NET Pour les clients SDK .NET, toutes les chaînes utilisent l’encodage UTF-16 par défaut et aucune conversion spéciale n’est nécessaire. La conversion vers/depuis UTF-16 est gérée en interne par le SDK MIP.
Autres plateformes Toutes les autres plateformes prises en charge par le SDK MIP prennent en charge nativement UTF-8.

Marquage du contenu

Question : Le SDK MIP prend-il en charge le marquage de contenu ?

Le SDK MIP ne prend pas en charge l’application directe du marquage de contenu, y compris l’en-tête, le pied de page ou le filigrane, sur tous les fichiers. Lorsque les métadonnées d’étiquette sont écrites dans un fichier, le Kit de développement logiciel (SDK) File écrit la propriété de métadonnées contentBits pour indiquer que la protection a été appliquée (si configurée). Elle n’écrit pas les propriétés qui indiquent l’en-tête, le pied de page ou le filigrane ont été appliquées. Lorsque le fichier est ouvert dans une application qui prend en charge le marquage de contenu, la configuration du marquage de contenu doit être évaluée par l’application et écrite dans le fichier lors de l’enregistrement.

Kits de développement logiciel (SDK) de protection et de stratégie sur Android

Question : Quelle bibliothèque partagée dois-je utiliser pour intégrer le SDK MIP dans mon application Android ?

Les fichiers binaires Android du SDK MIP incluent libmip_core.so, libmip_protection_sdk.solibmip_upe_sdk.so et lipmip_unified.so. libmip_unified.so est la bibliothèque recommandée qui inclut les bibliothèques partagées de base, de protection et de stratégie.

Conformité

Question : kit de développement logiciel (SDK) Microsoft Information Protection FIPS 140-2 est-il conforme ?

Le kit de développement logiciel (SDK) Microsoft Information Protection utilise les chiffrements approuvés FIPS 140-2, mais pas les bibliothèques de chiffrement validées FIPS 140-2 aujourd’hui. Les applications qui consomment le SDK MIP doivent être conscientes que le SDK n’est pas considéré comme conforme à FIPS pour l’instant. Pour plus d’informations, consultez l’article sur la conformité FIPS 140-2.

Informations de référence sur les problèmes et les erreurs

Erreur : « Format de fichier non pris en charge »

Question : Pourquoi est-ce que j’obtiens l’erreur suivante lors de la tentative de protection ou d’étiquetage d’un fichier PDF ?

Format de fichier non pris en charge

Cette exception résulte de la tentative de protection ou d’étiquetage d’un fichier PDF qui a été signé numériquement ou protégé par mot de passe. Consultez la nouvelle prise en charge du chiffrement PDF avec Microsoft Information Protection pour plus d’informations sur la protection et l’étiquetage des fichiers PDF.

Erreur : « Échec de l’analyse de la stratégie de conformité acquise »

Question : Pourquoi est-ce que j’obtiens l’erreur suivante après avoir téléchargé le kit de développement logiciel (SDK) MIP et tenté d’utiliser l’exemple de fichier pour répertorier toutes les étiquettes ?

Un problème s’est produit : échec de l’analyse de la stratégie de conformité acquise. 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]

Cette erreur indique que vous n’avez pas migré vos étiquettes d’Azure Information Protection vers l’expérience d’étiquetage unifiée. Suivez comment migrer des étiquettes Azure Information Protection vers des étiquettes de confidentialité unifiées pour migrer les étiquettes, puis créer une stratégie des étiquettes dans le portail de sécurité et de conformité Office 365.

Erreur : « NoPolicyException : La stratégie d’étiquette ne contenait pas de données »

Question : Pourquoi est-ce que j’obtiens l’erreur suivante lors de la tentative de lecture d’une étiquette ou d’une liste d’étiquettes via le SDK MIP ?

NoPolicyException : La stratégie d’étiquette ne contenait pas de données, CorrelationId=GUID, CorrelationId.Description=PolicyProfile, NoPolicyError.Category=SyncFile, NoPolicyError.Category=SyncFile

Cette erreur indique qu’une stratégie d’étiquette n’a pas été publiée dans le portail de conformité Microsoft Purview. Suivez Créer et configurer des étiquettes de confidentialité et leurs stratégies pour configurer la stratégie d’étiquetage.

Erreur : « System.ComponentModel.Win32Exception : Échec de LoadLibrary »

Question : Pourquoi est-ce que j’obtiens l’erreur suivante lors de l’utilisation du wrapper .NET du SDK MIP ?

System.ComponentModel.Win32Exception : Échec de LoadLibrary pour : [sdk_wrapper_dotnet.dll] lors de l’appel de MIP.Initialize().

Votre application n’a pas le runtime requis ou n’a pas été générée en tant que version. Pour plus d’informations, consultez Vérifier que votre application dispose du runtime requis.

Erreur : « Exception ProxyAuthError »

Question : Pourquoi est-ce que j’obtiens l’erreur suivante lors de l’utilisation du kit de développement logiciel (SDK) MIP ?

« ProxyAuthenticatonError : l’authentification proxy n’est pas prise en charge »

Le kit de développement logiciel (SDK) MIP ne prend pas en charge l’utilisation de proxys authentifiés. Pour résoudre ce message, les administrateurs de proxy doivent définir les points de terminaison de service Protection des données Microsoft Purview pour contourner le proxy. Une liste de ces points de terminaison est disponible sur la page URL et plages d’adresses IP Office 365. Le kit de développement logiciel (SDK) MIP nécessite que *.protection.outlook.com (ligne 9) et les points de terminaison de service Azure Information Protection (ligne 73) contournent l’authentification proxy.

Erreur : « Erreur inconnue » lors de l’étiquetage d’un fichier image à l’aide d’une sortie de flux

Question : Pourquoi est-ce que j’obtiens une « erreur inconnue » quand j’essaie d’ajouter ou de supprimer une étiquette ou une protection d’un type de fichier image à l’aide d’un flux de sortie ?

Lorsque vous utilisez un flux de sortie, le flux doit avoir à la fois un accès en lecture et en écriture pour modifier l’étiquette ou la protection d’un fichier image.

Question : Existe-t-il des limites de limitation basées sur le service lors de l’utilisation du Kit de développement logiciel (SDK) MIP ?

Le service de protection, utilisé par les opérations de protection ou de protection dans le Kit de développement logiciel (SDK) de fichier, a une limite de 7 500 requêtes par dix secondes pour l’ensemble de l’organisation. Autrement dit, si l’application A génère 4 000 requêtes par dix secondes et applicaiton B dans la même organisation génère 4 000 requêtes par dix secondes, les deux applications peuvent commencer à recevoir HTTP 429 Too Many Requests des réponses. Les développeurs doivent implémenter une période d’interruption lorsque ces exceptions sont reçues.