Compartir a través de


Control de acceso de los ingenieros de servicio de Microsoft 365

Acceso permanente cero (ZSA) significa que el personal del equipo de servicio de Microsoft no tiene acceso con privilegios permanentes al entorno de producción de Microsoft 365 ni a los datos del cliente. Cuando un miembro del equipo de servicio de Microsoft quiere actualizar el servicio o acceder a los datos del cliente por cualquier motivo, debe enviar una solicitud que justifique la necesidad y recibir la aprobación de un administrador autorizado. A escala, no es factible proporcionar y quitar manualmente el acceso según sea necesario para mantener los servicios de Microsoft 365, por lo que Microsoft ha desarrollado una solución automatizada para administrar el acceso con privilegios según sea necesario.

Caja de seguridad

Todo el acceso a los sistemas de Microsoft 365 y a los datos de los clientes se realiza mediante Lockbox, un sistema de control de acceso que usa un modelo Just-In-Time (JIT) y Just-Enough-Access (JEA) para proporcionar a los ingenieros de servicio acceso con privilegios temporales a los datos y servicios de Microsoft 365 especificados. Además, todas las solicitudes y acciones se registran con fines de auditoría y son accesibles mediante la API de actividad de administración de Office 365 y el Centro de seguridad y cumplimiento.

Antes de que un ingeniero de servicios de Microsoft pueda conectarse a cualquier sistema de Microsoft 365 o acceder a los datos del cliente, debe enviar una solicitud de acceso a través de la Caja de seguridad. Esta solicitud solo se puede aprobar si se cumplen determinados criterios:

  • El ingeniero de servicio cumple los requisitos de elegibilidad para una cuenta de equipo de servicio,
  • Pertenecen al rol De caja de seguridad asociado al trabajo en la solicitud,
  • El tiempo de acceso solicitado no supera el tiempo máximo permitido,
  • Tienen una justificación comercial legítima,
  • El recurso solicitado al que desean acceder está dentro de su ámbito de trabajo y
  • Reciben la aprobación del administrador

Una vez que lockbox cumple y comprueba todos los criterios, se concede acceso temporal para realizar la acción específica solicitada. Una vez transcurrido el tiempo de la solicitud, se revoca el acceso.

Flujo de caja de seguridad.

Además, si un cliente licencia y habilita la característica Caja de seguridad del cliente , cualquier intento de un ingeniero de servicios de Microsoft de acceder a los datos del cliente debe ser aprobado adicionalmente por un administrador en el inquilino del cliente. La necesidad de acceder a los datos del cliente puede surgir tanto del cliente como de Microsoft. Por ejemplo, un incidente generado por un cliente puede requerir acceso a sus datos para corregir el problema o cuando Microsoft necesita acceso a datos para aplicar una actualización específica.

Los clientes no tienen herramientas para iniciar una solicitud de Caja de seguridad del cliente; deben enviar un vale a Microsoft que requiera que se envíe una solicitud de caja de seguridad del cliente. Un administrador de Microsoft y un administrador autorizado en el inquilino del cliente deben aprobar una solicitud de Caja de seguridad del cliente planteada por un ingeniero de servicios de Microsoft.

Flujo de caja de seguridad del cliente.

Roles de caja de seguridad

Para aplicar la separación de tareas y el principio de privilegios mínimos, los ingenieros de servicio deben pertenecer a un rol de caja de seguridad que corresponda a su rol en el equipo. Los roles de caja de seguridad se administran dentro de la herramienta Identity Management y definen los privilegios y las acciones para los que se puede aprobar un miembro del equipo de servicio mediante el proceso de solicitud de Caja de seguridad. El personal del equipo de servicio debe solicitar ser miembro de un rol de caja de seguridad y recibir la aprobación del administrador. Si se aprueba, la cuenta del equipo de servicio del empleado se coloca en un grupo de seguridad aplicado por Active Directory (AD) y Microsoft Entra identificador.

Interfaces de administración restringidas

Los ingenieros de servicio usan dos interfaces de administración para realizar tareas administrativas: Escritorio remoto desde una estación de trabajo de Administración segura (SAW) a través de una puerta de enlace de Terminal Service (TSG) segura y PowerShell remoto. Dentro de estas interfaces de administración, los controles de acceso basados en las directivas de software y solicitud de Caja de seguridad aprobadas aplican restricciones significativas sobre qué aplicaciones se ejecutan y qué comandos y cmdlets están disponibles.

Escritorio remoto

Los miembros del equipo de servicio que administran su servicio mediante Escritorio remoto deben conectarse desde un SAW, equipos portátiles especialmente diseñados y fabricados administrados por Microsoft específicamente para este caso de uso. Microsoft se asocia con proveedores para crear saws, creando una cadena de suministro corta y segura. Las SAW usan sistemas operativos protegidos que están configurados para limitar toda la funcionalidad, excepto lo que se necesita para las tareas de administración definidas. Estas limitaciones incluyen la deshabilitación de todos los puertos USB, las listas estrictas de acceso a aplicaciones, la eliminación del acceso al correo electrónico, la limitación de la navegación por Internet y la aplicación de bloqueos de protector de pantalla de inactividad. Los sistemas de control de acceso de Microsoft examinan las máquinas SAW periódicamente para asegurarse de que son compatibles con los controles de seguridad más recientes y deshabilitan automáticamente las máquinas si se determina que no son compatibles.

Los ingenieros de servicio solo pueden conectarse a un TSG a la vez y no se permiten varias sesiones. Sin embargo, los TSG permiten a los administradores del equipo de servicio de Microsoft 365 conectarse a varios servidores, cada uno con una sola sesión simultánea, para que los administradores puedan realizar eficazmente sus tareas. Los administradores del equipo de servicio no tienen permisos en los propios TSG. El TSG solo se usa para aplicar los requisitos de cifrado y autenticación multifactor (MFA). Una vez que el administrador del equipo de servicio se conecta a un servidor específico a través de un TSG, el servidor específico aplica un límite de sesión de uno por administrador.

Las directivas de grupo de Active Directory establecen restricciones de uso, conexión y requisitos de configuración para el personal de Microsoft 365. Estas directivas incluyen las siguientes características de TSG:

  • Usar solo el cifrado validado de FIPS 140-2
  • Las sesiones se desconectan después de 15 minutos de inactividad
  • Las sesiones cierran sesión automáticamente después de 24 horas

Las conexiones a TSG también requieren MFA mediante una tarjeta inteligente física independiente. Los ingenieros de servicio emiten tarjetas inteligentes diferentes para varias plataformas y plataformas de administración de secretos que garantizan un almacenamiento seguro de credenciales. Los grupos de seguridad de red usan directivas de grupo de Active Directory para controlar quién puede iniciar sesión en servidores remotos, el número de sesiones permitidas y la configuración del tiempo de espera de inactividad.

PowerShell remoto

Además del acceso remoto mediante TSG especialmente configurados, el personal del equipo de servicio con el rol caja de seguridad de operaciones de service engineer puede acceder a cierta funcionalidad administrativa en servidores de producción mediante PowerShell remoto. Para usar este acceso, el usuario debe estar autorizado para el acceso de solo lectura (depuración) al entorno de producción de Microsoft 365. La escalación de privilegios está habilitada de la misma manera que se habilita para los TSG mediante el proceso de caja de seguridad.

Para el acceso remoto, cada centro de datos tiene una dirección IP virtual con equilibrio de carga que actúa como un único punto de acceso. Los cmdlets de PowerShell remoto disponibles se basan en el nivel de privilegios identificado en la notificación de acceso obtenida durante la autenticación. Estos cmdlets proporcionan la única funcionalidad administrativa a la que pueden acceder los usuarios que se conectan mediante este método. PowerShell remoto limita el ámbito de los comandos disponibles para el ingeniero y se basa en el nivel de acceso concedido a través del proceso de Caja de seguridad. Por ejemplo, en Exchange Online, el cmdlet Get-Mailbox podría estar disponible, pero el cmdlet Set-Mailbox no.

Recursos