Preguntas más frecuentes y problemas del SDK de Microsoft Information Protection (MIP)
En este artículo se proporcionan respuestas a las preguntas más frecuentes y se proporcionan instrucciones para solucionar problemas conocidos y errores comunes.
Preguntas más frecuentes
Cambios en el almacenamiento de metadatos
Ya anunciamos que estamos realizando un cambio en la ubicación de almacenamiento de los metadatos de las etiquetas para archivos de Office (Word, Excel, PowerPoint) a fin de admitir nuevas características en Office 365, SharePoint Online y otros servicios.
Preguntas más frecuentes sobre metadatos
Pregunta: ¿Se ven afectados otros formatos, como los archivos PDF?
- No, solo archivos de Office, específicamente archivos de Word, Excel y PowerPoint.
Pregunta: ¿Hay una versión específica del SDK de MIP que sea necesaria?
- El SDK de MIP versión 1.7 y posteriores son totalmente compatibles.
Pregunta: ¿Hay una versión específica del cliente de Office necesaria para usar esta ubicación de almacenamiento?
- Todos los clientes Aplicaciones Microsoft 365 publicados después de septiembre de 2021 admiten esta nueva ubicación de metadatos. La nueva ubicación de almacenamiento no se usa hasta que los administradores de inquilinos habilitan la característica de coautoría protegida.
Pregunta: ¿Los metadatos existentes se almacenan como una propiedad personalizada en custom.xml mantenerse actualizados?
- No. La primera vez que el documento se guarda después de habilitar la nueva ubicación de almacenamiento, los metadatos de etiqueta se mueven a la nueva ubicación. Los metadatos escritos a través
LabelingOptions.ExtendedPropertiesde permanecen en custom.xml.
Pregunta: ¿Es posible leer los metadatos de etiqueta sin el SDK de MIP?
- Sí, pero debe implementar su propio código para analizar el archivo y extraer la información.
Pregunta: Actualmente, es fácil "leer" la etiqueta extrayendo las cadenas del par clave-valor del archivo. ¿Todavía se pueden leer metadatos de esta manera?
- Sí, los metadatos siguen estando disponibles en el archivo XML de Office que se va a leer. La aplicación debe leer la configuración de coautoría del archivo de directiva para saber que el nuevo conjunto de características está habilitado. Esta configuración define dónde leer y escribir los datos de etiqueta (custom.xml frente a labelinfo.xml). Consulte MS-OFFCRYPTO: LabelInfo frente a propiedades de documento personalizadas | Microsoft Docs. para obtener detalles de la implementación.
Pregunta: Cómo determinar si la coautoría está habilitada en la directiva de etiqueta? El estado de la configuración de coautoría se devuelve del motor de directivas. Una aplicación puede leer los bytes sin procesar del motor de directivas para determinar el estado de coautoría.
Pregunta: ¿Cómo se migran las etiquetas a la nueva ubicación?
- La siguiente lógica se usa para determinar qué sección se lee y para leer o escribir datos de etiquetas.
| Action | Característica no habilitada | Característica habilitada |
|---|---|---|
| Leer | Etiqueta en custom.xml (desprotegido) o Doc SummaryInfo (protegido). | Si la etiqueta existe en labelinfo.xml, es la etiqueta efectiva. Si no hay ninguna etiqueta en labelinfo.xml, etiqueta en custom.xml o Doc SummaryInfo es la etiqueta efectiva. |
| Escribir | Todas las etiquetas nuevas se escriben en custom.xml (desprotegido) o Doc SummaryInfo (protegido). | Todas las etiquetas nuevas se escriben en labelinfo.xml. |
Análisis de archivos
Pregunta: ¿Puedo escribir en el mismo archivo que estoy leyendo actualmente con el SDK de archivos?
El SDK de MIP no admite la lectura simultánea y escritura del mismo archivo. Los archivos etiquetados dan como resultado una copia del archivo de entrada con las acciones de etiqueta aplicadas. La aplicación debe reemplazar el original por el archivo etiquetado.
Control de cadenas de SDK
Pregunta: ¿Cómo controla el SDK las cadenas y qué tipo de cadena debo usar en mi código?
El SDK está diseñado para usarse en múltiples plataformas y usa UTF-8 (formato de transformación Unicode de 8 bits) para el control de cadenas. Las instrucciones específicas dependen de la plataforma que use:
| Plataforma | Guía |
|---|---|
| Windows nativo | Para clientes del SDK de C++, se utiliza el tipo de biblioteca estándar de C++ std::string para pasar cadenas a funciones de API o desde ellas. El SDK de MIP administra internamente la conversión a UTF-8 o desde este. Cuando se devuelve un elemento std::string desde una API, lo más probable es que vea codificación UTF-8, y deberá decidir en consecuencia si convierte la cadena. En algunos casos, se devuelve una cadena como parte de un vector uint8_t (por ejemplo, una licencia de publicación (PL)), pero se debe tratar como un blob opaco.Para más información y ejemplos, consulte:
|
| .NET | Para los clientes del SDK de .NET, todas las cadenas usan la codificación UTF-16 predeterminada y no se necesita ninguna conversión especial. El SDK de MIP administra internamente la conversión a u uTF-16. |
| Otras plataformas | Todas las demás plataformas compatibles con el SDK de MIP tienen compatibilidad nativa con UTF-8. |
Marcado de contenido
Pregunta: ¿Admite el SDK de MIP el marcado de contenido?
El SDK de MIP no admite la aplicación directa de marcado de contenido, incluidos encabezados, pies de página o marcas de agua, en ningún archivo. Cuando los metadatos de etiqueta se escriben en un archivo, el SDK de archivos escribe la propiedad de metadatos contentBits para indicar que se aplicó la protección (si está configurada). No escribe las propiedades que indican que se aplicaron encabezados, pies de página o marca de agua. Cuando el archivo se abre en una aplicación, la aplicación debe evaluar la configuración de marcado de contenido y escribir en el archivo al guardar.
Sdk de protección y directivas en Android
Pregunta: ¿Qué biblioteca compartida debo usar para integrar el SDK de MIP en mi aplicación Android?
Los archivos binarios de Android del SDK de MIP incluyen libmip_core.so, libmip_protection_sdk.solibmip_upe_sdk.so y lipmip_unified.so. libmip_unified.so es la biblioteca recomendada que incluye las bibliotecas compartidas de núcleos, protección y directivas.
Cumplimiento normativo
Pregunta: ¿Es compatible el ESTÁNDAR federal de procesamiento de información (FIPS) 140-2 del SDK de Microsoft Information Protection?
Consulte Validación de FIPS 140-2.
Referencia de problemas y errores
Error: "No se admite el formato de archivo"
Pregunta: ¿Por qué obtengo el siguiente error al intentar proteger o etiquetar un archivo PDF?
No se admite el formato de archivo
Esta excepción resulta de intentar proteger o etiquetar un archivo PDF protegido digitalmente o con contraseña. Consulte Nueva compatibilidad con el cifrado de PDF con Microsoft Information Protection para obtener más información sobre cómo proteger y etiquetar archivos PDF.
Error: "NoPolicyException: La directiva de etiqueta no contenía datos"
Pregunta: ¿Por qué obtengo el siguiente error al intentar leer una etiqueta o una lista a través del SDK de MIP?
NoPolicyException: la directiva de etiqueta no contenía datos, CorrelationId=GUID, CorrelationId.Description=PolicyProfile, NoPolicyError.Category=SyncFile, NoPolicyError.Category=SyncFile.Category=SyncFile
Este error indica que una directiva de etiqueta no se publica en el portal de cumplimiento Microsoft Purview. Siga los pasos descritos en Creación y configuración de etiquetas de confidencialidad y sus directivas para configurar la directiva de etiquetado.
Si se ha publicado una directiva de etiquetado, asegúrese de que la cuenta de usuario se incluye en los grupos que forman parte de la sección publicada en de la configuración de la directiva de etiqueta. Para obtener más información, consulte Creación y publicación de etiquetas de confidencialidad.
Los usuarios externos, incluidos los usuarios invitados, no pueden acceder a las directivas de etiquetas de otra organización. Para dar cabida a estos usuarios, implemente un mecanismo de reintento. Si se produce una NoPolicyException excepción , establezca la FileEngineSettings propiedad ProtectionOnlyEngine en true y vuelva a intentar la solicitud. Las operaciones de etiquetado no estarán disponibles para esa IFileEngine instancia, pero las operaciones de protección estarán disponibles.
Error: "System.ComponentModel.Win32Exception: Error de LoadLibrary"
Pregunta: ¿Por qué obtengo el siguiente error al usar el contenedor de .NET del SDK de MIP?
System.ComponentModel.Win32Exception: LoadLibrary failed for: [sdk_wrapper_dotnet.dll] when calling MIP.Initialize().
La aplicación no tiene el entorno de ejecución necesario o no se ha compilado como Versión. Consulte Asegurarse de que la aplicación tiene el tiempo de ejecución necesario para obtener más información.
Error: "Excepción ProxyAuthError"
Pregunta: ¿Por qué obtengo el siguiente error al usar el SDK de MIP?
"ProxyAuthenticatonError: no se admite la autenticación de proxy"
El SDK de MIP no admite el uso de servidores proxy autenticados. Para corregir este mensaje, los administradores de proxy deben establecer los puntos de conexión de servicio de Microsoft Purview Information Protection para que omitan el proxy. Hay disponible una lista de esos puntos de conexión en la página Direcciones URL e intervalos de direcciones IP de Office 365. El SDK de MIP requiere que *.protection.outlook.com (fila 9) y los puntos de conexión de Azure Information Protection Service (fila 73) omitan la autenticación de proxy.
Error: "Error desconocido" al etiquetar un archivo de imagen mediante una salida de flujo
Pregunta: ¿Por qué obtengo un "error desconocido" cuando intento agregar o quitar una etiqueta o protección de un tipo de archivo de imagen mediante una secuencia para la salida?
Cuando se usa una secuencia para la salida, la secuencia debe tener acceso de lectura y escritura para modificar la etiqueta o protección de un archivo de imagen.
Pregunta: ¿Hay límites de limitación basados en servicios al usar el SDK de MIP?
El servicio de protección, usado por el SDK de protección o las operaciones de protección en el SDK de archivos, tiene un límite de 7500 solicitudes por 10 segundos para toda una organización. Es decir, si la aplicación A genera 4000 solicitudes por 10 segundos y la aplicación B de la misma organización genera 4000 solicitudes por 10 segundos, ambas aplicaciones pueden empezar a recibir HTTP 429 Too Many Requests respuestas. Los desarrolladores deben implementar un período de retroceso cuando se reciben estas excepciones.