¿Qué es una cuenta de servicios gestionados para desarrolladores?

Última actualización
Guardar como PDF

A los desarrolladores que creen aplicaciones que utilicen componentes de conexión de datos les recomendamos que utilicen la nueva función Developer Managed Service Accounts (DMSA) como método simplificado para proporcionar a los administradores de Procore la capacidad de instalar y aprovisionar fácilmente las aplicaciones de conexión de datos en sus cuentas de empresa. La función DMSA permite a los desarrolladores especificar los permisos exactos de la herramienta a nivel de empresa y de proyecto que se requieren para que su aplicación se ejecute correctamente en la plataforma Procore. Los administradores de la empresa definen a qué proyectos puede acceder la aplicación utilizando esos permisos. Los desarrolladores utilizan cuentas DMSA para ofrecer una alternativa más cómoda y segura a las cuentas de servicio tradicionales. Los administradores de la empresa se benefician de las DMSA gracias a una mejor gestión de las aplicaciones y una mayor visibilidad del uso de las mismas.

Todas las cuentas de servicio tradicionales se extinguirán el 31 de diciembre de 2024.

Las cuentas de servicio tradicionales quedaron obsoletas el 9 de diciembre de 2021. A partir del 1 de octubre de 2024, ya no permitiremos la creación de nuevas Cuentas de Servicio Tradicionales. Las cuentas de servicio tradicionales existentes continuarán funcionando hasta el 31 de diciembre de 2024.

De acuerdo con esta línea de tiempo, los desarrolladores de aplicaciones de conexión de datos que actualmente usan cuentas de servicio tradicionales deben actualizar sus aplicaciones para usar Developer Managed Service Accounts, y los clientes deberán instalar estas aplicaciones actualizadas antes de la fecha de puesta de sol. Todas las aplicaciones de conexión de datos no migradas antes de la fecha de caducidad dejarán de funcionar. Cualquier aplicación que aparezca en el App Marketplace de Procore que no utilice un método compatible para acceder a la API de Procore se eliminará antes de la fecha de caducidad. Consulte Migración de aplicaciones de conexión de datos para usar DMSA para obtener información adicional.

Beneficios de usar cuentas de servicio administradas por desarrolladores (DMSA)

Hay una serie de beneficios que se pueden obtener al usar DMSA sobre las cuentas de servicio tradicionales:

Administración simplificada de aplicaciones: los administradores de la empresa instalan y administran las DMSA utilizando la función Administración de aplicaciones en la herramienta Administrador de la empresa. El usuario de directorio asociado con la DMSA se crea automáticamente como parte del proceso de instalación de la aplicación. Con las cuentas de servicio tradicionales, los administradores de la empresa tienen que crear y administrar manualmente la cuenta y sus permisos de acceso, lo que requiere una comunicación y coordinación adicionales con el desarrollador de terceros para instalar y configurar la aplicación.
Gestión de permisos más segura: todos los permisos requeridos de la herramienta de nivel de empresa y de proyecto para una aplicación DMSA determinada se definen en un manifiesto de aplicación que se aplica a la cuenta de su empresa durante el proceso de instalación. Cuando una aplicación incorpora nuevas funciones y lanza una versión actualizada, el desarrollador puede solicitar nuevos permisos a través del proceso de actualización para que se revisen y aprueben.
Control de acceso a proyectos mejorado: durante el proceso de instalación y configuración, los administradores de la empresa seleccionan exactamente qué proyectos se permite utilizar a la aplicación DMSA. Con las cuentas de servicio tradicionales, el administrador de la empresa configura y administra manualmente el acceso al proyecto, lo que puede llevar mucho tiempo y ser costoso, y puede ser menos seguro como se describe a continuación.
Mejor información sobre el uso de la aplicación: debido a que las DMSA se instalan mediante la administración de aplicaciones, los administradores de la empresa tienen visibilidad del uso de la aplicación en forma de métricas de la aplicación, como la cantidad de solicitudes de API, qué usuarios han instalado y/o utilizado una aplicación, qué proyectos pueden usar una aplicación y más. Con las cuentas de servicio tradicionales, tales métricas no se recopilan ni son accesibles.

Riesgos asociados con las cuentas de servicio tradicionales

La instalación y el uso de aplicaciones que utilizan cuentas de servicio tradicionales conlleva los siguientes riesgos:

Transmisión no segura de credenciales de API: debido a que un administrador de la empresa crea manualmente una cuenta de servicio tradicional en Procore, el conjunto único de credenciales de API generadas (client_id y client_secret) debe devolverse al desarrollador para completar con éxito la configuración de integración. Desafortunadamente, la transmisión de esta información confidencial puede ocurrir a través de medios no seguros, como correo electrónico, mensaje de texto, etc., lo que deja los datos de la empresa potencialmente vulnerables.
Falta de datos de uso: si una cuenta de servicio tradicional se ve comprometida, es difícil rastrear dónde se está utilizando porque la cuenta no genera datos de uso.
El requisito de configurar y administrar manualmente los permisos asociados con una cuenta de servicio tradicional puede ser propenso a errores y conducir a un comportamiento inesperado de la aplicación.

¿En qué se diferencia una DMSA de una cuenta de servicio tradicional?

Estas son algunas de las principales diferencias entre las DMSA y las cuentas de servicio tradicionales.

	Cuenta de servicios gestionados para desarrolladores	Cuenta de servicio tradicional
Creación de cuentas	Se crea automáticamente un usuario de directorio asociado a DMSA en la herramienta Directorio de empresa y/o proyecto.	Una cuenta de servicio tradicional debe crearla y gestionarla manualmente un administrador de la empresa.
Autorización	Se utiliza un único conjunto de credenciales (client_id, client_secret) para acceder a todas las empresas en las que está instalada la aplicación.	Cada cuenta de servicio creada en una empresa por un administrador tiene un conjunto único de credenciales, por lo que es necesario coordinar manualmente con el desarrollador para que la integración sea satisfactoria.
Permisos	Los permisos necesarios los define el desarrollador en el manifiesto de la aplicación y se aplican automáticamente durante la instalación.	Los permisos para cada cuenta de servicio debe configurarlos manualmente un administrador de la empresa.
Configuración del proyecto	Durante la instalación, puede seleccionar los proyectos en los que se permite ejecutar la aplicación DMSA. Una vez instalada la aplicación, puede añadir o eliminar los proyectos permitidos según sea necesario.	El acceso al proyecto y debe ser configurado y gestionado manualmente por el administrador de la empresa.
Gestión de aplicaciones	Las aplicaciones compatibles con DMSA se instalan fácilmente desde App Marketplace o a modo de instalación personalizada. Para la desinstalación/reinstalación, se utiliza la herramienta de administración de la empresa (App Management).	Todos los aspectos de la instalación y gestión de cuentas de servicio tradicionales debe gestionarlos manualmente un administrador de la empresa.

¿Qué veré en mi cuenta después de instalar una aplicación que utiliza una DMSA?

Durante el proceso de instalación, se puede crear un nuevo registro de usuario en la herramienta Directorio de empresa y/o proyecto que representa la DMSA. El nombre del contacto DMSA sigue un formato distinto con el nombre de la aplicación convertido en minúsculas y separado por guiones seguido por un identificador generado aleatoriamente de ocho caracteres. Por ejemplo, la instalación de la aplicación My DMSA Test App crearía el usuario my-dmsa-test-app-469b1f7f en el Directorio de empresa. Es importante que no edite ni elimine los usuarios de directorio creados por las instalaciones de la aplicación DMSA, ya que esto puede causar problemas con el funcionamiento de la aplicación.

Implicaciones de conceder permisos de administrador de directorios a aplicaciones

Se advierte encarecidamente a los administradores de la empresa que no otorguen acceso de administrador a la herramienta Directorio de nivel de empresa a las aplicaciones que utilizan DMSA o cuentas de servicio tradicionales. Las aplicaciones con este nivel más alto de acceso tienen la capacidad de realizar cambios que pueden afectar negativamente a todas las herramientas en todo un proyecto o a todos los proyectos en toda la cuenta de Procore de su organización. Si bien algunas aplicaciones pueden requerir esto para funcionar, recomendamos revisar a fondo la necesidad de la integración y comprender el impacto antes de permitirlo.

Comprender la autenticación de la API de Procore

Las aplicaciones creadas en la plataforma Procore utilizan el marco de autorización OAuth 2.0 estándar del sector para la autenticación con la API. La API de Procore admite los siguientes dos tipos de concesión de autorización o flujos de autenticación:

Credenciales del cliente (DMSA y cuentas de servicio tradicionales): la mayoría de las aplicaciones de conexión de datos utilizan este tipo de concesión para la autenticación con la API. Con el tipo de concesión de credenciales de cliente, se utiliza un solo conjunto de credenciales de API (a través de una cuenta DMSA o de servicio tradicional) para autenticarse con la API de Procore. El acceso a herramientas y datos en la plataforma Procore se rige por la configuración de permisos asociada con esa cuenta. Como resultado, los desarrolladores y administradores de la empresa pueden especificar las herramientas y proyectos exactos a los que una aplicación tiene acceso. Este es el enfoque preferido para las aplicaciones de conexión de datos. Para obtener información adicional sobre el tipo de concesión de credenciales de cliente, consulte Uso del tipo de concesión de credenciales de cliente de OAuth 2.0.
Código de autorización (flujo de inicio de sesión del usuario): el servidor web y las aplicaciones basadas en navegador a menudo utilizan este tipo de concesión para la autenticación con la API. Con el tipo de concesión de código de autorización, la aplicación opera en nombre del usuario que ha iniciado sesión al autenticarse con la API de Procore. En este escenario, la aplicación asume los permisos del usuario conectado y tiene acceso a cualquier herramienta, proyecto o datos con los que se permita interactuar a ese usuario en particular. Debido a que la administración de permisos puede ser desafiante en este tipo de concesión, no se recomienda para aplicaciones de conexión de datos. Para obtener información adicional sobre el tipo de concesión de código de autorización, consulte Flujo de concesión de código de autorización OAuth 2.0.

Los administradores de empresas de Procore son en última instancia responsables de gestionar los permisos de sus usuarios de directorio independientemente del tipo de concesión de autorización utilizado por una integración: authorization_CODE (permisos de usuario conectado) o client_Credentials (permisos de cuenta de servicio/DMSA).

Modelo de seguridad de responsabilidad compartida

Como proveedor de Software como Servicio (SaaS), Procore sigue un modelo de responsabilidad compartida en el contexto de la seguridad de la plataforma.

Los clientes son responsables de las integraciones que instalan, los permisos que aprueban para que esas integraciones usen y cualquier cambio que realicen en los usuarios del directorio (DMSA o tradicionales) asociados con esas integraciones fuera de lo que Procore proporciona.
Los socios/desarrolladores son responsables del manejo de las credenciales, el código que llama a la API y lo que hacen con los datos. El cliente proporciona las claves a los Desarrolladores para que las utilicen los Desarrolladores.
Procore es responsable de proporcionar a los desarrolladores un medio para solicitar permisos a los clientes a través de OAuth y a los clientes la capacidad de instalar y administrar aplicaciones.

Fin de las cuentas de servicio tradicionales