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.
Todas las cuentas de servicio tradicionales se puestas en sol 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 utilizan 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 por la fecha de puesta de sol dejará de funcionar. Cualquier aplicación enumerada en la App Marketplace de Procore que no utiliza un método compatible para acceder a la Procore API se eliminará en la fecha de puesta de sol. Consulte Aplicaciones de conexión de datosmigrantes para usar DMSAs para obtener información adicional.
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 estándar de la industria OAuth 2.0 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:
Código de autorización (flujo de inicio de sesión de usuario) - Las aplicaciones basadas en web y del navegador a menudo utilizan este tipo de concesión para la autenticación con la API. Con el tipo de otorgamiento del código de autorización, la aplicación opera en nombre del usuario registrado actualmente al autenticar con la API de Procore. En este escenario, la aplicación asume los permisos del usuario registrado y tiene acceso a cualquier herramienta, proyecto o datos con los que se permite que el usuario en particular interactúe. Debido a que la gobernanza 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 otorgamiento del código de autorización, consulte OAuth 2.0 Código de autorización Otorgar flujo.
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.