Evite las licencias de gama alta con políticas de retención adaptables de bricolaje
En mi último artículo sobre los ámbitos adaptables para las políticas de retención de Microsoft 365, cubrí cómo usar los atributos personalizados de Azure AD para identificar el conjunto de cuentas para el procesamiento de retención. Además de tomar demasiado tiempo para evaluar e informar el conjunto de cuentas encontrado por la consulta de alcance, los alcances adaptables funcionan bien y son una buena manera de asegurarse de que el procesamiento de retención de Microsoft Purview se aplique automáticamente a conjuntos de cuentas específicos sin actualizaciones continuas por parte de un administrador.
La desventaja de los ámbitos adaptables es su requisito de licencias de cumplimiento de Office 365 E5 o Microsoft 365 E5. Microsoft tiene muchas ganas de maximizar la cantidad de ingresos generados por su base de usuarios de la nube, quizás como resultado de la desaceleración del crecimiento de usuarios de Office 365. El resultado es que cualquier función que incluya procesamiento automático, especialmente en el área de cumplimiento, generalmente requiere licencias de alto nivel.
Políticas de retención estática
Las políticas de retención de Microsoft 365 con ámbitos estáticos están disponibles para los inquilinos de Office 365 E3. Un ámbito estático significa que los administradores son responsables de administrar el conjunto de ubicaciones procesadas por una política. Una ubicación puede ser un buzón, un sitio, un grupo, un equipo o una cuenta de OneDrive.
A veces, no se necesita administración, como en el caso de que una política de retención se aplique a todas las ubicaciones de cierto tipo (como todos los buzones o todos los sitios). En otras circunstancias, asegurarse de que el conjunto de ubicaciones estáticas especificadas en una política sea precisa puede requerir un esfuerzo considerable.
PowerShell y Azure Automation ofrecen actualizaciones para políticas de retención adaptables
Se me ocurrió la idea de que debería ser posible crear una forma de procesamiento de retención adaptable de bricolaje con una combinación de un script de PowerShell y Azure Automation. La combinación replica lo que hacen los ámbitos adaptables sin necesidad de licencias de alto nivel. En este escenario, el script de PowerShell:
- Identifica el conjunto de ubicaciones para que se procese la política de retención. Los ámbitos adaptables consultan Azure AD para encontrar esta información. Nuestro script puede hacer lo mismo.
- Comprueba las ubicaciones ya especificadas en la política de retención para calcular las ubicaciones que se deben eliminar y las que se agregarán.
- Actualiza la política de retención con las nuevas ubicaciones.
Azure Automation ejecuta el script de forma programada para detectar y aplicar cambios en la política de retención. La reciente adición de soporte para identidades administradas por V3.0 del módulo de administración de Exchange Online facilita este proceso, incluso si los cmdlets que se ejecutan en el extremo de cumplimiento aún requieren credenciales para conectarse (Microsoft está trabajando para solucionar este problema y una solución podría estará disponible cuando lea este artículo).
Una implementación de ejemplo
Para probar que el principal funciona, escribí un runbook de Azure Automation (una versión de un script para ejecutar en el entorno de Azure Automation). Los ámbitos adaptables pueden procesar usuarios y grupos o sitios de SharePoint Online. Para esta demostración, el script procesa las cuentas de usuario actualizando los buzones de correo de Exchange Online y las cuentas de OneDrive para empresas propiedad de las cuentas de usuario encontradas por la consulta.
Para comenzar, creé una nueva política de retención estática con un alcance estático y definí una ubicación para los buzones de correo y las cuentas de OneDrive (Figura 1). Aunque esto puede parecer un paso extraño, es importante hacerlo y no orientar la política a todas las ubicaciones disponibles. Una política que muestra Todo para una ubicación busca y procesa todas las ubicaciones. Por ejemplo, si elige procesar Todos los buzones, la política procesa todos los buzones de usuario, compartidos e inactivos.
Figura 1: una política de retención estática con solo una ubicación de Exchange y OneDrive
Microsoft Purview trata las políticas de retención de manera diferente cuando procesan todas las ubicaciones disponibles para una carga de trabajo (como todos los buzones). El cmdlet Set-RetentionCompliancePolicy que usa el script solo puede actualizar las ubicaciones si la política está configurada para procesar las ubicaciones seleccionadas. En otras palabras, el cmdlet Set-RetentionCompliancePolicy no puede cambiar una política entre procesamiento integral y selectivo.
escribir el guion
Con una política de destino contra la que trabajar, podemos continuar y encontrar algunos buzones y cuentas de OneDrive para procesar. El script hace lo siguiente:
- Se conecta al SDK de PowerShell de Microsoft Graph con una identidad administrada para ejecutar el cmdlet Get-MgOrganization para encontrar el dominio predeterminado para el arrendatario. Necesitamos esto para calcular las direcciones URL de las cuentas de OneDrive para empresas de destino.
- Conéctese a Exchange Online con una identidad administrada.
- Conéctese al extremo de cumplimiento con las credenciales de la cuenta almacenadas en Azure Key Vault. La necesidad de usar credenciales almacenadas ya no será necesaria cuando Microsoft actualice los cmdlets de cumplimiento para usar identidades administradas (o corrija la autenticación basada en certificados).
- Use las mismas credenciales de cuenta para conectarse al extremo de administración de SharePoint Online.
- Encuentre el conjunto de buzones de correo de destino. Este ejemplo usa el mismo atributo personalizado para marcar buzones que en el artículo anterior.
- Busque el conjunto de cuentas de OneDrive para empresas en el arrendatario y almacene el nombre y la dirección URL del propietario en una tabla hash.
- Recorra el conjunto de buzones para comprobar el nombre principal de usuario de cada buzón en la tabla hash de OneDrive. Si se encuentra una coincidencia, sabemos que la cuenta de OneDrive pertenece al propietario del buzón, por lo que la almacenamos en una lista.
- Recupere el conjunto de ubicaciones actuales en la política mediante el cmdlet Get-RetentionCompliancePolicy.
- Verifique qué buzones de correo no están en el conjunto de ubicaciones actual y cree una lista de buzones de correo para agregar a la política. Haz lo mismo con las cuentas de OneDrive.
- Compruebe si los buzones de correo y las cuentas de OneDrive están dentro del alcance de la política, pero no deberían estarlo. Si encontramos alguno, agréguelo a una lista de ubicaciones para eliminar de la política.
- Llame al cmdlet Set-RetentionCompliancePolicy para agregar ubicaciones que deberían estar en la política y quitar las que no.
- Llame al cmdlet Get-RetentionCompliancePolicy para informar el conjunto de ubicaciones cubiertas ahora por la directiva.
Nunca he visto el código que usa Microsoft para implementar ámbitos activos para políticas de retención, pero estoy seguro de que se produce el mismo tipo de procesamiento para determinar el conjunto de ubicaciones que debe cubrir una política. Estoy seguro de que el código de Microsoft es más elegante y preciso que el mío (y no está escrito en PowerShell), pero el punto es que el código funciona y hace el mismo trabajo que un alcance adaptable.
Tenga en cuenta que una directiva de cumplimiento admite un máximo de 1000 buzones de correo individuales. Más importante aún, el límite es inferior (100) para los sitios de SharePoint Online y las cuentas de OneDrive para empresas. Las pruebas y el manejo de errores para los scripts utilizados en producción deben manejar estos límites. Para sortear los límites, puede crear varias políticas con la misma configuración de retención dirigida a diferentes conjuntos de buzones, sitios y cuentas.
Ejecutar el guión
Puede descargar el script de GitHub y probarlo usted mismo. El script se ejecuta en Azure Automation. Algunos cambios en la sección de autenticación del código harán que se ejecute de forma interactiva.
La figura 2 muestra los resultados del script después de ejecutarlo en el panel de prueba de una sesión de Azure Automation. El resultado muestra identificadores de objetos para que los buzones de correo agreguen y eliminen, mientras que las direcciones URL se usan para las cuentas de OneDrive para empresas. Estos son los valores utilizados para identificar ubicaciones internamente. Si quisiera, sería fácil cambiar las salidas para mostrar los nombres de las cuentas. Sin embargo, como el script se ejecuta como una tarea programada de Azure Automation, es probable que nadie mire el resultado a menos que algo salga mal.
Figura 2: prueba del script para actualizar las ubicaciones de la política de retención en Azure Automation
La figura 3 muestra las propiedades de la política de retención después de que se ejecuta el script. Donde anteriormente solo se indicaba una ubicación para Exchange Online y OneDrive for Business, ahora la política cubre 24 buzones y 23 cuentas. La discrepancia entre los dos números se debe a una nueva cuenta que aún no ha iniciado sesión en OneDrive.
Figura 3: La política de retención actualizada con ubicaciones agregadas para el procesamiento
El mismo principio explicado aquí podría extenderse para crear una política de retención adaptable para los sitios de Microsoft 365 Groups o SharePoint Online. Es solo una cuestión de programación de PowerShell.
El bricolaje no siempre es posible
No siempre es posible recrear una característica de Microsoft 365 con código DIY. En este caso, es razonablemente sencillo crear una forma personalizada de procesamiento de retención adaptable. La combinación de PowerShell y Azure Automation replica efectivamente lo que ofrece Microsoft en ámbitos adaptables.
