Para los desarrolladores que crean aplicaciones de construcción de aplicaciones de conexión de datos, recomendamos aprovechar la nueva función de cuentas de servicio administradas para programadores (DMSA) como un enfoque simplificado para proporcionar a los administradores de Procore la habilidad para instalar y proporcionar fácilmente aplicaciones de conexión de datos en sus cuentas de compañía. La función DMSA permite a los desarrolladores especificar los permisos exactos de la herramienta a nivel compañía y proyecto que son necesarios para que su aplicación se ejecute correctamente en la plataforma Procore. Los administradores de la compañía definen a qué proyectos la aplicación puede acceder utilizando esos permisos. Los desarrolladores utilizan DMSAs para proporcionar una alternativa más conveniente y segura a los cuentas de servicio tradicional. Los administradores de la compañía se benefician de las DMSAs mediante la administración de aplicaciones mejorada y una mejor visibilidad del uso de aplicaciones.
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 para obtener mediante el uso de las DMSAs sobre los cuentas de servicio tradicional:
Administración de aplicaciones simplificada : los administradores de la compañía instalan y administran las aplicaciones mediante la función Administración de aplicaciones en la herramienta Administrador de la compañía. El usuario del Directorio asociado con el DMSA se crea automáticamente como parte del proceso de instalación de la aplicación. Con cuentas de servicio tradicional, los administradores de la compañía tienen que crear y administrar manualmente los cuenta y sus permisos de acceso, lo que requiere una comunicación y coordinación adicionales con el desarrollador externo para instalar y configurar la aplicación.
Administración de permisos más seguros : se definen todos los permisos de herramienta a nivel compañía y proyecto requeridos para una aplicación DMSA determinada en un manifiesto de aplicación que se aplica a la cuenta de su compañía durante el proceso de instalación. Cuando una aplicación incorpora nuevas funcionalidades y publica una versión actualizada, el desarrollador puede solicitar nuevos permisos a través del proceso de actualización para ser revisado y aprobado.
Se mejoró el control de acceso del proyecto : durante el proceso de instalación y configuración, los administradores de la compañía seleccionan exactamente qué proyectos se permite utilizar la aplicación DMSA. Con la cuentas de servicio tradicional, el administrador de la compañía configura y administra manualmente el acceso al proyecto, lo que puede ser lento y costoso, y puede ser menos seguro como se describe a continuación.
Mejor conocimiento del uso de aplicaciones: debido a que los DMSAs se instalan utilizando Administración de aplicaciones, los administradores de la compañía tienen visibilidad del uso de la aplicación en forma de indicadores de aplicación, como la cantidad de solicitudes de API, que los usuarios han instalado o utilizado una aplicación, que los proyectos pueden usar una aplicación y más. Con la cuentas de servicio tradicional, tales indicadores no se reúnen ni son accesibles.
La instalación y el uso de aplicaciones que utilizan cuentas de servicio tradicional viene con los siguientes riesgos:
Transmisión no asegurada de credenciales de API : debido a que un administrador de la compañía crea manualmente un servicio tradicional cuenta en Procore, el conjunto único de credenciales generadas API (client_id y client_secret) deben proporcionarse al desarrollador para completar correctamente la configuración de integración. La transmisión de esta información confidencial puede ocurrir desafortunadamente a través de medios no garantizados, como correo electrónico, mensaje de texto, etc., lo que deja los datos de la compañía potencialmente vulnerables.
Falta de datos de uso : si un servicio tradicional cuenta se compromete, es difícil rastrear dónde se está utilizando porque la cuenta no genera datos de uso.
Potencial de error humano : el requisito de configurar y administrar manualmente los permisos asociados con una cuenta de servicio tradicional pueden ser errores imprevistos y llevar a comportamientos inesperados de aplicación.
Aquí hay algunas de las diferencias principales entre las DMSAs y los cuentas de servicio tradicional.
| Cuenta de servicio administrada para programadores | Cuenta de servicio tradicional | |
| Creación de cuenta |
|
|
| Autorización |
|
|
| Permisos |
|
|
| Configuración del proyecto |
|
|
| Administración de aplicaciones |
|
|
Durante el proceso de instalación, se puede crear un nuevo registro de usuario en la herramienta Directorio de compañías o proyectos que representa el DMSA. El nombre de contacto de DMSA sigue un formato diferente con el nombre de la aplicación convertido a minúsculas y separados por guiones seguido de una identificación generada al azar 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 la compañía. Es importante que no edite ni elimine usuarios del directorio creados por instalaciones de aplicaciones DMSA, ya que esto puede causar problemas con la operación de la aplicación.
La administración de permisos para una cuenta de servicio administrada para desarrolladores (DMSA) implica una consideración cuidadosa para garantizar la funcionalidad de la aplicación y la seguridad de la cuenta. A continuación, se presentan las mejores prácticas y las consideraciones importantes para administrar los permisos de manera eficaz.
Use la pestaña Permisos para la membresía del proyecto: para administrar el acceso al proyecto DMSA, incluida la adición o eliminación de membresías de proyectos, utilice la pestaña Permisos dentro de la aplicación en Administración de aplicaciones. Esta opción está disponible para los administradores de la compañía.
Reconfiguración de permisos en la actualización o reinstalación de aplicaciones: cada vez que se actualiza o reinstala una aplicación, los administradores de la compañía deben volver a configurar la lista de proyectos permitidos. Los proyectos futuros que requieran acceso a DMSA también deben agregarse 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 administración de DMSA:
Evite las actualizaciones manuales de los permisos de DMSA: generalmente se desaconseja ajustar manualmente los permisos de DMSA dentro de la herramienta Directorio, ya que puede generar inconsistencias y complicar la administración de cuentas.
Limitar el acceso de DMSA a la herramienta de directorio a nivel compañía: evite otorgar acceso de nivel de administrador a la herramienta Directorio a nivel compañía para el usuario de DMSA. Este nivel de acceso permite cambios en varios proyectos y herramientas en su cuenta de Procore, lo que podría afectar los flujos de trabajo de su organización. Solo permita este nivel de acceso 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 de la industria para la autenticación con la API. La Procore API admite los siguientes dos tipos de otorgamiento de autorización o flujos de autenticación:
Código de autorización (flujo de inicio de sesión del usuario): las aplicaciones basadas en navegador y servidor web 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 opera en nombre del usuario que ha iniciado sesión actualmente al autenticarse con la Procore API. En este escenario, la aplicación asume los permisos del usuario que ha iniciado sesión y tiene acceso a cualquier herramienta, proyecto o datos con los que ese usuario en particular pueda interactuar. Dado que la gobernanza de permisos puede ser un desafío 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 de OAuth 2.0.
Los administradores de la compañía Procore son finalmente responsables de administrar 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 registrado) o client_credentials (permisos de servicio cuenta/DMSA).
Como proveedor de software como servicio (SaaS), Procore sigue un modelo de responsabilidad compartido en el contexto de seguridad de la plataforma.
Los clientes son responsables de las integraciones que instalan, permisos que aprueban para que esas integraciones utilicen y cualquier cambio que realicen en los usuarios del directorio (DMSA o tradicional) asociados con esas integraciones fuera de lo que proporciona Procore.
Socios/Desarrolladores son responsables del manejo de credenciales, el código que llama a la API y lo que hacen con los datos. El cliente proporciona las claves de los desarrolladores para que los desarrolladores los utilicen.
Procore es responsable de proporcionar a los desarrolladores un medio para solicitar permisos a los clientes a través de OAuth y clientes los habilidad instalar y administrar aplicaciones.