Cree sus propias políticas de retención adaptables con Azure Automation

Evite licencias de alta gama con políticas de retención adaptables hechas por usted mismo

En mi último artículo que cubre los ámbitos adaptables para las políticas de retención de Microsoft 365, cubrí cómo usar 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 encontradas por la consulta de alcance, los alcances adaptables funcionan bien y son una buena manera de garantizar que el procesamiento de retención de Microsoft Purview se aplique automáticamente a conjuntos específicos de cuentas sin actualizaciones continuas por parte de un administrador.

La desventaja de los ámbitos adaptables es que requieren 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, tal vez como resultado de la desaceleración del crecimiento de usuarios de Office 365. El resultado es que cualquier característica 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 alcance estático significa que los administradores son responsables de gestionar 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 cuando se aplica una política de retención a todas las ubicaciones de un determinado tipo (como todos los buzones de correo o todos los sitios). En otras circunstancias, asegurarse de que el conjunto de ubicaciones estáticas especificadas en una política sea preciso puede requerir un esfuerzo considerable.

PowerShell y Azure Automation ofrecen actualizaciones para políticas de retención adaptables

Se me ocurrió que debería ser posible crear una forma de procesamiento de retención adaptativo que pueda hacer usted mismo con una combinación de un script de PowerShell y Azure Automation. La combinación replica lo que hacen los alcances adaptativos sin la 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 guión 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 deben agregar.
• 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 directiva de retención. La reciente adición de soporte para identidades administradas por V3.0 del módulo de administración de Exchange Online hace que este proceso sea más fácil, incluso si los cmdlets que se ejecutan en el punto final de cumplimiento aún requieren credenciales para conectarse (Microsoft está trabajando para solucionar este problema y es posible que se pueda encontrar una solución). estará disponible cuando lea este artículo).

Una implementación de ejemplo

Para demostrar que el principio 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 cuentas de usuario actualizando los buzones de correo de Exchange Online y las cuentas de OneDrive para la Empresa propiedad de las cuentas de usuario encontradas en 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 buzones de correo y cuentas de OneDrive (Figura 1). Aunque esto pueda parecer un paso extraño, es importante hacerlo y no orientar la política a todas las ubicaciones disponibles. Una política con Todo mostrado 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.

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 de correo). El cmdlet Set-RetentionCompliancePolicy utilizado por el script solo puede actualizar ubicaciones si la política está configurada para procesar ubicaciones seleccionadas. En otras palabras, el cmdlet Set-RetentionCompliancePolicy no puede cambiar una política entre procesamiento integral y selectivo.

Escribir el guión

Con una política de destino contra la cual trabajar, podemos seguir adelante y encontrar algunos buzones de correo y cuentas de OneDrive para procesar. El guión hace lo siguiente:

• Se conecta al SDK de Microsoft Graph PowerShell con una identidad administrada para ejecutar el cmdlet Get-MgOrganization y buscar el dominio predeterminado para el inquilino. Necesitamos esto para calcular las URL de las cuentas de OneDrive para Empresas de destino.
• Conéctese a Exchange Online con una identidad administrada.
• Conéctese al punto de conexión de cumplimiento mediante las credenciales de 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).
• Utilice las mismas credenciales de cuenta para conectarse al punto final de administración de SharePoint Online.
• Encuentre el conjunto de buzones de correo de destino. Este ejemplo utiliza el mismo atributo personalizado para marcar buzones que en el artículo anterior.
• Busque el conjunto de cuentas de OneDrive para la Empresa en el inquilino y almacene el nombre del propietario y la dirección URL en una tabla hash.
• Recorra el conjunto de buzones para verificar el nombre principal de usuario de cada buzón con 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 ubicación actual y cree una lista de buzones para agregar a la política. Haga lo mismo con las cuentas de OneDrive.
• Compruebe si algún buzón de correo y cuenta 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 eliminarlo de la política.
• Llame al cmdlet Set-RetentionCompliancePolicy para agregar ubicaciones que deberían estar en la política y eliminar aquellas que no deberían.
• Llame al cmdlet Get-RetentionCompliancePolicy para informar el conjunto de ubicaciones cubiertas ahora por la política.

Nunca he visto el código que utiliza Microsoft para implementar ámbitos activos para las 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 adaptativo.

Tenga en cuenta que una política 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.

Gestión de riesgos de ciberseguridad para Active Directory

Descubra cómo prevenir y recuperarse de ataques AD a través de estas soluciones de gestión de riesgos de ciberseguridad.

Ejecutando el guión

Puede descargar el script desde 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 URL se usan para las cuentas de OneDrive para la Empresa. 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, probablemente nadie verá el resultado a menos que algo salga mal.

La Figura 3 muestra las propiedades de la política de retención después de ejecutar el script. Mientras que antes solo se anotaba una ubicación para Exchange Online y OneDrive for Business, ahora la política cubre 24 buzones de correo y 23 cuentas. La discrepancia entre los dos números se debe a una cuenta nueva que aún no ha iniciado sesión en OneDrive.

El mismo principio explicado aquí podría extenderse para crear una política de retención adaptable para Grupos de Microsoft 365 o sitios de SharePoint Online. Es sólo una cuestión de programación PowerShell.

El bricolaje no siempre es posible

No siempre es posible recrear una característica de Microsoft 365 con código de bricolaje. En este caso, es razonablemente sencillo crear una forma personalizada de procesamiento de retención adaptativo. La combinación de PowerShell y Azure Automation replica de manera efectiva lo que ofrece Microsoft en ámbitos adaptables.