¿Qué es una cuenta de servicio administrada para programadores?

Última actualización
Guardar como PDF

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.

Beneficios de utilizar cuentas de servicio administradas para programadores (DMSAs)

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.

Riesgos asociados con cuentas de servicio tradicionales

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.

¿Cómo difiere un DMSA de un servicio tradicional cuenta?

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	Un usuario del directorio asociado con el DMSA se crea automáticamente en la herramienta Directorio de compañía o proyecto.	Un administrador de la compañía debe crear y administrar manualmente un administrador de la compañía una cuenta de servicio tradicional.
Autorización	Se utiliza un único conjunto de credenciales (client_id, client_secret) para acceder a todas las compañías donde se instala la aplicación.	Cada servicio cuenta creado en una compañía por un administrador tiene un conjunto único de credenciales, requiriendo una coordinación manual con el desarrollador para una integración exitosa.
Permisos	Los permisos requeridos se definen por 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 deben configurarse manualmente por un administrador de la compañía.
Configuración del proyecto	Durante la instalación, puede seleccionar en qué proyectos se permite ejecutar la aplicación DMSA. Una vez instalada la aplicación, puede agregar o quitar proyectos permitidos según sea necesario.	El administrador de la compañía debe configurar y administrar manualmente el acceso al proyecto.
Administración de aplicaciones	Las aplicaciones habilitadas por DMSA se instalan fácilmente desde App Marketplace o como una instalación personalizada. Herramienta administrador de la compañía (Administración de aplicaciones) utilizada para desinstalar/reinstalar.	Todos los aspectos de la cuenta instalación y administración de servicios tradicionales deben ser manipulados manualmente por el administrador de la compañía.

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

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.

Implicaciones de otorgar permisos de administrador del directorio a las aplicaciones

Los administradores de la compañía se advierten encarecidamente contra otorgar acceso de administrador a la herramienta Directorio a nivel compañía a las aplicaciones que utilizan DMSAs o cuentas de servicio tradicional. Las aplicaciones con este nivel de acceso más alto tienen la habilidad para realizar cambios que pueden afectar negativamente todas las herramientas de un proyecto completo o todos los proyectos de toda la compañía Procore de su organización cuenta. Si bien algunas aplicaciones pueden requerir esta función, recomendamos revisar exhaustivamente la necesidad de la integración y entender el impacto antes de permitir.

Comprender la autenticación API de Procore

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:

Credenciales de cliente (DMSAs y cuentas de servicio tradicional) - 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 único conjunto de credenciales de API (a través de una cuenta de servicio DMSA o de servicio tradicional) para autenticar 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 compañía pueden especificar las herramientas exactas y los proyectos 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 Usar la OAuth 2.0 Tipo de concesión de credenciales de cliente.
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).

Modelo de seguridad de responsabilidad compartida

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.

Puesta de sol de cuentas de servicio tradicionales