Superar la brecha de gobernanza

En el ámbito de los sistemas de datos modernos, Snowflake es la joya de la corona. Sin embargo, a medida que las Organizations crecen, gestionar quién tiene acceso a qué y, lo que es más importante, garantizar que se revoque dicho acceso, se convierte en un juego de cumplimiento normativo de alto riesgo. Si ha confiado exclusivamente en los conectores SCIM preconfigurados de Okta, probablemente se haya dado cuenta de que solo lo llevan a medias. Pueden crear un usuario, pero tienen dificultades para gestionar el complejo ciclo de vida de los roles de Snowflake y la recuperación de licencias.

Esta guía explora una sofisticada arquitectura de "tres flujos" que utiliza Okta Identity Governance (OIG) y Okta Workflows (actualizado en abril de 2026) para automatizar la "última milla" de la administración de Snowflake.

El problema: ¿Por qué los conectores de integración de Okta se quedan cortos?

La integración estándar entre Okta y Snowflake se centra normalmente en el aprovisionamiento de usuarios. Si bien esto resuelve la pregunta “¿Es esta persona un usuario?”, falla en dos aspectos críticos:

1. Gestión granular de roles: el acceso a Snowflake se define mediante roles (por ejemplo, SYSADMIN, DATA_ENGINEER). Los conectores estándar no activan de forma nativa comandos SQL específicos de cada rol en respuesta a las solicitudes de acceso de la OIG.
2. Limpieza de permisos: Cuando caduca una solicitud de OIG o se desvincula a un usuario de una aplicación, el registro del usuario suele persistir en Snowflake. Esto da lugar a cuentas “zombi” que consumen licencias y amplían su superficie de ataque de seguridad.

La solución consiste en utilizar Okta Workflows como motor de orquestación que escucha los eventos de OIG y habla el lenguaje de Snowflake.

Guía de configuración de requisitos

Antes de llegar a la solución propuesta de Okta OIG y Workflows, necesitamos realizar algunos cambios de configuración en Snowflake, OIG y Slack para usar el paquete de flujos de trabajo (Snowflake Delegated Flow, Unassigned Entitlements y Usuario Unassigned Cleanup). Debe completar estos pasos de configuración específicos en las cuatro plataformas. A continuación se presenta la guía completa para configurar los requisitos básicos:

Requisitos de Snowflake

Snowflake sirve como sistema de destino para la gestión de roles y usuarios.

1. Cree un rol de aprovisionador: cree un rol específico (por ejemplo, OKTA_PROVISIONER) que Okta asumirá para realizar acciones.

2. Configurar la integración SCIM: Cree una integración de seguridad SCIM para permitir que Okta se comunique con Snowflake.

3. Generar token SCIM: Genere el token de autorización para pegarlo en Okta.

4. Política de red: Asegúrese de que la política de red de Snowflake permita el tráfico entrante desde direcciones IP de Okta.

Requisitos de Okta (elementos básicos y Workflows)

Okta es el proveedor central de identidad y el motor que impulsa la automatización.

Integración SCIM de la aplicación Snowflake

1. Agregue la aplicación Snowflake desde Okta Integration Network.
2. En la pestaña Aprovisionamiento, habilite la integración de la API y pegue el token SCIM de Snowflake.
3. Habilitar la creación de usuarios, la actualización de atributos de usuario y la desactivación de usuarios.

Autorización e importación de Workflows conectores

El núcleo del sistema se basa en dos componentes principales: Okta Access Requests y Okta Workflows. Okta Workflows se utiliza para crear funciones empresariales específicas, como el aprovisionamiento manual, el envío de notificaciones o la creación de tickets de soporte. Estos flujos de trabajo están configurados como flujos delegados, que pueden ser utilizados por las Access Requests de Okta. Siga estos pasos para habilitar estos Workflows:

1. Autorizar el acceso

• Autorice el conector Snowflake en la consola de Workflows utilizando el token de acceso de la aplicación Snowflake. Esto nos ayudará a realizar llamadas a la API de la aplicación Snowflake.
• Conector Okta: Asegúrese de que la conexión esté autorizada.

• Conceda el ámbito okta.governance.entitlements.manage a la aplicación Okta Workflows OAuth en la consola de administración de Okta (Aplicaciones > Aplicación Okta Workflows OAuth).

2. Importar paquete de Workflows

Nota: Para completar este paso, deberá descargar este archivo de paquete de flujo de trabajo.

Importe el paquete de Workflows adjunto en la consola de administración -> Workflows -> Flujos: Snowflake Entitlement Management - Okta Workflows:

• Cree una nueva carpeta y nómbrala “Snowflake Entitlement Management”, y luego seleccione “Importar” en el menú desplegable.

• Existen tres Workflows principales: flujo delegado de Snowflake (Asignación), Desasignación de derechos y usuario desasignado de Snowflake. En la siguiente sección, explicaremos en detalle qué hace cada flujo de trabajo. 
  

  Habilite estas conexiones de aplicación en cada uno de los tres flujos (por ejemplo, la tarjeta Snowflake en el flujo “Desasignar derechos”).

3. Configurar el flujo delegado

Para utilizar el flujo delegado de Snowflake, primero debe habilitar Okta Workflows en Access Requests. Esto garantiza que, tras la aprobación de una solicitud de acceso para la aplicación Snowflake, el flujo delegado de Snowflake active una solicitud de API para asignar los permisos.

• Habilite esta opción en Configuración -> Artículo destacado -> Acciones de Okta Workflows en Access Requests

• Cree un rol y Recursos personalizados para permitir que Access Requests vea y ejecute los Workflows disponibles.

• Cree un conjunto de Recursos y asígnele Workflows.

• Vuelva al conjunto de recursos delegados para asignar los permisos de administrador.

• En Identity Governance, vaya a Access Requests -> Settings -> Recursos -> Workflows para confirmar que los flujos de trabajo delegados estén habilitados para ejecutarse desde las solicitudes de acceso. Si todo se ejecutó correctamente, verá que aparecen los “Workflows delegados”.

4. Cree un hook de evento

Configure un hook de evento para enviar datos de eventos desde Okta al extremo de API en el flujo delegado cuando ocurra un evento de OIG:

• Para crear un nuevo hook de evento, diríjase a la pestaña “Hooks de eventos” en “Workflows”.

Ahora, asegúrese de que el registro de sistema detecte un evento OIG de “actualización de derechos de usuario en un recurso” y lo envíe a la tarjeta del extremo de API asignando la URL de invocación del flujo de trabajo de desasignación de derechos en el campo URL del extremo y, a continuación, seleccionando ese evento en el hook de evento:

• Vaya al flujo de trabajo “Desasignar derechos” -> configuración del extremo.

• Copie la URL del extremo y péguela en “URL del extremo” del nuevo hook de evento.

• En el hook de evento, seleccione “Se actualizaron los derechos del usuario en un recurso”.

• Una vez configurado el hook de eventos, podremos probarlo en la pestaña “Vista previa”.

Requisitos de Okta Identity Governance (OIG)

OIG proporciona la capa de autorización granular utilizada en el flujo de sincronización.

1. Habilitar el motor de gobernanza: Asegúrese de que el motor de Okta Identity Governance esté habilitado para su organización.
2. Habilitar Entitlement Management: vaya a la aplicación Snowflake en Okta > pestaña Governance y haga clic en “habilitar Entitlement Management”. Antes de habilitar o deshabilitar Entitlement Management, primero debe deshabilitar el aprovisionamiento.

3. Configure permisos personalizados en la aplicación Snowflake -> Gobernanza. Como se mencionó anteriormente, los permisos de Snowflake no se completan automáticamente mediante el conector de Okta. Por lo tanto, tendremos que configurar roles y permisos personalizados.
   
   Estos son los roles que existen en la aplicación Snowflake:

Debemos hacer coincidir estos roles en la plataforma Okta: una vez que coinciden, estos roles (como ORGADMIN o SYSADMIN) se convierten en objetos “solicitables”, lo que los hace visibles para los usuarios dentro del catálogo de solicitudes de acceso.

• Vaya a la pestaña Gobernanza.

• Agregar derecho.

• Agregue un derecho llamado “ROLES”.

• Agregar roles de usuario, que utilizaremos en las solicitudes de acceso.

Una vez creados, así es como se verán:

• Cree un paquete para cada rol.

Cuando haya terminado de crear los paquetes, así es como se verá:

• Utilice estos paquetes para crear una solicitud de acceso para cada rol en la pestaña Access Requests de la aplicación Snowflake.

• Desplácese hasta la parte inferior y seleccione Secuencia de aprobación -> Seleccionar secuencia.

• Edite la secuencia “Justificación comercial”.

• Justo debajo del paso “Aprobación para el gerente del solicitante”, haga clic en “+” para agregar un nuevo paso del flujo de trabajo en la secuencia.

• Agregue un paso al Workflows y Select el Workflows delegado que importamos del paquete de Workflows.

• Una vez añadida, cambie el nombre de la secuencia a “Secuencia de aprobación de Snowflake” y guárdela.

• Seleccione la “Secuencia de aprobación de Snowflake” que acabamos de guardar para llamar al flujo delegado de Snowflake durante el proceso de solicitud de acceso.

• Habilitar las solicitudes de acceso para cada rol.

• Vaya al panel de control del usuario final y seleccione Solicitar acceso -> Snowflake para realizar una verificación final de que el usuario puede solicitar estos roles.

• Deberías ver listados todos los roles que los usuarios pueden solicitar.

Requisitos de Slack

Slack proporciona la capa de notificaciones para los Workflows.

1. Ámbitos y permisos: El usuario que autoriza el conector de Slack en Okta Workflows debe tener permiso para agregar aplicaciones al espacio de trabajo.
2. Autorización de la aplicación: Autorice la aplicación Okta Workflows en su espacio de trabajo de Slack.
3. ID del canal: Identifique el ID específico del canal de Slack (por ejemplo, #security-alerts o #it-ops) donde el flujo de trabajo debe publicar los mensajes. 

Ahora que se han cumplido los requisitos fundamentales, procederemos a desglosar el paquete de Workflows y a detallar la configuración de la arquitectura.

La arquitectura: un análisis profundo de la solución de tres Workflows

En esta sección, desglosaremos la función de cada uno de los tres Workflows principales:

1. Flujo delegado de Snowflake (asignación) 
2. Anular la asignación de derechos 
3. Desasignar usuario de Snowflake

Vea: cómo usar OIG y Workflows para administrar roles en Snowflake

Este video muestra cómo utilizar OIG y Workflows para gestionar los roles de Snowflake a gran escala sin las limitaciones de los conectores de integración tradicionales. Descubra cómo esta integración automatiza tareas, protege los datos y elimina la brecha de gobernanza, al tiempo que reduce el riesgo de error humano.

1. El flujo de asignación delegada: la “puerta de entrada”

Este flujo está diseñado para la administración delegada, lo que permite a los administradores activar la asignación de roles sin tener que acceder a la consola de Workflows.

• Lógica y puertas de seguridad: El flujo comienza tomando un userEmail y un requestedRole. Antes de actuar, realiza una comprobación readUser en Okta y una comprobación getAssignedUserForApplication para verificar el estado actual del usuario.
• El requisito de “aprovisionado”: una tarjeta “Continuar si” actúa como un guardián, asegurando que el estado del usuario en la aplicación Snowflake sea específicamente APROVISIONADO.
• Para evitar condiciones de carrera: implementamos una tarjeta de “Espera” de cinco segundos. Durante las pruebas, descubrimos que Snowflake a veces necesita unos segundos para registrar un nuevo usuario antes de poder aceptar un comando GRANT ROLE.
• Ejecución: Una vez validado, utiliza la tarjeta “Otorgar rol al usuario” de Snowflake y notifica al equipo a través de un canal de Slack.

Flujo delegado: tarjetas de asignación de roles de usuario 

1. INICIO: evento de flujo delegado

   1. Entradas: requestedRole, userEmail, AccessLevelName.

2. Okta - Leer usuario

   1. Recupera los detalles del perfil del usuario (nombre, apellido) utilizando el correo electrónico proporcionado.

3. Cadena - Concatenar

   1. Combina los nombres de usuario para fines de registro.

4. Control - Esperar

   1. Pausa el flujo durante 5 segundos para permitir que se complete el aprovisionamiento de etapa inicial.

5. Okta - Obtener usuario asignado para la aplicación

   1. Comprueba el estado de asignación del usuario específico para la aplicación Snowflake.

6. Control - Continuar si

   1. Condición: Proceda únicamente si el estado es PROVISIONADO.

   2. De lo contrario: Detenerse con el error "Error al otorgar un rol al usuario".

7. Snowflake - Otorgar rol al usuario

   1. Ejecuta la asignación de roles en Snowflake.

8. Cadena - Concatenar

   1. Crea el mensaje de éxito para Slack.

9. FIN: Slack - Enviar mensaje al canal

   1. Publica una confirmación: “[Usuario] ha sido asignado correctamente al rol de [Rol]”.

2. Desasignación de derechos: integración de la API de OIG

Este es el “cerebro” de la operación. Gestiona la compleja tarea de revocar roles específicos cuando se deniega o expira una concesión de OIG.

• El “Hilo Dorado” (grantId): Cuando la OIG activa una revocación, envía un webhook al extremo de API de este flujo. Usamos una tarjeta “Object Pick” para extraer el grantId de lo más profundo del JSON: data.events.0.debugContext.debugData.grantId.
• La devolución de llamada de la API de OIG: el webhook inicial a menudo carece del nombre de rol específico. El flujo utiliza una acción de API personalizada para llamar a la API de OIG: /governance/api/v1/grants/{{grantId}}?include=full_entitlements.
• Analizando derechos anidados: usando las tarjetas “At” y “Get”, el flujo navega por la lista devuelta para encontrar el nombre de rol exacto ubicado en values.0.name.
• La compuerta lógica “DENEGAR”: para evitar revocaciones accidentales durante los ciclos de aprobación, una tarjeta “Continuar si” verifica que la acción de OIG sea exactamente DENEGAR.

Anular la asignación de tarjetas de flujo de derechos 

1. INICIO: extremo de API (Webhook)

   1. Recibe datos del cuerpo que contienen información sobre la concesión y el destino.

2. Objeto - Obtener varios (Seleccionar)

   1. Extrae el grantId y el objeto target de los datos del evento.

3. Objeto - Obtener

   1. Extrae el Alternate ID (ID de usuario) del objeto de destino.

4. Okta - Leer usuario

   1. Recupera el perfil completo del usuario identificado.

5. Cadena - Concatenar

   1. Crea una URL relativa para la API de IGA: /governance/api/v1/grants/[grantId]?include=full_entitlements.

6. Okta IGA - Acción API personalizada

   1. Realiza una solicitud GET para recuperar todos los detalles de la concesión específica.

7. Control - Continuar si

   1. Condición: Proceda únicamente si la action es "DENY" (lo que indica una solicitud de eliminación).

8. Lista - En

   1. Recupera el derecho específico de la lista devuelta.

9. Objeto - Obtener

   1. Extrae el nombre del rol del objeto de autorización.

10. Concatenar - Nombre + Apellido

    1. Crea un nombre de usuario a partir del nombre y apellido del usuario para asignarlo en Snowflake.

11. Snowflake - Revocar rol a un usuario

    1. Elimina el rol del usuario en Snowflake.

12. Concatenar - Salida de Slack

    1. Crea un mensaje para mostrar en Slack.

13. FIN: Slack - Enviar mensaje al canal

    1. Publica la confirmación: “[Usuario] fue desasignado correctamente del rol [Rol]”.

3. Desvinculación completa: dar de baja al usuario

Cuando se elimina por completo a un usuario de la aplicación Snowflake en Okta, no basta con revocarle los roles; es necesario eliminar al usuario en sí para recuperar la licencia.

• El desencadenante: El flujo se inicia cuando se desvincula a un usuario de la instancia de la aplicación Snowflake en Okta.
• Procesamiento asíncrono: utiliza un bucle Async Each para procesar la desasignación, llamando a un flujo auxiliar por cada usuario eliminado.
• El acto final: el flujo auxiliar ejecuta el comando Drop User en Snowflake. Esto garantiza que el usuario sea eliminado por completo del entorno de Snowflake, automatizando una tarea que normalmente requiere intervención manual en SQL.

Tarjetas de flujo de desvinculación 

Flujo principal

1. INICIO: Okta - Usuario no asignado a la aplicación

   1. Supervisa los eventos application.user_membership.remove para la aplicación Snowflake.

2. Lista - Para cada (Async Each)

   1. Envía a cada usuario no asignado al flujo auxiliar para su procesamiento.

Flujo de ayuda

1. INICIO: evento invocable

   1. Recibe datos de usuario del flujo principal.

2. Objeto - Expandir

   1. Extrae el Alternate ID (normalmente el nombre de usuario).

3. Copo de nieve - Usuario de Drop

   1. Elimina la cuenta de usuario en Snowflake.

4. FIN: Slack - Enviar mensaje al canal

   1. Notifica al equipo que el usuario de Snowflake ha sido dado de baja.

Prueba de la configuración de OIG y Workflows

Probando la “Solicitud de acceso a rol” 

La solicitud de acceso (acción del usuario)

1. Inicie sesión como usuario de prueba estándar. Navegue al Panel de usuario final de Okta > Solicitar acceso.
2. Envíe una solicitud para el tipo de solicitud “Rol de Snowflake”. Seleccione el rol específico (por ejemplo, USERADMIN). 
3. Verifique el historial de solicitudes de acceso para asegurarse de que la solicitud se creó y se asignó al aprobador correcto (gerente).

Aprobación y aprovisionamiento (acción del administrador/gerente)

1. Inicie sesión como administrador aprobador y haga clic en “Aprobar”.
2. Enviar el rol a Snowflake: OIG Approval → Okta Assigns Entitlement to User → Okta SCIM.
3. En Okta, vaya al perfil del usuario > Aplicaciones > Snowflake para confirmar que el rol aparece en “Permisos”.
4. Realice comprobaciones similares en Snowflake para verificar que al usuario se le haya asignado el rol adecuado.

Ahora el usuario debería poder iniciar sesión en Snowflake y ver el rol que se le ha asignado.

Prueba de la revocación de derechos 

Revocación de derechos (medida de gobernanza)

Existen dos maneras de revocar el derecho al rol de Snowflake:

1. Navegue a Identity Governance > Access Certifications (o al perfil del usuario).
2. Navegue a Aplicaciones > Snowflake > Asignaciones y haga clic en Test_user > Administrar derechos

Flujo de ejecución

1. El evento de la OIG activa el webhook de la API Unassign Entitlements.
2. Inicio del flujo de trabajo: El flujo recibe el grantId y target (Usuario).
3. Llamada a la API de IGA: El flujo de trabajo llama a /governance/api/v1/grants/[id] para verificar que la action sea DENY.
4. Revocación en Snowflake: el flujo de trabajo ejecuta la tarjeta Revoke Role from the usuario en Snowflake.
5. Auditoría de Slack: Se envía un mensaje al canal de TI.

Criterios de verificación y éxito

1. Historial de Workflows: abra el historial del flujo de desasignación de derechos.
   1. Verificación de éxito: Cada tarjeta (Selección de objeto, API IGA, Revocación de Snowflake) debe tener una marca de verificación verde.
2. En Snowflake, ejecute SHOW GRANTS TO USER "TEST_USER";. El rol debe desaparecer.
3. En Slack, confirme el mensaje: [User] was successfully unassigned from the role [Role].

Probando la limpieza de “Eliminar usuario” para la desvinculación

1. Desvincule al usuario de prueba de toda la aplicación Snowflake en Okta.
2. Flujo de ejecución: Okta Unassignment → Parent Flow: usuario Unassigned → Helper Flow: Drop usuario.
3. En Okta, confirme que el usuario ya no aparece en la lista de asignaciones de la aplicación Snowflake.
4. En Snowflake, ejecute SHOW USERS LIKE 'TEST_USER%';. El usuario no debería devolver ningún resultado (descartado).
5. En Slack, confirme la notificación “El usuario de Snowflake ha sido eliminado”.

Lecciones aprendidas al automatizar los Workflows de OIG

La creación de esta automatización reveló varios matices cruciales en la forma en que OIG y Snowflake se comunican:

Mapeo de estado y acción

Uno de los errores más frecuentes que encontramos fue que el flujo se activaba en la etapa incorrecta del ciclo de vida de la gobernanza. Establecimos un mapeo estricto para las compuertas Continue If:

Formato de cadenas para Snowflake

Snowflake distingue entre mayúsculas y minúsculas y, a menudo, espera un formato de nombre de usuario específico. Utilizamos tarjetas de concatenación para fusionar los campos firstName y lastName de Okta y que coincidieran exactamente con los requisitos de user_name de Snowflake, por ejemplo: JOHNDOE

El estado de espera

Sin la tarjeta Wait, el flujo de “Asignación delegada” fallaría intermitentemente con un error de “Usuario no encontrado” de Snowflake, incluso si el usuario acababa de ser creado. Un retraso de cinco segundos solucionó el 100 % de estos errores por condición de carrera.

Lograr una verdadera Identity Governance

Al ir más allá del conector estándar y utilizar la API de Okta Identity Governance combinada con Workflows, se crea un sistema de circuito cerrado que ofrece importantes beneficios en materia de gobernanza de identidades:

• Seguridad: Los roles se revocan instantáneamente cuando expiran las autorizaciones.
• Eficiencia de costos: Los usuarios de Snowflake se dan de baja cuando ya no son necesarios y las licencias se recuperan automáticamente.
• Cumplimiento normativo: Cada acción, desde la solicitud de la OIG hasta el comando SQL de Snowflake, queda registrada y es auditable en el historial de ejecución del flujo de trabajo.

Pruébalo gratis: Descubre las ventajas de automatizar procesos de identidad complejos a gran escala con Okta Identity Governance and Workflows. Comienza tu prueba gratuita de 30 días.