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.
All Traditional Service Accounts will sunset on March 18, 2025.
Traditional Service Accounts were deprecated on December 9, 2021. Beginning January 21, 2025, we will no longer allow the creation of new Traditional Service Accounts. Existing Traditional Service Accounts will continue to function until March 18, 2025.
In accordance with this timeline, developers of data connection applications that currently use Traditional Service Accounts are required to update their applications to use Developer Managed Service Accounts, and customers will be required to install these updated applications before the sunset date. All data connection applications not migrated by the sunset date will cease to function. Any application listed on the Procore App Marketplace that is not using a supported method for accessing the Procore API will be removed by the sunset date. See Migrating Data Connection Applications to Use DMSAs for additional information.
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.
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.
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 |
|
|
| Autorización |
|
|
| Permisos |
|
|
| Configuración del proyecto |
|
|
| Gestión de aplicaciones |
|
|
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.
La gestión de permisos para una cuenta de servicio gestionada por desarrolladores (DMSA) implica una cuidadosa consideración para garantizar el funcionamiento de la aplicación y la seguridad de la cuenta. A continuación, se presentan las buenas prácticas y consideraciones importantes para gestionar los permisos de forma eficaz.
Utilice la pestaña Permisos para la pertenencia al proyecto : para gestionar el acceso al proyecto DMSA, incluida la adición o eliminación de pertenencias al proyecto, utilice la pestaña Permisos dentro de la aplicación, en Gestión de aplicaciones. Esta opción está disponible para los administradores de la empresa.
Reconfiguración de permisos al actualizar o reinstalar la aplicación : cada vez que se actualiza o reinstala una aplicación, los administradores de la empresa deben reconfigurar la lista de proyectos permitidos. Los proyectos futuros que requieran acceso DMSA también deben añadirse manualmente a la lista de permitidos.
Uso de la herramienta Directorio para plantillas de permisos . Algunos administradores utilizan la herramienta Directorio con una plantilla de permisos para agilizar la gestión de DMSA:
Evite las actualizaciones manuales de los permisos DMSA : por lo general, se desaconseja ajustar manualmente los permisos DMSA dentro de la herramienta Directorio, ya que puede generar incoherencias y complicar la gestión de cuentas.
Limitar el acceso de DMSA a la herramienta Directorio de nivel de empresa : evite otorgar acceso de nivel administrador a la herramienta Directorio de nivel de empresa para el usuario DMSA. Este nivel de acceso permite cambios en múltiples proyectos y herramientas en su cuenta de Procore, lo que podría afectar los flujos de trabajo de su organización. Permita este nivel de acceso solo si es absolutamente necesario para la integración y asegúrese de comprender completamente las implicaciones.
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 dos tipos de concesión de autorizaciones o flujos de autenticación siguientes:
Código de autorización (flujo de inicio de sesión de usuario) : el servidor web y las aplicaciones basadas en navegador suelen utilizar 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 funciona en nombre del usuario conectado actualmente cuando se autentica con la API de Procore. En este escenario, la aplicación asume los permisos del usuario que ha iniciado sesión y tiene acceso a cualquier herramienta, proyecto o dato con el que ese usuario en particular pueda interactuar. Dado que la gobernanza de permisos puede ser un reto con 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 de 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).
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.