Pour les développeurs qui créent des applications utilisant des composants de connexion de données, nous recommandons d'utiliser la nouvelle fonction Developer Managed Service Accounts (DMSA) en tant qu'approche simplifiée pour fournir aux administrateurs Procore la possibilité d'installer et de provisionner facilement les applications de connexion de données dans leurs comptes d'entreprise. La fonction DMSA permet aux développeurs de spécifier les autorisations exactes des outils au niveau entreprise et projet qui sont nécessaires pour que leur application fonctionne correctement sur la plateforme Procore. Les administrateurs de l'entreprise définissent les projets auxquels l'application peut accéder à l'aide de ces autorisations. Les développeurs utilisent les DMSA pour offrir une alternative plus pratique et plus sûre aux comptes de service traditionnels. Les administrateurs de l'entreprise tirent profit des DMSA en améliorant la gestion des applications et la visibilité sur leur utilisation.
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.
L'utilisation des DMSA par rapport aux comptes de service traditionnels présente un certain nombre d'avantages :
Gestion simplifiée des applications - Les DMSA sont installés et gérés par les administrateurs de l'entreprise à l'aide de la fonction Gestion des applications de l'outil Admin de l'entreprise. L'utilisateur de l'annuaire associé au DMSA est automatiquement créé dans le cadre du processus d'installation de l'application. Avec les comptes de service traditionnels, les administrateurs de l'entreprise doivent créer et gérer manuellement le compte et ses autorisations d'accès, ce qui nécessite une communication et une coordination supplémentaires avec le développeur tiers pour installer et configurer l'application.
Gestion des autorisations plus sécurisée - Toutes les autorisations d'outil requises au niveau entreprise et au niveau projet pour une application DMSA donnée sont définies dans un manifeste d'application qui est appliqué à votre compte d'entreprise pendant le processus d'installation. Lorsqu'une application intègre de nouvelles fonctionnalités et publie une version mise à jour, le développeur peut demander de nouvelles autorisations via le processus de mise à niveau pour être révisées et approuvées.
Contrôle d'accès au projet amélioré - Au cours du processus d'installation et de configuration, les administrateurs de l'entreprise sélectionnent exactement les projets que l'application DMSA est autorisée à utiliser. Avec les comptes de service traditionnels, l'accès au projet est configuré et géré manuellement par l'administrateur de l'entreprise, ce qui peut prendre du temps et de l'argent, et peut être moins sécurisé, comme décrit ci-dessous.
Meilleure visibilité sur l'utilisation des applications : les DMSA étant installés à l'aide de la gestion des applications, les administrateurs de l'entreprise ont une visibilité sur l'utilisation des applications sous la forme de mesures d'application telles que le nombre de demandes d'API, les utilisateurs qui ont installé et/ou utilisé une application, les projets autorisés. utiliser une application, et plus encore. Avec les comptes de service traditionnels, ces mesures ne sont ni collectées ni accessibles.
L'installation et l'utilisation d'applications qui utilisent des comptes de service traditionnels comportent les risques suivants :
Transmission non sécurisée des informations d'identification de l'API - Étant donné qu'un compte de service traditionnel est créé manuellement dans Procore par un administrateur de l'entreprise, l'ensemble unique d'informations d'identification d'API générées (client_id et client_secret) doit être renvoyé au développeur afin de terminer la configuration de l'intégration. La transmission de ces informations sensibles peut malheureusement se produire par des moyens non sécurisés tels que les e-mails, les SMS, etc., laissant les données de l'entreprise potentiellement vulnérables.
Manque de données d'utilisation : si un compte de service traditionnel est compromis, il est difficile de savoir où il est utilisé, car le compte ne génère pas de données d'utilisation.
Potentiel d'erreur humaine : l'exigence de configurer et de gérer manuellement les autorisations associées à un compte de service traditionnel peut être sujette à des erreurs et entraîner un comportement inattendu de l'application.
Voici quelques-unes des principales différences entre les DMSA et les comptes de service traditionnels.
| Compte de service gérés pour les développeurs | Compte de service traditionnel | |
| Création de compte |
|
|
| Autorisation |
|
|
| Autorisations |
|
|
| Configuration du projet |
|
|
| Gestion des applications |
|
|
Au cours du processus d'installation, un nouvel enregistrement d'utilisateur peut être créé dans l'outil Annuaire de l'entreprise et/ou du projet qui représente le DMSA. Le nom du contact DMSA suit un format distinct avec le nom de l'application converti en minuscules et séparé par des tirets suivis d'un identifiant de huit caractères généré de manière aléatoire. Par exemple, l'installation de l'application Mon application de test DMSA créerait l'utilisateur my-dmsa-test-app-469b1f7f dans l'annuaire de l'entreprise. Il est important de ne pas modifier ni supprimer les utilisateurs de l'annuaire créés par les installations d'applications DMSA, car cela pourrait entraîner des problèmes de fonctionnement de l'application.
La gestion des autorisations pour un Compte de services gérés pour les développeurs (CSGD) implique une attention particulière pour garantir la fonctionnalité de l’application et la sécurité du compte. Vous trouverez ci-dessous les meilleures pratiques et les considérations importantes à prendre en compte pour gérer efficacement les autorisations.
Utiliser l’onglet Autorisations pour l’appartenance au projet - Pour gérer l’accès au projet DMSA, y compris l’ajout ou la suppression d’adhésions à des projets, utilisez l’onglet Autorisations dans l’application sous Gestion des applications. Cette option est disponible pour les administrateurs de l’entreprise.
Reconfiguration des autorisations lors de la mise à jour ou de la réinstallation de l’application : chaque fois qu’une application est mise à jour ou réinstallée, les administrateurs de l’entreprise doivent reconfigurer la liste des projets autorisés. Les futurs projets nécessitant un accès aux CSGD doivent également être ajoutés manuellement à la liste des projets autorisés.
Utilisation de l’outil Annuaire pour les modèles d’autorisation - Certains administrateurs utilisent l’outil Annuaire avec un modèle d’autorisation pour rationaliser la gestion des CSGD :
Évitez les mises à jour manuelles des autorisations DMSA - L’ajustement manuel des autorisations DMSA dans l’outil Annuaire est généralement déconseillé, car cela peut entraîner des incohérences et compliquer la gestion des comptes.
Limiter l’accès des CSGD à l’outil d’annuaire au niveau entreprise : évitez d’accorder à l’utilisateur des CSGD un accès de niveau administrateur à l’outil Annuaire au niveau entreprise. Ce niveau d’accès permet d’apporter des modifications à plusieurs projets et outils de votre compte Procore, ce qui peut avoir un impact sur les flux de travail de votre organisation. N’autorisez ce niveau d’accès que si cela est absolument nécessaire pour l’intégration et assurez-vous de bien comprendre les implications.
Les applications basées sur la plateforme Procore utilisent le cadre d’autorisation standard OAuth 2.0 pour l’authentification avec l’API. L’API Procore prend en charge les deux types d’autorisation, ou flux d’authentification suivants :
Code d’autorisation (flux de connexion de l’utilisateur) : les applications basées sur un serveur Web et un navigateur utilisent souvent ce type d’autorisation pour s’authentifier auprès de l’API. Avec le type d’autorisation Code, l’application fonctionne au nom de l’utilisateur actuellement connecté lors de l’authentification avec l’API Procore. Dans ce scénario, l’application assume les autorisations de l’utilisateur connecté et a accès à tous les outils, projets ou données avec lesquels cet utilisateur particulier est autorisé à interagir. Étant donné que la gouvernance des autorisations peut être difficile avec ce type d’accord, elle n’est pas recommandée pour les applications de connexion de données. Pour plus d’informations sur le type d’octroi de code d’autorisation, consultez Flux d’octroi de code d’autorisation OAuth 2.0.
Les administrateurs de l'entreprise Procore sont ultimement responsables de la gestion des autorisations des utilisateurs de leur annuaire, quel que soit le type d'octroi d'autorisation utilisé par une intégration : code_autorisation (autorisations de l'utilisateur connecté) ou identifiants_client (compte de service/autorisations DMSA).
En tant que fournisseur de logiciel en tant que service (SaaS), Procore suit un modèle de responsabilité partagée dans le contexte de la sécurité de la plate-forme.
Les clients sont responsables des intégrations qu'ils installent, des autorisations qu'ils approuvent pour l'utilisation de ces intégrations et de toutes les modifications qu'ils apportent aux utilisateurs de l'annuaire (DMSA ou traditionnel) associés à ces intégrations en dehors de ce que Procore fournit.
Les partenaires/développeurs sont responsables du traitement des informations d'identification, du code qui appelle l'API et de ce qu'ils font avec les données. Le client fournit les clés aux développeurs à utiliser par les développeurs.
Procore est chargé de fournir aux développeurs un moyen de demander des autorisations aux clients via OAuth et aux clients la possibilité d'installer et de gérer des applications.