Guía

Incorporar a cientos de nuevos usuarios a partir de un archivo CSV proporcionado por RRHH.

→Utilice la función de carga masiva de la Consola de administración. Incluya la columna `Org Unit Path` en el CSV para colocar a los usuarios directamente en las UO correctas.

Por qué: Método más eficiente para la creación masiva de usuarios con la asignación de políticas correcta sin necesidad de scripting. Más directo que GCDS para una incorporación puntual.

Un empleado se va. Preserve sus archivos de Drive y transfiéralos al control de su gerente.

→Antes de suspender o eliminar al usuario, utilice la herramienta de transferencia de datos de la Consola de administración para transferir la propiedad de todos los archivos de Drive al gerente.

Por qué: Preserva la integridad de los datos y garantiza la continuidad del negocio. La transferencia directa de la propiedad es más limpia que compartir y mantiene un claro registro de auditoría.

Diferentes departamentos y equipos requieren configuraciones de servicio y políticas de seguridad únicas.

→Cree una estructura jerárquica de Unidades Organizativas (OU) (por ejemplo, /Ventas/Este, /Ventas/Oeste). Aplique políticas amplias en la OU principal y anulaciones específicas en las OUs secundarias.

Por qué: Las OUs proporcionan herencia de políticas jerárquica, lo que permite un control escalable y granular sobre la configuración para diferentes poblaciones de usuarios.

Automatizar la membresía de grupos para todos los usuarios del departamento de Ingeniería, incluidos los nuevos empleados.

→Cree un Grupo Dinámico con una consulta de membresía basada en el atributo de usuario `department==Engineering`.

Por qué: Gestiona automáticamente la membresía basándose en los atributos de usuario, eliminando las actualizaciones manuales y asegurando la coherencia a medida que cambian los roles de los usuarios.

Otorgue al personal de la Mesa de Ayuda la capacidad de restablecer contraseñas solo para los usuarios de la OU de la oficina principal.

→Cree un rol de administrador personalizado con solo el privilegio "Usuarios > Restablecer contraseña". Asigne este rol al equipo de la Mesa de Ayuda y delimítelo para que se aplique solo a la OU objetivo.

Por qué: Implementa el principio del privilegio mínimo. Los roles personalizados y delimitados evitan que los administradores delegados afecten a usuarios o configuraciones fuera de su responsabilidad.

Sincronizando desde Active Directory a través de GCDS, pero los UPN de usuario tienen un dominio antiguo. Es necesario crear usuarios con el nuevo dominio correcto.

→En GCDS, configure una regla de transformación de atributos para el atributo de dirección de correo electrónico para reemplazar la cadena del dominio antiguo por el nuevo.

Por qué: Corrige los datos durante el proceso de sincronización sin requerir la modificación del Active Directory de origen, lo que a menudo no es factible.

Un usuario fue eliminado accidentalmente hace 15 días. Su gerente ahora necesita un archivo crítico de su Drive.

→Desde la Consola de administración, restaure al usuario eliminado recientemente. La ventana de recuperación es de 20 días. Una vez restaurado, transfiera los datos y luego vuelva a eliminar si es necesario.

Por qué: Los usuarios eliminados son recuperables durante 20 días. Esta es la única forma de recuperar sus datos si no había una retención/conservación de Vault.

Un equipo de soporte necesita una dirección de correo electrónico compartida (support@) donde varios miembros puedan gestionar, asignar y rastrear las consultas de los clientes.

→Cree un Grupo de Google y configúrelo como una "Bandeja de entrada colaborativa".

Por qué: Este tipo de grupo está diseñado para flujos de trabajo compartidos, permitiendo la asignación de conversaciones y el seguimiento de la resolución, lo que es superior a una lista de distribución estándar o una cuenta de usuario compartida.

Aplicar un descargo de responsabilidad legal y una marca estandarizados en todos los correos electrónicos salientes del departamento de Ventas.

→En la configuración de Gmail, configure una regla de cumplimiento con una acción de "Adjuntar pie de página", delimitada a la OU de Ventas.

Por qué: Esto adjunta un pie de página no editable a nivel de servidor, asegurando un cumplimiento del 100%. Las soluciones del lado del usuario pueden ser modificadas o eludidas.

Permitir a los usuarios compartir archivos de Drive externamente, pero solo con dominios de socios específicos y aprobados.

→En la configuración para compartir Drive, agregue los dominios de los socios a la lista de "Dominios permitidos" y establezca la política de uso compartido en "Solo dominios permitidos".

Por qué: Proporciona un equilibrio entre seguridad y colaboración, evitando el intercambio de datos con partes externas no autorizadas mientras habilita asociaciones aprobadas.

Permitir invitados externos en Google Meet, pero evitar que se unan antes de que llegue un anfitrión interno.

→En la configuración de seguridad de Google Meet, asegúrese de que "El anfitrión debe admitir a personas de fuera de su organización" (golpear) esté habilitado.

Por qué: Mejora la seguridad de las reuniones al crear una sala de espera virtual, dando al anfitrión control sobre cuándo y qué participantes externos pueden unirse.

Migrar de un servidor Exchange local a Gmail con cero tiempo de inactividad para el correo electrónico entrante.

→Configure la entrega dual. Configure una ruta de correo en Workspace para reenviar el correo al servidor Exchange heredado, luego apunte los registros MX a Google.

Por qué: Garantiza que los usuarios reciban correo en ambos buzones durante una migración por fases, evitando mensajes perdidos y permitiendo una transición fluida.

Evitar que los usuarios instalen complementos de terceros no verificados en Docs, Sheets y Gmail.

→En la configuración de Marketplace, configure una lista de permitidos de aplicaciones aprobadas y establezca la política para restringir a los usuarios a solo las aplicaciones de la lista de permitidos.

Por qué: Reduce el riesgo de seguridad de aplicaciones de terceros maliciosas o ávidas de datos al crear un "jardín vallado" de herramientas aprobadas por TI.

Por cumplimiento, todos los correos electrónicos deben retenerse durante 7 años, incluso si los usuarios los eliminan de sus buzones.

→En Google Vault, cree una regla de retención personalizada para Gmail con una duración de 7 años. No establezca una fecha de caducidad.

Por qué: La retención de Vault opera independientemente de las acciones del usuario. Proporciona un archivo legalmente defendible para eDiscovery y cumplimiento, separado de los buzones de usuario activos.

El departamento legal requiere que todos los datos de empleados específicos (custodios) se conserven indefinidamente para litigios pendientes.

→En Google Vault, cree un Asunto (Matter), identifique a los usuarios como custodios y aplique una Retención Legal (Legal Hold) sobre ellos.

Por qué: Una Retención Legal anula todas las políticas de retención y eliminación. Los datos se conservan hasta que la retención se libera explícitamente, asegurando que se cumplan las obligaciones legales de preservación.

Evitar que los usuarios compartan accidentalmente documentos que contengan números de tarjetas de crédito o PII con partes externas.

→Cree una regla de Prevención de pérdida de datos (DLP) en `Security > Data protection`. Utilice detectores predefinidos (por ejemplo, Número de tarjeta de crédito) y configure la condición de activación para compartir externamente. La acción debe ser "Bloquear el uso compartido externo".

Por qué: DLP escanea el contenido en tiempo real para aplicar automáticamente las políticas de protección de datos, reduciendo el riesgo de error humano que lleva a fugas de datos.

Para cumplir con GDPR, asegúrese de que todos los datos primarios de los empleados europeos se almacenen en reposo dentro de los centros de datos europeos.

→Coloque a los usuarios europeos en una OU dedicada. En `Account > Data regions`, aplique una política de región de datos para "Europa" a esa OU.

Por qué: Esta función aborda directamente los requisitos de residencia de datos controlando la ubicación de almacenamiento geográfico de los datos primarios para servicios específicos.

Un usuario eliminó permanentemente un archivo crítico de Drive hace 10 días. Ya no está en su papelera.

→Si una regla de retención o retención legal de Vault cubría al usuario, busque el archivo en Vault y expórtelo para su recuperación.

Por qué: Vault actúa como una red de seguridad. Los datos cubiertos por retenciones/conservaciones se mantienen incluso después de ser eliminados "permanentemente" por el usuario.

Un empleado bajo retención legal se va. Necesita preservar sus datos y retención, pero liberar su licencia completa.

→Suspenda la cuenta de usuario y asigne una licencia de "Usuario archivado" (AU). Los datos permanecen en Vault y sujetos a la retención.

Por qué: Las licencias AU son una forma rentable de preservar datos de antiguos empleados para fines de cumplimiento y legales sin consumir una licencia activa completa.

Permitir el acceso a Workspace solo desde dispositivos corporativos gestionados o cuando se está conectado a la red de la oficina.

→Configure el Acceso Contextual (Context-Aware Access). Cree niveles de acceso para "Dispositivo conforme" (desde la gestión de puntos finales) y "Rango IP corporativo". Aplique una política que requiera uno de estos niveles para el acceso.

Por qué: Este es el núcleo de un modelo de confianza cero para Workspace, pasando de un perímetro de red a aplicar políticas de acceso basadas en el contexto del dispositivo y del usuario, independientemente de la ubicación.

Se sospecha que una cuenta de usuario ha sido comprometida. El atacante puede tener sesiones activas o acceso a aplicaciones.

→Inmediatamente: 1) Restablezca la contraseña del usuario. 2) Revoque todos los tokens OAuth de terceros. 3) Cierre todas las sesiones web.

Por qué: Este proceso de tres pasos garantiza que el atacante quede bloqueado de todos los puntos de acceso: inicio de sesión directo, acceso basado en aplicaciones y sesiones de navegador existentes.

Evitar que los usuarios otorguen acceso a datos corporativos a aplicaciones OAuth de terceros riesgosas o no verificadas.

→En `Security > API controls`, configure "App access control" para bloquear las aplicaciones no configuradas por defecto, luego agregue aplicaciones específicas y verificadas a la lista de "Confianza".

Por qué: Esto pasa de una postura de seguridad de permitir por defecto a una de denegar por defecto para las aplicaciones de terceros, dando a TI un control total sobre qué aplicaciones pueden acceder a los datos de la empresa.

Implementar el Inicio de Sesión Único (SSO) con un IdP de terceros, pero asegurar el acceso de administrador si el IdP no funciona.

→Configure SAML SSO para toda la organización. Cree un grupo o OU separado para los Superadministradores y configure una máscara de red o una configuración de grupo para excluirlos del requisito de SSO.

Por qué: Proporciona un procedimiento crítico de "break-glass", permitiendo a los administradores iniciar sesión con credenciales de Google durante una interrupción del IdP para gestionar el entorno.

Evitar que los atacantes suplanten su dominio en ataques de phishing y mejorar la entregabilidad del correo electrónico.

→Configure correctamente los registros DNS SPF, DKIM y DMARC para su dominio. Establezca la política DMARC en `p=reject` para una aplicación completa.

Por qué: Estos tres estándares trabajan juntos para autenticar su correo saliente, permitiendo a los servidores receptores rechazar con confianza los mensajes fraudulentos que suplantan su dominio.

Necesidad de notificación proactiva de eventos de seguridad como inicios de sesión sospechosos o advertencias de ataques respaldados por el gobierno.

→Monitorear regularmente el Centro de alertas. Configure reglas de alerta para enviar notificaciones por correo electrónico de eventos de alta prioridad al equipo de seguridad.

Por qué: El Centro de alertas es el centro centralizado para eventos relacionados con la seguridad. Las notificaciones proactivas permiten una respuesta rápida a incidentes.

Un usuario perdió su teléfono y no tiene códigos de respaldo, bloqueándolo de su cuenta protegida con 2SV.

→Como administrador, seleccione al usuario y genere códigos de verificación de respaldo de un solo uso para que recupere el acceso.

Por qué: Este es el procedimiento estándar y seguro para la recuperación de usuarios sin necesidad de deshabilitar temporalmente 2SV, lo que debilitaría la seguridad.

Exigir la forma más fuerte de autenticación para proteger a los usuarios de alto riesgo contra el phishing.

→Aplique una política de Verificación en 2 pasos que requiera el uso de solo Claves de seguridad (FIDO).

Por qué: Las claves de seguridad son resistentes al phishing porque utilizan criptografía de clave pública y verifican el origen de la página de inicio de sesión, a diferencia de TOTP o SMS que pueden ser objeto de phishing.

Un teléfono móvil gestionado por la empresa que contiene datos confidenciales ha sido perdido o robado.

→Desde la Consola de administración, en Dispositivos, localice el dispositivo e inicie inmediatamente un comando remoto de "Borrar dispositivo".

Por qué: Esta es la respuesta de seguridad principal para un dispositivo gestionado perdido. Restablece de fábrica el dispositivo de forma remota o borra el perfil de trabajo, protegiendo los datos corporativos del acceso no autorizado.

Aplicar un conjunto estándar de configuraciones de seguridad y extensiones obligatorias en todos los navegadores Chrome corporativos (Windows, Mac).

→Inscriba los navegadores en Chrome Browser Cloud Management (CBCM). Aplique políticas a la OU de usuario/navegador para instalar extensiones de forma forzada, bloquear otras y configurar ajustes.

Por qué: CBCM proporciona una gestión centralizada basada en la nube de los navegadores Chrome en cualquier plataforma, asegurando una política y postura de seguridad consistentes.

Permitir a los empleados usar dispositivos Android personales para trabajar (BYOD) manteniendo los datos corporativos separados y seguros.

→Implemente la Gestión Avanzada de Dispositivos Móviles y obligue a la creación de un Perfil de Trabajo de Android en los dispositivos propiedad de los empleados.

Por qué: Un Perfil de Trabajo crea un contenedor a nivel de sistema operativo que aísla las aplicaciones y datos de trabajo de los datos personales. El contenedor completo puede borrarse de forma remota sin afectar los archivos personales del usuario.

Una política de Acceso Contextual debe verificar que un dispositivo es propiedad de la empresa y está cifrado antes de conceder el acceso.

→Implemente la extensión/agente de Verificación de Punto Final de Google en todos los dispositivos gestionados. Configure el nivel de acceso de CAA para requerir un estado de dispositivo "Conforme" o "Propiedad de la empresa".

Por qué: La Verificación de Punto Final es el agente que recopila e informa la postura del dispositivo al motor de CAA, habilitando el control de acceso basado en la confianza del dispositivo.

Los usuarios informan que los correos electrónicos a un socio específico rebotan o se retrasan gravemente.

→Utilice la herramienta "Búsqueda de registros de correo electrónico" en la Consola de administración. Busque un mensaje de muestra para ver la ruta de entrega completa, las marcas de tiempo y cualquier error de rechazo del servidor receptor.

Por qué: La Búsqueda de registros de correo electrónico es la herramienta definitiva para diagnosticar problemas de entrega. Proporciona detalles granulares que confirman si el mensaje salió de Google y por qué fue rechazado.

Varios usuarios de la organización no pueden iniciar sesión de repente, informando errores de verificación de credenciales.

→El problema probablemente esté en el Proveedor de Identidad (IdP) de terceros. Verifique el estado del servicio IdP y la validez del certificado SAML en la configuración de SSO.

Por qué: Los fallos generalizados y repentinos de inicio de sesión en un entorno SSO casi siempre apuntan al IdP externo, no a cuentas de usuario individuales.

Un usuario informa que los códigos de 6 dígitos de su aplicación Google Authenticator son rechazados constantemente.

→Indique al usuario que verifique y sincronice la hora en su dispositivo móvil. La aplicación Authenticator tiene una función de corrección de tiempo.

Por qué: Los códigos OTP basados en tiempo (TOTP) dependen en gran medida de una hora sincronizada. La deriva del reloj es la causa más común de rechazo de códigos.

Los usuarios de una oficina específica se quejan de la mala calidad de video de Google Meet, mientras que en otras oficinas está bien.

→Investigue la red local en la oficina afectada. Verifique la saturación del ancho de banda, la alta latencia/jitter y asegúrese de que las reglas del firewall no estén limitando o bloqueando el tráfico de Google Meet.

Por qué: Los problemas de rendimiento específicos de la ubicación casi siempre son causados por problemas de red local, no por el propio servicio de Google.

Un usuario no recibe correos electrónicos de un remitente externo, pero sus compañeros sí.

→Verifique la configuración personal de Gmail del usuario para detectar cualquier filtro o regla de remitente bloqueado que pueda estar redirigiendo o eliminando los correos electrónicos entrantes.

Por qué: Cuando un problema afecta solo a un único usuario, la causa suele ser una configuración a nivel de usuario en lugar de una política a nivel de organización.

Un usuario puede iniciar una grabación de Meet, pero esta no se guarda después de que finaliza la reunión.

→Verifique la cuota de almacenamiento de Google Drive del usuario. Las grabaciones fallan si el usuario no tiene espacio suficiente.

Por qué: Las grabaciones de Meet se guardan en "Mi unidad" del organizador en una carpeta de "Grabaciones de Meet". Una cuota de Drive completa es la razón más común de los fallos de guardado.