Directorio de usuarios y acceso único

Cada servicio que usa su empresa tiene su propia base de datos de usuarios. GitHub tiene usuarios. Slack tiene usuarios. AWS tiene usuarios IAM. Su CRM, analítica, gestión de proyectos — cada uno mantiene una lista separada de quién puede iniciar sesión.

Esto se convierte en un problema rápidamente. Cuando alguien se incorpora, crea cuentas en todas partes. Cuando se va, necesita recordar cada servicio al que tenía acceso. Cuando la contraseña de alguien es comprometida, no hay un lugar central desde donde bloquearlo.

Un directorio de usuarios resuelve esto convirtiéndose en la única fuente de verdad para la identidad. Todos sus usuarios existen en un solo lugar. Los servicios se autentican contra ese directorio en lugar de mantener sus propias bases de datos de usuarios. Cuando alguien se va, deshabilita una cuenta y pierde el acceso a todas partes.

¿Qué es un directorio de usuarios?

Un directorio de usuarios (también llamado proveedor de identidad o IdP) es una base de datos central de cuentas de usuario. Almacena:

• Quiénes son sus usuarios (nombres, direcciones de correo electrónico)
• Credenciales de autenticación (contraseñas, configuración de MFA)
• Membresías de grupo (ingeniería, marketing, administradores)
• A qué aplicaciones puede acceder cada usuario

Cuando un usuario intenta iniciar sesión en una aplicación conectada, la aplicación pregunta al directorio: "¿Tiene permiso esta persona?" El directorio gestiona la autenticación y devuelve una respuesta de sí/no más cualquier información relevante del usuario.

Esta es la base del Acceso Único (SSO). Los usuarios se autentican una vez con el directorio y luego acceden a múltiples aplicaciones sin volver a introducir credenciales.

El beneficio real: control sobre los datos de la empresa

Un directorio de usuarios no es solo una cuestión de comodidad. Se trata de garantizar que su empresa realmente posea y controle el acceso a sus propios datos.

Cuentas de trabajo frente a cuentas personales

Sin un directorio, los empleados a menudo se registran en herramientas de trabajo usando direcciones de correo electrónico personales. El diseñador usa su Gmail personal para crear una cuenta de Figma. Un desarrollador se registra en GitHub con su correo electrónico personal. Marketing crea cuentas de redes sociales vinculadas al número de teléfono personal de alguien.

Esto crea problemas graves:

La empresa no es propietaria de las cuentas. ¿Esa cuenta de Figma con todos sus activos de diseño? Pertenece al correo electrónico personal del empleado. Cuando se va, tiene que pedirle amablemente el acceso. Si no coopera, podría perderlo todo.

Sin visibilidad sobre qué existe. No puede consultar "¿qué cuentas tiene esta persona?" porque no hay un registro central. Cada cuenta vive en aislamiento.

Los restablecimientos de contraseña van al correo personal. Si alguien olvida una contraseña, el enlace de restablecimiento va a su bandeja de entrada personal. Después de que se va, no puede recuperar la cuenta.

Las cuentas personales se comprometen. Las personas reutilizan contraseñas. Su correo electrónico personal es víctima de phishing. Ahora los atacantes tienen acceso a los datos de su empresa a través de una cuenta personal que no controla.

Lo que le da un directorio

Cuando todos los empleados usan cuentas de trabajo de su directorio:

Usted es propietario de cada cuenta. [email protected] es su dominio. Usted controla el DNS, el enrutamiento de correo y los restablecimientos de contraseña. El empleado usa la cuenta; la empresa la posee.

Visibilidad completa. Consulte el directorio: "Mostrar todos los usuarios activos." Revise los registros de SSO: "¿A qué accedió esta persona?" Tiene una imagen completa de quién existe y a qué puede acceder.

Capacidad de bloqueo instantáneo. Deshabilite la cuenta del directorio y cada servicio conectado queda inaccesible. Sin necesidad de buscar cuentas individuales.

Políticas de seguridad consistentes. Requisitos de contraseña, aplicación de MFA, tiempos de espera de sesión — configurados una vez, aplicados en todas partes. Sin cuentas con contraseñas débiles porque "ese servicio no lo exige."

Registro de auditoría. Quién inició sesión, cuándo, desde dónde. Requerido para el cumplimiento. Imposible sin identidad centralizada.

El costo de hacerlo mal

Escenarios reales que ocurren sin un control de directorio adecuado:

Escenario 1: El diseñador que se fue El diseñador se va. Nadie se da cuenta de que la cuenta de Figma fue creada con su correo electrónico personal. Tres meses después, la empresa necesita actualizar el sistema de diseño. La cuenta está bloqueada detrás del correo electrónico personal del ex-empleado, que no lo está revisando. Todos los activos de diseño son inaccesibles.

Escenario 2: El Gmail personal comprometido El desarrollador usa Gmail personal para GitHub. Su Gmail es víctima de phishing (sin relación con el trabajo). El atacante encuentra credenciales de GitHub en contraseñas guardadas. Ahora tiene acceso a sus repositorios privados, incluidos secretos que alguien confirmó accidentalmente.

Escenario 3: La toma de control de redes sociales El número de teléfono personal del responsable de marketing está en la cuenta de Instagram de la empresa para 2FA. Se va en malos términos. Siguen controlando el 2FA. Recuperar la cuenta requiere el glacialmente lento proceso de verificación empresarial de Instagram.

La regla

Todas las herramientas de trabajo deben accederse con una cuenta de trabajo de su directorio.

Sin excepciones. Si alguien dice "usaré mi correo personal, es más fácil", la respuesta es no. Créele una cuenta de directorio. Si el servicio no admite SSO, cree la cuenta con su dirección de correo de trabajo y almacene las credenciales en Passwork.

Esto aplica a:

• Todas las aplicaciones SaaS
• Cuentas de redes sociales (cree correos basados en rol como [email protected])
• Herramientas y plataformas de desarrollo
• Portales de proveedores y cuentas de socios
• Registradores de dominio y proveedores de DNS
• Todo

La conveniencia a corto plazo de dejar que alguien use una cuenta personal no vale perder el control de los datos de la empresa cuando se va.

Tipos de directorios de usuarios

Google Workspace

Si ya usa Google Workspace para el correo electrónico, tiene un directorio de usuarios. Cada usuario de Google Workspace está en el servicio de directorio de Google.

Ventajas:

• Probablemente ya lo está pagando
• Se integra con la mayoría de las aplicaciones SaaS
• Admite SAML y OIDC para SSO
• Buena consola de administración para gestionar usuarios

Desventajas:

• SSO (más allá de las aplicaciones de Google) requiere Business Starter o superior
• Las aplicaciones SAML requieren Business Plus o Enterprise ($18+/usuario/mes)
• Funciones de identidad avanzadas limitadas

Ideal para: Empresas que ya usan Google Workspace y quieren evitar añadir otra herramienta.

Microsoft 365 / Entra ID (Azure AD)

El servicio de directorio de Microsoft, incluido con los planes Microsoft 365 Business.

Ventajas:

• Incluido si usa Microsoft 365
• Integración profunda con Windows, Office y Azure
• Funciones empresariales maduras
• Políticas de acceso condicional

Desventajas:

• Más complejo de administrar que Google
• Las funciones avanzadas requieren licencias premium
• Menos intuitivo para entornos ajenos a Microsoft

Ideal para: Empresas que usan Microsoft 365 o la nube de Azure.

Okta

Plataforma dedicada de gestión de identidad — es todo lo que hacen.

Ventajas:

• Funciones de SSO e identidad de primera clase
• Enorme catálogo de integración de aplicaciones
• Seguridad avanzada (MFA adaptativo, confianza en dispositivos)
• Universal Directory funciona entre proveedores

Desventajas:

• Caro ($2-15/usuario/mes según las funciones)
• Excesivo para equipos pequeños
• Otro proveedor que gestionar

Ideal para: Empresas con necesidades de identidad complejas o planes de crecimiento rápido.

JumpCloud

Directorio en la nube diseñado para empresas pequeñas y equipos distribuidos.

Ventajas:

• Gratuito para hasta 10 usuarios
• Gestiona dispositivos (Mac, Windows, Linux) más aplicaciones en la nube
• Compatibilidad con LDAP y RADIUS
• Precios razonables ($7-15/usuario/mes)

Desventajas:

• Catálogo de aplicaciones más pequeño que Okta
• Menos maduro que Google/Microsoft
• La gestión de dispositivos puede ser compleja

Ideal para: Equipos pequeños que necesitan la gestión de dispositivos incluida con la identidad.

Lista completa de servicios de directorio

De más simple a más complejo, esto es lo que está disponible en el mercado.

Nivel 1: Probablemente ya lo tiene

Vienen incluidos con servicios que probablemente ya usa. Sin coste adicional, configuración mínima.

Servicio	Qué obtiene	Compatibilidad con SSO	Precio	Ideal para
Google Workspace	Directorio + correo + documentos	SAML (Business Plus+), OIDC	$6-18/usuario/mes	Empresas basadas en Gmail
Microsoft 365	Entra ID + Office	SAML, OIDC	$6-22/usuario/mes	Entornos Outlook/Windows
Zoho One	Directorio + más de 40 aplicaciones	SAML, OIDC	$37/usuario/mes	Usuarios del ecosistema Zoho

Nivel 2: Opciones gratuitas o muy económicas

Buenas para startups y equipos pequeños con presupuesto limitado.

Servicio	Qué obtiene	Nivel gratuito	Precio de pago	Ideal para
JumpCloud	Directorio en nube + MDM	10 usuarios gratis	$7-15/usuario/mes	Equipos pequeños, trabajo remoto
Authentik	IdP de código abierto	Autoalojado gratis	Soporte Enterprise de pago	Equipos con conocimientos técnicos
Keycloak	IdP de código abierto	Gratis (autoalojado)	—	Desarrolladores, on-prem
Authelia	SSO de código abierto	Gratis (autoalojado)	—	Home lab, infraestructura pequeña
Kanidm	IdP moderno de código abierto	Gratis (autoalojado)	—	Equipos con enfoque en seguridad
FusionAuth	Identidad para desarrolladores	Comunidad gratuita	$125+/mes	Aplicaciones personalizadas
Zitadel	IAM nativo en la nube	Nivel gratuito	$100+/mes	Startups nativas en la nube

Nivel 3: Proveedores de identidad de mercado medio

Plataformas de identidad dedicadas. Más funciones que las opciones incluidas, menos complejas que las empresariales.

Servicio	Características clave	Precio	Ideal para
OneLogin	SSO, MFA, directorio	$4-8/usuario/mes	Empresas en crecimiento
Duo Security (Cisco)	MFA primero, SSO	$3-9/usuario/mes	Organizaciones enfocadas en MFA
Passwork	Gestor de contraseñas y secretos con AD/LDAP, SAML SSO, soporte de passkeys	desde €3/usuario/mes	Equipos que usan Passwork como gestor de contraseñas
Rippling	RRHH + TI + identidad	$8+/usuario/mes	Empresas impulsadas por RRHH
WorkOS	SSO para SaaS B2B	Pago por conexión	Creadores de SaaS
Clerk	Autenticación para desarrolladores	Nivel gratuito + $0,02/MAU	Enfocado en desarrolladores
Stytch	Autenticación sin contraseña	Nivel gratuito + de pago	Aplicaciones modernas
Descope	Flujos de autenticación sin código	Nivel gratuito	Desarrollo rápido

Nivel 4: Plataformas de identidad empresariales

Plataformas con todas las funciones para requisitos complejos. Caras pero potentes.

Servicio	Características clave	Precio	Ideal para
Okta	Líder del sector, más de 7000 integraciones	$2-15/usuario/mes	SSO empresarial
Okta Customer Identity	Identidad B2C	Basado en uso	Aplicaciones orientadas al cliente
Microsoft Entra ID P1/P2	Acceso condicional, PIM	$6-9/usuario/mes	Empresas en Azure
Ping Identity	SSO empresarial, federación	Personalizado	Grandes empresas
ForgeRock	Plataforma de identidad	Personalizado	Banca, sanidad
IBM Security Verify	IAM empresarial	Personalizado	Entornos IBM
CyberArk Identity	Privilegiado + personal	Personalizado	Organizaciones orientadas a la seguridad
SailPoint	Gobernanza de identidad	Personalizado	Alta exigencia de cumplimiento
Saviynt	Nube de identidad	Personalizado	GRC empresarial

Nivel 5: Opciones especializadas y regionales

Soluciones de nicho para casos de uso específicos o regiones.

Servicio	Enfoque	Ideal para
Frontegg	Gestión de usuarios para SaaS B2B	Productos SaaS
PropelAuth	Autenticación B2B + organizaciones	SaaS multitenant
Kinde	Autenticación moderna	Startups, PYMEs
SuperTokens	Autenticación de código abierto	Preferencia autoalojada
Hanko	Primero en passkeys	Adopción sin contraseña
Ory	Identidad de código abierto	Equipos nativos en la nube
Auth.js (NextAuth)	Autenticación JavaScript	Aplicaciones Next.js/Node
Logto	CIAM de código abierto	Identidad del cliente
BoxyHQ	SSO SAML empresarial	SaaS B2B

Cómo elegir

¿Ya usa Google o Microsoft para el correo electrónico? → Empiece con su directorio integrado. Actualice el plan si necesita SAML SSO.

¿Presupuesto inferior a $5/usuario/mes? → JumpCloud (10 usuarios gratis) o Authentik/Keycloak autoalojado si tiene los conocimientos.

¿También necesita gestión de dispositivos? → JumpCloud, Rippling o Microsoft Intune.

¿Está construyendo un producto SaaS? → WorkOS, Clerk o Auth0 para autenticación orientada al cliente.

¿Empresa con cumplimiento complejo? → Okta, Ping Identity o Microsoft Entra ID P2.

¿Quiere código abierto? → Keycloak (maduro), Authentik (interfaz moderna) u Ory (nativo en la nube).

Qué deben hacer la mayoría de las empresas pequeñas

1. Si usa Google Workspace: Empiece por ahí. Actualice a Business Plus cuando necesite SAML para más aplicaciones.
2. Si usa Microsoft 365: Entra ID ya está incluido. Úselo.
3. Si no usa ninguno: JumpCloud ofrece el mejor valor para equipos pequeños.
4. Si el presupuesto es cero: Keycloak o Authentik autoalojados, pero espere dedicar tiempo al mantenimiento.

No lo complique en exceso. Un directorio funcionando con el 80% de sus aplicaciones conectadas es mejor que un directorio perfecto que nunca se despliega.

Por qué centralizar todos los usuarios en el directorio

La tentación es usar SSO del directorio para algunas aplicaciones y crear cuentas locales para otras. No lo haga.

Cree cada usuario en el directorio, incluso si:

• Solo necesitan acceso a una aplicación
• La aplicación no admite SSO
• Parece más rápido crear simplemente una cuenta local

Por qué:

La desvinculación funciona: Cuando alguien se va, deshabilite su cuenta de directorio. Pierde acceso a todo lo que está conectado. Sin cuentas olvidadas.

La incorporación es consistente: ¿Nuevo empleado? Cree una cuenta, asígnela a grupos, obtiene acceso a todo lo que su rol necesita.

Existe el registro de auditoría: ¿Quién tiene acceso a qué? Consulte el directorio. Sin necesidad de auditar 50 aplicaciones separadas.

Las políticas de contraseña aplican: Requisitos de contraseña, aplicación de MFA — configurados una vez en el directorio, aplican en todas partes.

Para las aplicaciones que no admiten SSO: De todos modos cree el usuario en el directorio para el seguimiento. Use el gestor de contraseñas (Passwork) para gestionar las credenciales de la cuenta local. Al menos tiene un registro central.

Configuración de un dominio dedicado para la identidad

Puede ejecutar su identidad desde su dominio principal (empresa.com), pero muchas organizaciones usan un subdominio dedicado o un dominio separado para propósitos de identidad.

Opciones:

Enfoque	Ejemplo	Ventajas	Desventajas
Dominio principal	[email protected]	Simple, un solo dominio	Todo vinculado
Subdominio	[email protected]	Separación, sigue con marca	Algunas aplicaciones lo gestionan mal
Dominio separado	[email protected]	Aislamiento completo	Confuso para los usuarios

Cuándo tiene sentido un dominio de identidad separado:

• Quiere separar la identidad de los empleados del correo orientado al cliente
• Usa varios proveedores de identidad
• El cumplimiento requiere separación de la infraestructura de identidad
• Planea cambiar los dominios principales pero mantener la identidad estable

Recomendación práctica: Para la mayoría de las empresas pequeñas, use su dominio principal. La complejidad de un dominio separado no vale la pena hasta que tenga requisitos específicos.

Cómo funciona el SSO (versión simple)

Cuando un usuario intenta acceder a una aplicación conectada mediante SSO:

1. El usuario va a app.ejemplo.com
   ↓
2. La aplicación redirige al proveedor de identidad: "¿Quién es este?"
   ↓
3. El usuario se autentica con el IdP (contraseña + MFA)
   ↓
4. El IdP envía una aserción firmada de vuelta a la aplicación: "Este es [email protected],
   miembro del grupo de ingeniería"
   ↓
5. La aplicación concede acceso basándose en la aserción

Dos protocolos principales gestionan esto:

SAML 2.0 — Más antiguo, basado en XML, ampliamente admitido por aplicaciones empresariales. La configuración implica intercambiar certificados y archivos XML de metadatos.

OIDC (OpenID Connect) — Más nuevo, basado en JSON, más fácil de implementar. Construido sobre OAuth 2.0. Preferido para aplicaciones modernas.

La mayoría de las aplicaciones admiten ambos. Si tiene opción, OIDC suele ser más fácil de configurar.

Conexión de aplicaciones a su directorio

Paso 1: Comprobar qué admite su directorio

Google Workspace:

• Configuración → Aplicaciones → Aplicaciones web y móviles → Añadir aplicación → Buscar aplicaciones SAML

Microsoft Entra ID:

• Portal de Azure → Entra ID → Aplicaciones empresariales → Nueva aplicación

Paso 2: Comprobar la compatibilidad con SSO de la aplicación

Antes de conectar una aplicación, compruebe:

1. ¿Admite SAML u OIDC?
2. ¿Qué plan se requiere? (Muchas aplicaciones requieren niveles de pago para SSO)
3. ¿Qué información necesita intercambiar?

Patrones habituales:

Aplicación	Protocolo SSO	Plan requerido
Slack	SAML	Business+
GitHub	SAML	Enterprise
AWS	SAML	Gratis (IAM Identity Center)
Notion	SAML	Business
Figma	SAML	Organization
Atlassian (Jira/Confluence)	SAML	Premium
Salesforce	SAML	Incluido
Zoom	SAML	Business+
Passwork	SAML	Advanced

Si usa Passwork como su gestor de contraseñas, puede conectarlo a su proveedor de identidad mediante SAML SSO — para que los empleados inicien sesión en Passwork a través del mismo inicio de sesión centralizado que todo lo demás. Esto está disponible en el plan Advanced.

El impuesto SSO: Muchos proveedores de SaaS cobran más por la compatibilidad con SSO. Es frustrante pero real. Inclúyalo en el presupuesto si el SSO es importante para usted.

Paso 3: Configurar la conexión

Proceso general (varía según la aplicación):

En el lado de la aplicación:

1. Encuentre los ajustes de SSO (normalmente Configuración → Seguridad o Admin → Autenticación)
2. Elija SAML u OIDC
3. Obtenga la URL de callback/ACS y el ID de entidad

En el lado del directorio:

1. Añada una nueva aplicación (SAML u OIDC)
2. Introduzca la URL de callback y el ID de entidad de la aplicación
3. Descargue los metadatos o los valores del IdP (ID de entidad, URL de SSO, certificado)

De vuelta en el lado de la aplicación:

1. Introduzca los metadatos o valores del IdP
2. Configure la asignación de atributos (correo electrónico, nombre, grupos)
3. Pruebe con un único usuario antes de aplicarlo a todos

Paso 4: Probar y aplicar

1. Pruebe el inicio de sesión SSO con una cuenta
2. Verifique que los atributos del usuario se pasan correctamente
3. Compruebe que las membresías de grupo funcionan (si usa acceso basado en grupos)
4. Habilite SSO para todos los usuarios
5. Deshabilite la autenticación local (opcional pero recomendado por seguridad)

Configuración del aprovisionamiento automático de usuarios (SCIM)

SSO gestiona la autenticación, pero ¿qué pasa con la creación y eliminación automática de usuarios?

SCIM (System for Cross-domain Identity Management) gestiona el aprovisionamiento:

• Nuevo usuario añadido al directorio → se crea automáticamente en las aplicaciones conectadas
• Usuario eliminado del directorio → se desactiva automáticamente en las aplicaciones
• El usuario cambia de grupo → los permisos de la aplicación se actualizan automáticamente

Qué aplicaciones admiten SCIM:

Aplicación	Compatibilidad con SCIM
Slack	Solo Enterprise Grid
GitHub	Enterprise Cloud
Salesforce	Sí
Aplicaciones conectadas a Okta	La mayoría
Aplicaciones de Google Workspace	Nativas

SCIM requiere más configuración que SSO pero mejora drásticamente la automatización de incorporación/desvinculación.

Estructura del directorio: grupos y roles

Organice los usuarios en grupos que correspondan a niveles de acceso:

empresa.com
├── all-employees
├── engineering
│   ├── eng-backend
│   ├── eng-frontend
│   └── eng-devops
├── product
├── marketing
├── finance
└── admins
    ├── it-admins
    └── security-admins

Asignación de grupos a acceso de aplicaciones:

Grupo	Slack	GitHub	AWS	Jira
engineering	✓	✓ (write)	✓ (dev)	✓
marketing	✓	✓ (read)	—	✓ (view)
finance	✓	—	✓ (billing)	—
admins	✓	✓ (admin)	✓ (admin)	✓ (admin)

Cuando se incorpora un nuevo ingeniero:

1. Cree el usuario en el directorio
2. Añádalo a los grupos all-employees y engineering
3. SSO concede automáticamente acceso a Slack, GitHub, AWS, Jira

Cuando se va:

1. Deshabilite la cuenta de directorio
2. Todo el acceso se revoca inmediatamente

Aplicación de MFA a través del directorio

Configure los requisitos de MFA en el directorio, no en cada aplicación.

Google Workspace: Consola de administración → Seguridad → Verificación en 2 pasos → Aplicación

Microsoft Entra ID: Seguridad → MFA → Configuración adicional de MFA en la nube

Mejores prácticas:

• Exija MFA para todos los usuarios
• Permita múltiples métodos (aplicación autenticadora, llaves de hardware)
• Proporcione opciones de recuperación (códigos de respaldo, restablecimiento por administrador)

Cuando MFA se aplica a nivel de directorio, los usuarios completan MFA una vez durante la autenticación SSO y luego acceden a todas las aplicaciones conectadas sin volver a autenticarse en cada una.

Gestión de aplicaciones sin compatibilidad con SSO

No todas las aplicaciones admiten SSO. Para estas:

1. De todos modos cree usuarios en el directorio para el seguimiento
2. Use el gestor de contraseñas (Passwork) para almacenar las credenciales
3. Documente la aplicación en su inventario de SaaS
4. Inclúyala en la lista de verificación de desvinculación para la desactivación manual

Almacene las credenciales en Passwork con nombres claros:

• [NombreApp] - Cuenta de administrador
• [NombreApp] - [email protected]

Cuando alguien se va, el proceso de desvinculación incluye:

1. Deshabilitar la cuenta de directorio (gestiona las aplicaciones SSO)
2. Comprobar Passwork para las cuentas locales (gestiona las aplicaciones sin SSO)
3. Desactivar esas manualmente

Configuración práctica: Google Workspace como directorio

Aquí tiene una guía paso a paso para empresas pequeñas que empiezan con Google Workspace:

Requisitos previos:

• Google Workspace Business Starter o superior
• Acceso de administrador a la consola de administración de Google
• Lista de aplicaciones a conectar

Paso 1: Verificar dominio y usuarios

Consola de administración → Usuarios
- Todos los empleados deben tener cuentas de Google Workspace
- Verifique que las direcciones de correo correspondan al formato esperado

Paso 2: Crear unidades organizativas y grupos

Consola de administración → Directorio → Unidades organizativas
- Cree la estructura: Ingeniería, Marketing, etc.

Consola de administración → Directorio → Grupos
- Cree grupos que coincidan con sus necesidades de acceso
- Añada usuarios a los grupos apropiados

Paso 3: Habilitar SSO para la primera aplicación (ejemplo: Slack)

En el lado de Slack:

1. Configuración del espacio de trabajo → Autenticación → Configurar SSO
2. Copie la URL ACS de Slack y anote la URL del espacio de trabajo

En el lado de Google:

1. Consola de administración → Aplicaciones → Aplicaciones web y móviles → Añadir aplicación
2. Busque Slack o añada una aplicación SAML personalizada
3. Introduzca la URL ACS de Slack
4. Descargue los metadatos del IdP de Google

De vuelta en Slack:

1. Suba los metadatos de Google o introduzca los valores manualmente
2. Configure la asignación de atributos (correo electrónico)
3. Pruebe con un usuario
4. Habilite para el espacio de trabajo

Paso 4: Repetir para otras aplicaciones

Trabaje en su lista de prioridades:

1. AWS (IAM Identity Center)
2. GitHub (si tiene Enterprise)
3. Otras aplicaciones críticas

Paso 5: Documentar y comunicar

• Actualice el inventario de SaaS con el estado de SSO
• Informe a los usuarios sobre los cambios en el inicio de sesión SSO
• Actualice los procedimientos de incorporación/desvinculación

Errores habituales

Error 1: Cuentas en la sombra

Los usuarios crean cuentas locales en las aplicaciones en lugar de usar SSO. Evitan el directorio y usted pierde el control.

Solución: Tras habilitar SSO, deshabilite la autenticación local donde sea posible. Haga del SSO la única forma de entrar.

Error 2: Asignación de grupos incompleta

Los grupos existen en el directorio pero no están asignados a los permisos de la aplicación. Los usuarios obtienen acceso SSO pero con niveles de permiso incorrectos.

Solución: Documente la asignación grupo-permiso para cada aplicación. Pruebe con usuarios de cada grupo.

Error 3: Sin cuentas de emergencia

Todos usan SSO. El directorio tiene una interrupción. Nadie puede acceder a nada, incluida la consola de administración del directorio.

Solución: Mantenga una o dos cuentas de administrador locales para acceso de emergencia. Almacene las credenciales en Passwork y pruébelas trimestralmente.

Error 4: Ignorar las aplicaciones sin SSO

La atención va a las aplicaciones con SSO. Las aplicaciones sin SSO se olvidan, con cuentas obsoletas que permanecen después de la desvinculación.

Solución: Incluya las aplicaciones sin SSO en su inventario de SaaS y en la lista de verificación de desvinculación.

Taller: configure su directorio de usuarios

Reserve 3-4 horas para la configuración inicial. Este es un trabajo fundamental que le ahorrará innumerables horas en incorporación y desvinculación.

Parte 1: Elegir y configurar su directorio (45 minutos)

Si ya tiene Google Workspace o Microsoft 365:

1. Inicie sesión en la consola de administración
2. Verifique que todos los empleados actuales tienen cuentas
3. Compruebe que ningún ex-empleado todavía tiene cuentas activas
4. Revise las políticas actuales de contraseñas y MFA

Si empieza desde cero:

1. Compare las opciones de la lista de servicios de directorio anterior
2. Regístrese en el servicio elegido (el nivel gratuito de JumpCloud es bueno para probar)
3. Configure los ajustes básicos (dominio, política de contraseñas)
4. Cree su cuenta de administrador con MFA habilitado

Entregable: Servicio de directorio elegido y acceso de administrador confirmado

Parte 2: Crear su estructura organizativa (30 minutos)

1. Cree unidades organizativas o grupos:

   ├── all-employees
   ├── engineering
   ├── product
   ├── marketing
   ├── finance
   └── admins

2. Documente a qué debe tener acceso cada grupo:

   Grupo	Slack	GitHub	AWS	Jira	CRM
   engineering	✓	✓ (write)	✓ (dev)	✓	—
   product	✓	✓ (read)	—	✓	✓
   marketing	✓	—	—	✓ (view)	✓

3. Agréguese a los grupos apropiados para las pruebas

Entregable: Estructura de grupos creada y documentada

Parte 3: Conectar su primera aplicación SSO (45 minutos)

Elija una aplicación que admita SSO y sea crítica para el negocio. Buenas primeras opciones:

• Passwork (plan Advanced) — su gestor de contraseñas es el punto de acceso único a todas las credenciales; conectarlo a SSO significa que los empleados usan un inicio de sesión centralizado para todo, y la desvinculación revoca el acceso a Passwork junto con todo lo demás
• AWS (IAM Identity Center) — infraestructura crítica
• Slack (requiere Business+) — todo el mundo lo usa
• GitHub (requiere Enterprise) — importante para los desarrolladores

Pasos:

1. Consulte la documentación de SSO de la aplicación
2. En su directorio, añada una nueva aplicación SAML u OIDC
3. Intercambie metadatos/configuración entre el directorio y la aplicación
4. Pruebe el inicio de sesión SSO con su cuenta
5. Documente la configuración

Entregable: Una aplicación conectada mediante SSO, probada y funcionando

Parte 4: Migrar usuarios existentes (30 minutos)

1. Exporte la lista de usuarios de la aplicación conectada
2. Verifique que cada usuario existe en su directorio
3. Cree las cuentas de directorio que falten
4. Pruebe el acceso SSO para uno o dos usuarios
5. Planifique la comunicación del despliegue al equipo

Entregable: Asignación de usuarios documentada, plan de migración creado

Parte 5: Configurar acceso de emergencia (15 minutos)

1. Cree una cuenta de administrador local de emergencia en las aplicaciones críticas
2. Genere una contraseña segura, almacénela en Passwork
3. Documente qué aplicaciones tienen cuentas de emergencia
4. Compruebe que el acceso de emergencia funciona

Entregable: Acceso de emergencia configurado y probado

Parte 6: Documentar la incorporación/desvinculación (30 minutos)

Cree o actualice sus procedimientos:

Lista de verificación de incorporación:

☐ Crear cuenta en [nombre del directorio]
☐ Añadir a los grupos apropiados: ___________
☐ Verificar acceso SSO a las aplicaciones críticas
☐ Crear cuentas locales para las aplicaciones sin SSO (almacenar en Passwork)
☐ Enviar correo de bienvenida con instrucciones de inicio de sesión

Lista de verificación de desvinculación:

☐ Deshabilitar cuenta en [nombre del directorio] (gestiona todas las aplicaciones SSO)
☐ Comprobar Passwork para las credenciales de aplicaciones sin SSO
☐ Desactivar manualmente las cuentas sin SSO:
   ☐ [Aplicación 1]
   ☐ [Aplicación 2]
☐ Transferir la propiedad de los recursos compartidos
☐ Confirmar que no queda ningún acceso

Entregable: Listas de verificación de incorporación y desvinculación listas para usar

Parte 7: Conectar dos aplicaciones más (60 minutos)

Repita la Parte 3 para dos aplicaciones críticas más. Al final, debería tener al menos tres aplicaciones usando SSO.

Orden de prioridad:

1. Correo/productividad (ya cubierto si usa Google/Microsoft como directorio)
2. Infraestructura en la nube (AWS, GCP, Azure)
3. Repositorio de código (GitHub, GitLab)
4. Comunicación (Slack, Teams)
5. Gestión de proyectos (Jira, Asana, Linear)

Entregable: Tres aplicaciones conectadas mediante SSO

Resumen del taller

Tras completar este taller, debería tener:

• Servicio de directorio configurado con su dominio
• Estructura de grupos que coincide con su organización
• Al menos 3 aplicaciones conectadas mediante SSO
• Cuentas de acceso de emergencia documentadas
• Listas de verificación de incorporación/desvinculación creadas
• Plan de migración para los usuarios restantes

Inversión de tiempo: ~4 horas ahora, ahorra más de 30 minutos por cada incorporación/baja para siempre.

Verificación: ¿está listo su directorio?

Fundamentos del directorio

• Elegido un directorio principal (Google Workspace, Microsoft 365, etc.)
• Todos los empleados tienen cuentas en el directorio
• Estructura de grupos creada (departamentos, roles)
• MFA aplicado para todos los usuarios

Conexiones SSO

• Identificadas qué aplicaciones admiten SSO
• Al menos 3 aplicaciones críticas conectadas mediante SSO
• Comprobado que el inicio de sesión SSO funciona correctamente
• Autenticación local deshabilitada donde sea posible

Aprovisionamiento y acceso

• La incorporación crea primero la cuenta de directorio
• La membresía de grupo determina el acceso a la aplicación
• La desvinculación deshabilita inmediatamente la cuenta de directorio
• Las aplicaciones sin SSO se rastrean por separado

Acceso de emergencia

• Existen cuentas de administrador locales de emergencia
• Credenciales de emergencia almacenadas en Passwork
• Acceso de emergencia probado en el último trimestre

Si puede marcar al menos 10 de estos 14 elementos, sus cimientos de directorio son sólidos.

Cómo explicarlo a la dirección

Si alguien pregunta por qué dedicó tiempo a esto:

"Centralizamos la gestión de usuarios en un directorio único con SSO. Ahora cuando alguien se incorpora, obtiene acceso a todo lo que necesita a través de una sola cuenta. Cuando se va, deshabilitamos esa cuenta y pierde el acceso a todo de inmediato. Sin más cuentas olvidadas en aplicaciones aleatorias, sin acceso huérfano. También significa mayor seguridad — podemos aplicar MFA y políticas de contraseñas en un solo lugar."

Versión corta: "Una cuenta por persona, un lugar para gestionar el acceso. Cuando alguien se va, activamos un interruptor y queda bloqueado de todo."

Qué sigue

Ahora tiene:

• Gestor de contraseñas y MFA (capítulo anterior)
• Directorio de usuarios centralizado con SSO

Próximo capítulo: inventario de SaaS y gestión de accesos — descubrir todas las aplicaciones que usa su empresa y mapear quién tiene acceso a qué.