Una identidad en todas las superficies: el argumento de gobernanza para SSO

Módulo 6 · Seguridad y gobernanza · Lección 4 de 6

Al terminar esta lección podrás guiar a un cliente en la configuración de SSO, elegir el modelo de aprovisionamiento adecuado y configurar los controles de acceso a nivel de red antes del lanzamiento.

Por qué importa la identidad

Sin SSO tienes cuentas de Claude. Con SSO, tienes una fuerza laboral gobernada.

SSO (SAML 2.0 u OIDC) enruta a todos los usuarios a través del proveedor de identidad del cliente. La captura de dominio (domain capture) asegura que todos los usuarios del dominio corporativo lleguen al espacio de trabajo correcto, sin cuentas personales sombra. El beneficio de gobernanza: una identidad, una pista de auditoría y un único flujo de baja. Cuando un desarrollador se va, su acceso a Claude se desaprovisiona junto con todo lo demás.

Para recordar

El SSO sin captura de dominio sigue dejando un hueco: los usuarios pueden acceder a Claude con cuentas personales del dominio corporativo. Activa la captura de dominio para cerrarlo.

Modelos de aprovisionamiento

SCIM es el valor predeterminado para producción, JIT sirve para empezar y el manual es solo para pilotos.

1. SCIM (recomendado)

Sincronización automática, dirigida por el IDP, de todo el ciclo de vida del usuario: aprovisionamiento, cambios de grupo y desaprovisionamiento. Escala a cualquier tamaño de equipo sin carga administrativa.

El factor decisivo: el desaprovisionamiento automatizado. Cuando alguien se va, su acceso lo revoca el IDP sin que nadie tenga que acordarse, exactamente lo que una revisión de seguridad quiere ver a escala.

2. Just-in-Time (JIT)

El usuario se crea automáticamente en el primer inicio de sesión SSO. Es sencillo de configurar, pero no tiene preaprovisionamiento ni gestión de grupos. Sirve para empezar, no para la gobernanza a escala.

La trampa: JIT crea cuentas pero no las elimina. No hay sincronización de grupos ni desaprovisionamiento. Está bien para empezar, pero deja el ciclo de vida a medio gestionar, así que planifica el paso a SCIM.

3. Manual

Invitaciones de asiento gestionadas por el administrador. Adecuado para pilotos de 20 a 50 usuarios. No es sostenible más allá de eso: pasa a SCIM antes del despliegue completo.

Dónde falla: cada alta y cada baja es una acción manual del administrador. Es viable para un piloto de 20 a 50 personas y una responsabilidad con cientos de usuarios, así que es un punto de partida, nunca el destino.

Patrón de despliegue de SCIM: piloto de 50 a 100 usuarios, monitorear durante 2 a 4 semanas, expandir por departamento y, después, a toda la organización. Ejecuta la configuración de identidad en paralelo con el diseño del piloto, no después de él.

flowchart LR
    P["Piloto<br/>50 a 100 usuarios"] --> M["Monitorear<br/>2 a 4 semanas"]
    M --> D["Expandir<br/>por departamento"]
    D --> ORG["Despliegue<br/>en toda la organización"]

Controles de red

IP allowlisting dice quién puede acceder a Claude. Las restricciones de tenant dicen a qué organización de Claude pueden acceder.

IP allowlisting (red)

Restringe el acceso a Claude a rangos de IP corporativos. Se aplica en el perímetro de red y es efectivo en entornos locales o protegidos por VPN.

Responde: «quién puede llegar a Claude en absoluto». Una petición desde fuera de los rangos corporativos nunca llega a conectarse. No dice nada sobre a qué organización inicia sesión; ese es el siguiente control.

Restricciones de tenant (red)

Impiden que los usuarios de la red corporativa inicien sesión en organizaciones de Claude no autorizadas. Bloquean el shadow AI incluso cuando el IP allowlisting está activo.

Responde: «a qué organización de Claude pueden acceder». Esto es lo que impide que un desarrollador en la red corporativa inicie sesión en un espacio de trabajo personal o no sancionado: el hueco de shadow AI que el IP allowlisting por sí solo deja abierto.

Captura de dominio (identidad)

Enruta automáticamente todos los inicios de sesión desde el dominio corporativo al espacio de trabajo corporativo de Claude. Cierra la brecha de las cuentas personales sin requerir configuración individual.

Por qué es la pieza que faltaba: el SSO por sí solo sigue permitiendo que alguien se registre con una cuenta personal en el correo corporativo. La captura de dominio obliga a que cada inicio de sesión del dominio corporativo entre en el espacio de trabajo gobernado. Es el hueco del que advierte el apartado «Por qué importa la identidad».

Seguridad de sesión (identidad)

Tiempo de expiración de sesión y intervalos de reautenticación configurables. Se define en la consola de administración junto con los demás controles de identidad.

En la práctica: los tiempos de expiración más cortos y la reautenticación periódica limitan el periodo durante el que una sesión secuestrada o desatendida sigue siendo útil. Es un control rutinario, pero los equipos de seguridad esperan verlo configurado de forma deliberada, no dejado en los valores predeterminados.

flowchart TB
    subgraph RED["Red"]
        IP["IP allowlisting<br/>quién puede llegar a Claude"]
        TEN["Restricciones de tenant<br/>a qué organización de Claude puede acceder"]
    end
    subgraph IDN["Identidad"]
        DOM["Captura de dominio<br/>enruta los inicios de sesión del dominio corporativo"]
        SES["Seguridad de sesión<br/>expiración y reautenticación"]
    end

Las restricciones de tenant van un paso más allá que el IP allowlisting: bloquean el acceso a la organización de Claude equivocada, no solo a Claude en sí. Ambas deben estar en el alcance de los despliegues empresariales en los que el shadow AI sea una preocupación.

Comprueba tu comprensión

Actividad: ¿qué modelo de aprovisionamiento encaja?

Responde como lo harías en una llamada de alcance. La recomendación sigue la misma lógica que aplicarías con un cliente.

1. ¿Cuántos usuarios cubrirá? Opciones: un piloto de 20 a 50 usuarios; un departamento (cientos); toda la organización (miles).

2. ¿Necesitas desaprovisionamiento automatizado y sincronización de grupos desde tu IDP? Opciones: sí, el ciclo de vida debe ser automatizado; todavía no, solo estamos empezando.

Ver respuesta

Respuesta según la combinación elegida:

• Ciclo de vida automatizado obligatorio (cualquier tamaño): SCIM. Debrief: «El desaprovisionamiento automatizado y la sincronización de grupos son exactamente lo que ofrece SCIM. JIT crea cuentas pero nunca las elimina, y el manual no puede seguirle el ritmo. Cuando la automatización del ciclo de vida es un requisito, SCIM es la respuesta, sin importar el tamaño.»
• Piloto de 20 a 50 usuarios, sin requisito de ciclo de vida: Manual. Debrief: «Un piloto de 20 a 50 usuarios sin requisito de ciclo de vida todavía no justifica la integración con el IDP. Las invitaciones manuales de asiento son el inicio más ligero, pero planifica el paso a SCIM antes de que el despliegue se expanda.»
• Departamento (cientos de usuarios), todavía no hay ciclo de vida automatizado: JIT. Debrief: «A escala de departamento, JIT da acceso rápido a las personas mediante SSO sin invitaciones manuales. Pero no tiene desaprovisionamiento, así que trátalo como un puente: pasa a SCIM a medida que el despliegue crece y la gobernanza del ciclo de vida importa.»
• Toda la organización (miles de usuarios), todavía no hay ciclo de vida automatizado: SCIM. Debrief: «A escala organizacional, el manual y JIT fallan: el manual por la carga administrativa y JIT por la falta de ciclo de vida. SCIM es el único modelo que gobierna miles de usuarios sin esfuerzo por usuario, incluso si todavía no has definido el desaprovisionamiento como requisito obligatorio.»

Actividad: ¿qué controles deben estar listos antes del lanzamiento?

FinCo tiene 1.800 desarrolladores, usa Okta como IDP y exige que todas las herramientas corporativas pasen por la VPN. El equipo de seguridad aprobó el piloto. Ahora el equipo de despliegue debe definir qué tiene que cumplirse antes de que un solo desarrollador use Claude Code en producción.

Antes de que cualquier desarrollador empiece a usar Claude Code en producción, ¿cuáles de los siguientes controles de identidad y acceso deben estar implementados? Selecciona todos los que correspondan.

• Identidad · SSO: SSO a través de Okta. Ruta: Consola de administración → ajustes de SSO.
• Identidad · dominio: captura de dominio. Ruta: Consola de administración → gestión de dominios.
• Aprovisionamiento: aprovisionamiento SCIM desde Okta. Ruta: Consola de administración → aprovisionamiento.
• Red: IP allowlisting hacia la VPN corporativa. Ruta: Consola de administración → controles de red.
• Posterior al lanzamiento · sesión: configuración del tiempo de expiración de sesión. Ruta: Consola de administración → ajustes de seguridad.
• Enfoque incorrecto · aprovisionamiento: enviar invitaciones de asiento manualmente a todos los desarrolladores. Ruta: Consola de administración → miembros.

Ver respuesta

• Identidad · SSO (SSO a través de Okta): correcta.
• Identidad · dominio (captura de dominio): correcta.
• Aprovisionamiento (SCIM desde Okta): correcta.
• Red (IP allowlisting hacia la VPN corporativa): correcta.
• Posterior al lanzamiento (expiración de sesión): no correcta, es un ajuste posterior al lanzamiento.
• Enfoque incorrecto (invitaciones manuales): no correcta.

Respuesta: SSO a través de Okta, captura de dominio, aprovisionamiento SCIM desde Okta e IP allowlisting hacia la VPN corporativa. Cuatro controles son obligatorios antes del lanzamiento. Los otros dos son ajuste posterior al lanzamiento (la expiración de sesión) o el enfoque de aprovisionamiento incorrecto a esta escala (las invitaciones manuales). Esta es la base de la Sección 4 del cuestionario de FinCo.

Ideas clave

• Con SSO, cada usuario se rastrea hasta el proveedor de identidad, con una pista de auditoría y un único flujo de baja. Sin captura de dominio sigue habiendo un hueco de cuentas personales.
• SCIM es el valor predeterminado para producción por su desaprovisionamiento automatizado; JIT sirve para empezar; el manual es solo para pilotos de 20 a 50 usuarios.
• El patrón de despliegue de SCIM es: piloto de 50 a 100 usuarios, monitoreo de 2 a 4 semanas, expansión por departamento y, después, a toda la organización.
• IP allowlisting controla quién puede llegar a Claude; las restricciones de tenant controlan a qué organización puede acceder; la captura de dominio enruta los inicios de sesión corporativos.
• Antes del lanzamiento, deben estar SSO, captura de dominio, SCIM e IP allowlisting. La expiración de sesión se trata como ajuste posterior al lanzamiento.

Siguiente: ZDR, retención personalizada y política de uso de datos